From nobody Wed Jan 1 10:44:29 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EE91200C4 for ; Wed, 1 Jan 2020 10:44:27 -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, 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 (1024-bit key) header.d=isoc.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etsbHuW762w8 for ; Wed, 1 Jan 2020 10:44:24 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2066.outbound.protection.outlook.com [40.107.220.66]) (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 7E420120044 for ; Wed, 1 Jan 2020 10:44:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oECpuPIkGLbduYrOEaS839TQETxABbsB6Q9JG3+qHJrk11zkUgKmtNh9wvPoDskqNu+pSzoaG54CXSyrTdeIdmarvwuNbwYQ+iIzYc0EwR0vX4bA5+Zk/PfRRLs8CffGi2soINEfPkMnRnESeino23WBtaAuZ/r+9sIFJibV0u/jDLHMwgKbnczgBDhvKR2FlwgewnNMSZp30j6Wzm+1IA/nSamjsuVk4v7salRZHn/9hnpYf0aASLAbfJOTm/WRERQHBv5t3AQlGeemxuc+qfJNzLvI9qKfol3hFS49+uTpoQphkjXkN0+CEPbHZDKfsF+gZl5MBeV6fpi4Hxo14Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O9gRW+0rMQVClRv1BjYWIcBmk3q37RHdd04guoXQjug=; b=lXogYI5HLdkmL5ZEq672PYuBNRYChrgnt3GtKS9U6qEmmAh/l8uwR3sN1CN3NhWJojR+9U1xJnxihebPpriyOPs7it0lPmitLl6Cy1NZ90Sx288rQRF2FkgpGyeBP5/2lOfJ38PTko6eXDrgoUkQ6jmWxY1nqFrQcfESh2dLRvrGXw3BS1q7vrUsRcbeZwoSsxS9faspjSrrUn8IVryYiicsptO0Rm1utU/yy4b9UddFSWTBkFq9D/JpQkJ0GXi0AHUjENM4nBgVAaZjxdJF36DNvTHuqAuF4wnc2vvxWMtagLGvr7vgSgY3GEQzBK0DnifESUco+DQvG/r9UPc1uA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O9gRW+0rMQVClRv1BjYWIcBmk3q37RHdd04guoXQjug=; b=uaUYJo/79fbIHNZPSfGoQ6fCX6oQnp6tDUmIQKd0BEkfKRn60aFhu1WavTOlNiQbwaOHM1FfNnhoia1UrCWhWVQQGqazEw6yqwwivRaRl4f93jAmTf7QI8ew7lDk1w+rFziQ6JOcQgypvmJB7EQzIMMTM69fC3j4QxVHJjFXIoo= Received: from DM5PR06MB2649.namprd06.prod.outlook.com (10.168.199.143) by DM5PR06MB2778.namprd06.prod.outlook.com (10.175.107.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.12; Wed, 1 Jan 2020 18:44:22 +0000 Received: from DM5PR06MB2649.namprd06.prod.outlook.com ([fe80::2c2d:4ecc:c8f0:115d]) by DM5PR06MB2649.namprd06.prod.outlook.com ([fe80::2c2d:4ecc:c8f0:115d%5]) with mapi id 15.20.2602.010; Wed, 1 Jan 2020 18:44:22 +0000 From: Dan York To: Lucy Lynch CC: Stephen Farrell , "architecture-discuss@iab.org" Thread-Topic: [arch-d] possible new IAB programme on Internet resilience Thread-Index: AQHVtzoIc/E2h2BESU61KFOCTP34h6fUsiuAgAGGVQA= Date: Wed, 1 Jan 2020 18:44:21 +0000 Message-ID: <7020A5C7-6D06-4D6B-85DD-3FCE9CFC03C7@isoc.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org; x-originating-ip: [2601:198:4100:84b0:413e:b645:50a0:2e94] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3a89214e-748a-49bb-6810-08d78eea9dfe x-ms-traffictypediagnostic: DM5PR06MB2778: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39840400004)(396003)(136003)(366004)(189003)(199004)(53546011)(81166006)(66476007)(66446008)(66946007)(64756008)(33656002)(4326008)(2906002)(76116006)(8936002)(2616005)(36756003)(6506007)(86362001)(45080400002)(81156014)(71200400001)(66556008)(186003)(8676002)(91956017)(5660300002)(66574012)(508600001)(6486002)(966005)(6916009)(54906003)(316002)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR06MB2778; H:DM5PR06MB2649.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: K5abxhXHwHsSnO5kxsMsOR+KHRWBFMul50tpzocKn8/pbURhvX62n1mhWdosAoKjrKLD3KVhPv9wWrKLGxtcJAX78rKAtI0A1UYXbqMBNFKIG/ugYAbsZJCfHvvNt5/d7AHMpfTqz+l4mxepNM16X6Bl4p/O3qmWP112NXgg+MxP/yQv3OAmRD7gHxxAfU/USa/Q/mrJpy7o1qD8g0CTldEVLvoOavtHmndlcwuXJBTXlHRXVrfAfL13AKpKJHzRWkrUzI9o6J0Q2UPxz5Bw8a3teprgW8lphOMwahsEzuoCfx57TC/fLYNzXzvv3jmkmscMVrXsNOKbKevKUbsi5lUE1gQRP9INQA/PBW18q8qA6zdAjHvCBRJr47M59ZneCAsCgaqcEv6uLXzf+yPtEZDG8ovMfrFibtltEdpJF7ocxdD2tnXdmC4koaQawIXP9EiNBWPcQNHdxgOQcDizl0fQQWtp0UcS/5FvPDI7Wzg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_7020A5C76D064D6B85DD3FCE9CFC03C7isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 3a89214e-748a-49bb-6810-08d78eea9dfe X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jan 2020 18:44:21.7962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: juf1ec/srIYasbN4BU9CUVPwMAKPUBZWNPB7/3rit364GsE+lz1i6C1FT2M6rJlY X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2778 Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2020 18:44:28 -0000 --_000_7020A5C76D064D6B85DD3FCE9CFC03C7isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3RlcGhlbiwNCg0KTHVjeSB2ZXJ5IG5pY2VseSBjYXB0dXJlZCBhIGNvbmNlcm4gSeKAmWQgaGFk 4oCmIHVwb24gd2hpY2ggSSBleHBhbmRlZCBhIGJpdCBiZWxvdy4uDQoNCk9uIERlYyAzMSwgMjAx OSwgYXQgMjoyNyBQTSwgTHVjeSBMeW5jaCA8bGx5bmNoQGNpdmlsLXRvbmd1ZS5uZXQ8bWFpbHRv OmxseW5jaEBjaXZpbC10b25ndWUubmV0Pj4gd3JvdGU6DQoNCk9uIEZyaSwgMjAgRGVjIDIwMTks IFN0ZXBoZW4gRmFycmVsbCB3cm90ZToNCg0KDQpbMV0gaHR0cHM6Ly9naXRodWIuY29tL2ludGFy Y2hib2FyZC9yZXNpbGllbmNlLw0KDQoNCkNpcmNsaW5nIGJhY2sgdG8gdGhlIHRvcCBoZXJlLg0K DQpJIHRoaW5rIHRoaXMgaXMgYSBmaW5lIHRvcGljIGZvciBhbiBJQUIgcHJvZ3JhbSBhbmQgSSB0 b29rIHRoZQ0KZHJhZnQgY2hhcnRlciB0byBlbmNvbXBhc3MgcmVzaWxpZW5jZSBhcyBib3RoIGEg dGVjaG5pY2FsIGFuZCBhDQpkZXNpZ24gcHJvYmxlbS4NCg0KSSBhbHNvIGFncmVlIHRoYXQgdGhp cyBzZWVtcyB0byBiZSBhIGdyZWF0IHRvcGljIGZvciBhbiBJQUIgcHJvZ3JhbS4NCg0KSSBhbSBw YXJ0aWN1bGFybHkgaW50ZXJlc3RlZCBpbiB0aGlzIHN0YXRlbWVudDoNCi0tLS0NCkRlZmluaXRp b24gb2YgcmVzaWxpZW5jZToNCg0KMV0gIHRoZSBjYXBhYmlsaXR5IG9mIGEgc3RyYWluZWQgYm9k eSB0byByZWNvdmVyIGl0cyBzaXplIGFuZCBzaGFwZQ0KICAgYWZ0ZXIgZGVmb3JtYXRpb24gY2F1 c2VkIGVzcGVjaWFsbHkgYnkgY29tcHJlc3NpdmUgc3RyZXNzDQoyXSAgYW4gYWJpbGl0eSB0byBy ZWNvdmVyIGZyb20gb3IgYWRqdXN0IGVhc2lseSB0byBtaXNmb3J0dW5lIG9yIGNoYW5nZQ0KDQpU aGlzIHByb2dyYW0gaXMgbW9zdGx5IGludGVyZXN0ZWQgaW4gZGVmaW5pdGlvbiAjMi4NCi0tLS0N CkkgYWN0dWFsbHkgaGF2ZSBteSBvd24gY29uY2VybnMgcmVsYXRlZCB0byAjMSBhcyB3ZWxsIGFu ZCB3b3VsZCBob3BlIHRoYXQgdGhpcyBwcm9ncmFtIG1pZ2h0IGNvbnNpZGVyIHRoZSB3YXJwaW5n IG9mIHRoZSBvdmVyYWxsIEludGVybmV0IG1vZGVsIHRvIGFjY29tbW9kYXRlIGN1cnJlbnRzIHRy ZW5kcyBvciBidXNpbmVzcyBwcmFjdGljZXMuDQoNCkFzIGFuIGV4YW1wbGUgLSBhbiBJbnRlcm5l dCBvcHRpbWl6ZWQgZm9yIHRoZSB3ZWIgbWF5IG5vdCBiZSB0aGUgc2FtZQ0KaW50ZXJuZXQgdGhh dCBzdXBwb3J0cyByZWFsIHRpbWUgZGF0YSBjb2xsZWN0aW9uIGFuZCBzaGFyZWQgY29tcHV0YXRp b24gaW4gdGhlIGNvbnRleHQgb2YgYmlnIHNjaWVuY2UuIEhvdyBkbyB3ZSBhdm9pZCBjbG9zaW5n IG91dCBjYXBhYmlsaXRpZXMgYXMgd2Ugb3B0aW1pemUgZm9yIG90aGVycz8gTmFycm93aW5nIG9m IGNob2ljZXMgbG9va3MgbGlrZSBhIHBhdGggdG8gYSBsaW1pdGVkIGFuZCBtb3JlIGJyaXR0bGUg bW9kZWwgdG8gbWUuDQoNCkkgYWdyZWUgd2l0aCBMdWN54oCZcyBleGFtcGxl4oCmIGFuZCB3b3Vs ZCBhbHNvIG5vdGUgdGhhdCBvdGhlciBzb3VyY2VzIG9mIOKAnGNvbXByZXNzaXZlIHN0cmVzc+KA nSBjb3VsZCBiZSB0aGUgaW5jcmVhc2luZyBtb3ZlbWVudCBvZiBtb3N0IGFsbCByZWFsLXRpbWUg Y29tbXVuaWNhdGlvbiB2aWEgdm9pY2UgYW5kIHZpZGVvIHRvIGJlIG92ZXIgdGhlIEludGVybmV0 LCBhbmQgbW9zdCByZWNlbnRseSB0aGUgdmVyeSBsYXJnZSBtb3ZlbWVudCBvZiBzdHJlYW1pbmcg b25saW5lIGdhbWluZywgd2hpY2ggaGFzIHZlcnkgZGlmZmVyZW50IGNoYXJhY3RlcmlzdGljcyBh bmQgc3RyZXNzIGZhY3RvcnMgKGFzIG5vdGVkIGluIHJlY2VudCBkaXNjdXNzaW9ucyBpbiB0aGUg bmV3IE1PUFMgd29ya2luZyBncm91cCBhbmQgdGhlIEJPRiBiZWZvcmUgaXQpLg0KDQpJIGxpa2Ug THVjeeKAmXMgcGhyYXNlICJ0aGUgd2FycGluZyBvZiB0aGUgb3ZlcmFsbCBJbnRlcm5ldCBtb2Rl bCB0byBhY2NvbW1vZGF0ZSBjdXJyZW50IHRyZW5kcyBvciBidXNpbmVzcyBwcmFjdGljZXMs4oCd IHBhcnRpY3VsYXJseSB3aGVuIHNvbWUgb2YgdGhvc2UgY3VycmVudCBidXNpbmVzcyBwcmFjdGlj ZXMgbWF5IGludm9sdmUgY29ubmVjdGluZyBuZXR3b3JrcyBub3Qgb25seSB0byB0aGUgcHVibGlj IEludGVybmV0LCBidXQgYWxzbyB0byBwcml2YXRlLCBwcm9wcmlldGFyeSwgZ2xvYmUtc3Bhbm5p bmcgbmV0d29ya3MuDQoNCkZvciBleGFtcGxlLCBhdCBBbWF6b27igJlzIHJlY2VudCByZTpJbnZl bnQgY29uZmVyZW5jZSB0aGV5IHByb21vdGVkIGEgd2F5IHRvIGRpcmVjdGx5IGNvbm5lY3QgZW50 ZXJwcmlzZSBkYXRhIGNlbnRlcnMgdG8gQW1hem9u4oCZcyBnbG9iYWwgQVdTIG5ldHdvcmsgKOKA nE91dHBvc3Rz4oCdKSBhbmQgYWxzbyBhIHdheSB0byBjb25uZWN0IHRlbGNvIHBvaW50cy1vZi1w cmVzZW5jZSB0byBBbWF6b27igJlzIG5ldHdvcmsgKOKAnFdhdmVsZW5ndGjigJ0pLiBNeSB1bmRl cnN0YW5kaW5nIGlzIHRoYXQgTWljcm9zb2Z0IGhhcyBzaW1pbGFyIGZ1bmN0aW9uYWxpdHkgZm9y IEF6dXJlICjigJxTdGFja+KAnSwgSSBiZWxpZXZlKSBhbmQgR29vZ2xlIGVpdGhlciBoYXMgb3Ig aXMgd29ya2luZyBvbiBzb21ldGhpbmcgc2ltaWxhciBmb3IgdGhlaXIgR29vZ2xlIENsb3VkIFBs YXRmb3JtLiBTaW1pbGFybHksIGxhcmdlIGVudGl0aWVzIHN1Y2ggYXMgRmFjZWJvb2sgYW5kIE5l dGZsaXggaGF2ZSBidWlsdCB0aGVpciBvd24gZ2xvYmFsLCBwcml2YXRlIG5ldHdvcmtzIHRoYXQg aW50ZXJjb25uZWN0IHRvIGxvY2FsIGRhdGEgY2VudGVycyAod2hlcmUgdGhvc2UgZGF0YSBjZW50 ZXJzIGFyZSBhbHNvIGNvbm5lY3RlZCB0byB0aGUgcHVibGljIEludGVybmV0KS4NCg0KQWxsIG9m IHRoZXNlIHNlcGFyYXRlLCBwcml2YXRlLCBnbG9iYWwgbmV0d29ya3MgYXJlIGRlc2lnbmVkIHRv IGhlbHAgc3BlZWQgYWNjZXNzIHRvIGNvbnRlbnQsIGFwcGxpY2F0aW9ucywgZXRjLiwgdGhyb3Vn aCBjYWNoaW5nLCDigJxlZGdl4oCdIGNvbXB1dGluZywgYW5kIG90aGVyIHRlY2hub2xvZ2llcy4g VGhpbmtpbmcgYXMgYSBuZXR3b3JrIGVuZ2luZWVyIGFib3V0IHJ1bm5pbmcgYXBwbGljYXRpb25z IGluIHZhcmlvdXMgY2xvdWQgcHJvdmlkZXJzLCBJIGNhbiBzZWUgdGhlIHZhbHVlIHRoYXQgY291 bGQgYmUgb2J0YWluZWQgYnkgdGhlc2UgY29ubmVjdGlvbnMuIEFuZCBzb21lIG9mIHRoZXNlIHBy b3ZpZGVycyBhcmUgdHlwaWNhbGx5IHByb21vdGluZyB0aGVzZSBzZXJ2aWNlcyBhcyBwcm92aWRp bmcgYSBsb3ctbGF0ZW5jeSBhbHRlcm5hdGl2ZSB0byBzZW5kaW5nIHRyYWZmaWMgYWNyb3NzIHRo ZSBwdWJsaWMgSW50ZXJuZXQuDQoNCkdvaW5nIGJhY2sgdG8gdGhlIGRyYWZ0IGNoYXJ0ZXIgdGV4 dCAoIGh0dHBzOi8vZ2l0aHViLmNvbS9pbnRhcmNoYm9hcmQvcmVzaWxpZW5jZS8gKSAsIEkgbm90 ZSB0aGlzOg0KDQo+IE9uZSBmdW5kYW1lbnRhbCBwYXR0ZXJuIGNvbnRyaWJ1dGluZyB0byBJbnRl cm5ldCByZXNpbGllbmNlIGlzIGRpdmVyc2l0eTogZm9yIGV4YW1wbGUsIGRpdmVyc2l0eSBvZiBw aHlzaWNhbCBsaW5rcywgb2YgcGVlciBuZXR3b3Jrcywgb2YgcGF0aHMgdGhyb3VnaCB0aGUgbmV0 d29yay4gTGFjayBvZiBkaXZlcnNpdHkgaXMgYSBrZXkgY2hhbGxlbmdlIGZvciBJbnRlcm5ldCBy ZXNpbGllbmNlLg0KDQpXaGF0IGlmIHRoZXJlIHdpbmRzIHVwIGJlaW5nIGEgbGFjayBvZiBkaXZl cnNpdHkgb2YgcGF0aHMgdGhyb3VnaCB0aGUg4oCcb3BlbuKAnSBhbmQg4oCccHVibGlj4oCdIElu dGVybmV0PyBXaGF0IGlmIGluY3JlYXNpbmdseSB0cmFmZmljIHdpbmRzIHVwIHRyYXZlbGluZyB0 aHJvdWdoIHRoZXNlIHByb3ByaWV0YXJ5IGdsb2JhbCBuZXR3b3JrcyAodG8gd2hpY2ggeW91IG5l ZWQgdG8gcGF5IHRvIGNvbm5lY3QgYW5kIHRocm91Z2ggdGhhdCBnYWluIHBlcm1pc3Npb24gdG8g c2VuZCB0cmFmZmljIC0gYW5kIG9ubHkgdG8gdGhhdCBjb21wYW554oCZcyBwbGF0Zm9ybXMpPw0K DQpHaXZlbiB0aGF0IHRoZSBJbnRlcm5ldCBoYXMgYWx3YXlzIGJlZW4gYSDigJxuZXR3b3JrIG9m IG5ldHdvcmtz4oCdLCB0aGVyZSBoYXZlIGJlZW4gKGFuZCBzdGlsbCBhcmUpIG11bHRpcGxlIGxh cmdlLCBnbG9iYWwgbmV0d29ya3MgdG8gd2hpY2ggeW91IGNvdWxkIGNvbm5lY3QgeW91ciBuZXR3 b3JrIGFuZCBkYXRhIGNlbnRlcnMuIFlvdSBtYXksIGluIGZhY3QsIGNvbm5lY3QgdG8gbXVsdGlw bGUgb2YgdGhvc2UgbGFyZ2UsIGdsb2JhbCBJU1BzIHRvIGhhdmUgYSBoaWdoZXIgZGVncmVlIG9m IOKAnHJlc2lsaWVuY2XigJ0gZm9yIHlvdXIgbmV0d29yay4gVGhlIGRpZmZlcmVuY2UgdG8gbWUg aXMgdGhhdCBpbiBjb25uZWN0aW5nIHRvIHRob3NlIG5ldHdvcmsgcHJvdmlkZXJzIChhbmQgcGF5 aW5nIHRvIGRvIHNvKSwgeW91IGFyZSBjb25uZWN0aW5nIHRvIHRoZSBvcGVuLCBwdWJsaWMgSW50 ZXJuZXQuDQoNCkluIGNvbnRyYXN0LCBjb25uZWN0aW5nIHRvIHRoZXNlIG5ld2VyIHByaXZhdGUg bmV0d29ya3MgZ2l2ZXMgeW91IG9ubHkgYWNjZXNzIHRvIHRoZSBjb21wYW554oCZcyBjbG91ZCBv ciBjb250ZW50IHBsYXRmb3JtLiBJdOKAmXMgbm90IHRoZSB3aG9sZSBJbnRlcm5ldC4NCg0KU28g cmVnYXJkaW5nIGRlZmluaXRpb24gIzIsIGhvdyBkb2VzIHRoaXMgZXZvbHV0aW9uIGluIG5ldHdv cmsgY29ubmVjdGl2aXR5IGltcGFjdCB0aGUgb3ZlcmFsbCByZXNpbGllbmNlIG9mIHRoZSBJbnRl cm5ldCB0byByZWNvdmVyIGZyb20gaXNzdWVzPw0KDQpJIHRoaW5rIGl04oCZcyBhIHZlcnkgaW50 ZXJlc3RpbmcgcXVlc3Rpb24gdG8gY29uc2lkZXIgYXMgcGFydCBvZiB0aGlzIHByb2dyYW0uDQoN Ck15IDIgY2VudHMsDQpEYW4NCg0KUC5TLiBBbmQgeWVzLCBJ4oCZbSB3ZWxsIGF3YXJlIHRoYXQg c29tZSBsYXJnZSBlbnRlcnByaXNlcyBhbHNvIG9wZXJhdGUgdGhlaXIgb3duIHByaXZhdGUsIGds b2JhbCBuZXR3b3JrcyAvIFdBTnMgdG8gaW50ZXJjb25uZWN0IHRoZWlyIG93biBkYXRhIGNlbnRl cnMgLSBhbmQgaGF2ZSBkb25lIHNvIGZvciBtYW55IHllYXJzLiBJIHRoaW5rIHRoZSBkaWZmZXJl bmNlIGlzIG9uZSBvZiBzY2FsZS4gVGhlIG5ldyDigJxjbG91ZOKAnSBwcm92aWRlcnMgYXJlIG9w ZXJhdGluZyBuZXR3b3JrcyBzaWduaWZpY2FudGx5IGxhcmdlciB0aGFuIGFueSBpbmRpdmlkdWFs IGVudGVycHJpc2UgLSBhbmQgYXJlIGFsc28gZW5jb3VyYWdpbmcgZW50ZXJwcmlzZXMgdG8gbW92 ZSBhd2F5IGZyb20gb3BlcmF0aW5nIHRoZWlyIG93biBuZXR3b3JrcyBhbmQgdG8gaW5zdGVhZCBt b3ZlIHRoZWlyIG5ldHdvcmtpbmcgdG8gdGhlc2UgbmV3ZXIgbmV0d29ya3MuDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg== --_000_7020A5C76D064D6B85DD3FCE9CFC03C7isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClN0ZXBoZW4sDQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5MdWN5IHZlcnkgbmljZWx5IGNhcHR1cmVk IGEgY29uY2VybiBJ4oCZZCBoYWTigKYgdXBvbiB3aGljaCBJIGV4cGFuZGVkIGEgYml0IGJlbG93 Li48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBEZWMgMzEsIDIwMTksIGF0 IDI6MjcgUE0sIEx1Y3kgTHluY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpsbHluY2hAY2l2aWwtdG9u Z3VlLm5ldCIgY2xhc3M9IiI+bGx5bmNoQGNpdmlsLXRvbmd1ZS5uZXQ8L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPk9uDQog RnJpLCAyMCBEZWMgMjAxOSwgU3RlcGhlbiBGYXJyZWxsIHdyb3RlOjwvc3Bhbj48YnIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpbMV0gPGEgaHJlZj0i aHR0cHM6Ly9naXRodWIuY29tL2ludGFyY2hib2FyZC9yZXNpbGllbmNlLyIgY2xhc3M9IiI+aHR0 cHM6Ly9naXRodWIuY29tL2ludGFyY2hib2FyZC9yZXNpbGllbmNlLzwvYT48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj b3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+Q2lyY2xpbmcNCiBiYWNrIHRvIHRoZSB0b3AgaGVyZS48L3NwYW4+PGJyIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj5JDQogdGhpbmsgdGhpcyBpcyBhIGZpbmUgdG9waWMgZm9yIGFuIElBQiBw cm9ncmFtIGFuZCBJIHRvb2sgdGhlPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0 aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i Ij5kcmFmdA0KIGNoYXJ0ZXIgdG8gZW5jb21wYXNzIHJlc2lsaWVuY2UgYXMgYm90aCBhIHRlY2hu aWNhbCBhbmQgYTwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ZGVzaWduDQog cHJvYmxlbS4gPC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXY+SSBhbHNvIGFncmVlIHRoYXQgdGhpcyBzZWVtcyB0byBiZSBhIGdyZWF0 IHRvcGljIGZvciBhbiBJQUIgcHJvZ3JhbS48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj5JDQogYW0gcGFydGljdWxhcmx5IGludGVyZXN0ZWQgaW4gdGhp cyBzdGF0ZW1lbnQ6PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyIgY2xhc3M9IiI+DQotLS0tPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZs b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkRlZmluaXRp b24NCiBvZiByZXNpbGllbmNlOjwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPjFdDQog Jm5ic3A7dGhlIGNhcGFiaWxpdHkgb2YgYSBzdHJhaW5lZCBib2R5IHRvIHJlY292ZXIgaXRzIHNp emUgYW5kIHNoYXBlPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBm bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4mbmJzcDsm bmJzcDsmbmJzcDthZnRlcg0KIGRlZm9ybWF0aW9uIGNhdXNlZCBlc3BlY2lhbGx5IGJ5IGNvbXBy ZXNzaXZlIHN0cmVzczwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsg ZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Ml0NCiAm bmJzcDthbiBhYmlsaXR5IHRvIHJlY292ZXIgZnJvbSBvciBhZGp1c3QgZWFzaWx5IHRvIG1pc2Zv cnR1bmUgb3IgY2hhbmdlPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+VGhpcw0KIHBy b2dyYW0gaXMgbW9zdGx5IGludGVyZXN0ZWQgaW4gZGVmaW5pdGlvbiAjMi48L3NwYW4+PGJyIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCi0tLS08YnIgc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SQ0KIGFjdHVhbGx5IGhhdmUgbXkgb3duIGNvbmNlcm5z IHJlbGF0ZWQgdG8gIzEgYXMgd2VsbCBhbmQgd291bGQgaG9wZSB0aGF0IHRoaXMgcHJvZ3JhbSBt aWdodCBjb25zaWRlciB0aGUgd2FycGluZyBvZiB0aGUgb3ZlcmFsbCBJbnRlcm5ldCBtb2RlbCB0 byBhY2NvbW1vZGF0ZSBjdXJyZW50cyB0cmVuZHMgb3IgYnVzaW5lc3MgcHJhY3RpY2VzLjwvc3Bh bj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJy IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkFzDQogYW4gZXhhbXBsZSAtIGFuIEludGVybmV0 IG9wdGltaXplZCBmb3IgdGhlIHdlYiBtYXkgbm90IGJlIHRoZSBzYW1lPC9zcGFuPjxiciBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5pbnRlcm5ldA0KIHRoYXQgc3VwcG9ydHMgcmVhbCB0aW1l IGRhdGEgY29sbGVjdGlvbiBhbmQgc2hhcmVkIGNvbXB1dGF0aW9uIGluIHRoZSBjb250ZXh0IG9m IGJpZyBzY2llbmNlLiBIb3cgZG8gd2UgYXZvaWQgY2xvc2luZyBvdXQgY2FwYWJpbGl0aWVzIGFz IHdlIG9wdGltaXplIGZvciBvdGhlcnM/IE5hcnJvd2luZyBvZiBjaG9pY2VzIGxvb2tzIGxpa2Ug YSBwYXRoIHRvIGEgbGltaXRlZCBhbmQgbW9yZSBicml0dGxlIG1vZGVsIHRvIG1lLjwvc3Bhbj48 YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KSSBhZ3JlZSB3aXRo IEx1Y3nigJlzIGV4YW1wbGXigKYgYW5kIHdvdWxkIGFsc28gbm90ZSB0aGF0IG90aGVyIHNvdXJj ZXMgb2Yg4oCcY29tcHJlc3NpdmUgc3RyZXNz4oCdIGNvdWxkIGJlIHRoZSBpbmNyZWFzaW5nIG1v dmVtZW50IG9mIG1vc3QgYWxsIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIHZpYSB2b2ljZSBhbmQg dmlkZW8gdG8gYmUgb3ZlciB0aGUgSW50ZXJuZXQsIGFuZCBtb3N0IHJlY2VudGx5IHRoZSB2ZXJ5 IGxhcmdlIG1vdmVtZW50IG9mIHN0cmVhbWluZw0KIG9ubGluZSBnYW1pbmcsIHdoaWNoIGhhcyB2 ZXJ5IGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3MgYW5kIHN0cmVzcyBmYWN0b3JzIChhcyBub3Rl ZCBpbiByZWNlbnQgZGlzY3Vzc2lvbnMgaW4gdGhlIG5ldyBNT1BTIHdvcmtpbmcgZ3JvdXAgYW5k IHRoZSBCT0YgYmVmb3JlIGl0KS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+SSBsaWtlIEx1Y3nigJlzIHBocmFzZSAmcXVvdDt0aGUgd2FycGluZyBvZiB0aGUgb3Zl cmFsbCBJbnRlcm5ldCBtb2RlbCB0byBhY2NvbW1vZGF0ZSBjdXJyZW50IHRyZW5kcyBvciBidXNp bmVzcyBwcmFjdGljZXMs4oCdIHBhcnRpY3VsYXJseSB3aGVuIHNvbWUgb2YgdGhvc2UgY3VycmVu dCBidXNpbmVzcyBwcmFjdGljZXMgbWF5IGludm9sdmUgY29ubmVjdGluZyBuZXR3b3JrcyBub3Qg b25seSB0byB0aGUgcHVibGljIEludGVybmV0LCBidXQgYWxzbyB0bw0KIHByaXZhdGUsIHByb3By aWV0YXJ5LCBnbG9iZS1zcGFubmluZyBuZXR3b3Jrcy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkZvciBleGFtcGxlLCBhdCBBbWF6b27igJlzIHJlY2VudCBy ZTpJbnZlbnQgY29uZmVyZW5jZSB0aGV5IHByb21vdGVkIGEgd2F5IHRvIGRpcmVjdGx5IGNvbm5l Y3QgZW50ZXJwcmlzZSBkYXRhIGNlbnRlcnMgdG8gQW1hem9u4oCZcyBnbG9iYWwgQVdTIG5ldHdv cmsgKOKAnE91dHBvc3Rz4oCdKSBhbmQgYWxzbyBhIHdheSB0byBjb25uZWN0IHRlbGNvIHBvaW50 cy1vZi1wcmVzZW5jZSB0byBBbWF6b27igJlzIG5ldHdvcmsgKOKAnFdhdmVsZW5ndGjigJ0pLiBN eSB1bmRlcnN0YW5kaW5nDQogaXMgdGhhdCBNaWNyb3NvZnQgaGFzIHNpbWlsYXIgZnVuY3Rpb25h bGl0eSBmb3IgQXp1cmUgKOKAnFN0YWNr4oCdLCBJIGJlbGlldmUpIGFuZCBHb29nbGUgZWl0aGVy IGhhcyBvciBpcyB3b3JraW5nIG9uIHNvbWV0aGluZyBzaW1pbGFyIGZvciB0aGVpciBHb29nbGUg Q2xvdWQgUGxhdGZvcm0uIFNpbWlsYXJseSwgbGFyZ2UgZW50aXRpZXMgc3VjaCBhcyBGYWNlYm9v ayBhbmQgTmV0ZmxpeCBoYXZlIGJ1aWx0IHRoZWlyIG93biBnbG9iYWwsIHByaXZhdGUNCiBuZXR3 b3JrcyB0aGF0IGludGVyY29ubmVjdCB0byBsb2NhbCBkYXRhIGNlbnRlcnMgKHdoZXJlIHRob3Nl IGRhdGEgY2VudGVycyBhcmUgYWxzbyBjb25uZWN0ZWQgdG8gdGhlIHB1YmxpYyBJbnRlcm5ldCku PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5BbGwgb2YgdGhlc2Ugc2Vw YXJhdGUsIHByaXZhdGUsIGdsb2JhbCBuZXR3b3JrcyBhcmUgZGVzaWduZWQgdG8gaGVscCBzcGVl ZCBhY2Nlc3MgdG8gY29udGVudCwgYXBwbGljYXRpb25zLCBldGMuLCB0aHJvdWdoIGNhY2hpbmcs IOKAnGVkZ2XigJ0gY29tcHV0aW5nLCBhbmQgb3RoZXIgdGVjaG5vbG9naWVzLiBUaGlua2luZyBh cyBhIG5ldHdvcmsgZW5naW5lZXIgYWJvdXQgcnVubmluZyBhcHBsaWNhdGlvbnMgaW4gdmFyaW91 cyBjbG91ZCBwcm92aWRlcnMsDQogSSBjYW4gc2VlIHRoZSB2YWx1ZSB0aGF0IGNvdWxkIGJlIG9i dGFpbmVkIGJ5IHRoZXNlIGNvbm5lY3Rpb25zLiBBbmQgc29tZSBvZiB0aGVzZSBwcm92aWRlcnMg YXJlIHR5cGljYWxseSBwcm9tb3RpbmcgdGhlc2Ugc2VydmljZXMgYXMgcHJvdmlkaW5nIGEgbG93 LWxhdGVuY3kgYWx0ZXJuYXRpdmUgdG8gc2VuZGluZyB0cmFmZmljIGFjcm9zcyB0aGUgcHVibGlj IEludGVybmV0LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+R29pbmcg YmFjayB0byB0aGUgZHJhZnQgY2hhcnRlciB0ZXh0ICgmbmJzcDs8YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vaW50YXJjaGJvYXJkL3Jlc2lsaWVuY2UvIiBjbGFzcz0iIj5odHRwczovL2dpdGh1 Yi5jb20vaW50YXJjaGJvYXJkL3Jlc2lsaWVuY2UvPC9hPiZuYnNwOykgLCBJIG5vdGUgdGhpczo8 L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDtPbmUgZnVu ZGFtZW50YWwgcGF0dGVybiBjb250cmlidXRpbmcgdG8gSW50ZXJuZXQgcmVzaWxpZW5jZSBpcyBk aXZlcnNpdHk6IGZvciBleGFtcGxlLCBkaXZlcnNpdHkgb2YgcGh5c2ljYWwgbGlua3MsIG9mIHBl ZXIgbmV0d29ya3MsIG9mIHBhdGhzIHRocm91Z2ggdGhlIG5ldHdvcmsuIExhY2sgb2YgZGl2ZXJz aXR5IGlzIGEga2V5IGNoYWxsZW5nZSBmb3IgSW50ZXJuZXQgcmVzaWxpZW5jZS4NCjwvZGl2Pg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+V2hhdCBpZiB0aGVyZSB3aW5kcyB1cCBi ZWluZyBhIGxhY2sgb2YgZGl2ZXJzaXR5IG9mIHBhdGhzIHRocm91Z2ggdGhlIOKAnG9wZW7igJ0g YW5kIOKAnHB1YmxpY+KAnSBJbnRlcm5ldD8gV2hhdCBpZiBpbmNyZWFzaW5nbHkgdHJhZmZpYyB3 aW5kcyB1cCB0cmF2ZWxpbmcgdGhyb3VnaCB0aGVzZSBwcm9wcmlldGFyeSBnbG9iYWwgbmV0d29y a3MgKHRvIHdoaWNoIHlvdSBuZWVkIHRvIHBheSB0byBjb25uZWN0IGFuZCB0aHJvdWdoIHRoYXQg Z2FpbiBwZXJtaXNzaW9uDQogdG8gc2VuZCB0cmFmZmljIC0gYW5kIG9ubHkgdG8gdGhhdCBjb21w YW554oCZcyBwbGF0Zm9ybXMpPzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2PkdpdmVuIHRoYXQgdGhlIEludGVybmV0IGhhcyBhbHdheXMgYmVlbiBhIOKAnG5l dHdvcmsgb2YgbmV0d29ya3PigJ0sIHRoZXJlIGhhdmUgYmVlbiAoYW5kIHN0aWxsIGFyZSkgbXVs dGlwbGUgbGFyZ2UsIGdsb2JhbCBuZXR3b3JrcyB0byB3aGljaCB5b3UgY291bGQgY29ubmVjdCB5 b3VyIG5ldHdvcmsgYW5kIGRhdGEgY2VudGVycy4gWW91IG1heSwgaW4gZmFjdCwgY29ubmVjdCB0 byBtdWx0aXBsZSBvZiB0aG9zZSBsYXJnZSwgZ2xvYmFsIElTUHMNCiB0byBoYXZlIGEgaGlnaGVy IGRlZ3JlZSBvZiDigJxyZXNpbGllbmNl4oCdIGZvciB5b3VyIG5ldHdvcmsuIFRoZSBkaWZmZXJl bmNlIHRvIG1lIGlzIHRoYXQgaW4gY29ubmVjdGluZyB0byB0aG9zZSBuZXR3b3JrIHByb3ZpZGVy cyAoYW5kIHBheWluZyB0byBkbyBzbyksIHlvdSBhcmUgY29ubmVjdGluZyB0byB0aGUgb3Blbiwg cHVibGljIEludGVybmV0LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+SW4gY29udHJhc3QsIGNvbm5lY3RpbmcgdG8gdGhlc2UgbmV3ZXIgcHJpdmF0ZSBuZXR3 b3JrcyBnaXZlcyB5b3Ugb25seSBhY2Nlc3MgdG8gdGhlIGNvbXBhbnnigJlzIGNsb3VkIG9yIGNv bnRlbnQgcGxhdGZvcm0uIEl04oCZcyBub3QgdGhlIHdob2xlIEludGVybmV0LjwvZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+U28gcmVnYXJkaW5nIGRlZmluaXRpb24gIzIs IGhvdyBkb2VzIHRoaXMgZXZvbHV0aW9uIGluIG5ldHdvcmsgY29ubmVjdGl2aXR5IGltcGFjdCB0 aGUgb3ZlcmFsbCByZXNpbGllbmNlIG9mIHRoZSBJbnRlcm5ldCB0byByZWNvdmVyIGZyb20gaXNz dWVzPzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SSB0aGluayBpdOKA mXMgYSB2ZXJ5IGludGVyZXN0aW5nIHF1ZXN0aW9uIHRvIGNvbnNpZGVyIGFzIHBhcnQgb2YgdGhp cyBwcm9ncmFtLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+TXkgMiBj ZW50cywmbmJzcDs8L2Rpdj4NCjxkaXY+RGFuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj5QLlMuIEFuZCB5ZXMsIEnigJltIHdlbGwgYXdhcmUgdGhhdCBzb21lIGxhcmdl IGVudGVycHJpc2VzIGFsc28gb3BlcmF0ZSB0aGVpciBvd24gcHJpdmF0ZSwgZ2xvYmFsIG5ldHdv cmtzIC8gV0FOcyB0byBpbnRlcmNvbm5lY3QgdGhlaXIgb3duIGRhdGEgY2VudGVycyAtIGFuZCBo YXZlIGRvbmUgc28gZm9yIG1hbnkgeWVhcnMuIEkgdGhpbmsgdGhlIGRpZmZlcmVuY2UgaXMgb25l IG9mIHNjYWxlLiBUaGUgbmV3IOKAnGNsb3Vk4oCdIHByb3ZpZGVycw0KIGFyZSBvcGVyYXRpbmcg bmV0d29ya3Mgc2lnbmlmaWNhbnRseSBsYXJnZXIgdGhhbiBhbnkgaW5kaXZpZHVhbCBlbnRlcnBy aXNlIC0gYW5kIGFyZSBhbHNvIGVuY291cmFnaW5nIGVudGVycHJpc2VzIHRvIG1vdmUgYXdheSBm cm9tIG9wZXJhdGluZyB0aGVpciBvd24gbmV0d29ya3MgYW5kIHRvIGluc3RlYWQgbW92ZSB0aGVp ciBuZXR3b3JraW5nIHRvIHRoZXNlIG5ld2VyIG5ldHdvcmtzLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_7020A5C76D064D6B85DD3FCE9CFC03C7isocorg_-- From nobody Wed Jan 1 11:12:29 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EFF1200D7 for ; Wed, 1 Jan 2020 11:12:28 -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_HELO_NONE=0.001, 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 1sQ7IiujpGH0 for ; Wed, 1 Jan 2020 11:12:25 -0800 (PST) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 3CC63120099 for ; Wed, 1 Jan 2020 11:12:25 -0800 (PST) Received: by mail-pg1-x543.google.com with SMTP id r11so20916796pgf.1 for ; Wed, 01 Jan 2020 11:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pR9Ustxt5AOoczKn4Ncf6qibu/RojCVAK0LsHNqcYfg=; b=TDiZtM8NPpv6RtPKtCI3shZ3zoKKrLJVHM+urfcuxf6djBVsyqjnAOlYXJiVD5iA2t HkhgGdIp/1NdALl2gbxMJ4tiwHfiO0pFmK8Lezvf+cWT4VGcN8W/LrJLbI5qOzv+VOMX KJNpIiQ0/uFZO9GAlu+NJZrkqfytgRJBWctqroapKNmepQjHDYu1GbxPkscCYUKHEWWC SnFyXNZ/KXkQuDYsUIICkdpjjmrjpoVGK7a7IRtQwdxHPil6kzpgbX8vZx+lr+GGF4G/ aI5ZlaL4t7XfTd+AGVV8L5GaNbxcUnAFQg1+2jnoCkX6Us7MI2j0BevEBe4EwIweCRE3 JrTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pR9Ustxt5AOoczKn4Ncf6qibu/RojCVAK0LsHNqcYfg=; b=ek9yW0ow0VTCFvKKpg+Nn6LjVXKPDB3M6Bb8wdVDyqfvXdsZ63+v0wJPeTQv2mARsV 3BQiH0t6fYiujGdo6kptK9bVi67rSKccYH5klRx5DFTtrsFXTIZaVzjUW+LKty4xTSND gRxhFh4Wy36ksJwPEuE/Ai73e3C8kbHSY6dumVYjEoR7GRCa6rL/+KWqCOVUQKjej0iF ncGmo4ZD4DNhv1nUlzMPkNA2G97aquRJCnSGKMukoMeNucz+JVpQO/0mHyY8C2JqpAHY KNm9JW1ixg09QabkuHTG/uqpKZPubXhJ0zG0UZzNi2H0tKePHJu49FcLJJvk4j5nFA+4 IBdw== X-Gm-Message-State: APjAAAVSszO8YlRHpjgWu+6+6jw60q3VaW1e2wS8ZkcG0FSPcFTpRF30 W/B9l+SGGWZCjGt/bL+vEvF2MQYQ X-Google-Smtp-Source: APXvYqxisOAWT5Bgfvjgc1YuHhyu7wn0W+cRN/xNHaK4jVFG1O27G9IdJMYsi7OfyYFAeqX9/WZQ5g== X-Received: by 2002:aa7:8193:: with SMTP id g19mr85429848pfi.172.1577905944267; Wed, 01 Jan 2020 11:12:24 -0800 (PST) Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id y14sm41468015pfe.147.2020.01.01.11.12.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jan 2020 11:12:23 -0800 (PST) To: Dan York , Lucy Lynch Cc: "architecture-discuss@iab.org" References: <7020A5C7-6D06-4D6B-85DD-3FCE9CFC03C7@isoc.org> From: Brian E Carpenter Message-ID: <818e8334-ac5c-76b4-c716-4f8af7229873@gmail.com> Date: Thu, 2 Jan 2020 08:12:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <7020A5C7-6D06-4D6B-85DD-3FCE9CFC03C7@isoc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2020 19:12:28 -0000 Hi Dan, Cherry-picking from your interesing message: > What if there winds up being a lack of diversity of paths through the =E2= =80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if increa= singly traffic winds up traveling through these proprietary global networ= ks (to which you need to pay to connect and through that gain permission = to send traffic - and only to that company=E2=80=99s platforms)? Is this really new, from a technical viewpoint? It reminds me very much o= f the early 1990s, when policy based BGP4 routing first became a thing, a= nd acceptable use policies were applied by NSFNET, ESNET, and their equiv= alents in Europe and Asia. That was all about money, of course, except th= at it was public money. Regards Brian On 02-Jan-20 07:44, Dan York wrote: > Stephen, >=20 > Lucy very nicely captured a concern I=E2=80=99d had=E2=80=A6 upon which= I expanded a bit below.. >=20 >> On Dec 31, 2019, at 2:27 PM, Lucy Lynch > wrote: >> >> On Fri, 20 Dec 2019, Stephen Farrell wrote: >> >>> >>> [1] https://github.com/intarchboard/resilience/ >>> >> >> Circling back to the top here. >> >> I think this is a fine topic for an IAB program and I took the >> draft charter to encompass resilience as both a technical and a >> design problem. >=20 > I also agree that this seems to be a great topic for an IAB program. >=20 >> I am particularly interested in this statement: >> ---- >> Definition of resilience: >> >> 1] =C2=A0the capability of a strained body to recover its size and sha= pe >> =C2=A0=C2=A0=C2=A0after deformation caused especially by compressive s= tress >> 2] =C2=A0an ability to recover from or adjust easily to misfortune or = change >> >> This program is mostly interested in definition #2. >> ---- >> I actually have my own concerns related to #1 as well and would hope t= hat this program might consider the warping of the overall Internet model= to accommodate currents trends or business practices. >> >> As an example - an Internet optimized for the web may not be the same >> internet that supports real time data collection and shared computatio= n in the context of big science. How do we avoid closing out capabilities= as we optimize for others? Narrowing of choices looks like a path to a l= imited and more brittle model to me. >=20 > I agree with Lucy=E2=80=99s example=E2=80=A6 and would also note that o= ther sources of =E2=80=9Ccompressive stress=E2=80=9D could be the increas= ing movement of most all real-time communication via voice and video to b= e over the Internet, and most recently the very large movement of streami= ng online gaming, which has very different characteristics and stress fac= tors (as noted in recent discussions in the new MOPS working group and th= e BOF before it). >=20 > I like Lucy=E2=80=99s phrase "the warping of the overall Internet model= to accommodate current trends or business practices,=E2=80=9D particular= ly when some of those current business practices may involve connecting n= etworks not only to the public Internet, but also to private, proprietary= , globe-spanning networks.=C2=A0 >=20 > For example, at Amazon=E2=80=99s recent re:Invent conference they promo= ted a way to directly connect enterprise data centers to Amazon=E2=80=99s= global AWS network (=E2=80=9COutposts=E2=80=9D) and also a way to connec= t telco points-of-presence to Amazon=E2=80=99s network (=E2=80=9CWaveleng= th=E2=80=9D). My understanding is that Microsoft has similar functionalit= y for Azure (=E2=80=9CStack=E2=80=9D, I believe) and Google either has or= is working on something similar for their Google Cloud Platform. Similar= ly, large entities such as Facebook and Netflix have built their own glob= al, private networks that interconnect to local data centers (where those= data centers are also connected to the public Internet). >=20 > All of these separate, private, global networks are designed to help sp= eed access to content, applications, etc., through caching, =E2=80=9Cedge= =E2=80=9D computing, and other technologies. Thinking as a network engine= er about running applications in various cloud providers, I can see the v= alue that could be obtained by these connections. And some of these provi= ders are typically promoting these services as providing a low-latency al= ternative to sending traffic across the public Internet. >=20 > Going back to the draft charter text (=C2=A0https://github.com/intarchb= oard/resilience/=C2=A0) , I note this: >=20 >>=C2=A0One fundamental pattern contributing to Internet resilience is di= versity: for example, diversity of physical links, of peer networks, of p= aths through the network. Lack of diversity is a key challenge for Intern= et resilience. >=20 > What if there winds up being a lack of diversity of paths through the =E2= =80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if increa= singly traffic winds up traveling through these proprietary global networ= ks (to which you need to pay to connect and through that gain permission = to send traffic - and only to that company=E2=80=99s platforms)? >=20 > Given that the Internet has always been a =E2=80=9Cnetwork of networks=E2= =80=9D, there have been (and still are) multiple large, global networks t= o which you could connect your network and data centers. You may, in fact= , connect to multiple of those large, global ISPs to have a higher degree= of =E2=80=9Cresilience=E2=80=9D for your network. The difference to me i= s that in connecting to those network providers (and paying to do so), yo= u are connecting to the open, public Internet.=C2=A0 >=20 > In contrast, connecting to these newer private networks gives you only = access to the company=E2=80=99s cloud or content platform. It=E2=80=99s n= ot the whole Internet. >=20 > So regarding definition #2, how does this evolution in network connecti= vity impact the overall resilience of the Internet to recover from issues= ? >=20 > I think it=E2=80=99s a very interesting question to consider as part of= this program. >=20 > My 2 cents,=C2=A0 > Dan >=20 > P.S. And yes, I=E2=80=99m well aware that some large enterprises also o= perate their own private, global networks / WANs to interconnect their ow= n data centers - and have done so for many years. I think the difference = is one of scale. The new =E2=80=9Ccloud=E2=80=9D providers are operating = networks significantly larger than any individual enterprise - and are al= so encouraging enterprises to move away from operating their own networks= and to instead move their networking to these newer networks. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Wed Jan 1 12:11:41 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDB81200A1 for ; Wed, 1 Jan 2020 12:11:40 -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, 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 (1024-bit key) header.d=isoc.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfCCnPDetaWK for ; Wed, 1 Jan 2020 12:11:37 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2089.outbound.protection.outlook.com [40.107.243.89]) (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 BF667120096 for ; Wed, 1 Jan 2020 12:11:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IZzQ330D6ccPl7Y6j1UdMZi1IXHlONWUX3553U4kq8Xzm73ED4Ec0klYrw4vG6jpOIHOpWdOZRJpwnaV9cfM/H8e2PWEofRwA7YBtG+NRhwymCokfLyNol9YKntS91iWR7v403ALCQe9Azz04d9TQ+BS2kbq3jTg6Sf3iZ3fnqvEgI/dlgOoOBtH8b0sqPjes/q25P04GcvWUBtp+++Y6ra8UIW92j375ZzMCuI7qnYdW7MnYSeNNLzdjGQeKKA+yzoOS2lhwfN4Z1uudS8/7kc/wB8JXqYKaCBAnk/xJbvZyYK3J0r9weaJQZiHhKfWylB7i2MCzn4Dmljpi4EJEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=faiNQ/XashnDNyxG2D2jfR+GmS+Mm7qBf7B8VIO5sH0=; b=mcUtQ+OtvDZcJdH4AClasOKJgk0gmQRgfU9Qj7N/jw0wArggUbDp4x07PQDIR1FvYPetKo6/PdWRQdaqwn+Gt9UyYdQR1v53sTd5RvlfORMkWYespf05XNo0AuaxelatQyfWfSdl9WuqFtcu029EWZxcj/1dWSnN15HK7B+nFhbFOCCiHNDHoCDD/qW3NQ/c/VWB4v9dtwfcAnDqE+p4Gi6xaVsZzXmd0Rf+EOvza9iEfYe7mNBQ0155m0rJo0KUrfP01ztCanVSbab5kS3A/3fTTWGTAAQYBLB4Vb3sqX0CV6G+wPH2o6HQC14nh7mIy9KuyZ0ZxZ8tMXY8yIKXXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=faiNQ/XashnDNyxG2D2jfR+GmS+Mm7qBf7B8VIO5sH0=; b=3sD5NV0GD0fykO4M7MP3mxqMQcCsnzXTvilWmsa6b7hAKc4BT+JXhwmXRjIeR7jrG2WGZZiuWf2FtylYIi82QoPclb9rsZn/aodKYWepFPezUSbuKlqt0E1qtZUteWqmz1MZvnldvRBcpx1Pw6rbxK2oJ2AUm1svuVS3S2hiIak= Received: from DM5PR06MB2649.namprd06.prod.outlook.com (10.168.199.143) by DM5PR06MB2489.namprd06.prod.outlook.com (10.168.179.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.12; Wed, 1 Jan 2020 20:11:33 +0000 Received: from DM5PR06MB2649.namprd06.prod.outlook.com ([fe80::2c2d:4ecc:c8f0:115d]) by DM5PR06MB2649.namprd06.prod.outlook.com ([fe80::2c2d:4ecc:c8f0:115d%5]) with mapi id 15.20.2602.010; Wed, 1 Jan 2020 20:11:33 +0000 From: Dan York To: Brian E Carpenter CC: Lucy Lynch , "architecture-discuss@iab.org" Thread-Topic: [arch-d] possible new IAB programme on Internet resilience Thread-Index: AQHVtzoIc/E2h2BESU61KFOCTP34h6fUsiuAgAGGVQCAAAfSgIAAEIsA Date: Wed, 1 Jan 2020 20:11:33 +0000 Message-ID: References: <7020A5C7-6D06-4D6B-85DD-3FCE9CFC03C7@isoc.org> <818e8334-ac5c-76b4-c716-4f8af7229873@gmail.com> In-Reply-To: <818e8334-ac5c-76b4-c716-4f8af7229873@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org; x-originating-ip: [2601:198:4100:84b0:413e:b645:50a0:2e94] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6683c496-35f0-457c-fa42-08d78ef6cc52 x-ms-traffictypediagnostic: DM5PR06MB2489: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400004)(396003)(376002)(346002)(366004)(136003)(199004)(189003)(76116006)(5660300002)(508600001)(54906003)(66556008)(64756008)(66476007)(66446008)(66946007)(316002)(6916009)(91956017)(2906002)(66574012)(36756003)(81156014)(8676002)(8936002)(2616005)(86362001)(53546011)(186003)(6486002)(33656002)(6512007)(6506007)(4326008)(71200400001)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR06MB2489; H:DM5PR06MB2649.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wGnWeoRDi/lV0LiocFJh1jXrcTjMWEjQ49Cx/nzpci12fOXBjiw7HHHuJQeLuPluDK3tEU8zY8DnNeosTphlKuPis4SpCfLaXL3X4Wh+LMs2axjByqD1G2KRhKwGhPE/BLw9+Z7elNS72g8H34Eut15yzNGp8Hqq2yHt4A29Y6f1Cs39wOF889/5xjOJkE/waapHK69JYYjfVdDsIYn9TAMakNv+yFzs6ZGARG/2u22wZ5spYaDrLQDqK9fj31W6qVutXqbdIBFPawH51nuf29BnaLAYFI/R9TX9yQLWqvwZwueD2+/fDuztEaTQsGE9k8Oq5IxsO5N1OQ//GDeZl752mkQ53buEZef7gVN+0ttWrtH4QxH5fn96mwhs2dZEZA9Ous8yJJLPrZJMu7ZneRXawJPQRXkrAv0IPceRq7YhS8VUU6krESJ73tirN9gO x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_A26379AEE3EF472A8927CE55CF417FEBisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 6683c496-35f0-457c-fa42-08d78ef6cc52 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jan 2020 20:11:33.2215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GBHXwWEzxmec72miiBcOOG+EWbdnMaDCmO1ATgyoOs/RQIU9Bo/WLQ6cc2rDQzsG X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2489 Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2020 20:11:40 -0000 --_000_A26379AEE3EF472A8927CE55CF417FEBisocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJpYW4sDQoNCk9uIEphbiAxLCAyMDIwLCBhdCAyOjEyIFBNLCBCcmlhbiBFIENhcnBlbnRlciA8 YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPG1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFp bC5jb20+PiB3cm90ZToNCg0KQ2hlcnJ5LXBpY2tpbmcgZnJvbSB5b3VyIGludGVyZXNpbmcgbWVz c2FnZToNCg0KV2hhdCBpZiB0aGVyZSB3aW5kcyB1cCBiZWluZyBhIGxhY2sgb2YgZGl2ZXJzaXR5 IG9mIHBhdGhzIHRocm91Z2ggdGhlIOKAnG9wZW7igJ0gYW5kIOKAnHB1YmxpY+KAnSBJbnRlcm5l dD8gV2hhdCBpZiBpbmNyZWFzaW5nbHkgdHJhZmZpYyB3aW5kcyB1cCB0cmF2ZWxpbmcgdGhyb3Vn aCB0aGVzZSBwcm9wcmlldGFyeSBnbG9iYWwgbmV0d29ya3MgKHRvIHdoaWNoIHlvdSBuZWVkIHRv IHBheSB0byBjb25uZWN0IGFuZCB0aHJvdWdoIHRoYXQgZ2FpbiBwZXJtaXNzaW9uIHRvIHNlbmQg dHJhZmZpYyAtIGFuZCBvbmx5IHRvIHRoYXQgY29tcGFueeKAmXMgcGxhdGZvcm1zKT8NCg0KSXMg dGhpcyByZWFsbHkgbmV3LCBmcm9tIGEgdGVjaG5pY2FsIHZpZXdwb2ludD8NCg0KSeKAmW0gbm90 IHN1cmUuIEkgaGF2ZW7igJl0IHlldCB3b3JrZWQgZW5vdWdoIHBlcnNvbmFsbHkgd2l0aCB0aGVz ZSBuZXdlciBuZXR3b3JrcyB0byBiZSBhYmxlIHRvIGZ1bGx5IGFuc3dlciB0aGF0IHF1ZXN0aW9u LiAgTXkga25vd2xlZGdlIGNvbWVzIGZyb20gcmVhZGluZyBhcnRpY2xlcywgZ29pbmcgdGhyb3Vn aCB0dXRvcmlhbHMsIGxpc3RlbmluZyB0byB0YWxrcyAvIHBvZGNhc3RzLCBhbmQgZXhwZXJpbWVu dGluZyB0byB0aGUgZGVncmVlIEkgY2FuLiBCdXQgSSBkb27igJl0IG9wZXJhdGUgYSBuZXR3b3Jr IG9yIGRhdGEgY2VudGVyIHdoZXJlIEkgY291bGQgam9pbiBpbiB0byBvbmUgKG9yIG1vcmUpIG9m IHRoZW3igKYgc28gSSBoYXZlIHRvIGRlZmVyIHRvIHRob3NlIHdobyBoYXZlIHRoYXQga2luZCBv ZiBtb3JlIGRpcmVjdCBleHBlcmllbmNlLg0KDQpJdCByZW1pbmRzIG1lIHZlcnkgbXVjaCBvZiB0 aGUgZWFybHkgMTk5MHMsIHdoZW4gcG9saWN5IGJhc2VkIEJHUDQgcm91dGluZyBmaXJzdCBiZWNh bWUgYSB0aGluZywgYW5kIGFjY2VwdGFibGUgdXNlIHBvbGljaWVzIHdlcmUgYXBwbGllZCBieSBO U0ZORVQsIEVTTkVULCBhbmQgdGhlaXIgZXF1aXZhbGVudHMgaW4gRXVyb3BlIGFuZCBBc2lhLiBU aGF0IHdhcyBhbGwgYWJvdXQgbW9uZXksIG9mIGNvdXJzZSwgZXhjZXB0IHRoYXQgaXQgd2FzIHB1 YmxpYyBtb25leS4NCg0KSW50ZXJlc3RpbmcgdGhvdWdodC4gSSBndWVzcyB0aGUgZGlmZmVyZW5j ZSBJIGNvdWxkIHNlZSB3YXMgdGhhdCBpbiB0aG9zZSBkYXlzIHRoZSBuZXR3b3JrcyB3ZXJlIGFs bCB1c2luZyB0aGUgc2FtZSBvcGVuIHN0YW5kYXJkcy1iYXNlZCBwcm90b2NvbHMsIGV2ZW4gd2l0 aCBBVVDigJlzIGJlaW5nIGFwcGxpZWQuIFRoZXkgd2VyZSBhbGwgd2VhdmluZyB0b2dldGhlciBh IGNvbW1vbiBuZXR3b3JrIGZhYnJpYywgZnJvbSB3aGF0IEkgc2F3IGFzIGEgbmV0d29yayB1c2Vy IGF0IHRoYXQgdGltZS4NCg0KV2l0aCB0aGVzZSBuZXdlciBwcml2YXRlIG5ldHdvcmtzLCB0aGV5 IG1heSAtIG9yIG1heSBub3QgLSBiZSB1c2luZyB0aGUgc2FtZSBwcm90b2NvbHMgdGhhdCB0aGUg cHVibGljIEludGVybmV0IGlzIHVzaW5nLiBZb3UgbWF5IG9yIG1heSBub3Qga25vdy4gKEFuZCBm cm9tIGEgcHVyZWx5IG9wZXJhdGlvbmFsIHBvaW50LW9mLXZpZXcsIHlvdSBtYXkgbm90IGNhcmXi gKYgYSBtYWluIHJlYXNvbiBmb3IgdXNpbmcgdGhlIHByaXZhdGUgbmV0d29yayBpcyB0byBoYXZl IGxvdy1sYXRlbmN5IGNvbm5lY3Rpdml0eSB0byBhcHBsaWNhdGlvbnMgb3IgY29udGVudC4pDQoN CkluIGF0IGxlYXN0IG9uZSBvZiB0aGUgY2FzZXMgKEFtYXpvbiBPdXRwb3N0cyksIG15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCB0aGUgY29tcGFueSBjb21lcyBhbmQgaW5zdGFsbHMgaGFyZHdhcmUg aW4geW91ciBkYXRhIGNlbnRlciB0aGF0IHRoZW4gY29ubmVjdHMgeW91ciBuZXR3b3JrIGJhY2sg dG8gQW1hem9u4oCZcyBBV1MgbmV0d29yay4gSXMgaXQgYWxsIHJ1bm5pbmcgb3BlbiBJbnRlcm5l dCBwcm90b2NvbHM/IE9yIGFyZSB0aGVyZSBwcm9wcmlldGFyeSBwcm90b2NvbHMgKG9yIOKAnGV4 dGVuc2lvbnPigJ0pIHRoYXQgYXJlIG1ha2luZyB0aGUgY29ubmVjdGl2aXR5IHRoYXQgbXVjaCBm YXN0ZXIvYmV0dGVyPyAgKEFuZCBJIGhvbmVzdGx5IGRvIG5vdCBrbm93LikgIERvIHlvdSBvbmx5 IGhhdmUgY29ubmVjdGl2aXR5IHRvIHRoZWlyIHBsYXRmb3JtKHMpPyBPciBkbyB5b3UgaGF2ZSB3 aWRlciBjb25uZWN0aXZpdHk/DQoNClRvIG1lLCB0aGlzIGlzIHBhcnQgb2YgdGhlIHF1ZXN0aW9u IC0gZG8gdGhlc2UgbmV3ZXIsIGdsb2JhbCwgcHJpdmF0ZSBuZXR3b3JrcyAqaW5jcmVhc2UqIHRo ZSBvdmVyYWxsIHJlc2lsaWVuY2Ugb2YgdGhlIG9wZW4sIHB1YmxpYyBJbnRlcm5ldD8gT3IgZG8g dGhleSAqZGVjcmVhc2UqIHRoZSBvdmVyYWxsIHJlc2lsaWVuY2Ugb2YgdGhlIG9wZW4sIHB1Ymxp YyBJbnRlcm5ldD8gT3IgZG8gdGhleSBub3QgcmVhbGx5IGhhdmUgYW55IGVmZmVjdD8gT3IgaXMg aXQgdG9vIHNvb24gdG8gdGVsbD8NCg0KSW50ZXJlc3RpbmcgdGltZXMsDQpEYW4NCg0KDQo= --_000_A26379AEE3EF472A8927CE55CF417FEBisocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <1DA9DFC3D18D694AA70F2CE2054AFCA1@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkJyaWFuLA0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPk9uIEphbiAxLCAyMDIwLCBhdCAyOjEyIFBNLCBCcmlhbiBFIENhcnBlbnRlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSIgY2xhc3M9IiI+YnJp YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlz cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5DaGVycnktcGlja2luZw0KIGZyb20g eW91ciBpbnRlcmVzaW5nIG1lc3NhZ2U6PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0 bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IiBjbGFzcz0iIj4NCldoYXQgaWYgdGhlcmUgd2luZHMgdXAgYmVpbmcgYSBsYWNrIG9mIGRpdmVy c2l0eSBvZiBwYXRocyB0aHJvdWdoIHRoZSDigJxvcGVu4oCdIGFuZCDigJxwdWJsaWPigJ0gSW50 ZXJuZXQ/IFdoYXQgaWYgaW5jcmVhc2luZ2x5IHRyYWZmaWMgd2luZHMgdXAgdHJhdmVsaW5nIHRo cm91Z2ggdGhlc2UgcHJvcHJpZXRhcnkgZ2xvYmFsIG5ldHdvcmtzICh0byB3aGljaCB5b3UgbmVl ZCB0byBwYXkgdG8gY29ubmVjdCBhbmQgdGhyb3VnaCB0aGF0IGdhaW4gcGVybWlzc2lvbg0KIHRv IHNlbmQgdHJhZmZpYyAtIGFuZCBvbmx5IHRvIHRoYXQgY29tcGFueeKAmXMgcGxhdGZvcm1zKT88 YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9 IiI+SXMNCiB0aGlzIHJlYWxseSBuZXcsIGZyb20gYSB0ZWNobmljYWwgdmlld3BvaW50PyA8L3Nw YW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj5J4oCZbSBub3Qgc3VyZS4gSSBoYXZlbuKAmXQgeWV0IHdvcmtlZCBlbm91Z2ggcGVyc29uYWxs eSB3aXRoIHRoZXNlIG5ld2VyIG5ldHdvcmtzIHRvIGJlIGFibGUgdG8gZnVsbHkgYW5zd2VyIHRo YXQgcXVlc3Rpb24uICZuYnNwO015IGtub3dsZWRnZSBjb21lcyBmcm9tIHJlYWRpbmcgYXJ0aWNs ZXMsIGdvaW5nIHRocm91Z2ggdHV0b3JpYWxzLCBsaXN0ZW5pbmcgdG8gdGFsa3MgLyBwb2RjYXN0 cywgYW5kIGV4cGVyaW1lbnRpbmcgdG8gdGhlIGRlZ3JlZQ0KIEkgY2FuLiBCdXQgSSBkb27igJl0 IG9wZXJhdGUgYSBuZXR3b3JrIG9yIGRhdGEgY2VudGVyIHdoZXJlIEkgY291bGQgam9pbiBpbiB0 byBvbmUgKG9yIG1vcmUpIG9mIHRoZW3igKYgc28gSSBoYXZlIHRvIGRlZmVyIHRvIHRob3NlIHdo byBoYXZlIHRoYXQga2luZCBvZiBtb3JlIGRpcmVjdCBleHBlcmllbmNlLjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkl0DQogcmVtaW5kcyBtZSB2ZXJ5 IG11Y2ggb2YgdGhlIGVhcmx5IDE5OTBzLCB3aGVuIHBvbGljeSBiYXNlZCBCR1A0IHJvdXRpbmcg Zmlyc3QgYmVjYW1lIGEgdGhpbmcsIGFuZCBhY2NlcHRhYmxlIHVzZSBwb2xpY2llcyB3ZXJlIGFw cGxpZWQgYnkgTlNGTkVULCBFU05FVCwgYW5kIHRoZWlyIGVxdWl2YWxlbnRzIGluIEV1cm9wZSBh bmQgQXNpYS4gVGhhdCB3YXMgYWxsIGFib3V0IG1vbmV5LCBvZiBjb3Vyc2UsIGV4Y2VwdCB0aGF0 IGl0IHdhcyBwdWJsaWMNCiBtb25leS48L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW50ZXJlc3RpbmcgdGhvdWdodC4g SSBndWVzcyB0aGUgZGlmZmVyZW5jZSBJIGNvdWxkIHNlZSB3YXMgdGhhdCBpbiB0aG9zZSBkYXlz IHRoZSBuZXR3b3JrcyB3ZXJlIGFsbCB1c2luZyB0aGUgc2FtZSBvcGVuIHN0YW5kYXJkcy1iYXNl ZCBwcm90b2NvbHMsIGV2ZW4gd2l0aCBBVVDigJlzIGJlaW5nIGFwcGxpZWQuIFRoZXkgd2VyZSBh bGwgd2VhdmluZyB0b2dldGhlciBhIGNvbW1vbiBuZXR3b3JrIGZhYnJpYywgZnJvbSB3aGF0DQog SSBzYXcgYXMgYSBuZXR3b3JrIHVzZXIgYXQgdGhhdCB0aW1lLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2l0aCB0aGVzZSBuZXdlciBw cml2YXRlIG5ldHdvcmtzLCB0aGV5IG1heSAtIG9yIG1heSBub3QgLSBiZSB1c2luZyB0aGUgc2Ft ZSBwcm90b2NvbHMgdGhhdCB0aGUgcHVibGljIEludGVybmV0IGlzIHVzaW5nLiBZb3UgbWF5IG9y IG1heSBub3Qga25vdy4gKEFuZCBmcm9tIGEgcHVyZWx5IG9wZXJhdGlvbmFsIHBvaW50LW9mLXZp ZXcsIHlvdSBtYXkgbm90IGNhcmXigKYgYSBtYWluIHJlYXNvbiBmb3IgdXNpbmcgdGhlIHByaXZh dGUNCiBuZXR3b3JrIGlzIHRvIGhhdmUgbG93LWxhdGVuY3kgY29ubmVjdGl2aXR5IHRvIGFwcGxp Y2F0aW9ucyBvciBjb250ZW50LikmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkluIGF0IGxlYXN0IG9uZSBvZiB0aGUgY2FzZXMg KEFtYXpvbiBPdXRwb3N0cyksIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgY29tcGFueSBj b21lcyBhbmQgaW5zdGFsbHMgaGFyZHdhcmUgaW4geW91ciBkYXRhIGNlbnRlciB0aGF0IHRoZW4g Y29ubmVjdHMgeW91ciBuZXR3b3JrIGJhY2sgdG8gQW1hem9u4oCZcyBBV1MgbmV0d29yay4gSXMg aXQgYWxsIHJ1bm5pbmcgb3BlbiBJbnRlcm5ldCBwcm90b2NvbHM/IE9yIGFyZQ0KIHRoZXJlIHBy b3ByaWV0YXJ5IHByb3RvY29scyAob3Ig4oCcZXh0ZW5zaW9uc+KAnSkgdGhhdCBhcmUgbWFraW5n IHRoZSBjb25uZWN0aXZpdHkgdGhhdCBtdWNoIGZhc3Rlci9iZXR0ZXI/ICZuYnNwOyhBbmQgSSBo b25lc3RseSBkbyBub3Qga25vdy4pICZuYnNwO0RvIHlvdSBvbmx5IGhhdmUgY29ubmVjdGl2aXR5 IHRvIHRoZWlyIHBsYXRmb3JtKHMpPyBPciBkbyB5b3UgaGF2ZSB3aWRlciBjb25uZWN0aXZpdHk/ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5UbyBtZSwgdGhpcyBpcyBwYXJ0IG9mIHRoZSBxdWVzdGlvbiAtIGRvIHRoZXNlIG5ld2VyLCBn bG9iYWwsIHByaXZhdGUgbmV0d29ya3MgKmluY3JlYXNlKiB0aGUgb3ZlcmFsbCByZXNpbGllbmNl IG9mIHRoZSBvcGVuLCBwdWJsaWMgSW50ZXJuZXQ/IE9yIGRvIHRoZXkgKmRlY3JlYXNlKiB0aGUg b3ZlcmFsbCByZXNpbGllbmNlIG9mIHRoZSBvcGVuLCBwdWJsaWMgSW50ZXJuZXQ/IE9yIGRvIHRo ZXkgbm90IHJlYWxseSBoYXZlDQogYW55IGVmZmVjdD8gT3IgaXMgaXQgdG9vIHNvb24gdG8gdGVs bD88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkludGVyZXN0aW5nIHRpbWVzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5EYW4mbmJzcDs8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A26379AEE3EF472A8927CE55CF417FEBisocorg_-- From nobody Wed Jan 1 12:48:20 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4718C120096 for ; Wed, 1 Jan 2020 12:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Vmolfl_O-vB5 for ; Wed, 1 Jan 2020 12:48:17 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E0812001A for ; Wed, 1 Jan 2020 12:48:17 -0800 (PST) Received: from [192.168.2.56] (96-64-23-78-static.hfc.comcastbusiness.net [96.64.23.78]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 34F155401C7; Wed, 1 Jan 2020 15:48:15 -0500 (EST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Jared Mauch In-Reply-To: <818e8334-ac5c-76b4-c716-4f8af7229873@gmail.com> Date: Wed, 1 Jan 2020 15:48:13 -0500 Cc: Dan York , Lucy Lynch , "architecture-discuss@iab.org" Message-Id: <82EDC199-A1DC-42AC-BB23-2A738F33A9F9@puck.nether.net> References: <818e8334-ac5c-76b4-c716-4f8af7229873@gmail.com> To: Brian E Carpenter X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2020 20:48:19 -0000 M > On Jan 1, 2020, at 2:12 PM, Brian E Carpenter wrote: >=20 > Hi Dan, >=20 > Cherry-picking from your interesing message: >=20 >> What if there winds up being a lack of diversity of paths through the =E2= =80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if increasin= gly traffic winds up traveling through these proprietary global networks (to= which you need to pay to connect and through that gain permission to send t= raffic - and only to that company=E2=80=99s platforms)? >=20 > Is this really new, from a technical viewpoint? It reminds me very much of= the early 1990s, when policy based BGP4 routing first became a thing, and a= cceptable use policies were applied by NSFNET, ESNET, and their equivalents i= n Europe and Asia. That was all about money, of course, except that it was p= ublic money. Many of us operate networks to meet our business goals. I think the issues t= hat arise from that become relevant if one or more players requires certain n= etworks or those one or two players are damaged or fail catastrophically.=20= (Operational note: as we have privatized our own traffic we have found the p= ublic carriers no longer have the capability and capacity to handle the traf= fic if we place it back on their networks). From nobody Wed Jan 1 13:49:03 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8891200EC for ; Wed, 1 Jan 2020 13:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.105 X-Spam-Level: X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=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 DO96V_TdneiB for ; Wed, 1 Jan 2020 13:49:00 -0800 (PST) Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E856120020 for ; Wed, 1 Jan 2020 13:49:00 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1imlrL-000GdB-Cn; Wed, 01 Jan 2020 16:48:55 -0500 Date: Wed, 01 Jan 2020 16:48:50 -0500 From: John C Klensin To: Brian E Carpenter , Dan York , Lucy Lynch cc: architecture-discuss@iab.org Message-ID: <75E5F3DE269AB6BEC3083567@JcK-HP5.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2020 21:49:02 -0000 Brian, Dan, and Lucy, I agree with Lucy's point and Dan's elaboration. Yes, it seems to me that some of the private cloud issues that Dan is talking about are a reversion to where we were in the 1990s, with a few large differences other than public and private money. One is that the public network, such as it was at the beginning of the 1990s, was, in many respects, a connectivity workaround to the AUP-restricted research and education networks Brian refers to. At this point, there is hugely more dependency on the existence of the so-called public Internet. And, to the extent that those proprietary clouds reduce the incentives to provide high-quality services available to the public at a reasonable price, resilience suffers as do several other things. Two other aspects of the situation Lucy and Dan point out concern me even more. One is that the design of the network for robustness in the light of disaster (natural, technological, or political) depends heavily on assumptions about diversity of paths and resources. Where once we had a great deal of low-bandwidth copper and relatively low-density fiber, diverse physical paths were easy to find for many transmissions. Now, as bandwidth of fiber has risen to levels most of us could not imagine in the 1980s, physical path diversity opportunities have decreased and the inherent robustness of "if a packet doesn't go one way, it can go another" has decreased with it. For, e.g., undersea cables, there may still be an increasing number of physical cables, but the number of landing points is not increasing as rapidly. There is another aspect of that change which is also connected to the growth of large clouds. Unless we are very careful, encrypting everything and organize things so that an individual's traffic gets lost in the crowd also decreases robustness and resiliency, perhaps not against attacks on privacy but against attacks on (or unplanned problems with) the ability to transmit and deliver packets and the data they carry. The third issue is one we are seeing, IMO, more and more at the applications layer. In the networks of the early 1990s, especially those not restricted by AUPs, most applications services were provided on a single system into which one logged in. Outside the research and education networks, network transmission, when it occurred at all, was a matter of gateways (some legal, some less so) among those essentially-proprietary systems. And many of those arrangements involved bilateral agreements among the proprietors. If standards were needed, the proprietary system operates made agreements among themselves, with anyone who wanted to interoperate with them at their mercy. As concentration increases among a relatively small number of operators or software providers, even if their systems are distributed across proprietary clouds rather than being all in one place, I wonder if we are seeing that again with de facto standards for web browsers being made by a handful of web browser producers, de facto standards for email being made by a handful or very large providers, etc, as examples. There may be advantages to such arrangements -- certainly they represent running code -- but they put robustness and resiliency almost entirely in the hands of those operators and vendors. I hope the IAB intends to address those issues. If it does not, I fear that the proposed programme will not be useful to the Internet. john --On Thursday, 02 January, 2020 08:12 +1300 Brian E Carpenter wrote: > Hi Dan, >=20 > Cherry-picking from your interesing message: >=20 >> What if there winds up being a lack of diversity of paths >> through the "open" and "public" Internet? What if >> increasingly traffic winds up traveling through these >> proprietary global networks (to which you need to pay to >> connect and through that gain permission to send traffic - >> and only to that company's platforms)? >=20 > Is this really new, from a technical viewpoint? It reminds me > very much of the early 1990s, when policy based BGP4 routing > first became a thing, and acceptable use policies were applied > by NSFNET, ESNET, and their equivalents in Europe and Asia. > That was all about money, of course, except that it was public > money. >=20 > Regards > Brian >=20 > On 02-Jan-20 07:44, Dan York wrote: >> Stephen, >>=20 >> Lucy very nicely captured a concern I'd had=E2=80=A6 upon = which I >> expanded a bit below.. >>=20 >>> On Dec 31, 2019, at 2:27 PM, Lucy Lynch >>> > >>> wrote: >>>=20 >>> On Fri, 20 Dec 2019, Stephen Farrell wrote: >>>=20 >>>>=20 >>>> [1] https://github.com/intarchboard/resilience/ >>>>=20 >>>=20 >>> Circling back to the top here. >>>=20 >>> I think this is a fine topic for an IAB program and I took >>> the draft charter to encompass resilience as both a >>> technical and a design problem. >>=20 >> I also agree that this seems to be a great topic for an IAB >> program. >>=20 >>> I am particularly interested in this statement: >>> ---- >>> Definition of resilience: >>>=20 >>> 1] =C2=A0the capability of a strained body to recover its = size >>> and shape =C2=A0=C2=A0=C2=A0after deformation caused = especially by >>> compressive stress 2] =C2=A0an ability to recover from or = adjust >>> easily to misfortune or change >>>=20 >>> This program is mostly interested in definition #2. >>> ---- >>> I actually have my own concerns related to #1 as well and >>> would hope that this program might consider the warping of >>> the overall Internet model to accommodate currents trends or >>> business practices. >>>=20 >>> As an example - an Internet optimized for the web may not be >>> the same internet that supports real time data collection >>> and shared computation in the context of big science. How do >>> we avoid closing out capabilities as we optimize for others? >>> Narrowing of choices looks like a path to a limited and more >>> brittle model to me. >>=20 >> I agree with Lucy's example=E2=80=A6 and would also note that >> other sources of "compressive stress" could be the >> increasing movement of most all real-time communication via >> voice and video to be over the Internet, and most recently >> the very large movement of streaming online gaming, which has >> very different characteristics and stress factors (as noted >> in recent discussions in the new MOPS working group and the >> BOF before it). >>=20 >> I like Lucy's phrase "the warping of the overall Internet >> model to accommodate current trends or business practices," >> particularly when some of those current business practices >> may involve connecting networks not only to the public >> Internet, but also to private, proprietary, globe-spanning >> networks.=C2=A0 >>=20 >> For example, at Amazon's recent re:Invent conference they >> promoted a way to directly connect enterprise data centers to >> Amazon's global AWS network ("Outposts") and also a way >> to connect telco points-of-presence to Amazon's network >> ("Wavelength"). My understanding is that Microsoft has >> similar functionality for Azure ("Stack", I believe) and >> Google either has or is working on something similar for >> their Google Cloud Platform. Similarly, large entities such >> as Facebook and Netflix have built their own global, private >> networks that interconnect to local data centers (where those >> data centers are also connected to the public Internet). >>=20 >> All of these separate, private, global networks are designed >> to help speed access to content, applications, etc., through >> caching, "edge" computing, and other technologies. >> Thinking as a network engineer about running applications in >> various cloud providers, I can see the value that could be >> obtained by these connections. And some of these providers >> are typically promoting these services as providing a >> low-latency alternative to sending traffic across the public >> Internet. >>=20 >> Going back to the draft charter text >> (=C2=A0https://github.com/intarchboard/resilience/=C2=A0) , I = note >> this: >>=20 >>> =C2=A0One fundamental pattern contributing to Internet >>> resilience is diversity: for example, diversity of physical >>> links, of peer networks, of paths through the network. Lack >>> of diversity is a key challenge for Internet resilience. >>=20 >> What if there winds up being a lack of diversity of paths >> through the "open" and "public" Internet? What if >> increasingly traffic winds up traveling through these >> proprietary global networks (to which you need to pay to >> connect and through that gain permission to send traffic - >> and only to that company's platforms)? >>=20 >> Given that the Internet has always been a "network of >> networks", there have been (and still are) multiple large, >> global networks to which you could connect your network and >> data centers. You may, in fact, connect to multiple of those >> large, global ISPs to have a higher degree of >> "resilience" for your network. The difference to me is >> that in connecting to those network providers (and paying to >> do so), you are connecting to the open, public = Internet.=C2=A0 >>=20 >> In contrast, connecting to these newer private networks gives >> you only access to the company's cloud or content platform. >> It's not the whole Internet. >>=20 >> So regarding definition #2, how does this evolution in >> network connectivity impact the overall resilience of the >> Internet to recover from issues? >>=20 >> I think it's a very interesting question to consider as >> part of this program. >>=20 >> My 2 cents,=C2=A0 >> Dan >>=20 >> P.S. And yes, I'm well aware that some large enterprises >> also operate their own private, global networks / WANs to >> interconnect their own data centers - and have done so for >> many years. I think the difference is one of scale. The new >> "cloud" providers are operating networks significantly >> larger than any individual enterprise - and are also >> encouraging enterprises to move away from operating their own >> networks and to instead move their networking to these newer >> networks. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >>=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Wed Jan 1 15:40:45 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2919512004C for ; Wed, 1 Jan 2020 15:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, 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 PPKhTvC0FklV for ; Wed, 1 Jan 2020 15:40:41 -0800 (PST) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 D8D0612000F for ; Wed, 1 Jan 2020 15:40:41 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id t101so2614337pjb.4 for ; Wed, 01 Jan 2020 15:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1OWaoCTzxKZIzea9KHsutKkxvhr4MmJCErg4gHGZoco=; b=RJxNJsgCmvyphMrhlRpiGyYeHcEicLurxZbRicC+nOSQPSbCHzOGpD9EFAo3alwGbR cfS6EQmniL/tlEmmyR0pVLFzLUfxaPQOBkCUqkTgYVxGUrrsd7Bntd2qFY/Ot7yBuHhZ fWh4K5vPrGEWFk5R78Obw9SqGS8Kd2dHzEorT2XRUkNXA682oiKGizLVCPqOwKCjeWeG idcYM15ofYZ0bH1FDlrUdAFDqR13RjGZE/tmAIIVTYKr4wPipdW9kne4hxU5GasrMwHv ITUtEPRKBvCWhBLl/MReX9zenKmaMrMYg4MINBKctcSVPh6QydESqBkXeOmKU4VejSrD x0bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=1OWaoCTzxKZIzea9KHsutKkxvhr4MmJCErg4gHGZoco=; b=pjvDxArboGtxBwu3r/9jrZ2isP2HfJ1cA/pw4GbU8CmW4eeE9ial4JO74eQojXqBoI lw7d6l4y2N46kk2TWHpWucO3i+E/FF1ElhjtqE/nLha1rdXUMhgYigeeTX9yUGb+Cmm7 bFK90YtpMhNOu8om5lSXHpMUW8aCM5BlTCneGQdki+J5w5obujLQ/mXDlMMO5FbwQWCY iI3DvLK94DomghbFhdQORO0OpbMoeEPEmvkr9ij2HHpmkk8o8p9CNz/yNKJzELNUO6z1 jOHXdnGjymidXN/7N1rTkwYKMAS+IcQ0qOtoROC1bWEMoWtzJsT77Pf0omzIlaRPuFoT C1DQ== X-Gm-Message-State: APjAAAVYyAE1KavJQAkFkZOJSthT3bA4uMBndzKCleuW74s5CbMQMqlJ fX+sVzzJCxGyB7aK470pE0r/SIh4 X-Google-Smtp-Source: APXvYqwY4QAx5US1n5/RTjYBTyM8Tk9PTKMRdAzcCS4IaTna10/V1mu+ccCq9QE6+jX2OPnWpxxsAA== X-Received: by 2002:a17:90a:e2d4:: with SMTP id fr20mr16491453pjb.85.1577922040932; Wed, 01 Jan 2020 15:40:40 -0800 (PST) Received: from [192.168.1.13] (47-36-118-16.dhcp.reno.nv.charter.com. [47.36.118.16]) by smtp.gmail.com with ESMTPSA id l186sm56894157pge.31.2020.01.01.15.40.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jan 2020 15:40:39 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-28FCBC89-F29C-4AEF-BE3E-5E0F0FEFADBE Content-Transfer-Encoding: 7bit From: Jeff Tantsura Mime-Version: 1.0 (1.0) Date: Wed, 1 Jan 2020 15:40:39 -0800 Message-Id: <6D9C717F-B921-411B-8AAD-67FD47F79047@gmail.com> References: Cc: Brian E Carpenter , "architecture-discuss@iab.org" In-Reply-To: To: Dan York X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2020 23:40:44 -0000 --Apple-Mail-28FCBC89-F29C-4AEF-BE3E-5E0F0FEFADBE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable While I share Lucy=E2=80=99 points, wrt connectivity of Outpost/similar plat= forms back to the centralized DC=E2=80=98s - noone is reinventing the wheel(= there=E2=80=99s no value), outer encap is IP, do we really care what=E2=80=99= s inside? Regards, Jeff > On Jan 1, 2020, at 12:11, Dan York wrote: >=20 > =EF=BB=BF Brian, >=20 >>> On Jan 1, 2020, at 2:12 PM, Brian E Carpenter wrote: >>>=20 >>> Cherry-picking from your interesing message: >>>=20 >>> What if there winds up being a lack of diversity of paths through the =E2= =80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if increasin= gly traffic winds up traveling through these proprietary global networks (to= which you need to pay to connect and through that gain permission to send t= raffic - and only to that company=E2=80=99s platforms)? >>=20 >> Is this really new, from a technical viewpoint? >=20 > I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally with t= hese newer networks to be able to fully answer that question. My knowledge c= omes from reading articles, going through tutorials, listening to talks / po= dcasts, and experimenting to the degree I can. But I don=E2=80=99t operate a= network or data center where I could join in to one (or more) of them=E2=80= =A6 so I have to defer to those who have that kind of more direct experience= . >=20 >> It reminds me very much of the early 1990s, when policy based BGP4 routin= g first became a thing, and acceptable use policies were applied by NSFNET, E= SNET, and their equivalents in Europe and Asia. That was all about money, of= course, except that it was public money. >=20 > Interesting thought. I guess the difference I could see was that in those d= ays the networks were all using the same open standards-based protocols, eve= n with AUP=E2=80=99s being applied. They were all weaving together a common n= etwork fabric, from what I saw as a network user at that time. >=20 > With these newer private networks, they may - or may not - be using the sa= me protocols that the public Internet is using. You may or may not know. (An= d from a purely operational point-of-view, you may not care=E2=80=A6 a main r= eason for using the private network is to have low-latency connectivity to a= pplications or content.)=20 >=20 > In at least one of the cases (Amazon Outposts), my understanding is that t= he company comes and installs hardware in your data center that then connect= s your network back to Amazon=E2=80=99s AWS network. Is it all running open I= nternet protocols? Or are there proprietary protocols (or =E2=80=9Cextension= s=E2=80=9D) that are making the connectivity that much faster/better? (And I= honestly do not know.) Do you only have connectivity to their platform(s)?= Or do you have wider connectivity? >=20 > To me, this is part of the question - do these newer, global, private netw= orks *increase* the overall resilience of the open, public Internet? Or do t= hey *decrease* the overall resilience of the open, public Internet? Or do th= ey not really have any effect? Or is it too soon to tell? >=20 > Interesting times, > Dan=20 >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail-28FCBC89-F29C-4AEF-BE3E-5E0F0FEFADBE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable While I share Lucy=E2=80=99 points, wrt con= nectivity of Outpost/similar platforms back to the centralized DC=E2=80=98s -= noone is reinventing the wheel(there=E2=80=99s no value), outer encap is IP= ,  do we really care what=E2=80=99s inside?

Reg= ards,
Jeff

On J= an 1, 2020, at 12:11, Dan York <york@isoc.org> wrote:

=EF=BB=BF Brian,

On Jan 1, 2020, at 2:12 PM, Brian E Carpenter <brian.e.carpenter@gmail.com<= /a>> wrote:

Cherry-picking from your interesing message:

What if there winds up being a lack of diversity of paths through the =E2=80= =9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if increasingly= traffic winds up traveling through these proprietary global networks (to wh= ich you need to pay to connect and through that gain permission to send traffic - and only to that company=E2=80=99s platforms)?

Is this really new, from a technical viewpoint?

I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally wi= th these newer networks to be able to fully answer that question.  My k= nowledge comes from reading articles, going through tutorials, listening to t= alks / podcasts, and experimenting to the degree I can. But I don=E2=80=99t operate a network or data center where I could j= oin in to one (or more) of them=E2=80=A6 so I have to defer to those who hav= e that kind of more direct experience.

It reminds me very much of the early 1990s, when policy based BGP4 routing fir= st became a thing, and acceptable use policies were applied by NSFNET, ESNET= , and their equivalents in Europe and Asia. That was all about money, of cou= rse, except that it was public money.

Interesting thought. I guess the difference I could see was t= hat in those days the networks were all using the same open standards-based p= rotocols, even with AUP=E2=80=99s being applied. They were all weaving toget= her a common network fabric, from what I saw as a network user at that time.

With these newer private networks, they may - or may not - b= e using the same protocols that the public Internet is using. You may or may= not know. (And from a purely operational point-of-view, you may not care=E2= =80=A6 a main reason for using the private network is to have low-latency connectivity to applications or content.)&nb= sp;

In at least one of the cases (Amazon Outposts), my understan= ding is that the company comes and installs hardware in your data center tha= t then connects your network back to Amazon=E2=80=99s AWS network. Is it all= running open Internet protocols? Or are there proprietary protocols (or =E2=80=9Cextensions=E2=80=9D) that are maki= ng the connectivity that much faster/better?  (And I honestly do not kn= ow.)  Do you only have connectivity to their platform(s)? Or do you hav= e wider connectivity?

To me, this is part of the question - do these newer, global= , private networks *increase* the overall resilience of the open, public Int= ernet? Or do they *decrease* the overall resilience of the open, public Inte= rnet? Or do they not really have any effect? Or is it too soon to tell?

Interesting times,
Dan 


_______________________________________________
Archit= ecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss
= --Apple-Mail-28FCBC89-F29C-4AEF-BE3E-5E0F0FEFADBE-- From nobody Thu Jan 2 18:10:41 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAB81200BA for ; Thu, 2 Jan 2020 18:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 nO9iLva5oJdi for ; Thu, 2 Jan 2020 18:10:37 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 9A131120058 for ; Thu, 2 Jan 2020 18:10:37 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id b18so37525437otp.0 for ; Thu, 02 Jan 2020 18:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bg2aaGBlf+lmp9DHwN5sXIHSXKGSYxvFUHRxx3hcM1I=; b=oA7Kgh4wcEHzaBa38tBm/c/u3ZHNec7r4Wuv5dnVQed0oaOlWfE0iDBTdQrHbfdqeC kGvSdld9rhVNyBCFzOXa9Vou3zIA726prDbMgcxhZbOKj+cUncmccv01IKM3vvvHywav hhKE2PiiefQHUOAxNXOK50jff0J+sJyD/EZh8Dhw+2TUIpRYSqmzWbeZR2edlhXi4Rd3 vKmOqMJACQPpBmavpIlwSp3lR/+ioTYzdtrqv1frqyLAuYAZvdO3XgDH6NkFoTgnNWSC ovK4BsRWlzPgWyRVg3exBA+Szy76znR0o8vJg6PaM7B3tp29d9UCUDW+eTEDdvjZf+Qh j7Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bg2aaGBlf+lmp9DHwN5sXIHSXKGSYxvFUHRxx3hcM1I=; b=GlDLQs3WWjxV9NqMr1pXBa0G/u1V3WfLc6fikWvZgbvNYhwD77fpEGWD3s7ahznGqf XDQoCkt5eVnn1inxDxlQRiiWB6f9w0LQRH6Pl/BX4Btc/sLxzmqF0GsZV5BfxLMfqRH9 v2fTiEdh+Zof6gvzl/1ZFpbmeaTVjf8P9vtvxrNrpuodj6N8NqJfLkIa56fuLSytJEx4 4mAhS6D4vRZd3hbpOyw0gng9YrCcvDzNuWpuMgJa53UOOEJkEqAtfHxK+V5fCO6/YhIP sCMYYyHTzlT4heVTtGkhJ97HvmciZ1GKUBuw+2lTW51ETTGt0y34s6FWNraqXqh2MUzj Vlnw== X-Gm-Message-State: APjAAAVFO840jFHrLPTjGXIJmIFrViVKJ+5oS3WzEBbAQ+tJBiaWhEQN sJzbqzyC0dHoQUB+p5+L3YOWVQqiWV4niF2Dx/M= X-Google-Smtp-Source: APXvYqzedOe6DzBMNJg9E0RA4PbA4oFZtsNg1WKAOIR2GHQnbnZswfmawvEBDs52gXbbTeRvypozxG/MYsXsZGTDrCA= X-Received: by 2002:a05:6830:10a:: with SMTP id i10mr91289447otp.365.1578017436916; Thu, 02 Jan 2020 18:10:36 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Thu, 2 Jan 2020 18:10:36 -0800 (PST) In-Reply-To: <6D9C717F-B921-411B-8AAD-67FD47F79047@gmail.com> References: <6D9C717F-B921-411B-8AAD-67FD47F79047@gmail.com> From: Guntur Wiseno Putra Date: Fri, 3 Jan 2020 09:10:36 +0700 Message-ID: To: Jeff Tantsura Cc: Dan York , "architecture-discuss@iab.org" Content-Type: multipart/alternative; boundary="000000000000c6e085059b32d071" Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 02:10:40 -0000 --000000000000c6e085059b32d071 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss, "Communication" may be understood as "society" and Internet is about networks of human communications... If it matters --and perhaps others: (1) UN's inititives for Sustainable Development Goals by supports of ICTs --including Internet & (2) engineering Internet's (architectural) resiliency (*), one closed enough in J. Hillier's "Strategic Navigation: a Multiplanar Methodology for Strategic Spatial Planning" I mentioned above is "sustainability" referring to longer-term plans. "Multiplanar theory offers the potential for multiple plans (Hillier 2007, 2011) : =E2=80=93 several (or one collectively preferred) trajectories or =E2=80=9C= visions=E2=80=9D of the longer-term future, including concepts towards which human and non-human actants =E2=80=9Cdesire=E2=80=9D to navigate, such as sustainability (Deleu= ze and Guattari=E2=80=99s planes of immanence) ; =E2=80=93 shorter-term, location-specific detailed plans and projects with collaboratively determined tangible goals, for example, for city centre regeneration, provision of affordable housing and so on (Deleuze and Guattari=E2=80=99s planes of organisation)". (*) Apologize: I rendering "resilience" without accessing Stephen's document directly at github --there was an icon feature I could not access by clicking (the triple lines in up-right corner) and I wandered if there were guidances to use the website... Regard, Guntur Wiseno Putra Pada Kamis, 02 Januari 2020, Jeff Tantsura menulis: > While I share Lucy=E2=80=99 points, wrt connectivity of Outpost/similar p= latforms > back to the centralized DC=E2=80=98s - noone is reinventing the wheel(the= re=E2=80=99s no > value), outer encap is IP, do we really care what=E2=80=99s inside? > > Regards, > Jeff > > On Jan 1, 2020, at 12:11, Dan York wrote: > > =EF=BB=BF Brian, > > On Jan 1, 2020, at 2:12 PM, Brian E Carpenter > wrote: > > Cherry-picking from your interesing message: > > What if there winds up being a lack of diversity of paths through the > =E2=80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if inc= reasingly traffic winds up > traveling through these proprietary global networks (to which you need to > pay to connect and through that gain permission to send traffic - and onl= y > to that company=E2=80=99s platforms)? > > > Is this really new, from a technical viewpoint? > > > I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally with= these newer > networks to be able to fully answer that question. My knowledge comes fr= om > reading articles, going through tutorials, listening to talks / podcasts, > and experimenting to the degree I can. But I don=E2=80=99t operate a netw= ork or > data center where I could join in to one (or more) of them=E2=80=A6 so I = have to > defer to those who have that kind of more direct experience. > > It reminds me very much of the early 1990s, when policy based BGP4 routin= g > first became a thing, and acceptable use policies were applied by NSFNET, > ESNET, and their equivalents in Europe and Asia. That was all about money= , > of course, except that it was public money. > > > Interesting thought. I guess the difference I could see was that in those > days the networks were all using the same open standards-based protocols, > even with AUP=E2=80=99s being applied. They were all weaving together a c= ommon > network fabric, from what I saw as a network user at that time. > > With these newer private networks, they may - or may not - be using the > same protocols that the public Internet is using. You may or may not know= . > (And from a purely operational point-of-view, you may not care=E2=80=A6 a= main > reason for using the private network is to have low-latency connectivity = to > applications or content.) > > In at least one of the cases (Amazon Outposts), my understanding is that > the company comes and installs hardware in your data center that then > connects your network back to Amazon=E2=80=99s AWS network. Is it all run= ning open > Internet protocols? Or are there proprietary protocols (or =E2=80=9Cexten= sions=E2=80=9D) > that are making the connectivity that much faster/better? (And I honestl= y > do not know.) Do you only have connectivity to their platform(s)? Or do > you have wider connectivity? > > To me, this is part of the question - do these newer, global, private > networks *increase* the overall resilience of the open, public Internet? = Or > do they *decrease* the overall resilience of the open, public Internet? O= r > do they not really have any effect? Or is it too soon to tell? > > Interesting times, > Dan > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > > --000000000000c6e085059b32d071 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,


"Communic= ation" may be understood as "society" and Internet is about = networks of human communications...



If it matters --and perhaps others: (1) UN's inititives= for Sustainable Development Goals by supports of ICTs --including Internet= & (2) engineering Internet's (architectural) resiliency (*), one c= losed enough in J. Hillier's "Strategic Navigation: a Multiplanar = Methodology for Strategic Spatial Planning" I mentioned above is "= ;sustainability" referring to longer-term plans.

<= div>

"Multiplanar theory o= ffers the potential for multiple plans (Hillier 2007, 2011)=C2=A0:

=E2=80=93 several (or one collectively preferred) = trajectories or =E2=80=9Cvisions=E2=80=9D of the longer-term future, includ= ing concepts towards which human and non-human actants =E2=80=9Cdesire=E2= =80=9D to navigate, such as sustainability (Deleuze and Guattari=E2=80=99s = planes of immanence)=C2=A0;

=E2=80=93 shor= ter-term, location-specific detailed plans and projects with collaborativel= y determined tangible goals, for example, for city centre regeneration, pro= vision of affordable housing and so on (Deleuze and Guattari=E2=80=99s plan= es of organisation)".

(*) Apologize: I rendering "r= esilience" without accessing Stephen's document directly at github= --there was an icon feature I could not access by clicking (the triple lin= es in up-right corner) and I wandered if there were guidances to use the we= bsite...

Regard,
Guntur Wiseno Putra
=
Pada Kamis, 02 Januari 2020, Jeff Tantsura <jefftant.ietf@gmail.com> menulis:
While I share Lucy=E2=80=99 points, wr= t connectivity of Outpost/similar platforms back to the centralized DC=E2= =80=98s - noone is reinventing the wheel(there=E2=80=99s no value), outer e= ncap is IP, =C2=A0do we really care what=E2=80=99s inside?

Regards,
Jeff

On Jan 1, 2020, at 12:11, Dan York <york@isoc.org> wrote:

<= /div>
=EF=BB=BF Brian,

On Jan 1, 2020, at 2:12 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Cherry-picking from your interesing message:

What if there winds up being a lack of diversity of paths through the =E2= =80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if increasi= ngly traffic winds up traveling through these proprietary global networks (= to which you need to pay to connect and through that gain permission to send traffic - and only to that company=E2=80=99s platforms)?

Is this really new, from a technical viewpoint?

I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally w= ith these newer networks to be able to fully answer that question.=C2=A0 My= knowledge comes from reading articles, going through tutorials, listening = to talks / podcasts, and experimenting to the degree I can. But I don=E2=80=99t operate a network or data center where I could = join in to one (or more) of them=E2=80=A6 so I have to defer to those who h= ave that kind of more direct experience.

It reminds me very much of the early 1990s, when policy based BGP4 routing fi= rst became a thing, and acceptable use policies were applied by NSFNET, ESN= ET, and their equivalents in Europe and Asia. That was all about money, of = course, except that it was public money.

Interesting thought. I guess the difference I could see was that in th= ose days the networks were all using the same open standards-based protocol= s, even with AUP=E2=80=99s being applied. They were all weaving together a = common network fabric, from what I saw as a network user at that time.

With these newer private networks, they may - or may not - be using th= e same protocols that the public Internet is using. You may or may not know= . (And from a purely operational point-of-view, you may not care=E2=80=A6 a= main reason for using the private network is to have low-latency connectivity to applications or content.)= =C2=A0

In at least one of the cases (Amazon Outposts), my understanding is th= at the company comes and installs hardware in your data center that then co= nnects your network back to Amazon=E2=80=99s AWS network. Is it all running= open Internet protocols? Or are there proprietary protocols (or =E2=80=9Cextensions=E2=80=9D) that are mak= ing the connectivity that much faster/better? =C2=A0(And I honestly do not = know.) =C2=A0Do you only have connectivity to their platform(s)? Or do you = have wider connectivity?

To me, this is part of the question - do these newer, global, private = networks *increase* the overall resilience of the open, public Internet? Or= do they *decrease* the overall resilience of the open, public Internet? Or= do they not really have any effect? Or is it too soon to tell?

Interesting times,
Dan=C2=A0


_______________________________________________
= Architecture-discuss mailing list
Architecture-discuss@ietf.org=
https://www.ietf.org/mailman/listinfo/a= rchitecture-discuss
--000000000000c6e085059b32d071-- From nobody Fri Jan 3 06:19:45 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BE412024E for ; Fri, 3 Jan 2020 06:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 EOqu9ARuxruj for ; Fri, 3 Jan 2020 06:19:41 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 C5E95120046 for ; Fri, 3 Jan 2020 06:19:41 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id k14so61346481otn.4 for ; Fri, 03 Jan 2020 06:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=czmGYJl0fKaqJhoi/JozlEYrbbdZg0yYLqeyx2MOdfs=; b=H+ry0VU6G1hjdvLfWo9owQDJC1QfoI6RWgwzwAVTUIfkMa7E6IJUwqK0iLirDJCr8z s2qr5oBU+jLzoEAf9EdDPUDOWq8dmECZelv7c6BcigSNXBxwTSWWspmNmcFPxzwPr0nJ ldMPIHRq70HgspONY08w/BzaaIVfhsV4E1ngtZdN7FeDLrodUYF5R+BSgTQa16Io4dTd PjmK3BMJDA2n4bytTXp+BlVAf57n2TXO9XoyxmZlYrXsIgpmZ0+lhdNFTv3HrxEnQydE AyJgprqhCyGxeZnZQ2vowCC+dKLz40tHCMXkVEgQ7OCENVzzNVSlK47og9UH9hqIRaop DfvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=czmGYJl0fKaqJhoi/JozlEYrbbdZg0yYLqeyx2MOdfs=; b=S+g5QW0kZ4uMrTJOYJZDkzeV6Xhm9zDR6u64lAIMC6Cwf14cQqPxTIXcxZzN0EhDJz F1vlFjLb/ysKANn4SaKLFLW8265zlrmY3ylWtyWlfqd1zw740faJPZUyD1pfHm4K1pmX Hdquwx39lTOKrHYFbExhhHrYWq0O6sbhDF/t/hTKEG19jO1XKRKCgehycOAexfaHh6p9 KRwkTX8/z+nSLtYa7DvlX+VC9NIk/xkB5c3kHKsWTSxbUuuLVptTh0cQRldSw2CmZXGU v7eDXPd12llXaJAUjIge/vJjBLp5PkoS12KHwBHQLg1HRMu5WEiHjCxVTDvNzb0Nbq55 zo4w== X-Gm-Message-State: APjAAAU+2YF1IMX5wfTeRRjbXCllMM7/6MiwngclP2ADAVlYWjHIZ4+M fjYc4/aVlFQKmLlKx0bZ+cC3AfupMEhAZP94o8U= X-Google-Smtp-Source: APXvYqwLxGAN9w+tsmPIU59dn6x6+B6/zcHTrLR17u5AkyBqvUYZ7I9l/ZgykVpPWHpoub22jTtErjo4InNH4qYFhl4= X-Received: by 2002:a9d:65da:: with SMTP id z26mr90745488oth.197.1578061181157; Fri, 03 Jan 2020 06:19:41 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Fri, 3 Jan 2020 06:19:40 -0800 (PST) In-Reply-To: References: <6D9C717F-B921-411B-8AAD-67FD47F79047@gmail.com> From: Guntur Wiseno Putra Date: Fri, 3 Jan 2020 21:19:40 +0700 Message-ID: To: Jeff Tantsura , stephen.farrell@cs.tcd.ie Cc: Dan York , "architecture-discuss@iab.org" , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000002308ba059b3d0025" Archived-At: Subject: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 14:19:43 -0000 --0000000000002308ba059b3d0025 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss (Stephen and Others), When we think about "cyberspace", and also "real space", of communications networks, of societies, and about engineering Internet architecturally, this quotation concerning with "design" --as the term has so far been part of this thread of discussion-- may be inspiring: Navigating strategically across multiple planes requires practitioners to sense and discern connections and patterns in what is taking place, to try to understand the underlying dynamics and interdependencies between elements, to appreciate the diverse possibilities of what is happening and what might happen, and to respond by designing actions which align with the intentions and values of the agreed longer-term strategic trajectory (Hames 2007a, p. 114), but which are contextually appropriate, not copy/pastes of other, previous or =E2=80=9Cbest=E2=80=9D practices (Hillier 2011, p. 508). (being cited from J. Hillier's ".. Strategic Spatial Planning" I mentioned in the previous message) Note: I have just realized that the 1st message of this thread of discussion --Stephen's one-- was sent by architecture-discuss@iab.org. Has been there a transfer from @ietf to @iab in managing the architecture-discuss list --while my accepted registration to architecture-discuss@ietf was in March 2019...? Regard, Guntur Wiseno Putra Pada Jumat, 03 Januari 2020, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > > "Communication" may be understood as "society" and Internet is about > networks of human communications... > > > > If it matters --and perhaps others: (1) UN's inititives for Sustainable > Development Goals by supports of ICTs --including Internet & (2) > engineering Internet's (architectural) resiliency (*), one closed enough = in > J. Hillier's "Strategic Navigation: a Multiplanar Methodology for Strateg= ic > Spatial Planning" I mentioned above is "sustainability" referring to > longer-term plans. > > > "Multiplanar theory offers the potential for multiple plans (Hillier 2007= , > 2011) : > > =E2=80=93 several (or one collectively preferred) trajectories or =E2=80= =9Cvisions=E2=80=9D of the > longer-term future, including concepts towards which human and non-human > actants =E2=80=9Cdesire=E2=80=9D to navigate, such as sustainability (Del= euze and > Guattari=E2=80=99s planes of immanence) ; > > =E2=80=93 shorter-term, location-specific detailed plans and projects wit= h > collaboratively determined tangible goals, for example, for city centre > regeneration, provision of affordable housing and so on (Deleuze and > Guattari=E2=80=99s planes of organisation)". > (*) Apologize: I rendering "resilience" without accessing Stephen's > document directly at github --there was an icon feature I could not acces= s > by clicking (the triple lines in up-right corner) and I wandered if there > were guidances to use the website... > > Regard, > Guntur Wiseno Putra > > Pada Kamis, 02 Januari 2020, Jeff Tantsura > menulis: > >> While I share Lucy=E2=80=99 points, wrt connectivity of Outpost/similar = platforms >> back to the centralized DC=E2=80=98s - noone is reinventing the wheel(th= ere=E2=80=99s no >> value), outer encap is IP, do we really care what=E2=80=99s inside? >> >> Regards, >> Jeff >> >> On Jan 1, 2020, at 12:11, Dan York wrote: >> >> =EF=BB=BF Brian, >> >> On Jan 1, 2020, at 2:12 PM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >> Cherry-picking from your interesing message: >> >> What if there winds up being a lack of diversity of paths through the >> =E2=80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if in= creasingly traffic winds up >> traveling through these proprietary global networks (to which you need t= o >> pay to connect and through that gain permission to send traffic - and on= ly >> to that company=E2=80=99s platforms)? >> >> >> Is this really new, from a technical viewpoint? >> >> >> I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally wit= h these newer >> networks to be able to fully answer that question. My knowledge comes f= rom >> reading articles, going through tutorials, listening to talks / podcasts= , >> and experimenting to the degree I can. But I don=E2=80=99t operate a net= work or >> data center where I could join in to one (or more) of them=E2=80=A6 so I= have to >> defer to those who have that kind of more direct experience. >> >> It reminds me very much of the early 1990s, when policy based BGP4 >> routing first became a thing, and acceptable use policies were applied b= y >> NSFNET, ESNET, and their equivalents in Europe and Asia. That was all ab= out >> money, of course, except that it was public money. >> >> >> Interesting thought. I guess the difference I could see was that in thos= e >> days the networks were all using the same open standards-based protocols= , >> even with AUP=E2=80=99s being applied. They were all weaving together a = common >> network fabric, from what I saw as a network user at that time. >> >> With these newer private networks, they may - or may not - be using the >> same protocols that the public Internet is using. You may or may not kno= w. >> (And from a purely operational point-of-view, you may not care=E2=80=A6 = a main >> reason for using the private network is to have low-latency connectivity= to >> applications or content.) >> >> In at least one of the cases (Amazon Outposts), my understanding is that >> the company comes and installs hardware in your data center that then >> connects your network back to Amazon=E2=80=99s AWS network. Is it all ru= nning open >> Internet protocols? Or are there proprietary protocols (or =E2=80=9Cexte= nsions=E2=80=9D) >> that are making the connectivity that much faster/better? (And I honest= ly >> do not know.) Do you only have connectivity to their platform(s)? Or do >> you have wider connectivity? >> >> To me, this is part of the question - do these newer, global, private >> networks *increase* the overall resilience of the open, public Internet?= Or >> do they *decrease* the overall resilience of the open, public Internet? = Or >> do they not really have any effect? Or is it too soon to tell? >> >> Interesting times, >> Dan >> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> >> --0000000000002308ba059b3d0025 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss
(Stephen and Others),

When= we think about "cyberspace", and also "real space", of= communications networks, of societies, and about engineering Internet arch= itecturally, this quotation concerning with "design" --as the ter= m has so far been part of this thread of discussion-- may be inspiring:


Navi= gating strategically across multiple planes requires practitioners to sense= and discern connections and patterns in what is taking place, to try to un= derstand the underlying dynamics and interdependencies between elements, to= appreciate the diverse possibilities of what is happening and what might h= appen, and to respond by designing actions which align with the intentions = and values of the agreed longer-term strategic trajectory (Hames 2007a, p.= =C2=A0114), but which are contextually appropriate, not copy/pastes of othe= r, previous or =E2=80=9Cbest=E2=80=9D practices (Hillier 2011, p.=C2=A0508)= .


(being cited from J. H= illier's ".. Strategic Spatial Planning" I mentioned in the p= revious message)



Not= e: I have just realized that the 1st message of this thread of discussion -= -Stephen's one-- was sent by architecture-discuss@iab.org. Has been there a transfer from @iet= f to @iab in managing the architecture-discuss list --while my accepted reg= istration to architecture-discuss@ietf was in March 2019...?

=

Regard,
Guntur Wiseno Putra

Pada= Jumat, 03 Januari 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,


"Communication" may be understood as "society"= and Internet is about networks of human communications...



If it matters --and perhaps others: = (1) UN's inititives for Sustainable Development Goals by supports of IC= Ts --including Internet & (2) engineering Internet's (architectural= ) resiliency (*), one closed enough in J. Hillier's "Strategic Nav= igation: a Multiplanar Methodology for Strategic Spatial Planning" I m= entioned above is "sustainability" referring to longer-term plans= .


&qu= ot;Multiplanar theory offers the potential for multiple plans (Hillier 2007= , 2011)=C2=A0:

=E2=80=93 several (or one c= ollectively preferred) trajectories or =E2=80=9Cvisions=E2=80=9D of the lon= ger-term future, including concepts towards which human and non-human actan= ts =E2=80=9Cdesire=E2=80=9D to navigate, such as sustainability (Deleuze an= d Guattari=E2=80=99s planes of immanence)=C2=A0;

=E2=80=93 shorter-term, location-specific detailed plans and project= s with collaboratively determined tangible goals, for example, for city cen= tre regeneration, provision of affordable housing and so on (Deleuze and Gu= attari=E2=80=99s planes of organisation)".

(*) Apologize= : I rendering "resilience" without accessing Stephen's docume= nt directly at github --there was an icon feature I could not access by cli= cking (the triple lines in up-right corner) and I wandered if there were gu= idances to use the website...

Regard,
Gu= ntur Wiseno Putra

Pada Kamis, 02 Januari 2020, Jeff Tantsura <jefftant.ietf@gma= il.com> menulis:
While I share Lucy=E2=80=99 points, wrt connectivity of Outpost/similar pl= atforms back to the centralized DC=E2=80=98s - noone is reinventing the whe= el(there=E2=80=99s no value), outer encap is IP, =C2=A0do we really care wh= at=E2=80=99s inside?

Regards,
Jeff
<= div dir=3D"ltr">
On Jan 1, 2020, at 12:11, Dan= York <york@isoc.org<= /a>> wrote:

=EF=BB=BF Brian,


Cherry-picking from your interesing message:

What if there winds up being a lack of diversity of paths through the =E2= =80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if increasi= ngly traffic winds up traveling through these proprietary global networks (= to which you need to pay to connect and through that gain permission to send traffic - and only to that company=E2=80=99s platforms)?

Is this really new, from a technical viewpoint?

I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally w= ith these newer networks to be able to fully answer that question.=C2=A0 My= knowledge comes from reading articles, going through tutorials, listening = to talks / podcasts, and experimenting to the degree I can. But I don=E2=80=99t operate a network or data center where I could = join in to one (or more) of them=E2=80=A6 so I have to defer to those who h= ave that kind of more direct experience.

It reminds me very much of the early 1990s, when policy based BGP4 routing fi= rst became a thing, and acceptable use policies were applied by NSFNET, ESN= ET, and their equivalents in Europe and Asia. That was all about money, of = course, except that it was public money.

Interesting thought. I guess the difference I could see was that in th= ose days the networks were all using the same open standards-based protocol= s, even with AUP=E2=80=99s being applied. They were all weaving together a = common network fabric, from what I saw as a network user at that time.

With these newer private networks, they may - or may not - be using th= e same protocols that the public Internet is using. You may or may not know= . (And from a purely operational point-of-view, you may not care=E2=80=A6 a= main reason for using the private network is to have low-latency connectivity to applications or content.)= =C2=A0

In at least one of the cases (Amazon Outposts), my understanding is th= at the company comes and installs hardware in your data center that then co= nnects your network back to Amazon=E2=80=99s AWS network. Is it all running= open Internet protocols? Or are there proprietary protocols (or =E2=80=9Cextensions=E2=80=9D) that are mak= ing the connectivity that much faster/better? =C2=A0(And I honestly do not = know.) =C2=A0Do you only have connectivity to their platform(s)? Or do you = have wider connectivity?

To me, this is part of the question - do these newer, global, private = networks *increase* the overall resilience of the open, public Internet? Or= do they *decrease* the overall resilience of the open, public Internet? Or= do they not really have any effect? Or is it too soon to tell?

Interesting times,
Dan=C2=A0


_______________________________________________
= Architecture-discuss mailing list
Architecture-discuss@ietf.org=
https://www.ietf.org/mailman/listinfo/a= rchitecture-discuss
--0000000000002308ba059b3d0025-- From nobody Fri Jan 3 06:19:50 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9E8120046 for ; Fri, 3 Jan 2020 06:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 r3MpFSS-urCa for ; Fri, 3 Jan 2020 06:19:42 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 D0F9B120086 for ; Fri, 3 Jan 2020 06:19:41 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id k8so44166572otl.13 for ; Fri, 03 Jan 2020 06:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=czmGYJl0fKaqJhoi/JozlEYrbbdZg0yYLqeyx2MOdfs=; b=H+ry0VU6G1hjdvLfWo9owQDJC1QfoI6RWgwzwAVTUIfkMa7E6IJUwqK0iLirDJCr8z s2qr5oBU+jLzoEAf9EdDPUDOWq8dmECZelv7c6BcigSNXBxwTSWWspmNmcFPxzwPr0nJ ldMPIHRq70HgspONY08w/BzaaIVfhsV4E1ngtZdN7FeDLrodUYF5R+BSgTQa16Io4dTd PjmK3BMJDA2n4bytTXp+BlVAf57n2TXO9XoyxmZlYrXsIgpmZ0+lhdNFTv3HrxEnQydE AyJgprqhCyGxeZnZQ2vowCC+dKLz40tHCMXkVEgQ7OCENVzzNVSlK47og9UH9hqIRaop DfvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=czmGYJl0fKaqJhoi/JozlEYrbbdZg0yYLqeyx2MOdfs=; b=Cei+tyUuXYGjH0uXNcCsOEFlmERaqcKvtJ9dz8W7XSyxPCoxhV4Y1+GaZAz1eS8Lih n5nIeyz26hivSBQXHrZgP7FJPQ1i6nvlJDA7U1qiNIs6Hb3E3omqfYtNNCFs95SmcRTu JNHf8BxfniKvaWWc3UVq/q3VhgjaloMYX4iJIf2YXY/peFbknoT6cPjf3JnT6kT2Rwm8 8R0n/vxDtFIgVJJa1P8CtHntQLZR2zseJgJY+5pWLBTUi0mM8RMS/bNCbg+APbTsEAbd lAknFs6oDZhcNqO4ru1aOdY0Z622c5uiOp0Vo5mgk+saurZOWLrpcKyAc3BvCtt0rMgb soIA== X-Gm-Message-State: APjAAAXTjl/ruH1VwJRpY/tvy8GE/30H02a0WfVQJUW2YU6WRVwoHsjb 840dvVqlbXRLH/7O66km0scE06PVxWYu9DmsrfI= X-Google-Smtp-Source: APXvYqwLxGAN9w+tsmPIU59dn6x6+B6/zcHTrLR17u5AkyBqvUYZ7I9l/ZgykVpPWHpoub22jTtErjo4InNH4qYFhl4= X-Received: by 2002:a9d:65da:: with SMTP id z26mr90745488oth.197.1578061181157; Fri, 03 Jan 2020 06:19:41 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Fri, 3 Jan 2020 06:19:40 -0800 (PST) In-Reply-To: References: <6D9C717F-B921-411B-8AAD-67FD47F79047@gmail.com> From: Guntur Wiseno Putra Date: Fri, 3 Jan 2020 21:19:40 +0700 Message-ID: To: Jeff Tantsura , stephen.farrell@cs.tcd.ie Cc: Dan York , "architecture-discuss@iab.org" , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000002308ba059b3d0025" Archived-At: Subject: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 14:19:43 -0000 --0000000000002308ba059b3d0025 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss (Stephen and Others), When we think about "cyberspace", and also "real space", of communications networks, of societies, and about engineering Internet architecturally, this quotation concerning with "design" --as the term has so far been part of this thread of discussion-- may be inspiring: Navigating strategically across multiple planes requires practitioners to sense and discern connections and patterns in what is taking place, to try to understand the underlying dynamics and interdependencies between elements, to appreciate the diverse possibilities of what is happening and what might happen, and to respond by designing actions which align with the intentions and values of the agreed longer-term strategic trajectory (Hames 2007a, p. 114), but which are contextually appropriate, not copy/pastes of other, previous or =E2=80=9Cbest=E2=80=9D practices (Hillier 2011, p. 508). (being cited from J. Hillier's ".. Strategic Spatial Planning" I mentioned in the previous message) Note: I have just realized that the 1st message of this thread of discussion --Stephen's one-- was sent by architecture-discuss@iab.org. Has been there a transfer from @ietf to @iab in managing the architecture-discuss list --while my accepted registration to architecture-discuss@ietf was in March 2019...? Regard, Guntur Wiseno Putra Pada Jumat, 03 Januari 2020, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > > "Communication" may be understood as "society" and Internet is about > networks of human communications... > > > > If it matters --and perhaps others: (1) UN's inititives for Sustainable > Development Goals by supports of ICTs --including Internet & (2) > engineering Internet's (architectural) resiliency (*), one closed enough = in > J. Hillier's "Strategic Navigation: a Multiplanar Methodology for Strateg= ic > Spatial Planning" I mentioned above is "sustainability" referring to > longer-term plans. > > > "Multiplanar theory offers the potential for multiple plans (Hillier 2007= , > 2011) : > > =E2=80=93 several (or one collectively preferred) trajectories or =E2=80= =9Cvisions=E2=80=9D of the > longer-term future, including concepts towards which human and non-human > actants =E2=80=9Cdesire=E2=80=9D to navigate, such as sustainability (Del= euze and > Guattari=E2=80=99s planes of immanence) ; > > =E2=80=93 shorter-term, location-specific detailed plans and projects wit= h > collaboratively determined tangible goals, for example, for city centre > regeneration, provision of affordable housing and so on (Deleuze and > Guattari=E2=80=99s planes of organisation)". > (*) Apologize: I rendering "resilience" without accessing Stephen's > document directly at github --there was an icon feature I could not acces= s > by clicking (the triple lines in up-right corner) and I wandered if there > were guidances to use the website... > > Regard, > Guntur Wiseno Putra > > Pada Kamis, 02 Januari 2020, Jeff Tantsura > menulis: > >> While I share Lucy=E2=80=99 points, wrt connectivity of Outpost/similar = platforms >> back to the centralized DC=E2=80=98s - noone is reinventing the wheel(th= ere=E2=80=99s no >> value), outer encap is IP, do we really care what=E2=80=99s inside? >> >> Regards, >> Jeff >> >> On Jan 1, 2020, at 12:11, Dan York wrote: >> >> =EF=BB=BF Brian, >> >> On Jan 1, 2020, at 2:12 PM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >> Cherry-picking from your interesing message: >> >> What if there winds up being a lack of diversity of paths through the >> =E2=80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if in= creasingly traffic winds up >> traveling through these proprietary global networks (to which you need t= o >> pay to connect and through that gain permission to send traffic - and on= ly >> to that company=E2=80=99s platforms)? >> >> >> Is this really new, from a technical viewpoint? >> >> >> I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally wit= h these newer >> networks to be able to fully answer that question. My knowledge comes f= rom >> reading articles, going through tutorials, listening to talks / podcasts= , >> and experimenting to the degree I can. But I don=E2=80=99t operate a net= work or >> data center where I could join in to one (or more) of them=E2=80=A6 so I= have to >> defer to those who have that kind of more direct experience. >> >> It reminds me very much of the early 1990s, when policy based BGP4 >> routing first became a thing, and acceptable use policies were applied b= y >> NSFNET, ESNET, and their equivalents in Europe and Asia. That was all ab= out >> money, of course, except that it was public money. >> >> >> Interesting thought. I guess the difference I could see was that in thos= e >> days the networks were all using the same open standards-based protocols= , >> even with AUP=E2=80=99s being applied. They were all weaving together a = common >> network fabric, from what I saw as a network user at that time. >> >> With these newer private networks, they may - or may not - be using the >> same protocols that the public Internet is using. You may or may not kno= w. >> (And from a purely operational point-of-view, you may not care=E2=80=A6 = a main >> reason for using the private network is to have low-latency connectivity= to >> applications or content.) >> >> In at least one of the cases (Amazon Outposts), my understanding is that >> the company comes and installs hardware in your data center that then >> connects your network back to Amazon=E2=80=99s AWS network. Is it all ru= nning open >> Internet protocols? Or are there proprietary protocols (or =E2=80=9Cexte= nsions=E2=80=9D) >> that are making the connectivity that much faster/better? (And I honest= ly >> do not know.) Do you only have connectivity to their platform(s)? Or do >> you have wider connectivity? >> >> To me, this is part of the question - do these newer, global, private >> networks *increase* the overall resilience of the open, public Internet?= Or >> do they *decrease* the overall resilience of the open, public Internet? = Or >> do they not really have any effect? Or is it too soon to tell? >> >> Interesting times, >> Dan >> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> >> --0000000000002308ba059b3d0025 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss
(Stephen and Others),

When= we think about "cyberspace", and also "real space", of= communications networks, of societies, and about engineering Internet arch= itecturally, this quotation concerning with "design" --as the ter= m has so far been part of this thread of discussion-- may be inspiring:


Navi= gating strategically across multiple planes requires practitioners to sense= and discern connections and patterns in what is taking place, to try to un= derstand the underlying dynamics and interdependencies between elements, to= appreciate the diverse possibilities of what is happening and what might h= appen, and to respond by designing actions which align with the intentions = and values of the agreed longer-term strategic trajectory (Hames 2007a, p.= =C2=A0114), but which are contextually appropriate, not copy/pastes of othe= r, previous or =E2=80=9Cbest=E2=80=9D practices (Hillier 2011, p.=C2=A0508)= .


(being cited from J. H= illier's ".. Strategic Spatial Planning" I mentioned in the p= revious message)



Not= e: I have just realized that the 1st message of this thread of discussion -= -Stephen's one-- was sent by architecture-discuss@iab.org. Has been there a transfer from @iet= f to @iab in managing the architecture-discuss list --while my accepted reg= istration to architecture-discuss@ietf was in March 2019...?

=

Regard,
Guntur Wiseno Putra

Pada= Jumat, 03 Januari 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,


"Communication" may be understood as "society"= and Internet is about networks of human communications...



If it matters --and perhaps others: = (1) UN's inititives for Sustainable Development Goals by supports of IC= Ts --including Internet & (2) engineering Internet's (architectural= ) resiliency (*), one closed enough in J. Hillier's "Strategic Nav= igation: a Multiplanar Methodology for Strategic Spatial Planning" I m= entioned above is "sustainability" referring to longer-term plans= .


&qu= ot;Multiplanar theory offers the potential for multiple plans (Hillier 2007= , 2011)=C2=A0:

=E2=80=93 several (or one c= ollectively preferred) trajectories or =E2=80=9Cvisions=E2=80=9D of the lon= ger-term future, including concepts towards which human and non-human actan= ts =E2=80=9Cdesire=E2=80=9D to navigate, such as sustainability (Deleuze an= d Guattari=E2=80=99s planes of immanence)=C2=A0;

=E2=80=93 shorter-term, location-specific detailed plans and project= s with collaboratively determined tangible goals, for example, for city cen= tre regeneration, provision of affordable housing and so on (Deleuze and Gu= attari=E2=80=99s planes of organisation)".

(*) Apologize= : I rendering "resilience" without accessing Stephen's docume= nt directly at github --there was an icon feature I could not access by cli= cking (the triple lines in up-right corner) and I wandered if there were gu= idances to use the website...

Regard,
Gu= ntur Wiseno Putra

Pada Kamis, 02 Januari 2020, Jeff Tantsura <jefftant.ietf@gma= il.com> menulis:
While I share Lucy=E2=80=99 points, wrt connectivity of Outpost/similar pl= atforms back to the centralized DC=E2=80=98s - noone is reinventing the whe= el(there=E2=80=99s no value), outer encap is IP, =C2=A0do we really care wh= at=E2=80=99s inside?

Regards,
Jeff
<= div dir=3D"ltr">
On Jan 1, 2020, at 12:11, Dan= York <york@isoc.org<= /a>> wrote:

=EF=BB=BF Brian,


Cherry-picking from your interesing message:

What if there winds up being a lack of diversity of paths through the =E2= =80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if increasi= ngly traffic winds up traveling through these proprietary global networks (= to which you need to pay to connect and through that gain permission to send traffic - and only to that company=E2=80=99s platforms)?

Is this really new, from a technical viewpoint?

I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally w= ith these newer networks to be able to fully answer that question.=C2=A0 My= knowledge comes from reading articles, going through tutorials, listening = to talks / podcasts, and experimenting to the degree I can. But I don=E2=80=99t operate a network or data center where I could = join in to one (or more) of them=E2=80=A6 so I have to defer to those who h= ave that kind of more direct experience.

It reminds me very much of the early 1990s, when policy based BGP4 routing fi= rst became a thing, and acceptable use policies were applied by NSFNET, ESN= ET, and their equivalents in Europe and Asia. That was all about money, of = course, except that it was public money.

Interesting thought. I guess the difference I could see was that in th= ose days the networks were all using the same open standards-based protocol= s, even with AUP=E2=80=99s being applied. They were all weaving together a = common network fabric, from what I saw as a network user at that time.

With these newer private networks, they may - or may not - be using th= e same protocols that the public Internet is using. You may or may not know= . (And from a purely operational point-of-view, you may not care=E2=80=A6 a= main reason for using the private network is to have low-latency connectivity to applications or content.)= =C2=A0

In at least one of the cases (Amazon Outposts), my understanding is th= at the company comes and installs hardware in your data center that then co= nnects your network back to Amazon=E2=80=99s AWS network. Is it all running= open Internet protocols? Or are there proprietary protocols (or =E2=80=9Cextensions=E2=80=9D) that are mak= ing the connectivity that much faster/better? =C2=A0(And I honestly do not = know.) =C2=A0Do you only have connectivity to their platform(s)? Or do you = have wider connectivity?

To me, this is part of the question - do these newer, global, private = networks *increase* the overall resilience of the open, public Internet? Or= do they *decrease* the overall resilience of the open, public Internet? Or= do they not really have any effect? Or is it too soon to tell?

Interesting times,
Dan=C2=A0


_______________________________________________
= Architecture-discuss mailing list
Architecture-discuss@ietf.org=
https://www.ietf.org/mailman/listinfo/a= rchitecture-discuss
--0000000000002308ba059b3d0025-- From nobody Fri Jan 3 06:44:54 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF532120086 for ; Fri, 3 Jan 2020 06:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 wOtSXN0fqqIF for ; Fri, 3 Jan 2020 06:44:48 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE746120046 for ; Fri, 3 Jan 2020 06:44:48 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id n16so10288148oie.12 for ; Fri, 03 Jan 2020 06:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UbNoZAi8A8V0Ovxoujrza96c/yUNNiSNhYHrEnxN86U=; b=m8tLz3SUsHEsdOFSrmfuQE6I/E0LfhNgyg3sqd1zs4lsFc2bKKVRIF16QaI+mgWrTV OmCnZKHMptGb+vPXo8HJ19yZ/izQSVe5y1kB/NoXTYoyDTVT3eSMTRmAxtmMopoEydA+ 2rQTWYwMmD2MwYFYAImo8dFJsldoO8WqDQeSG7xgWyU815kNU6QHilgvI7+CFtEF0TJ+ Si6twh5ymE9EMKQZ4FF31IcA1eoRwMeGMzND6DBIc+FtazXq8mFWupq98Xe4jafMqwLG ZLc63AYGLTptmVIK3OUNTQW2x8IBypsRHZhKkRRD8hD3EHa/7P9fwvpgRuiIvaA60Q+d uEiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UbNoZAi8A8V0Ovxoujrza96c/yUNNiSNhYHrEnxN86U=; b=ZpOMQC+JBgJaYUUvQ3lZSkRegYIzqxZZvHGc7u7ZUHUsoI4wWkQLahd+LdcI/tFew1 lUvFfd2J0ezGp4PL8+V6y+0YwH/1eTjBFkOsDpf2M1miPdkNyFyonzHeaW7Q2qxLVHQL 8dJ9lqb31y1FRImQzxY7FVTDV3Inco/K+yhPDRprE+12Pe8HAt7HAfCcrU9vg1ksWYat eGPLOLaAJNe9dqEvdbGBZs9iZvxDIWlSvl/TLA2IMIz9Bs+0H7iwItqX6gPUHRC17dNQ NARe3cwwZWns/NCqliZ+OwvqVNMFSj17UOieYkErBLYyNBj6UIxeyOt45UFKZOEyZCBR dFXA== X-Gm-Message-State: APjAAAWJXfUtf37VpP5mRwRAfpOzCfzftm+B92PMyxADh/OWNqmvcSua ApODT46x2XskUQaPCxKpfSe3NgDxfL+q79vHHZ0= X-Google-Smtp-Source: APXvYqyswihg+jV64z7ar/ibqMOQ+c0GCQiGSyMjy/SK7dm1GLx9PB8Lf4bg3QG2YQLOc+Vt1v8Sb/C5aLKvuGwxg0c= X-Received: by 2002:a54:468b:: with SMTP id k11mr3806737oic.134.1578062687994; Fri, 03 Jan 2020 06:44:47 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Fri, 3 Jan 2020 06:44:47 -0800 (PST) In-Reply-To: References: <6D9C717F-B921-411B-8AAD-67FD47F79047@gmail.com> From: Guntur Wiseno Putra Date: Fri, 3 Jan 2020 21:44:47 +0700 Message-ID: To: Jeff Tantsura , "stephen.farrell@cs.tcd.ie" Cc: Dan York , "architecture-discuss@iab.org" , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f386cb059b3d59cb" Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 14:44:51 -0000 --000000000000f386cb059b3d59cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss (Stephen and Others), When we think about "cyberspace", and also "real space", of communications networks, of societies, and about engineering Internet architecturally, this quotation concerning with "design" --as the term has so far been part of this thread of discussion-- may be inspiring: Navigating strategically across multiple planes requires practitioners to sense and discern connections and patterns in what is taking place, to try to understand the underlying dynamics and interdependencies between elements, to appreciate the diverse possibilities of what is happening and what might happen, and to respond by designing actions which align with the intentions and values of the agreed longer-term strategic trajectory (Hames 2007a, p. 114), but which are contextually appropriate, not copy/pastes of other, previous or =E2=80=9Cbest=E2=80=9D practices (Hillier 2011, p. 508). (being cited from J. Hillier's ".. Strategic Spatial Planning" I mentioned in the previous message) Note: I have just realized that the 1st message of this thread of discussion --Stephen's one-- was sent by architecture-discuss@iab.org. Has been there a transfer from @ietf to @iab in managing the architecture-discuss list --while my accepted registration to architecture-discuss@ietf was in March 2019...? I make also BCC for this message to architecture-discuss@ietf.org... Regard, Guntur Wiseno Putra Pada Jumat, 03 Januari 2020, Guntur Wiseno Putra menulis: > Dear architecture-discuss > (Stephen and Others), > > When we think about "cyberspace", and also "real space", of communication= s > networks, of societies, and about engineering Internet architecturally, > this quotation concerning with "design" --as the term has so far been par= t > of this thread of discussion-- may be inspiring: > > > Navigating strategically across multiple planes requires practitioners to > sense and discern connections and patterns in what is taking place, to tr= y > to understand the underlying dynamics and interdependencies between > elements, to appreciate the diverse possibilities of what is happening an= d > what might happen, and to respond by designing actions which align with t= he > intentions and values of the agreed longer-term strategic trajectory (Ham= es > 2007a, p. 114), but which are contextually appropriate, not copy/pastes o= f > other, previous or =E2=80=9Cbest=E2=80=9D practices (Hillier 2011, p. 508= ). > > > (being cited from J. Hillier's ".. Strategic Spatial Planning" I mentione= d > in the previous message) > > > > Note: I have just realized that the 1st message of this thread of > discussion --Stephen's one-- was sent by architecture-discuss@iab.org. > Has been there a transfer from @ietf to @iab in managing the > architecture-discuss list --while my accepted registration to > architecture-discuss@ietf was in March 2019...? > > > Regard, > Guntur Wiseno Putra > > Pada Jumat, 03 Januari 2020, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> >> "Communication" may be understood as "society" and Internet is about >> networks of human communications... >> >> >> >> If it matters --and perhaps others: (1) UN's inititives for Sustainable >> Development Goals by supports of ICTs --including Internet & (2) >> engineering Internet's (architectural) resiliency (*), one closed enough= in >> J. Hillier's "Strategic Navigation: a Multiplanar Methodology for Strate= gic >> Spatial Planning" I mentioned above is "sustainability" referring to >> longer-term plans. >> >> >> "Multiplanar theory offers the potential for multiple plans (Hillier >> 2007, 2011) : >> >> =E2=80=93 several (or one collectively preferred) trajectories or =E2=80= =9Cvisions=E2=80=9D of >> the longer-term future, including concepts towards which human and >> non-human actants =E2=80=9Cdesire=E2=80=9D to navigate, such as sustaina= bility (Deleuze and >> Guattari=E2=80=99s planes of immanence) ; >> >> =E2=80=93 shorter-term, location-specific detailed plans and projects wi= th >> collaboratively determined tangible goals, for example, for city centre >> regeneration, provision of affordable housing and so on (Deleuze and >> Guattari=E2=80=99s planes of organisation)". >> (*) Apologize: I rendering "resilience" without accessing Stephen's >> document directly at github --there was an icon feature I could not acce= ss >> by clicking (the triple lines in up-right corner) and I wandered if ther= e >> were guidances to use the website... >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Kamis, 02 Januari 2020, Jeff Tantsura >> menulis: >> >>> While I share Lucy=E2=80=99 points, wrt connectivity of Outpost/similar >>> platforms back to the centralized DC=E2=80=98s - noone is reinventing t= he >>> wheel(there=E2=80=99s no value), outer encap is IP, do we really care = what=E2=80=99s >>> inside? >>> >>> Regards, >>> Jeff >>> >>> On Jan 1, 2020, at 12:11, Dan York wrote: >>> >>> =EF=BB=BF Brian, >>> >>> On Jan 1, 2020, at 2:12 PM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>> Cherry-picking from your interesing message: >>> >>> What if there winds up being a lack of diversity of paths through the >>> =E2=80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if i= ncreasingly traffic winds up >>> traveling through these proprietary global networks (to which you need = to >>> pay to connect and through that gain permission to send traffic - and o= nly >>> to that company=E2=80=99s platforms)? >>> >>> >>> Is this really new, from a technical viewpoint? >>> >>> >>> I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally wi= th these newer >>> networks to be able to fully answer that question. My knowledge comes = from >>> reading articles, going through tutorials, listening to talks / podcast= s, >>> and experimenting to the degree I can. But I don=E2=80=99t operate a ne= twork or >>> data center where I could join in to one (or more) of them=E2=80=A6 so = I have to >>> defer to those who have that kind of more direct experience. >>> >>> It reminds me very much of the early 1990s, when policy based BGP4 >>> routing first became a thing, and acceptable use policies were applied = by >>> NSFNET, ESNET, and their equivalents in Europe and Asia. That was all a= bout >>> money, of course, except that it was public money. >>> >>> >>> Interesting thought. I guess the difference I could see was that in >>> those days the networks were all using the same open standards-based >>> protocols, even with AUP=E2=80=99s being applied. They were all weaving= together a >>> common network fabric, from what I saw as a network user at that time. >>> >>> With these newer private networks, they may - or may not - be using the >>> same protocols that the public Internet is using. You may or may not kn= ow. >>> (And from a purely operational point-of-view, you may not care=E2=80=A6= a main >>> reason for using the private network is to have low-latency connectivit= y to >>> applications or content.) >>> >>> In at least one of the cases (Amazon Outposts), my understanding is tha= t >>> the company comes and installs hardware in your data center that then >>> connects your network back to Amazon=E2=80=99s AWS network. Is it all r= unning open >>> Internet protocols? Or are there proprietary protocols (or =E2=80=9Cext= ensions=E2=80=9D) >>> that are making the connectivity that much faster/better? (And I hones= tly >>> do not know.) Do you only have connectivity to their platform(s)? Or d= o >>> you have wider connectivity? >>> >>> To me, this is part of the question - do these newer, global, private >>> networks *increase* the overall resilience of the open, public Internet= ? Or >>> do they *decrease* the overall resilience of the open, public Internet?= Or >>> do they not really have any effect? Or is it too soon to tell? >>> >>> Interesting times, >>> Dan >>> >>> >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >>> --000000000000f386cb059b3d59cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss
(Stephen and Others),
When we think about "cyberspace", and also "= real space", of communications networks, of societies, and about engin= eering Internet architecturally, this quotation concerning with "desig= n" --as the term has so far been part of this thread of discussion-- m= ay be inspiring:


Navigating strategically across multiple planes requires pr= actitioners to sense and discern connections and patterns in what is taking= place, to try to understand the underlying dynamics and interdependencies = between elements, to appreciate the diverse possibilities of what is happen= ing and what might happen, and to respond by designing actions which align = with the intentions and values of the agreed longer-term strategic trajecto= ry (Hames 2007a, p.=C2=A0114), but which are contextually appropriate, not = copy/pastes of other, previous or =E2=80=9Cbest=E2=80=9D practices (Hillier= 2011, p.=C2=A0508).


(be= ing cited from J. Hillier's ".. Strategic Spatial Planning" I= mentioned in the previous message)



Note: I have just realized that the 1st message of this thr= ead of discussion --Stephen's one-- was sent by=C2=A0architecture-discuss@iab.or= g. Has been there a transfer from @ietf to @iab in managing the archite= cture-discuss list --while my accepted registration to architecture-discuss= @ietf was in March 2019...? I make also BCC for this message to architectur= e-discuss@ietf.org...


Regard,
=
Guntur Wiseno Putra


Pada Jumat, 03 Januari 20= 20, Guntur Wiseno Putra <gsenopu@gm= ail.com> menulis:
Dear architectur= e-discuss
(Stephen and Others),

When we think about = "cyberspace", and also "real space", of communications = networks, of societies, and about engineering Internet architecturally, thi= s quotation concerning with "design" --as the term has so far bee= n part of this thread of discussion-- may be inspiring:


Navigating strategic= ally across multiple planes requires practitioners to sense and discern con= nections and patterns in what is taking place, to try to understand the und= erlying dynamics and interdependencies between elements, to appreciate the = diverse possibilities of what is happening and what might happen, and to re= spond by designing actions which align with the intentions and values of th= e agreed longer-term strategic trajectory (Hames 2007a, p.=C2=A0114), but w= hich are contextually appropriate, not copy/pastes of other, previous or = =E2=80=9Cbest=E2=80=9D practices (Hillier 2011, p.=C2=A0508).


(being cited from J. Hillier's &q= uot;.. Strategic Spatial Planning" I mentioned in the previous message= )



Note: I have just = realized that the 1st message of this thread of discussion --Stephen's = one-- was sent by architecture-discuss@iab.org. Has been there a transfer from @= ietf to @iab in managing the architecture-discuss list --while my accepted = registration to architecture-discuss@ietf was in March 2019...?
<= br>

Regard,
Guntur Wiseno Putra

P= ada Jumat, 03 Januari 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

"Communication" may be understood as "society&qu= ot; and Internet is about networks of human communications...


If it matters --and perhaps other= s: (1) UN's inititives for Sustainable Development Goals by supports of= ICTs --including Internet & (2) engineering Internet's (architectu= ral) resiliency (*), one closed enough in J. Hillier's "Strategic = Navigation: a Multiplanar Methodology for Strategic Spatial Planning" = I mentioned above is "sustainability" referring to longer-term pl= ans.


= "Multiplanar theory offers the potential for multiple plans (Hillier 2= 007, 2011)=C2=A0:

=E2=80=93 several (or on= e collectively preferred) trajectories or =E2=80=9Cvisions=E2=80=9D of the = longer-term future, including concepts towards which human and non-human ac= tants =E2=80=9Cdesire=E2=80=9D to navigate, such as sustainability (Deleuze= and Guattari=E2=80=99s planes of immanence)=C2=A0;

=E2=80=93 shorter-term, location-specific detailed plans and proj= ects with collaboratively determined tangible goals, for example, for city = centre regeneration, provision of affordable housing and so on (Deleuze and= Guattari=E2=80=99s planes of organisation)".

(*) Apolog= ize: I rendering "resilience" without accessing Stephen's doc= ument directly at github --there was an icon feature I could not access by = clicking (the triple lines in up-right corner) and I wandered if there were= guidances to use the website...

Regard,
Guntur Wiseno Putra

Pada Kamis, 02 Januari 2020, Jeff Tantsura <= jefftant.ietf@= gmail.com> menulis:
While I share Lucy=E2=80=99 points, wrt connectivity of Outpost/similar= platforms back to the centralized DC=E2=80=98s - noone is reinventing the = wheel(there=E2=80=99s no value), outer encap is IP, =C2=A0do we really care= what=E2=80=99s inside?

Regards,
Jeff

On Jan 1, 2020, at 12:11, = Dan York <york@isoc.o= rg> wrote:

=EF=BB=BF Brian,

On Jan 1, 2020, at 2:12 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Cherry-picking from your interesing message:

What if there winds up being a lack of diversity of paths through the =E2= =80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if increasi= ngly traffic winds up traveling through these proprietary global networks (= to which you need to pay to connect and through that gain permission to send traffic - and only to that company=E2=80=99s platforms)?

Is this really new, from a technical viewpoint?

I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally w= ith these newer networks to be able to fully answer that question.=C2=A0 My= knowledge comes from reading articles, going through tutorials, listening = to talks / podcasts, and experimenting to the degree I can. But I don=E2=80=99t operate a network or data center where I could = join in to one (or more) of them=E2=80=A6 so I have to defer to those who h= ave that kind of more direct experience.

It reminds me very much of the early 1990s, when policy based BGP4 routing fi= rst became a thing, and acceptable use policies were applied by NSFNET, ESN= ET, and their equivalents in Europe and Asia. That was all about money, of = course, except that it was public money.

Interesting thought. I guess the difference I could see was that in th= ose days the networks were all using the same open standards-based protocol= s, even with AUP=E2=80=99s being applied. They were all weaving together a = common network fabric, from what I saw as a network user at that time.

With these newer private networks, they may - or may not - be using th= e same protocols that the public Internet is using. You may or may not know= . (And from a purely operational point-of-view, you may not care=E2=80=A6 a= main reason for using the private network is to have low-latency connectivity to applications or content.)= =C2=A0

In at least one of the cases (Amazon Outposts), my understanding is th= at the company comes and installs hardware in your data center that then co= nnects your network back to Amazon=E2=80=99s AWS network. Is it all running= open Internet protocols? Or are there proprietary protocols (or =E2=80=9Cextensions=E2=80=9D) that are mak= ing the connectivity that much faster/better? =C2=A0(And I honestly do not = know.) =C2=A0Do you only have connectivity to their platform(s)? Or do you = have wider connectivity?

To me, this is part of the question - do these newer, global, private = networks *increase* the overall resilience of the open, public Internet? Or= do they *decrease* the overall resilience of the open, public Internet? Or= do they not really have any effect? Or is it too soon to tell?

Interesting times,
Dan=C2=A0


_______________________________________________
= Architecture-discuss mailing list
Architecture-discuss@ietf.org=
https://www.ietf.org/mailman/listinfo/a= rchitecture-discuss
--000000000000f386cb059b3d59cb-- From nobody Fri Jan 3 06:44:59 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17495120046 for ; Fri, 3 Jan 2020 06:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 e4WG23nz8p_K for ; Fri, 3 Jan 2020 06:44:48 -0800 (PST) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46F8120077 for ; Fri, 3 Jan 2020 06:44:48 -0800 (PST) Received: by mail-oi1-x234.google.com with SMTP id d62so14308562oia.11 for ; Fri, 03 Jan 2020 06:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UbNoZAi8A8V0Ovxoujrza96c/yUNNiSNhYHrEnxN86U=; b=m8tLz3SUsHEsdOFSrmfuQE6I/E0LfhNgyg3sqd1zs4lsFc2bKKVRIF16QaI+mgWrTV OmCnZKHMptGb+vPXo8HJ19yZ/izQSVe5y1kB/NoXTYoyDTVT3eSMTRmAxtmMopoEydA+ 2rQTWYwMmD2MwYFYAImo8dFJsldoO8WqDQeSG7xgWyU815kNU6QHilgvI7+CFtEF0TJ+ Si6twh5ymE9EMKQZ4FF31IcA1eoRwMeGMzND6DBIc+FtazXq8mFWupq98Xe4jafMqwLG ZLc63AYGLTptmVIK3OUNTQW2x8IBypsRHZhKkRRD8hD3EHa/7P9fwvpgRuiIvaA60Q+d uEiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UbNoZAi8A8V0Ovxoujrza96c/yUNNiSNhYHrEnxN86U=; b=deMdawY+4lN8oJny+K6VUBI6w7YASPJJjMVyNdN9cyUKegaCFeReKp31TKnoyUvvKK 2TODBCjWRGV5gP8X+hROXD54wBNLSUNBZ8Thg01Jmu2Lv6B97INKI0I0wjanZaoED7f1 LiUcqY6DgHQWL1eDRqvoYegPzESyXOyZkFD8165wc9dnoK1FcrPbO1nAC52pPiFqVyHF tShUXhE2Ei09WybGUVhCkzL+vaz35gyE7aHvAsVrqWTUNe7qdhaYJmWDwIfX5KnKYHJV OFyH8Sey2xx+wsaaWB6+7yMwKw5360x5yzlGaiIs3QoMeFTH/ZbafZXr3k6Onu1WA4zI 8CHA== X-Gm-Message-State: APjAAAWnam5c822TAt0B5dH+sKxnFDpjF1Eowc+Cxe55H0fn0prHo22r oOEqozueSmucEj/NK9yfKOakQjRLXKhRtgfN9fQ= X-Google-Smtp-Source: APXvYqyswihg+jV64z7ar/ibqMOQ+c0GCQiGSyMjy/SK7dm1GLx9PB8Lf4bg3QG2YQLOc+Vt1v8Sb/C5aLKvuGwxg0c= X-Received: by 2002:a54:468b:: with SMTP id k11mr3806737oic.134.1578062687994; Fri, 03 Jan 2020 06:44:47 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Fri, 3 Jan 2020 06:44:47 -0800 (PST) In-Reply-To: References: <6D9C717F-B921-411B-8AAD-67FD47F79047@gmail.com> From: Guntur Wiseno Putra Date: Fri, 3 Jan 2020 21:44:47 +0700 Message-ID: To: Jeff Tantsura , "stephen.farrell@cs.tcd.ie" Cc: Dan York , "architecture-discuss@iab.org" , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f386cb059b3d59cb" Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 14:44:51 -0000 --000000000000f386cb059b3d59cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss (Stephen and Others), When we think about "cyberspace", and also "real space", of communications networks, of societies, and about engineering Internet architecturally, this quotation concerning with "design" --as the term has so far been part of this thread of discussion-- may be inspiring: Navigating strategically across multiple planes requires practitioners to sense and discern connections and patterns in what is taking place, to try to understand the underlying dynamics and interdependencies between elements, to appreciate the diverse possibilities of what is happening and what might happen, and to respond by designing actions which align with the intentions and values of the agreed longer-term strategic trajectory (Hames 2007a, p. 114), but which are contextually appropriate, not copy/pastes of other, previous or =E2=80=9Cbest=E2=80=9D practices (Hillier 2011, p. 508). (being cited from J. Hillier's ".. Strategic Spatial Planning" I mentioned in the previous message) Note: I have just realized that the 1st message of this thread of discussion --Stephen's one-- was sent by architecture-discuss@iab.org. Has been there a transfer from @ietf to @iab in managing the architecture-discuss list --while my accepted registration to architecture-discuss@ietf was in March 2019...? I make also BCC for this message to architecture-discuss@ietf.org... Regard, Guntur Wiseno Putra Pada Jumat, 03 Januari 2020, Guntur Wiseno Putra menulis: > Dear architecture-discuss > (Stephen and Others), > > When we think about "cyberspace", and also "real space", of communication= s > networks, of societies, and about engineering Internet architecturally, > this quotation concerning with "design" --as the term has so far been par= t > of this thread of discussion-- may be inspiring: > > > Navigating strategically across multiple planes requires practitioners to > sense and discern connections and patterns in what is taking place, to tr= y > to understand the underlying dynamics and interdependencies between > elements, to appreciate the diverse possibilities of what is happening an= d > what might happen, and to respond by designing actions which align with t= he > intentions and values of the agreed longer-term strategic trajectory (Ham= es > 2007a, p. 114), but which are contextually appropriate, not copy/pastes o= f > other, previous or =E2=80=9Cbest=E2=80=9D practices (Hillier 2011, p. 508= ). > > > (being cited from J. Hillier's ".. Strategic Spatial Planning" I mentione= d > in the previous message) > > > > Note: I have just realized that the 1st message of this thread of > discussion --Stephen's one-- was sent by architecture-discuss@iab.org. > Has been there a transfer from @ietf to @iab in managing the > architecture-discuss list --while my accepted registration to > architecture-discuss@ietf was in March 2019...? > > > Regard, > Guntur Wiseno Putra > > Pada Jumat, 03 Januari 2020, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> >> "Communication" may be understood as "society" and Internet is about >> networks of human communications... >> >> >> >> If it matters --and perhaps others: (1) UN's inititives for Sustainable >> Development Goals by supports of ICTs --including Internet & (2) >> engineering Internet's (architectural) resiliency (*), one closed enough= in >> J. Hillier's "Strategic Navigation: a Multiplanar Methodology for Strate= gic >> Spatial Planning" I mentioned above is "sustainability" referring to >> longer-term plans. >> >> >> "Multiplanar theory offers the potential for multiple plans (Hillier >> 2007, 2011) : >> >> =E2=80=93 several (or one collectively preferred) trajectories or =E2=80= =9Cvisions=E2=80=9D of >> the longer-term future, including concepts towards which human and >> non-human actants =E2=80=9Cdesire=E2=80=9D to navigate, such as sustaina= bility (Deleuze and >> Guattari=E2=80=99s planes of immanence) ; >> >> =E2=80=93 shorter-term, location-specific detailed plans and projects wi= th >> collaboratively determined tangible goals, for example, for city centre >> regeneration, provision of affordable housing and so on (Deleuze and >> Guattari=E2=80=99s planes of organisation)". >> (*) Apologize: I rendering "resilience" without accessing Stephen's >> document directly at github --there was an icon feature I could not acce= ss >> by clicking (the triple lines in up-right corner) and I wandered if ther= e >> were guidances to use the website... >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Kamis, 02 Januari 2020, Jeff Tantsura >> menulis: >> >>> While I share Lucy=E2=80=99 points, wrt connectivity of Outpost/similar >>> platforms back to the centralized DC=E2=80=98s - noone is reinventing t= he >>> wheel(there=E2=80=99s no value), outer encap is IP, do we really care = what=E2=80=99s >>> inside? >>> >>> Regards, >>> Jeff >>> >>> On Jan 1, 2020, at 12:11, Dan York wrote: >>> >>> =EF=BB=BF Brian, >>> >>> On Jan 1, 2020, at 2:12 PM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>> Cherry-picking from your interesing message: >>> >>> What if there winds up being a lack of diversity of paths through the >>> =E2=80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if i= ncreasingly traffic winds up >>> traveling through these proprietary global networks (to which you need = to >>> pay to connect and through that gain permission to send traffic - and o= nly >>> to that company=E2=80=99s platforms)? >>> >>> >>> Is this really new, from a technical viewpoint? >>> >>> >>> I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally wi= th these newer >>> networks to be able to fully answer that question. My knowledge comes = from >>> reading articles, going through tutorials, listening to talks / podcast= s, >>> and experimenting to the degree I can. But I don=E2=80=99t operate a ne= twork or >>> data center where I could join in to one (or more) of them=E2=80=A6 so = I have to >>> defer to those who have that kind of more direct experience. >>> >>> It reminds me very much of the early 1990s, when policy based BGP4 >>> routing first became a thing, and acceptable use policies were applied = by >>> NSFNET, ESNET, and their equivalents in Europe and Asia. That was all a= bout >>> money, of course, except that it was public money. >>> >>> >>> Interesting thought. I guess the difference I could see was that in >>> those days the networks were all using the same open standards-based >>> protocols, even with AUP=E2=80=99s being applied. They were all weaving= together a >>> common network fabric, from what I saw as a network user at that time. >>> >>> With these newer private networks, they may - or may not - be using the >>> same protocols that the public Internet is using. You may or may not kn= ow. >>> (And from a purely operational point-of-view, you may not care=E2=80=A6= a main >>> reason for using the private network is to have low-latency connectivit= y to >>> applications or content.) >>> >>> In at least one of the cases (Amazon Outposts), my understanding is tha= t >>> the company comes and installs hardware in your data center that then >>> connects your network back to Amazon=E2=80=99s AWS network. Is it all r= unning open >>> Internet protocols? Or are there proprietary protocols (or =E2=80=9Cext= ensions=E2=80=9D) >>> that are making the connectivity that much faster/better? (And I hones= tly >>> do not know.) Do you only have connectivity to their platform(s)? Or d= o >>> you have wider connectivity? >>> >>> To me, this is part of the question - do these newer, global, private >>> networks *increase* the overall resilience of the open, public Internet= ? Or >>> do they *decrease* the overall resilience of the open, public Internet?= Or >>> do they not really have any effect? Or is it too soon to tell? >>> >>> Interesting times, >>> Dan >>> >>> >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >>> --000000000000f386cb059b3d59cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss
(Stephen and Others),
When we think about "cyberspace", and also "= real space", of communications networks, of societies, and about engin= eering Internet architecturally, this quotation concerning with "desig= n" --as the term has so far been part of this thread of discussion-- m= ay be inspiring:


Navigating strategically across multiple planes requires pr= actitioners to sense and discern connections and patterns in what is taking= place, to try to understand the underlying dynamics and interdependencies = between elements, to appreciate the diverse possibilities of what is happen= ing and what might happen, and to respond by designing actions which align = with the intentions and values of the agreed longer-term strategic trajecto= ry (Hames 2007a, p.=C2=A0114), but which are contextually appropriate, not = copy/pastes of other, previous or =E2=80=9Cbest=E2=80=9D practices (Hillier= 2011, p.=C2=A0508).


(be= ing cited from J. Hillier's ".. Strategic Spatial Planning" I= mentioned in the previous message)



Note: I have just realized that the 1st message of this thr= ead of discussion --Stephen's one-- was sent by=C2=A0architecture-discuss@iab.or= g. Has been there a transfer from @ietf to @iab in managing the archite= cture-discuss list --while my accepted registration to architecture-discuss= @ietf was in March 2019...? I make also BCC for this message to architectur= e-discuss@ietf.org...


Regard,
=
Guntur Wiseno Putra


Pada Jumat, 03 Januari 20= 20, Guntur Wiseno Putra <gsenopu@gm= ail.com> menulis:
Dear architectur= e-discuss
(Stephen and Others),

When we think about = "cyberspace", and also "real space", of communications = networks, of societies, and about engineering Internet architecturally, thi= s quotation concerning with "design" --as the term has so far bee= n part of this thread of discussion-- may be inspiring:


Navigating strategic= ally across multiple planes requires practitioners to sense and discern con= nections and patterns in what is taking place, to try to understand the und= erlying dynamics and interdependencies between elements, to appreciate the = diverse possibilities of what is happening and what might happen, and to re= spond by designing actions which align with the intentions and values of th= e agreed longer-term strategic trajectory (Hames 2007a, p.=C2=A0114), but w= hich are contextually appropriate, not copy/pastes of other, previous or = =E2=80=9Cbest=E2=80=9D practices (Hillier 2011, p.=C2=A0508).


(being cited from J. Hillier's &q= uot;.. Strategic Spatial Planning" I mentioned in the previous message= )



Note: I have just = realized that the 1st message of this thread of discussion --Stephen's = one-- was sent by architecture-discuss@iab.org. Has been there a transfer from @= ietf to @iab in managing the architecture-discuss list --while my accepted = registration to architecture-discuss@ietf was in March 2019...?
<= br>

Regard,
Guntur Wiseno Putra

P= ada Jumat, 03 Januari 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

"Communication" may be understood as "society&qu= ot; and Internet is about networks of human communications...


If it matters --and perhaps other= s: (1) UN's inititives for Sustainable Development Goals by supports of= ICTs --including Internet & (2) engineering Internet's (architectu= ral) resiliency (*), one closed enough in J. Hillier's "Strategic = Navigation: a Multiplanar Methodology for Strategic Spatial Planning" = I mentioned above is "sustainability" referring to longer-term pl= ans.


= "Multiplanar theory offers the potential for multiple plans (Hillier 2= 007, 2011)=C2=A0:

=E2=80=93 several (or on= e collectively preferred) trajectories or =E2=80=9Cvisions=E2=80=9D of the = longer-term future, including concepts towards which human and non-human ac= tants =E2=80=9Cdesire=E2=80=9D to navigate, such as sustainability (Deleuze= and Guattari=E2=80=99s planes of immanence)=C2=A0;

=E2=80=93 shorter-term, location-specific detailed plans and proj= ects with collaboratively determined tangible goals, for example, for city = centre regeneration, provision of affordable housing and so on (Deleuze and= Guattari=E2=80=99s planes of organisation)".

(*) Apolog= ize: I rendering "resilience" without accessing Stephen's doc= ument directly at github --there was an icon feature I could not access by = clicking (the triple lines in up-right corner) and I wandered if there were= guidances to use the website...

Regard,
Guntur Wiseno Putra

Pada Kamis, 02 Januari 2020, Jeff Tantsura <= jefftant.ietf@= gmail.com> menulis:
While I share Lucy=E2=80=99 points, wrt connectivity of Outpost/similar= platforms back to the centralized DC=E2=80=98s - noone is reinventing the = wheel(there=E2=80=99s no value), outer encap is IP, =C2=A0do we really care= what=E2=80=99s inside?

Regards,
Jeff

On Jan 1, 2020, at 12:11, = Dan York <york@isoc.o= rg> wrote:

=EF=BB=BF Brian,

On Jan 1, 2020, at 2:12 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Cherry-picking from your interesing message:

What if there winds up being a lack of diversity of paths through the =E2= =80=9Copen=E2=80=9D and =E2=80=9Cpublic=E2=80=9D Internet? What if increasi= ngly traffic winds up traveling through these proprietary global networks (= to which you need to pay to connect and through that gain permission to send traffic - and only to that company=E2=80=99s platforms)?

Is this really new, from a technical viewpoint?

I=E2=80=99m not sure. I haven=E2=80=99t yet worked enough personally w= ith these newer networks to be able to fully answer that question.=C2=A0 My= knowledge comes from reading articles, going through tutorials, listening = to talks / podcasts, and experimenting to the degree I can. But I don=E2=80=99t operate a network or data center where I could = join in to one (or more) of them=E2=80=A6 so I have to defer to those who h= ave that kind of more direct experience.

It reminds me very much of the early 1990s, when policy based BGP4 routing fi= rst became a thing, and acceptable use policies were applied by NSFNET, ESN= ET, and their equivalents in Europe and Asia. That was all about money, of = course, except that it was public money.

Interesting thought. I guess the difference I could see was that in th= ose days the networks were all using the same open standards-based protocol= s, even with AUP=E2=80=99s being applied. They were all weaving together a = common network fabric, from what I saw as a network user at that time.

With these newer private networks, they may - or may not - be using th= e same protocols that the public Internet is using. You may or may not know= . (And from a purely operational point-of-view, you may not care=E2=80=A6 a= main reason for using the private network is to have low-latency connectivity to applications or content.)= =C2=A0

In at least one of the cases (Amazon Outposts), my understanding is th= at the company comes and installs hardware in your data center that then co= nnects your network back to Amazon=E2=80=99s AWS network. Is it all running= open Internet protocols? Or are there proprietary protocols (or =E2=80=9Cextensions=E2=80=9D) that are mak= ing the connectivity that much faster/better? =C2=A0(And I honestly do not = know.) =C2=A0Do you only have connectivity to their platform(s)? Or do you = have wider connectivity?

To me, this is part of the question - do these newer, global, private = networks *increase* the overall resilience of the open, public Internet? Or= do they *decrease* the overall resilience of the open, public Internet? Or= do they not really have any effect? Or is it too soon to tell?

Interesting times,
Dan=C2=A0


_______________________________________________
= Architecture-discuss mailing list
Architecture-discuss@ietf.org=
https://www.ietf.org/mailman/listinfo/a= rchitecture-discuss
--000000000000f386cb059b3d59cb-- From nobody Fri Jan 3 12:13:24 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE04F12004A for ; Fri, 3 Jan 2020 12:13:22 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 LUaCq8Cy6X2X for ; Fri, 3 Jan 2020 12:13:20 -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 D0EDF120045 for ; Fri, 3 Jan 2020 12:13:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4D8FFBE50 for ; Fri, 3 Jan 2020 20:13:17 +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 mgV9eZTzd7I4 for ; Fri, 3 Jan 2020 20:13:15 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2852FBE47 for ; Fri, 3 Jan 2020 20:13:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578082395; bh=unC8u3NmgEpRpJquW6hHLfky2Fl5xHcNLYkqGPfOVUM=; h=Subject:From:To:References:Date:In-Reply-To:From; b=x2MVJUFFjrrobx1Jo99m8K9P5tgpOK3iG0p8qCGsjllawCScythnQrTc97niRo/QB Ul/YZdWj2+o1lz7XqCMj+cyQgxja+J+UBtUSne1F2m0RhBfLRpAEjYKXOhrKn/a+vv Aswa4lwgftOS7sIBonExoww0/ogttNwKgdxsJJno= From: Stephen Farrell To: architecture-discuss@iab.org References: Message-ID: Date: Fri, 3 Jan 2020 20:13:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: [arch-d] my summary of resilience thread (Was: possible new IAB programme on Internet resilience) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 20:13:23 -0000 Hi all, Thanks for the ~70 messages on this over the holidays - I think that demonstrates a clear and thoughtful interest in the topic, which is great. One concern is that there were only a few people who said they'd do work (as opposed to comment on work), so we might not know for a while if this'll take off (and be useful) or not. I think that's ok, but feel free to send mail saying you would do work if that's the case. Meanwhile, my summary of the thread so far is below - please correct me if I've gotten anything badly wrong. (I'll offer this sub-thread to the IAB as a summary of the discussion - many people, IAB members included, are busy digesting things other than email over the holidays:-) Lastly, the initial idea for this originated from Terry Manderson and not from within the IAB - Terry told it to me over some beers at the very end of IETF105 in Montreal and I related it to the IAB, who were supportive. Now that we've seen that people don't think the idea is totally crazy, I think it's a good time to ack Terry for that. Terry's not responsible for any badness in charter-text of course - that'd be down to my or collective IAB ineptitude:-) Cheers, S. My notes on the thread [1] so far, roughly in order of how concrete the subsequent action seems (to me) to be. (1) Various folks noted that robustness is highly related to resilience, and that both may be terms-of-art for some people. I thought the message from Laurent [2] quoting Jeurgen Schoenwaelder captured that nicely. My guess is that a bit of charter editing to try embed that distinction may be worthwhile to avoid potential confusion. (2) Marc [3] suggested that another example (e.g. DDoS) might be useful to add so it's more clear that diversity is not a panacea. Seems reasonable. (3) Lucy [4] and others asked about sense#1 of the quoted definition of resilience. Seems to me the high level bit of the answer is "yes, that could be in scope" though of course work only happens when people volunteer to do it, (and then actually do it:-), so "in scope" is not at all the same as saying that something will happen. I think the "mostly" in the charter text is fine for that, but changing to "mostly, but not exclusively," would maybe be good. (As an aside, that sub-thread describing various things as "compression" is interesting, maybe even cute:-) (4) Toerless [5] asked about "membership" of the programme, raising both the issues of potential cliques and EAR related reasons why smokey-back-rooms are even less desirable today compared to a few years ago. I think that's one where the IAB should probably chat - it may indicate a need to change our conception of programmes and membership a bit, both to be more open and to handle those EAR-related issues. (Personally, I'd like if we could find a modus-operandi that's fully open, but that can also recognise a smaller set of folks as being active participants that the IAB think might usefully contribute.) (4) In a long sub-thread various people wondered whether the proposed programme would/could/should/should-not discuss various policy or layer-9 issues, such as centralisation, (that also had a bit of "#include "). I guess we'll have to see what the IAB make of that but FWIW, my take is that it generally makes sense for IAB programmes to not be limited to consideration of layers 1-8, but that no IAB programme ought be seen as the exclusive venue for any discussion, and nor does any IAB programme bind the IETF to anything. If the IAB agreed with that, I think that'd maybe mean that the technical consequences of such issues are in scope for discussion, but with two caveats: 1) we need to keep in mind that saying something is in-scope for a programme does not mean that anything will happen - as always that depends on someone doing (good) work on a topic, writing that up for others to discuss, and actually finishing the work and 2) there's still a preference for IETF work to be done in the IETF, so when/if anything in this space gets to be very concrete (i.e. protocol specific or BCP-like) it'd need to be decided in the IETF and will not be decided in/by this IAB programme. I don't think any charter-text change is needed for any of that. (5) There was a mention of things being done in ICANN, ITU or IGF rather than in an IAB programme. I don't think those ideas received much support that I could see, so don't think the charter needs changes for this. (In saying that, I'm not making any comment on whether or not it'd be a good or bad idea for those bodies to take up any related discussions.) [1] https://mailarchive.ietf.org/arch/msg/architecture-discuss/pZR9EYOhTIir0m_YDXQkUGPXwfk [2] https://mailarchive.ietf.org/arch/msg/architecture-discuss/iFQVe_1QdiT7JfQqxt9T_b3bp8w [3] https://mailarchive.ietf.org/arch/msg/architecture-discuss/pYATTKqH_Avi7D1tOGjz7XD1RHQ [4] https://mailarchive.ietf.org/arch/msg/architecture-discuss/qo4evXDIVVDhgNKQ0XzzSMsXwpM [5] https://mailarchive.ietf.org/arch/msg/architecture-discuss/6dqFdDrq8DXICx0hACx_rwob6nU From nobody Tue Jan 7 08:23:33 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5841200F3 for ; Tue, 7 Jan 2020 08:23:31 -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_HELO_NONE=0.001, 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 F4bAIVMdi28U for ; Tue, 7 Jan 2020 08:23:26 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C611200E0 for ; Tue, 7 Jan 2020 08:23:25 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id m26so143347ljc.13 for ; Tue, 07 Jan 2020 08:23:25 -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=aiqbK6di65Og3ZpZ8prF73kPkkKx9vfgIp5Kuh7Mmz8=; b=SvYWTliAFY8uL/qR8TXSPzyp6+bhI/u6+19L+XeTrkUvZ32j8CUokPy81pSYTz5Sk9 MEjpnKK5Ib7/XOfITEPNg74PQRqupE0tHwyVVdhIFiOhcXMWSU0t4cHXiFcydilboemd ImKNgl1mTQJrfmcwCDOlpsrCHhAnojUo2QHd/DalQ/G/f0WsYTsqwHtbBDtPh3vrSY/m 7uDBZDabaMsHzGiVW8kBuZ+q+e/zO6syIB835/aPBLGHINuZwkYCgL1UGoHIb1T43BxS +oQ+JdAlFpX6eVXG8EbkGeFho3Wt5cWZXUGpcPRB76TXEkOeUS7ALyCq9DxGY2T+OjV7 n0xg== 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=aiqbK6di65Og3ZpZ8prF73kPkkKx9vfgIp5Kuh7Mmz8=; b=BXPK3kVdpxJPY5TRaHEYmqv5TUFXumCYlxGawzrxlwR6rTsa0XAQN0+pdM1zqjuVml grDoAoND6A61W6VdYQpq7/dya/05uD3E+cXBo9D2pFlEeILxthvX2AB43wYq/UdSvYmQ r3uB6I3B/s6rk8LDndhPZ/bDVaEyjmWMpUPt0Jmc4avEsOnYshjuJnFAhyM3cyqWJN2i LeqQgAxEhel8sUdlMB2yH9yyaRHErim11QrQWXQwxgaACzvhP769/rVCKewSl+WRdV9f 7gXc7VjifHoCjCHb2vFlFNB1ZBGBcEJ+EBTLPlBYQ6Q7x22GO1FTq+i3vVm9nqDfd8rw eQxQ== X-Gm-Message-State: APjAAAX2HLjlIOMOzchRVo9W5YvfaTXRdx8hAzgGEzpkOavfX6eHtDml VJiQxkdCAsF6KWQ7as18qAMIWjy0vx35QlhBHgLOHc8w X-Google-Smtp-Source: APXvYqx7e9mR8sfhyuRnIwImFHH4G8j9lwnDI7F1NFGaSDstC9hnmZveBetvkijquI8bhD34PtuFpF+zMt7A8+i3iOQ= X-Received: by 2002:a2e:7005:: with SMTP id l5mr187756ljc.230.1578414203679; Tue, 07 Jan 2020 08:23:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 7 Jan 2020 10:22:56 -0600 Message-ID: To: Andrew Campling Cc: "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000eb39d0059b8f314a" Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:23:31 -0000 --000000000000eb39d0059b8f314a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I see that this topic is fragmenting into different threads, which is fine, so I'm not sure where I should insert this comment, but when we're talking about "centralized" and "decentralized", it's worth noting that "decentralized" fault tolerance can trip over implementation errors that are common across many devices owned or operated by a centralized entity. One of the largest SS7 outages in the US happened in 1990, when a one-line error that was present in a large number of switches caused >50 percent call failures across the entire ATT network. So, implementation diversity matters, not just decentralization. There's a nice write-up at http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/att_collapse.html, that matches my recollection of reports at the time. For me, the money quote was When the destination switch received the second of the two closely timed messages while it was still busy with the first (buffer not empty, line 7), the program should have dropped out of the if clause (line 7), processed the incoming message, and set up the pointers to the database (line 11). Instead, because of the break statement in the else clause (line 10), the program dropped out of the case statement entirely and began doing optional parameter work which overwrote the data (line 13). Error correction software detected the overwrite and shut the switch down while it could reset. Because every switch contained the same software, the resets cascaded down the network, incapacitating the system. Best, Spencer On Wed, Nov 13, 2019 at 12:57 AM Andrew Campling wrote: > "Martin Thomson" <*mt@lowentropy.net* > wrote on Tue, > 05 November 2019 22:58: > > The draft specifically calls out the notion of a single point of failure > being a problem. But my experience with centralized services is that the= y > aren't centralized in the fault tolerance sense. If I look at the big > services, that scale is only achieved with careful distributed systems > design. Name any modern service of even modest scale and you generally > find excellent fault tolerance. > > I thought that the document made it quite clear that it wasn=E2=80=99t > specifically referring to a single point of failure in a technical, fault > tolerance sense. In fact it made this clear by, for example, also > highlighting issues such as =E2=80=9Cadministrative or governance system = can become > weak through too much power or imagined power concentratred in one place= =E2=80=9D. > > Finally, I don't like the emphasis on DNS in this document. It only > serves to sensationalize. > > I thought that the reference to DNS was particularly helpful given one of > the potential side-effects of the push behind DoH could be to centralise > what is currently a highly decentralised system. I agree with the commen= t > in section 4 that =E2=80=9Cwhere such centralised points are created, the= y will > eventually fail, or they will be misused through surveillance or legal > actions regardless of the best efforts of the Internet community. The be= st > defense to data leak is to avoid creating that data store to begin with= =E2=80=9D. > > In addition, noting the references to RFC 1958 and RFC3935, I believe tha= t > it would be prudent for RFC8484 to be reviewed accordingly. > > > *Andrew* > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000eb39d0059b8f314a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I see that this top= ic is fragmenting into different threads, which is fine, so I'm not sur= e where I should insert this comment, but when we're talking about &quo= t;centralized" and "decentralized", it's worth noting th= at "decentralized" fault tolerance can trip over implementation e= rrors that are common across many devices owned or operated by a centralize= d entity. One of the largest SS7 outages in the US happened in 1990, when a= one-line error that was present in a large number of switches caused >5= 0 percent call failures across the entire ATT=C2=A0network.=C2=A0

So, implementation diversity matters, not just decentraliza= tion.=C2=A0

There's a nice write-up at=C2=A0http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/att_collapse.html, t= hat matches my recollection of reports at the time.=C2=A0

For me, the money quote was=C2=A0

When the destination switch received the= second of the two closely timed messages while it was still busy with the = first (buffer not empty, line 7), the program should have dropped out of th= e if cla= use (line 7), processed the incoming message, and set up the pointers to th= e database (line 11). Instead, because of the break statement in the else clause (l= ine 10), the program dropped out of the case statement entirely and began d= oing optional parameter work which overwrote the data (line 13). Error corr= ection software detected the overwrite and shut the switch down while it co= uld reset. Because every switch contained the same software, the resets cas= caded down the network, incapacitating the system.
=

Best,=C2=A0

Spencer

On Wed, Nov 13, 2019 at 12:57 AM Andrew Campling <andrew.campli= ng@419.consulting> wrote:
"Martin Thomson" <mt@lowentropy.net= > wrote on Tue, 05 November 2019 22:58:
=C2=A0
The draft specifically calls out the notio= n of a single point of failure being a problem.=C2=A0 But my experience wit= h centralized services is that they aren't centralized in the fault tol= erance sense.=C2=A0 If I look at the big services, that scale is only achieved with careful distributed systems design.=C2=A0 = Name any modern service of even modest scale and you generally find excelle= nt fault tolerance.
=C2=A0
I thought that the document made it quite clear that it wasn=E2=80=99t= specifically referring to a single point of failure in a technical, fault = tolerance sense.=C2=A0 In fact it made this clear by, for example, also hig= hlighting issues such as =E2=80=9Cadministrative or governance system can become weak through too much power or imagined power concentratr= ed in one place=E2=80=9D.=C2=A0
=C2=A0
Finally, I don't like the emphasis on = DNS in this document.=C2=A0 It only serves to sensationalize.
=C2=A0
I thought that the reference to DNS was particularly helpful given one= of the potential side-effects of the push behind DoH could be to centralis= e what is currently a highly decentralised system.=C2=A0 I agree with the c= omment in section 4 that =E2=80=9Cwhere such centralised points are created, they will eventually fail, or they will be = misused through surveillance or legal actions regardless of the best effort= s of the Internet community.=C2=A0 The best defense to data leak is to avoi= d creating that data store to begin with=E2=80=9D.=C2=A0
=C2=A0
In addition, noting the references to RFC 1958 and RFC3935, I believe = that it would be prudent for RFC8484 to be reviewed accordingly.=C2=A0
=C2=A0
=C2=A0
Andrew
=C2= =A0
=C2=A0
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arch= itecture-discuss
--000000000000eb39d0059b8f314a-- From nobody Tue Jan 7 08:53:13 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B723B12011B for ; Tue, 7 Jan 2020 08:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIivd8Qi77Ug for ; Tue, 7 Jan 2020 08:53:08 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5006120052 for ; Tue, 7 Jan 2020 08:53:08 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0745554802F; Tue, 7 Jan 2020 17:53:02 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 00608440059; Tue, 7 Jan 2020 17:53:01 +0100 (CET) Date: Tue, 7 Jan 2020 17:53:01 +0100 From: Toerless Eckert To: Spencer Dawkins at IETF Cc: Andrew Campling , "architecture-discuss@ietf.org" Message-ID: <20200107165301.GP8801@faui48f.informatik.uni-erlangen.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:53:11 -0000 On Tue, Jan 07, 2020 at 10:22:56AM -0600, Spencer Dawkins at IETF wrote: > I see that this topic is fragmenting into different threads, which is fine, > so I'm not sure where I should insert this comment, but when we're talking > about "centralized" and "decentralized", it's worth noting that > "decentralized" fault tolerance can trip over implementation errors that > are common across many devices owned or operated by a centralized entity. > One of the largest SS7 outages in the US happened in 1990, when a one-line > error that was present in a large number of switches caused >50 percent > call failures across the entire ATT network. Do i hear a slight criticism/concern about most networks current SDN == centralized intelligence & failure dependency ? Or is it just me ? > So, implementation diversity matters, not just decentralization. I think i had mentioned this already in the very beginning of the discussion. Btw: The historic often cited cause for as much as half-country wide Internet service outages in Germany was broken Radius/Accounting servers. Of course, when there was volume accounting you could not make money when those servers where broken, but even when the accounting models changed did these issues/dependencies persist if i remember correctly. In other words: design-wise you need to make sure you have distributed resilience up to lets say "cash-registers" that can still ensure service that still work under failure are also still accounted and charged for. Aka: distributed "routing" and other lower layer resilience is not sufficient in a commercial environment. And i can not remmber that DoD/Arpanet ever tried to fund research into these commercial issues. > There's a nice write-up at > http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/att_collapse.html, that > matches my recollection of reports at the time. > > For me, the money quote was > > When the destination switch received the second of the two closely timed > messages while it was still busy with the first (buffer not empty, line 7), > the program should have dropped out of the if clause (line 7), processed > the incoming message, and set up the pointers to the database (line 11). > Instead, because of the break statement in the else clause (line 10), the > program dropped out of the case statement entirely and began doing optional > parameter work which overwrote the data (line 13). Error correction > software detected the overwrite and shut the switch down while it could > reset. Because every switch contained the same software, the resets > cascaded down the network, incapacitating the system. Yes. I think the low-level analysis of newer incidents of this type can not be that easily explained anymore. A few years back, there was a big breakdown in google from too many conflicting automation systems if i remember correctly. Try to explain in detail how that worked... Cheers Toerless > Best, > > Spencer > > On Wed, Nov 13, 2019 at 12:57 AM Andrew Campling > wrote: > > > "Martin Thomson" <*mt@lowentropy.net* > wrote on Tue, > > 05 November 2019 22:58: > > > > The draft specifically calls out the notion of a single point of failure > > being a problem. But my experience with centralized services is that they > > aren't centralized in the fault tolerance sense. If I look at the big > > services, that scale is only achieved with careful distributed systems > > design. Name any modern service of even modest scale and you generally > > find excellent fault tolerance. > > > > I thought that the document made it quite clear that it wasn???t > > specifically referring to a single point of failure in a technical, fault > > tolerance sense. In fact it made this clear by, for example, also > > highlighting issues such as ???administrative or governance system can become > > weak through too much power or imagined power concentratred in one place???. > > > > Finally, I don't like the emphasis on DNS in this document. It only > > serves to sensationalize. > > > > I thought that the reference to DNS was particularly helpful given one of > > the potential side-effects of the push behind DoH could be to centralise > > what is currently a highly decentralised system. I agree with the comment > > in section 4 that ???where such centralised points are created, they will > > eventually fail, or they will be misused through surveillance or legal > > actions regardless of the best efforts of the Internet community. The best > > defense to data leak is to avoid creating that data store to begin with???. > > > > In addition, noting the references to RFC 1958 and RFC3935, I believe that > > it would be prudent for RFC8484 to be reviewed accordingly. > > > > > > *Andrew* > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Tue Jan 7 11:46:25 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652F4120113 for ; Tue, 7 Jan 2020 11:46:23 -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, SPF_HELO_NONE=0.001, 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 dOCtx_0J8Vn7 for ; Tue, 7 Jan 2020 11:46:21 -0800 (PST) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 D678F12010E for ; Tue, 7 Jan 2020 11:46:21 -0800 (PST) Received: by mail-pj1-x1030.google.com with SMTP id bg7so13236pjb.5 for ; Tue, 07 Jan 2020 11:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7o+xTgmC5aKfcOM1gNpzFhCEg0yvagB+ug93/7iEdxY=; b=QqaSHGvDHdePbX5QrESfMNQLHG5ojM82tTYXtSfJt37wD+U2MewW5zBiV5JNKS/LaW xIj+y8TilvAWIjMRfmqhkeI6uStyVLHS8/+V+L20iG94msloB1fgi3/Xo0zkRjIw5x0U advTSbkdZawNnBwnPltry4wA0XycTS26GQbfJScItC1PYqz7QKMCn8qjLFS1EoR/EFzM cA9204/5X30fQM6B7YE09+FT0iGuH+Z6lG8KeaWjavS6uQfmSchBG6Nr73TCU3GaJYJx 8JJ6YB9OcU22CR7patCJsUUsIMuav6NhoMf7wkkTePKoHMDBxYf/A4JVf4JFuGYxfZM0 ZkWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7o+xTgmC5aKfcOM1gNpzFhCEg0yvagB+ug93/7iEdxY=; b=OOQdQU0Ab0dQ2iBvDl/km52af5w/g3WYN+thWeglkQTPA4AMojBfEW9a2hIL7ktEnB 4OUdtOoswLBLAjFPoQjeWXErSMfFxbzj/1MS3tBG5sBplGZwtBCGEthYDqzs+X6MM6ac lim6ZSm33kRtJ3iyoA1D6sq5eKtyuzdbqRo1r3vAR5BuhwWd/HvOOi4hPIP/TZndKmpi uRSbe2Q2wvPUZPUq34lDiIw8ayHdt0Gj9GIIeRPJ5KtIMJUnbHVcOmDLIIp6sjWKmFYo kCc4McFz6hfN7hQwSuXPX/EJB2b1OH7exAsxNaQhrVX/1jipJ7053t2nlqLwfvfMMLQ/ vISw== X-Gm-Message-State: APjAAAWRtgHYEA2LjAVn2ypaKqm8YqPe61vTiv/YvbiZvlqyVrMt1nj5 ZcIaWnnKzJgOv8N6Qc1q5+YDwude X-Google-Smtp-Source: APXvYqwjxLOVzCGYJT0AKVlf8f5kz9e0J5kfNH7zEsfIrWAk/ieoD85oIjg8ei2DaXMcjiQZ1Xw4lg== X-Received: by 2002:a17:902:9882:: with SMTP id s2mr68374plp.156.1578426380986; Tue, 07 Jan 2020 11:46:20 -0800 (PST) Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id c17sm355928pfi.104.2020.01.07.11.46.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 11:46:20 -0800 (PST) To: Spencer Dawkins at IETF , Andrew Campling Cc: "architecture-discuss@ietf.org" References: From: Brian E Carpenter Message-ID: Date: Wed, 8 Jan 2020 08:46:18 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:46:23 -0000 On 08-Jan-20 05:22, Spencer Dawkins at IETF wrote: =2E.. > So, implementation diversity matters, not just decentralization.=C2=A0 Well yes, and this has been understood in high reliability design for at = least 30 years. Triple redundancy with diversity are the buzzwords. This = was very familiar to me when I worked in control systems, longer ago than= I wish to remember. Google will find you examples from the 1980s in comp= uterised nuclear reactor control systems**, and I think the same techniqu= e was used in spacecraft control from a very early stage. It's not quite clear how to enforce this via the IETF, beyond the multipl= e interoperable implementations of RFC6410. Brian ** e.g. https://inis.iaea.org/collection/NCLCollectionStore/_Public/17/06= 9/17069159.pdf From nobody Tue Jan 7 13:35:52 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0EB120143 for ; Tue, 7 Jan 2020 13:35:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 nPEI93jUiZa0 for ; Tue, 7 Jan 2020 13:35:48 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 A758412013C for ; Tue, 7 Jan 2020 13:35:48 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id x6so493175pfo.10 for ; Tue, 07 Jan 2020 13:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6+f0oA3l5dIyIu/ny/BOsfAnBBQPMXN6uQexmfxDVEg=; b=DGuMhXGC+IA4lR3x5ARY0m9uFXNTBMFCEec/Z6VCxILo7Xl37zZaHS8BNASWi6JLm9 2UxW/ngsL2hK6g9cqjipxxQ+dyW7g4cLNuMZXKSTp3ArSROAorr0mpQUHRIKlCDo78kI y3iRKpJLs/jXoRlRzdIcL1eGhC6/jtuzJOW4vWhjlO8dIykEmtciRQo0kCdbEH3xET6B k+QE32pIGCl5TIf4GgMaKd9+0FzIEfHWSynXGmrkLsJHzxLSGY6cBEKefGHuB8XSITgk TMHlS+UtOiCFqbVQz+zvB5tz9g3Kn0jkHCIdGKe+ZYZ7kAGJW/0Zc70SXC3hsqIQZH9E H69w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6+f0oA3l5dIyIu/ny/BOsfAnBBQPMXN6uQexmfxDVEg=; b=KYEuJrPdlPyX/IFQoN/hFeaaU7q1jGSnd0g5XL7UXAtO+yOgZI56VYT4uWr0CXNrJS Ft6XeZoNPzCPBYBAYmquEN2hbIgtOhjw9NJVDf5cvYIzbniGEH4jGqVbGqDmRp9/3C/o /0hSSd/m3AibTsC1s5DDMa3tu/JeCxQXPNWKyXmN868u06g6vVobKsl0yerLcWcIMj6z PPvnxzq3PQrOJdAh0y39C/11Ks/fyc/cm680rAVLmWq5yIK7BHuaOes2E9uZkBcdjJd+ pjwopUQbjwLqy0HREAHhxMEoZqCrrq0QQfx8/uYJHRBPTQuutnR1Zg2wFyPUSFKgGRlz 3bDg== X-Gm-Message-State: APjAAAUwZA4T1y3/ZGdBg8G/XjxR4TUOHj8ej/7ULFioqgbDlO/h/Qho Qy0QxxqiEMtcfgjfgsqPfdc= X-Google-Smtp-Source: APXvYqzVRwHP83sNN0W5gTlnDRFntHQhe6O8hPARr6e5KBISezsFJ1qQlXDJUapcok3VkcTgQyc64w== X-Received: by 2002:aa7:85d3:: with SMTP id z19mr1435925pfn.62.1578432948319; Tue, 07 Jan 2020 13:35:48 -0800 (PST) Received: from [172.22.74.163] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id p12sm540140pjo.5.2020.01.07.13.35.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 13:35:47 -0800 (PST) Sender: Tony Li From: tony.li@tony.li Message-Id: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_84B0947D-8616-49D7-A2DE-AF92CA2819CC" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 7 Jan 2020 13:35:45 -0800 In-Reply-To: Cc: Spencer Dawkins at IETF , Andrew Campling , "architecture-discuss@ietf.org" To: Brian E Carpenter References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 21:35:50 -0000 --Apple-Mail=_84B0947D-8616-49D7-A2DE-AF92CA2819CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > It's not quite clear how to enforce this via the IETF, beyond the = multiple interoperable implementations of RFC6410. The IETF has no police force, thankfully, so enforcement is out of = question anyway. The good news, however, is that Murphy does have a police force and has = demonstrated repeatedly that genetic diversity in a network is a Very = Good Thing. Several ISPs who have learned this lesson the hard way have dual planar = networks where plane 1 is all vendor A and plane 2 is all vendor B. Some others still have to learn this. One of the good things that might = come of this effort is to write this down. Tony --Apple-Mail=_84B0947D-8616-49D7-A2DE-AF92CA2819CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

It's not = quite clear how to enforce this via the IETF, beyond the multiple = interoperable implementations of = RFC6410.

The IETF has no police force, = thankfully, so enforcement is out of question anyway.

The good news, however, = is that Murphy does have a police force and has demonstrated repeatedly = that genetic diversity in a network is a Very Good Thing.

Several ISPs who have = learned this lesson the hard way have dual planar networks where plane 1 = is all vendor A and plane 2 is all vendor B.

Some others still have to learn this. =  One of the good things that might come of this effort is to write = this down.

Tony

= --Apple-Mail=_84B0947D-8616-49D7-A2DE-AF92CA2819CC-- From nobody Wed Jan 8 07:30:05 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6A312013D for ; Wed, 8 Jan 2020 07:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 0QSi_dmpDe8Q for ; Wed, 8 Jan 2020 07:30:02 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0329B12001A for ; Wed, 8 Jan 2020 07:30:02 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id u1so3744087ljk.7 for ; Wed, 08 Jan 2020 07:30:01 -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=xxjea1rxtcNRxwP43h1EfHFrhTIAyGpP09wQxvNMxOo=; b=FE4soxVQ8n/8zEDvCwRma7jhAF8MePYxnTVNitqJeAEL4i8F4p18ZE9oCQ3GB5yT71 yDXz0WNrZ3xVETWfr5h6w3A6e1skcCSGorfveCA1vxDO4U8Voh/v5VIQByUbMLBDJOi2 AV1kjBwgixFYrwpUCAnu6xLt8tL9wigT/5teMjuqrXWz0rbrLVU90IQ4c4v23ul/4GNz dpxeC7H+8ySXpiKcqGc4MGOFStrSUTCG1iGlYeZX73DC9pOLKOyEtPe2rSLmY3UQmF0N Y6rv4L6twFYexUDbFVJjEeKQY39g03havmMAN0e0e5FMIiiIzrBPvYoJkLF4luenJjwg aGVg== 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=xxjea1rxtcNRxwP43h1EfHFrhTIAyGpP09wQxvNMxOo=; b=sFbXJbFr2UtPQAiiMEwRqdCJumkROtQ9D5yzEBbdTCufzmT4wpdPocKnL3yIl7yvgs ebZRyGc/t0QSgRHPkjp/CX/afjlDeuhr7gPGLQIOU8giZgNEiNU8ZrF+33AK/J2BxL97 B1xAJK+Qj6Obapb3El/nDTcvY9uGmVSW3kCmPnqKjz3JWcLQ63CmCdph0gTwyPhgn3rc zg25ja5z4o6PKtlCsxMIEFAeeWG56/4ljHPQIqsORepxBlABKA/cV2KdTKSCmy2reB4T od67k4tjmZW9/lo2kG2IlhJVJgluRaDNb3xbPqYOgGromQOxrySJ4UXhbUzOLklK4V5f Xwog== X-Gm-Message-State: APjAAAXVyDIAe4tufhO0HEAyHKcFYcPxnWbtpgymY5TGLl7qPECUNYJ7 dllUA0ObdAII3CfqC7UzrxCjQ2BcXqTaquR6IbI= X-Google-Smtp-Source: APXvYqyKoEwzbv2Wap6t1ptMZSUJta8HGDoP1EJw39McNZPY7nCR0JOJPhRnQkOs8OY0F+iTwEXM8ITrnk37onIJTcw= X-Received: by 2002:a2e:9596:: with SMTP id w22mr3202846ljh.21.1578497400248; Wed, 08 Jan 2020 07:30:00 -0800 (PST) MIME-Version: 1.0 References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> In-Reply-To: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> From: Spencer Dawkins at IETF Date: Wed, 8 Jan 2020 09:29:31 -0600 Message-ID: To: tony.li@tony.li Cc: Brian E Carpenter , Andrew Campling , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d21d8b059ba29084" Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 15:30:04 -0000 --000000000000d21d8b059ba29084 Content-Type: text/plain; charset="UTF-8" Hi, Tony, On Tue, Jan 7, 2020 at 3:35 PM wrote: > > It's not quite clear how to enforce this via the IETF, beyond the multiple > interoperable implementations of RFC6410. > > > > The IETF has no police force, thankfully, so enforcement is out of > question anyway. > > The good news, however, is that Murphy does have a police force and has > demonstrated repeatedly that genetic diversity in a network is a Very Good > Thing. > > Several ISPs who have learned this lesson the hard way have dual planar > networks where plane 1 is all vendor A and plane 2 is all vendor B. > > Some others still have to learn this. One of the good things that might > come of this effort is to write this down. > Thanks - that was my hope :-) Spencer > Tony > --000000000000d21d8b059ba29084 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Tony,=C2=A0

On Tue, Jan 7, 2020 at 3:3= 5 PM <tony.li@tony.li> wrote:<= br>
It's not quite clear how to enfo= rce this via the IETF, beyond the multiple interoperable implementations of= RFC6410.


The IETF h= as no police force, thankfully, so enforcement is out of question anyway.

The good news, however, is that Murphy does have a = police force and has demonstrated repeatedly that genetic diversity in a ne= twork is a Very Good Thing.

Several ISPs who have = learned this lesson the hard way have dual planar networks where plane 1 is= all vendor A and plane 2 is all vendor B.

Some ot= hers still have to learn this.=C2=A0 One of the good things that might come= of this effort is to write this down.

Thanks - that was my hope :-)

Spencer
=C2=A0
Message-ID: <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 18:28:24 -0000 On Tue, Jan 07, 2020 at 01:35:45PM -0800, tony.li@tony.li wrote: > > > It's not quite clear how to enforce this via the IETF, beyond the multiple interoperable implementations of RFC6410. > > > The IETF has no police force, thankfully, so enforcement is out of question anyway. Indeed. And i have little opinions about enforcement other than "SEP - Somebody Else's Problem (not IETF)" Nevertheless: I think it would help for IETF to have something like "(protocol/solution/...) implementation compliance specifications" that would better help for external parties to vet/measure implementations/deployments against what the IETF envisions. And where to go from vetting/measured merics, i don't care (yet). > The good news, however, is that Murphy does have a police force and has demonstrated repeatedly that genetic diversity in a network is a Very Good Thing. Give or take the absence of competition due to the huge capital investment requirements. > Several ISPs who have learned this lesson the hard way have dual planar networks where plane 1 is all vendor A and plane 2 is all vendor B. *yawn*. Sorry, but coming from financal (services) networks, that had this since the 1990th, what you are saying now is like saying "Fred Flintstone now has upgraded to a color CRT TV". Btw: To stick to my theme of identifyin single points of failures: around 2010 or so, national financial service (in some unnamed country), had actually two separate planes. But built a single management plane. I think you can guess where this story goes. The fun part with the financial services community is how they can immediately come up with all type of financial loss number for every period of non-availability of network services (in units of millions of dollars). > Some others still have to learn this. One of the good things that might come of this effort is to write this down. One should also remember that the cost of dual-plane may be vastly different based on the density and structure of the country and underlying infra (fiber trunks, power supplies, etc..). Countries like USA and china are a lot more interesting/challenging than the typical european country. Cheers Toerless > Tony > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Wed Jan 8 10:53:07 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58160120072 for ; Wed, 8 Jan 2020 10:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, 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 M8soQBOe2jlN for ; Wed, 8 Jan 2020 10:53:04 -0800 (PST) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 52483120047 for ; Wed, 8 Jan 2020 10:53:04 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id d5so5003pjz.5 for ; Wed, 08 Jan 2020 10:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EYGidJM4rlw4hPuMowzxxszsWC11zVHFvIKgi2XFh9Y=; b=px/0OCKxBXMyOzMpKg5SAAcsQHIzRlj6wVMgfvn71PhLwRmmj55u+DQ93cNiY9w9VG wcD7o+YDoWiJB/FEjGX+R6CcvGgtTUyAF7A7lvrl8Tbv7MTUxvv/Qx8MJ1qW/PyhkLZQ QT8bqlRROCQP/MKmJ+cfPTnS1dDJOF/w2II8KERAJ0BD/8wBxBHYG6QKUjg6Hav977TI 7yFX9ibRiReufn9lZIha15FqdB30uHOiPYoh4oyX6o3FQIDqqluETmGLsUD/wj8Dh8h5 kCARUoq7q5jsre3Mk/8QBdpQRASlRbI+L8WjPbfYqqr6LF+kVNH+Q3ajDfEqnaiFB0ca 31kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=EYGidJM4rlw4hPuMowzxxszsWC11zVHFvIKgi2XFh9Y=; b=NIfcal8Kfj6jPsroAhZaXSASbNjZM2T+TU75GcC+bRQ4vzbwt0uOXZqyeRKg5T+3xM q24VnNggaB7N+66thN6zBchEEjia2Qi1CzpCxINICO+DeI4OKzIrd4yHn52EAHxgPLha kQyBXggysgo3Y0+X5OlFxkVxE2nvGJMbAl6Xr4QO1GNWIR//UsK5ker0Maq4ntxm79Vc AfFkzcDWw1pTYTfRQ8aqXSvLL1jmvEIuIcwPahzLbybJ2Ps2sSUS3q01F3iKe6KXBDIY dG3O+53iforYqT9aazjoo3pjIAmNTOItG/eNaimItgBTaBWuD6NaZ2rhQJWGz9ISslyn VOvA== X-Gm-Message-State: APjAAAUUvgz/dXHN1QcdkbAlROWjnqK9gn+c3lTLeaY1TpBE9Zmok19y lPb8YdUXwEGeR92/J9nkGnC0371r X-Google-Smtp-Source: APXvYqzrINybow0HeDJbY7O4/DEFKJKsNt3fNy7jmAX24gUvHdp1HqJ4LGOTWZP0Zl9FScFSJD/tyw== X-Received: by 2002:a17:902:8344:: with SMTP id z4mr7185852pln.41.1578509583712; Wed, 08 Jan 2020 10:53:03 -0800 (PST) Received: from [10.95.88.236] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id y203sm4694028pfb.65.2020.01.08.10.53.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 10:53:03 -0800 (PST) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: tony.li@tony.li In-Reply-To: <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> Date: Wed, 8 Jan 2020 10:53:01 -0800 Cc: Brian E Carpenter , Andrew Campling , "architecture-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 18:53:05 -0000 Hi Toerless, > Nevertheless: I think it would help for IETF to have something like > "(protocol/solution/...) implementation compliance specifications" > that would better help for external parties to vet/measure > implementations/deployments against what the IETF envisions. Nope. Been there and tried that. ISO has PIC statements that are pretty = much that for their standards. Did not help at all. What it does do is to encourage people to write =E2=80=9Cconformance = test suites=E2=80=9D. These then get sold to unsuspecting customers and = end-users. Unfortunately, the=20 quality of such suites is so low that you spend way, way, way more time = debugging the test suite and you never find bugs in your implementation. >> The good news, however, is that Murphy does have a police force and = has demonstrated repeatedly that genetic diversity in a network is a = Very Good Thing. >=20 > Give or take the absence of competition due to the huge capital > investment requirements. Customers who buy into single vendor architectures are inflicting vendor = lock on themselves. >> Several ISPs who have learned this lesson the hard way have dual = planar networks where plane 1 is all vendor A and plane 2 is all vendor = B. >=20 > *yawn*. Sorry, but coming from financal (services) networks, that had > this since the 1990th, what you are saying now is like saying > "Fred Flintstone now has upgraded to a color CRT TV=E2=80=9D. Good. Then I=E2=80=99ll say something more controversial: not everyone = does it that way, yet. >> Some others still have to learn this. One of the good things that = might come of this effort is to write this down. >=20 > One should also remember that the cost of dual-plane may be vastly > different based on the density and structure of the country and > underlying infra (fiber trunks, power supplies, etc..). Countries > like USA and china are a lot more interesting/challenging than the > typical european country. Redundancy always has costs. When it is needed it then pays dividends. = :-) Tony From nobody Wed Jan 8 11:26:04 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE9D12013B for ; Wed, 8 Jan 2020 11:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 GHd9YSFvbLGL for ; Wed, 8 Jan 2020 11:25:59 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865A31200CC for ; Wed, 8 Jan 2020 11:25:59 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A4770548048; Wed, 8 Jan 2020 20:25:53 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 97413440059; Wed, 8 Jan 2020 20:25:53 +0100 (CET) Date: Wed, 8 Jan 2020 20:25:53 +0100 From: Toerless Eckert To: tony.li@tony.li Cc: Brian E Carpenter , Andrew Campling , "architecture-discuss@ietf.org" Message-ID: <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 19:26:02 -0000 On Wed, Jan 08, 2020 at 10:53:01AM -0800, tony.li@tony.li wrote: > Nope. Been there and tried that. ISO has PIC statements that are pretty much that for their standards. Did not help at all. Yes, i was thinking of ISO PICS. But i lost track of those ISO standards since the 90th. I guess i would have to see a successfull and still currently used standard and how its PICS do or do not help. Just not alot of those ISO specs left in wide deployments, right. X.500 ? Maybe i can get more insight from the security community. > What it does do is to encourage people to write ???conformance test suites???. These then get sold to unsuspecting customers and end-users. Unfortunately, the quality of such suites is so low that you spend way, way, way more time debugging the test suite and you never find bugs in your implementation. This is just the worst possible outcome, and i am sure one can learn from those bad experiences. Just think of taking a more organized step towards being able to collect protocol implementation information from the industry. Right now every WG who wants to raise the level of an IETF protocol, e.g.: to(wards) full standard is coming up with a questionaire in an ad-hoc fashion (we're just doing this in Multicast for IGMP/MLD). > >> The good news, however, is that Murphy does have a police force and has demonstrated repeatedly that genetic diversity in a network is a Very Good Thing. > > > > Give or take the absence of competition due to the huge capital > > investment requirements. > > Customers who buy into single vendor architectures are inflicting vendor lock on themselves. My point was: If the only murphy you have is competitive pressure, it works not it there is only limited competition, such as a total of maybe no more than 3 competing national infrastructures. Remember my last mail where repeatedly half countries had no internet from one of those three providers four many hours because of single points of failures ? For years and years. So much for competitive pressure/Murphy. Besides, Trump has already concluded that you only need to eliminate one of the equipment vendors to solve the problem of secure, reliable national infrastructures. (not sure what the most fitting emoji is for this paragraph). > > *yawn*. Sorry, but coming from financal (services) networks, that had > > this since the 1990th, what you are saying now is like saying > > "Fred Flintstone now has upgraded to a color CRT TV???. > > Good. Then I???ll say something more controversial: not everyone does it that way, yet. See above. The best i think we (IETF) can do is to educate better about this by appropriate documents. Certainly some additional protocol work will result from that. I for once had simple slides 10 years ago how to fixup non-dual plane networks to be dual-plane. And maybe we can come up with questionaires to get better numbers from actual deployments (the PICS discussion). Figuring out ideas for a complete ecosystem of monetization and deployment between competition and regulation is better left for an ongoing bar-bof with emphasis on bar. > >> Some others still have to learn this. One of the good things that might come of this effort is to write this down. > > > > One should also remember that the cost of dual-plane may be vastly > > different based on the density and structure of the country and > > underlying infra (fiber trunks, power supplies, etc..). Countries > > like USA and china are a lot more interesting/challenging than the > > typical european country. > > Redundancy always has costs. When it is needed it then pays dividends. :-) Actually one of the interesting conclusions was that dual-plane in many cases is really free but deployments often just don't fully utilize it. Cheers Toerless > Tony From nobody Wed Jan 8 12:58:25 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5532712089D for ; Wed, 8 Jan 2020 12:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 10hIPVRgML8e for ; Wed, 8 Jan 2020 12:58:16 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346BB12083C for ; Wed, 8 Jan 2020 12:58:16 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id l9so3952530oii.5 for ; Wed, 08 Jan 2020 12:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=anOUw0MtoTyGeMNWhUMoFNWuPc+WBWYJMpTnvLVo1r4=; b=fz71ZxQgoaelifUlwsbuWzHNAOWWljtSP6xCmJ+CDDv3h59O8PJSSXP/XnV7YuVoko xZ/Me2jIasBh5PNXYZaNllNYsU7UR4BplBH4xQPMHpNdGBCgauR/omfQNZRcquEkgxZ1 Z/qQsRtB1RewhyR0yUU5HB6Jme26/lA5PQxk3LBOvdKZWMhj1vf5KUqzbPL4pVblTKvL b90IzMelehVHC/nv3YxYfzYm8Z/j6NiuEo0Kh+UdA8PRLyu9kbs8yEFeFUVfMfq9vBZJ 37+8ssAjCmEhAB24uDss52kG10HUF/S2RRsHf8WWDbLMJvxF7tz2hUgM9bml1VsGqXvf jxXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=anOUw0MtoTyGeMNWhUMoFNWuPc+WBWYJMpTnvLVo1r4=; b=RzW1FqgjYPQucQEQVdWzGJoVm4tbcds79o+dQgxI7wWgfSdHiLozk4CZZfqQ8HzHPt S7o7F3j8fL8Qme34MNPmEZgHao4T2aBaP/AopGerw+HUi9G995Csj4n1wQT5rvTixqXt fra8mc3ogaeJuY9K+50j7miUIgZxojOcNyh8rzI23zFWMnw0tXgi+FrMKiBXnxOc7Bw1 hf5xqNXkHvQxo5Rv/4j0q5AmUHkGsGfA3nMigVpn1zUNq2SYnun6/11jNaIfj/df54yu sItHqDTFXS8UX8hBSHXOm4eWO8lNkG8DaEMv0pUbjiMNH3KwxC+k6qm7WETRHGdYT+mN I3VA== X-Gm-Message-State: APjAAAU/6DyqqHd2N354H3N/Y8UT5XTO2BGXfLrlKk/F8mrd+mglRyGf p5uWapbxvTvEhTkxgpNFxI8= X-Google-Smtp-Source: APXvYqyfQc7pSsjGs8H/6bbDVTmPCvZ4JOvIb2BxVL9grPmLZBsHQFInVMXjL4sYqvHNNqR3ccqNVw== X-Received: by 2002:aca:1012:: with SMTP id 18mr395658oiq.151.1578517095378; Wed, 08 Jan 2020 12:58:15 -0800 (PST) Received: from [192.168.2.37] (108-205-201-113.lightspeed.sntcca.sbcglobal.net. [108.205.201.113]) by smtp.gmail.com with ESMTPSA id a24sm1457923oic.10.2020.01.08.12.58.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 12:58:14 -0800 (PST) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: tony.li@tony.li In-Reply-To: <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> Date: Wed, 8 Jan 2020 12:58:13 -0800 Cc: Brian E Carpenter , Andrew Campling , "architecture-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 20:58:24 -0000 > Yes, i was thinking of ISO PICS. But i lost track of those ISO = standards > since the 90th. I guess i would have to see a successfull and still > currently used standard and how its PICS do or do not help. Just > not alot of those ISO specs left in wide deployments, right. > X.500 ? Maybe i can get more insight from the security community. You need not go that far. Remember IS-IS? Still thriving. =20 And yes, my experience with PICs and test suites comes from that. >> What it does do is to encourage people to write ???conformance test = suites???. These then get sold to unsuspecting customers and end-users. = Unfortunately, the quality of such suites is so low that you spend way, = way, way more time debugging the test suite and you never find bugs in = your implementation. >=20 > This is just the worst possible outcome, and i am sure one can learn > from those bad experiences. Just think of taking a more organized > step towards being able to collect protocol implementation information > from the industry. Right now every WG who wants to raise the level of > an IETF protocol, e.g.: to(wards) full standard is coming up with a > questionaire in an ad-hoc fashion (we're just doing this in Multicast > for IGMP/MLD).=20 You can do that if you like, but the one proven, effective method is = interoperability testing. Running code trumps questionaires, conformance test suites, theory, and = mandate. > My point was: If the only murphy you have is competitive pressure, it = works not > it there is only limited competition, such as a total of maybe no > more than 3 competing national infrastructures.=20 And countries that stifle competition inflict vendor lock on themselves. > See above. The best i think we (IETF) can do is to educate better = about > this by appropriate documents. Certainly some additional protocol work > will result from that. I for once had simple slides 10 years ago how = to fixup > non-dual plane networks to be dual-plane. And maybe we can come up = with > questionaires to get better numbers from actual deployments (the > PICS discussion). The IETF=E2=80=99s job is not education. It does not work as the = education is not requested and not welcome. The IETF=E2=80=99s job is standards and it needs to = focus on that. > Figuring out ideas for a complete ecosystem of monetization and > deployment between competition and regulation is better left for > an ongoing bar-bof with emphasis on bar. I concur. Let=E2=80=99s stop fooling ourselves into thinking that = anything that the IAB/IETF writes has any impact on regulation or economics. > Actually one of the interesting conclusions was that dual-plane in > many cases is really free but deployments often just don't fully > utilize it. I=E2=80=99d agree that it=E2=80=99s close to free. If you accept that = you need a dual-plane approach for resiliency, then adding a second vendor to the mix is relatively easy. There=E2=80=99s = additional cost because of decreased=20 purchasing volume. There=E2=80=99s additional costs in management and = operations. However, as compared to the costs of an unnecessary outage, it=E2=80=99s = still trivial. Tony From nobody Wed Jan 8 13:49:58 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A3E1201EA for ; Wed, 8 Jan 2020 13:49:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=comcast.net 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 vWcIuzBJ21g8 for ; Wed, 8 Jan 2020 13:49:52 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 A18FE12003E for ; Wed, 8 Jan 2020 13:49:52 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-10v.sys.comcast.net with ESMTP id pIXGiO0edRHmIpJD5ipBti; Wed, 08 Jan 2020 21:49:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1578520191; bh=uME5qzaFTLhlYOXAMa6XL/H5U4cZaMWRBrkJWzCRHhI=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=sydpshLQ1qnvr07sIb6rSkJkKXCDqIERDch1Q0gcpqoxTebPd5dlFM0Z1IUCPXk1H e596pim3OsgDGylv1fgvXux3FH4QoF2wgX5jJUL5Gzfwbya0Yk0rEtWYyytzWTQEbT Wa4dg02NPU68mAfLfO3vH5FKTkKft35aby4WyLkIYFlfN+Me8an2vrrZKq0clkYwMS Kl9cnYXuC7+IBaJW9Q6YT5YxsgzV1kiIStn7yZb8GRbNNm2WWVoLdoNc9GwnJr5gHl yIHJtO80SXqE9RgGk4WLY3nLhDXyQsDtijejr1uH7ftfpkRzhhDb6HgDEc+vcnAab1 gcVwDWqpIolTQ== Received: from [10.0.1.32] ([24.34.101.155]) by resomta-ch2-20v.sys.comcast.net with ESMTPA id pJD2inb0i0kUupJD3i5Hcg; Wed, 08 Jan 2020 21:49:51 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedufedrvdehkedgudehudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeflohhhnhcuffgrhicuoehjvggrnhhjohhurhestghomhgtrghsthdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepvdegrdefgedruddtuddrudehheenucfrrghrrghmpehhvghloheplgdutddrtddruddrfedvngdpihhnvghtpedvgedrfeegrddutddurdduheehpdhmrghilhhfrhhomhepjhgvrghnjhhouhhrsegtohhmtggrshhtrdhnvghtpdhrtghpthhtohepthhonhihrdhlihesthhonhihrdhlihdprhgtphhtthhopehtthgvsegtshdrfhgruhdruggvpdhrtghpthhtoheprghnughrvgifrdgtrghmphhlihhnghesgeduledrtghonhhsuhhlthhinhhgpdhrtghpthhtoheprghrtghhihhtvggtthhurhgvqdguihhstghushhssehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: John Day In-Reply-To: Date: Wed, 8 Jan 2020 16:49:46 -0500 Cc: Toerless Eckert , Andrew Campling , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <265A560E-F07F-4CB8-8D5F-6077D1419CE5@comcast.net> References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> To: tony.li@tony.li X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 21:49:56 -0000 FWIW, there were also problems with keeping the test suites up-to-date = with the errata. Bugs could be fixed in the standards and incorporated = into implementations faster than the people developing the test suites = could keep up (or wanted to). Of course the fixes were in the = implementations before they were in the standards. And what was worse, = when pointed out to them that their test-suited didn=E2=80=99t conform = to the spec, they didn=E2=80=99t care. They still insisted they were = right. For some standards, it was possible to develop utilities that did a = specific function and used part of a standard to do that function but = didn=E2=80=99t need the rest of the standard. But the people running the = test suites couldn=E2=80=99t deal with it. If it didn=E2=80=99t = implement the entire protocol, it didn=E2=80=99t pass. The utility = couldn=E2=80=99t cause any of the rest of the protocol to be generated. = It conformed to the standard for everything it did. They were using the = standard as it had been intended.=20 But the testers were effectively bean-counters and totally stupid. Conformance fell under the ANSI committee I chaired and I remember = writing them (some military base in Arizona whose name I have thankfully = forgotten) nasty letters telling them to get their act together or get = out. They were doing more harm than good. Wish we had known about the = IS-IS issues as well to add to the list. One needs some way to test implementations before trying them live. But = one has to treat them (and it has to be instilled in the testers) that = the purpose is to help: obey Postel=E2=80=99s rule, find problems, and = then determine whether it is the tests, the =E2=80=99standard=E2=80=99 = or the new implementation that is at fault. And above all if it isn=E2=80=99= t externally visible, it is none of the tester=E2=80=99s business. Even = if there is =E2=80=98formal specification=E2=80=99, one can=E2=80=99t be = sure that a bug is in the prose, the formal spec, the tests, or the = implementation. They are all suspect. (Often formal specifications are = more complex than the code. And we know what that means!) Years before the standards issues arose, I did a survey of testing = methods for our own use. I expected to find that two or three were = pretty effective, pick one or two. What I found were 20 or 25 that were = all pretty effective and the advice was pick 2 or 3 and it didn=E2=80=99t = really matter which ones as long as they were different. (Not the result = I was looking for.) ;-) Take care, John > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote: >=20 >=20 >> Yes, i was thinking of ISO PICS. But i lost track of those ISO = standards >> since the 90th. I guess i would have to see a successfull and still >> currently used standard and how its PICS do or do not help. Just >> not alot of those ISO specs left in wide deployments, right. >> X.500 ? Maybe i can get more insight from the security community. >=20 >=20 > You need not go that far. Remember IS-IS? Still thriving. =20 >=20 > And yes, my experience with PICs and test suites comes from that. >=20 >=20 >>> What it does do is to encourage people to write ???conformance test = suites???. These then get sold to unsuspecting customers and end-users. = Unfortunately, the quality of such suites is so low that you spend way, = way, way more time debugging the test suite and you never find bugs in = your implementation. >>=20 >> This is just the worst possible outcome, and i am sure one can learn >> from those bad experiences. Just think of taking a more organized >> step towards being able to collect protocol implementation = information >> from the industry. Right now every WG who wants to raise the level of >> an IETF protocol, e.g.: to(wards) full standard is coming up with a >> questionaire in an ad-hoc fashion (we're just doing this in Multicast >> for IGMP/MLD).=20 >=20 >=20 > You can do that if you like, but the one proven, effective method is = interoperability testing. >=20 > Running code trumps questionaires, conformance test suites, theory, = and mandate. >=20 >=20 >> My point was: If the only murphy you have is competitive pressure, it = works not >> it there is only limited competition, such as a total of maybe no >> more than 3 competing national infrastructures.=20 >=20 >=20 > And countries that stifle competition inflict vendor lock on = themselves. >=20 >=20 >> See above. The best i think we (IETF) can do is to educate better = about >> this by appropriate documents. Certainly some additional protocol = work >> will result from that. I for once had simple slides 10 years ago how = to fixup >> non-dual plane networks to be dual-plane. And maybe we can come up = with >> questionaires to get better numbers from actual deployments (the >> PICS discussion). >=20 >=20 > The IETF=E2=80=99s job is not education. It does not work as the = education is not requested > and not welcome. The IETF=E2=80=99s job is standards and it needs to = focus on that. >=20 >=20 >> Figuring out ideas for a complete ecosystem of monetization and >> deployment between competition and regulation is better left for >> an ongoing bar-bof with emphasis on bar. >=20 >=20 > I concur. Let=E2=80=99s stop fooling ourselves into thinking that = anything that the IAB/IETF writes has any impact > on regulation or economics. >=20 >=20 >> Actually one of the interesting conclusions was that dual-plane in >> many cases is really free but deployments often just don't fully >> utilize it. >=20 >=20 > I=E2=80=99d agree that it=E2=80=99s close to free. If you accept that = you need a dual-plane approach for resiliency, then > adding a second vendor to the mix is relatively easy. There=E2=80=99s = additional cost because of decreased=20 > purchasing volume. There=E2=80=99s additional costs in management and = operations. >=20 > However, as compared to the costs of an unnecessary outage, it=E2=80=99s= still trivial. >=20 > Tony >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Wed Jan 8 15:15:01 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5ADF12022A; Wed, 8 Jan 2020 15:14:59 -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, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=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 q7JpPBAEafFy; Wed, 8 Jan 2020 15:14:58 -0800 (PST) Received: from thornhill.mtv.corp.google.com (unknown [IPv6:2620:0:1000:1111:c03e:1e8:50bf:2fe4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id E0D6112022E; Wed, 8 Jan 2020 15:14:57 -0800 (PST) To: ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org From: IAB Chair Message-ID: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Date: Wed, 8 Jan 2020 15:14:57 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------BF796EEED930DB9A884FBDF1" Content-Language: en-US Archived-At: Subject: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 23:15:00 -0000 This is a multi-part message in MIME format. --------------BF796EEED930DB9A884FBDF1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Colleagues, The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please send them toiab@iab.org . best regards, Ted Hardie for the IAB INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY This policy covers the nomcom-selected Internet Architecture Board (IAB) members and ex-officio members (collectively, “Covered Individuals”). This policy has no impact on any other participants in IAB activities, for instance liaisons to and from the IAB or IAB program members. In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be—or may appear to be—incompatible or in conflict with a Covered Individual’s personal interests (including interests of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter. The IAB does not directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology. Covered Individuals shall not use the IAB’s resources or decisions as a means for personal or third-party gain. Disclosure of Actual or Potential Conflicts The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates. In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion. The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms: * A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees. * A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. * Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult. Disclosure Transparency A person's recusal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private. --------------BF796EEED930DB9A884FBDF1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please send them to iab@iab.org.

best regards,

Ted Hardie
for the IAB

INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY

This policy covers the nomcom-selected Internet Architecture Board (IAB) members and ex-officio members (collectively, “Covered Individuals”). This policy has no impact on any other participants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be—or may appear to be—incompatible or in conflict with a Covered Individual’s personal interests (including interests of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals shall not use the IAB’s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's recusal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.


--------------BF796EEED930DB9A884FBDF1-- From nobody Wed Jan 8 17:23:34 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E45120020 for ; Wed, 8 Jan 2020 17:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 t3o4BM3bKSp3 for ; Wed, 8 Jan 2020 17:23:30 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA7F12004F for ; Wed, 8 Jan 2020 17:23:30 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ipMXg-000D4S-BB; Wed, 08 Jan 2020 20:23:20 -0500 Date: Wed, 08 Jan 2020 20:23:14 -0500 From: John C Klensin To: John Day , tony.li@tony.li cc: Andrew Campling , Toerless Eckert , architecture-discuss@ietf.org Message-ID: In-Reply-To: <265A560E-F07F-4CB8-8D5F-6077D1419CE5@comcast.net> References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> <265A560E-F07F-4CB8-8D5F-6077D1419CE5@comcast.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 01:23:34 -0000 Let me add three small things to John's and Tony's observations and experience, partially from other areas of standards... * When there is a test suite that is more or less official (typically by designation by the SDO that created the standard, some related body, or just because "everyone" is using it) , there is considerably risk of its becoming a substitute for the standard. In other words, "conform to the standard" turns out, in practice, to mean "conform to the test suite" even, or especially, if the two don't quite align. John's suggestion of having a collection of them that are developed independently and picking 2 or 3 can mitigate that problem significantly but, if the chosen test suites are completely consistent with each other, then one is, de facto, back to a de facto official test suite. * Empirical experience that parallels the above and observations others made are the reason why the Internet was build rather more on reference implementations (good examples but not intrinsically authoritative) and interoperability testing (if problems show up, they are issues to be investigated, understood, and repaired, not the source of extended debates about who was most correct or most conforming), rather than test suites. * John's observation about applying the robustness ("Postel's") principle to systematic testing has proven very useful and is something we should keep in mind when people, especially people with less experience, claim that principle has outlived its usefulness. * While the PICS effort, and "PICS proforma"s, are good candidates for good examples in this area for networking-related standards, they differ from many other examples because they had the character of what we would call Applicability Statements that were often expressed in test suites, i.e., specifications of what constituted conformance s.t., if something was not in the PICS, it didn't count. In broader IT standards areas, the all-time poster child was probably the Ada programming language and there is a case to be made that its longevity and brilliant success when not mandated by law or contracts was largely a result of implementations designed around passing the test suite rather than, e.g., actually working. Neither examples I think the IETF should follow unless with have a death (or at least obscurity) wish. john --On Wednesday, January 8, 2020 16:49 -0500 John Day wrote: > FWIW, there were also problems with keeping the test suites > up-to-date with the errata. Bugs could be fixed in the > standards and incorporated into implementations faster than > the people developing the test suites could keep up (or wanted > to). Of course the fixes were in the implementations before > they were in the standards. And what was worse, when pointed > out to them that their test-suited didn't conform to the > spec, they didn't care. They still insisted they were right. > > For some standards, it was possible to develop utilities that > did a specific function and used part of a standard to do that > function but didn't need the rest of the standard. But the > people running the test suites couldn't deal with it. If it > didn't implement the entire protocol, it didn't pass. The > utility couldn't cause any of the rest of the protocol to be > generated. It conformed to the standard for everything it did. > They were using the standard as it had been intended. > > But the testers were effectively bean-counters and totally > stupid. > > Conformance fell under the ANSI committee I chaired and I > remember writing them (some military base in Arizona whose > name I have thankfully forgotten) nasty letters telling them > to get their act together or get out. They were doing more > harm than good. Wish we had known about the IS-IS issues as > well to add to the list. > > One needs some way to test implementations before trying them > live. But one has to treat them (and it has to be instilled > in the testers) that the purpose is to help: obey Postel's > rule, find problems, and then determine whether it is the > tests, the 'standard' or the new implementation that is at > fault. And above all if it isn't externally visible, it is > none of the tester's business. Even if there is 'formal > specification', one can't be sure that a bug is in the > prose, the formal spec, the tests, or the implementation. They > are all suspect. (Often formal specifications are more complex > than the code. And we know what that means!) > > Years before the standards issues arose, I did a survey of > testing methods for our own use. I expected to find that two > or three were pretty effective, pick one or two. What I found > were 20 or 25 that were all pretty effective and the advice > was pick 2 or 3 and it didn't really matter which ones as > long as they were different. (Not the result I was looking > for.) ;-) > > Take care, > John > >> On Jan 8, 2020, at 15:58, tony.li@tony.li wrote: >> >> >>> Yes, i was thinking of ISO PICS. But i lost track of those >>> ISO standards since the 90th. I guess i would have to see a >>> successfull and still currently used standard and how its >>> PICS do or do not help. Just not alot of those ISO specs >>> left in wide deployments, right. X.500 ? Maybe i can get >>> more insight from the security community. >> >> >> You need not go that far. Remember IS-IS? Still thriving. >> >> And yes, my experience with PICs and test suites comes from >> that. >> >> >>>> What it does do is to encourage people to write >>>> ???conformance test suites???. These then get sold to >>>> unsuspecting customers and end-users. Unfortunately, the >>>> quality of such suites is so low that you spend way, way, >>>> way more time debugging the test suite and you never find >>>> bugs in your implementation. >>> >>> This is just the worst possible outcome, and i am sure one >>> can learn from those bad experiences. Just think of taking a >>> more organized step towards being able to collect protocol >>> implementation information from the industry. Right now >>> every WG who wants to raise the level of an IETF protocol, >>> e.g.: to(wards) full standard is coming up with a >>> questionaire in an ad-hoc fashion (we're just doing this in >>> Multicast for IGMP/MLD). >> >> >> You can do that if you like, but the one proven, effective >> method is interoperability testing. >> >> Running code trumps questionaires, conformance test suites, >> theory, and mandate. >> >> >>> My point was: If the only murphy you have is competitive >>> pressure, it works not it there is only limited competition, >>> such as a total of maybe no more than 3 competing national >>> infrastructures. >> >> >> And countries that stifle competition inflict vendor lock on >> themselves. >> >> >>> See above. The best i think we (IETF) can do is to educate >>> better about this by appropriate documents. Certainly some >>> additional protocol work will result from that. I for once >>> had simple slides 10 years ago how to fixup non-dual plane >>> networks to be dual-plane. And maybe we can come up with >>> questionaires to get better numbers from actual deployments >>> (the PICS discussion). >> >> >> The IETF's job is not education. It does not work as the >> education is not requested and not welcome. The IETF's job >> is standards and it needs to focus on that. >> >> >>> Figuring out ideas for a complete ecosystem of monetization >>> and deployment between competition and regulation is better >>> left for an ongoing bar-bof with emphasis on bar. >> >> >> I concur. Let's stop fooling ourselves into thinking that >> anything that the IAB/IETF writes has any impact on >> regulation or economics. >> >> >>> Actually one of the interesting conclusions was that >>> dual-plane in many cases is really free but deployments >>> often just don't fully utilize it. >> >> >> I'd agree that it's close to free. If you accept that >> you need a dual-plane approach for resiliency, then adding a >> second vendor to the mix is relatively easy. There's >> additional cost because of decreased purchasing volume. >> There's additional costs in management and operations. >> >> However, as compared to the costs of an unnecessary outage, >> it's still trivial. >> >> Tony >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Thu Jan 9 00:33:07 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A04120849; Thu, 9 Jan 2020 00:33:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=elandsys.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 TJL4pqgruc9I; Thu, 9 Jan 2020 00:33:04 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9EF120819; Thu, 9 Jan 2020 00:33:04 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.142.251]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 0098Wng9001772 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2020 00:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1578558783; x=1578645183; i=@elandsys.com; bh=onQ3z9wdzkbJ19P+zmEAl/GUxNJ9O7Kd+DPveMAtTNA=; h=Date:To:From:Subject:In-Reply-To:References; b=nVhrp0JGcS4ijVKTcPRU24GZGUczgAD/u2gTFDy4lGlJJdBX/k5VVqDUJBKPXgWdE CiYBFjagKZWav18+4//Poy0u/872XEpEeSDLkdF9hLWtlrnvoTpGbJD4vGPIJrufQp /AQewxTv0x2LwIiXo/zuVNxsWLuv+Bd+x9Zj8+fk= Message-Id: <6.2.5.6.2.20200108213623.144cb518@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 09 Jan 2020 00:22:51 -0800 To: architecture-discuss@ietf.org, iab@iab.org From: S Moonesamy In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 08:33:05 -0000 Hello, At 03:14 PM 08-01-2020, IAB Chair wrote: >In carrying out their IAB role, Covered=20 >Individuals must act in the best interest of the=20 >Internet community. Occasionally this duty may=20 >be=97or may appear to be=97incompatible or in IThe "best interest of the Internet community"=20 can be quite subjective. I'll use the recent=20 "open letter" as an example. I would probably=20 decline to sign it. That does not mean that a=20 person who signs it would be acting against the=20 best interest of the Internet community. >conflict with a a Covered Individual's personal=20 >interests (including interests of their family=20 >members), or the interests of an organization of=20 >which the Covered Individual is an employee,=20 >director, owner, or otherwise has business or=20 >financial interest. If a Covered Individual has=20 >a conflict of interest for whatever reason, that=20 >individual must avoid participating in the work=20 >of the IAB that touches on the related matter. The proposed policy may also conflict with the=20 IAB Charter as it states that the members shall=20 owe no fiduciary duty of loyalty or care to=20 ... One of the members of the IAB is a director=20 of the IETF Administration LLC. Does that create=20 a situation where the person could be in conflict [1]? >The IAB does not directly deal with matters=20 >relating to contracts or finance. The IAB does,=20 >however, have a role in personnel decisions, and=20 >its decisions and outputs have a potential to=20 >indirectly affect contracts within the IETF=20 >system. IAB's technical decisions and outputs=20 >have also a potential to impact both work=20 >elsewhere in the IETF and businesses that employ=20 >or develop Internet technology. The above is related to the IETF Administration=20 LLC instead of the IETF. It could be interpreted=20 as meaning that the IAB can exercise undue=20 influence on the decisions of the IETF Administration LLC. >Covered Individuals shall not use the IAB's=20 >resources or decisions as a means for personal or third-party gain. > >Disclosure of Actual or Potential Conflicts > >The IAB requires that all Covered Individuals=20 >disclose their main employment, sponsorship,=20 >consulting customer, or other sources of income=20 >when joining the IAB or whenever there are updates. > >In addition, when a topic is discussed at the=20 >IAB, the Covered Individuals are required to=20 >promptly disclose if that topic constitutes a=20 >perceived or potential conflict of interest.=20 >Once disclosed, Covered Individuals may recuse=20 >from participation in discussions or decisions at their discretion. What if the individual decides that he/she does=20 not need to recuse himself/herself from the decision-making process? If I am not mistaken, the term used in such=20 policies is "material interest" [2]. My=20 understanding of the draft is that the "material=20 interests" are covered under the "Activity on the=20 IAB involves discussion and decisions regarding=20 ..." paragraph. Is that correct? Regards, S. Moonesamy 1. It is dependent on the interpretation of the text. 2. The interest is not only considered in terms of contracts.=20 From nobody Thu Jan 9 01:45:47 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B44D12010E for ; Thu, 9 Jan 2020 01:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGVWlIGUwqJO for ; Thu, 9 Jan 2020 01:45:43 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA8E120105 for ; Thu, 9 Jan 2020 01:45:43 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7C26854804B; Thu, 9 Jan 2020 10:45:37 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6B8BC440059; Thu, 9 Jan 2020 10:45:37 +0100 (CET) Date: Thu, 9 Jan 2020 10:45:37 +0100 From: Toerless Eckert To: John Day Cc: tony.li@tony.li, Andrew Campling , architecture-discuss@ietf.org Message-ID: <20200109094537.GY8801@faui48f.informatik.uni-erlangen.de> References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> <265A560E-F07F-4CB8-8D5F-6077D1419CE5@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <265A560E-F07F-4CB8-8D5F-6077D1419CE5@comcast.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 09:45:45 -0000 Good insights about the outcome of PICS. To clarify, i am primarily interested to see if we can do something to better support static network planning and protocol evolution. Something which is more a self-declaration than a (broken) conformance suite "verified" testing result. Something which always must be followed by appropriate testing (interop, deployment) depending on the goal. But something that can help to faster get to that step. Something to to help avoid horrenduously repetitive RFP questions by poor customers (does your IETF FOO protocol on your product support the optional BAR feature). One could think of another axis of information in our yang models, a subset of "implementation defined" behavior whose values can be statically exposed without access to a live system and hence be published and then used in netork planning for example (or auto-collection by a curious WG trying to progress some standard to full internet ;-)). I was interested in the type of information i remember to have seen in the 90th in PICS, i am horrified about the process i learn about it here in te thread ;-) Cheers Toerless On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote: > FWIW, there were also problems with keeping the test suites up-to-date with the errata. Bugs could be fixed in the standards and incorporated into implementations faster than the people developing the test suites could keep up (or wanted to). Of course the fixes were in the implementations before they were in the standards. And what was worse, when pointed out to them that their test-suited didn???t conform to the spec, they didn???t care. They still insisted they were right. > > For some standards, it was possible to develop utilities that did a specific function and used part of a standard to do that function but didn???t need the rest of the standard. But the people running the test suites couldn???t deal with it. If it didn???t implement the entire protocol, it didn???t pass. The utility couldn???t cause any of the rest of the protocol to be generated. It conformed to the standard for everything it did. They were using the standard as it had been intended. > > But the testers were effectively bean-counters and totally stupid. > > Conformance fell under the ANSI committee I chaired and I remember writing them (some military base in Arizona whose name I have thankfully forgotten) nasty letters telling them to get their act together or get out. They were doing more harm than good. Wish we had known about the IS-IS issues as well to add to the list. > > One needs some way to test implementations before trying them live. But one has to treat them (and it has to be instilled in the testers) that the purpose is to help: obey Postel???s rule, find problems, and then determine whether it is the tests, the ???standard??? or the new implementation that is at fault. And above all if it isn???t externally visible, it is none of the tester???s business. Even if there is ???formal specification???, one can???t be sure that a bug is in the prose, the formal spec, the tests, or the implementation. They are all suspect. (Often formal specifications are more complex than the code. And we know what that means!) > > Years before the standards issues arose, I did a survey of testing methods for our own use. I expected to find that two or three were pretty effective, pick one or two. What I found were 20 or 25 that were all pretty effective and the advice was pick 2 or 3 and it didn???t really matter which ones as long as they were different. (Not the result I was looking for.) ;-) > > Take care, > John > > > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote: > > > > > >> Yes, i was thinking of ISO PICS. But i lost track of those ISO standards > >> since the 90th. I guess i would have to see a successfull and still > >> currently used standard and how its PICS do or do not help. Just > >> not alot of those ISO specs left in wide deployments, right. > >> X.500 ? Maybe i can get more insight from the security community. > > > > > > You need not go that far. Remember IS-IS? Still thriving. > > > > And yes, my experience with PICs and test suites comes from that. > > > > > >>> What it does do is to encourage people to write ???conformance test suites???. These then get sold to unsuspecting customers and end-users. Unfortunately, the quality of such suites is so low that you spend way, way, way more time debugging the test suite and you never find bugs in your implementation. > >> > >> This is just the worst possible outcome, and i am sure one can learn > >> from those bad experiences. Just think of taking a more organized > >> step towards being able to collect protocol implementation information > >> from the industry. Right now every WG who wants to raise the level of > >> an IETF protocol, e.g.: to(wards) full standard is coming up with a > >> questionaire in an ad-hoc fashion (we're just doing this in Multicast > >> for IGMP/MLD). > > > > > > You can do that if you like, but the one proven, effective method is interoperability testing. > > > > Running code trumps questionaires, conformance test suites, theory, and mandate. > > > > > >> My point was: If the only murphy you have is competitive pressure, it works not > >> it there is only limited competition, such as a total of maybe no > >> more than 3 competing national infrastructures. > > > > > > And countries that stifle competition inflict vendor lock on themselves. > > > > > >> See above. The best i think we (IETF) can do is to educate better about > >> this by appropriate documents. Certainly some additional protocol work > >> will result from that. I for once had simple slides 10 years ago how to fixup > >> non-dual plane networks to be dual-plane. And maybe we can come up with > >> questionaires to get better numbers from actual deployments (the > >> PICS discussion). > > > > > > The IETF???s job is not education. It does not work as the education is not requested > > and not welcome. The IETF???s job is standards and it needs to focus on that. > > > > > >> Figuring out ideas for a complete ecosystem of monetization and > >> deployment between competition and regulation is better left for > >> an ongoing bar-bof with emphasis on bar. > > > > > > I concur. Let???s stop fooling ourselves into thinking that anything that the IAB/IETF writes has any impact > > on regulation or economics. > > > > > >> Actually one of the interesting conclusions was that dual-plane in > >> many cases is really free but deployments often just don't fully > >> utilize it. > > > > > > I???d agree that it???s close to free. If you accept that you need a dual-plane approach for resiliency, then > > adding a second vendor to the mix is relatively easy. There???s additional cost because of decreased > > purchasing volume. There???s additional costs in management and operations. > > > > However, as compared to the costs of an unnecessary outage, it???s still trivial. > > > > Tony > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Jan 9 03:37:02 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5B112009C for ; Thu, 9 Jan 2020 03:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 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_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 azCBGnGszC4w for ; Thu, 9 Jan 2020 03:36:58 -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 EBBC1120098 for ; Thu, 9 Jan 2020 03:36:57 -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 93BA56A257; Thu, 9 Jan 2020 12:36:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1578569815; bh=VhIwFPilKlG+v44nolE/wjBEkrTozl6ncXvLwzD+yqA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=5qu+FNSihkY9IyAu7fVujiEzOnXjT2hYkVs3iZz6/cgf2p24aje/c9F28uajTqcgK 3/WjfS5ndRvT2MSy/oBloiSYjL2pRp+i9KbRHQ22qyBZT6mvJi4S7eAKAoNYUKShkK 9woecXwuCbKqF1aqLovglpm+PZwa12scucFeD5LvuAAbZ7iiAGUXgu6gxY8M0mfCx9 TS640ys+N5rNvnw7uGutNq9jzvQfU6ZP97M3NcVRsW3TqqdMVqGpbKAuABFxpxxXJr eab4/isGGaGRpODu6spuLHp3WTuAwk9rDxpfDUY0julSInbTtww3HHrZ8a84eS8LW+ LeYGJhL7+qv9g== 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 872B03C0579; Thu, 9 Jan 2020 12:36:55 +0100 (CET) Date: Thu, 9 Jan 2020 12:36:54 +0100 (CET) From: Vittorio Bertola To: iab@iab.org Cc: architecture-discuss@ietf.org Message-ID: <1585922465.23644.1578569815452@appsuite-gw1.open-xchange.com> In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev3 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 11:37:01 -0000

Il 09/01/2020 00:14 IAB Chair <iab-chair@iab.org> ha scritto:


Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please send them to iab@iab.org.

best regards,

Ted Hardie
for the IAB



Thanks for doing this. I have some comments on the substantial section, the central one:

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential

"Perceived" is unclear - perceived by whom? By the individual, or by other participants? The latter interpretation would cover the situation where the individual does not see a conflict but other participants, based on information available to them, think otherwise.
conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The "may" should at least be a "should". By the way, the introduction is much stronger and says that they "must avoid participating in discussions". I think "should" is reasonable, as there might be exceptional reasons for doing otherwise, but it should not be an entirely discretionary decision by the individual.
The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters.

Er, here the policy is basically saying "we will never disclose our conflicts of interest except in extraordinary cases and only if we like". That is not what is expected from a conflict of interest policy.
  • For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

There should be some more explicit mentioning of the conflict of interest with the financial and industrial interests of the individual's employer/source of consultancies. I would accept that a purely technical conflict of interests (i.e. "the IAB has to discuss possible technical solutions A and B and I am the author of B") is not a conflict, but positions in favour or against certain technologies/documents/architectures have business implications and that is exactly when actual conflict of interests arise. In that case, the conflict should definitely be disclosed and the person should possibly recuse him/herself at least at the decision-making moment.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Thu Jan 9 05:14:49 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8941200D7; Thu, 9 Jan 2020 05:14:43 -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_HELO_NONE=0.001, 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 WQVVTO7z4wdx; Thu, 9 Jan 2020 05:14:41 -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 3C890120048; Thu, 9 Jan 2020 05:14:41 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id q6so7318398wro.9; Thu, 09 Jan 2020 05:14:41 -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=OL2lvxX9Jfz5lPDjP7wequw8QdwPPLwlM5W2+acbuOk=; b=FkEaI01EErQnsl8o+BixuSPyricIIovRKokMSvhC3+ojftSczbXAdXsAu9lYXhfNe5 fo2QdMTSZxottweH7Y/fwQuD6lx3ymKh/+QG1C7uPvuwoTVXvsGxI8Q5t52Krl/CvfTs AeI6Mgw1rd0i4v4TCq4eDgELggDtAedKaxoikjybsGUYRBY/vaRTVsvC2y3Q5ViKxJgG 1AYMUnyZPuUN73tQ3LbcC4njsK5CK2mLKbAT8N+ekGdlnVE+9eBkI15TbAXpAnK4jZJH aqQnWdsPaJiskElXRFicG6sdwd7mJmZKabvT1REi5GMmAAgvYz2ORw7PHy0rHKbVxJIG 4E4g== 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=OL2lvxX9Jfz5lPDjP7wequw8QdwPPLwlM5W2+acbuOk=; b=LuKsz1yc+1wB4xHIVpRG2VHLjO3sjdaUFfyhCxHKgwarSUbeZ5OmEuRJOSzezEXoSo ops4PRp+GpExxOW73I4OiWoP5JE+puHbRfco/ny5BgnRR4xWivhN/MxLcv3ZxPVoCcr/ ncWv6Nlq3lckdl96sL577tihjddAjdT2hMEvtAKycNeVVfVT2okPyYcmb/jpfn4uxszW XZTYYB/73zOliHkSBWVIbj1l0fmtkDpLwoWbPiniV9qZOhFp4SvnzBa9WyV1Ss2mK9KD wZ8HGuRta4gB+6iQ3LCZB+fRtDt6GWSpLxC4OjyjZeB86+84XCzI3tvYhNwjLDuprrOQ b+jg== X-Gm-Message-State: APjAAAURtwMwYJpU5lMkfuRte94xvzfBVRw7FGXOgH0Ea77AHFkG8Twp cKAfburvFvxsKahEwDF+MILTCiGC X-Google-Smtp-Source: APXvYqzAV4CYS8TLkhhMd3RtC+hjSWGDGIBtOfcfGA3Ns0QIKtV6sC3DhQEC9vyIN+p3PQtiGmTbPQ== X-Received: by 2002:a5d:46c7:: with SMTP id g7mr10801923wrs.11.1578575679689; Thu, 09 Jan 2020 05:14:39 -0800 (PST) Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id i5sm8173697wrv.34.2020.01.09.05.14.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 05:14:38 -0800 (PST) From: Stewart Bryant Message-Id: <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_32B9592E-2F59-4C16-9754-0290F38BD087" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Thu, 9 Jan 2020 13:14:37 +0000 In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Cc: ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org To: IAB Chair References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 13:14:43 -0000 --Apple-Mail=_32B9592E-2F59-4C16-9754-0290F38BD087 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 8 Jan 2020, at 23:14, IAB Chair wrote: >=20 > The IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates. >=20 >=20 Is this to be a public or a private register of interests? Best regards Stewart= --Apple-Mail=_32B9592E-2F59-4C16-9754-0290F38BD087 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 8 Jan 2020, at 23:14, IAB Chair <iab-chair@iab.org> = wrote:

The = IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates.



Is this to be a public or a private register = of interests?

Best regards

Stewart
= --Apple-Mail=_32B9592E-2F59-4C16-9754-0290F38BD087-- From nobody Thu Jan 9 06:28:58 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D77512004E; Thu, 9 Jan 2020 06:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 QrgWGMwoQcOF; Thu, 9 Jan 2020 06:28:52 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90B0120089; Thu, 9 Jan 2020 06:28:52 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ipYnq-000F2b-0X; Thu, 09 Jan 2020 09:28:50 -0500 Date: Thu, 09 Jan 2020 09:28:44 -0500 From: John C Klensin To: Stewart Bryant , IAB Chair cc: iab@iab.org, ietf@ietf.org, architecture-discuss@ietf.org Message-ID: In-Reply-To: <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 14:28:57 -0000 --On Thursday, January 9, 2020 13:14 +0000 Stewart Bryant wrote: >> On 8 Jan 2020, at 23:14, IAB Chair wrote: >> >> The IAB requires that all Covered Individuals disclose their >> main employment, sponsorship, consulting customer, or other >> sources of income when joining the IAB or whenever there are >> updates. > Is this to be a public or a private register of interests? Stewart's question is important for what may be an additional reason. There is a fairly long history of IAB members who often show up as "independent" but who are full-time consultants with multiple clients (as distinct from those who serve in consulting, rather than employee, roles but with one principal client). They may have, in the words of the draft, no "main employment, sponsorship, consulting customer, ...". In those situations, it isn't terribly unusual for consulting agreements to contain requirements that the relationship not be disclosed by either party without mutual consent. I've had little trouble getting consent when there is a substantive reason that doesn't threaten the reasons for the confidentiality provision and there are provisions to keep the information from becoming generally known, but completely public disclosures would probably not fly. I'd assume that someone working for, or a principal of, a stealth startup might face similar constraints. While I applaud the IAB's coming to grips with this issue, let's be sure we don't do anything that limits the diversity or range of skills and perspectives of people who can serve on the IAB as an accidental side-effect of a well-intentioned policy. john From nobody Thu Jan 9 06:44:35 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C32C1200D8 for ; Thu, 9 Jan 2020 06:44:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 5XEsN_d13IYn for ; Thu, 9 Jan 2020 06:44: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 87CE01200B9 for ; Thu, 9 Jan 2020 06:44:25 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id u71so7457595lje.11 for ; Thu, 09 Jan 2020 06:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7pEweHIiSZh8B78Wmp8vnjz0ng3w/M96pSNbAnYI3JA=; b=ZQIwSHwlJEvh2ykkde9ST8YEsmwpYzg2E9HZ5uabVmVzXvIMzirTXHSoWVUBoU9C0T StNIBP9xbXc3xR+xuELE6AOIxO7nfieM236Mt/ZMnSsY5k/SX7GQvCfd5MJu+B8sSeZe 6kPns3d/Fe2G8Q4IJAJZ3Vh6Cix+tr24V99Fq94AvutP1NHNuVhNFhmShUhH02FF0ykW rtonL5aHRyLvx5dpstZpK+sgc5InMh7mBbiThR/T2odxPfwFja3bUGIhpR+OdJziwYx1 2o1vsLfDecWG590SzxhubXzn9vS00yePEkJpRC55jgpzZlzQf/SiF18ahEX7Dpb3sxwj l35A== 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=7pEweHIiSZh8B78Wmp8vnjz0ng3w/M96pSNbAnYI3JA=; b=NcZACokHRREmCn/SCaDg8yomdC1Mw1ivS+GCEDgZixPgA1e5EbukAT0Jw/X+1mVMmE zRKfDwUaMXDYBR+DCnFvQFfQLUBU7RgJGWWrIvFBm83c1taLWrk8BYVUSltkFqGrmOj2 O5sfs/YaYrEeOPrpl9Ya9iuzFqzFmHUuEAan70Ks1wnNa71OR7W3l06ruYhC4ukOU01W 7e7OKJFArl2vtta5dnerFy2ovGiG3ZP0qX9jTSJUab64cOmzyhlbfBSPzfIpT+A3Fb5h ShjsolnaboMeh/QQjjDLp9wxgBWWR4ZnyOFWfA7E32cO8NVRUfD53rZz2I+9qo+xIykK thng== X-Gm-Message-State: APjAAAWe9WF1qI5beWg0jAnQJPTgSyIChvW6MZv+VBpQm2qAYdHa//UK Ggh+B7PtptV0NlnIJLxboaegO4uLyy3BRibrujtBxQ== X-Google-Smtp-Source: APXvYqyQltGeoytUWPXkU1Evktqm5VcVesRaOZFlxjaJpRIqmzS2+3ZNKKUCu+YLYsoDwAFUUfMqd3K+Z7xU8SjKPF8= X-Received: by 2002:a2e:88c5:: with SMTP id a5mr6899536ljk.201.1578581063639; Thu, 09 Jan 2020 06:44:23 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> In-Reply-To: From: Eric Rescorla Date: Thu, 9 Jan 2020 06:43:47 -0800 Message-ID: To: John C Klensin Cc: Stewart Bryant , IAB Chair , "iab@iab.org IAB" , IETF discussion list , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000008c42df059bb60bc0" Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 14:44:29 -0000 --0000000000008c42df059bb60bc0 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 9, 2020 at 6:29 AM John C Klensin wrote: > > > --On Thursday, January 9, 2020 13:14 +0000 Stewart Bryant > wrote: > > >> On 8 Jan 2020, at 23:14, IAB Chair wrote: > >> > >> The IAB requires that all Covered Individuals disclose their > >> main employment, sponsorship, consulting customer, or other > >> sources of income when joining the IAB or whenever there are > >> updates. > > > Is this to be a public or a private register of interests? > > Stewart's question is important for what may be an additional > reason. There is a fairly long history of IAB members who often > show up as "independent" but who are full-time consultants with > multiple clients (as distinct from those who serve in > consulting, rather than employee, roles but with one principal > client). They may have, in the words of the draft, no "main > employment, sponsorship, consulting customer, ...". In those > situations, it isn't terribly unusual for consulting agreements > to contain requirements that the relationship not be disclosed > by either party without mutual consent. I've had little trouble > getting consent when there is a substantive reason that doesn't > threaten the reasons for the confidentiality provision and there > are provisions to keep the information from becoming generally > known, but completely public disclosures would probably not fly. > > I'd assume that someone working for, or a principal of, a > stealth startup might face similar constraints. > > While I applaud the IAB's coming to grips with this issue, let's > be sure we don't do anything that limits the diversity or range > of skills and perspectives of people who can serve on the IAB > as an accidental side-effect of a well-intentioned policy. > This seems like an important point. In addition, it's not clear to me as I read this text how I am supposed to read "main.... or other sources of income". Surely the intention is not that people disclose all other sources of income. -Ekr > john > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000008c42df059bb60bc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 6:29 AM John C= Klensin <john-ietf@jck.com>= wrote:


--On Thursday, January 9, 2020 13:14 +0000 Stewart Bryant
<stewart.b= ryant@gmail.com> wrote:

>> On 8 Jan 2020, at 23:14, IAB Chair <iab-chair@iab.org> wrote:
>>
>> The IAB requires that all Covered Individuals disclose their
>> main employment, sponsorship, consulting customer, or other
>> sources of income when joining the IAB or whenever there are
>> updates.

> Is this to be a public or a private register of interests?

Stewart's question is important for what may be an additional
reason.=C2=A0 There is a fairly long history of IAB members who often
show up as "independent" but who are full-time consultants with multiple clients (as distinct from those who serve in
consulting, rather than employee, roles but with one principal
client).=C2=A0 They may have, in the words of the draft, no "main
employment, sponsorship, consulting customer, ...".=C2=A0 In those
situations, it isn't terribly unusual for consulting agreements
to contain requirements that the relationship not be disclosed
by either party without mutual consent.=C2=A0 I've had little trouble getting consent when there is a substantive reason that doesn't
threaten the reasons for the confidentiality provision and there
are provisions to keep the information from becoming generally
known, but completely public disclosures would probably not fly.

I'd assume that someone working for, or a principal of, a
stealth startup might face similar constraints.

While I applaud the IAB's coming to grips with this issue, let's be sure we don't do anything that limits the diversity or range
of skills and perspectives of people who can serve on=C2=A0 the IAB
as an accidental side-effect of a well-intentioned policy.
=

This seems like an important point. In addition, it'= ;s not clear to me as
I read this text how I am supposed to read = "main.... or other sources
of income". Surely the inten= tion is not that people disclose all other
sources of income.
=

-Ekr


=C2=A0 =C2=A0john


_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000008c42df059bb60bc0-- From nobody Thu Jan 9 06:48:18 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0DD120019; Thu, 9 Jan 2020 06:48:15 -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_HELO_NONE=0.001, 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 ObwnXYwM25Dh; Thu, 9 Jan 2020 06:48:12 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 4B2291200B4; Thu, 9 Jan 2020 06:48:12 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id g17so7693390wro.2; Thu, 09 Jan 2020 06:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/ec5x6EM612P81UnJ13/N83rOfr3xExnsEptsdWstwQ=; b=RFUnPFPQVSlgfwCqiPyN5PwXqYIE1HweLI7Tmy3UvE+Kgg86LMJweEZEtjlAkK1CmJ ZtNDEED2/fDoauNPP2te/8vky89lYI25XD4VfMoA4/Op4OGTVMIgsimECU/mUxK5YK5K GV/3JIQtjqerd7cpnQasdXGTUlUTEA6v/ac1ZmFRDp1x4kYp5GX1/SANWBXUxkkYHWQY boqnrpQlV8VnvcG5PLIjXx7tRF+jq7lIQXisbro9cSSDEpdQvS/pREMSjb7+BId7Bl+t 5Yc1/32qA6p80btjTbDR9wElC58LXaQmy8+01ZuZaYxIoTfJpAgaHMEHY60253fHFt7d w0rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/ec5x6EM612P81UnJ13/N83rOfr3xExnsEptsdWstwQ=; b=Z1UtVktKRF2F5ZZeZ9v9R+2GgHjtv5oAKi9S9o+bD/2WrPxBmJbAOntewHx1qTeLCb vDh2L5/dP2f73BWufdZlbH3TnMdADj9jNvVuFCYGuWByK+9xHbIbIrHBIBokpkCx9LV0 6QMkb0AVd44JBVkOi5O9W2L5Lsc9IbmBU+93fiyDMhxryuN5QcGY/bQMUffNX5bGhdqo pEKIfAOay2PtHbs10Wxp675gbyLA6kGuH/j7oxZENOadBFI3xfd9pCBvuEsehNDwMOuT FkD8+nJ2qyzejrGz6qD7xk/QnMKqU7rPqQg0jAn+P91477tG2tolYMF9W0/YI/MO2T5S 0dVg== X-Gm-Message-State: APjAAAVCnWUuUt8iGW2TxSK8z+ecvzXUKILVs0xvOW/JNd+7VO9xiPwA R0yvqPRvDH2JYxl7GnxbavVXCCHM X-Google-Smtp-Source: APXvYqwUy6csmnqd0kYAUsVWqffNJfwz6rdmflUqTcIPy9jbsVmpEeX7ZtFtSV2G/DMFDrnY+spOOw== X-Received: by 2002:adf:eb89:: with SMTP id t9mr11608315wrn.5.1578581290751; Thu, 09 Jan 2020 06:48:10 -0800 (PST) Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id f17sm3149302wmc.8.2020.01.09.06.48.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 06:48:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Stewart Bryant In-Reply-To: Date: Thu, 9 Jan 2020 14:48:09 +0000 Cc: IAB Chair , iab@iab.org, ietf@ietf.org, architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> To: John C Klensin X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 14:48:15 -0000 > On 9 Jan 2020, at 14:28, John C Klensin wrote: >=20 >=20 >=20 > --On Thursday, January 9, 2020 13:14 +0000 Stewart Bryant > wrote: >=20 >>> On 8 Jan 2020, at 23:14, IAB Chair wrote: >>>=20 >>> The IAB requires that all Covered Individuals disclose their >>> main employment, sponsorship, consulting customer, or other >>> sources of income when joining the IAB or whenever there are >>> updates. >=20 >> Is this to be a public or a private register of interests? >=20 > Stewart's question is important for what may be an additional > reason. There is a fairly long history of IAB members who often > show up as "independent" but who are full-time consultants with > multiple clients (as distinct from those who serve in > consulting, rather than employee, roles but with one principal > client). They may have, in the words of the draft, no "main > employment, sponsorship, consulting customer, ...". In those > situations, it isn't terribly unusual for consulting agreements > to contain requirements that the relationship not be disclosed > by either party without mutual consent. I've had little trouble > getting consent when there is a substantive reason that doesn't > threaten the reasons for the confidentiality provision and there > are provisions to keep the information from becoming generally > known, but completely public disclosures would probably not fly. >=20 > I'd assume that someone working for, or a principal of, a > stealth startup might face similar constraints. >=20 > While I applaud the IAB's coming to grips with this issue, let's > be sure we don't do anything that limits the diversity or range > of skills and perspectives of people who can serve on the IAB > as an accidental side-effect of a well-intentioned policy. >=20 > John >=20 John I think that this is a dilemma we need to explore in more depth. Is taking money from a secret client consistent with holding high office = in an open standards organisation? I for one have always found that = difficult to accept as reasonable. Say it is, we all agree on the potential for abuse. Say it is not, then as you say the candidate pool is reduced. A compromise might be to require confidential disclosure to some trusted = party that monitors recusal, but the even that is potentially subject to = abuse through soft power. I suspect that the only way to ensure that we have a fully trustworthy = system is to require openness and accept that the candidate pool is = reduced. - Stewart >=20 From nobody Thu Jan 9 06:54:59 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84092120944; Thu, 9 Jan 2020 06:54:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bKpQLlAPyMB; Thu, 9 Jan 2020 06:54:54 -0800 (PST) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 1078F120934; Thu, 9 Jan 2020 06:54:53 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id t17so5839226eds.6; Thu, 09 Jan 2020 06:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :content-transfer-encoding; bh=SgLF/Z9na83qPxU942H2jQv1zQDvCIftCTdUkuLAcv8=; b=e/Abp9dZ4g+a6JtVjveYoeEe8J7lQneXJcgoopLqS9GoCr/QLUK18Uityibv1Ry0dX dT+i1Qzt4hx9bRnULXfHEXOGY/chWBNVSZCNYJODpoTiop0rM07oy/I0439SVYiV13L3 rEobLpnD23y5MUkNxUNygkU6H2fVG/dZj2sJUz/RsC9kN6pPUNsR5QjZo3yccLS1EN1n 8KTYR21vrXgGqJ8vEoAsjGnz69rbdPkzmF2j0unZuXRKzT7soFfMDihpPORdHQiKMFdH zsDukCixvpJOh4713gWCO3jc0yvbhAnubGTp4xx/LnXZzJGXl6Uq6lFS6uSCpTTX/Vgk SbwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:content-transfer-encoding; bh=SgLF/Z9na83qPxU942H2jQv1zQDvCIftCTdUkuLAcv8=; b=QdPmrfLHFsJl31zPXtVzlyXRlheRKkaOuwX8urCPeHutRfWTcNZpHMUcaKhY0+9EOw U+FA4wHiQDJAKQRCBthY7BHDMEQCembJ5Bp7IO3yb93ADBa9mwUf27m0xvpcy3+Kaqfs 10iZfwDFYkceWQbp5X4Fabo1321/eiyWVBF6T9bvT68xjYqW5n28DhM4fLRSQMvVpn/G uQrl/oYXfYjur3AWPRe6WTdv9wOVixEMNnO2zy8JcUujjKwMIWPwQSCihsMOlZV4O6VX +r0+29emdq0rYileZjIJMI0F8bHRpclpqok1e27v/Q3wRq/l7XtUIYa7ZV6r/XdUTMtG ld6A== X-Gm-Message-State: APjAAAUayzLw3BOIOk+ZSzwvHkaNPms2wXk/yFFWnYXaDyJV/NPGGavP GXOaW9hRmW7XUWlyo/ZX3ncIQH+j35uETySp4ZXVkw== X-Google-Smtp-Source: APXvYqwpqaP5n5EDsA8bXpUDVondEU4+5Jtva/Ph7br06QvfBS6zTLHvyHOc4R1A2oYOgNTkBqZFSofCqVnCLdIQeWs= X-Received: by 2002:a05:6402:1777:: with SMTP id da23mr11706125edb.292.1578581691423; Thu, 09 Jan 2020 06:54:51 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 9 Jan 2020 06:54:50 -0800 From: Alvaro Retana In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> MIME-Version: 1.0 Date: Thu, 9 Jan 2020 06:54:50 -0800 Message-ID: To: architecture-discuss@ietf.org, IAB Chair , iab@iab.org, ietf@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 14:54:57 -0000 On January 8, 2020 at 6:15:13 PM, IAB Chair wrote: Hi! > This policy covers the nomcom-selected Internet Architecture Board (IAB) > members and ex-officio members (collectively, =E2=80=9CCovered Individual= s=E2=80=9D). This > policy has no impact on any other participants in IAB activities, for > instance liaisons to and from the IAB or IAB program members. I have two questions: (1) Why are the liaison members of the IAB not included as Covered Individuals? =C2=A0rfc2850 treats both ex-officio and liaison members in about the same way -- the only distinction that I could see is that "an ex-officio position may be held by a full member" (=C2=A71.2). =C2=A0Gi= ven that all the other expectations for both are the same, I would like to understand why the liaison members are not included in the policy if they can participate in the IAB discussions. (2) Liaison managers (to other organizations) represent the interests of the IETF, should they be subject to a similar COI policy? =C2=A0Maybe it is not appropriate to include them in this specific policy, but I didn't find anything in rfc4052 related to this point. Thanks! Alvaro. From nobody Thu Jan 9 07:11:26 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB08120132; Thu, 9 Jan 2020 07:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 csFxy9HFcbRM; Thu, 9 Jan 2020 07:11:23 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 DF8CA120019; Thu, 9 Jan 2020 07:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AxOXb3J5pxM0w2XVlLWES/MOfXkLVRWWjwBm569Mr/k=; b=JHYDkKGuMPKMsvL9Emao4tMA+ mqlmV/cYXHjF4hSwklQZbHMPvHDp1lmsJzAwcJDuqU0dPEWNrKXxysS7WOGJ4ni16qUBAx4weYwBz pbT4E9yZq5XWZVkNNX++l66reqjjPlo6h3/NPEz8yNjmToDsM50WbcKxB4ZZiQzK5b2idN69SX65d 6ea2F8Ou+7K+3FH2qUE2RP/4y4u+IM5sGbDNSJx5qWdDVLOOUOzp4I24xpgR8j9+57YyfVREo2jSy 9p8NEUSiroEMjybbBK896NIv6iFIdxZvn1Kpi/tKYMUIX02WfYzoZwLReEj/xJtkCnOtMXFWmPQsz 4uvAC4B+g==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59627 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ipZSt-004LDh-Vu; Thu, 09 Jan 2020 10:11:20 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_8BCF0222-ACF7-4CF2-8486-BDDCB39DAAA2" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Joe Touch In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Date: Thu, 9 Jan 2020 07:11:14 -0800 Cc: ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org Message-Id: <7433C1A1-E071-417C-B7B8-CB4C12E7FEDC@strayalpha.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> To: IAB Chair X-Mailer: Apple Mail (2.3608.40.2.2.4) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 15:11:24 -0000 --Apple-Mail=_8BCF0222-ACF7-4CF2-8486-BDDCB39DAAA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, Numerous issues typically mentioned in COI policies are missing here: 1) compensation may be pending or in the immediate future 2) Compensation need not be financial (e.g., authorship, appointment to = perceived prestigious non-paying positions, quid-pro-quo, etc.) 3) Conflicts go beyond direct collaborations (i.e., the employers whole = organization) 4) The policy should indicate a time frame=20 Some examples from other COI policies include: - no current student/teacher relationship - no PhD graduate / PhD primary advisor *forever* - no current or recent proposal or paper co-author (whether = granted or not) for 4 years - not in any way associated with a current employer *and its = subsidiaries* - agree to not accept compensation (financial or not) for at = least 1 year *after* participation Joe > On Jan 8, 2020, at 3:14 PM, IAB Chair wrote: >=20 > Dear Colleagues, >=20 > The IAB is considering adoption of the conflict of interest policy = below. If you have comments on this draft policy, please send them to = iab@iab.org . >=20 > best regards, >=20 > Ted Hardie > for the IAB >=20 >=20 >=20 > INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >=20 > This policy covers the nomcom-selected Internet Architecture Board = (IAB) members and ex-officio members (collectively, =E2=80=9CCovered = Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the = IAB or IAB program members. >=20 > In carrying out their IAB role, Covered Individuals must act in the = best interest of the Internet community. Occasionally this duty may = be=E2=80=94or may appear to be=E2=80=94incompatible or in conflict with = a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which = the Covered Individual is an employee, director, owner, or otherwise has = business or financial interest. If a Covered Individual has a conflict = of interest for whatever reason, that individual must avoid = participating in the work of the IAB that touches on the related matter. >=20 > The IAB does not directly deal with matters relating to contracts or = finance. The IAB does, however, have a role in personnel decisions, and = its decisions and outputs have a potential to indirectly affect = contracts within the IETF system. IAB's technical decisions and outputs = have also a potential to impact both work elsewhere in the IETF and = businesses that employ or develop Internet technology. >=20 > Covered Individuals shall not use the IAB=E2=80=99s resources or = decisions as a means for personal or third-party gain. >=20 > Disclosure of Actual or Potential Conflicts >=20 > The IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates. >=20 > In addition, when a topic is discussed at the IAB, the Covered = Individuals are required to promptly disclose if that topic constitutes = a perceived or potential conflict of interest. Once disclosed, Covered = Individuals may recuse from participation in discussions or decisions at = their discretion. >=20 > The specific conflicts that may cause a perceived or potential = conflict of interest are matters for individual and IAB judgment, but = generally come in the following forms: >=20 > A personnel decision relates to the Covered Individual, a colleague = that the Covered Individual's works closely with, or a family member. = For the purposes of this policy, a "person working closely with" is = someone working in the same team or project, or a direct manager or = employee of the Covered Individual. And "family" means a spouse, = domestic partner, child, sibling, parent, stepchild, stepparent, and = mother-, father-, son-, daughter-, brother-, or sister-in-law, and any = other person living in the same household, except tenants and household = employees. >=20 > A decision or output from the IAB impacts a contract that the IETF = enters into with a party, and that party relates to the Covered = Individual, a colleague that the Covered Individual's works closely = with, or a family member. >=20 > Activity on the IAB involves discussion and decisions regarding = technical matters, mainly related to IETF activities. As an activity = adjacent to a standardization process, it is often the case that Covered = Individuals will have some (frequently non-financial) stake in the = outcome of discussions or decisions that relate to technical matters. = This policy does not require that Covered Individuals disclose such = conflicts of interest as they relate to technical matters. However, = Covered Individuals need to exercise their judgment and, in = extraordinary cases be willing to disclose potential or perceived = conflicts of interest even as they relate to technical matters. For = example, if a Covered Individual's sponsor were in the process of = entering a new market where there is an ongoing IAB discussion, then = disclosure, or even recusal, might be appropriate, even if difficult. >=20 > Disclosure Transparency >=20 > A person's recusal to participate in the discussion of a topic is = always noted in the public IAB minutes. In addition, the IAB will = maintain a repository of all general disclosures of employment and other = sponsorship. It is expected that much of this repository is public, but = there can be situations where some disclosures (such as customers of = consultants) are private. >=20 >=20 > = >=20 --Apple-Mail=_8BCF0222-ACF7-4CF2-8486-BDDCB39DAAA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = all,

Numerous issues = typically mentioned in COI policies are missing here:

1) compensation may be = pending or in the immediate future

2) Compensation need not be financial = (e.g., authorship, appointment to perceived prestigious non-paying = positions, quid-pro-quo, etc.)

3) Conflicts go beyond direct = collaborations (i.e., the employers whole organization)

4) The policy should = indicate a time frame 

Some examples from other COI policies include:

- no = current student/teacher relationship
- no PhD = graduate / PhD primary advisor *forever*
- no = current or recent proposal or paper co-author (whether granted or not) = for 4 years
- not in any way associated with = a current employer *and its subsidiaries*
- agree = to not accept compensation (financial or not) for at least 1 year = *after* participation

Joe


On Jan 8, 2020, at 3:14 PM, IAB = Chair <iab-chair@iab.org> wrote:

=20 =20

Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please = send them to iab@iab.org.

best regards,

Ted Hardie
for the IAB



INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST = POLICY

This policy covers the nomcom-selected Internet = Architecture Board (IAB) members and ex-officio members (collectively, = =E2=80=9CCovered Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB = role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in = conflict with a Covered Individual=E2=80=99s personal interests (including = interests of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not = directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals = shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their = main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the = Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The = specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the = Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB = impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves = discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's = recusal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.




= --Apple-Mail=_8BCF0222-ACF7-4CF2-8486-BDDCB39DAAA2-- From nobody Thu Jan 9 07:15:39 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB45120133 for ; Thu, 9 Jan 2020 07:15:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-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 9Wo1DHfyi5_r for ; Thu, 9 Jan 2020 07:15:32 -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 16D341201B7 for ; Thu, 9 Jan 2020 07:15:32 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id c16so6260463qko.6 for ; Thu, 09 Jan 2020 07:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RzGXWKfcRWH0MysPCL6IRnCr1p4YslyqVTvBasak8bw=; b=G3wl8lKYCLyWXv0wA553WnAhSkqUOKC/7WF10gy2CCXfz1Kwthn4k/S0rEtJKpRVsq IgGF6Hko4ORaR9kjIIRnAtPYXhN0RGxSsSwxOOlh+bpm7+elkFcJHWa/kfHgzowsz4Gw OwEnMkrkXsEX2NGfR/6pmmVYvIZoGCNDMeWUDbW/m2PCteMKwqgOaeVb52AspcN0i3fd xXs+u3ocgRtEusA7ktYQOIzWMRS4GV9XfTPn82S21s734jDqP+X8F0ftPjbhg+hsy7KS nt7e3WzvFcW+BXrJayrX+PhLlTTDJ6JYlzjegG/C4zBBkcraj3rX2f0MvVFseATIymSI l/TQ== 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=RzGXWKfcRWH0MysPCL6IRnCr1p4YslyqVTvBasak8bw=; b=L72ltGEPK5Up25Sa/v1bUq5OjY0/EcUTHyVRSohQA45jms5hdzCnE1w0PhUGU+4WIs CFnI618hdibn00t4QOOe4aZ7fvx1jxz/fuikqPvqn6vimvEFT67PsxgQ8CMTwlFMZrtn XRfmIhoQQIKai31devbGlmc1xnY7EyrHQ6sE6yAnqOBK8p0gV8QHJax+5QDYv7qA6469 A7okykUF7+A+E/KrlF2IBkj9jqwvkyFGnfrHPq/u78fvmZp1UL/IgUsfd3mfLN6sxtMB 1l7cQXa/4eoK1eE7hlZ+Kmh50SXiVpZioFapXsKZLxcxcVs6PoTJVj+ZFAZ8mdMbLWUO GT+A== X-Gm-Message-State: APjAAAWT0Fx2JO8u3xd05qFKgYnTyJW0ydROG2qfq7HsmwYioeRjNc1t /mF9+ptuJFUcHbm6fK7fe9xCp0lmjBvwu6KtCwv2Qw== X-Google-Smtp-Source: APXvYqzV+v3IlbD3Oo1gCzDXuI6REJahkGutKdeLZPlrUlTMW9ZgRX+d5BmOfzDFV5mxkD+gEBmlsMEmpULNVub5+/8= X-Received: by 2002:a37:9982:: with SMTP id b124mr9758576qke.245.1578582930870; Thu, 09 Jan 2020 07:15:30 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> From: Warren Kumari Date: Thu, 9 Jan 2020 10:14:54 -0500 Message-ID: To: IAB Chair Cc: IETF Discuss , architecture-discuss@ietf.org, IAB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 15:15:37 -0000 On Wed, Jan 8, 2020 at 6:15 PM IAB Chair wrote: > > Dear Colleagues, > > The IAB is considering adoption of the conflict of interest policy below.= If you have comments on this draft policy, please send them to iab@iab.or= g. > > best regards, > > Ted Hardie > for the IAB > > > INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY > > This policy covers the nomcom-selected Internet Architecture Board (IAB) = members and ex-officio members (collectively, =E2=80=9CCovered Individuals= =E2=80=9D). This policy has no impact on any other participants in IAB acti= vities, for instance liaisons to and from the IAB or IAB program members. > > In carrying out their IAB role, Covered Individuals must act in the best = interest of the Internet community. Occasionally this duty may be=E2=80=94o= r may appear to be=E2=80=94incompatible or in conflict with a Covered Indiv= idual=E2=80=99s personal interests (including interests of their family mem= bers), or the interests of an organization of which the Covered Individual = is an employee, director, owner, or otherwise has business or financial int= erest. If a Covered Individual has a conflict of interest for whatever reas= on, that individual must avoid participating in the work of the IAB that to= uches on the related matter. > > The IAB does not directly deal with matters relating to contracts or fina= nce. The IAB does, however, have a role in personnel decisions, and its dec= isions and outputs have a potential to indirectly affect contracts within t= he IETF system. IAB's technical decisions and outputs have also a potential= to impact both work elsewhere in the IETF and businesses that employ or de= velop Internet technology. > > Covered Individuals shall not use the IAB=E2=80=99s resources or decision= s as a means for personal or third-party gain. > > Disclosure of Actual or Potential Conflicts > > The IAB requires that all Covered Individuals disclose their main employm= ent, sponsorship, consulting customer, or other sources of income when join= ing the IAB or whenever there are updates. > > In addition, when a topic is discussed at the IAB, the Covered Individual= s are required to promptly disclose if that topic constitutes a perceived o= r potential conflict of interest. Once disclosed, Covered Individuals may r= ecuse from participation in discussions or decisions at their discretion. > > The specific conflicts that may cause a perceived or potential conflict o= f interest are matters for individual and IAB judgment, but generally come = in the following forms: > > A personnel decision relates to the Covered Individual, a colleague that = the Covered Individual's works closely with, or a family member. For the pu= rposes of this policy, a "person working closely with" is someone working i= n the same team or project, or a direct manager or employee of the Covered = Individual. And "family" means a spouse, domestic partner, child, sibling, = parent, stepchild, stepparent, and mother-, father-, son-, daughter-, broth= er-, or sister-in-law, and any other person living in the same household, e= xcept tenants and household employees. I'm a bit concerned by the specificity of these -- the fact that they are explicitly enumerated implies that everything not listed so just fine - for example, my dear Grandma[0] is a leading ASP.NET developer, and is forming a company - as grandparents are not excluded, *clearly* I could, as an IAB member, recommend she gets the contract for rewriting the DT in some shiny new asp based framework. I'm guessing that this was copied from somewhere else, because I'm assuming most IAB people won't run into the "household employees" issue (which is sad, because my personal valet gives good legal advice, and my butler ties a great Windsor knot, and is also an expert on long term archival solutions for technical documents). I *do* realize that this says "perceived or potential conflict of interest", and so issues like my Grandma should be excluded, but perhaps something more along the lines of Spencer's "Do the right thing" tone would be better? Or a combination, with some specificity but a mention of the list not being wholly inclusive/just a sample or subset? W > > A decision or output from the IAB impacts a contract that the IETF enters= into with a party, and that party relates to the Covered Individual, a col= league that the Covered Individual's works closely with, or a family member= . > > Activity on the IAB involves discussion and decisions regarding technical= matters, mainly related to IETF activities. As an activity adjacent to a s= tandardization process, it is often the case that Covered Individuals will = have some (frequently non-financial) stake in the outcome of discussions or= decisions that relate to technical matters. This policy does not require t= hat Covered Individuals disclose such conflicts of interest as they relate = to technical matters. However, Covered Individuals need to exercise their j= udgment and, in extraordinary cases be willing to disclose potential or per= ceived conflicts of interest even as they relate to technical matters. For = example, if a Covered Individual's sponsor were in the process of entering = a new market where there is an ongoing IAB discussion, then disclosure, or = even recusal, might be appropriate, even if difficult. > > Disclosure Transparency > > A person's recusal to participate in the discussion of a topic is always = noted in the public IAB minutes. In addition, the IAB will maintain a repos= itory of all general disclosures of employment and other sponsorship. It is= expected that much of this repository is public, but there can be situatio= ns where some disclosures (such as customers of consultants) are private. > > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Jan 9 08:13:45 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D2E12012D; Thu, 9 Jan 2020 08:13:40 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 LJwpxWI5Rzzp; Thu, 9 Jan 2020 08:13:32 -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 0BD911200FA; Thu, 9 Jan 2020 08:13:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 89BD6BE53; Thu, 9 Jan 2020 16:13:29 +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 p_BBMyQ6lNrT; Thu, 9 Jan 2020 16:13:27 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E4B1ABE51; Thu, 9 Jan 2020 16:13:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578586406; bh=afrDVyJooG78WG6aaVSPBY/eT/xPJTEoqP4/LuMZzuI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=vba6xeTPSVhYz+0UFDVr7ZcL/eqTqFwcgRM4qJFCnKNC7U8LyxzBf4HovmX5e9Wdv ICHHl46mOGTNbY+bDfgqDLsVhgbTBPhFcZYEjwXDWiCJXn3ZVFk3jfuDIJo4bsEO+a WT3mVqCrlZMozqNL5cNfngT57Z0FYUnwRmR6GROE= To: IAB Chair , ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: <352570ca-1f4b-33e7-3bfe-57cc0e852f1b@cs.tcd.ie> Date: Thu, 9 Jan 2020 16:13:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OwwVpwsyWy4ztjNFtYVMbf6ITe9hlnVZV" Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 16:13:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OwwVpwsyWy4ztjNFtYVMbf6ITe9hlnVZV Content-Type: multipart/mixed; boundary="BCkoJBa5askY94jk21CMv450JjTXEzZjF"; protected-headers="v1" From: Stephen Farrell To: IAB Chair , ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org Message-ID: <352570ca-1f4b-33e7-3bfe-57cc0e852f1b@cs.tcd.ie> Subject: Re: Draft IAB conflict of interest policy References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> --BCkoJBa5askY94jk21CMv450JjTXEzZjF Content-Type: multipart/mixed; boundary="------------01B0991A504123AE170DEA38" Content-Language: en-US This is a multi-part message in MIME format. --------------01B0991A504123AE170DEA38 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, FYI, this text is also in a github repo [1] so raising issues there is also a possibility that may help us to track things more easily, for folks who prefer to do things that way. Cheers, S. [1] https://github.com/jariarkko/alternate-iab-coi-policy/blob/master/coi-pol= icy.md On 08/01/2020 23:14, IAB Chair wrote: > Dear Colleagues, >=20 > The IAB is considering adoption of the conflict of interest policy > below.=C2=A0 If you have comments on this draft policy, please send the= m > toiab@iab.org . >=20 > best regards, >=20 > Ted Hardie > for the IAB >=20 >=20 > =C2=A0=C2=A0=C2=A0=C2=A0 INTERNET ARCHITECTURE BOARD CONFLICT OF INTERE= ST POLICY >=20 > This policy covers the nomcom-selected Internet Architecture Board (IAB= ) > members and ex-officio members (collectively, =E2=80=9CCovered Individu= als=E2=80=9D). > This policy has no impact on any other participants in IAB activities, > for instance liaisons to and from the IAB or IAB program members. >=20 > In carrying out their IAB role, Covered Individuals must act in the bes= t > interest of the Internet community. Occasionally this duty may be=E2=80= =94or may > appear to be=E2=80=94incompatible or in conflict with a Covered Individ= ual=E2=80=99s > personal interests (including interests of their family members), or th= e > interests of an organization of which the Covered Individual is an > employee, director, owner, or otherwise has business or financial > interest. If a Covered Individual has a conflict of interest for > whatever reason, that individual must avoid participating in the work o= f > the IAB that touches on the related matter. >=20 > The IAB does not directly deal with matters relating to contracts or > finance. The IAB does, however, have a role in personnel decisions, and= > its decisions and outputs have a potential to indirectly affect > contracts within the IETF system. IAB's technical decisions and outputs= > have also a potential to impact both work elsewhere in the IETF and > businesses that employ or develop Internet technology. >=20 > Covered Individuals shall not use the IAB=E2=80=99s resources or decisi= ons as a > means for personal or third-party gain. >=20 >=20 > =C2=A0=C2=A0=C2=A0=C2=A0 Disclosure of Actual or Potential Conflicts >=20 > The IAB requires that all Covered Individuals disclose their main > employment, sponsorship, consulting customer, or other sources of incom= e > when joining the IAB or whenever there are updates. >=20 > In addition, when a topic is discussed at the IAB, the Covered > Individuals are required to promptly disclose if that topic constitutes= > a perceived or potential conflict of interest. Once disclosed, Covered > Individuals may recuse from participation in discussions or decisions a= t > their discretion. >=20 > The specific conflicts that may cause a perceived or potential conflict= > of interest are matters for individual and IAB judgment, but generally > come in the following forms: >=20 > =C2=A0* >=20 > =C2=A0=C2=A0 A personnel decision relates to the Covered Individual, a = colleague > =C2=A0=C2=A0 that the Covered Individual's works closely with, or a fam= ily > =C2=A0=C2=A0 member. For the purposes of this policy, a "person working= closely > =C2=A0=C2=A0 with" is someone working in the same team or project, or a= direct > =C2=A0=C2=A0 manager or employee of the Covered Individual. And "family= " means a > =C2=A0=C2=A0 spouse, domestic partner, child, sibling, parent, stepchil= d, > =C2=A0=C2=A0 stepparent, and mother-, father-, son-, daughter-, brother= -, or > =C2=A0=C2=A0 sister-in-law, and any other person living in the same hou= sehold, > =C2=A0=C2=A0 except tenants and household employees. >=20 > =C2=A0* >=20 > =C2=A0=C2=A0 A decision or output from the IAB impacts a contract that = the IETF > =C2=A0=C2=A0 enters into with a party, and that party relates to the Co= vered > =C2=A0=C2=A0 Individual, a colleague that the Covered Individual's work= s closely > =C2=A0=C2=A0 with, or a family member. >=20 > =C2=A0* >=20 > =C2=A0=C2=A0 Activity on the IAB involves discussion and decisions rega= rding > =C2=A0=C2=A0 technical matters, mainly related to IETF activities. As a= n activity > =C2=A0=C2=A0 adjacent to a standardization process, it is often the cas= e that > =C2=A0=C2=A0 Covered Individuals will have some (frequently non-financi= al) stake > =C2=A0=C2=A0 in the outcome of discussions or decisions that relate to = technical > =C2=A0=C2=A0 matters. This policy does not require that Covered Individ= uals > =C2=A0=C2=A0 disclose such conflicts of interest as they relate to tech= nical > =C2=A0=C2=A0 matters. However, Covered Individuals need to exercise the= ir > =C2=A0=C2=A0 judgment and, in extraordinary cases be willing to disclos= e > =C2=A0=C2=A0 potential or perceived conflicts of interest even as they = relate to > =C2=A0=C2=A0 technical matters. For example, if a Covered Individual's = sponsor > =C2=A0=C2=A0 were in the process of entering a new market where there i= s an > =C2=A0=C2=A0 ongoing IAB discussion, then disclosure, or even recusal, = might be > =C2=A0=C2=A0 appropriate, even if difficult. >=20 >=20 > =C2=A0=C2=A0=C2=A0=C2=A0 Disclosure Transparency >=20 > A person's recusal to participate in the discussion of a topic is alway= s > noted in the public IAB minutes. In addition, the IAB will maintain a > repository of all general disclosures of employment and other > sponsorship. It is expected that much of this repository is public, but= > there can be situations where some disclosures (such as customers of > consultants) are private. >=20 >=20 >=20 > =C2=A0 >=20 >=20 >=20 >=20 --------------01B0991A504123AE170DEA38 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------01B0991A504123AE170DEA38-- --BCkoJBa5askY94jk21CMv450JjTXEzZjF-- --OwwVpwsyWy4ztjNFtYVMbf6ITe9hlnVZV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4XUSEACgkQWrL68XsX K+oT7BAAnkOXHTc3bzqg8d8h5mhCj7xQXxBDU+/6rAFq3t9Ppt7KABsi7jI3EKQd ZoAjg05kxRCKl0lhXuG7GHSIWGKJYuVfjNKNv2tt8iL9U63URdmNWz3yd4wyC/Mm WZEZUbufp2Mv37MuQxffP2D2ywRRM3oTvMFFhYfvgfnkxcusffW2Ww4GroRoe7kN LDHTtokWz34MpBu12oS85EMJIdcF0NALuJaGRknZA+Z6AIojHQ53eVeUXls2n2io b603bRWQI7Edq0apuf+LFPQjG58Mfq2y/DN02tEICOJL6WwsUsT6BwWCyo/9gVtp SoFld0hZcj6nPSnBA2sO5OziTGfxnllGOU/+QCMZ+oIhTkAYfuHze5prOX+TDYmp +1mXa9VvyY90cLMN9L9CuIG/bFXaAFCe5Vpo9TdoXEyrqyiYv1p6C5bqeQsuS2UL phwRRtnOCldZYZDQbv8xNFqt6icce4xk8P8FWX7d7gmbMIL+33RlnTEVE0FDElDV VAUdJcBpwQj9AYGqClIi1o5wYBUcZJC1Oo2BCGxdE5KIFUy7BHt6Bwg1umCRAF/N DwQ5/BI0Mc1vOVML1vm3nWT4jlZo/aPyIIXScOr8SGxaN7BZzmBHhxCRjaGS/3M9 ja/Zd3t7ZZsxtPRCfF8ozZe9r0Ko3HZyEnCn99HK0D1WHk6nLGA= =dLkh -----END PGP SIGNATURE----- --OwwVpwsyWy4ztjNFtYVMbf6ITe9hlnVZV-- From nobody Thu Jan 9 08:57:52 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9315B1200FA for ; Thu, 9 Jan 2020 08:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 YfoCUlIYEZ0j for ; Thu, 9 Jan 2020 08:57:46 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 3286F1200F1 for ; Thu, 9 Jan 2020 08:57:46 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id j5so6403294qtq.9 for ; Thu, 09 Jan 2020 08:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D1/8cfNa3Egi7p+5LKcPs+HsBMhtja7eTewZ/niP68M=; b=Ms3yO9Xlkau3Mys2C1b7Lg3FLJkCbJHU0M6jxvnjtUPw2kcTqR1Nz9ajsiYRvKdvwV X5IM84efeIJEdfoFkWezUm//jMqBcB7K5RAa2UD92XPUb8R0Dkp0cUschz+OArDxVQAs HDOkcCkQ8wHzZ5rHjrZ1WcUASXCyAf6prubTMzuMOmDxQDdd5AJFiREijDGpIOkRJDcB yLdvD/301EV1rW4UTDE6EBGpx/pO0IlY/423kj5QFCagYVH56iGJH7N4WiyurOUGQfKC mPG8oxW5geOkTaGkLC3Wkh+81KCfqun2xCIknPXOE0Eehfa183pIL+WwR/PcZrx1h+gW Ki/w== 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=D1/8cfNa3Egi7p+5LKcPs+HsBMhtja7eTewZ/niP68M=; b=Q3gfH0Xgc6HzG8qCUvDu8DmoANh8OFkZMWmDupemM7ZwHG99EWJmO18s1CNIBmekPi yTLfURyKmfALWYcz6CydSEVDj1eKgc/ncF1q+0wPwX1uECXO9/RmM3d9nK4g+3rUk+T9 z2h7T7OLiZ6roNdw+FXBgBKjf1v9bBAapO7NAGwt6aumv7DvyuBR2tmfLgLpYri9X4Rh ZLExX7nnJfMf9djbMaIM0us3nP2eMV+/YChZvrh9YX83GTumPBvsqoIEWk6w7d0gm2dI kQxj8qHw4P7eFk0zgXe9gR1EN9gsMl0Pp8VS5k1oMSG6rN+1unpbq9l6ArNILOUnIq6/ t6mg== X-Gm-Message-State: APjAAAVvcsBkU3O9DahXlWSN7HnWHAwAFG4Kc7t7QCBznYzrvDbZwIzO mYwMKJ22IGIPqemELewty/bv5w/ps7y1M85Azed9+v7e X-Google-Smtp-Source: APXvYqy7tsI6lfDtKMlqSzl0SQXYpjK2Z6bJbHczdRT2k9bFDYi4/K5K/ySIJe+4NmE+wDhAEzwCo+dh5nWYevtHHdE= X-Received: by 2002:ac8:47c1:: with SMTP id d1mr8520563qtr.84.1578589065163; Thu, 09 Jan 2020 08:57:45 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> From: Richard Barnes Date: Thu, 9 Jan 2020 11:57:33 -0500 Message-ID: To: IAB Chair Cc: IETF discussion list , architecture-discuss@ietf.org, IAB IAB Content-Type: multipart/alternative; boundary="00000000000079dab8059bb7e8ad" Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 16:57:50 -0000 --00000000000079dab8059bb7e8ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would propose the IAB not adopt this policy, or at least scope it way down. Much of the IAB's work is focused on technical issues, at a high enough strategic level that the impacts to specific people or companies are highly attenuated. In those discussions, the IAB's work benefits from having diverse opinions, including the opinions of those who have skin in the game. Trying to introduce some notion of CoI in this context would be harmful -- because there's no hard conflict, it will inevitably be vague, and thus primarily a tool for IAB members to try to silence one another or a cause for IAB members to self-censor. Where the IAB is directly involved in finance or personnel decisions, there of course should be guards against self dealing. That's where any CoI policy for the IAB should stop. --Richard On Wed, Jan 8, 2020 at 6:16 PM IAB Chair wrote: > Dear Colleagues, > > The IAB is considering adoption of the conflict of interest policy below. > If you have comments on this draft policy, please send them to iab@iab.or= g > . > > best regards, > Ted Hardie > for the IAB > > > INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY > > This policy covers the nomcom-selected Internet Architecture Board (IAB) > members and ex-officio members (collectively, =E2=80=9CCovered Individual= s=E2=80=9D). This > policy has no impact on any other participants in IAB activities, for > instance liaisons to and from the IAB or IAB program members. > > In carrying out their IAB role, Covered Individuals must act in the best > interest of the Internet community. Occasionally this duty may be=E2=80= =94or may > appear to be=E2=80=94incompatible or in conflict with a Covered Individua= l=E2=80=99s > personal interests (including interests of their family members), or the > interests of an organization of which the Covered Individual is an > employee, director, owner, or otherwise has business or financial interes= t. > If a Covered Individual has a conflict of interest for whatever reason, > that individual must avoid participating in the work of the IAB that > touches on the related matter. > > The IAB does not directly deal with matters relating to contracts or > finance. The IAB does, however, have a role in personnel decisions, and i= ts > decisions and outputs have a potential to indirectly affect contracts > within the IETF system. IAB's technical decisions and outputs have also a > potential to impact both work elsewhere in the IETF and businesses that > employ or develop Internet technology. > > Covered Individuals shall not use the IAB=E2=80=99s resources or decision= s as a > means for personal or third-party gain. > Disclosure of Actual or Potential Conflicts > > The IAB requires that all Covered Individuals disclose their main > employment, sponsorship, consulting customer, or other sources of income > when joining the IAB or whenever there are updates. > > In addition, when a topic is discussed at the IAB, the Covered Individual= s > are required to promptly disclose if that topic constitutes a perceived o= r > potential conflict of interest. Once disclosed, Covered Individuals may > recuse from participation in discussions or decisions at their discretion= . > > The specific conflicts that may cause a perceived or potential conflict o= f > interest are matters for individual and IAB judgment, but generally come = in > the following forms: > > - > > A personnel decision relates to the Covered Individual, a colleague > that the Covered Individual's works closely with, or a family member. = For > the purposes of this policy, a "person working closely with" is someon= e > working in the same team or project, or a direct manager or employee o= f the > Covered Individual. And "family" means a spouse, domestic partner, chi= ld, > sibling, parent, stepchild, stepparent, and mother-, father-, son-, > daughter-, brother-, or sister-in-law, and any other person living in = the > same household, except tenants and household employees. > - > > A decision or output from the IAB impacts a contract that the IETF > enters into with a party, and that party relates to the Covered Indivi= dual, > a colleague that the Covered Individual's works closely with, or a fam= ily > member. > - > > Activity on the IAB involves discussion and decisions regarding > technical matters, mainly related to IETF activities. As an activity > adjacent to a standardization process, it is often the case that Cover= ed > Individuals will have some (frequently non-financial) stake in the out= come > of discussions or decisions that relate to technical matters. This pol= icy > does not require that Covered Individuals disclose such conflicts of > interest as they relate to technical matters. However, Covered Individ= uals > need to exercise their judgment and, in extraordinary cases be willing= to > disclose potential or perceived conflicts of interest even as they rel= ate > to technical matters. For example, if a Covered Individual's sponsor w= ere > in the process of entering a new market where there is an ongoing IAB > discussion, then disclosure, or even recusal, might be appropriate, ev= en if > difficult. > > Disclosure Transparency > > A person's recusal to participate in the discussion of a topic is always > noted in the public IAB minutes. In addition, the IAB will maintain a > repository of all general disclosures of employment and other sponsorship= . > It is expected that much of this repository is public, but there can be > situations where some disclosures (such as customers of consultants) are > private. > > > > > > --00000000000079dab8059bb7e8ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would propose the IAB not adopt this policy, or at = least scope it way down.

Much of the IAB's wor= k is focused on technical issues, at a high enough strategic level that the= impacts to specific people or companies are highly attenuated.=C2=A0 In th= ose discussions, the IAB's work benefits from having diverse opinions, = including the opinions of those who have skin in the game.=C2=A0 Trying to = introduce some notion of CoI in this context would be harmful -- because th= ere's no hard conflict, it will inevitably be vague, and thus primarily= a tool for IAB members to try to silence one another or a cause for IAB me= mbers to self-censor.

Where the IAB is directl= y involved in finance or personnel decisions, there of course should be gua= rds against self dealing.=C2=A0 That's where any CoI policy for the IAB= should stop.

--Richard

On Wed, Jan 8, 20= 20 at 6:16 PM IAB Chair <iab-chair@= iab.org> wrote:
=20 =20 =20

<= /span>Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.=C2=A0 If you have comments on this draft policy, please send them to=C2=A0iab@iab.org.

best regards,

Ted Hardie
for the IAB

INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY

This policy covers the nomcom-selected Internet Architecture Board (IAB) members and ex-officio members (collectively, =E2=80=9CCo= vered Individuals=E2=80=9D). This policy has no impact on any other partici= pants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in co= nflict with a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, o= r a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partn= er, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's recusal to participate in the discussion of a topic i= s always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.



--00000000000079dab8059bb7e8ad-- From nobody Thu Jan 9 09:04:34 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C36F1200A4 for ; Thu, 9 Jan 2020 09:04:32 -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_HELO_NONE=0.001, 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 15MOYsIU5A5k for ; Thu, 9 Jan 2020 09:04:28 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B30120019 for ; Thu, 9 Jan 2020 09:04:28 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id p125so6440894oif.10 for ; Thu, 09 Jan 2020 09:04:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fulpbebZodsE9QlmRO1W9Cc4c4s3GxA3dS4MXdMbiZ0=; b=e9oxOnL/tNLhCMI8MtrN3Ff33yY4i7v08+A3vr9va30GwNc9Bj0J8DIiK2lmAFNebw CEmAt8iNjEtxmwqdULNE3tBRDLk6RXyiwgwKkkLahhP7EbpolYr6t2mk7MiodBjdQFnR ZJg8NyQDh1xQkpELftzAJeAGBlc8J1oGZHqOnmttcPL8ErzT9S2PpCLnU07QaUvk1jaQ 9kNj0u9IZZ3TOcU7JY1rwKipn7M3Mi5BCZyfBtwrvpvKyRUTtCRjz2F1h4w+OuMXk2sd L1hmFtppiU984pt3hFA1W4m8Sq8QtyAAAhS6NfeSkUGB8nRlk/qKYqD1gl++XUge3cUT fFxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fulpbebZodsE9QlmRO1W9Cc4c4s3GxA3dS4MXdMbiZ0=; b=hC+kbTKED+GfkivCEDeXZdSqZ9XwQFrskeYXQ/zHFQH4JWYM27YdwS4FjnPP18wL+5 aJdumAEwZpbwbqgaU1zCdFZrTjPc9Y1zlY7xIorjhZfOlARa1le8iMe3UuzFBXCJSpfg ccR7UmsHkVpTOl7qGY2a+Tj9sB/0H/yueCffpKUyJoNsnVBdDz7OOSUCb00ssHq2M3GL 2Bf7fnGV5yb05a11AbYc4EzTq5VSLizoauK2bApRoel8U5ub984J0TQatdgHLeufO02f 3V+1Voq2rEO4Af1hu9bXDgvZ/j9Qb7dw9wYFXkqfa+hGiq5EJT/v1mnlH4rYTxICcc49 0/Fw== X-Gm-Message-State: APjAAAUU3n+B4yUpxP52OmDU5gRQ2x9pgKZ4wzmv3wgfcfS5zwuFZCq6 UU7yxfip6fDdliulDmGyaMQOlFPKn2ww/4QJOi9Zmg== X-Google-Smtp-Source: APXvYqw+vMJD3ENYsSaDOq1egrkeE0yU79xVylxPUb/75fSVAcx6vO5A2ZjMWxSz6FFA9S4sZ3wXquLN8Fx6FsdTd4w= X-Received: by 2002:aca:f354:: with SMTP id r81mr3740770oih.90.1578589467587; Thu, 09 Jan 2020 09:04:27 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Thu, 9 Jan 2020 09:04:25 -0800 (PST) In-Reply-To: <20200109094537.GY8801@faui48f.informatik.uni-erlangen.de> References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> <265A560E-F07F-4CB8-8D5F-6077D1419CE5@comcast.net> <20200109094537.GY8801@faui48f.informatik.uni-erlangen.de> From: Guntur Wiseno Putra Date: Fri, 10 Jan 2020 00:04:25 +0700 Message-ID: To: Toerless Eckert Cc: John Day , Andrew Campling , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000763991059bb800e7" Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 17:04:32 -0000 --000000000000763991059bb800e7 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, (It seems contradictory yet happen: "centralization" to "diversity/heterogeneity" as a network condition...?) Toward the problematic issues on "centralization" on Internet practice, such a way to arrive there is about (re)considering "network conditions": here we meet with diversity/heterogeneity as the Internet draft mentioned "Centralized Architecture on Internet Infrastructure". What does it mean by "centralization" thus...? --how does it work/mean/value for diversity/heterogeneity...? For diversity/heterogeneity as a network condition we may refer to "liquid architecture" (1) of which other things with nuances deserve to mention: "bloobs"(2), "plasm"(3), "plasmatic"(4) and "plasmatics"(5). Thus we are also saying about a spatial analysis of a network condition as it is about cyberspace, about Internet --and we may plan things strategically about the space... - we may think of Internet as one among other collective matters yet it is also one among other personal matters: those matters are maintaining dialogues. Is it not so...in considering Internet sustainability? --at least we find that Internet has a significance for planning societies of nations initiated by the United Nations (see "Leveraging Tech...") (1) "...Liquid architecture makes liquid cities, cities that change at the shift of a value, where visitors with different backgrounds sec different landmarks, where neighborhoods vary with ideas held in common, and evolve as the ideas mature or dissolve". (Novak, Marcos, "Liquid Architecture in Cyberspace" (1991) https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf) (2) "bloobs" refers to "active element or primitive generatiing their own spaces... (with possibilities of) unpredictable reciprocal deformations". (Massumi, Brian, "Interface and Active Space", in Cheetam, M. A, "Kant, Art and Art History: Moments of Disciplines, Cambridge University Press, Cambridge et all., 2001, p. 25; Cheetam refered Massumi's "Interface and Active Space: Human-Machine Design" available at http://www anu.edu/HRC/firs t_and_last/links/massumi_works.htm) (3) plasm refers to "a mould of matrix in which something is cast or formed"; "plasma" refers to "living matter of a cell" and to "liquid part of blood in which corpuscles float"; then, plasmatic refers to what is related with "plasm" or "plasma". "Plasmatic" may be applied to refer to "disciplinary interactions ...(having) ...multidimensional and shifting cultural intensities, and that the specific contours of this matric are inflected historically by the forces of which it is comprised ... (--) ...a model of complexity and flexibility allowing us to understand how an active element in the system... can shape and be shaped by disciplines. (Cheetam, M. A, "Kant, Art and Art History: Moments of Disciplines, Cambridge University Press, Cambridge et all., 2001, p. 25) Regard, Guntur Wiseno Putra Pada Kamis, 09 Januari 2020, Toerless Eckert menulis: > Good insights about the outcome of PICS. > > To clarify, i am primarily interested to see if we can do something > to better support static network planning and protocol evolution. > > Something which is more a self-declaration than a (broken) conformance > suite "verified" testing result. Something which always must be > followed by appropriate testing (interop, deployment) depending > on the goal. But something that can help to faster get to that > step. Something to to help avoid horrenduously repetitive RFP questions > by poor customers (does your IETF FOO protocol on your product support > the optional BAR feature). > > One could think of another axis of information in our yang models, > a subset of "implementation defined" behavior whose values can be > statically exposed without access to a live system and hence be > published and then used in netork planning for example > (or auto-collection by a curious WG trying to progress some > standard to full internet ;-)). > > I was interested in the type of information i remember to have seen > in the 90th in PICS, i am horrified about the process i learn > about it here in te thread ;-) > > Cheers > Toerless > > On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote: > > FWIW, there were also problems with keeping the test suites up-to-date > with the errata. Bugs could be fixed in the standards and incorporated > into implementations faster than the people developing the test suites > could keep up (or wanted to). Of course the fixes were in the > implementations before they were in the standards. And what was worse, when > pointed out to them that their test-suited didn???t conform to the spec, > they didn???t care. They still insisted they were right. > > > > For some standards, it was possible to develop utilities that did a > specific function and used part of a standard to do that function but > didn???t need the rest of the standard. But the people running the test > suites couldn???t deal with it. If it didn???t implement the entire > protocol, it didn???t pass. The utility couldn???t cause any of the rest of > the protocol to be generated. It conformed to the standard for everything > it did. They were using the standard as it had been intended. > > > > But the testers were effectively bean-counters and totally stupid. > > > > Conformance fell under the ANSI committee I chaired and I remember > writing them (some military base in Arizona whose name I have thankfully > forgotten) nasty letters telling them to get their act together or get out. > They were doing more harm than good. Wish we had known about the IS-IS > issues as well to add to the list. > > > > One needs some way to test implementations before trying them live. But > one has to treat them (and it has to be instilled in the testers) that the > purpose is to help: obey Postel???s rule, find problems, and then > determine whether it is the tests, the ???standard??? or the new > implementation that is at fault. And above all if it isn???t externally > visible, it is none of the tester???s business. Even if there is ???formal > specification???, one can???t be sure that a bug is in the prose, the > formal spec, the tests, or the implementation. They are all suspect. (Often > formal specifications are more complex than the code. And we know what that > means!) > > > > Years before the standards issues arose, I did a survey of testing > methods for our own use. I expected to find that two or three were pretty > effective, pick one or two. What I found were 20 or 25 that were all > pretty effective and the advice was pick 2 or 3 and it didn???t really > matter which ones as long as they were different. (Not the result I was > looking for.) ;-) > > > > Take care, > > John > > > > > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote: > > > > > > > > >> Yes, i was thinking of ISO PICS. But i lost track of those ISO > standards > > >> since the 90th. I guess i would have to see a successfull and still > > >> currently used standard and how its PICS do or do not help. Just > > >> not alot of those ISO specs left in wide deployments, right. > > >> X.500 ? Maybe i can get more insight from the security community. > > > > > > > > > You need not go that far. Remember IS-IS? Still thriving. > > > > > > And yes, my experience with PICs and test suites comes from that. > > > > > > > > >>> What it does do is to encourage people to write ???conformance test > suites???. These then get sold to unsuspecting customers and end-users. > Unfortunately, the quality of such suites is so low that you spend way, > way, way more time debugging the test suite and you never find bugs in your > implementation. > > >> > > >> This is just the worst possible outcome, and i am sure one can learn > > >> from those bad experiences. Just think of taking a more organized > > >> step towards being able to collect protocol implementation information > > >> from the industry. Right now every WG who wants to raise the level of > > >> an IETF protocol, e.g.: to(wards) full standard is coming up with a > > >> questionaire in an ad-hoc fashion (we're just doing this in Multicast > > >> for IGMP/MLD). > > > > > > > > > You can do that if you like, but the one proven, effective method is > interoperability testing. > > > > > > Running code trumps questionaires, conformance test suites, theory, > and mandate. > > > > > > > > >> My point was: If the only murphy you have is competitive pressure, it > works not > > >> it there is only limited competition, such as a total of maybe no > > >> more than 3 competing national infrastructures. > > > > > > > > > And countries that stifle competition inflict vendor lock on > themselves. > > > > > > > > >> See above. The best i think we (IETF) can do is to educate better > about > > >> this by appropriate documents. Certainly some additional protocol work > > >> will result from that. I for once had simple slides 10 years ago how > to fixup > > >> non-dual plane networks to be dual-plane. And maybe we can come up > with > > >> questionaires to get better numbers from actual deployments (the > > >> PICS discussion). > > > > > > > > > The IETF???s job is not education. It does not work as the education > is not requested > > > and not welcome. The IETF???s job is standards and it needs to focus > on that. > > > > > > > > >> Figuring out ideas for a complete ecosystem of monetization and > > >> deployment between competition and regulation is better left for > > >> an ongoing bar-bof with emphasis on bar. > > > > > > > > > I concur. Let???s stop fooling ourselves into thinking that anything > that the IAB/IETF writes has any impact > > > on regulation or economics. > > > > > > > > >> Actually one of the interesting conclusions was that dual-plane in > > >> many cases is really free but deployments often just don't fully > > >> utilize it. > > > > > > > > > I???d agree that it???s close to free. If you accept that you need a > dual-plane approach for resiliency, then > > > adding a second vendor to the mix is relatively easy. There???s > additional cost because of decreased > > > purchasing volume. There???s additional costs in management and > operations. > > > > > > However, as compared to the costs of an unnecessary outage, it???s > still trivial. > > > > > > Tony > > > > > > _______________________________________________ > > > Architecture-discuss mailing list > > > Architecture-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > -- > --- > tte@cs.fau.de > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000763991059bb800e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

(It seems contradictory yet h= appen: "centralization" to "diversity/heterogeneity" as= a network condition...?)

Toward the problematic i= ssues on "centralization" on Internet practice, such a way to arr= ive there is about (re)considering "network conditions": here we = meet with diversity/heterogeneity as the Internet draft mentioned "Cen= tralized Architecture on Internet Infrastructure". What does it mean b= y "centralization" thus...? --how does it work/mean/value for div= ersity/heterogeneity...?

For diversity/heterogenei= ty as a network condition we may refer to "liquid architecture" (= 1) of which other things with nuances deserve to mention: "bloobs"= ;(2), "plasm"(3), "plasmatic"(4) and "plasmatics&q= uot;(5). Thus we are also =C2=A0saying about a spatial analysis of a networ= k condition as it is about cyberspace, about Internet --and we may plan thi= ngs strategically about the space...

- we may thin= k of Internet as one among other collective matters yet it is also one amon= g other personal matters: =C2=A0those matters are maintaining dialogues. Is= it not so...in considering Internet sustainability? --at least we find tha= t Internet has a significance for planning societies of nations initiated b= y the United Nations (see "Leveraging Tech...")


(1) "...Liquid architecture makes= liquid cities, cities that change at the shift of a value, where visitors = with different backgrounds sec different landmarks, where neighborhoods var= y with ideas held in common, and evolve as the ideas mature or dissolve&quo= t;. (Novak, Marcos, "Liquid Architecture in Cyberspace" (1991) = =C2=A0=C2=A0
=

(2) "bloobs" refers to "active element o= r primitive generatiing their own spaces... (with possibilities of) unpredi= ctable reciprocal deformations".=C2=A0
(Massumi, Brian, &quo= t;Interface and Active Space", =C2=A0in Cheetam, M. A, "Kant, Art= and Art History: Moments of Disciplines, Cambridge University Press, Cambr= idge et all., 2001, p. 25; Cheetam refered Massumi's "Interface an= d Active Space: Human-Machine Design" available at=C2=A0http://www=C2=A0anu.edu/HRC/first_and_last/links/= massumi_works.htm)

(3) plasm refers to &q= uot;a mould of matrix in which something is cast or formed"; "pla= sma" refers to "living matter of a cell" and to "liquid= part of blood in which corpuscles float"; then, plasmatic refers to w= hat is related with "plasm" or "plasma". "Plasmati= c" may be applied to refer to "disciplinary interactions ...(havi= ng) ...multidimensional and shifting cultural intensities, and that the spe= cific contours of this matric are inflected historically by the forces of w= hich it is comprised ... (--) ...a model of complexity and flexibility allo= wing us to understand how an active element in the system... can shape and = be shaped by disciplines. (Cheetam, M. A, "Kant, Art and Art History: = Moments of Disciplines, Cambridge University Press, Cambridge et all., 2001= , p. 25)

Regard,
Guntur Wiseno Putra
=
Pada Kamis, 09 Januari 2020, Toerless Eckert <tte@cs.fau.de> menulis:
Good insights about the outcome of PICS.

To clarify, i am primarily interested to see if we can do something
to better support static network planning and protocol evolution.

Something which is more a self-declaration than a (broken) conformance
suite "verified" testing result. Something which always must be followed by appropriate testing (interop, deployment) depending
on the goal. But something that can help to faster get to that
step. Something to to help avoid horrenduously repetitive RFP questions
by poor customers (does your IETF FOO protocol on your product support
the optional BAR feature).

One could think of another axis of information in our yang models,
a subset of "implementation defined" behavior whose values can be=
statically exposed without access to a live system and hence be
published and then used in netork planning for example
(or auto-collection by a curious WG trying to progress some
standard to full internet ;-)).

I was interested in the type of information i remember to have seen
in the 90th in PICS, i am horrified about the process i learn
about it here in te thread ;-)

Cheers
=C2=A0 =C2=A0 Toerless

On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote:
> FWIW, there were also problems with keeping the test suites up-to-date= with the errata.=C2=A0 Bugs could be fixed in the standards and incorporat= ed into implementations faster than the people developing the test suites c= ould keep up (or wanted to). Of course the fixes were in the implementation= s before they were in the standards. And what was worse, when pointed out t= o them that their test-suited didn???t conform to the spec, they didn???t c= are. They still insisted they were right.
>
> For some standards, it was possible to develop utilities that did a sp= ecific function and used part of a standard to do that function but didn???= t need the rest of the standard. But the people running the test suites cou= ldn???t deal with it. If it didn???t implement the entire protocol, it didn= ???t pass. The utility couldn???t cause any of the rest of the protocol to = be generated. It conformed to the standard for everything it did. They were= using the standard as it had been intended.
>
> But the testers were effectively bean-counters and totally stupid.
>
> Conformance fell under the ANSI committee I chaired and I remember wri= ting them (some military base in Arizona whose name I have thankfully forgo= tten) nasty letters telling them to get their act together or get out. They= were doing more harm than good. Wish we had known about the IS-IS issues a= s well to add to the list.
>
> One needs some way to test implementations before trying them live.=C2= =A0 But one has to treat them (and it has to be instilled in the testers) t= hat the purpose is to help:=C2=A0 obey Postel???s rule, find problems, and = then determine whether it is the tests, the ???standard??? or the new imple= mentation that is at fault. And above all if it isn???t externally visible,= it is none of the tester???s business.=C2=A0 Even if there is ???formal sp= ecification???, one can???t be sure that a bug is in the prose, the formal = spec, the tests, or the implementation. They are all suspect. (Often formal= specifications are more complex than the code. And we know what that means= !)
>
> Years before the standards issues arose, I did a survey of testing met= hods for our own use. I expected to find that two or three were pretty effe= ctive, pick one or two.=C2=A0 What I found were 20 or 25 that were all pret= ty effective and the advice was pick 2 or 3 and it didn???t really matter w= hich ones as long as they were different. (Not the result I was looking for= .)=C2=A0 ;-)
>
> Take care,
> John
>
> > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote:
> >
> >
> >> Yes, i was thinking of ISO PICS. But i lost track of those IS= O standards
> >> since the 90th. I guess i would have to see a successfull and= still
> >> currently used standard and how its PICS do or do not help. J= ust
> >> not alot of those ISO specs left in wide deployments, right.<= br> > >> X.500 ? Maybe i can get more insight from the security commun= ity.
> >
> >
> > You need not go that far.=C2=A0 Remember IS-IS?=C2=A0 Still thriv= ing.=C2=A0
> >
> > And yes, my experience with PICs and test suites comes from that.=
> >
> >
> >>> What it does do is to encourage people to write ???confor= mance test suites???.=C2=A0 These then get sold to unsuspecting customers a= nd end-users.=C2=A0 Unfortunately, the quality of such suites is so low tha= t you spend way, way, way more time debugging the test suite and you never = find bugs in your implementation.
> >>
> >> This is just the worst possible outcome, and i am sure one ca= n learn
> >> from those bad experiences. Just think of taking a more organ= ized
> >> step towards being able to collect protocol implementation in= formation
> >> from the industry. Right now every WG who wants to raise the = level of
> >> an IETF protocol, e.g.: to(wards) full standard is coming up = with a
> >> questionaire in an ad-hoc fashion (we're just doing this = in Multicast
> >> for IGMP/MLD).
> >
> >
> > You can do that if you like, but the one proven, effective method= is interoperability testing.
> >
> > Running code trumps questionaires, conformance test suites, theor= y, and mandate.
> >
> >
> >> My point was: If the only murphy you have is competitive pres= sure, it works not
> >> it there is only limited competition, such as a total of mayb= e no
> >> more than 3 competing national infrastructures.
> >
> >
> > And countries that stifle competition inflict vendor lock on them= selves.
> >
> >
> >> See above. The best i think we (IETF) can do is to educate be= tter about
> >> this by appropriate documents. Certainly some additional prot= ocol work
> >> will result from that. I for once had simple slides 10 years = ago how to fixup
> >> non-dual plane networks to be dual-plane. And maybe we can co= me up with
> >> questionaires to get better numbers from actual deployments (= the
> >> PICS discussion).
> >
> >
> > The IETF???s job is not education. It does not work as the educat= ion is not requested
> > and not welcome. The IETF???s job is standards and it needs to fo= cus on that.
> >
> >
> >> Figuring out ideas for a complete ecosystem of monetization a= nd
> >> deployment between competition and regulation is better left = for
> >> an ongoing bar-bof with emphasis on bar.
> >
> >
> > I concur. Let???s stop fooling ourselves into thinking that anyth= ing that the IAB/IETF writes has any impact
> > on regulation or economics.
> >
> >
> >> Actually one of the interesting conclusions was that dual-pla= ne in
> >> many cases is really free but deployments often just don'= t fully
> >> utilize it.
> >
> >
> > I???d agree that it???s close to free.=C2=A0 If you accept that y= ou need a dual-plane approach for resiliency, then
> > adding a second vendor to the mix is relatively easy. There???s a= dditional cost because of decreased
> > purchasing volume. There???s additional costs in management and o= perations.
> >
> > However, as compared to the costs of an unnecessary outage, it???= s still trivial.
> >
> > Tony
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architec= ture-discuss

--
---
tte@cs.fau.de

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--000000000000763991059bb800e7-- From nobody Thu Jan 9 09:36:34 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CD712001A; Thu, 9 Jan 2020 09:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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=nostrum.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 QHoGr6nYK3Vp; Thu, 9 Jan 2020 09:36:30 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6B33C120019; Thu, 9 Jan 2020 09:36:30 -0800 (PST) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 009HaPf2056092 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Jan 2020 11:36:26 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578591389; bh=tntLVFRA+GgpAfj61NhBojH71PktnbsLACjVKDN45gA=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=mUZ7DeSIzXcQ8oV6bkXh1ftBFVDdEBpYd+a9g7h8Bbt3Nz3gfQ24zOcL5h5yx811m WfEo3C7jm/CBkmRBYuN3PBAtUc00gi/Mhjc+47WRVeBBG7nTRSVbc5KfB+idYe9QFY kAGll7BKvV+o+J6EmzsziG7wNV53DeG3ywpaI6ec= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Message-Id: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7791B92E-E578-4D91-BC5A-B20455E83642"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Thu, 9 Jan 2020 11:36:17 -0600 In-Reply-To: Cc: IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org To: Richard Barnes References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 17:36:33 -0000 --Apple-Mail=_7791B92E-E578-4D91-BC5A-B20455E83642 Content-Type: multipart/alternative; boundary="Apple-Mail=_EF74CBB8-C91D-443B-93A5-44947A227B80" --Apple-Mail=_EF74CBB8-C91D-443B-93A5-44947A227B80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I also wondered why CoI on technical matters is any different for IAB = members than for people participating in protocol design in working = groups. That concern is somewhat mitigated by the fact that the third bullet = (discussing technical CoI) only requires the exercise of judgement. But = I hope we expect IAB members to exercise judgement in all aspects of the = role :-) Ben. > On Jan 9, 2020, at 10:57 AM, Richard Barnes wrote: >=20 > I would propose the IAB not adopt this policy, or at least scope it = way down. >=20 > Much of the IAB's work is focused on technical issues, at a high = enough strategic level that the impacts to specific people or companies = are highly attenuated. In those discussions, the IAB's work benefits = from having diverse opinions, including the opinions of those who have = skin in the game. Trying to introduce some notion of CoI in this = context would be harmful -- because there's no hard conflict, it will = inevitably be vague, and thus primarily a tool for IAB members to try to = silence one another or a cause for IAB members to self-censor. >=20 > Where the IAB is directly involved in finance or personnel decisions, = there of course should be guards against self dealing. That's where any = CoI policy for the IAB should stop. >=20 > --Richard >=20 > On Wed, Jan 8, 2020 at 6:16 PM IAB Chair > wrote: > Dear Colleagues, >=20 > The IAB is considering adoption of the conflict of interest policy = below. If you have comments on this draft policy, please send them to = iab@iab.org . >=20 > best regards, >=20 > Ted Hardie > for the IAB >=20 >=20 >=20 > INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >=20 > This policy covers the nomcom-selected Internet Architecture Board = (IAB) members and ex-officio members (collectively, =E2=80=9CCovered = Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the = IAB or IAB program members. >=20 > In carrying out their IAB role, Covered Individuals must act in the = best interest of the Internet community. Occasionally this duty may = be=E2=80=94or may appear to be=E2=80=94incompatible or in conflict with = a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which = the Covered Individual is an employee, director, owner, or otherwise has = business or financial interest. If a Covered Individual has a conflict = of interest for whatever reason, that individual must avoid = participating in the work of the IAB that touches on the related matter. >=20 > The IAB does not directly deal with matters relating to contracts or = finance. The IAB does, however, have a role in personnel decisions, and = its decisions and outputs have a potential to indirectly affect = contracts within the IETF system. IAB's technical decisions and outputs = have also a potential to impact both work elsewhere in the IETF and = businesses that employ or develop Internet technology. >=20 > Covered Individuals shall not use the IAB=E2=80=99s resources or = decisions as a means for personal or third-party gain. >=20 > Disclosure of Actual or Potential Conflicts >=20 > The IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates. >=20 > In addition, when a topic is discussed at the IAB, the Covered = Individuals are required to promptly disclose if that topic constitutes = a perceived or potential conflict of interest. Once disclosed, Covered = Individuals may recuse from participation in discussions or decisions at = their discretion. >=20 > The specific conflicts that may cause a perceived or potential = conflict of interest are matters for individual and IAB judgment, but = generally come in the following forms: >=20 > A personnel decision relates to the Covered Individual, a colleague = that the Covered Individual's works closely with, or a family member. = For the purposes of this policy, a "person working closely with" is = someone working in the same team or project, or a direct manager or = employee of the Covered Individual. And "family" means a spouse, = domestic partner, child, sibling, parent, stepchild, stepparent, and = mother-, father-, son-, daughter-, brother-, or sister-in-law, and any = other person living in the same household, except tenants and household = employees. >=20 > A decision or output from the IAB impacts a contract that the IETF = enters into with a party, and that party relates to the Covered = Individual, a colleague that the Covered Individual's works closely = with, or a family member. >=20 > Activity on the IAB involves discussion and decisions regarding = technical matters, mainly related to IETF activities. As an activity = adjacent to a standardization process, it is often the case that Covered = Individuals will have some (frequently non-financial) stake in the = outcome of discussions or decisions that relate to technical matters. = This policy does not require that Covered Individuals disclose such = conflicts of interest as they relate to technical matters. However, = Covered Individuals need to exercise their judgment and, in = extraordinary cases be willing to disclose potential or perceived = conflicts of interest even as they relate to technical matters. For = example, if a Covered Individual's sponsor were in the process of = entering a new market where there is an ongoing IAB discussion, then = disclosure, or even recusal, might be appropriate, even if difficult. >=20 > Disclosure Transparency >=20 > A person's recusal to participate in the discussion of a topic is = always noted in the public IAB minutes. In addition, the IAB will = maintain a repository of all general disclosures of employment and other = sponsorship. It is expected that much of this repository is public, but = there can be situations where some disclosures (such as customers of = consultants) are private. >=20 >=20 > = >=20 --Apple-Mail=_EF74CBB8-C91D-443B-93A5-44947A227B80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = also wondered why CoI on technical matters is any different for IAB = members than for people participating in protocol design in working = groups. 

That = concern is somewhat mitigated by the fact that the third bullet = (discussing technical CoI) only requires the exercise of judgement. But = I hope we expect IAB members to exercise judgement in all aspects of the = role :-)

Ben.


On = Jan 9, 2020, at 10:57 AM, Richard Barnes <rlb@ipv.sx> wrote:

I would propose the IAB not adopt this = policy, or at least scope it way down.

Much of the IAB's work is focused on = technical issues, at a high enough strategic level that the impacts to = specific people or companies are highly attenuated.  In those = discussions, the IAB's work benefits from having diverse opinions, = including the opinions of those who have skin in the game.  Trying = to introduce some notion of CoI in this context would be harmful -- = because there's no hard conflict, it will inevitably be vague, and thus = primarily a tool for IAB members to try to silence one another or a = cause for IAB members to self-censor.

Where the IAB is = directly involved in finance or personnel decisions, there of course = should be guards against self dealing.  That's where any CoI policy = for the IAB should stop.

--Richard

On Wed, Jan = 8, 2020 at 6:16 PM IAB Chair <iab-chair@iab.org> wrote:
=20 =20 =20

Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please = send them to iab@iab.org.

best regards,

Ted Hardie
for the IAB



INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST = POLICY

This policy covers the nomcom-selected Internet = Architecture Board (IAB) members and ex-officio members (collectively, = =E2=80=9CCovered Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB = role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in = conflict with a Covered Individual=E2=80=99s personal interests (including = interests of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not = directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals = shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their = main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the = Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The = specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the = Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB = impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves = discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's = recusal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.




= --Apple-Mail=_EF74CBB8-C91D-443B-93A5-44947A227B80-- --Apple-Mail=_7791B92E-E578-4D91-BC5A-B20455E83642 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----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl4XZJEACgkQgFZKbJXz 1A0TlRAAmZAmBvD5kK3F5BHL8hQZsofipiWzxgcOA35FL2b5d48aOzn7qw6l+T2N ZdNVZ3ma7AkOo900Pgf1knUEsvwoC1y9E5GoO1BvFoBsH2hjNb0ffmVy4YnDm29y GmYxJCQXDgawnhWOflOPx8nm/Cmln6AhcXhpSrE26FmobZFHj/P0xlZJJ+Vv8k01 hOmlauv/eo71B3hJ4+unKaB847ceonE+FsQiVMvSZ7Rmlf6hx8IUKq2ryPnwuK1a GHvtwkB7RUuZ6HNSO3vfYl0aaLgkYCwxlZf6Z3vCsZPL4h7CCd8naqUHnVARrLQJ Pk2ov86g/R9J3bRPMYHVBdpVEtqWp7D0LdWzJiHr6j3JCLCK40zuNTIyuANzrjMR yoN4tHD6mdPy/+CTYOaY5lfon26E6aQgseZ9eLoNC0XfjeSL3U0/h/g7OrkAXm8J XE4y7yGMbRiHiL40WP39ovI9PQpy4jdxbTJ2Bc03poGI/g2kXVOkDWRWjjVN8vSM HqyXj6JrKWpVoEXoVCnyYzm4/zhzyGah13Q5KRXi/W4tJ0k4HOY3uw+jKJ1UVePo N+RYnGZoM3aToO0IwIFpHOU/Bw5NWbW/J6kLUZPFnbIxOEmwiWnCA5pntUr+Vvii gVD2VsHX9qM8ZS1FFrhCnnl3iPuM/WQCG6KZxqBo+7qUUA+AcSY= =48rJ -----END PGP SIGNATURE----- --Apple-Mail=_7791B92E-E578-4D91-BC5A-B20455E83642-- From nobody Thu Jan 9 09:55:39 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC621200FE; Thu, 9 Jan 2020 09:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 7waRihT_YnZw; Thu, 9 Jan 2020 09:55:35 -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 654CA120019; Thu, 9 Jan 2020 09:55:35 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009Hsmbw024522; Thu, 9 Jan 2020 17:55:34 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=NHMwRGPyQDxFea6jd/r+XOLwTkE2oO6A1D7lZf2aX0Q=; b=GIjWVaIKM6R03rGJVqfRSSSB3g26fOW3qkEzwTZU/UBLtyhgrsDaurek74J3QgFrlNIC u5LZyR7Ud7z0dGBxnnkRsLfNyoKFC0HL0d9Ol6n7lHoFPtD4PpTpLxvLlXe5F+i4OgDu lg/EJyDq3KHKupxO9nsl6uCk0uvX+Sz78ItTicupSPrIvg1XYIXTSR74dz8rqt5HV+xR 1Xw/4XVc6pBlQh9+Iw7DhHcOsRvp/K2sIhGaseuNKodmmCi5fkx/uSA3QP9iHBhmUbNp utZnTAQPamkbvwBPXa//RuMwIPVqPBKlwA72Aq8TYuDxTOFypVl7ldFAmxM5U8AcEAnM iQ== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2xdbv7nshg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 17:55:34 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 009HlWVm011773; Thu, 9 Jan 2020 09:55:33 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint5.akamai.com with ESMTP id 2xasjb4h7w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 09:55:33 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 12:55:32 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 9 Jan 2020 12:55:32 -0500 From: "Salz, Rich" To: Stewart Bryant , John C Klensin CC: IAB Chair , "iab@iab.org" , "ietf@ietf.org" , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmMup37bT2dZUClj9/F6vIplqfipFqAgAAUtQCAAAVtgP//4IiA Date: Thu, 9 Jan 2020 17:55:31 +0000 Message-ID: <815C4AB0-9BFB-4073-BA49-1A8F90B2F0B1@akamai.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <1E62D045-4171-41D6-858A-C277C947AD05@gmail.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.21.0.200104 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.52] Content-Type: text/plain; charset="utf-8" Content-ID: <91166063EC3B9641A0084EA8A662910A@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-09_03:, , 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=865 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001090146 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_03:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 impostorscore=0 clxscore=1011 mlxscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=838 adultscore=0 suspectscore=0 spamscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090146 Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 17:55:37 -0000 PiAgICBJIHN1c3BlY3QgdGhhdCB0aGUgIG9ubHkgd2F5IHRvIGVuc3VyZSB0aGF0IHdlIGhhdmUg YSBmdWxseSB0cnVzdHdvcnRoeSBzeXN0ZW0gaXMgdG8gcmVxdWlyZSBvcGVubmVzcyBhbmQgYWNj ZXB0IHRoYXQgdGhlIGNhbmRpZGF0ZSBwb29sIGlzIHJlZHVjZWQuDQogDQpUaGVyZSBtYXkgYmUg b3RoZXIgd2F5cyB0byBhY2hpZXZlIHRoZSBnb2FsLCBidXQgSSBhZ3JlZSB3aXRoIHRyYW5zcGFy ZW5jeSB0cnVtcHMgYWxsIGFzIHRoZSBkZWZhdWx0Lg0KICAgIA0KICAgIA0KICAgIA0KICAgIA0K ICAgID4gDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Thu Jan 9 10:11:54 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A311200CD; Thu, 9 Jan 2020 10:11:53 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Q4pLmdCYFA6X; Thu, 9 Jan 2020 10:11:51 -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 463C812004C; Thu, 9 Jan 2020 10:11:51 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 009I5KAf001010; Thu, 9 Jan 2020 18:11:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=TqElYi6Uzz27AAS1+gSIRKL9Nuvcooh7XLjEXsF7T+s=; b=fXTTfp9D55Ic2Nwj6FhYRp9So5lOCBI6r4wie3Bb/38WzNuPUtDGr0uc57DaTKP1Kvew AF7CfnzcCWHfXLCxzrmi3acuSD7OzUNA3FzCVZZ2W3ca3crRbmW1NSldNzMmqzAXtqVl O2JeEodRe4xl1itg9gRx9ac7lSzIpYyJnkg/9CiBKR7Vc8VRSTUPEpF0n6K92fB8HXJi yRNRd4EYq+KRIsKYrDTSGFWKaqE/bdXodYDkwvbncajf5npGv+d+thL2/WRLhxz02aEF N0Tg15FwZfOs6QTE+VoiuyCU1m3Rwi9FGeTrY1iRV1WNUxhyRtDwk2k2kwdY/yge+QkW Dg== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2xd9fn6wp0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 18:11:50 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 009I2jhT027036; Thu, 9 Jan 2020 10:11:49 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint5.akamai.com with ESMTP id 2xasjb4mnj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 10:11:49 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 13:11:48 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 9 Jan 2020 13:11:47 -0500 From: "Salz, Rich" To: IAB Chair , "ietf@ietf.org" , "architecture-discuss@ietf.org" , "iab@iab.org" Thread-Topic: Draft IAB conflict of interest policy Thread-Index: AQHVxnmMup37bT2dZUClj9/F6vIplqfio4+A Date: Thu, 9 Jan 2020 18:11:47 +0000 Message-ID: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200104 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.52] Content-Type: multipart/alternative; boundary="_000_C7834943A7AD49D2B748E22A1E82A014akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-09_03:, , 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=888 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001090149 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_03:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0 mlxlogscore=864 spamscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090149 Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 18:11:53 -0000 --_000_C7834943A7AD49D2B748E22A1E82A014akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhc3N1bWUgdGhpcyB3YXMgcmV2aWV3ZWQgYnkgdGhlIGFwcHJvcHJpYXRlL3JlbGV2YW50IGxl Z2FsIGNvdW5zZWw/DQoNCg0K --_000_C7834943A7AD49D2B748E22A1E82A014akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <605CAE39CE8B4F4191FEBFAD65E99DD8@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2MzA0NzU2NDg7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjE3NjU1ODMyMDY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhc3N1bWUgdGhp cyB3YXMgcmV2aWV3ZWQgYnkgdGhlIGFwcHJvcHJpYXRlL3JlbGV2YW50IGxlZ2FsIGNvdW5zZWw/ PG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_C7834943A7AD49D2B748E22A1E82A014akamaicom_-- From nobody Thu Jan 9 10:28:21 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F8D120111; Thu, 9 Jan 2020 10:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 3DGretRDW9oO; Thu, 9 Jan 2020 10:28:17 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 DD6BB120115; Thu, 9 Jan 2020 10:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=H3YOVYAYa2EwnfDp/tKJrAI83CK+X0d7I1XZse0PLek=; b=Zz+OHH28Bj8W6FJZHpqsxX75Lb Ol0G+7JnTMKNgUBmMbeWduMRARiOV/ZeMGEtSxZBt+9UUYdQBgiDoKrXHV2svDko14MZcKQ+xdnXi RKx9x+3QUz44KJZfG8eFZbyTj4zz1H0fnovv2QGvfHyAgHdjCVPob4m7KO/Ioko9pAlvU0ZyMHsQS jrIP15b7ZPspNejBIbrOqFN7GBirKFv/A1ciq6ajN+PpssipBUFcnsXA7dvt1PH1pv440PXzMXe+3 iNpZTbs/QorT6MtUI0Otv9HJHcbpfvS5aqnPl/N5D1w7mPvdhCQM/pE0IPtoca6wOJnE9S9MAtN8+ NZSPC+Gw==; Received: from [38.64.80.138] (port=62000 helo=[172.21.15.51]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ipcXT-003bGO-CA; Thu, 09 Jan 2020 13:28:16 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-D0D97742-66D3-4C65-9B32-0F19E44DB96E Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> Date: Thu, 9 Jan 2020 10:28:10 -0800 Cc: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org Message-Id: References: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> To: Ben Campbell X-Mailer: iPhone Mail (17C54) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 18:28:19 -0000 --Apple-Mail-D0D97742-66D3-4C65-9B32-0F19E44DB96E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable They and IESG members are in positions of decision.=20 Others are not.=20 Joe > On Jan 9, 2020, at 9:37 AM, Ben Campbell wrote: >=20 > =EF=BB=BFI also wondered why CoI on technical matters is any different for= IAB members than for people participating in protocol design in working gro= ups.=20 >=20 > That concern is somewhat mitigated by the fact that the third bullet (disc= ussing technical CoI) only requires the exercise of judgement. But I hope we= expect IAB members to exercise judgement in all aspects of the role :-) >=20 > Ben. >=20 >=20 >> On Jan 9, 2020, at 10:57 AM, Richard Barnes wrote: >>=20 >> I would propose the IAB not adopt this policy, or at least scope it way d= own. >>=20 >> Much of the IAB's work is focused on technical issues, at a high enough s= trategic level that the impacts to specific people or companies are highly a= ttenuated. In those discussions, the IAB's work benefits from having divers= e opinions, including the opinions of those who have skin in the game. Tryi= ng to introduce some notion of CoI in this context would be harmful -- becau= se there's no hard conflict, it will inevitably be vague, and thus primarily= a tool for IAB members to try to silence one another or a cause for IAB mem= bers to self-censor. >>=20 >> Where the IAB is directly involved in finance or personnel decisions, the= re of course should be guards against self dealing. That's where any CoI po= licy for the IAB should stop. >>=20 >> --Richard >>=20 >> On Wed, Jan 8, 2020 at 6:16 PM IAB Chair wrote: >>> Dear Colleagues, >>>=20 >>> The IAB is considering adoption of the conflict of interest policy below= . If you have comments on this draft policy, please send them to iab@iab.or= g. >>>=20 >>> best regards, >>>=20 >>> Ted Hardie >>> for the IAB >>>=20 >>>=20 >>>=20 >>> INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >>>=20 >>> This policy covers the nomcom-selected Internet Architecture Board (IAB)= members and ex-officio members (collectively, =E2=80=9CCovered Individuals=E2= =80=9D). This policy has no impact on any other participants in IAB activiti= es, for instance liaisons to and from the IAB or IAB program members. >>>=20 >>> In carrying out their IAB role, Covered Individuals must act in the best= interest of the Internet community. Occasionally this duty may be=E2=80=94o= r may appear to be=E2=80=94incompatible or in conflict with a Covered Indivi= dual=E2=80=99s personal interests (including interests of their family membe= rs), or the interests of an organization of which the Covered Individual is a= n employee, director, owner, or otherwise has business or financial interest= . If a Covered Individual has a conflict of interest for whatever reason, th= at individual must avoid participating in the work of the IAB that touches o= n the related matter. >>>=20 >>> The IAB does not directly deal with matters relating to contracts or fin= ance. The IAB does, however, have a role in personnel decisions, and its dec= isions and outputs have a potential to indirectly affect contracts within th= e IETF system. IAB's technical decisions and outputs have also a potential t= o impact both work elsewhere in the IETF and businesses that employ or devel= op Internet technology. >>>=20 >>> Covered Individuals shall not use the IAB=E2=80=99s resources or decisio= ns as a means for personal or third-party gain. >>>=20 >>> Disclosure of Actual or Potential Conflicts >>>=20 >>> The IAB requires that all Covered Individuals disclose their main employ= ment, sponsorship, consulting customer, or other sources of income when join= ing the IAB or whenever there are updates. >>>=20 >>> In addition, when a topic is discussed at the IAB, the Covered Individua= ls are required to promptly disclose if that topic constitutes a perceived o= r potential conflict of interest. Once disclosed, Covered Individuals may re= cuse from participation in discussions or decisions at their discretion. >>>=20 >>> The specific conflicts that may cause a perceived or potential conflict o= f interest are matters for individual and IAB judgment, but generally come i= n the following forms: >>>=20 >>> A personnel decision relates to the Covered Individual, a colleague that= the Covered Individual's works closely with, or a family member. For the pu= rposes of this policy, a "person working closely with" is someone working in= the same team or project, or a direct manager or employee of the Covered In= dividual. And "family" means a spouse, domestic partner, child, sibling, par= ent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-,= or sister-in-law, and any other person living in the same household, except= tenants and household employees. >>>=20 >>> A decision or output from the IAB impacts a contract that the IETF enter= s into with a party, and that party relates to the Covered Individual, a col= league that the Covered Individual's works closely with, or a family member.= >>>=20 >>> Activity on the IAB involves discussion and decisions regarding technica= l matters, mainly related to IETF activities. As an activity adjacent to a s= tandardization process, it is often the case that Covered Individuals will h= ave some (frequently non-financial) stake in the outcome of discussions or d= ecisions that relate to technical matters. This policy does not require that= Covered Individuals disclose such conflicts of interest as they relate to t= echnical matters. However, Covered Individuals need to exercise their judgme= nt and, in extraordinary cases be willing to disclose potential or perceived= conflicts of interest even as they relate to technical matters. For example= , if a Covered Individual's sponsor were in the process of entering a new ma= rket where there is an ongoing IAB discussion, then disclosure, or even recu= sal, might be appropriate, even if difficult. >>>=20 >>> Disclosure Transparency >>>=20 >>> A person's recusal to participate in the discussion of a topic is always= noted in the public IAB minutes. In addition, the IAB will maintain a repos= itory of all general disclosures of employment and other sponsorship. It is e= xpected that much of this repository is public, but there can be situations w= here some disclosures (such as customers of consultants) are private. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail-D0D97742-66D3-4C65-9B32-0F19E44DB96E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
They and IESG members are i= n positions of decision. 

Others are not. 

J= oe

On Jan 9, 2020, at 9:= 37 AM, Ben Campbell <ben@nostrum.com> wrote:

=EF=BB=BFI also wondered why CoI on= technical matters is any different for IAB members than for people particip= ating in protocol design in working groups. 

That concern is somewhat mitigated by the fact that= the third bullet (discussing technical CoI) only requires the exercise of j= udgement. But I hope we expect IAB members to exercise judgement in all aspe= cts of the role :-)

Ben.

On Ja= n 9, 2020, at 10:57 AM, Richard Barnes <rlb@ipv.sx> wrote:

I would propo= se the IAB not adopt this policy, or at least scope it way down.

Much of the IAB's work is foc= used on technical issues, at a high enough strategic level that the impacts t= o specific people or companies are highly attenuated.  In those discuss= ions, the IAB's work benefits from having diverse opinions, including the op= inions of those who have skin in the game.  Trying to introduce some no= tion of CoI in this context would be harmful -- because there's no hard conf= lict, it will inevitably be vague, and thus primarily a tool for IAB members= to try to silence one another or a cause for IAB members to self-censor.

Where= the IAB is directly involved in finance or personnel decisions, there of co= urse should be guards against self dealing.  That's where any CoI polic= y for the IAB should stop.

--Richard

On Wed, Jan 8, 2020 at 6:16= PM IAB Chair <iab-chair@= iab.org> wrote:
=20 =20 =20
<= /font>

Dear Colleagues,

The I= AB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please send them to iab@iab.org.<= /font>

best regards,

Ted Hardie
for the IAB



INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY

This policy covers the nomcom-selected Internet Architectur= e Board (IAB) members and ex-officio members (collectively, =E2=80=9CCov= ered Individuals=E2=80=9D). This policy has no impact on any other particip= ants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB role, C= overed Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in con= flict with a Covered Individual=E2=80=99s personal interests (including interests o= f their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not direc= tly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals shal= l not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The spe= cific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Cover= ed Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts= a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion a= nd decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's recu= sal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.




__________________= _____________________________
Architecture-discuss mailing l= ist
Architecture-discuss@ietf.org
https://ww= w.ietf.org/mailman/listinfo/architecture-discuss
= --Apple-Mail-D0D97742-66D3-4C65-9B32-0F19E44DB96E-- From nobody Thu Jan 9 10:47:39 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B7612011D for ; Thu, 9 Jan 2020 10:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 dUlZHOeXFTR3 for ; Thu, 9 Jan 2020 10:47:36 -0800 (PST) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1A3120052 for ; Thu, 9 Jan 2020 10:47:35 -0800 (PST) Received: by mail-lj1-x243.google.com with SMTP id y4so8335011ljj.9 for ; Thu, 09 Jan 2020 10:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3h2LbRbuwpuCqcAwnux4Xdy2qyxCgxfFwPuqvlhNdnU=; b=RXGr0Iw1sz4gX6B9X9MiiS8HeBzFVfLDBVjA8LE2KG4/HZf0PbFmIdXgDTRCsAR1nN W5akOylu/xT8luRwyjVLw3Tp0pcaT4ENSEILp2iMmIKQaaDWykzxtQBaStaGnDS2+ypc FgK3UtRMC6DYvWkaEJuK94/1RE1T0n1hu80X2i2BFcinLI2NjZAeHxe1XR7Y58VkGiNl i+W7XbvYBM546Ollle4HkBTwMRScHNUMFmR4E00K0m7DpfT4NG3RQmm1ZE4ORataPhyC Oox93pjbrgId2fcsfHqkWgTvbVkejA2g2+PBig3rIpl02/wOlJnmoZ674axHi40dwWWg cDBQ== 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=3h2LbRbuwpuCqcAwnux4Xdy2qyxCgxfFwPuqvlhNdnU=; b=CQVAt/ZEe1a/DpG+iyons1oIFFoF4TMqxj3rADKqfwd6GPR9ApqhioIC2984AsYmgc kfe0iK0Te7JoUSFRilXLcaNH+W8FfPAcLnyJvwsYf1DDUlY8TfFjInRIFgB+IdYU+hX0 EZG7hQg8xn2+Y0zNuP1qcWQo82mOuSYJuvNKHCm+fGyOvuIx+IpFZtodHAOpQDTaYAoB foOnivQfnb0JdiwJZsPQNMl8aKeJ12tC3ee19lhAv2nJ3+R9+o4u7RDt4iW2Lw4DHokL VsCKAAzhuAAnKAzkOpYp7MddQ6fJVTXBbF11zpni6ckb+ZxQM0+T7HcSxsnnnIa1uBsV ptPQ== X-Gm-Message-State: APjAAAUirQ993Nr+B/8GfwI5idEEzgNREbML9dsfhXrnXw1pavMR7s2E 8MajQPaGwaXtVnWN3F7906BvlcNSBcS4X0FL07wEvQ== X-Google-Smtp-Source: APXvYqxf7j5LS+gwOxVATwTAK/JU1EGzFDDzA/m2XzBgdClA8jZahyQE/q1NQwARCO+I8+7nrfs3OTq3g4wISc51piI= X-Received: by 2002:a05:651c:239:: with SMTP id z25mr7735646ljn.48.1578595653970; Thu, 09 Jan 2020 10:47:33 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: From: Eric Rescorla Date: Thu, 9 Jan 2020 10:46:57 -0800 Message-ID: To: Richard Barnes Cc: IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000330b34059bb9719e" Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 18:47:38 -0000 --000000000000330b34059bb9719e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I concur with Richard here. The IETF is most successful when we get input from people who are directly involved in the technologies that we are standardizing, but of course that very often means that they are working on those technologies for their employer. And indeed one of the criteria we often use to ask whether someone is a good fit for leadership is whether they have this kind of non-standards "day job" expertise. Treating this as the same kind of fianancial or personnel CoI that we properly should discourage seems backwards. -Ekr On Thu, Jan 9, 2020 at 8:58 AM Richard Barnes wrote: > I would propose the IAB not adopt this policy, or at least scope it way > down. > > Much of the IAB's work is focused on technical issues, at a high enough > strategic level that the impacts to specific people or companies are high= ly > attenuated. In those discussions, the IAB's work benefits from having > diverse opinions, including the opinions of those who have skin in the > game. Trying to introduce some notion of CoI in this context would be > harmful -- because there's no hard conflict, it will inevitably be vague, > and thus primarily a tool for IAB members to try to silence one another o= r > a cause for IAB members to self-censor. > > Where the IAB is directly involved in finance or personnel decisions, > there of course should be guards against self dealing. That's where any > CoI policy for the IAB should stop. > > --Richard > > On Wed, Jan 8, 2020 at 6:16 PM IAB Chair wrote: > >> Dear Colleagues, >> >> The IAB is considering adoption of the conflict of interest policy >> below. If you have comments on this draft policy, please send them to >> iab@iab.org. >> >> best regards, >> Ted Hardie >> for the IAB >> >> >> INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >> >> This policy covers the nomcom-selected Internet Architecture Board (IAB) >> members and ex-officio members (collectively, =E2=80=9CCovered Individua= ls=E2=80=9D). This >> policy has no impact on any other participants in IAB activities, for >> instance liaisons to and from the IAB or IAB program members. >> >> In carrying out their IAB role, Covered Individuals must act in the best >> interest of the Internet community. Occasionally this duty may be=E2=80= =94or may >> appear to be=E2=80=94incompatible or in conflict with a Covered Individu= al=E2=80=99s >> personal interests (including interests of their family members), or the >> interests of an organization of which the Covered Individual is an >> employee, director, owner, or otherwise has business or financial intere= st. >> If a Covered Individual has a conflict of interest for whatever reason, >> that individual must avoid participating in the work of the IAB that >> touches on the related matter. >> >> The IAB does not directly deal with matters relating to contracts or >> finance. The IAB does, however, have a role in personnel decisions, and = its >> decisions and outputs have a potential to indirectly affect contracts >> within the IETF system. IAB's technical decisions and outputs have also = a >> potential to impact both work elsewhere in the IETF and businesses that >> employ or develop Internet technology. >> >> Covered Individuals shall not use the IAB=E2=80=99s resources or decisio= ns as a >> means for personal or third-party gain. >> Disclosure of Actual or Potential Conflicts >> >> The IAB requires that all Covered Individuals disclose their main >> employment, sponsorship, consulting customer, or other sources of income >> when joining the IAB or whenever there are updates. >> >> In addition, when a topic is discussed at the IAB, the Covered >> Individuals are required to promptly disclose if that topic constitutes = a >> perceived or potential conflict of interest. Once disclosed, Covered >> Individuals may recuse from participation in discussions or decisions at >> their discretion. >> >> The specific conflicts that may cause a perceived or potential conflict >> of interest are matters for individual and IAB judgment, but generally c= ome >> in the following forms: >> >> - >> >> A personnel decision relates to the Covered Individual, a colleague >> that the Covered Individual's works closely with, or a family member.= For >> the purposes of this policy, a "person working closely with" is someo= ne >> working in the same team or project, or a direct manager or employee = of the >> Covered Individual. And "family" means a spouse, domestic partner, ch= ild, >> sibling, parent, stepchild, stepparent, and mother-, father-, son-, >> daughter-, brother-, or sister-in-law, and any other person living in= the >> same household, except tenants and household employees. >> - >> >> A decision or output from the IAB impacts a contract that the IETF >> enters into with a party, and that party relates to the Covered Indiv= idual, >> a colleague that the Covered Individual's works closely with, or a fa= mily >> member. >> - >> >> Activity on the IAB involves discussion and decisions regarding >> technical matters, mainly related to IETF activities. As an activity >> adjacent to a standardization process, it is often the case that Cove= red >> Individuals will have some (frequently non-financial) stake in the ou= tcome >> of discussions or decisions that relate to technical matters. This po= licy >> does not require that Covered Individuals disclose such conflicts of >> interest as they relate to technical matters. However, Covered Indivi= duals >> need to exercise their judgment and, in extraordinary cases be willin= g to >> disclose potential or perceived conflicts of interest even as they re= late >> to technical matters. For example, if a Covered Individual's sponsor = were >> in the process of entering a new market where there is an ongoing IAB >> discussion, then disclosure, or even recusal, might be appropriate, e= ven if >> difficult. >> >> Disclosure Transparency >> >> A person's recusal to participate in the discussion of a topic is always >> noted in the public IAB minutes. In addition, the IAB will maintain a >> repository of all general disclosures of employment and other sponsorshi= p. >> It is expected that much of this repository is public, but there can be >> situations where some disclosures (such as customers of consultants) are >> private. >> >> >> >> >> >> _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000330b34059bb9719e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I concur with Richard here. The IETF is most successful wh= en we get
input from people who are directly involved in the technologie= s that
we are standardizing, but of course that very often means that th= ey
are working on those technologies for their employer. And indeed=
one of the criteria we often use to ask whether someone is a goo= d
fit for leadership is whether they have this kind of non-standa= rds
"day job" expertise.

Treating this as = the same kind of fianancial or personnel CoI that we
properly should dis= courage seems backwards.

-Ekr

On Thu, Jan 9, 2020 at 8:58 AM Rich= ard Barnes <rlb@ipv.sx> wrote:
I would propose the IAB not adop= t this policy, or at least scope it way down.

Much= of the IAB's work is focused on technical issues, at a high enough str= ategic level that the impacts to specific people or companies are highly at= tenuated.=C2=A0 In those discussions, the IAB's work benefits from havi= ng diverse opinions, including the opinions of those who have skin in the g= ame.=C2=A0 Trying to introduce some notion of CoI in this context would be = harmful -- because there's no hard conflict, it will inevitably be vagu= e, and thus primarily a tool for IAB members to try to silence one another = or a cause for IAB members to self-censor.

Whe= re the IAB is directly involved in finance or personnel decisions, there of= course should be guards against self dealing.=C2=A0 That's where any C= oI policy for the IAB should stop.

--Richard

On Wed, Jan 8, 2020 at 6:16 PM IAB Chair <iab-chair@iab.org> wrote:
=20 =20 =20

<= /span>Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.=C2=A0 If you have comments on this draft policy, please send them to=C2=A0iab@iab.org.

best regards,

Ted Hardie
for the IAB

INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY

This policy covers the nomcom-selected Internet Architecture Board (IAB) members and ex-officio members (collectively, =E2=80=9CCo= vered Individuals=E2=80=9D). This policy has no impact on any other partici= pants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in co= nflict with a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, o= r a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partn= er, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's recusal to participate in the discussion of a topic i= s always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.



_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000330b34059bb9719e-- From nobody Thu Jan 9 10:48:05 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04ACF120168; Thu, 9 Jan 2020 10:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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=nostrum.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 vPu_3rcTdIuI; Thu, 9 Jan 2020 10:47:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C4F7812086A; Thu, 9 Jan 2020 10:47:53 -0800 (PST) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 009IlnHu068001 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Jan 2020 12:47:50 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578595672; bh=lfzm02+PJyRufm4hzjGZ3/iLkgwCRfLXNUxyACsfDRQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=UcYSA/wubZXovfIrv8DWfBA9EHSu4XrzeOA325AXrjpiSdTpiAnu/WAxVLgJYi3oN tIDxLN4NsjkRjTDM8/1pyrf15HoKDPlg6qb3yRcskrq6XnNAKsJXlrGJPJazGQ6HqL 1z4k0gYIXgPMdllP04UicpQdq5skwvio5/pV/5jQ= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Message-Id: <79623A46-F585-4DD1-B4CA-C12967E7EE1B@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C9590659-21AB-4409-80F8-E5FBD76B42AD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Thu, 9 Jan 2020 12:47:40 -0600 In-Reply-To: Cc: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org To: Joe Touch References: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 18:48:00 -0000 --Apple-Mail=_C9590659-21AB-4409-80F8-E5FBD76B42AD Content-Type: multipart/alternative; boundary="Apple-Mail=_F31E6990-7C65-4089-B844-E7FC2A6FD892" --Apple-Mail=_F31E6990-7C65-4089-B844-E7FC2A6FD892 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with that for the IESG, but the IAB is not usually in a position = to approve or block specific technical decisions. Yes, it sets = architectural direction, but see Richard=E2=80=99s comment down-thread. Ben. > On Jan 9, 2020, at 12:28 PM, Joe Touch wrote: >=20 > They and IESG members are in positions of decision. >=20 > Others are not. >=20 > Joe >=20 >> On Jan 9, 2020, at 9:37 AM, Ben Campbell wrote: >>=20 >> =EF=BB=BFI also wondered why CoI on technical matters is any = different for IAB members than for people participating in protocol = design in working groups. >>=20 >> That concern is somewhat mitigated by the fact that the third bullet = (discussing technical CoI) only requires the exercise of judgement. But = I hope we expect IAB members to exercise judgement in all aspects of the = role :-) >>=20 >> Ben. >>=20 >>=20 >>> On Jan 9, 2020, at 10:57 AM, Richard Barnes > wrote: >>>=20 >>> I would propose the IAB not adopt this policy, or at least scope it = way down. >>>=20 >>> Much of the IAB's work is focused on technical issues, at a high = enough strategic level that the impacts to specific people or companies = are highly attenuated. In those discussions, the IAB's work benefits = from having diverse opinions, including the opinions of those who have = skin in the game. Trying to introduce some notion of CoI in this = context would be harmful -- because there's no hard conflict, it will = inevitably be vague, and thus primarily a tool for IAB members to try to = silence one another or a cause for IAB members to self-censor. >>>=20 >>> Where the IAB is directly involved in finance or personnel = decisions, there of course should be guards against self dealing. = That's where any CoI policy for the IAB should stop. >>>=20 >>> --Richard >>>=20 >>> On Wed, Jan 8, 2020 at 6:16 PM IAB Chair > wrote: >>> Dear Colleagues, >>>=20 >>> The IAB is considering adoption of the conflict of interest policy = below. If you have comments on this draft policy, please send them to = iab@iab.org . >>>=20 >>> best regards, >>>=20 >>> Ted Hardie >>> for the IAB >>>=20 >>>=20 >>>=20 >>> INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >>>=20 >>> This policy covers the nomcom-selected Internet Architecture Board = (IAB) members and ex-officio members (collectively, =E2=80=9CCovered = Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the = IAB or IAB program members. >>>=20 >>> In carrying out their IAB role, Covered Individuals must act in the = best interest of the Internet community. Occasionally this duty may = be=E2=80=94or may appear to be=E2=80=94incompatible or in conflict with = a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which = the Covered Individual is an employee, director, owner, or otherwise has = business or financial interest. If a Covered Individual has a conflict = of interest for whatever reason, that individual must avoid = participating in the work of the IAB that touches on the related matter. >>>=20 >>> The IAB does not directly deal with matters relating to contracts or = finance. The IAB does, however, have a role in personnel decisions, and = its decisions and outputs have a potential to indirectly affect = contracts within the IETF system. IAB's technical decisions and outputs = have also a potential to impact both work elsewhere in the IETF and = businesses that employ or develop Internet technology. >>>=20 >>> Covered Individuals shall not use the IAB=E2=80=99s resources or = decisions as a means for personal or third-party gain. >>>=20 >>> Disclosure of Actual or Potential Conflicts >>>=20 >>> The IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates. >>>=20 >>> In addition, when a topic is discussed at the IAB, the Covered = Individuals are required to promptly disclose if that topic constitutes = a perceived or potential conflict of interest. Once disclosed, Covered = Individuals may recuse from participation in discussions or decisions at = their discretion. >>>=20 >>> The specific conflicts that may cause a perceived or potential = conflict of interest are matters for individual and IAB judgment, but = generally come in the following forms: >>>=20 >>> A personnel decision relates to the Covered Individual, a colleague = that the Covered Individual's works closely with, or a family member. = For the purposes of this policy, a "person working closely with" is = someone working in the same team or project, or a direct manager or = employee of the Covered Individual. And "family" means a spouse, = domestic partner, child, sibling, parent, stepchild, stepparent, and = mother-, father-, son-, daughter-, brother-, or sister-in-law, and any = other person living in the same household, except tenants and household = employees. >>>=20 >>> A decision or output from the IAB impacts a contract that the IETF = enters into with a party, and that party relates to the Covered = Individual, a colleague that the Covered Individual's works closely = with, or a family member. >>>=20 >>> Activity on the IAB involves discussion and decisions regarding = technical matters, mainly related to IETF activities. As an activity = adjacent to a standardization process, it is often the case that Covered = Individuals will have some (frequently non-financial) stake in the = outcome of discussions or decisions that relate to technical matters. = This policy does not require that Covered Individuals disclose such = conflicts of interest as they relate to technical matters. However, = Covered Individuals need to exercise their judgment and, in = extraordinary cases be willing to disclose potential or perceived = conflicts of interest even as they relate to technical matters. For = example, if a Covered Individual's sponsor were in the process of = entering a new market where there is an ongoing IAB discussion, then = disclosure, or even recusal, might be appropriate, even if difficult. >>>=20 >>> Disclosure Transparency >>>=20 >>> A person's recusal to participate in the discussion of a topic is = always noted in the public IAB minutes. In addition, the IAB will = maintain a repository of all general disclosures of employment and other = sponsorship. It is expected that much of this repository is public, but = there can be situations where some disclosures (such as customers of = consultants) are private. >>>=20 >>>=20 >>> = >>>=20 >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail=_F31E6990-7C65-4089-B844-E7FC2A6FD892 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with that for the IESG, but the IAB is not usually in a position = to approve or block specific technical decisions. Yes, it sets = architectural direction, but see Richard=E2=80=99s comment = down-thread.

Ben.


On Jan 9, 2020, at 12:28 PM, = Joe Touch <touch@strayalpha.com> wrote:

They = and IESG members are in positions of decision. 

Others are = not. 

Joe

On Jan 9, 2020, at 9:37 = AM, Ben Campbell <ben@nostrum.com> wrote:

=EF=BB=BFI also wondered why = CoI on technical matters is any different for IAB members than for = people participating in protocol design in working groups. 

That concern is somewhat = mitigated by the fact that the third bullet (discussing technical CoI) = only requires the exercise of judgement. But I hope we expect IAB = members to exercise judgement in all aspects of the role :-)

Ben.


On Jan = 9, 2020, at 10:57 AM, Richard Barnes <rlb@ipv.sx> wrote:

I would propose the IAB not adopt this = policy, or at least scope it way down.

Much of the IAB's work is focused on = technical issues, at a high enough strategic level that the impacts to = specific people or companies are highly attenuated.  In those = discussions, the IAB's work benefits from having diverse opinions, = including the opinions of those who have skin in the game.  Trying = to introduce some notion of CoI in this context would be harmful -- = because there's no hard conflict, it will inevitably be vague, and thus = primarily a tool for IAB members to try to silence one another or a = cause for IAB members to self-censor.

Where the IAB is = directly involved in finance or personnel decisions, there of course = should be guards against self dealing.  That's where any CoI policy = for the IAB should stop.

--Richard

On Wed, Jan = 8, 2020 at 6:16 PM IAB Chair <iab-chair@iab.org> wrote:
=20 =20 =20

Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please = send them to iab@iab.org.

best regards,

Ted Hardie
for the IAB



INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST = POLICY

This policy covers the nomcom-selected Internet = Architecture Board (IAB) members and ex-officio members (collectively, = =E2=80=9CCovered Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB = role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in = conflict with a Covered Individual=E2=80=99s personal interests (including = interests of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not = directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals = shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their = main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the = Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The = specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the = Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB = impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves = discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's = recusal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.




_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss<= /span>
= --Apple-Mail=_F31E6990-7C65-4089-B844-E7FC2A6FD892-- --Apple-Mail=_C9590659-21AB-4409-80F8-E5FBD76B42AD 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----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl4XdUwACgkQgFZKbJXz 1A2MYQ/9FKq5RO7oha++N0i8RXvs+RQE+sWR0RSI2T+cgGAsHbzZTVovVyC8WMwz VnvPtEPIo8ECPghng+ew0rSyxnoNHDRkBAI3BB2vlFqfXEaodQOhZOYNN/bbaf/H R2IwDV4wezUX+ZfCohp23OhlFXlGunOooFlggdaSXcVs//1JO+7xlzowM577Rk8+ B+6PbFZcT4Yl31fQwGanYUq8gZ4YcWGqiHcYM73z8IzVmNTmJEzxZG5ok5aWobhp vCPIHwZiCmCivgoNF1KmSxwjyPvj5ByDBLqmH9AhztI0KoyY92VQjB7X/LhydpYp diKOSVDTr923yMqDiq1DSbDoNFI4S9UQe8FynwpXB3SgNhHaMkYAYGfotBBF90qF 6UhUS/Qif4AHVTxC6bjBZp9WhDL62MHIPTRj/iliXGkLS8k7bTJvl+2K4MJ5jlP0 xDlrT218FA7UChqKpGl09+DzTMQR2IdOrpgmVeRx+i9WrElqCdt/kW8ul6edcCRq PK22KTJwYZ/jDuBDN8E+R3so3luZXmGKGfwlihfZVWgGAJmkmzbJgpb+MgSUQ6lq pqyDRV7oPJcWJsZQBT8gLbwi08UaTZywx3EjQuXD/ipRxYLr/01u8yDA5e6D0AWY qj1P0Bu6DeHLNAySZqCqtsTSjsaErENNMOFaoASzZIJZHJXhCJw= =62SZ -----END PGP SIGNATURE----- --Apple-Mail=_C9590659-21AB-4409-80F8-E5FBD76B42AD-- From nobody Thu Jan 9 11:42:21 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5693D12029C for ; Thu, 9 Jan 2020 11:42:19 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjhhiUY3q1iS for ; Thu, 9 Jan 2020 11:42:16 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0: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 BB2FA12020A for ; Thu, 9 Jan 2020 11:42:16 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id f5so6668932ilq.5 for ; Thu, 09 Jan 2020 11:42:16 -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=sa5RIAeeHRkzfus/y8YdCwLyvUZ1d3HjG2kngOzbV7U=; b=Ojx9N1nqZ7bvY4qVhVoNy/Ct8+uRdwNY/z1lbY84UGxlsW0kNFLg2WbOelG4d9XILQ QkpBngvw9JRC2AiBQcWD1H9w4E0KH5Pce2Azs/lKsiRVA+xD5NvyKWm56akHq7OOyPp5 BU4PK9X7rTcKJwj+uR9pzyNGWi1YFmU1Asxzz+I8O6XrXfcS7e2fln2HO1s7dDJv8+Qk T1aN8UvQcqUCW9b3c/4EXuu65sCE8UbMQIvTW8f/CtpHIjC5ZzkemWlnIWjp4ht7FM1c Lt9q241J4fXeldKxwH9uk6XMBRiCCulAovycdjjMIa+tC0PftDWG4+w/euNZl3UxnI2/ QyoA== 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=sa5RIAeeHRkzfus/y8YdCwLyvUZ1d3HjG2kngOzbV7U=; b=EBrj9jtiwmseDyzJ013IaWUQhoSfzFOxzy4T66rxVh5LEitSFM2WASPHC9PaPKr9ii SdQeL6To3b7mlULDGr2X4H8oygzOeP8ZwkBozUd54C3UswAtr3rob6ykDfkpl3R+QaG1 5PRWPIiifahwlNHmeE06X6l+2GFDnCeRcY5bNVBZeAbxOnCnMLcnoR9NE5WQcLHeP0kU KURyka8fMtgyTvfoAqUnzrJCbZ9bbZw++8K8SeAw8ZolODn00MpX9x1fnMq57pOw8UtS eOjt4iZg4c7ljYnMon6nqw13g9mrUmQ96kSfi6zSg/MK0tMfYbAVPXJPjuCTn/bgFsBL Jozg== X-Gm-Message-State: APjAAAUx+Ytrlul+cojBSy1AB+yvszUY/GT+CBnbHNR3g1I17XV+83Ix CJpJMQ665/VmxRMSkSSkukgBtLxG1h+r76WK0JGGVr56 X-Google-Smtp-Source: APXvYqy1VEFAPrjuIlIwICjjiM50j7kfvU29ZxwejSLVAEqMbrbdq3CjcXPDWq7bQtqoeFAoh6Kl8aRfgTWLeABrBuo= X-Received: by 2002:a92:51:: with SMTP id 78mr10262228ila.121.1578598936050; Thu, 09 Jan 2020 11:42:16 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <6.2.5.6.2.20200108213623.144cb518@elandnews.com> In-Reply-To: <6.2.5.6.2.20200108213623.144cb518@elandnews.com> From: Ted Hardie Date: Thu, 9 Jan 2020 11:41:49 -0800 Message-ID: To: S Moonesamy Cc: architecture-discuss@ietf.org, Internet Architecture Board Content-Type: multipart/alternative; boundary="000000000000d38132059bba3412" Archived-At: Subject: Re: [arch-d] [IAB] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 19:42:19 -0000 --000000000000d38132059bba3412 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Howdy, A few responses below, in-line. On Thu, Jan 9, 2020 at 12:33 AM S Moonesamy wrote: > Hello, > At 03:14 PM 08-01-2020, IAB Chair wrote: > >In carrying out their IAB role, Covered > >Individuals must act in the best interest of the > >Internet community. Occasionally this duty may > >be=E2=80=94or may appear to be=E2=80=94incompatible or in > > IThe "best interest of the Internet community" > can be quite subjective. I'll use the recent > "open letter" as an example. I would probably > decline to sign it. That does not mean that a > person who signs it would be acting against the > best interest of the Internet community. > > >conflict with a a Covered Individual's personal > >interests (including interests of their family > >members), or the interests of an organization of > >which the Covered Individual is an employee, > >director, owner, or otherwise has business or > >financial interest. If a Covered Individual has > >a conflict of interest for whatever reason, that > >individual must avoid participating in the work > >of the IAB that touches on the related matter. > > The proposed policy may also conflict with the > IAB Charter as it states that the members shall > owe no fiduciary duty of loyalty or care to > .... One of the members of the IAB is a director > of the IETF Administration LLC. Does that create > a situation where the person could be in conflict [1]? > > This policy deals with covered individuals' work within the context of their role on the IAB. If they have other roles, they may also need to abide by the policies of those bodies (e.g. the LLC COI policy, found at: https://ietf.org/about/administration/policies-procedures/ ). > >The IAB does not directly deal with matters > >relating to contracts or finance. The IAB does, > >however, have a role in personnel decisions, and > >its decisions and outputs have a potential to > >indirectly affect contracts within the IETF > >system. IAB's technical decisions and outputs > >have also a potential to impact both work > >elsewhere in the IETF and businesses that employ > >or develop Internet technology. > > The above is related to the IETF Administration > LLC instead of the IETF. It could be interpreted > as meaning that the IAB can exercise undue > influence on the decisions of the IETF Administration LLC. > > The first part of the above paragraph relates to appointments which result in a contract with the IETF LLC. The IAB's role in approving RSOC recommendations for the RSE is an example. The IAB does not negotiate the contract for the RSE, but since the approval is a required step prior to that contract negotiation, individuals on the IAB need to be aware of any conflicts of interest in providing or withholding an approval. The second part is unrelated to the IETF LLC, and I believe, based on your comment, it might be better to split the two ideas into two different paragraphs. > >Covered Individuals shall not use the IAB's > >resources or decisions as a means for personal or third-party gain. > > > >Disclosure of Actual or Potential Conflicts > > > >The IAB requires that all Covered Individuals > >disclose their main employment, sponsorship, > >consulting customer, or other sources of income > >when joining the IAB or whenever there are updates. > > > >In addition, when a topic is discussed at the > >IAB, the Covered Individuals are required to > >promptly disclose if that topic constitutes a > >perceived or potential conflict of interest. > >Once disclosed, Covered Individuals may recuse > >from participation in discussions or decisions at their discretion. > > What if the individual decides that he/she does > not need to recuse himself/herself from the decision-making process? > > Then the other members of the IAB are aware of the conflict and can take it into account. An example: The IAB as a whole decides that it would be useful to take up the topic of geographic redundancy of submarine cable infrastructure. Some IAB member might have a member of their immediate family that is a director of a company focused on providing land-side infrastructure to that industry; as a result, a statement by the IAB suggesting more or less redundancy in that infrastructure could have an impact on their household. By my reading, disclosing that conflict would be required by this draft policy. But if a portion of the analysis were to examine application layer protocol failover tolerance, so as to understand the cases for which non-submarine cable infrastructure could be used as redundant capacity, the IAB member might choose not to recuse from the discussion of that topic *even if they recused from the discussion of the final recommendation on the main issue*. The data and analysis on failover tolerance is broadly useful, after all, and it may be an area of concern for them in their own work. The rest of the IAB would be aware of the issue and could provide guide rails if needed, but the discretion here is to allow IAB members to contribute when appropriate, even when some conflict of interest has been noted. This is just my opinion, though, and my reading of the draft policy. regards, Ted > If I am not mistaken, the term used in such > policies is "material interest" [2]. My > understanding of the draft is that the "material > interests" are covered under the "Activity on the > IAB involves discussion and decisions regarding > ...." paragraph. Is that correct? > > Regards, > S. Moonesamy > > 1. It is dependent on the interpretation of the text. > 2. The interest is not only considered in terms of contracts. > > --000000000000d38132059bba3412 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,=C2=A0

A few resp= onses below, in-line.

On Thu, Jan 9, 2020 at 12:33 AM S Moonesamy <sm+ietf@elandsys.com> wrote:=
Hello,
At 03:14 PM 08-01-2020, IAB Chair wrote:
>In carrying out their IAB role, Covered
>Individuals must act in the best interest of the
>Internet community. Occasionally this duty may
>be=E2=80=94or may appear to be=E2=80=94incompatible or in

IThe "best interest of the Internet community"
can be quite subjective.=C2=A0 I'll use the recent
"open letter" as an example.=C2=A0 I would probably
decline to sign it.=C2=A0 That does not mean that a
person who signs it would be acting against the
best interest of the Internet community.

>conflict with a a Covered Individual's personal
>interests (including interests of their family
>members), or the interests of an organization of
>which the Covered Individual is an employee,
>director, owner, or otherwise has business or
>financial interest. If a Covered Individual has
>a conflict of interest for whatever reason, that
>individual must avoid participating in the work
>of the IAB that touches on the related matter.

The proposed policy may also conflict with the
IAB Charter as it states that the members shall
owe no fiduciary duty of loyalty or care to
....=C2=A0 One of the members of the IAB is a director
of the IETF Administration LLC.=C2=A0 Does that create
a situation where the person could be in conflict [1]?


This policy deals with covered individ= uals' work within the context of their role on the IAB.=C2=A0 If they= =C2=A0 have other roles, they may also need to abide by the policies of tho= se bodies (e.g. the LLC COI policy, found at: https://ietf.org/about/administra= tion/policies-procedures/ ).
=C2=A0
>The IAB does not directly deal with matters
>relating to contracts or finance. The IAB does,
>however, have a role in personnel decisions, and
>its decisions and outputs have a potential to
>indirectly affect contracts within the IETF
>system. IAB's technical decisions and outputs
>have also a potential to impact both work
>elsewhere in the IETF and businesses that employ
>or develop Internet technology.

The above is related to the IETF Administration
LLC instead of the IETF.=C2=A0 It could be interpreted
as meaning that the IAB can exercise undue
influence on the decisions of the IETF Administration LLC.


The first part of the above paragraph = relates to appointments which result in a contract with the IETF LLC.=C2=A0= The IAB's role in approving RSOC recommendations for the RSE is an exa= mple.=C2=A0 The IAB does not negotiate the contract for the RSE, but since = the approval is a required step prior to that contract negotiation, individ= uals on the IAB need to be aware of any conflicts of interest in providing = or withholding an approval.=C2=A0

The second = part is unrelated to the IETF LLC, and I believe, based on your comment, it= might be better to split the two ideas into two different paragraphs.
<= /div>

=C2=A0
>Covered Individuals shall not use the IAB's
>resources or decisions as a means for personal or third-party gain.
>
>Disclosure of Actual or Potential Conflicts
>
>The IAB requires that all Covered Individuals
>disclose their main employment, sponsorship,
>consulting customer, or other sources of income
>when joining the IAB or whenever there are updates.
>
>In addition, when a topic is discussed at the
>IAB, the Covered Individuals are required to
>promptly disclose if that topic constitutes a
>perceived or potential conflict of interest.
>Once disclosed, Covered Individuals may recuse
>from participation in discussions or decisions at their discretion.

What if the individual decides that he/she does
not need to recuse himself/herself from the decision-making process?


Then the other members of the IAB are = aware of the conflict and can take it into account.=C2=A0
An example:=C2=A0 The IAB as a whole decides that it would be = useful to take up the topic of geographic redundancy of submarine cable inf= rastructure.=C2=A0 Some IAB member might have a member of their immediate f= amily that is a director of a company focused on providing land-side infras= tructure to that industry; as a result, a statement by the IAB suggesting m= ore or less redundancy in that infrastructure could have an impact on their= household.=C2=A0 By my reading, disclosing that conflict would be required= by this=C2=A0 draft policy.=C2=A0

But if a p= ortion of the analysis were to examine application layer protocol failover = tolerance, so as to understand the cases for which non-submarine cable infr= astructure could be used as redundant capacity,=C2=A0 the IAB member might = choose not to recuse from the discussion of that topic *even if they recuse= d from the discussion of the final recommendation on the main issue*.=C2=A0= The data and analysis on failover tolerance is broadly useful, after all, = and it may be an area of concern for them in their own work.=C2=A0 The rest= of the IAB would be aware of the issue and could provide guide rails if ne= eded, but the discretion here is to allow IAB members to contribute when ap= propriate, even when some conflict of interest has been noted.=C2=A0

This is just my opinion, though, and my reading of = the draft policy.

regards,

Ted
=C2=A0
If I am not mistaken, the term used in such
policies is "material interest" [2].=C2=A0 My
understanding of the draft is that the "material
interests" are covered under the "Activity on the
IAB involves discussion and decisions regarding
...." paragraph.=C2=A0 Is that correct?

Regards,
S. Moonesamy

1. It is dependent on the interpretation of the text.
2. The interest is not only considered in terms of contracts.

--000000000000d38132059bba3412-- From nobody Thu Jan 9 11:49:34 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B501207FF for ; Thu, 9 Jan 2020 11:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=1WWShTR+; dkim=pass (2048-bit key) header.d=comcast.com header.b=kTZUB32r; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=hzrz3WCw 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 iNa4KghLIUjv for ; Thu, 9 Jan 2020 11:49:30 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 8FCEC120047 for ; Thu, 9 Jan 2020 11:49:30 -0800 (PST) Received: from pps.filterd (m0156892.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009Jb5YV029092 for ; Thu, 9 Jan 2020 14:49:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=CQxV8SudkM6Dl/NFwobAgikHGrh4fb2vWOnfVx8u3Fc=; b=1WWShTR+8s+xhMhTqazY8X+Z+r7zuQVzCXXTzoH2liNHexhS3jmj67HaIALPsU2aySeD zpGQ4i/rw4unwpRQnCPH458/GntFbvmqEckBERIi3rFl1N5yaaaPAZbRI1iQTwXlWzhu LN9CJJ///hmf4XUvhAm7lFOJH35lvrbJKvR296gRx5XwQEBXW8I8V2lzxRRL2BX+azIV o8KOABSJPdLil1qW/lJD0X49BCdGkzAZTgzVen6LX4HSEwjkZsys5CwPFM4DS9IBYSqe NedieUZqnI3fyA4WlwEQ/W658w4BLphaYcF+QrV+ye1A5tkYYCBYUvo0VUgFqzu23+hP dQ== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 2xe54wjn1a-13 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 09 Jan 2020 14:49:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1578599370; x=2442512970; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CQxV8SudkM6Dl/NFwobAgikHGrh4fb2vWOnfVx8u3Fc=; b=kTZUB32rZTML6tM3Oh362fJ787QcfsY2OSZCBdTh55hoVdowPhLu6FihegCSBMa4 2feWvSiedyBDsk0Gf22MgC7/NAzwCBIlKTI8DGDveLpaAQOv6MUwxlhVjQ4TyT/n YYRXgWo10pUwXP7n0Lf0cSXmRXhi/2+3oUuF9Dz49NNwNjm20mtZeWeYQkqwVEVr vtz92dvv+YhmS8a0NaMbKY7j8xOcaunA3WAGIbD1cI5goDgeBc8AmBqQqkGZDgqp Q6dAOoAznq9QlyMkRTTaBQXQ7NVbvlAr3329gQw1uBYm7Glu1NsQHaC/TClf+sX8 jOJZa+tUU9PJFKYkeMcw3A==; X-AuditID: 60729ed4-237ff7000000bc72-5b-5e1783c947e3 Received: from COPDCEX13.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 5B.37.48242.AC3871E5; Thu, 9 Jan 2020 12:49:30 -0700 (MST) Received: from COPDCEX50.cable.comcast.com (147.191.125.149) by COPDCEX13.cable.comcast.com (147.191.124.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 12:49:29 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX50.cable.comcast.com (147.191.125.149) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 Jan 2020 12:49:29 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.101) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 14:49:18 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2211.namprd11.prod.outlook.com (10.174.112.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.15; Thu, 9 Jan 2020 19:49:17 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2623.011; Thu, 9 Jan 2020 19:49:17 +0000 From: "Livingood, Jason" To: Stewart Bryant , John C Klensin CC: IAB Chair , "iab@iab.org" , "ietf@ietf.org" , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmqPjy+NwtyX0e9LVb75savKafiUIiAgAAUtQCAAAVtgIAAAFAA Date: Thu, 9 Jan 2020 19:49:17 +0000 Message-ID: <5C0D54E4-08E7-4151-8235-D03BAC0546E9@cable.comcast.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <1E62D045-4171-41D6-858A-C277C947AD05@gmail.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.20.0.191208 x-originating-ip: [2001:558:1438:13:cf9:e038:159a:bd7b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: deb9f544-b98c-4137-10e9-08d7953d035f x-ms-traffictypediagnostic: BN6PR1101MB2211: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39860400002)(396003)(376002)(346002)(189003)(199004)(33656002)(316002)(2616005)(53546011)(54906003)(4326008)(6486002)(6512007)(110136005)(6506007)(4744005)(2906002)(64756008)(66476007)(66556008)(76116006)(91956017)(66446008)(8936002)(186003)(81156014)(5660300002)(478600001)(66946007)(71200400001)(86362001)(81166006)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2211; H:BN6PR1101MB2195.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZtOq0SIul/eoPuL4lWPd2+zNsWKNSQHBaV0nXMR+DfPsBQH2u3VKZTar1Uu0+4J7oSrL+eNLcH3luj99zHzbE6tJlj1yzqQgFKTdx0VjE2Zs5eKEnyYkcG8JqMRRZYNSP7yWX/yb/8HISNLkYbjja2VSwKDt7lkPq+Pb2sk+/hIgY4g37gC9JMpvK1iVc9sOxk1IZsd6haC/eFf+P6Qu7Dbsrrfj26ysQoh/uulXONPKse/xGJKpKC5neh45kGwCmEVXijZXanzpFMhuu7Iv1aCpf/GU4RNHuOM81GROxCpj5yiba8VKG5udhnjLUDnsb33KXVi/94KYxqL5WD5Lafl9HqGGgCSTznq6JPzlCcanlVXYHE/XuzJKBzB+uBPLfz9CnebCVOCD1NCZiJLz6mXu59JGxY9cx/oNpN5KJsVGEbxznMf8aGEc4N1MDY2U x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JawGo13xCZs7owmwZkFyIWeFqBxrnCYhG0aImFl7uQL40f4n5h/vCNkMPSPMGFttT9kIS7XBQpVPvxDaUFrRHm8vI6eS0Gdm2fiWIB/+oAqnAd/w2uKoSOjixAztZIGJVBPirNsPTx6hJzEmOYKYVMOfSDf4/OSd3lx3iwnCW5y+z7JNkuTZme+0ueaxL9ByhF64E4vWmJ8y2J1R6cl6n/6JffLNi4wmsbIRGEerhydvzqenkT23JzbbsUF0T0XTDa1GM0+1x0LcZQpMuiJDKdPYtLhQadgrpHVvUhQnY2oL75qmhDqxS7zJMyjtUmCiY40CkhAMf2Nl41RgotMxAw== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=izGEaD+HdIOE11JBo+tpQRpQOdNiK3eAG2rNq8rSiGU=; b=QYicx6xP5E894rw9FUznaiZuSw0fdEvksEMGzeAXVX0nZWkrwVtLydAjKKXElMAhAAVpc6K+73hB6Ew1LeJBZChFh+F642AD96oxJVPKJ1XMvU5fKVDLyoYnMVtl649PVzb5xFHR0v490DyoJZLHwxQXR4yVtrUODywRBFUVoQYinPVZ5OB0AbBI3VAJniHAfeoWJaOZwgkzWC5Z6anP7eCcrZK/HVLODuKByiOqvq85G6K5AEIIt/i1KQq4F3iscfdjnNzXqXoGXNPVIQtIS8c1MPPT7mynz+uqZHw674+bJF5x9I7ZWQSAD53MlR0LTMoC2RNQc6bLjMXiomLofg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=izGEaD+HdIOE11JBo+tpQRpQOdNiK3eAG2rNq8rSiGU=; b=hzrz3WCwSKGlEPxkbQ4mjp69FqQIYsHDiKps0kIOuBeECw4CsWQ687TfjTRrfouLlV1ECxAfSImRR+g8hjvAeHvDpMqRJc8kE4iQft6tCP8/lupu+qyALKf7tAtuZfI5Qa8ml2XNtRMTqo7gdPZBMTWvwNILv/92bL8a/9U2N7o= x-ms-exchange-crosstenant-network-message-id: deb9f544-b98c-4137-10e9-08d7953d035f x-ms-exchange-crosstenant-originalarrivaltime: 09 Jan 2020 19:49:17.4281 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: ehOPw7qVCL7z/Y3BPVT5YTMjl0AsBMkjvYZCfoM8/WC0FMYWU/YMkxW4QmYJhcaA+kkPU6FiUD6TRrrfXU9xpfX9rX2liOf/SzjJ2E8Qt5E= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2211 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <7E673C845D93C740A559F6C4BCBA274A@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA22Se0hTURzHOffe3d2Ji9My98Me1KjQKNfMxyoTBav1R1BGEVHqjR2zWmp3 U7IoLDVwEzIsRrNa6iZZWiaVVgZlRbWSairlqwetkUnRg95SbfdaBHn++vx+53O+58HhaFUV G8FtyrEQIYc3adgQJlM4UjnbU6xOn1NSJNM39ZfJ9B3dR1l9zbCP0vvPOhl9qXeY1Xue8cms 4aJjQG7o7R6kDS7XN8rQWT9EL2fWFqFES7ZAeEsqySI5ZpIUMuW/kbiBZOUKZBEvmArTiInw o2tB00hMmwqIoB01RjtqTqaVyj7Re4PO87DbX/dkFqFzrBUpOMCx8LSpTmQVvk7BkFdhRSEB vobAee8KKxV9CAZ8rSPFbQT1bptcKuwUPOxvlEnFcwRvyrvlwTAWx8NAdRcd5DC8Eto/fBcl GrsCknVAlMbhBVDyySuTpERwl/oZiRdD7z0HFWQGT4OW4r1ikBKnwq3KOvrvCT19blFS4IXQ 9P6CGIpwOHzxNIh9Gquh1+ekpKticLXdpyUeD4Mvfoobj8da8Pe0MtJaI9Raa0b8BPj0tnbk mSaB12lDViQP8DJoUUndWWAv/RpYyQU4F+oqVkvtGVDbdZmReCLcdf4Qrw74EAMfmvfJg74K b4Y33UkVKM7xzzkdgRkaR8GZS1qpbYAnlVWMxFPhoO253CG+w1i4c9jHHEeyk2jMvPhonS42 Whenj47RxTQj8cse62pFnXZDO8Ic0oQqK7ap01UyvsBcuLUdAUdrwpQ3H4enq5RGvnAHEXIz hHwTMbejCRyjUSvZhd/Xq/BG3kK2EJJHhD+zFKeIKEINHxMah9ep+7sOjA3zXl9TbLCkDLJp T28dS5AVdH777O9IsU/eRsnOR8791SEsfVBaZp+/c1dS6A9vftSGg4fajNOXcC5FQ9XVxlOh 5XFqtMqyZ8XE+j373ZFpQ0cf2WJibC2vspdzdf7k0y8z4nd7zKu0u1dQrsg035IX71DntGoN Y87mdTNpwcz/BqkTWbmuAwAA X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_04:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 19:49:32 -0000 T24gMS85LzIwLCA5OjQ5IEFNLCAiaWV0ZiBvbiBiZWhhbGYgb2YgU3Rld2FydCBCcnlhbnQiIDxp ZXRmLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNv bT4gd3JvdGU6DQoNCg0KPiBBIGNvbXByb21pc2UgbWlnaHQgYmUgdG8gcmVxdWlyZSBjb25maWRl bnRpYWwgZGlzY2xvc3VyZSB0byBzb21lIHRydXN0ZWQgcGFydHkgdGhhdCBtb25pdG9ycyByZWN1 c2FsLCBidXQgdGhlIGV2ZW4gdGhhdCBpcyBwb3RlbnRpYWxseSBzdWJqZWN0IHRvIGFidXNlIHRo cm91Z2ggc29mdCBwb3dlci4NCg0KW0pMXSBUaGUgYXBwcm9hY2ggdGhlIElFVEYgTExDIHRvb2sg d2FzIHRvIGhhdmUgZGlzY2xvc3VyZSB0byB0aGUgYm9hcmQgYW5kIHRoZW4gdGhlIGJvYXJkIGRl Y2lkZXMgd2hldGhlciBhbnkgaW5mbyBzaG91bGQgYmUgcmVkYWN0ZWQgYmVmb3JlIHB1Ymxpc2hp bmcgKGlmIHRoZSBkaXNjbG9zZXIgaGFzIGFza2VkIGZvciBpdCkuIEluIHRoZSBJQUIgZXhhbXBs ZSwgdGhlIHBhcmFsbGVsIHdvdWxkIGJlIGNvbmZpZGVudGlhbCBkaXNjbG9zdXJlIHRvIHRoZSBJ QUIgaXRzZWxmIChyYXRoZXIgdGhhbiB0byBhIDNyZCBwYXJ0eSkuDQoNCg0K From nobody Thu Jan 9 11:53:43 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FA71202A0 for ; Thu, 9 Jan 2020 11:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=xM4sY4VO; dkim=pass (2048-bit key) header.d=comcast.com header.b=RoVNjRPZ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=Hk1U6mvs 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 EUOkIBYy_IGP for ; Thu, 9 Jan 2020 11:53:40 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (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 DA82C120047 for ; Thu, 9 Jan 2020 11:53:39 -0800 (PST) Received: from pps.filterd (m0156895.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009Jisct007047 for ; Thu, 9 Jan 2020 14:53:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=CYW56m/G07GMdunMPtfJ+wAxK9630IQHQ3YV1C5H1D8=; b=xM4sY4VOms1T/GBUye7nTwS3bCoz7iXxHlanH30bCdOs1H40KhVjjnocRP1E+tV92pE+ CY7NybELFvLHqxnPOPBfLQs4w0gsT/msmzhhyL3Fx9LzDHWFwGm/Z4ciLrkkiQkORd2g cLSBkw5XVSAyjDjxDKjAU8cdbKqjMeEKSKZQtFUWy2qIP5JMSw8XPr8EdjoEdkdh5/ph iHed3vUPgxZZxRP8r5117QfiiL7Ei1bIz1cFDmNdt7pG/845svW+D4mmY4i4kdAoZbgp /nTEmq8CiU/Zoz9vFqAUBjjPGlLnYKJXA6nueGB3eAJvOjTrHQE4swcSjO9+ykay7e4t dg== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0b-00143702.pphosted.com with ESMTP id 2xeakpg1y6-74 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 09 Jan 2020 14:53:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1578599617; x=2442513217; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CYW56m/G07GMdunMPtfJ+wAxK9630IQHQ3YV1C5H1D8=; b=RoVNjRPZdr8764PdYg8FSZ2WFZfeaQiMpIp/1ySI/TO416qKGf7N9kMedD3UgAEg vU7c4Q2XGA/Hb2Sv5j2JIsC0MGFObc0QBLy+0JohcYEM9k/yITwHtsq6NeFR5E1D ytK0nZi7eH0cxy8HcCQm7Kzy2OXPlr88OCHE7dqeuxD7NWp1w3axNI2VbulMG4A8 ajuobpiTkzL9zG9fIiSQ93lGRAC9w8JKLRK5wQ8TUMUBLeJHUjnTNnQ8m6ZYHSeA /BRngPv9giXNUbZ+GKgdSInSilHuLA+Jmu4OWOMUfRuWJoruazc1sG0adecTPmhy kD6aYDbYnaI5buCAuWqVig==; X-AuditID: 60729ed4-237ff7000000bc72-5d-5e1784c1c150 Received: from COPDCEX12.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 27.97.48242.1C4871E5; Thu, 9 Jan 2020 12:53:37 -0700 (MST) Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX12.cable.comcast.com (147.191.124.143) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 12:53:37 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX19.cable.comcast.com (147.191.124.150) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 Jan 2020 12:53:37 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.55) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 14:53:27 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2242.namprd11.prod.outlook.com (10.174.116.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Thu, 9 Jan 2020 19:53:26 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2623.011; Thu, 9 Jan 2020 19:53:26 +0000 From: "Livingood, Jason" To: Joe Touch , IAB Chair CC: "iab@iab.org" , "ietf@ietf.org" , "architecture-discuss@ietf.org" Thread-Topic: Draft IAB conflict of interest policy Thread-Index: AQHVxnmqPjy+NwtyX0e9LVb75savKaficR0A///7BwA= Date: Thu, 9 Jan 2020 19:53:26 +0000 Message-ID: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <7433C1A1-E071-417C-B7B8-CB4C12E7FEDC@strayalpha.com> In-Reply-To: <7433C1A1-E071-417C-B7B8-CB4C12E7FEDC@strayalpha.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [2001:558:1438:13:cf9:e038:159a:bd7b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a4011d9-75fe-47ca-02ef-08d7953d97cf x-ms-traffictypediagnostic: BN6PR1101MB2242: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(346002)(366004)(39860400002)(199004)(189003)(478600001)(33656002)(8936002)(71200400001)(66446008)(91956017)(66556008)(66946007)(76116006)(64756008)(66476007)(186003)(5660300002)(2906002)(2616005)(86362001)(6486002)(6506007)(6512007)(54906003)(110136005)(81166006)(4744005)(316002)(81156014)(4326008)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2242; H:BN6PR1101MB2195.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ek5cQyEyfu4fjC2zR/XZWvCci7FYu9qLX8cPIE0IUoyD/IC7j3i45lXxC9C9ASEEHaPCN8UEaGXLh62+Hri8ROu/34lSOqysFaeyspZy8q2K9cYVZ1v8MK+WArblbsayG8qbcVUUrd5tW/llm/E0r5uISK4mk8vyPRrld1AzptYseYXM1RSl3rkJMjxSM1X/8Bk/nvjaQXg04heYwW70UUKAupWr7um6+djv8MlaYIUqgXKhOuxvihdHpFqBH4HEMe1rD55NNWSF3zIZaRjyY1q9uG+SzN8CLc5Z5y1ZVl7pbJM4GKwW56kUbFZO2W7DLnfKBSiAMI7pSaY3E9QXpvSuZrRp4WFhag0hScjpiqjuB/6JCl7J5+XZY4uIFBpMKb4lG9ZhIdwLQx4Tr+1vuicVdmREFbM9pdp4fW0QA+RGXWZwkEdheda+NEVG5vbR x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d6w/rOpDgUxM8f6u9X6DueTAzNL+FKZomDzjScdCDMntnKtcW8V3nyax4Ziq1qRys50lxC/qrE5VI6KhYHG1Pj3m+yNKQHH9M/3nxQvHX/AAfA98QESlWVgkeg7MrCQG/t71vxjiz/xNA+XD46w8DOv72MiqBSqYZNW8E6VFQ3ry6eMAI3ZOtix7ppiWgWlOG+t3IBK5eYJJew2RjY50wIxgyXXMYeo88KXVPhf4YEi/yFg0NOb5mMl8kxiFYs/qXgocEI9Svc5qUXEWfWabSGe7g2eqDCV15R4sAtjVf6ITiOAYOFhSaTmj/2em0olhuMkuLVz1Gs7Pt/nFe+c1qw== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UQRXOQp1g70eeZiNuITjeCuBJbCfjM5pts2VDWtc6tU=; b=M5uxlIW6GXTjNqfZiPP+YKnku5DkOkiAWmIx/a9iDc89MlrBPJWQQxOH6AwRBROnays6PBT2Kd0Vtd6Kt1MG6RV6hNGK2PL87TIAgZiMdXNJ/6HDbqqclNcCE7Iynb7SF3UZlPwwM4YSTgJDmofyJg7dTGA3y/5wkhyiM0SdLFc6B39Yqd6n0xebPhg9fogLr+k78iAk2QIxVsy08TJzJhbwiB5fK97EiTB9PU2QlgE5pd7a+P+A/ANQ/k13Orj2Q63QxX953jkWpQ3lPJbq0ueCSm33v2OQ0vKcTbb0bjsOyxMT32cZrguhRJdwy3NGVP2lrnWhYftfcy96TahJ6g== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UQRXOQp1g70eeZiNuITjeCuBJbCfjM5pts2VDWtc6tU=; b=Hk1U6mvsri3S6oto7A9KDGD2k6aEcPA+qU+kRMS96YpFcrak5QmwmeC4TEbQk7F6w7oObWaczgTvWYQvX28VJkuNjRLPi1Ae6DtjzE1izBZmeJleqeYPSa5593FjVWmHiFidTH4XfgG0R4RRjv5ZnWt8oHEOGxweoL3+POQi6X0= x-ms-exchange-crosstenant-network-message-id: 1a4011d9-75fe-47ca-02ef-08d7953d97cf x-ms-exchange-crosstenant-originalarrivaltime: 09 Jan 2020 19:53:26.7345 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 5M8nW2PgEYFFiTYicNEZq2s2ipa8FF69n4LpP9bVxlcqz7KzuerprKT3HUgWgbQHX6ihRGQsllRtfrwiZuxSLQ4Z7QwdFnhAq/2qfiYAgQ0= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2242 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <829DEC4C00AA8E409515FFB87A024E3D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA22SeUhUURTGu28Zn9LEdVLntEg5SYuYNmo1idli0hAEGf0lZD6ba2qT2huV DDI128aIQnGZFmuUDK3UIDVNSbPMpJTScg9XENukZaykct6bIMj71+/c853v3vtxOVqRLVvI RccmECGW16tkDky4cDlrdUOGMmzN0z5/TXnfWVbzvPOKTGOeHqE0YxUFjKZkYoTZzGp7Osdp bVHRd0rbfbKd3UWHpqKAhCiB8AnbSCSJNZBAh6X/rYAIEhknkGBe0CfvJnrCzy6zKnVEH51E BO9Zbbxn9Qk3UlHVLeUovoY9Yr6TQ6eim6wR2XOA/eDbdAUyIgdOgR9RUHbuEi0VDQimTtXY SUUvgvuFTaxUNCPommikrfMKnENBX3qI1BhEUJoxKBrL8Drov94xI+I4JxwEtQ8drRoan0Bg MZ2ys2rmYx8wtr8R2Qn7Qn3abySxPxQ9mBR9GOwOufeyZFaW422QNvnJdrAA5tYzot4eb4Xe Ww2UlRF2AcuzWyLTWAk9IwWU9FA849lGS+wM48O/RH9n7A1j3dWMNKuDQqPZpl8PXz8UyiR2 hZcFmUjinXD+WpMtPE9Iyx+y7cdBVW26bXY5VL1us/FiaC34KSYHOJOB4R/5lDUUBY6B952B F9Ba0z9XNc10aLwKymq8pW0t5Fy00BK7QXbmoJ1JTMIRWvJHmGuILUHzNqzzUqv9vNRrNV4+ ap+7SPyrVzuq0atcbSPCHFLNlV84rAxTsHySIflQIwKOVjnJH3e5hCnkOj75KBHi9gmJemJo RIs4RqWUyzb+2KvAB/gEcpCQeCL87VKc/cJUtGVJdkjwZ9dR80B2qWfdiqk5k33t7SXbLSjx U9WLYt/JHQP33t7VhbbFT+fojrv1+ChC8z5OZToGMZXKvIzNK317nvTWjpOtt2v6N305Ptx8 J6vi2Lvo4shEv5h0reXGI9Z9KCUlZd7FOvfO/ctKT+fX5bmpK/0jUkYfe+y50bQgoF7FGKJ4 tQctGPg/urfg06cDAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_04:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 19:53:42 -0000 RnJvbTogaWV0ZiA8aWV0Zi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSm9lIFRvdWNo IDx0b3VjaEBzdHJheWFscGhhLmNvbT4NCg0KPiAxKSBjb21wZW5zYXRpb24gbWF5IGJlIHBlbmRp bmcgb3IgaW4gdGhlIGltbWVkaWF0ZSBmdXR1cmUNCj4gNCkgVGhlIHBvbGljeSBzaG91bGQgaW5k aWNhdGUgYSB0aW1lIGZyYW1lDQoNCltKTF0gVGhlIHdheSB0aGUgSUVURiBMTEMgc29sdmVkIHRo ZXNlIGlzc3VlcyB3YXMgdG8gc2F5IHRoYXQgdGhlIGRpc2Nsb3N1cmVzIHNob3VsZCBiZSBhbm51 YWwgYXQgYSBtaW5pbXVtICYgc2hvdWxkIGJlIHVwZGF0ZWQgYXMgc29tZW9uZSdzIHNpdHVhdGlv biBjaGFuZ2VzLiBTbyBhbiBJQUIgbWVtYmVyIGluIHRoaXMgZXhhbXBsZSBtaWdodCBmaWxlIGEg Q29JIGZvcm0gaW4gSmFudWFyeSBidXQgdGhlbiB0aGV5IGNoYW5nZSBvcmdhbml6YXRpb25zIGlu IEp1bmUsIHNvIHBvc3QgYW4gdXBkYXRlZCBvbmUgYXQgdGhhdCB0aW1lLg0KDQoNCg0KDQo= From nobody Thu Jan 9 12:07:56 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A461208A3 for ; Thu, 9 Jan 2020 12:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=PEEK5BJ3; dkim=pass (2048-bit key) header.d=comcast.com header.b=0nybhGXW; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=EO5TeXSp 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 3Pf5d-ZHsoV2 for ; Thu, 9 Jan 2020 12:07:49 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 10973120808 for ; Thu, 9 Jan 2020 12:07:49 -0800 (PST) Received: from pps.filterd (m0184894.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009K34EU004591 for ; Thu, 9 Jan 2020 15:07:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=wgaC909p/eAzK2qiA8YSjPc3BIFklm+MG+3MbQmUOk0=; b=PEEK5BJ3wWrfdM/AoJUIX0UmxXRgQxzeSdeloMqqJVLvbpnwrvj4q0vKXirpT7gyicCC +YMFhE8F7pJHydId4lvfqWVp+spo3i+lueXWKF3n7P+O+z19WHbDvZUzgXUXt0ED1ygf fLeT8/lpz+Wrm0SCQrkF3hJU3fvyjDJyFZ1Euv9cYNJ2ouzRwXzsnlNK1/8firJ8KYaO tuJPeWjJguw2vMePofBkAQBmDhS7HU61JjdJpkHH+xHIcpkC4KrsF5KD0pg+o2yf0eru GoQ7880N8ZpKefLZzzvh0laQTAA3oGUpm7exv+F9D912pE1jOYaAPciuMHGlYz/zosah 5Q== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 2xdjm88qgh-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 09 Jan 2020 15:07:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1578600468; x=2442514068; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wgaC909p/eAzK2qiA8YSjPc3BIFklm+MG+3MbQmUOk0=; b=0nybhGXWjfzckn90vQyNLUf+2UVsxmvZ0IVPocpsRYlhu+Pn865Qi627kjAyx8hS 05HTMCeDUzllkcqs0yvZHyiec4JL08/COI+nIEdupqYrS7GNTj5Ro9OgtafKKHOx 7MX/y+N6eGPKuBQZ/YT6zBmL1u50F97q9pMmwwp6YJNzg+cx2sTnm6VX3IVxASNf k9bqj4GHsh2Io0N80cv5Eqz1iOxDYi4WjHUC3Ndl+Lh2QsKisp2BxCGQ0BKzPskC xFgTuJzOWBiIOGF9kQul8RLwX33TNWaGETF0rtLbrLzLpLYEeY3IPDWPKtFf/1Ad 6IX6kdxXDaQoDuXstd9m0Q==; X-AuditID: 60729ed4-24fff7000000bc72-fc-5e17881405db Received: from COPDCEX12.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id A8.19.48242.418871E5; Thu, 9 Jan 2020 13:07:48 -0700 (MST) Received: from COPDCEX13.cable.comcast.com (147.191.124.144) by COPDCEX12.cable.comcast.com (147.191.124.143) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 13:07:47 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX13.cable.comcast.com (147.191.124.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 Jan 2020 13:07:47 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.53) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 15:07:32 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2209.namprd11.prod.outlook.com (10.174.112.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Thu, 9 Jan 2020 20:07:32 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2623.011; Thu, 9 Jan 2020 20:07:31 +0000 From: "Livingood, Jason" To: Ben Campbell , Joe Touch CC: IAB Chair , IAB IAB , IETF discussion list , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmqPjy+NwtyX0e9LVb75savKafijtKAgAAK0oCAAA5/AIAABXMA///CfAA= Date: Thu, 9 Jan 2020 20:07:31 +0000 Message-ID: <73739D2E-EE15-4D49-8E99-0BAA79838548@cable.comcast.com> References: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> <79623A46-F585-4DD1-B4CA-C12967E7EE1B@nostrum.com> In-Reply-To: <79623A46-F585-4DD1-B4CA-C12967E7EE1B@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [2001:558:1438:13:155f:33bf:4c1a:6884] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 00c82093-9a97-4a62-888d-08d7953f8f86 x-ms-traffictypediagnostic: BN6PR1101MB2209: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(346002)(376002)(396003)(136003)(189003)(199004)(33656002)(86362001)(2906002)(66946007)(66446008)(66476007)(66556008)(64756008)(186003)(76116006)(91956017)(2616005)(4326008)(6506007)(71200400001)(316002)(478600001)(110136005)(8676002)(81156014)(81166006)(54906003)(8936002)(6486002)(6512007)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2209; H:BN6PR1101MB2195.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Bq9sIjfzL9hGAtuqKiAU2l9fQ9qZnkSO1osrnaVaGgIJU4wM5CfWAVV52RW5+m8CDGFvKSYxfJJos1zLpMrtjEnIa6lLf5pBsFcw3ei9dzPV6grombO3uIMkJPqBauZyMSFrrCdkpkGMqiH3imgitOYln4hrpYr9o8r7x0j3ZqWTffvtvUGA/X5UyUxtpQKqlCYX+QT0mnJukHrMS1YFr0cWosg4CPeHhtr5YhxvWhJ1SbmphFRa5h1Y8ytSH0GSn876fcgOD+QeYqc1jNqSTRsoyfjObJX1j4ADsPsd66j+cGs/UegvY6CV7RHfA9duIVfogEjBqxQQMraq+oLBfPyA/tXkbEDEZ+e9V3E0V6Yjw4cfnO/xpcVL0oeJsABtxFz0Rq4B9222/I05gnUpWOOOTrcqbeIh/9xTcO2ysYunWEuh7FbI97HHsfwT0mzN x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=boJakw4JenLmp8QWVjox8wzEO3e54HUH6cd4h7VzdbMwXBradNbw74cqd5yeyXkhAwn9DWJPZExCPoJKqCRnAsYzsib1NlKi8LiXdsDnSvt9/K6bTaZHtVZOHhD683Ulefz6c1sjn/1HMSFRd3mYP8h4IuTxLMVNlh+PMX1msPJOe9xBJs02XHHp9Mg7OnX8RHIgYfy27yf0CNXgwxv71WOejg7D9pC4UaSa/ySK5st+Fe6v+jBpVwldxtrgVcCchqxJj6fYDKJBh/XCLBWAEx5ZCm6Cr1tMt1yY1/45UR0E6MA/2ToSLl1NwSF4dShKrrriS7KOTVCLXnjZ6SKpBA== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u3AXdO1VXACGn7cbLkTTsVzCnv1rYybQt66wvQNdvE0=; b=KF+csxdK8ZK7w51ZffKMIleACTGWr7+M0W/t61+l6V7SSG3qvezR1fDzt6dmtDH08nddbhbERpQAhI0UGq2yWKGIWgdxBL1hr127tIloL26FEfEMA10mSKdGED8Zg0vrACLJOGE9Gx9rO3E7mpb6I4lB/Z3wXgVcUHoZf6R53PAvZpxuABVmavZHrN+AwSIzS4hEU6U2TBLMBeuzYEtKsGxGUEmvB0MN9DPn+nLrdIP6EnxDBI+iLyAbHB87/HZm65mG1r21tFRr2uFywXf+WvKplOIMi4IQZUm9BB6SdtojMrWlUk9CW1LYI0xbbU0Lbca1mXw3/ykyruzMLyPH2Q== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u3AXdO1VXACGn7cbLkTTsVzCnv1rYybQt66wvQNdvE0=; b=EO5TeXSpen8vjodF+pkmIMNPt1h0gzGlxZmeH9tdnc4gfI9g8GlrGQ0+8zo3jy0qRCEGJy1qtoXupLn+j8GDqLCY6v3M5JwrNKuRKfj7i7BbfE/xc/oB88L1NACbKo5Zg1R4aa2xW79KwHcE7hOYIiIPevOYbH/HwJhIkmUnWx4= x-ms-exchange-crosstenant-network-message-id: 00c82093-9a97-4a62-888d-08d7953f8f86 x-ms-exchange-crosstenant-originalarrivaltime: 09 Jan 2020 20:07:31.7952 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: FoYQA4L7yockBN78vVQpNgKEWBk8v7pffT/h3IXrN54l7Um80U7eGrR64NqHCut8npWXULIKv5ELk2tc3K5sxTEvFzSXjwws9Y7BTpq3Wvs= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2209 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <762EA41C6D4FE04BB767AFEE32806649@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHJsWRmVeSWpSXmKPExsWSUDRnsq5Ih3icwZxWSYsNdzpZLeZ3nma3 OHt1LpvFoj9PmCyebZzPYrHq9RMWBzaPW1dfMnssWfKTyWPWzicsHjdbL7AGsEQ1MNqUZBSl Jpa4pKal5hWn2nEpYACbpNS0/KJU18SinMqg1JzUROzKQCpTUnMyy1KL9LEao4/VnIQupox5 Mw0LNvFUfNx5l62BsYOni5GTQ0LARGLPvE6WLkYuDiGBw0wSm3qfskI4Bxklbnf+YINwbjNK 7F6+kAnCOc4o8WPCOWYIZyqTxLcHjVBlDxklHi++xggymU3ATOLuwivMILaIgIvEvBVH2EGK mAUWM0rcbb/ACpIQFrCWaPl6iRWiyEZiaeszFgjbD2jQB3YQm0VAReLys+NsIDYv0KDVDd+h 7ljNKPFizTqwDZwC9hKHe1+DNTMKiEl8P7WGCcRmFhCXuPVkPhPErwISS/acZ4awRSVePv4H tlhUQF/i2c0dUL0pEou7FkHVW0hMWnKFFcKWlbg0v5sRwvaVONB0iA3C1pFYdPkS1Mx8ieuz 5kHZahI33nRA2TISp+f/hprTxCLxr72qi5ED6IEsibdX7SYwms5CcuksoAyzgKbE+l36EKaH xJ8zhhAVihJTuh+yzwIHhKDEyZlPWBYwsq5i5LM00zM0NNEzNLXQMzI02sQITrXzruxgvDzd 4xCjAAejEg/vhELxOCHWxLLiytxDjBIczEoivEdviMUJ8aYkVlalFuXHF5XmpBYfYpTmYFES 52Wz/RUrJJCeWJKanZpakFoEk2Xi4JRqYBT8sHO2/ebt552mf3hbZtt7/d254CKnSY81fZen 7L0pe+uuYIeb5pycZaV/fRumb6qTFNz1Ocfn+tnVl08XBbrf5Vvw3OfBrf1MGfXSq/NN3/JP bsiw31Vq7dWtvK69a7tonWL1nb4XP5iqOYSXTa/5pTVL56t9F7Phl05N7zP9vfKRJ3XmMyqx FGckGmoxFxUnAgB2zhmRsQMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_04:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 20:07:54 -0000 RnJvbTogaWV0ZiA8aWV0Zi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQmVuIENhbXBi ZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQo+IEkgYWdyZWUgd2l0aCB0aGF0IGZvciB0aGUgSUVTRywg YnV0IHRoZSBJQUIgaXMgbm90IHVzdWFsbHkgaW4gYSBwb3NpdGlvbiB0byBhcHByb3ZlIG9yIGJs b2NrIHNwZWNpZmljIHRlY2huaWNhbCBkZWNpc2lvbnMuIFllcywgaXQgc2V0cyBhcmNoaXRlY3R1 cmFsIGRpcmVjdGlvbiwgYnV0IHNlZSBSaWNoYXJk4oCZcyBjb21tZW50IGRvd24tdGhyZWFkLg0K DQpbSkxdIFBlcmhhcHMgd2UgYXJlIHRoaW5raW5nIHRvbyBuYXJyb3dseSBhYm91dCB3aGF0IHRo ZSBJQUIgZG9lcz8gSGVyZSBhcmUgc29tZSBhcmVhcyBmb3IgcG90ZW50aWFsIGNvbmZsaWN0IHRo YXQgYXJlIHVucmVsYXRlZCB0byBhcmNoaXRlY3R1cmFsIGRpcmVjdGlvbjoNCjEgLSBDb25maXJt aW5nIHRoZSBJRVRGIENoYWlyIGFuZCBBcmVhIERpcmVjdG9ycw0KMiAtIFN0YW5kYXJkcyBhcHBl YWxzDQozIC0gUkZDIFNlcmllcw0KNCAtIExpYWlzb24gcm9sZXMNCjUgLSBBZHZpY2UgdG8gSVNP Qw0KDQpbSkxdIEV2ZW4gaW4gYXJjaGl0ZWN0dXJhbCBvdmVyc2lnaHQsIHdoYXQgaWYgdGhlcmUg d2FzIGEgc3Ryb25nIHB1c2ggZm9yIGEgcGFydGljdWxhciBhcHByb2FjaCBhZ2FpbnN0IGEgcGFy dGljdWxhciBwcm90b2NvbCBvciBjb2RlYyBhbmQgc29tZW9uZSBvbiB0aGUgSUFCIGhhZCBhbiB1 bmRpc2Nsb3NlZCBmaW5hbmNpYWwgc3Rha2UgaW4gYSBwYXRlbnQgcG9vbCB0aGF0IHdvdWxkIGRp cmVjdGx5IGJlbmVmaXQgZnJvbSBhIGNlcnRhaW4gZGVjaXNpb24/IE9yIGlmIHRoZXkgIndvcmtl ZCIgZm9yIGEgdW5pdmVyc2l0eSBidXQgd2VyZSAxMDAlIGZ1bmRlZCBieSBhIGdyYW50IGZyb20g YSBnb3Zlcm5tZW50IHRoYXQgd2FzIHVuZGVyd3JpdGluZyB0aGVpciB0aW1lIHNwZWNpZmljYWxs eSB0byB3b3JrIGFnYWluc3QgYSBzcGVjaWZpYyB1cGdyYWRlIHRvIGVuY3J5cHRpb24/IE9yIHdo YXRldmVyIG90aGVyIGNhc2VzIHlvdSBtaWdodCBpbWFnaW5lLg0KDQpbSkxdIFNvIElNTyBpdCBz ZWVtcyBsaWtlIHNvbWUgQ29JIHBvbGljeSBmb3IgdGhlIElBQiBpcyBiZXR0ZXIgdGhhbiBubyBD b0kgcG9saWN5Lg0KDQoNCg== From nobody Thu Jan 9 12:19:56 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E611207FB; Thu, 9 Jan 2020 12:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmAPbFHCOA0R; Thu, 9 Jan 2020 12:19:43 -0800 (PST) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (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 8B242120047; Thu, 9 Jan 2020 12:19:43 -0800 (PST) Received: from pps.filterd (m0048276.ppops.net [127.0.0.1]) by m0048276.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 009KI1cj021440; Thu, 9 Jan 2020 15:19:43 -0500 Received: from usushmgip001.mail.tfayd.com ([216.178.109.235]) by m0048276.ppops.net-00176a04. with ESMTP id 2xamh1wfy1-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT); Thu, 09 Jan 2020 15:19:43 -0500 Received: from unknown (HELO ashemwp00047.mail.tfayd.com) ([10.40.33.204]) by usushmgip001.mail.tfayd.com with ESMTP; 09 Jan 2020 12:19:41 -0800 Received: from ashemwp00012.mail.tfayd.com (100.126.24.36) by ashemwp00048.mail.tfayd.com (100.126.24.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 9 Jan 2020 15:19:40 -0500 Received: from ashemwp00001.mail.tfayd.com (100.126.24.25) by ashemwp00012.mail.tfayd.com (100.126.24.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 9 Jan 2020 15:19:39 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (10.40.78.204) by ashemwp00001.mail.tfayd.com (100.126.24.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Thu, 9 Jan 2020 15:19:39 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WEwqFS1UrJ2Z43eQ6R0NUcIJSS2xZ1Ivp4v0Q6FctoO5F73GcDJKu+wc1T8J0rmUUGT66EkaEnwG9rLDnMsehlBo2Dymp3QHIvUab8s27e+lLStV7nwHFcQR2K+Gnhxl++h8N+Ydd97JNTCCoxYmZoFDlG1L2pv3RlxNcnbF2+f9iDdx/zH2bkMgMJJC5AwHKuLxhJOn4eF7sogpyEIWqAQ28zcuCXDFF3MwiWuy/RIwdIcMsy8NssXkXHdG8IYdG0BiZ4EG+19aAyVo1y++lQ9I0C3xzzprqN52T6ZVTzmiagtPaCdNcJ7eeu6g5OVfOcAENwaB7DrqcuRhjexuDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2AIwWNIiBjOoTXg/pORE9wZ5pC2clVjIh937XVno5hY=; b=iszzaZNQ+vr5xgocbbI6ASk+/TUWBgVPxdFhp+vyD8Dqbz4Y4J0Qq8IJSGIZ+GbJmnQY1+dqOrCwxCCur+gtN/r5gdEd+oq5qhgCiOYfeqr0Kx+/gjYbaUopfUlWRqegAUrbmD9S4wkxH3mzVFz4dsq7+qQ0DnPaluNt5v9HQHj28yaTOMx9FqZosJfH1lMV6Kx/8BaAJO3DiJx8QTyIL9B2TFMz6N7k2i+drRvNkOXI5GQvfmcgTWQUK0SyuXR1KXsbWs+gFmEVdQeEmjEM51pSI2hwm9FuSGh5lEcCSKqTLOAnTkD4CF8tV29LWu8XLC7OV8L2HrIzndj0fdx/Jw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2AIwWNIiBjOoTXg/pORE9wZ5pC2clVjIh937XVno5hY=; b=lLkjWUhMeEW5VmTK2g9fp/6qYD/9K5datUxKOccomHbwIn0xs7vNipnJUh1lAlp6eMdpE9BD/YV7rQsHBaGLTmPajMbw95FpowiGxb1vmHncusSAvvOvLCcJYaw0JCFyoySfUuafgSDjHbY8tA3LxB9Qvdpy3D5Bkb/8f0aHybM= Received: from DM6PR14MB3993.namprd14.prod.outlook.com (10.141.186.71) by DM6PR14MB2138.namprd14.prod.outlook.com (20.176.89.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 9 Jan 2020 20:19:38 +0000 Received: from DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592]) by DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592%5]) with mapi id 15.20.2623.010; Thu, 9 Jan 2020 20:19:38 +0000 From: "Deen, Glenn (NBCUniversal)" To: "Livingood, Jason" , Ben Campbell , Joe Touch CC: IAB Chair , IAB IAB , IETF discussion list , "architecture-discuss@ietf.org" , "Deen, Glenn (NBCUniversal)" Thread-Topic: [EXTERNAL] Re: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxyoembeUp/4Pp02qBY4US3O0UA== Date: Thu, 9 Jan 2020 20:19:38 +0000 Message-ID: <52B13773-88C3-490D-8003-475F845F1ACB@nbcuni.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [108.185.101.45] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 63d4707b-f632-4bc0-c7b0-08d7954140a8 x-ms-traffictypediagnostic: DM6PR14MB2138: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(376002)(39860400002)(396003)(346002)(189003)(199004)(71200400001)(107886003)(4326008)(66446008)(8676002)(81156014)(36756003)(966005)(6486002)(6506007)(478600001)(64756008)(2616005)(81166006)(186003)(66556008)(91956017)(316002)(2906002)(33656002)(76116006)(66476007)(86362001)(26005)(66946007)(6512007)(5660300002)(110136005)(54906003)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR14MB2138; H:DM6PR14MB3993.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nbcuni.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yMlThIaN3FICTmA2kVvpjNs3YicjObgcRD/GSQJwzGFnbedsbxO8SaMw8zwjeVbBVjgcGcOX9E4fGPqrOAgtUHYAz8dl1Vfgsk9hT+W7FBNwe8JtLSux5MgnnJESfkntn9LPjYHcklISRsXxT1n+MKYAqXh5usz01B79XkDgUfYfbqU0xRkeD6cAFq0mM3hoimF9o97yUJqTxZ9YCf30vu/MFJapzTZ+aDw8XyjxljBgAXNX7qZZiJPEF4EMswzkpjdXO8fRz6VExl17IkOMRsAkEDpotRD3w67LUDkEVDU4MfMArlIMcGcY66+WVAZXbA8GSeQyz4WO871k+IWa9LLwK3oICN96Gn88V+Ey/8cDjU47hF1JDVsDsLsER9JQ1R9swlypM00GXCstTleq6kceOo5YUbONbvgCid7o/xm49cIxJruFknrKJZ1UtbeFIIJgu+rRWWcNSmsqVS3n7+FjVHBgesADkxYU9qrvHpnVkUXUTLi9SIrBQho3/UDvEORa5S/f914euJbxN/rNEw== Content-Type: text/plain; charset="utf-8" Content-ID: <5256406D18E5F04F88209FE4E3CF51E7@namprd14.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 63d4707b-f632-4bc0-c7b0-08d7954140a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 20:19:38.5295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BPwjPrHo1OFG1ToX8mJHTYvcijiUhLjMH2soGFGSy2hVBe2BbRBM5QaBqOWTGdnun/DLMETpEmg/f/KXzCZSKw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB2138 X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-OriginatorOrg: nbcuni.com X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_04:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 spamscore=0 bulkscore=0 priorityscore=1501 clxscore=1011 mlxscore=0 phishscore=0 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090166 Archived-At: Subject: Re: [arch-d] [EXTERNAL] Re: Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 20:19:48 -0000 DQoNCu+7v09uIDEvOS8yMCwgMTI6MDggUE0sICJBcmNoaXRlY3R1cmUtZGlzY3VzcyBvbiBiZWhh bGYgb2YgTGl2aW5nb29kLCBKYXNvbiIgPGFyY2hpdGVjdHVyZS1kaXNjdXNzLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIEphc29uX0xpdmluZ29vZEBjb21jYXN0LmNvbT4gd3JvdGU6DQoN CiAgICBGcm9tOiBpZXRmIDxpZXRmLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBCZW4g Q2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4NCiAgICA+IEkgYWdyZWUgd2l0aCB0aGF0IGZvciB0 aGUgSUVTRywgYnV0IHRoZSBJQUIgaXMgbm90IHVzdWFsbHkgaW4gYSBwb3NpdGlvbiB0byBhcHBy b3ZlIG9yIGJsb2NrIHNwZWNpZmljIHRlY2huaWNhbCBkZWNpc2lvbnMuIFllcywgaXQgc2V0cyBh cmNoaXRlY3R1cmFsIGRpcmVjdGlvbiwgYnV0IHNlZSBSaWNoYXJk4oCZcyBjb21tZW50IGRvd24t dGhyZWFkLg0KICAgIA0KICAgIFtKTF0gUGVyaGFwcyB3ZSBhcmUgdGhpbmtpbmcgdG9vIG5hcnJv d2x5IGFib3V0IHdoYXQgdGhlIElBQiBkb2VzPyBIZXJlIGFyZSBzb21lIGFyZWFzIGZvciBwb3Rl bnRpYWwgY29uZmxpY3QgdGhhdCBhcmUgdW5yZWxhdGVkIHRvIGFyY2hpdGVjdHVyYWwgZGlyZWN0 aW9uOg0KICAgIDEgLSBDb25maXJtaW5nIHRoZSBJRVRGIENoYWlyIGFuZCBBcmVhIERpcmVjdG9y cw0KICAgIDIgLSBTdGFuZGFyZHMgYXBwZWFscw0KICAgIDMgLSBSRkMgU2VyaWVzDQogICAgNCAt IExpYWlzb24gcm9sZXMNCiAgICA1IC0gQWR2aWNlIHRvIElTT0MNCg0KW0dEXSArIDYgLSBBcHBv aW50IGFuIElTT0MgVHJ1c3RlZSANCiAgICANCiAgICBbSkxdIEV2ZW4gaW4gYXJjaGl0ZWN0dXJh bCBvdmVyc2lnaHQsIHdoYXQgaWYgdGhlcmUgd2FzIGEgc3Ryb25nIHB1c2ggZm9yIGEgcGFydGlj dWxhciBhcHByb2FjaCBhZ2FpbnN0IGEgcGFydGljdWxhciBwcm90b2NvbCBvciBjb2RlYyBhbmQg c29tZW9uZSBvbiB0aGUgSUFCIGhhZCBhbiB1bmRpc2Nsb3NlZCBmaW5hbmNpYWwgc3Rha2UgaW4g YSBwYXRlbnQgcG9vbCB0aGF0IHdvdWxkIGRpcmVjdGx5IGJlbmVmaXQgZnJvbSBhIGNlcnRhaW4g ZGVjaXNpb24/IE9yIGlmIHRoZXkgIndvcmtlZCIgZm9yIGEgdW5pdmVyc2l0eSBidXQgd2VyZSAx MDAlIGZ1bmRlZCBieSBhIGdyYW50IGZyb20gYSBnb3Zlcm5tZW50IHRoYXQgd2FzIHVuZGVyd3Jp dGluZyB0aGVpciB0aW1lIHNwZWNpZmljYWxseSB0byB3b3JrIGFnYWluc3QgYSBzcGVjaWZpYyB1 cGdyYWRlIHRvIGVuY3J5cHRpb24/IE9yIHdoYXRldmVyIG90aGVyIGNhc2VzIHlvdSBtaWdodCBp bWFnaW5lLg0KICAgIA0KICAgIFtKTF0gU28gSU1PIGl0IHNlZW1zIGxpa2Ugc29tZSBDb0kgcG9s aWN5IGZvciB0aGUgSUFCIGlzIGJldHRlciB0aGFuIG5vIENvSSBwb2xpY3kuDQogICAgDQogICAg DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICBBcmNoaXRlY3R1cmUtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCiAgICBBcmNoaXRlY3R1cmUtZGlz Y3Vzc0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FyY2hpdGVjdHVyZS1kaXNjdXNzX187ISFQSVpl ZVc1d3NjeW5SUSE4TzJpQ3pnZVNsSTViQVBhb0xnby04MEs4SUdYYXA4c0lEenlNeWZIY3lUYVZq eE1HX3pVeFZEWExxajNOaWQxJCANCiAgICANCg0K From nobody Thu Jan 9 12:21:11 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92701202A0; Thu, 9 Jan 2020 12:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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=nostrum.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 5rL2k6dgv6hp; Thu, 9 Jan 2020 12:21:04 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AA6A91207FB; Thu, 9 Jan 2020 12:21:04 -0800 (PST) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 009KKxBS083665 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Jan 2020 14:21:00 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578601261; bh=AYngZb7tiZbxHzxKuE5CNWyrK8ezrccy59R5HlsI2RU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=fs1xqOuufkcefuDNk7cx+4Ct0X3YhuhNG1P/N8/S30qsDn5BBkZ3tUycpLi1DYnK9 cenmR4EAPis0gRLilsfzRPoW9dc5YNoXTjlUB7SSBol++52p+DDb4vMo8KVLEWY40I xVz/X+J5Hi++T5XzN8ei0zgg43jh9qvDYoNi1JUU= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Message-Id: <87973F7E-A12D-4DEC-A490-475B7C3BFF34@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_287540C7-2546-498F-9E77-720FC12B4308"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Thu, 9 Jan 2020 14:20:50 -0600 In-Reply-To: <73739D2E-EE15-4D49-8E99-0BAA79838548@cable.comcast.com> Cc: Joe Touch , IAB Chair , IAB IAB , IETF discussion list , "architecture-discuss@ietf.org" To: "Livingood, Jason" References: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> <79623A46-F585-4DD1-B4CA-C12967E7EE1B@nostrum.com> <73739D2E-EE15-4D49-8E99-0BAA79838548@cable.comcast.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 20:21:06 -0000 --Apple-Mail=_287540C7-2546-498F-9E77-720FC12B4308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 9, 2020, at 2:07 PM, Livingood, Jason = wrote: >=20 > From: ietf on behalf of Ben Campbell = >> I agree with that for the IESG, but the IAB is not usually in a = position to approve or block specific technical decisions. Yes, it sets = architectural direction, but see Richard=E2=80=99s comment down-thread. >=20 > [JL] Perhaps we are thinking too narrowly about what the IAB does? = Here are some areas for potential conflict that are unrelated to = architectural direction: > 1 - Confirming the IETF Chair and Area Directors > 2 - Standards appeals > 3 - RFC Series > 4 - Liaison roles > 5 - Advice to ISOC I think a good part of those categories are covered by the sections on = personnel and contract CoIs. I agree with those sections in principle. >=20 > [JL] Even in architectural oversight, what if there was a strong push = for a particular approach against a particular protocol or codec and = someone on the IAB had an undisclosed financial stake in a patent pool = that would directly benefit from a certain decision? Or if they "worked" = for a university but were 100% funded by a grant from a government that = was underwriting their time specifically to work against a specific = upgrade to encryption? Or whatever other cases you might imagine. I think the IPR pool example is already covered by the IETF IPR = policies. I assume those will continue to apply. (And I suppose a = reminder of them in any such CoI policy would not be a bad thing.) In the govt grant example: Is the issue not also true for someone = pushing similar views in, say, the TLS wg? It seems to me that an effort = to undermine a specific upgrade would be done more effectively at the wg = level than in the IAB. That all being said, I=E2=80=99m almost okay with the proposed text that = effectively says =E2=80=9CIAB members should use their judgement to = decide if they have a problem=E2=80=9D, but that doesn=E2=80=99t seem to = need to be said in a written policy (unless it=E2=80=99s purpose is to = explain why we don=E2=80=99t say more.) >=20 > [JL] So IMO it seems like some CoI policy for the IAB is better than = no CoI policy. >=20 I am not arguing for no policy. I agree in principle with the other two = bullets. Ben. --Apple-Mail=_287540C7-2546-498F-9E77-720FC12B4308 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----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl4XiyIACgkQgFZKbJXz 1A2kfBAAojoUZBIe3uumuaVWtONX2NkoTVDxNSxOfEV7jvHl1E4lJqTSUBx/iN0V JpW3QEVvI+DBh7iaBeMExCiIfMQZyJmHd0zMzU2xS5cj6U17Ufjz93vV5LHTIpbl KFLHweWB7DdZKw7kbehsHq05WQ4svmetF4KCU0xCcp8gVsv4g09B0CAG912OtF3z /OhOoxiUL+GBBH5Bk9YSvWjkOEeN5eiZeK4bSkJgV+e8mAhJgjGHSaLYU/bKsPqz RpnKTBUMq+dTctx3Qm2TtI1JxdRoiRvgwHnIKT9A0VQFUl8XE1b0uvUrytrmerGS NV0Lf2Rd5X1CkW1+HDC+HlrgpaeaQzVt5NiH681v9JhCXPd/k217677qq0S4YhBz YulOpkBhO/O7uK0mv5Y+nwewp5g0UxYx6f49Bpod8Ca0uxp/dJNtJwthemAku8/X XN//5iEimtTgEdC+74ecLyvgrwQNnEgFyvYfZGa6yDPzSWyl08PUpWmmAICglWv6 HnGP5F9Sof4xbsuInG7rZdpGqxDwgVB0kXICnOF1pl8HK2m/yCEikhEzLZCJAsyv yg25xxo9NDUJs9zpQIhX3HbB07q5RzHHONbElFOOe/pMmgaoZ+EEwbYo6rrG+roZ wGCf8vC6Kl1SX+3LTwKn0QN4cNuucNlaffKt0tG5AfLvukUCA0o= =nEa6 -----END PGP SIGNATURE----- --Apple-Mail=_287540C7-2546-498F-9E77-720FC12B4308-- From nobody Thu Jan 9 13:00:58 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2213312013B; Thu, 9 Jan 2020 13:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 oA-Mm_CE0SMH; Thu, 9 Jan 2020 13:00:49 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id B6BAB120288; Thu, 9 Jan 2020 13:00:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 03FD5299945B; Thu, 9 Jan 2020 16:00:47 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhVFViIoN9bd; Thu, 9 Jan 2020 16:00:40 -0500 (EST) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 49750299944A; Thu, 9 Jan 2020 16:00:39 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Scott O. Bradner" In-Reply-To: <87973F7E-A12D-4DEC-A490-475B7C3BFF34@nostrum.com> Date: Thu, 9 Jan 2020 16:00:38 -0500 Cc: Jason Livingood , IAB Chair , IETF discussion list , IAB IAB , "architecture-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2B5FED59-A77B-405F-9895-FDA920623D7B@sobco.com> References: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> <79623A46-F585-4DD1-B4CA-C12967E7EE1B@nostrum.com> <73739D2E-EE15-4D49-8E99-0BAA79838548@cable.comcast.com> <87973F7E-A12D-4DEC-A490-475B7C3BFF34@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 21:00:51 -0000 > On Jan 9, 2020, at 3:20 PM, Ben Campbell wrote: >=20 =20 > I think the IPR pool example is already covered by the IETF IPR = policies. I assume those will continue to apply. (And I suppose a = reminder of them in any such CoI policy would not be a bad thing.) a big question in the BOFs developing what is now RFC 8179 was =E2=80=98wh= o is a Participant=E2=80=9D and one sub issue in that topic involved participation by means of role - see RFC 8179 Section 1.m = - consensus in the BOF & mailing list was that WG Chairs & ADs were participants in a working group even if = they never posted to the mailing list or spoke in a meeting because of their role - the result being that they = were required to disclose any IPR they knew about that related to the WG work items there was no discussion participating by role for IAB members so having = something in an IAB CoI policy that=20 says, one way or the other, what IPR disclosure obligations arise from = the role of an IAB member - it might be as=20 simple as saying =E2=80=9CIAB members are treated as normal IETF = participants when it comes to their IPR disclosure=20 obligations under BCP 79.=E2=80=9D or saying =E2=80=9CIAB members are = categorized as participants in all IETF working groups=20 when it comes to their IPR disclosure obligations under BCP 79=E2=80=9D but I suggest saying something so as to not leave the question open for = review by plaintiffs lawyers in the future. Scott From nobody Thu Jan 9 13:10:38 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF64120807; Thu, 9 Jan 2020 13:10:36 -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_HELO_NONE=0.001, 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 Z3yTiWvg9z6Q; Thu, 9 Jan 2020 13:10:34 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 32FFF120801; Thu, 9 Jan 2020 13:10:34 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id s21so3035679plr.7; Thu, 09 Jan 2020 13:10:34 -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=t9V/P/+iz5ZLe/dsdX0cZxNQp3KncbxZn+jwBHBXGRI=; b=aPy0/+wQ61rgTsItQs5YWaZHNa7cW/8CK6zpVS0WPdZKx3saaPCQHhQicO/ziS42qa EvIF9ZnpmA/4dTnBbrPpZEJFvjcpAGgMMJxqAmgxGl6MhwzC8RRkF08lSSCNSoE8LPZl DbQil1J233pCrc/1JM23Vk3/Gea84VPrrdXmOsqDz6x7lZhe1maXCupOJyN5aKZ6mNwR CAWw8Rf9p7YHliTQ6sM/pg4y9ChXXDd4VKV74lFay/CJUn89fO6fjhW2CpAmjqGReIfA qyjrOqWAoDq9tw5B/lsMTdM3vDt4cAcfC2Mz5zQmHrIQT7RKjQJGGvzvF5I+FRPeTAsN K9EQ== 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=t9V/P/+iz5ZLe/dsdX0cZxNQp3KncbxZn+jwBHBXGRI=; b=hNevHEDMlwFz7lCYcqQlnNXBfbjbg2imzx/ErBmO2q3y2/db/e8t9qJWJnn8JsWxjh c4ztBnsa03Y5A4ZKJfoDxhw74E8Tnj8/BQyQiJpO0Vn2rrkHLABvruDl0WAeFUfYDbYR I8lH9Ja8ULg5E8DaOAAnQ1N68Y012vl4NV4F930G41aSwJnXltsBGNWiyHt5Fzuu0eoB mLTx/ZqCvyMQ6/Avgk/U9XhKE+Ns4zuXSEZeP41r6Zf+TcBQoCMds3i7fSaqR9WBXdZt fa1yYEOQQdY+f6yvgH/iwL8sxrqQw500QmUNiAFHD7kHanLKCUEPLm+BuCsfTk55Luio gQDA== X-Gm-Message-State: APjAAAW4jVBlUf23gWLIFeUxJP2LvRwGdtjFdmZTqlV/8DF44Noz3RTm eHJ2rJiWyFP7mWfiEboNCc+mcBTI47vLgprPRLI= X-Google-Smtp-Source: APXvYqx0HW5KMOfhsNZEGucyEIgnQVnUrfsRvBIrk2KeJtgOLtwFSJy4l5ywnQ18g+eim7NanEF06Xr5dKblS088NFE= X-Received: by 2002:a17:90a:bb0c:: with SMTP id u12mr79548pjr.100.1578604233629; Thu, 09 Jan 2020 13:10:33 -0800 (PST) MIME-Version: 1.0 References: <52B13773-88C3-490D-8003-475F845F1ACB@nbcuni.com> In-Reply-To: <52B13773-88C3-490D-8003-475F845F1ACB@nbcuni.com> From: Mary Barnes Date: Thu, 9 Jan 2020 15:10:22 -0600 Message-ID: To: "Deen, Glenn (NBCUniversal)" Cc: "Livingood, Jason" , Ben Campbell , Joe Touch , IAB Chair , IAB IAB , IETF discussion list , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009626fa059bbb70ef" Archived-At: Subject: Re: [arch-d] [EXTERNAL] Re: Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 21:10:36 -0000 --0000000000009626fa059bbb70ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Jason. The notion that much of the IAB's work is focused on technical issues is a mis-conception. And, beyond Glenn's point about ISOC Trustee appointment, here's a complete list of all the appointments and confirmations for which the IAB is responsible: https://www.iab.org/activities/iab-appointments-and-confirmations/ And, you can look at many of the IAB correspondence, reports, etc and see that many of the topics are not particularly technical: https://www.iab.org/documents/correspondence-reports-documents/ I think some sort of COI policy is helpful, although as others have suggested, I think we have to put a certain level of trust in the individuals to do the right thing. Regards, Mary. On Thu, Jan 9, 2020 at 2:20 PM Deen, Glenn (NBCUniversal) < Glenn.Deen@nbcuni.com> wrote: > > > =EF=BB=BFOn 1/9/20, 12:08 PM, "Architecture-discuss on behalf of Livingoo= d, Jason" > Jason_Livingood@comcast.com> wrote: > > From: ietf on behalf of Ben Campbell < > ben@nostrum.com> > > I agree with that for the IESG, but the IAB is not usually in a > position to approve or block specific technical decisions. Yes, it sets > architectural direction, but see Richard=E2=80=99s comment down-thread. > > [JL] Perhaps we are thinking too narrowly about what the IAB does? > Here are some areas for potential conflict that are unrelated to > architectural direction: > 1 - Confirming the IETF Chair and Area Directors > 2 - Standards appeals > 3 - RFC Series > 4 - Liaison roles > 5 - Advice to ISOC > > [GD] + 6 - Appoint an ISOC Trustee > > [JL] Even in architectural oversight, what if there was a strong push > for a particular approach against a particular protocol or codec and > someone on the IAB had an undisclosed financial stake in a patent pool th= at > would directly benefit from a certain decision? Or if they "worked" for a > university but were 100% funded by a grant from a government that was > underwriting their time specifically to work against a specific upgrade t= o > encryption? Or whatever other cases you might imagine. > > [JL] So IMO it seems like some CoI policy for the IAB is better than > no CoI policy. > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/archite= cture-discuss__;!!PIZeeW5wscynRQ!8O2iCzgeSlI5bAPaoLgo-80K8IGXap8sIDzyMyfHcy= TaVjxMG_zUxVDXLqj3Nid1$ > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000009626fa059bbb70ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Jason.=C2=A0 The notion=C2=A0that much of the= IAB's work is focused on technical issues is a mis-conception.=C2=A0 A= nd, beyond Glenn's point about ISOC Trustee appointment, here's a c= omplete list of all the appointments and confirmations for which the IAB is= responsible:=C2=A0=C2=A0https://www.iab.org/activities/iab-appointment= s-and-confirmations/

And, you can look at many of th= e IAB correspondence, reports, etc and see that many of the topics are not = particularly technical:=C2=A0=C2=A0

I thin= k some sort of COI policy is helpful, although as others have suggested, I = think we have to put a certain level of trust in the individuals to do the = right thing.

Regards,
Mary.

On Thu, Jan 9, 2020 at 2:20 PM Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com> wrote:


=EF=BB=BFOn 1/9/20, 12:08 PM, "Architecture-discuss on behalf of Livin= good, Jason" <architecture-discuss-bounces@ietf.org on behalf o= f Jason_Li= vingood@comcast.com> wrote:

=C2=A0 =C2=A0 From: ietf <ietf-bounces@ietf.org> on behalf of Ben Campbell <ben@nostrum.com><= br> =C2=A0 =C2=A0 > I agree with that for the IESG, but the IAB is not usual= ly in a position to approve or block specific technical decisions. Yes, it = sets architectural direction, but see Richard=E2=80=99s comment down-thread= .

=C2=A0 =C2=A0 [JL] Perhaps we are thinking too narrowly about what the IAB = does? Here are some areas for potential conflict that are unrelated to arch= itectural direction:
=C2=A0 =C2=A0 1 - Confirming the IETF Chair and Area Directors
=C2=A0 =C2=A0 2 - Standards appeals
=C2=A0 =C2=A0 3 - RFC Series
=C2=A0 =C2=A0 4 - Liaison roles
=C2=A0 =C2=A0 5 - Advice to ISOC

[GD] + 6 - Appoint an ISOC Trustee

=C2=A0 =C2=A0 [JL] Even in architectural oversight, what if there was a str= ong push for a particular approach against a particular protocol or codec a= nd someone on the IAB had an undisclosed financial stake in a patent pool t= hat would directly benefit from a certain decision? Or if they "worked= " for a university but were 100% funded by a grant from a government t= hat was underwriting their time specifically to work against a specific upg= rade to encryption? Or whatever other cases you might imagine.

=C2=A0 =C2=A0 [JL] So IMO it seems like some CoI policy for the IAB is bett= er than no CoI policy.


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Architecture-discuss mailing list
=C2=A0 =C2=A0 Architecture-discuss@ietf.org
=C2=A0 =C2=A0 https://urldefense.com/v3/__https://www.ietf.org/mailman/listin= fo/architecture-discuss__;!!PIZeeW5wscynRQ!8O2iCzgeSlI5bAPaoLgo-80K8IGXap8s= IDzyMyfHcyTaVjxMG_zUxVDXLqj3Nid1$


_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000009626fa059bbb70ef-- From nobody Thu Jan 9 14:40:21 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FACE120829; Thu, 9 Jan 2020 14:40:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=elandsys.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 4wPpkB5quvBF; Thu, 9 Jan 2020 14:40:18 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 579A5120825; Thu, 9 Jan 2020 14:40:18 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.131.215]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 009Me46B003536 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2020 14:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1578609616; x=1578696016; i=@elandsys.com; bh=4B11ErzaVeb2TzfKmohQ7t23ORq+b3hZaZtb3amg/Yk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mL8zyH6naAq2AkoI6SB03Tus0HN1ci3Pn6/GWd5mLhSpf7br4lPcd62zEHjAZ9kAR m9//HLacnXhrjARyhVQFa64pL/GL6aSqOmyCf4mHQZwbJxc8l6KzFwIn+soJ8NbBA+ QDJSwTwXscQ5SsFCS58lbfBuw+oZRxx74oSUAUyE= Message-Id: <6.2.5.6.2.20200109123000.132b1688@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 09 Jan 2020 14:31:50 -0800 To: Ted Hardie , architecture-discuss@ietf.org From: S Moonesamy Cc: Internet Architecture Board In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <6.2.5.6.2.20200108213623.144cb518@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] [IAB] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 22:40:20 -0000 Hi Ted, At 11:41 AM 09-01-2020, Ted Hardie wrote: >A few responses below, in-line. Thanks. I'll comment in-line. >This policy deals with covered individuals' work within the context >of their role on the IAB. If they have other roles, they may also >need to abide by the policies of those bodies (e.g. the LLC COI >policy, found at: >https://ietf.org/about/administration/policies-procedures/ >). I guess that I was not clear. The obligation for the IETF LLC Board Directors is, in simple terms, to act in the interest of that legal entity. It would be there even if there wasn't a LLC conflict of interest policy. The sentence from the IAB Charter states that the member shall not have any obligation. The two obligations are in conflict with each other. >The first part of the above paragraph relates to appointments which >result in a contract with the IETF LLC. The IAB's role in approving >RSOC recommendations for the RSE is an example. The IAB does not >negotiate the contract for the RSE, but since the approval is a >required step prior to that contract negotiation, individuals on the >IAB need to be aware of any conflicts of interest in providing or >withholding an approval. Ok. >The second part is unrelated to the IETF LLC, and I believe, based >on your comment, it might be better to split the two ideas into two >different paragraphs. Ok. >Then the other members of the IAB are aware of the conflict and can >take it into account. Ok. >An example: The IAB as a whole decides that it would be useful to >take up the topic of geographic redundancy of submarine cable >infrastructure. Some IAB member might have a member of their >immediate family that is a director of a company focused on >providing land-side infrastructure to that industry; as a result, a >statement by the IAB suggesting more or less redundancy in that >infrastructure could have an impact on their household. By my >reading, disclosing that conflict would be required by this draft policy. Thanks for providing an example to convey the idea. >But if a portion of the analysis were to examine application layer >protocol failover tolerance, so as to understand the cases for which >non-submarine cable infrastructure could be used as redundant >capacity, the IAB member might choose not to recuse from the >discussion of that topic *even if they recused from the discussion >of the final recommendation on the main issue*. The data and >analysis on failover tolerance is broadly useful, after all, and it >may be an area of concern for them in their own work. The rest of >the IAB would be aware of the issue and could provide guide rails if >needed, but the discretion here is to allow IAB members to >contribute when appropriate, even when some conflict of interest has >been noted. > >This is just my opinion, though, and my reading of the draft policy. The above is the usual practice (outside the IAB). If I could raise a concern, it would be about the following sentence: "In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community". It is not possible to get a sense of what that community perceives as being in its best interest. It is like putting in a requirement which sounds good in theory and which cannot be assessed in a practical manner. Regards, S. Moonesamy From nobody Thu Jan 9 14:40:35 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0621612086F; Thu, 9 Jan 2020 14:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 LZ2z5zQSHwld; Thu, 9 Jan 2020 14:40:23 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 E438C12087D; Thu, 9 Jan 2020 14:40:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FcT+6QbkbpF1NVGT71n2yxDar1a3YHDMnpGN5RC7gdA=; b=jL6Ge6oveVfDaq95x4t1WS2+J D7srEKgjolSFKJ+ioYYQI2kEaNKI/WqPGWUaU17R8zDZC8oULobcvMFahFJrvkYLlVjnMd2ONFE0R 8vtbU3flWQAyuu4w3oN7+X2pmvbTZtzNdzQAgNFN3+aKLw9IOlYShalyqZqbEseOFAbmpOGKQOJ/m HerLLNWOA39d1W+6N8E6BvYarKezfoV3X2WuXduCluvuUXTg4pIrsO42LQ1m0mYaZoVXvYEjCm8Ij cyqyLgU1I9LlnGuSGWkoDkS+JjpsomIWywaFScdIrbutNJgQRezcd9EKjWwIgHAIvgahxZPgzlnSt 66tox6Czw==; Received: from [::1] (port=44532 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from ) id 1ipgTS-003OGU-A9; Thu, 09 Jan 2020 17:40:22 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a4da178f75e2759888d63513768d5f9a" Date: Thu, 09 Jan 2020 14:40:18 -0800 From: Joe Touch To: Eric Rescorla Cc: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Message-ID: <2377bee131af6f5a6f5a1104bc25e056@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.7 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 22:40:28 -0000 --=_a4da178f75e2759888d63513768d5f9a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2020-01-09 10:46, Eric Rescorla wrote: > I concur with Richard here. The IETF is most successful when we get > input from people who are directly involved in the technologies that > we are standardizing, but of course that very often means that they > are working on those technologies for their employer. And indeed > one of the criteria we often use to ask whether someone is a good > fit for leadership is whether they have this kind of non-standards > "day job" expertise. That, IMO, is why we encourage their participation in WG discussions and on lists. But it is dangerous to have those parties directly involved in decision making. The actual and potential COI (esp. perceived potential COI) undermine the decisions made - even when those decisions are otherwise reasonable. I.e., think of this as protecting the value of IAB decisions (and, as Ben noted, there are many, esp. during appeals, that are of a substantive nature that COI benefits). Joe --=_a4da178f75e2759888d63513768d5f9a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 2020-01-09 10:46, Eric Rescorla wrote:

I concur with Richard here. The IETF is most successful wh= en we get
input from people who are directly involved in the technolog= ies that
we are standardizing, but of course that very often means tha= t they
are working on those technologies for their employer. And indeed
one of the criteria we often use to ask whether someone is a good
fit for leadership is whether they have this kind of non-standards
"day job" expertise.
 
 
That, IMO, is why we encourage their participation in WG discussions a= nd on lists.
 
But it is dangerous to have those parties directly involved in decisio= n making. The actual and potential COI (esp. perceived potential COI) under= mine the decisions made - even when those decisions are otherwise reasonabl= e.
 
I.e., think of this as protecting the value of IAB decisions (and, as = Ben noted, there are many, esp. during appeals, that are of a substantive n= ature that COI benefits).
 
Joe


--=_a4da178f75e2759888d63513768d5f9a-- From nobody Thu Jan 9 14:59:26 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382C4120807; Thu, 9 Jan 2020 14:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 MWqZqeuO5UcU; Thu, 9 Jan 2020 14:59:20 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 699FF120241; Thu, 9 Jan 2020 14:59:20 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id g23so101441vsr.7; Thu, 09 Jan 2020 14:59:20 -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=F/3ay+sYg9MxcVh2s8h2Y7whzO+xaAJxl4xQwrQydMI=; b=ce/H9IqkdvDowfhvtgPRN8a9l+PjICUTaynAHCJ2Cg5caky7ui2Hpifk2zQY3akGbO 7JazuD1J53Wkww4EVCZMAlW/f4KsWHCUFgChnjxCb2JSWEzxhMHCuHBRiSHnukIZCGIP xytc+d2azYRnhGq1wQLciEtpluPUucOo79svtM33bEfE7uYQU7LDcv7HRXtbLHSYRHx0 ezAsjdR8MheCSbWaKPKUPT9F8acyZOZjI6op+WbsoTG7m438QRX4asBCcbGRSd2/pLoV 4nqxQuWC5NnSFONFfvmwsE8Nc8WPAfB1WILkXyOKEAVveiAEYSO2P421/TlvceofiLeS rx3A== 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=F/3ay+sYg9MxcVh2s8h2Y7whzO+xaAJxl4xQwrQydMI=; b=IivECdbJuZIy+cz1p1yW2dJA5JTxShDPSily9t5M+5TB7f1WvBWdVFuin2EhYR+uJp sJ6YLWc3MeSuqJndAo7zOhYs88l00xAqVQtAX0RoeuKyWqTKLSMIvLgrybtHRBzoBO5T 5xBQCOgKP0QweeOHITfJTHGRm78gZmN1fhG/J+jZmOWJzWtzB91MqijFldKqzTb3b3ox U7tClMc1WVjvnZUQB7qKGFy1vAaLXXvSFsbFtuFuxtyMVrBJ6ufpapwGV3NqTQjBXG1W XHgU8j/Te7+Us1FGrWG2kGd6FMw1sNuuICyUA23WP/NUFYVOymGFI1mV1OKrNyGMrQ+m sQTw== X-Gm-Message-State: APjAAAVd0kA6NpgtibYo7dmnVkZPlyGTwKfdQ9gj6XkGEDbjVnyqLTjV XAUQRAewW9pYafQ2X5shqnJt34qwSodDMPSU7CBRTA== X-Google-Smtp-Source: APXvYqw2wjOtcBzHIifJpZ8/JKEmZeeHKMML6R7INONcr2uIqEUS5YOjH+MHjPSjwSDI1AikZwbXrg+h6XnPEvh9hTU= X-Received: by 2002:a05:6102:20c:: with SMTP id z12mr69978vsp.32.1578610759083; Thu, 09 Jan 2020 14:59:19 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: From: Bernard Aboba Date: Thu, 9 Jan 2020 14:59:08 -0800 Message-ID: To: Richard Barnes Cc: IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000088abbd059bbcf588" Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 22:59:24 -0000 --00000000000088abbd059bbcf588 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agree with Richard here. Much of the IAB work is technical in nature. The IAB should therefore not need a conflict-of-interest policy as heavy weight as that required to assume a senior role within government, a legislature or a governmental advisory committee. Having served on a governmental advisory committee covered by FACA, it would appear to me that the proposed IAB COI policy is potentially more stringent. As an example, under FACA I was not required to provide a complete financial disclosure. The guidance was that a disclosure need only be made in the event of a potential conflict, should one arise. On Thu, Jan 9, 2020 at 8:58 AM Richard Barnes wrote: > I would propose the IAB not adopt this policy, or at least scope it way > down. > > Much of the IAB's work is focused on technical issues, at a high enough > strategic level that the impacts to specific people or companies are high= ly > attenuated. In those discussions, the IAB's work benefits from having > diverse opinions, including the opinions of those who have skin in the > game. Trying to introduce some notion of CoI in this context would be > harmful -- because there's no hard conflict, it will inevitably be vague, > and thus primarily a tool for IAB members to try to silence one another o= r > a cause for IAB members to self-censor. > > Where the IAB is directly involved in finance or personnel decisions, > there of course should be guards against self dealing. That's where any > CoI policy for the IAB should stop. > > --Richard > > On Wed, Jan 8, 2020 at 6:16 PM IAB Chair wrote: > >> Dear Colleagues, >> >> The IAB is considering adoption of the conflict of interest policy >> below. If you have comments on this draft policy, please send them to >> iab@iab.org. >> >> best regards, >> Ted Hardie >> for the IAB >> >> >> INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >> >> This policy covers the nomcom-selected Internet Architecture Board (IAB) >> members and ex-officio members (collectively, =E2=80=9CCovered Individua= ls=E2=80=9D). This >> policy has no impact on any other participants in IAB activities, for >> instance liaisons to and from the IAB or IAB program members. >> >> In carrying out their IAB role, Covered Individuals must act in the best >> interest of the Internet community. Occasionally this duty may be=E2=80= =94or may >> appear to be=E2=80=94incompatible or in conflict with a Covered Individu= al=E2=80=99s >> personal interests (including interests of their family members), or the >> interests of an organization of which the Covered Individual is an >> employee, director, owner, or otherwise has business or financial intere= st. >> If a Covered Individual has a conflict of interest for whatever reason, >> that individual must avoid participating in the work of the IAB that >> touches on the related matter. >> >> The IAB does not directly deal with matters relating to contracts or >> finance. The IAB does, however, have a role in personnel decisions, and = its >> decisions and outputs have a potential to indirectly affect contracts >> within the IETF system. IAB's technical decisions and outputs have also = a >> potential to impact both work elsewhere in the IETF and businesses that >> employ or develop Internet technology. >> >> Covered Individuals shall not use the IAB=E2=80=99s resources or decisio= ns as a >> means for personal or third-party gain. >> Disclosure of Actual or Potential Conflicts >> >> The IAB requires that all Covered Individuals disclose their main >> employment, sponsorship, consulting customer, or other sources of income >> when joining the IAB or whenever there are updates. >> >> In addition, when a topic is discussed at the IAB, the Covered >> Individuals are required to promptly disclose if that topic constitutes = a >> perceived or potential conflict of interest. Once disclosed, Covered >> Individuals may recuse from participation in discussions or decisions at >> their discretion. >> >> The specific conflicts that may cause a perceived or potential conflict >> of interest are matters for individual and IAB judgment, but generally c= ome >> in the following forms: >> >> - >> >> A personnel decision relates to the Covered Individual, a colleague >> that the Covered Individual's works closely with, or a family member.= For >> the purposes of this policy, a "person working closely with" is someo= ne >> working in the same team or project, or a direct manager or employee = of the >> Covered Individual. And "family" means a spouse, domestic partner, ch= ild, >> sibling, parent, stepchild, stepparent, and mother-, father-, son-, >> daughter-, brother-, or sister-in-law, and any other person living in= the >> same household, except tenants and household employees. >> - >> >> A decision or output from the IAB impacts a contract that the IETF >> enters into with a party, and that party relates to the Covered Indiv= idual, >> a colleague that the Covered Individual's works closely with, or a fa= mily >> member. >> - >> >> Activity on the IAB involves discussion and decisions regarding >> technical matters, mainly related to IETF activities. As an activity >> adjacent to a standardization process, it is often the case that Cove= red >> Individuals will have some (frequently non-financial) stake in the ou= tcome >> of discussions or decisions that relate to technical matters. This po= licy >> does not require that Covered Individuals disclose such conflicts of >> interest as they relate to technical matters. However, Covered Indivi= duals >> need to exercise their judgment and, in extraordinary cases be willin= g to >> disclose potential or perceived conflicts of interest even as they re= late >> to technical matters. For example, if a Covered Individual's sponsor = were >> in the process of entering a new market where there is an ongoing IAB >> discussion, then disclosure, or even recusal, might be appropriate, e= ven if >> difficult. >> >> Disclosure Transparency >> >> A person's recusal to participate in the discussion of a topic is always >> noted in the public IAB minutes. In addition, the IAB will maintain a >> repository of all general disclosures of employment and other sponsorshi= p. >> It is expected that much of this repository is public, but there can be >> situations where some disclosures (such as customers of consultants) are >> private. >> >> >> >> >> >> _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --00000000000088abbd059bbcf588 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree with Richard here.=C2=A0 Much of the IAB work is tec= hnical in nature.=C2=A0 The IAB should therefore not need a conflict-of-int= erest policy as heavy weight as that required to assume a senior role withi= n government, a legislature or a governmental advisory committee.=C2=A0
Having served on a governmental advisory committee covered= by FACA, it would appear to me that the proposed IAB COI policy is potenti= ally more stringent.=C2=A0 As an example, under FACA I was not required to = provide a complete financial disclosure.=C2=A0 The guidance was that a disc= losure need only be made in the event of a potential conflict, should one a= rise.=C2=A0

On Thu, Jan 9, 2020 at 8:58 AM Richard Barnes <rlb@ipv.= sx> wrote:
I would propose the IAB not adopt this policy, or at le= ast scope it way down.

Much of the IAB's work = is focused on technical issues, at a high enough strategic level that the i= mpacts to specific people or companies are highly attenuated.=C2=A0 In thos= e discussions, the IAB's work benefits from having diverse opinions, in= cluding the opinions of those who have skin in the game.=C2=A0 Trying to in= troduce some notion of CoI in this context would be harmful -- because ther= e's no hard conflict, it will inevitably be vague, and thus primarily a= tool for IAB members to try to silence one another or a cause for IAB memb= ers to self-censor.

Where the IAB is directly = involved in finance or personnel decisions, there of course should be guard= s against self dealing.=C2=A0 That's where any CoI policy for the IAB s= hould stop.

--Richard

On Wed, Jan 8, 2020= at 6:16 PM IAB Chair <iab-chair@iab.org> wrote:
=20 =20 =20

<= /span>Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.=C2=A0 If you have comments on this draft policy, please send them to=C2=A0iab@iab.org.

best regards,

Ted Hardie
for the IAB

INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY

This policy covers the nomcom-selected Internet Architecture Board (IAB) members and ex-officio members (collectively, =E2=80=9CCo= vered Individuals=E2=80=9D). This policy has no impact on any other partici= pants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in co= nflict with a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, o= r a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partn= er, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's recusal to participate in the discussion of a topic i= s always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.



_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--00000000000088abbd059bbcf588-- From nobody Thu Jan 9 15:59:49 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5282B120831 for ; Thu, 9 Jan 2020 15:59:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 8lwsHXN-Q4uL for ; Thu, 9 Jan 2020 15:59:39 -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 3CB84120810 for ; Thu, 9 Jan 2020 15:59:39 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id z22so227350ljg.1 for ; Thu, 09 Jan 2020 15:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xZGMtq1nQFigj2Qe0Xq8HQFRTkeUZiXDIAnAHHwehPw=; b=1aBqPZUxztwSjRwwta+r30p9Shnd5GoazkA1jZ/PsWPgXjUI3RanGYwXgUBsJR+F2t /VscAKpZZa0fIyphyd1qz7CDPm0XP1SJLluB/tgGJgh1/yW8t9PSJA+eGQ3soe34YpE9 cgdqybqiUYcMkHkDrwiGqK65K8aIDugz6k54ONRRhk3lwadIVGMty4Z15AbvVjtfGakR N7W4gtQ4AwgepqsKvfHIST9JANBd9kjv1kK8pRn+89qtN4I3fKSwExs8vtab8tEi2Z/5 OogOKf13GAMSpsjGC2XdpFnks2/4KElXor468hIqmXbXyqMV9mhuIlEX3ylNy4HIjDFh hw/w== 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=xZGMtq1nQFigj2Qe0Xq8HQFRTkeUZiXDIAnAHHwehPw=; b=i0Vk7DkSXNrWYEElHdF/+keasMGZem3yF+e9ZF1RLPztRmGqLSA3VT5G3DW2T9vXWR 4OvKQo4bTvRLrHV6cjgZHFNDdAUddlwGwc3x24PPQgl1Efw8MTvZKPOe8UynjXhkTfAM DXD4L06LNin4U5Od2VaKARAwbDqp7HbeGvnn34t6OihfcQFwwwBNgz9SNBH109mMh+/A wqE8SFTnjhib6hgNmmMjtPHaLTcZOpUW+cEWPRPlaMqTdzIG7EoXJcF3hadk7QL0HOB9 9XgSEZgVbINMyL6pCipjZOFAK7kZGHdTpy0MPDgN9Ex9ymbbuR6DBL+GhSgiLAfu8ZbO zoyg== X-Gm-Message-State: APjAAAVkJok+dueHWjw2bImSKqPpyLMi1e3U8npICyT3th28tIHwNWGc q2KOxtv4PQ5qEzDfAn3g0PeiMwcRjZHR4+OyiElPXA== X-Google-Smtp-Source: APXvYqxON2zPyochOOZTblm8CMpQD58MOQ1IMqIzAKWjfkdRCUDVJZnmnye91JEik21L5GqhGE8jX95C9Lb2GQ/AzcI= X-Received: by 2002:a2e:9008:: with SMTP id h8mr388738ljg.217.1578614377503; Thu, 09 Jan 2020 15:59:37 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <2377bee131af6f5a6f5a1104bc25e056@strayalpha.com> In-Reply-To: <2377bee131af6f5a6f5a1104bc25e056@strayalpha.com> From: Eric Rescorla Date: Thu, 9 Jan 2020 15:59:01 -0800 Message-ID: To: Joe Touch Cc: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000356e07059bbdcdbd" Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 23:59:42 -0000 --000000000000356e07059bbdcdbd Content-Type: text/plain; charset="UTF-8" On Thu, Jan 9, 2020 at 2:40 PM Joe Touch wrote: > On 2020-01-09 10:46, Eric Rescorla wrote: > > I concur with Richard here. The IETF is most successful when we get > input from people who are directly involved in the technologies that > we are standardizing, but of course that very often means that they > are working on those technologies for their employer. And indeed > one of the criteria we often use to ask whether someone is a good > fit for leadership is whether they have this kind of non-standards > "day job" expertise. > > > > That, IMO, is why we encourage their participation in WG discussions and > on lists. > > But it is dangerous to have those parties directly involved in decision > making. The actual and potential COI (esp. perceived potential COI) > undermine the decisions made - even when those decisions are otherwise > reasonable. > > I.e., think of this as protecting the value of IAB decisions (and, as Ben > noted, there are many, esp. during appeals, that are of a substantive > nature that COI benefits). > And yet we routinely allow have WG chairs and ADs who are deeply involved (and whose employers are deeply involved) in the technologies that are being standardized. -Ekr > Joe > > > --000000000000356e07059bbdcdbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 2:40 PM Joe To= uch <touch@strayalpha.com>= ; wrote:

On 2020-01-09 10:46, Eric Rescorla wrote:

I concur with Richard here. The IETF is most successful wh= en we get
input from people who are directly involved in the technologie= s that
we are standardizing, but of course that very often means that th= ey
are working on those technologies for their employer. And indeed
one of the criteria we often use to ask whether someone is a good
fit for leadership is whether they have this kind of non-standards
"day job" expertise.
=C2=A0
=C2=A0
That, IMO, is why we encourage their participation in WG discussions a= nd on lists.
=C2=A0
But it is dangerous to have those parties directly involved in decisio= n making. The actual and potential COI (esp. perceived potential COI) under= mine the decisions made - even when those decisions are otherwise reasonabl= e.
=C2=A0
I.e., think of this as protecting the value of IAB decisions (and, as = Ben noted, there are many, esp. during appeals, that are of a substantive n= ature that COI benefits).

And yet we routinely allow have WG chairs and ADs who are deeply involved = (and whose employers are deeply involved) in the technologies that are bein= g standardized.

-Ekr

=C2=A0
Joe


--000000000000356e07059bbdcdbd-- From nobody Thu Jan 9 17:33:13 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866D3120131; Thu, 9 Jan 2020 17:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 hsEKHjHPNLKG; Thu, 9 Jan 2020 17:33:10 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 0C0D2120288; Thu, 9 Jan 2020 17:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=wIU3yYqsr66mRzy6RdJQad6Ex8uxKgKu30EpExjdPaM=; b=D6UZJs9vpLoDzSTPXv+IRX/Z/h oQucsYAR7iLjeRy47vNlEh00sq//W6a8w+JweuvVcYUxUVzswNjpqo74EJIn1bWwOwaQdx0mBxOi/ JN7tksFhITvrc2QN02xsV99GgJ12N9z0EiYKn1wbiQ1InhofdgJKyhXX020xUqzshT7r/YWcvwTf8 T2b3hU9JFn+1TIeuxUPEYnVM3BAh34UvDRLya6q8MMJzO+niz4rUS6uBaneCjIrCURPg6cdbOnwQf zlQyb7TcoybbuINAW4m+6OhIV1XjbVKPuGaCcAa3xG1MSFDFMJd9Af+BS5xvMTfoRflydtpCmjwRc Q8t2XElg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:54648 helo=[192.168.1.2]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ipjAe-001v1m-S5; Thu, 09 Jan 2020 20:33:09 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-1DABDE5E-3ECF-4D58-B95A-026E399AA6AE Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: Date: Thu, 9 Jan 2020 17:33:02 -0800 Cc: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org Message-Id: References: To: Eric Rescorla X-Mailer: iPad Mail (17C54) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 01:33:12 -0000 --Apple-Mail-1DABDE5E-3ECF-4D58-B95A-026E399AA6AE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. And it at times has been an issue. Joe > On Jan 9, 2020, at 3:59 PM, Eric Rescorla wrote: >=20 > =EF=BB=BF >=20 >=20 >> On Thu, Jan 9, 2020 at 2:40 PM Joe Touch wrote: >>> On 2020-01-09 10:46, Eric Rescorla wrote: >>>=20 >>> I concur with Richard here. The IETF is most successful when we get >>> input from people who are directly involved in the technologies that >>> we are standardizing, but of course that very often means that they >>> are working on those technologies for their employer. And indeed >>> one of the criteria we often use to ask whether someone is a good >>> fit for leadership is whether they have this kind of non-standards >>> "day job" expertise. >> =20 >> =20 >> That, IMO, is why we encourage their participation in WG discussions and o= n lists. >> =20 >> But it is dangerous to have those parties directly involved in decision m= aking. The actual and potential COI (esp. perceived potential COI) undermine= the decisions made - even when those decisions are otherwise reasonable. >> =20 >> I.e., think of this as protecting the value of IAB decisions (and, as Ben= noted, there are many, esp. during appeals, that are of a substantive natur= e that COI benefits). >=20 > And yet we routinely allow have WG chairs and ADs who are deeply involved (= and whose employers are deeply involved) in the technologies that are being s= tandardized. >=20 > -Ekr >=20 >> =20 >> Joe >>=20 --Apple-Mail-1DABDE5E-3ECF-4D58-B95A-026E399AA6AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes.  And it at times= has been an issue.

Joe

On Jan 9, 2020, at 3:59 PM,= Eric Rescorla <ekr@rtfm.com> wrote:

=EF=BB=BF


On Thu, Jan 9, 2020 at 2:40 PM Joe Touch <touch@strayalpha.com> wrote:

On 2020-01-09 10:46, Eric Rescorla wrote:

I concur with Richard here. The IETF is most successful whe= n we get
input from people who are directly involved in the technologies t= hat
we are standardizing, but of course that very often means that they
are working on those technologies for their employer. And indeed
one of the criteria we often use to ask whether someone is a good
=
fit for leadership is whether they have this kind of non-standards
"day job" expertise.
 
 
That, IMO, is why we encourage their participation in WG discussions an= d on lists.
 
But it is dangerous to have those parties directly involved in decision= making. The actual and potential COI (esp. perceived potential COI) undermi= ne the decisions made - even when those decisions are otherwise reasonable.<= /div>
 
I.e., think of this as protecting the value of IAB decisions (and, as B= en noted, there are many, esp. during appeals, that are of a substantive nat= ure that COI benefits).

An= d yet we routinely allow have WG chairs and ADs who are deeply involved (and= whose employers are deeply involved) in the technologies that are being sta= ndardized.

-Ekr

 
Joe


= --Apple-Mail-1DABDE5E-3ECF-4D58-B95A-026E399AA6AE-- From nobody Thu Jan 9 17:40:48 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71235120288 for ; Thu, 9 Jan 2020 17:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viagenie-ca.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 Iled04pVnnJG for ; Thu, 9 Jan 2020 17:40:38 -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 797F4120131 for ; Thu, 9 Jan 2020 17:40:38 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id 21so517064qky.4 for ; Thu, 09 Jan 2020 17:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=yHMwuAvLK9gUw6iIFm/sm9hze3x1TscAYm1qCihsuYo=; b=CVYDrDaMpRJVVvPJq0uTiMCgf01VkIupNu/vOMj3Xy8lVy9FvtDFhJQsyJkV6l3R87 Hj/Hwc6wiJrVulwz9U6RS/m9jLier4HePapTVnMbZohQYaxgm3dTdFHM0V5crbh2FWe7 +/uloS2/e7Fa4TqRgBcFHEEKD1j+woHVTlle2xfT3krZwShLHoVmVwr9XNerV/7Ehgh/ g6eCUzLqmBdbFbduj+Gj9WkiNEOHsoFfWPqdo74hIrtlfs6afueN8SEhqHrVs250ptvQ u5ufzsF4C38cdMm0Ya3PwNxHrqbvlRZwz9KuymXXOPr/wux3u3qQtdlBfoYappKssOo9 AUiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=yHMwuAvLK9gUw6iIFm/sm9hze3x1TscAYm1qCihsuYo=; b=SBpSRof/jZwA064btSR7QtOltX97W/Zf6bfoifjWmN+MX0v2VUr3Ez3xD6oSJUGD1h ulVf9Whh2BNd+bcguRxMNfGHMp088Uu7pn8J/yJ7sTMi74eOmx9Oo2Anas/BhQDDV3Ja Je00M709edFuphg9woxNc4laZAHrioj7A/zD971+e8bJ3jCjuCa1LzIsm3ES66It9z3v zblQFvsGdPOhRCOhtbnhVvPedO43J/epFJsWcHrvY07iw3uaGt0pxxxTCmJ4AEFD6z3l Tl8bIbeJ0UrJJE37ZLTXKdRTZ6Ec2/2ufDJ1mQtspemykRSvgekOFHoDq2HtDaNP/lEN UbvA== X-Gm-Message-State: APjAAAUTy0nuLMr6iYZDErxPbb7VlADTmRVMCgTG4bSpUaIT6ELCFUr+ 1CZQTzwwjxb9EpUjFS92PCfdIxYTEwY91Q== X-Google-Smtp-Source: APXvYqx1lCbGi7tDLy1XHPfdM9iY977TYAUmK8ZRMJpJykOApdeZpw6qguYXhBwBVEHjSN6UYUskUw== X-Received: by 2002:a37:63d2:: with SMTP id x201mr896299qkb.30.1578620437475; Thu, 09 Jan 2020 17:40:37 -0800 (PST) Received: from [169.254.100.189] (modemcable016.82-162-184.mc.videotron.ca. [184.162.82.16]) by smtp.gmail.com with ESMTPSA id h34sm236186qtc.62.2020.01.09.17.40.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 17:40:36 -0800 (PST) From: "Marc Blanchet" To: "Eric Rescorla" Cc: "Joe Touch" , "Richard Barnes" , "IAB Chair" , "IAB IAB" , "IETF discussion list" , architecture-discuss@ietf.org Date: Thu, 09 Jan 2020 20:40:35 -0500 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <2377bee131af6f5a6f5a1104bc25e056@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 01:40:41 -0000 On 9 Jan 2020, at 18:59, Eric Rescorla wrote: > On Thu, Jan 9, 2020 at 2:40 PM Joe Touch wrote: > >> On 2020-01-09 10:46, Eric Rescorla wrote: >> >> I concur with Richard here. The IETF is most successful when we get >> input from people who are directly involved in the technologies that >> we are standardizing, but of course that very often means that they >> are working on those technologies for their employer. And indeed >> one of the criteria we often use to ask whether someone is a good >> fit for leadership is whether they have this kind of non-standards >> "day job" expertise. >> >> >> >> That, IMO, is why we encourage their participation in WG discussions and >> on lists. >> >> But it is dangerous to have those parties directly involved in decision >> making. The actual and potential COI (esp. perceived potential COI) >> undermine the decisions made - even when those decisions are otherwise >> reasonable. >> >> I.e., think of this as protecting the value of IAB decisions (and, as Ben >> noted, there are many, esp. during appeals, that are of a substantive >> nature that COI benefits). >> > > And yet we routinely allow have WG chairs and ADs who are deeply involved > (and whose employers are deeply involved) in the technologies that are > being standardized. pretty relevant point, and very common. Marc. > > -Ekr > > >> Joe >> >> >> > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Thu Jan 9 20:08:09 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7270412080A for ; Thu, 9 Jan 2020 20:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 ZimuUXfL0hSi for ; Thu, 9 Jan 2020 20:08:03 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0: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 652761200E7 for ; Thu, 9 Jan 2020 20:08:03 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id 13so732755oij.13 for ; Thu, 09 Jan 2020 20:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D0yNDGC0FOtqI5NIyW//gatJJ++WJ1L735HmcHWKP98=; b=LO7lIbJ4opm6Z9Cb0Iv/0WH60HN9yyrftH98inN7wCMe5yZzl1iBICfhkkEan79DVk 9Y5aJY1/X9ghW8Mbbj0vFhNXyd+s1pK3CKnOxrHidIDK9F8XYCVZgOuV6YAfXsvp0FC1 hW8SLOR3N82gW9wYQ8bbESL8pia4onJwRzH1y2lSarWpx3nIRdv8AXMJFwJSUtSVvFyj RjbU39iCpAEeUBtsGj6sA9huSLBUZSYtyQCLGnddhpfytljeh1I5FW/0Frasabq18LAi y6rBqwAg1b4d+i3Lc6ZWO4xVyjibtPJrdcwEt18oP+ROJIiQfxznSSgEd6L3Neh8bMu4 2mJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D0yNDGC0FOtqI5NIyW//gatJJ++WJ1L735HmcHWKP98=; b=Ja5yfN+yadrmroRnXfkAt4Ml1aCnzISYI0HaM+p2p/pQU8WQ8VAdbsxluNCCk1Dp3Y Pp/AfPAuk6f5vAHzW+R6kt9qTMlvrToaVrnC8biENI/6x67KgWEjq5CCPcV9rHhqqx+c yS99ffSyJRVGsnqLQi2aZopBddbMUUlBnTXuNp0j0/w9+VMuDo4DRM2ohAnkjfTe/gGZ eZ4ZrW4GxfdloFO85srgcOaRYvEZx3GmZnDsqL1eqDoq1/7UNkleWuOfSow8lsUB9swe b6mE/2GIvrTYhcKZFxrfpTeHPVTZK1COT8Gk/5gQ/0CCyTNkXqDODSJJ7PCEuC7O5RL7 d2Gg== X-Gm-Message-State: APjAAAWtpGtAJQQGt94mi1hMcO7qeE6kxHHyRlWsJpMVKxf+b62nGWor YLdrdZIxCYP4odB6cOPwxDQ7AgjDxTVUn+xhPAo= X-Google-Smtp-Source: APXvYqztaC9SQljOzWJXDSv+ngE0+9IkuIAfQ/F0FKK/qS4fRTzq0NkJsZ4MVNWyZxe89z3r33IgMGyvmZGKfxJV2lg= X-Received: by 2002:aca:f354:: with SMTP id r81mr680079oih.90.1578629282239; Thu, 09 Jan 2020 20:08:02 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Thu, 9 Jan 2020 20:08:01 -0800 (PST) In-Reply-To: References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> <265A560E-F07F-4CB8-8D5F-6077D1419CE5@comcast.net> <20200109094537.GY8801@faui48f.informatik.uni-erlangen.de> From: Guntur Wiseno Putra Date: Fri, 10 Jan 2020 11:08:01 +0700 Message-ID: To: Toerless Eckert Cc: John Day , Andrew Campling , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="00000000000099987c059bc1456e" Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 04:08:07 -0000 --00000000000099987c059bc1456e Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, Adding what I mentioned in the previous message (in trying to learn on "Networks conditions"): "diversity/heterogeneity" seems contradictory to "centralization" when the latter is about "uniformity"...? Of "blobs" (1) there are moments of active elements or primitives, a corresponding force of attractions, of fusions, of inflection, and of deformations: Does "centralization" in Internet infrastructure not represent those moments...? Thinking also about disciplinary interactions (thus, moments of disciplines) having a moment of complexity and flexibility: does such an analogue works for "networks conditions" to say that moments of diversities have also moments of uniformities...? (1) The quotation is fully presented below (it is how Brian Massumi define what Greg Lynn speaks as "blob"): "active elements or 'primitives' which combine to generate their own space. Each blob is differentiated. It is assigned (by the programmer) a circumference, a mass, and a corresponding force of atttaction. The force of attraction defines a field of influence outside the perimeter of the blob, and that field is in turn differentiated into zones. Closest to the perimeter is a zone of fusion. Any blob entering it will combine with the first blob to form a larger blob. Beyond the fusion zone is a zone of inflection, the area within which the atttactive force of the blob will alter the shape, and therefore the field of influence, of a neighbouring blob. Put a number of blob together, and their differential influenced on each other produce unpredictable reciprocal deformations. (Massumi 1995) Regard, Guntur Wiseno Putra Pada Jumat, 10 Januari 2020, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > (It seems contradictory yet happen: "centralization" to > "diversity/heterogeneity" as a network condition...?) > > Toward the problematic issues on "centralization" on Internet practice, > such a way to arrive there is about (re)considering "network conditions": > here we meet with diversity/heterogeneity as the Internet draft mentioned > "Centralized Architecture on Internet Infrastructure". What does it mean by > "centralization" thus...? --how does it work/mean/value for > diversity/heterogeneity...? > > For diversity/heterogeneity as a network condition we may refer to "liquid > architecture" (1) of which other things with nuances deserve to mention: > "bloobs"(2), "plasm"(3), "plasmatic"(4) and "plasmatics"(5). Thus we are > also saying about a spatial analysis of a network condition as it is about > cyberspace, about Internet --and we may plan things strategically about the > space... > > - we may think of Internet as one among other collective matters yet it is > also one among other personal matters: those matters are maintaining > dialogues. Is it not so...in considering Internet sustainability? --at > least we find that Internet has a significance for planning societies of > nations initiated by the United Nations (see "Leveraging Tech...") > > > (1) "...Liquid architecture makes liquid cities, cities that change at the > shift of a value, where visitors with different backgrounds sec different > landmarks, where neighborhoods vary with ideas held in common, and evolve > as the ideas mature or dissolve". (Novak, Marcos, "Liquid Architecture in > Cyberspace" (1991) > https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf) > > (2) "bloobs" refers to "active element or primitive generatiing their own > spaces... (with possibilities of) unpredictable reciprocal deformations". > (Massumi, Brian, "Interface and Active Space", in Cheetam, M. A, "Kant, > Art and Art History: Moments of Disciplines, Cambridge University Press, > Cambridge et all., 2001, p. 25; Cheetam refered Massumi's "Interface and > Active Space: Human-Machine Design" available at http://www > anu.edu/HRC/first_and_last/links/massumi_works.htm) > > (3) plasm refers to "a mould of matrix in which something is cast or > formed"; "plasma" refers to "living matter of a cell" and to "liquid part > of blood in which corpuscles float"; then, plasmatic refers to what is > related with "plasm" or "plasma". "Plasmatic" may be applied to refer to > "disciplinary interactions ...(having) ...multidimensional and shifting > cultural intensities, and that the specific contours of this matric are > inflected historically by the forces of which it is comprised ... (--) ...a > model of complexity and flexibility allowing us to understand how an active > element in the system... can shape and be shaped by disciplines. (Cheetam, > M. A, "Kant, Art and Art History: Moments of Disciplines, Cambridge > University Press, Cambridge et all., 2001, p. 25) > > Regard, > Guntur Wiseno Putra > > Pada Kamis, 09 Januari 2020, Toerless Eckert menulis: > >> Good insights about the outcome of PICS. >> >> To clarify, i am primarily interested to see if we can do something >> to better support static network planning and protocol evolution. >> >> Something which is more a self-declaration than a (broken) conformance >> suite "verified" testing result. Something which always must be >> followed by appropriate testing (interop, deployment) depending >> on the goal. But something that can help to faster get to that >> step. Something to to help avoid horrenduously repetitive RFP questions >> by poor customers (does your IETF FOO protocol on your product support >> the optional BAR feature). >> >> One could think of another axis of information in our yang models, >> a subset of "implementation defined" behavior whose values can be >> statically exposed without access to a live system and hence be >> published and then used in netork planning for example >> (or auto-collection by a curious WG trying to progress some >> standard to full internet ;-)). >> >> I was interested in the type of information i remember to have seen >> in the 90th in PICS, i am horrified about the process i learn >> about it here in te thread ;-) >> >> Cheers >> Toerless >> >> On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote: >> > FWIW, there were also problems with keeping the test suites up-to-date >> with the errata. Bugs could be fixed in the standards and incorporated >> into implementations faster than the people developing the test suites >> could keep up (or wanted to). Of course the fixes were in the >> implementations before they were in the standards. And what was worse, when >> pointed out to them that their test-suited didn???t conform to the spec, >> they didn???t care. They still insisted they were right. >> > >> > For some standards, it was possible to develop utilities that did a >> specific function and used part of a standard to do that function but >> didn???t need the rest of the standard. But the people running the test >> suites couldn???t deal with it. If it didn???t implement the entire >> protocol, it didn???t pass. The utility couldn???t cause any of the rest of >> the protocol to be generated. It conformed to the standard for everything >> it did. They were using the standard as it had been intended. >> > >> > But the testers were effectively bean-counters and totally stupid. >> > >> > Conformance fell under the ANSI committee I chaired and I remember >> writing them (some military base in Arizona whose name I have thankfully >> forgotten) nasty letters telling them to get their act together or get out. >> They were doing more harm than good. Wish we had known about the IS-IS >> issues as well to add to the list. >> > >> > One needs some way to test implementations before trying them live. >> But one has to treat them (and it has to be instilled in the testers) that >> the purpose is to help: obey Postel???s rule, find problems, and then >> determine whether it is the tests, the ???standard??? or the new >> implementation that is at fault. And above all if it isn???t externally >> visible, it is none of the tester???s business. Even if there is ???formal >> specification???, one can???t be sure that a bug is in the prose, the >> formal spec, the tests, or the implementation. They are all suspect. (Often >> formal specifications are more complex than the code. And we know what that >> means!) >> > >> > Years before the standards issues arose, I did a survey of testing >> methods for our own use. I expected to find that two or three were pretty >> effective, pick one or two. What I found were 20 or 25 that were all >> pretty effective and the advice was pick 2 or 3 and it didn???t really >> matter which ones as long as they were different. (Not the result I was >> looking for.) ;-) >> > >> > Take care, >> > John >> > >> > > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote: >> > > >> > > >> > >> Yes, i was thinking of ISO PICS. But i lost track of those ISO >> standards >> > >> since the 90th. I guess i would have to see a successfull and still >> > >> currently used standard and how its PICS do or do not help. Just >> > >> not alot of those ISO specs left in wide deployments, right. >> > >> X.500 ? Maybe i can get more insight from the security community. >> > > >> > > >> > > You need not go that far. Remember IS-IS? Still thriving. >> > > >> > > And yes, my experience with PICs and test suites comes from that. >> > > >> > > >> > >>> What it does do is to encourage people to write ???conformance test >> suites???. These then get sold to unsuspecting customers and end-users. >> Unfortunately, the quality of such suites is so low that you spend way, >> way, way more time debugging the test suite and you never find bugs in your >> implementation. >> > >> >> > >> This is just the worst possible outcome, and i am sure one can learn >> > >> from those bad experiences. Just think of taking a more organized >> > >> step towards being able to collect protocol implementation >> information >> > >> from the industry. Right now every WG who wants to raise the level of >> > >> an IETF protocol, e.g.: to(wards) full standard is coming up with a >> > >> questionaire in an ad-hoc fashion (we're just doing this in Multicast >> > >> for IGMP/MLD). >> > > >> > > >> > > You can do that if you like, but the one proven, effective method is >> interoperability testing. >> > > >> > > Running code trumps questionaires, conformance test suites, theory, >> and mandate. >> > > >> > > >> > >> My point was: If the only murphy you have is competitive pressure, >> it works not >> > >> it there is only limited competition, such as a total of maybe no >> > >> more than 3 competing national infrastructures. >> > > >> > > >> > > And countries that stifle competition inflict vendor lock on >> themselves. >> > > >> > > >> > >> See above. The best i think we (IETF) can do is to educate better >> about >> > >> this by appropriate documents. Certainly some additional protocol >> work >> > >> will result from that. I for once had simple slides 10 years ago how >> to fixup >> > >> non-dual plane networks to be dual-plane. And maybe we can come up >> with >> > >> questionaires to get better numbers from actual deployments (the >> > >> PICS discussion). >> > > >> > > >> > > The IETF???s job is not education. It does not work as the education >> is not requested >> > > and not welcome. The IETF???s job is standards and it needs to focus >> on that. >> > > >> > > >> > >> Figuring out ideas for a complete ecosystem of monetization and >> > >> deployment between competition and regulation is better left for >> > >> an ongoing bar-bof with emphasis on bar. >> > > >> > > >> > > I concur. Let???s stop fooling ourselves into thinking that anything >> that the IAB/IETF writes has any impact >> > > on regulation or economics. >> > > >> > > >> > >> Actually one of the interesting conclusions was that dual-plane in >> > >> many cases is really free but deployments often just don't fully >> > >> utilize it. >> > > >> > > >> > > I???d agree that it???s close to free. If you accept that you need a >> dual-plane approach for resiliency, then >> > > adding a second vendor to the mix is relatively easy. There???s >> additional cost because of decreased >> > > purchasing volume. There???s additional costs in management and >> operations. >> > > >> > > However, as compared to the costs of an unnecessary outage, it???s >> still trivial. >> > > >> > > Tony >> > > >> > > _______________________________________________ >> > > Architecture-discuss mailing list >> > > Architecture-discuss@ietf.org >> > > https://www.ietf.org/mailman/listinfo/architecture-discuss >> >> -- >> --- >> tte@cs.fau.de >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > --00000000000099987c059bc1456e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

Adding what I mentione= d in the previous message (in trying to learn on "Networks conditions&= quot;):=C2=A0

"diversity/heterogeneity&quo= t; seems contradictory to "centralization" when the latter is abo= ut "uniformity"...?

Of "blobs&quo= t; (1) there are moments of active elements or primitives, a corresponding = force of attractions, of fusions, of inflection, and of deformations: Does = "centralization" in Internet infrastructure not represent those m= oments...?=C2=A0

Thinking also about disciplinar= y interactions (thus, moments of disciplines) having a moment of complexity= and flexibility: does such an analogue works for "networks conditions= " to say that moments of diversities have also moments of uniformities= ...?


(1) The quotation is fully = presented below (it is how Brian Massumi define what Greg Lynn speaks as &q= uot;blob"):
"active elements or 'primitives' w= hich combine to generate their own space. Each blob is differentiated. It i= s assigned (by the programmer) a circumference, a mass, and a corresponding= force of atttaction. The force of attraction defines a field of influence = outside the perimeter of the blob, and that field is in turn differentiated= into zones. Closest to the perimeter is a zone of fusion. Any blob enterin= g it will combine with the first blob to form a larger blob. Beyond the fus= ion zone is a zone of inflection, the area within which the atttactive forc= e of the blob will alter the shape, and therefore the field of influence, o= f a neighbouring blob. Put a number of blob together, and their differentia= l influenced on each other produce unpredictable reciprocal deformations. (= Massumi 1995)


Regard,
Guntur Wiseno Putra

Pada Jumat, 10 Januari 2020, Guntur Wiseno Pu= tra <gsenopu@gmail.com> menu= lis:
Dear architecture-discuss,

<= /div>
(It seems contradictory yet happen: "centralization" to= "diversity/heterogeneity" as a network condition...?)
=
Toward the problematic issues on "centralization" = on Internet practice, such a way to arrive there is about (re)considering &= quot;network conditions": here we meet with diversity/heterogeneity as= the Internet draft mentioned "Centralized Architecture on Internet In= frastructure". What does it mean by "centralization" thus...= ? --how does it work/mean/value for diversity/heterogeneity...?
<= br>
For diversity/heterogeneity as a network condition we may ref= er to "liquid architecture" (1) of which other things with nuance= s deserve to mention: "bloobs"(2), "plasm"(3), "pl= asmatic"(4) and "plasmatics"(5). Thus we are also =C2=A0sayi= ng about a spatial analysis of a network condition as it is about cyberspac= e, about Internet --and we may plan things strategically about the space...=

- we may think of Internet as one among other col= lective matters yet it is also one among other personal matters: =C2=A0thos= e matters are maintaining dialogues. Is it not so...in considering Internet= sustainability? --at least we find that Internet has a significance for pl= anning societies of nations initiated by the United Nations (see "Leve= raging Tech...")


(1) "...Liquid architecture makes liquid cities, cities that change a= t the shift of a value, where visitors with different backgrounds sec diffe= rent landmarks, where neighborhoods vary with ideas held in common, and evo= lve as the ideas mature or dissolve". (Novak, Marcos, "Liquid Arc= hitecture in Cyberspace" (1991) =C2=A0=C2=A0

(2) "bloobs= " refers to "active element or primitive generatiing their own sp= aces... (with possibilities of) unpredictable reciprocal deformations"= .=C2=A0
(Massumi, Brian, "Interface and Active Space", = =C2=A0in Cheetam, M. A, "Kant, Art and Art History: Moments of Discipl= ines, Cambridge University Press, Cambridge et all., 2001, p. 25; Cheetam r= efered Massumi's "Interface and Active Space: Human-Machine Design= " available at=C2=A0http://www=C2= =A0anu.edu/HRC/first_and_last/links/massumi_works.htm)
=

(3) plasm refers to "a mould of matrix in which so= mething is cast or formed"; "plasma" refers to "living = matter of a cell" and to "liquid part of blood in which corpuscle= s float"; then, plasmatic refers to what is related with "plasm&q= uot; or "plasma". "Plasmatic" may be applied to refer t= o "disciplinary interactions ...(having) ...multidimensional and shift= ing cultural intensities, and that the specific contours of this matric are= inflected historically by the forces of which it is comprised ... (--) ...= a model of complexity and flexibility allowing us to understand how an acti= ve element in the system... can shape and be shaped by disciplines. (Cheeta= m, M. A, "Kant, Art and Art History: Moments of Disciplines, Cambridge= University Press, Cambridge et all., 2001, p. 25)

Regard,
Guntur Wiseno Putra

Pada Kamis, 09 Januari 2020, = Toerless Eckert <tte@= cs.fau.de> menulis:
Good insights = about the outcome of PICS.

To clarify, i am primarily interested to see if we can do something
to better support static network planning and protocol evolution.

Something which is more a self-declaration than a (broken) conformance
suite "verified" testing result. Something which always must be followed by appropriate testing (interop, deployment) depending
on the goal. But something that can help to faster get to that
step. Something to to help avoid horrenduously repetitive RFP questions
by poor customers (does your IETF FOO protocol on your product support
the optional BAR feature).

One could think of another axis of information in our yang models,
a subset of "implementation defined" behavior whose values can be=
statically exposed without access to a live system and hence be
published and then used in netork planning for example
(or auto-collection by a curious WG trying to progress some
standard to full internet ;-)).

I was interested in the type of information i remember to have seen
in the 90th in PICS, i am horrified about the process i learn
about it here in te thread ;-)

Cheers
=C2=A0 =C2=A0 Toerless

On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote:
> FWIW, there were also problems with keeping the test suites up-to-date= with the errata.=C2=A0 Bugs could be fixed in the standards and incorporat= ed into implementations faster than the people developing the test suites c= ould keep up (or wanted to). Of course the fixes were in the implementation= s before they were in the standards. And what was worse, when pointed out t= o them that their test-suited didn???t conform to the spec, they didn???t c= are. They still insisted they were right.
>
> For some standards, it was possible to develop utilities that did a sp= ecific function and used part of a standard to do that function but didn???= t need the rest of the standard. But the people running the test suites cou= ldn???t deal with it. If it didn???t implement the entire protocol, it didn= ???t pass. The utility couldn???t cause any of the rest of the protocol to = be generated. It conformed to the standard for everything it did. They were= using the standard as it had been intended.
>
> But the testers were effectively bean-counters and totally stupid.
>
> Conformance fell under the ANSI committee I chaired and I remember wri= ting them (some military base in Arizona whose name I have thankfully forgo= tten) nasty letters telling them to get their act together or get out. They= were doing more harm than good. Wish we had known about the IS-IS issues a= s well to add to the list.
>
> One needs some way to test implementations before trying them live.=C2= =A0 But one has to treat them (and it has to be instilled in the testers) t= hat the purpose is to help:=C2=A0 obey Postel???s rule, find problems, and = then determine whether it is the tests, the ???standard??? or the new imple= mentation that is at fault. And above all if it isn???t externally visible,= it is none of the tester???s business.=C2=A0 Even if there is ???formal sp= ecification???, one can???t be sure that a bug is in the prose, the formal = spec, the tests, or the implementation. They are all suspect. (Often formal= specifications are more complex than the code. And we know what that means= !)
>
> Years before the standards issues arose, I did a survey of testing met= hods for our own use. I expected to find that two or three were pretty effe= ctive, pick one or two.=C2=A0 What I found were 20 or 25 that were all pret= ty effective and the advice was pick 2 or 3 and it didn???t really matter w= hich ones as long as they were different. (Not the result I was looking for= .)=C2=A0 ;-)
>
> Take care,
> John
>
> > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote:
> >
> >
> >> Yes, i was thinking of ISO PICS. But i lost track of those IS= O standards
> >> since the 90th. I guess i would have to see a successfull and= still
> >> currently used standard and how its PICS do or do not help. J= ust
> >> not alot of those ISO specs left in wide deployments, right.<= br> > >> X.500 ? Maybe i can get more insight from the security commun= ity.
> >
> >
> > You need not go that far.=C2=A0 Remember IS-IS?=C2=A0 Still thriv= ing.=C2=A0
> >
> > And yes, my experience with PICs and test suites comes from that.=
> >
> >
> >>> What it does do is to encourage people to write ???confor= mance test suites???.=C2=A0 These then get sold to unsuspecting customers a= nd end-users.=C2=A0 Unfortunately, the quality of such suites is so low tha= t you spend way, way, way more time debugging the test suite and you never = find bugs in your implementation.
> >>
> >> This is just the worst possible outcome, and i am sure one ca= n learn
> >> from those bad experiences. Just think of taking a more organ= ized
> >> step towards being able to collect protocol implementation in= formation
> >> from the industry. Right now every WG who wants to raise the = level of
> >> an IETF protocol, e.g.: to(wards) full standard is coming up = with a
> >> questionaire in an ad-hoc fashion (we're just doing this = in Multicast
> >> for IGMP/MLD).
> >
> >
> > You can do that if you like, but the one proven, effective method= is interoperability testing.
> >
> > Running code trumps questionaires, conformance test suites, theor= y, and mandate.
> >
> >
> >> My point was: If the only murphy you have is competitive pres= sure, it works not
> >> it there is only limited competition, such as a total of mayb= e no
> >> more than 3 competing national infrastructures.
> >
> >
> > And countries that stifle competition inflict vendor lock on them= selves.
> >
> >
> >> See above. The best i think we (IETF) can do is to educate be= tter about
> >> this by appropriate documents. Certainly some additional prot= ocol work
> >> will result from that. I for once had simple slides 10 years = ago how to fixup
> >> non-dual plane networks to be dual-plane. And maybe we can co= me up with
> >> questionaires to get better numbers from actual deployments (= the
> >> PICS discussion).
> >
> >
> > The IETF???s job is not education. It does not work as the educat= ion is not requested
> > and not welcome. The IETF???s job is standards and it needs to fo= cus on that.
> >
> >
> >> Figuring out ideas for a complete ecosystem of monetization a= nd
> >> deployment between competition and regulation is better left = for
> >> an ongoing bar-bof with emphasis on bar.
> >
> >
> > I concur. Let???s stop fooling ourselves into thinking that anyth= ing that the IAB/IETF writes has any impact
> > on regulation or economics.
> >
> >
> >> Actually one of the interesting conclusions was that dual-pla= ne in
> >> many cases is really free but deployments often just don'= t fully
> >> utilize it.
> >
> >
> > I???d agree that it???s close to free.=C2=A0 If you accept that y= ou need a dual-plane approach for resiliency, then
> > adding a second vendor to the mix is relatively easy. There???s a= dditional cost because of decreased
> > purchasing volume. There???s additional costs in management and o= perations.
> >
> > However, as compared to the costs of an unnecessary outage, it???= s still trivial.
> >
> > Tony
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architec= ture-discuss

--
---
tte@cs.fau.de

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--00000000000099987c059bc1456e-- From nobody Thu Jan 9 23:04:32 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6A120142; Thu, 9 Jan 2020 23:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_SIZE_LARGE=0.001, 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OJMraudM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=W0b1mCcT 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 LTQ2kwUcq589; Thu, 9 Jan 2020 23:04:11 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2EC120112; Thu, 9 Jan 2020 23:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27189; q=dns/txt; s=iport; t=1578639851; x=1579849451; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UbYYqBK1B0TJLbvx9O0GFMFKDvltgMmhBc+fJXLefK4=; b=OJMraudMx0H9rE0VQXuY0jRAvtU0rhMHv3hSdaPfGKnZMH+znv41QHbH 7Mp8ihT6AtMDcj11KfFjEhlAjnv9Gz/B7DPgFhOPwl/4duOViYra2BiOD Jo1jPaSeBndeQJob8YAbOusdHN0zlWdTEtquKHG/XHbonM2ysAIYQl6MB 4=; IronPort-PHdr: =?us-ascii?q?9a23=3A1ntIyBY88LKJvWVxX1C6OHf/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20Q+bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavnayEzBuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8CACNIRhe/4YNJK1lHQEBAQkBEQU?= =?us-ascii?q?FAYF7gVQpJwVsD0kgBAsqhAmDRgOLAow/iUuEYoFCgRADVAkBAQEMAQEYAQw?= =?us-ascii?q?IAgEBg3tFAheBWSQ4EwIDDQEBBAEBAQIBBQRthTcMhV8CAQMBARARHQEBKgI?= =?us-ascii?q?DBQMBDwIBCBItAwICAh8GCxQDDgIEDgUUDoI5SwGBfU0DLgEOoBgCgTiIYXW?= =?us-ascii?q?BMoJ+AQEFhRUNC4IMAwaBNowZGoFBP4ERJyCBTlAuPoIbSQEBAoEpHEmCYzK?= =?us-ascii?q?CLI00UYINOYVXmCMxRAqCN4c7ikyEJhQHgkeHf5AilzKCIIwJg3ACBAIEBQI?= =?us-ascii?q?OAQEFgWkigVhwFTsqAYJBUBgNkk8MF4NQhRSFP3SBKJAsAQE?= X-IronPort-AV: E=Sophos;i="5.69,415,1571702400"; d="scan'208,217";a="401204104" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Jan 2020 07:03:46 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 00A73kdS009639 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Jan 2020 07:03:46 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 Jan 2020 01:03:45 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 Jan 2020 01:03:45 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 10 Jan 2020 01:03:45 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hzjdG6y8YEIQq/CZbg0hUxnhfYuwyshXlCTf6ZrGUmi7caGhVfboFhkd32f+EK6LCrpPCQCo5FrlGNr4wwGXN6H+XTKRvrmz7VzuVnElnEJ3dw3zrFSKzV4z+xnh4GqiCpzQHQD/6VkE7L4UaMCQTGA64DqeTkeOeJ27j8+4meiVTkJn2zQfqK2U3VGrJB1ALGePICEs6ka1lnNM4QLIv37JJlWlZ2tEYFJfCUHU7r0stdvrr6ulozsRsq8Zlo93C8P4qPmNNr48sVe47r8zLCTsd+UNeTKGq7DV0FyW1l2CGWEv2tlDW0aYgQkKUDwRrGkIKPkaCW+R45QEZPaflw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UbYYqBK1B0TJLbvx9O0GFMFKDvltgMmhBc+fJXLefK4=; b=G7DAXaTzrtVyFzyiymnbbsQgydWdaRS43swmNe/s/DqF9+8gwkRvGn/MF6mgzuszYGhGIhXzr5PaexN0dNPF7KjIbUjrrhhHKZnBefxvmkBplBH3g4rCoL5UQMLW+Yjo16wxGBZziksh+E4jUHpdJH5mSBP9CsB6AlLbZIs5F4rSatkeEz4VQGJb77BsUC5WQU+T1MXpElINmZFcbW9pZR+5LlQfv0a8kX9JtNVtgDC8vZDcLD56oflcZRCx1kQUO2DJ4RXMatt39ivL6ZOhJo0rpHdoOi+KV3QCprJJPdU6nO5hKLOVt+miVSWgsoQG/m6/1tq62tqMvWUvX9Al8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UbYYqBK1B0TJLbvx9O0GFMFKDvltgMmhBc+fJXLefK4=; b=W0b1mCcTC9W74qImY0m4DJ19YA4FGBZjzE95195gQWCm4Z7gmhyEcm7kdrSUJqGZ6R7OPaPA2f1T10sUDS9/h3KbH1BqDb00lrdQa+td6fEpliNKEazcEcQlhGgOugszLnAKQgpAn3JHmHw7+wIkfwrOje91G7nc9N9KX3uXlEg= Received: from DM6PR11MB3995.namprd11.prod.outlook.com (10.255.61.204) by DM6PR11MB4041.namprd11.prod.outlook.com (20.176.125.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Fri, 10 Jan 2020 07:03:44 +0000 Received: from DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5]) by DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5%7]) with mapi id 15.20.2623.010; Fri, 10 Jan 2020 07:03:44 +0000 From: "Eliot Lear (elear)" To: Bernard Aboba CC: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmHmJFkBEFdAU6GRM36N32yCafijtKAgABlBgCAAIdkgA== Date: Fri, 10 Jan 2020 07:03:44 +0000 Message-ID: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:e841:a75e:18e1:8e4c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef708c5e-7028-444c-dc74-08d7959b3b54 x-ms-traffictypediagnostic: DM6PR11MB4041: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(136003)(39860400002)(366004)(199004)(189003)(52314003)(8676002)(186003)(33656002)(6486002)(6512007)(5660300002)(71200400001)(6506007)(53546011)(2616005)(2906002)(478600001)(4326008)(66556008)(6916009)(64756008)(66574012)(66476007)(66946007)(66446008)(76116006)(8936002)(91956017)(81166006)(54906003)(966005)(81156014)(36756003)(316002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4041; H:DM6PR11MB3995.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iWfIXmMZRSMPHo1cRSEmCfzX1rkUt7pZ8O1onHZLW2Fzsem+EnNAX1JRTPYFRt2YdHxIhQa4QPUsVQxA1suTJilRlLh7Y7FM8CIeRpVABxEQN1OhCb5GZw9vhgOytv1p1r8pr515tZRU8J4tGibfJHl4T8xZu5DCYwCxEoMtNCJ388pWMQT2C1TgHwxWmSGdpsbrzrYRXzaL4ZVNSRj2DbAbv3sDPsTyb8dXQIJPOWNWn00igw2f2wTPQFhlLBqA7qwJn/8fyTjIsAqHVRqaoalHIswDFeaVEbZrnCyF0aRojpfLDTelE/K01uQZWS70ZS8ksar2VXP39pGpbjovo/NljEWbJIJKHq0nk+zj5XbDPXE20nmSYP0xPvq+pxSI5p9A5wIoa2FskSItbtAyUXkQbE0WqNM00jaSfRJksrQZel/VAqoIii7KfNO3v0RVUVjORUzJ71b2kLeWkyR/0xW6c+4X1Qeeoq1X2lY9Lp/MryZAO5/Pq+o/Z3zo5luoHyivuO6zVEODiZdkUvqxwVV55qLjr7hrC2Vx8bhi/To= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_E56C960BEFF447EAAB62C441B4FD3354ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ef708c5e-7028-444c-dc74-08d7959b3b54 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2020 07:03:44.3011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Qb/k6wqAU8NMcJaPMYOCr6WavfA98OP0ZwiIoa7hajzJVmT0Fl/dGsWYzWludqXt X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4041 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 07:04:17 -0000 --_000_E56C960BEFF447EAAB62C441B4FD3354ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIFJpY2hhcmQsIEJlcm5hcmQsIGFuZCBFS1IuICBXaGVyZSBpbmRpdmlkdWFs cyBvbiB0aGUgSUVTRyBoYXZlIGdyZWF0IHBvd2VyLCB0aGlzIGdlbmVyYWxseSBjYW5ub3QgYmUg c2FpZCBhYm91dCBJQUIgbWVtYmVycywgIHdobyBsYXJnZWx5IG1ha2UgZGVjaXNpb25zIG9uIHJv dWdoIGNvbnNlbnN1cy4gICBUaGUgYXBwcm9wcmlhdGUgc2FmZWd1YXJkIGFnYWluc3QgQ09JIGlu IHRoZSBJQUIgaXMgdG8gaGF2ZSBhIGRpdmVyc2UgSUFCLCBhbmQgdGhlIE5PTUNPTSBhbmQgdGhl IElTT0MgQm9UIHNob3VsZCBzZWUgdG8gaXQgdGhhdCB0aGlzIGlzIHRoZSBjYXNlIGFueXdheSwg c28gYXMgdG8gaGVscCB0aGUgY29tbXVuaXR5IGJlIHByZXBhcmVkIGZvciBUaGUgTmV4dCAodW5m b3Jlc2VlbikgUHJvYmxlbS4NCg0KRWxpb3QNCg0KT24gOSBKYW4gMjAyMCwgYXQgMjM6NTksIEJl cm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2Jh QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpBZ3JlZSB3aXRoIFJpY2hhcmQgaGVyZS4gIE11Y2ggb2Yg dGhlIElBQiB3b3JrIGlzIHRlY2huaWNhbCBpbiBuYXR1cmUuICBUaGUgSUFCIHNob3VsZCB0aGVy ZWZvcmUgbm90IG5lZWQgYSBjb25mbGljdC1vZi1pbnRlcmVzdCBwb2xpY3kgYXMgaGVhdnkgd2Vp Z2h0IGFzIHRoYXQgcmVxdWlyZWQgdG8gYXNzdW1lIGEgc2VuaW9yIHJvbGUgd2l0aGluIGdvdmVy bm1lbnQsIGEgbGVnaXNsYXR1cmUgb3IgYSBnb3Zlcm5tZW50YWwgYWR2aXNvcnkgY29tbWl0dGVl Lg0KDQpIYXZpbmcgc2VydmVkIG9uIGEgZ292ZXJubWVudGFsIGFkdmlzb3J5IGNvbW1pdHRlZSBj b3ZlcmVkIGJ5IEZBQ0EsIGl0IHdvdWxkIGFwcGVhciB0byBtZSB0aGF0IHRoZSBwcm9wb3NlZCBJ QUIgQ09JIHBvbGljeSBpcyBwb3RlbnRpYWxseSBtb3JlIHN0cmluZ2VudC4gIEFzIGFuIGV4YW1w bGUsIHVuZGVyIEZBQ0EgSSB3YXMgbm90IHJlcXVpcmVkIHRvIHByb3ZpZGUgYSBjb21wbGV0ZSBm aW5hbmNpYWwgZGlzY2xvc3VyZS4gIFRoZSBndWlkYW5jZSB3YXMgdGhhdCBhIGRpc2Nsb3N1cmUg bmVlZCBvbmx5IGJlIG1hZGUgaW4gdGhlIGV2ZW50IG9mIGEgcG90ZW50aWFsIGNvbmZsaWN0LCBz aG91bGQgb25lIGFyaXNlLg0KDQpPbiBUaHUsIEphbiA5LCAyMDIwIGF0IDg6NTggQU0gUmljaGFy ZCBCYXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PiB3cm90ZToNCkkgd291bGQg cHJvcG9zZSB0aGUgSUFCIG5vdCBhZG9wdCB0aGlzIHBvbGljeSwgb3IgYXQgbGVhc3Qgc2NvcGUg aXQgd2F5IGRvd24uDQoNCk11Y2ggb2YgdGhlIElBQidzIHdvcmsgaXMgZm9jdXNlZCBvbiB0ZWNo bmljYWwgaXNzdWVzLCBhdCBhIGhpZ2ggZW5vdWdoIHN0cmF0ZWdpYyBsZXZlbCB0aGF0IHRoZSBp bXBhY3RzIHRvIHNwZWNpZmljIHBlb3BsZSBvciBjb21wYW5pZXMgYXJlIGhpZ2hseSBhdHRlbnVh dGVkLiAgSW4gdGhvc2UgZGlzY3Vzc2lvbnMsIHRoZSBJQUIncyB3b3JrIGJlbmVmaXRzIGZyb20g aGF2aW5nIGRpdmVyc2Ugb3BpbmlvbnMsIGluY2x1ZGluZyB0aGUgb3BpbmlvbnMgb2YgdGhvc2Ug d2hvIGhhdmUgc2tpbiBpbiB0aGUgZ2FtZS4gIFRyeWluZyB0byBpbnRyb2R1Y2Ugc29tZSBub3Rp b24gb2YgQ29JIGluIHRoaXMgY29udGV4dCB3b3VsZCBiZSBoYXJtZnVsIC0tIGJlY2F1c2UgdGhl cmUncyBubyBoYXJkIGNvbmZsaWN0LCBpdCB3aWxsIGluZXZpdGFibHkgYmUgdmFndWUsIGFuZCB0 aHVzIHByaW1hcmlseSBhIHRvb2wgZm9yIElBQiBtZW1iZXJzIHRvIHRyeSB0byBzaWxlbmNlIG9u ZSBhbm90aGVyIG9yIGEgY2F1c2UgZm9yIElBQiBtZW1iZXJzIHRvIHNlbGYtY2Vuc29yLg0KDQpX aGVyZSB0aGUgSUFCIGlzIGRpcmVjdGx5IGludm9sdmVkIGluIGZpbmFuY2Ugb3IgcGVyc29ubmVs IGRlY2lzaW9ucywgdGhlcmUgb2YgY291cnNlIHNob3VsZCBiZSBndWFyZHMgYWdhaW5zdCBzZWxm IGRlYWxpbmcuICBUaGF0J3Mgd2hlcmUgYW55IENvSSBwb2xpY3kgZm9yIHRoZSBJQUIgc2hvdWxk IHN0b3AuDQoNCi0tUmljaGFyZA0KDQpPbiBXZWQsIEphbiA4LCAyMDIwIGF0IDY6MTYgUE0gSUFC IENoYWlyIDxpYWItY2hhaXJAaWFiLm9yZzxtYWlsdG86aWFiLWNoYWlyQGlhYi5vcmc+PiB3cm90 ZToNCg0KRGVhciBDb2xsZWFndWVzLA0KDQpUaGUgSUFCIGlzIGNvbnNpZGVyaW5nIGFkb3B0aW9u IG9mIHRoZSBjb25mbGljdCBvZiBpbnRlcmVzdCBwb2xpY3kgYmVsb3cuICBJZiB5b3UgaGF2ZSBj b21tZW50cyBvbiB0aGlzIGRyYWZ0IHBvbGljeSwgcGxlYXNlIHNlbmQgdGhlbSB0byBpYWJAaWFi Lm9yZzxtYWlsdG86aWFiQGlhYi5vcmc+Lg0KDQpiZXN0IHJlZ2FyZHMsDQoNClRlZCBIYXJkaWUN CmZvciB0aGUgSUFCDQoNCg0KDQpJTlRFUk5FVCBBUkNISVRFQ1RVUkUgQk9BUkQgQ09ORkxJQ1Qg T0YgSU5URVJFU1QgUE9MSUNZDQoNClRoaXMgcG9saWN5IGNvdmVycyB0aGUgbm9tY29tLXNlbGVj dGVkIEludGVybmV0IEFyY2hpdGVjdHVyZSBCb2FyZCAoSUFCKSBtZW1iZXJzIGFuZCBleC1vZmZp Y2lvIG1lbWJlcnMgKGNvbGxlY3RpdmVseSwg4oCcQ292ZXJlZCBJbmRpdmlkdWFsc+KAnSkuIFRo aXMgcG9saWN5IGhhcyBubyBpbXBhY3Qgb24gYW55IG90aGVyIHBhcnRpY2lwYW50cyBpbiBJQUIg YWN0aXZpdGllcywgZm9yIGluc3RhbmNlIGxpYWlzb25zIHRvIGFuZCBmcm9tIHRoZSBJQUIgb3Ig SUFCIHByb2dyYW0gbWVtYmVycy4NCg0KSW4gY2Fycnlpbmcgb3V0IHRoZWlyIElBQiByb2xlLCBD b3ZlcmVkIEluZGl2aWR1YWxzIG11c3QgYWN0IGluIHRoZSBiZXN0IGludGVyZXN0IG9mIHRoZSBJ bnRlcm5ldCBjb21tdW5pdHkuIE9jY2FzaW9uYWxseSB0aGlzIGR1dHkgbWF5IGJl4oCUb3IgbWF5 IGFwcGVhciB0byBiZeKAlGluY29tcGF0aWJsZSBvciBpbiBjb25mbGljdCB3aXRoIGEgQ292ZXJl ZCBJbmRpdmlkdWFs4oCZcyBwZXJzb25hbCBpbnRlcmVzdHMgKGluY2x1ZGluZyBpbnRlcmVzdHMg b2YgdGhlaXIgZmFtaWx5IG1lbWJlcnMpLCBvciB0aGUgaW50ZXJlc3RzIG9mIGFuIG9yZ2FuaXph dGlvbiBvZiB3aGljaCB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsIGlzIGFuIGVtcGxveWVlLCBkaXJl Y3Rvciwgb3duZXIsIG9yIG90aGVyd2lzZSBoYXMgYnVzaW5lc3Mgb3IgZmluYW5jaWFsIGludGVy ZXN0LiBJZiBhIENvdmVyZWQgSW5kaXZpZHVhbCBoYXMgYSBjb25mbGljdCBvZiBpbnRlcmVzdCBm b3Igd2hhdGV2ZXIgcmVhc29uLCB0aGF0IGluZGl2aWR1YWwgbXVzdCBhdm9pZCBwYXJ0aWNpcGF0 aW5nIGluIHRoZSB3b3JrIG9mIHRoZSBJQUIgdGhhdCB0b3VjaGVzIG9uIHRoZSByZWxhdGVkIG1h dHRlci4NCg0KVGhlIElBQiBkb2VzIG5vdCBkaXJlY3RseSBkZWFsIHdpdGggbWF0dGVycyByZWxh dGluZyB0byBjb250cmFjdHMgb3IgZmluYW5jZS4gVGhlIElBQiBkb2VzLCBob3dldmVyLCBoYXZl IGEgcm9sZSBpbiBwZXJzb25uZWwgZGVjaXNpb25zLCBhbmQgaXRzIGRlY2lzaW9ucyBhbmQgb3V0 cHV0cyBoYXZlIGEgcG90ZW50aWFsIHRvIGluZGlyZWN0bHkgYWZmZWN0IGNvbnRyYWN0cyB3aXRo aW4gdGhlIElFVEYgc3lzdGVtLiBJQUIncyB0ZWNobmljYWwgZGVjaXNpb25zIGFuZCBvdXRwdXRz IGhhdmUgYWxzbyBhIHBvdGVudGlhbCB0byBpbXBhY3QgYm90aCB3b3JrIGVsc2V3aGVyZSBpbiB0 aGUgSUVURiBhbmQgYnVzaW5lc3NlcyB0aGF0IGVtcGxveSBvciBkZXZlbG9wIEludGVybmV0IHRl Y2hub2xvZ3kuDQoNCkNvdmVyZWQgSW5kaXZpZHVhbHMgc2hhbGwgbm90IHVzZSB0aGUgSUFC4oCZ cyByZXNvdXJjZXMgb3IgZGVjaXNpb25zIGFzIGEgbWVhbnMgZm9yIHBlcnNvbmFsIG9yIHRoaXJk LXBhcnR5IGdhaW4uDQoNCkRpc2Nsb3N1cmUgb2YgQWN0dWFsIG9yIFBvdGVudGlhbCBDb25mbGlj dHMNCg0KVGhlIElBQiByZXF1aXJlcyB0aGF0IGFsbCBDb3ZlcmVkIEluZGl2aWR1YWxzIGRpc2Ns b3NlIHRoZWlyIG1haW4gZW1wbG95bWVudCwgc3BvbnNvcnNoaXAsIGNvbnN1bHRpbmcgY3VzdG9t ZXIsIG9yIG90aGVyIHNvdXJjZXMgb2YgaW5jb21lIHdoZW4gam9pbmluZyB0aGUgSUFCIG9yIHdo ZW5ldmVyIHRoZXJlIGFyZSB1cGRhdGVzLg0KDQpJbiBhZGRpdGlvbiwgd2hlbiBhIHRvcGljIGlz IGRpc2N1c3NlZCBhdCB0aGUgSUFCLCB0aGUgQ292ZXJlZCBJbmRpdmlkdWFscyBhcmUgcmVxdWly ZWQgdG8gcHJvbXB0bHkgZGlzY2xvc2UgaWYgdGhhdCB0b3BpYyBjb25zdGl0dXRlcyBhIHBlcmNl aXZlZCBvciBwb3RlbnRpYWwgY29uZmxpY3Qgb2YgaW50ZXJlc3QuIE9uY2UgZGlzY2xvc2VkLCBD b3ZlcmVkIEluZGl2aWR1YWxzIG1heSByZWN1c2UgZnJvbSBwYXJ0aWNpcGF0aW9uIGluIGRpc2N1 c3Npb25zIG9yIGRlY2lzaW9ucyBhdCB0aGVpciBkaXNjcmV0aW9uLg0KDQpUaGUgc3BlY2lmaWMg Y29uZmxpY3RzIHRoYXQgbWF5IGNhdXNlIGEgcGVyY2VpdmVkIG9yIHBvdGVudGlhbCBjb25mbGlj dCBvZiBpbnRlcmVzdCBhcmUgbWF0dGVycyBmb3IgaW5kaXZpZHVhbCBhbmQgSUFCIGp1ZGdtZW50 LCBidXQgZ2VuZXJhbGx5IGNvbWUgaW4gdGhlIGZvbGxvd2luZyBmb3JtczoNCg0KICAqICAgQSBw ZXJzb25uZWwgZGVjaXNpb24gcmVsYXRlcyB0byB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsLCBhIGNv bGxlYWd1ZSB0aGF0IHRoZSBDb3ZlcmVkIEluZGl2aWR1YWwncyB3b3JrcyBjbG9zZWx5IHdpdGgs IG9yIGEgZmFtaWx5IG1lbWJlci4gRm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlzIHBvbGljeSwgYSAi cGVyc29uIHdvcmtpbmcgY2xvc2VseSB3aXRoIiBpcyBzb21lb25lIHdvcmtpbmcgaW4gdGhlIHNh bWUgdGVhbSBvciBwcm9qZWN0LCBvciBhIGRpcmVjdCBtYW5hZ2VyIG9yIGVtcGxveWVlIG9mIHRo ZSBDb3ZlcmVkIEluZGl2aWR1YWwuIEFuZCAiZmFtaWx5IiBtZWFucyBhIHNwb3VzZSwgZG9tZXN0 aWMgcGFydG5lciwgY2hpbGQsIHNpYmxpbmcsIHBhcmVudCwgc3RlcGNoaWxkLCBzdGVwcGFyZW50 LCBhbmQgbW90aGVyLSwgZmF0aGVyLSwgc29uLSwgZGF1Z2h0ZXItLCBicm90aGVyLSwgb3Igc2lz dGVyLWluLWxhdywgYW5kIGFueSBvdGhlciBwZXJzb24gbGl2aW5nIGluIHRoZSBzYW1lIGhvdXNl aG9sZCwgZXhjZXB0IHRlbmFudHMgYW5kIGhvdXNlaG9sZCBlbXBsb3llZXMuDQoNCiAgKiAgIEEg ZGVjaXNpb24gb3Igb3V0cHV0IGZyb20gdGhlIElBQiBpbXBhY3RzIGEgY29udHJhY3QgdGhhdCB0 aGUgSUVURiBlbnRlcnMgaW50byB3aXRoIGEgcGFydHksIGFuZCB0aGF0IHBhcnR5IHJlbGF0ZXMg dG8gdGhlIENvdmVyZWQgSW5kaXZpZHVhbCwgYSBjb2xsZWFndWUgdGhhdCB0aGUgQ292ZXJlZCBJ bmRpdmlkdWFsJ3Mgd29ya3MgY2xvc2VseSB3aXRoLCBvciBhIGZhbWlseSBtZW1iZXIuDQoNCiAg KiAgIEFjdGl2aXR5IG9uIHRoZSBJQUIgaW52b2x2ZXMgZGlzY3Vzc2lvbiBhbmQgZGVjaXNpb25z IHJlZ2FyZGluZyB0ZWNobmljYWwgbWF0dGVycywgbWFpbmx5IHJlbGF0ZWQgdG8gSUVURiBhY3Rp dml0aWVzLiBBcyBhbiBhY3Rpdml0eSBhZGphY2VudCB0byBhIHN0YW5kYXJkaXphdGlvbiBwcm9j ZXNzLCBpdCBpcyBvZnRlbiB0aGUgY2FzZSB0aGF0IENvdmVyZWQgSW5kaXZpZHVhbHMgd2lsbCBo YXZlIHNvbWUgKGZyZXF1ZW50bHkgbm9uLWZpbmFuY2lhbCkgc3Rha2UgaW4gdGhlIG91dGNvbWUg b2YgZGlzY3Vzc2lvbnMgb3IgZGVjaXNpb25zIHRoYXQgcmVsYXRlIHRvIHRlY2huaWNhbCBtYXR0 ZXJzLiBUaGlzIHBvbGljeSBkb2VzIG5vdCByZXF1aXJlIHRoYXQgQ292ZXJlZCBJbmRpdmlkdWFs cyBkaXNjbG9zZSBzdWNoIGNvbmZsaWN0cyBvZiBpbnRlcmVzdCBhcyB0aGV5IHJlbGF0ZSB0byB0 ZWNobmljYWwgbWF0dGVycy4gSG93ZXZlciwgQ292ZXJlZCBJbmRpdmlkdWFscyBuZWVkIHRvIGV4 ZXJjaXNlIHRoZWlyIGp1ZGdtZW50IGFuZCwgaW4gZXh0cmFvcmRpbmFyeSBjYXNlcyBiZSB3aWxs aW5nIHRvIGRpc2Nsb3NlIHBvdGVudGlhbCBvciBwZXJjZWl2ZWQgY29uZmxpY3RzIG9mIGludGVy ZXN0IGV2ZW4gYXMgdGhleSByZWxhdGUgdG8gdGVjaG5pY2FsIG1hdHRlcnMuIEZvciBleGFtcGxl LCBpZiBhIENvdmVyZWQgSW5kaXZpZHVhbCdzIHNwb25zb3Igd2VyZSBpbiB0aGUgcHJvY2VzcyBv ZiBlbnRlcmluZyBhIG5ldyBtYXJrZXQgd2hlcmUgdGhlcmUgaXMgYW4gb25nb2luZyBJQUIgZGlz Y3Vzc2lvbiwgdGhlbiBkaXNjbG9zdXJlLCBvciBldmVuIHJlY3VzYWwsIG1pZ2h0IGJlIGFwcHJv cHJpYXRlLCBldmVuIGlmIGRpZmZpY3VsdC4NCg0KRGlzY2xvc3VyZSBUcmFuc3BhcmVuY3kNCg0K QSBwZXJzb24ncyByZWN1c2FsIHRvIHBhcnRpY2lwYXRlIGluIHRoZSBkaXNjdXNzaW9uIG9mIGEg dG9waWMgaXMgYWx3YXlzIG5vdGVkIGluIHRoZSBwdWJsaWMgSUFCIG1pbnV0ZXMuIEluIGFkZGl0 aW9uLCB0aGUgSUFCIHdpbGwgbWFpbnRhaW4gYSByZXBvc2l0b3J5IG9mIGFsbCBnZW5lcmFsIGRp c2Nsb3N1cmVzIG9mIGVtcGxveW1lbnQgYW5kIG90aGVyIHNwb25zb3JzaGlwLiBJdCBpcyBleHBl Y3RlZCB0aGF0IG11Y2ggb2YgdGhpcyByZXBvc2l0b3J5IGlzIHB1YmxpYywgYnV0IHRoZXJlIGNh biBiZSBzaXR1YXRpb25zIHdoZXJlIHNvbWUgZGlzY2xvc3VyZXMgKHN1Y2ggYXMgY3VzdG9tZXJz IG9mIGNvbnN1bHRhbnRzKSBhcmUgcHJpdmF0ZS4NCg0KDQo8aHR0cHM6Ly9naXRodWIuY29tL2ph cmlhcmtrby9hbHRlcm5hdGUtaWFiLWNvaS1wb2xpY3kvYmxvYi9tYXN0ZXIvY29pLXBvbGljeS4u bWQjc3RhdHVzPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpBcmNoaXRlY3R1cmUtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCkFyY2hpdGVjdHVyZS1k aXNjdXNzQGlldGYub3JnPG1haWx0bzpBcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXJjaGl0ZWN0dXJlLWRpc2N1c3MN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBcmNoaXRl Y3R1cmUtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCkFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYub3Jn PG1haWx0bzpBcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYXJjaGl0ZWN0dXJlLWRpc2N1c3MNCg0K --_000_E56C960BEFF447EAAB62C441B4FD3354ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3C00E35C69C96646B5902F8838170874@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgYWdyZWUgd2l0aCBSaWNoYXJkLCBCZXJuYXJk LCBhbmQgRUtSLiAmbmJzcDtXaGVyZSBpbmRpdmlkdWFscyBvbiB0aGUgSUVTRyBoYXZlIGdyZWF0 IHBvd2VyLCB0aGlzIGdlbmVyYWxseSBjYW5ub3QgYmUgc2FpZCBhYm91dCBJQUIgbWVtYmVycywg Jm5ic3A7d2hvIGxhcmdlbHkgbWFrZSBkZWNpc2lvbnMgb24gcm91Z2ggY29uc2Vuc3VzLiAmbmJz cDsgVGhlIGFwcHJvcHJpYXRlIHNhZmVndWFyZCBhZ2FpbnN0IENPSSBpbiB0aGUgSUFCIGlzIHRv IGhhdmUgYSBkaXZlcnNlDQogSUFCLCBhbmQgdGhlIE5PTUNPTSBhbmQgdGhlIElTT0MgQm9UIHNo b3VsZCBzZWUgdG8gaXQgdGhhdCB0aGlzIGlzIHRoZSBjYXNlIGFueXdheSwgc28gYXMgdG8gaGVs cCB0aGUgY29tbXVuaXR5IGJlIHByZXBhcmVkIGZvciBUaGUgTmV4dCAodW5mb3Jlc2VlbikgUHJv YmxlbS4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkVsaW90PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA5IEphbiAyMDIwLCBhdCAyMzo1OSwgQmVybmFyZCBB Ym9iYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiBjbGFzcz0i Ij5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0i bHRyIiBjbGFzcz0iIj5BZ3JlZSB3aXRoIFJpY2hhcmQgaGVyZS4mbmJzcDsgTXVjaCBvZiB0aGUg SUFCIHdvcmsgaXMgdGVjaG5pY2FsIGluIG5hdHVyZS4mbmJzcDsgVGhlIElBQiBzaG91bGQgdGhl cmVmb3JlIG5vdCBuZWVkIGEgY29uZmxpY3Qtb2YtaW50ZXJlc3QgcG9saWN5IGFzIGhlYXZ5IHdl aWdodCBhcyB0aGF0IHJlcXVpcmVkIHRvIGFzc3VtZSBhIHNlbmlvciByb2xlIHdpdGhpbiBnb3Zl cm5tZW50LCBhIGxlZ2lzbGF0dXJlIG9yIGEgZ292ZXJubWVudGFsDQogYWR2aXNvcnkgY29tbWl0 dGVlLiZuYnNwOw0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+SGF2aW5nIHNlcnZlZCBvbiBhIGdvdmVybm1lbnRhbCBhZHZpc29yeSBjb21taXR0ZWUg Y292ZXJlZCBieSBGQUNBLCBpdCB3b3VsZCBhcHBlYXIgdG8gbWUgdGhhdCB0aGUgcHJvcG9zZWQg SUFCIENPSSBwb2xpY3kgaXMgcG90ZW50aWFsbHkgbW9yZSBzdHJpbmdlbnQuJm5ic3A7IEFzIGFu IGV4YW1wbGUsIHVuZGVyIEZBQ0EgSSB3YXMgbm90IHJlcXVpcmVkIHRvIHByb3ZpZGUgYSBjb21w bGV0ZSBmaW5hbmNpYWwgZGlzY2xvc3VyZS4mbmJzcDsNCiBUaGUgZ3VpZGFuY2Ugd2FzIHRoYXQg YSBkaXNjbG9zdXJlIG5lZWQgb25seSBiZSBtYWRlIGluIHRoZSBldmVudCBvZiBhIHBvdGVudGlh bCBjb25mbGljdCwgc2hvdWxkIG9uZSBhcmlzZS4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9 ImdtYWlsX2F0dHIiPk9uIFRodSwgSmFuIDksIDIwMjAgYXQgODo1OCBBTSBSaWNoYXJkIEJhcm5l cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giIGNsYXNzPSIiPnJsYkBpcHYuc3g8L2E+ Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHgg c29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JIHdvdWxkIHByb3Bvc2UgdGhlIElBQiBub3QgYWRv cHQgdGhpcyBwb2xpY3ksIG9yIGF0IGxlYXN0IHNjb3BlIGl0IHdheSBkb3duLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TXVjaCBvZiB0 aGUgSUFCJ3Mgd29yayBpcyBmb2N1c2VkIG9uIHRlY2huaWNhbCBpc3N1ZXMsIGF0IGEgaGlnaCBl bm91Z2ggc3RyYXRlZ2ljIGxldmVsIHRoYXQgdGhlIGltcGFjdHMgdG8gc3BlY2lmaWMgcGVvcGxl IG9yIGNvbXBhbmllcyBhcmUgaGlnaGx5IGF0dGVudWF0ZWQuJm5ic3A7IEluIHRob3NlIGRpc2N1 c3Npb25zLCB0aGUgSUFCJ3Mgd29yayBiZW5lZml0cyBmcm9tIGhhdmluZyBkaXZlcnNlIG9waW5p b25zLCBpbmNsdWRpbmcNCiB0aGUgb3BpbmlvbnMgb2YgdGhvc2Ugd2hvIGhhdmUgc2tpbiBpbiB0 aGUgZ2FtZS4mbmJzcDsgVHJ5aW5nIHRvIGludHJvZHVjZSBzb21lIG5vdGlvbiBvZiBDb0kgaW4g dGhpcyBjb250ZXh0IHdvdWxkIGJlIGhhcm1mdWwgLS0gYmVjYXVzZSB0aGVyZSdzIG5vIGhhcmQg Y29uZmxpY3QsIGl0IHdpbGwgaW5ldml0YWJseSBiZSB2YWd1ZSwgYW5kIHRodXMgcHJpbWFyaWx5 IGEgdG9vbCBmb3IgSUFCIG1lbWJlcnMgdG8gdHJ5IHRvIHNpbGVuY2Ugb25lIGFub3RoZXINCiBv ciBhIGNhdXNlIGZvciBJQUIgbWVtYmVycyB0byBzZWxmLWNlbnNvci48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PldoZXJlIHRoZSBJQUIgaXMgZGlyZWN0bHkgaW52b2x2ZWQgaW4gZmluYW5jZSBvciBwZXJzb25u ZWwgZGVjaXNpb25zLCB0aGVyZSBvZiBjb3Vyc2Ugc2hvdWxkIGJlIGd1YXJkcyBhZ2FpbnN0IHNl bGYgZGVhbGluZy4mbmJzcDsgVGhhdCdzIHdoZXJlIGFueSBDb0kgcG9saWN5IGZvciB0aGUgSUFC IHNob3VsZCBzdG9wLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+LS1SaWNoYXJkPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJnbWFpbF9hdHRyIj5PbiBXZWQsIEphbiA4LCAyMDIwIGF0IDY6MTYgUE0gSUFCIENoYWly ICZsdDs8YSBocmVmPSJtYWlsdG86aWFiLWNoYWlyQGlhYi5vcmciIHRhcmdldD0iX2JsYW5rIiBj bGFzcz0iIj5pYWItY2hhaXJAaWFiLm9yZzwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAw cHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRp bmctbGVmdDoxZXgiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJBcmlhbCIgY2xhc3M9IiI+ PGZvbnQgc2l6ZT0iJiM0MzszIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0 LDM0KTtmb250LXNpemU6c21hbGw7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0 dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0 ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10 cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3Jv dW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7 dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7ZGlzcGxheTppbmxpbmU7ZmxvYXQ6bm9uZSIg Y2xhc3M9IiI+PC9zcGFuPjwvZm9udD48L2ZvbnQ+DQo8cCBzdHlsZT0iY29sb3I6cmdiKDM0LDM0 LDM0KTtmb250LWZhbWlseTpBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21h bGw7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0ZXItc3BhY2luZzpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0 ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUs MjU1LDI1NSk7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNv bG9yOmluaXRpYWwiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PHNwYW4gZGlyPSJsdHIiIG5h bWU9ImFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYub3JnIiBjbGFzcz0iIj48L3NwYW4+PC9zcGFu Pjxmb250IHNpemU9IiYjNDM7MSIgY2xhc3M9IiI+RGVhciBDb2xsZWFndWVzLDwvZm9udD48L3A+ DQo8cCBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTpBcmlhbCxIZWx2ZXRp Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGw7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJp YW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0 OjQwMDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDow cHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBw eDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7dGV4dC1kZWNvcmF0aW9uLXN0eWxl OmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwiIGNsYXNzPSIiPg0KPGZvbnQg c2l6ZT0iJiM0MzsxIiBjbGFzcz0iIj5UaGUgSUFCIGlzIGNvbnNpZGVyaW5nIGFkb3B0aW9uIG9m IHRoZSBjb25mbGljdCBvZiBpbnRlcmVzdCBwb2xpY3kgYmVsb3cuJm5ic3A7IElmIHlvdSBoYXZl IGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQgcG9saWN5LCBwbGVhc2Ugc2VuZCB0aGVtIHRvPHNwYW4g Y2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppYWJAaWFiLm9yZyIgc3R5bGU9 ImNvbG9yOnJnYigxNyw4NSwyMDQpIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aWFiQGlhYi5v cmc8L2E+LjwvZm9udD48L3A+DQo8cCBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZh bWlseTpBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGw7Zm9udC1zdHls ZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3Jt YWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7dGV4 dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwi IGNsYXNzPSIiPg0KPGZvbnQgc2l6ZT0iJiM0MzsxIiBjbGFzcz0iIj5iZXN0IHJlZ2FyZHMsPC9m b250PjwvcD4NCjxmb250IHNpemU9IiYjNDM7MSIgY2xhc3M9IiI+VGVkIEhhcmRpZTwvZm9udD48 YnIgY2xhc3M9IiI+DQo8Zm9udCBzaXplPSImIzQzOzEiIGNsYXNzPSIiPmZvciB0aGUgSUFCPGJy IGNsYXNzPSIiPg0KPC9mb250PjxiciBjbGFzcz0iIj4NCjxmb250IHNpemU9IiYjNDM7MiIgY2xh c3M9IiI+PGZvbnQgc2l6ZT0iJiM0MzszIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6cmdi KDM0LDM0LDM0KTtmb250LWZhbWlseTpBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNp emU6c21hbGw7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0ZXItc3BhY2luZzpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9u ZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNTUsMjU1LDI1NSk7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0 aW9uLWNvbG9yOmluaXRpYWw7ZGlzcGxheTppbmxpbmU7ZmxvYXQ6bm9uZSIgY2xhc3M9IiI+PC9z cGFuPjwvZm9udD48YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNs YXNzPSIiPjxzcGFuIGRpcj0ibHRyIiBuYW1lPSJhcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9y ZyIgY2xhc3M9IiI+PC9zcGFuPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhv bGRlciI+DQo8L2Rpdj4NCjxoMyBjbGFzcz0iIj5JTlRFUk5FVCBBUkNISVRFQ1RVUkUgQk9BUkQg Q09ORkxJQ1QgT0YgSU5URVJFU1QgUE9MSUNZPC9oMz4NCjxwIGNsYXNzPSIiPlRoaXMgcG9saWN5 IGNvdmVycyB0aGUgbm9tY29tLXNlbGVjdGVkIEludGVybmV0IEFyY2hpdGVjdHVyZSBCb2FyZCAo SUFCKSBtZW1iZXJzIGFuZCBleC1vZmZpY2lvIG1lbWJlcnMgKGNvbGxlY3RpdmVseSwg4oCcQ292 ZXJlZCBJbmRpdmlkdWFsc+KAnSkuIFRoaXMgcG9saWN5IGhhcyBubyBpbXBhY3Qgb24gYW55IG90 aGVyIHBhcnRpY2lwYW50cyBpbiBJQUIgYWN0aXZpdGllcywgZm9yIGluc3RhbmNlIGxpYWlzb25z IHRvIGFuZCBmcm9tDQogdGhlIElBQiBvciBJQUIgcHJvZ3JhbSBtZW1iZXJzLjwvcD4NCjxwIGNs YXNzPSIiPkluIGNhcnJ5aW5nIG91dCB0aGVpciBJQUIgcm9sZSwgQ292ZXJlZCBJbmRpdmlkdWFs cyBtdXN0IGFjdCBpbiB0aGUgYmVzdCBpbnRlcmVzdCBvZiB0aGUgSW50ZXJuZXQgY29tbXVuaXR5 LiBPY2Nhc2lvbmFsbHkgdGhpcyBkdXR5IG1heSBiZeKAlG9yIG1heSBhcHBlYXIgdG8gYmXigJRp bmNvbXBhdGlibGUgb3IgaW4gY29uZmxpY3Qgd2l0aCBhIENvdmVyZWQgSW5kaXZpZHVhbOKAmXMg cGVyc29uYWwgaW50ZXJlc3RzIChpbmNsdWRpbmcNCiBpbnRlcmVzdHMgb2YgdGhlaXIgZmFtaWx5 IG1lbWJlcnMpLCBvciB0aGUgaW50ZXJlc3RzIG9mIGFuIG9yZ2FuaXphdGlvbiBvZiB3aGljaCB0 aGUgQ292ZXJlZCBJbmRpdmlkdWFsIGlzIGFuIGVtcGxveWVlLCBkaXJlY3Rvciwgb3duZXIsIG9y IG90aGVyd2lzZSBoYXMgYnVzaW5lc3Mgb3IgZmluYW5jaWFsIGludGVyZXN0LiBJZiBhIENvdmVy ZWQgSW5kaXZpZHVhbCBoYXMgYSBjb25mbGljdCBvZiBpbnRlcmVzdCBmb3Igd2hhdGV2ZXIgcmVh c29uLA0KIHRoYXQgaW5kaXZpZHVhbCBtdXN0IGF2b2lkIHBhcnRpY2lwYXRpbmcgaW4gdGhlIHdv cmsgb2YgdGhlIElBQiB0aGF0IHRvdWNoZXMgb24gdGhlIHJlbGF0ZWQgbWF0dGVyLjwvcD4NCjxw IGNsYXNzPSIiPlRoZSBJQUIgZG9lcyBub3QgZGlyZWN0bHkgZGVhbCB3aXRoIG1hdHRlcnMgcmVs YXRpbmcgdG8gY29udHJhY3RzIG9yIGZpbmFuY2UuIFRoZSBJQUIgZG9lcywgaG93ZXZlciwgaGF2 ZSBhIHJvbGUgaW4gcGVyc29ubmVsIGRlY2lzaW9ucywgYW5kIGl0cyBkZWNpc2lvbnMgYW5kIG91 dHB1dHMgaGF2ZSBhIHBvdGVudGlhbCB0byBpbmRpcmVjdGx5IGFmZmVjdCBjb250cmFjdHMgd2l0 aGluIHRoZSBJRVRGIHN5c3RlbS4gSUFCJ3MNCiB0ZWNobmljYWwgZGVjaXNpb25zIGFuZCBvdXRw dXRzIGhhdmUgYWxzbyBhIHBvdGVudGlhbCB0byBpbXBhY3QgYm90aCB3b3JrIGVsc2V3aGVyZSBp biB0aGUgSUVURiBhbmQgYnVzaW5lc3NlcyB0aGF0IGVtcGxveSBvciBkZXZlbG9wIEludGVybmV0 IHRlY2hub2xvZ3kuPC9wPg0KPHAgY2xhc3M9IiI+Q292ZXJlZCBJbmRpdmlkdWFscyBzaGFsbCBu b3QgdXNlIHRoZSBJQULigJlzIHJlc291cmNlcyBvciBkZWNpc2lvbnMgYXMgYSBtZWFucyBmb3Ig cGVyc29uYWwgb3IgdGhpcmQtcGFydHkgZ2Fpbi48L3A+DQo8aDMgY2xhc3M9IiI+RGlzY2xvc3Vy ZSBvZiBBY3R1YWwgb3IgUG90ZW50aWFsIENvbmZsaWN0czwvaDM+DQo8cCBjbGFzcz0iIj5UaGUg SUFCIHJlcXVpcmVzIHRoYXQgYWxsIENvdmVyZWQgSW5kaXZpZHVhbHMgZGlzY2xvc2UgdGhlaXIg bWFpbiBlbXBsb3ltZW50LCBzcG9uc29yc2hpcCwgY29uc3VsdGluZyBjdXN0b21lciwgb3Igb3Ro ZXIgc291cmNlcyBvZiBpbmNvbWUgd2hlbiBqb2luaW5nIHRoZSBJQUIgb3Igd2hlbmV2ZXIgdGhl cmUgYXJlIHVwZGF0ZXMuPC9wPg0KPHAgY2xhc3M9IiI+SW4gYWRkaXRpb24sIHdoZW4gYSB0b3Bp YyBpcyBkaXNjdXNzZWQgYXQgdGhlIElBQiwgdGhlIENvdmVyZWQgSW5kaXZpZHVhbHMgYXJlIHJl cXVpcmVkIHRvIHByb21wdGx5IGRpc2Nsb3NlIGlmIHRoYXQgdG9waWMgY29uc3RpdHV0ZXMgYSBw ZXJjZWl2ZWQgb3IgcG90ZW50aWFsIGNvbmZsaWN0IG9mIGludGVyZXN0LiBPbmNlIGRpc2Nsb3Nl ZCwgQ292ZXJlZCBJbmRpdmlkdWFscyBtYXkgcmVjdXNlIGZyb20gcGFydGljaXBhdGlvbg0KIGlu IGRpc2N1c3Npb25zIG9yIGRlY2lzaW9ucyBhdCB0aGVpciBkaXNjcmV0aW9uLjwvcD4NCjxwIGNs YXNzPSIiPlRoZSBzcGVjaWZpYyBjb25mbGljdHMgdGhhdCBtYXkgY2F1c2UgYSBwZXJjZWl2ZWQg b3IgcG90ZW50aWFsIGNvbmZsaWN0IG9mIGludGVyZXN0IGFyZSBtYXR0ZXJzIGZvciBpbmRpdmlk dWFsIGFuZCBJQUIganVkZ21lbnQsIGJ1dCBnZW5lcmFsbHkgY29tZSBpbiB0aGUgZm9sbG93aW5n IGZvcm1zOjwvcD4NCjx1bCBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iIj4NCjxwIGNsYXNzPSIiPkEg cGVyc29ubmVsIGRlY2lzaW9uIHJlbGF0ZXMgdG8gdGhlIENvdmVyZWQgSW5kaXZpZHVhbCwgYSBj b2xsZWFndWUgdGhhdCB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsJ3Mgd29ya3MgY2xvc2VseSB3aXRo LCBvciBhIGZhbWlseSBtZW1iZXIuIEZvciB0aGUgcHVycG9zZXMgb2YgdGhpcyBwb2xpY3ksIGEg JnF1b3Q7cGVyc29uIHdvcmtpbmcgY2xvc2VseSB3aXRoJnF1b3Q7IGlzIHNvbWVvbmUgd29ya2lu ZyBpbiB0aGUgc2FtZSB0ZWFtIG9yIHByb2plY3QsDQogb3IgYSBkaXJlY3QgbWFuYWdlciBvciBl bXBsb3llZSBvZiB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsLiBBbmQgJnF1b3Q7ZmFtaWx5JnF1b3Q7 IG1lYW5zIGEgc3BvdXNlLCBkb21lc3RpYyBwYXJ0bmVyLCBjaGlsZCwgc2libGluZywgcGFyZW50 LCBzdGVwY2hpbGQsIHN0ZXBwYXJlbnQsIGFuZCBtb3RoZXItLCBmYXRoZXItLCBzb24tLCBkYXVn aHRlci0sIGJyb3RoZXItLCBvciBzaXN0ZXItaW4tbGF3LCBhbmQgYW55IG90aGVyIHBlcnNvbiBs aXZpbmcgaW4gdGhlIHNhbWUNCiBob3VzZWhvbGQsIGV4Y2VwdCB0ZW5hbnRzIGFuZCBob3VzZWhv bGQgZW1wbG95ZWVzLjwvcD4NCjwvbGk+PGxpIGNsYXNzPSIiPg0KPHAgY2xhc3M9IiI+QSBkZWNp c2lvbiBvciBvdXRwdXQgZnJvbSB0aGUgSUFCIGltcGFjdHMgYSBjb250cmFjdCB0aGF0IHRoZSBJ RVRGIGVudGVycyBpbnRvIHdpdGggYSBwYXJ0eSwgYW5kIHRoYXQgcGFydHkgcmVsYXRlcyB0byB0 aGUgQ292ZXJlZCBJbmRpdmlkdWFsLCBhIGNvbGxlYWd1ZSB0aGF0IHRoZSBDb3ZlcmVkIEluZGl2 aWR1YWwncyB3b3JrcyBjbG9zZWx5IHdpdGgsIG9yIGEgZmFtaWx5IG1lbWJlci48L3A+DQo8L2xp PjxsaSBjbGFzcz0iIj4NCjxwIGNsYXNzPSIiPkFjdGl2aXR5IG9uIHRoZSBJQUIgaW52b2x2ZXMg ZGlzY3Vzc2lvbiBhbmQgZGVjaXNpb25zIHJlZ2FyZGluZyB0ZWNobmljYWwgbWF0dGVycywgbWFp bmx5IHJlbGF0ZWQgdG8gSUVURiBhY3Rpdml0aWVzLiBBcyBhbiBhY3Rpdml0eSBhZGphY2VudCB0 byBhIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzLCBpdCBpcyBvZnRlbiB0aGUgY2FzZSB0aGF0IENv dmVyZWQgSW5kaXZpZHVhbHMgd2lsbCBoYXZlIHNvbWUgKGZyZXF1ZW50bHkNCiBub24tZmluYW5j aWFsKSBzdGFrZSBpbiB0aGUgb3V0Y29tZSBvZiBkaXNjdXNzaW9ucyBvciBkZWNpc2lvbnMgdGhh dCByZWxhdGUgdG8gdGVjaG5pY2FsIG1hdHRlcnMuIFRoaXMgcG9saWN5IGRvZXMgbm90IHJlcXVp cmUgdGhhdCBDb3ZlcmVkIEluZGl2aWR1YWxzIGRpc2Nsb3NlIHN1Y2ggY29uZmxpY3RzIG9mIGlu dGVyZXN0IGFzIHRoZXkgcmVsYXRlIHRvIHRlY2huaWNhbCBtYXR0ZXJzLiBIb3dldmVyLCBDb3Zl cmVkIEluZGl2aWR1YWxzIG5lZWQNCiB0byBleGVyY2lzZSB0aGVpciBqdWRnbWVudCBhbmQsIGlu IGV4dHJhb3JkaW5hcnkgY2FzZXMgYmUgd2lsbGluZyB0byBkaXNjbG9zZSBwb3RlbnRpYWwgb3Ig cGVyY2VpdmVkIGNvbmZsaWN0cyBvZiBpbnRlcmVzdCBldmVuIGFzIHRoZXkgcmVsYXRlIHRvIHRl Y2huaWNhbCBtYXR0ZXJzLiBGb3IgZXhhbXBsZSwgaWYgYSBDb3ZlcmVkIEluZGl2aWR1YWwncyBz cG9uc29yIHdlcmUgaW4gdGhlIHByb2Nlc3Mgb2YgZW50ZXJpbmcgYSBuZXcgbWFya2V0DQogd2hl cmUgdGhlcmUgaXMgYW4gb25nb2luZyBJQUIgZGlzY3Vzc2lvbiwgdGhlbiBkaXNjbG9zdXJlLCBv ciBldmVuIHJlY3VzYWwsIG1pZ2h0IGJlIGFwcHJvcHJpYXRlLCBldmVuIGlmIGRpZmZpY3VsdC48 L3A+DQo8L2xpPjwvdWw+DQo8aDMgY2xhc3M9IiI+RGlzY2xvc3VyZSBUcmFuc3BhcmVuY3k8L2gz Pg0KPHAgY2xhc3M9IiI+QSBwZXJzb24ncyByZWN1c2FsIHRvIHBhcnRpY2lwYXRlIGluIHRoZSBk aXNjdXNzaW9uIG9mIGEgdG9waWMgaXMgYWx3YXlzIG5vdGVkIGluIHRoZSBwdWJsaWMgSUFCIG1p bnV0ZXMuIEluIGFkZGl0aW9uLCB0aGUgSUFCIHdpbGwgbWFpbnRhaW4gYSByZXBvc2l0b3J5IG9m IGFsbCBnZW5lcmFsIGRpc2Nsb3N1cmVzIG9mIGVtcGxveW1lbnQgYW5kIG90aGVyIHNwb25zb3Jz aGlwLiBJdCBpcyBleHBlY3RlZCB0aGF0IG11Y2ggb2YNCiB0aGlzIHJlcG9zaXRvcnkgaXMgcHVi bGljLCBidXQgdGhlcmUgY2FuIGJlIHNpdHVhdGlvbnMgd2hlcmUgc29tZSBkaXNjbG9zdXJlcyAo c3VjaCBhcyBjdXN0b21lcnMgb2YgY29uc3VsdGFudHMpIGFyZSBwcml2YXRlLjwvcD4NCjxoMSBj bGFzcz0iIj48YSBpZD0iZ21haWwtbV82NjU4NTkxOTc1MTQ0OTAzMDE1Z21haWwtbV8tMzg2NDM1 Mjc2MjYwNDkxNDQ1M3VzZXItY29udGVudC1zdGF0dXMiIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv bS9qYXJpYXJra28vYWx0ZXJuYXRlLWlhYi1jb2ktcG9saWN5L2Jsb2IvbWFzdGVyL2NvaS1wb2xp Y3kuLm1kI3N0YXR1cyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjx1IGNsYXNzPSIiPjwvdT48 YnIgY2xhc3M9IiI+DQo8dSBjbGFzcz0iIj48L3U+PC9hPjwvaDE+DQo8cCBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48c3BhbiBkaXI9Imx0ciIgbmFtZT0iYXJjaGl0ZWN0 dXJlLWRpc2N1c3NAaWV0Zi5vcmciIGNsYXNzPSIiPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KQXJjaGl0ZWN0dXJlLWRpc2N1c3MgbWFpbGlu ZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOkFyY2hpdGVjdHVyZS1kaXNjdXNz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+QXJjaGl0ZWN0dXJlLWRpc2N1c3NA aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hcmNoaXRlY3R1cmUtZGlzY3VzcyIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hcmNoaXRlY3R1cmUtZGlzY3VzczwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSIiPg0KQXJjaGl0ZWN0dXJlLWRpc2N1c3MgbWFpbGluZyBsaXN0PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOkFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYub3JnIiBjbGFz cz0iIj5BcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FyY2hpdGVjdHVyZS1kaXNjdXNzPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E56C960BEFF447EAAB62C441B4FD3354ciscocom_-- From nobody Thu Jan 9 23:20:05 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341C5120131 for ; Thu, 9 Jan 2020 23:20:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=elandsys.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 UloGofofXu7u for ; Thu, 9 Jan 2020 23:20:02 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5141200B3 for ; Thu, 9 Jan 2020 23:20:01 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.131.215]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00A7Jm5Y011148 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2020 23:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1578640800; x=1578727200; i=@elandsys.com; bh=Y0iE0UdMUek9WGVT5QZOFtV/nYuqVIhjbSn8UFP+NlM=; h=Date:To:From:Subject:In-Reply-To:References; b=DcAwZxX/mBffr83HUVTFsWZbfqoWR+d6GHcY5S1miR64chIgzkmIVhiGR411paw2a QNPxRpKhnyYJTG0gECRnBRTYLCTt3BAc7ew7vIOstlqea1H8YLgtXA8e5H99kmHPFj A4X9QNFb5surMVlZDCOHqFLb6O7jGhD0Uap3tbdU= Message-Id: <6.2.5.6.2.20200109210438.07f5deb0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 09 Jan 2020 23:17:53 -0800 To: Joe Touch , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <7433C1A1-E071-417C-B7B8-CB4C12E7FEDC@strayalpha.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <7433C1A1-E071-417C-B7B8-CB4C12E7FEDC@strayalpha.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 07:20:03 -0000 Hi Joe, At 07:11 AM 09-01-2020, Joe Touch wrote: >Numerous issues typically mentioned in COI policies are missing here: > >1) compensation may be pending or in the immediate future There is some text in second paragraph of the second section about that. >2) Compensation need not be financial (e.g., authorship, appointment >to perceived prestigious non-paying positions, quid-pro-quo, etc.) > >3) Conflicts go beyond direct collaborations (i.e., the employers >whole organization) The above could be quite lengthy if the duties/responsibilities are not clearly defined. It is sometimes considered in a policy under perceived conflict of interest. >4) The policy should indicate a time frame I didn't understand what you meant in (4). >Some examples from other COI policies include: > >- no current student/teacher relationship >- no PhD graduate / PhD primary advisor *forever* >- no current or recent proposal or paper co-author (whether granted >or not) for 4 years >- not in any way associated with a current employer *and its subsidiaries* >- agree to not accept compensation (financial or not) for at least 1 >year *after* participation The last one is about "revolving door" rules. I'll reuse an example which Ted posted. The IAB is considering a recommendation for a RSE and decides to reject it. An IAB member steps down and sets up a LLC. There is another RFP and, based on the recommendation of RSOC, the IAB approves the contract for the LLC. Would that be an appropriate course of action? Regards, S. Moonesamy From nobody Fri Jan 10 06:36:30 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFAC1200FF for ; Fri, 10 Jan 2020 06:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 6fonWKoyeJTg for ; Fri, 10 Jan 2020 06:36:25 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 AA31A1200EC for ; Fri, 10 Jan 2020 06:36:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zDUamMWr2AJHh+9c9tT/BFLhzQhOYfuzT+ndbYiOboE=; b=BAMXJ8FHezvAbnehVcB2+TMR6 ocm3yj6TTq7j9wuP5KvqWmepDaeF/HAq5NHicC2+E2VDdKYTljh+lqgckCBqg3AVs8gkA3OceJNxe SqZ+fVKLNs7G5Wu9EuQx+ZcLzycDZvzAKlBo0XFKkKYhd7y3BGu1i7AjoREyRKcKQLztStQE6LXw3 PSue68EBVSupLe9h0Fz7QDHTTWKi34ikAc0wNOqu4Yum9WxhN8oyBVJah55eOjijFTs+53RQCgAjq NF6pUHDNZGgv6eUgQc4cTreckeJsyIiCnnfFKj7C5P8+6YBl5EQtWMJwli/WSzE9br6KegfANMyWJ ai771joBw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52385 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ipvOX-002X44-0o; Fri, 10 Jan 2020 09:36:19 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_809AD86C-31B7-4F66-BA74-B275DB9AE662" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Joe Touch In-Reply-To: <6.2.5.6.2.20200109210438.07f5deb0@elandnews.com> Date: Fri, 10 Jan 2020 06:36:12 -0800 Cc: architecture-discuss@ietf.org Message-Id: <9F257662-5BD3-4D46-B4C2-3E9C67534F0C@strayalpha.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <7433C1A1-E071-417C-B7B8-CB4C12E7FEDC@strayalpha.com> <6.2.5.6.2.20200109210438.07f5deb0@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.3608.40.2.2.4) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 14:36:29 -0000 --Apple-Mail=_809AD86C-31B7-4F66-BA74-B275DB9AE662 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 9, 2020, at 11:17 PM, S Moonesamy wrote: >=20 >> 4) The policy should indicate a time frame >=20 > I didn't understand what you meant in (4). Most of the examples imply current employer/collaborator. That = association should be declared even into the recent past, for some = number of years. >> Some examples from other COI policies include: >>=20 >> - no current student/teacher relationship >> - no PhD graduate / PhD primary advisor *forever* >> - no current or recent proposal or paper co-author (whether granted = or not) for 4 years >> - not in any way associated with a current employer *and its = subsidiaries* >> - agree to not accept compensation (financial or not) for at least 1 = year *after* participation >=20 > The last one is about "revolving door" rules. I'll reuse an example = which Ted posted. The IAB is considering a recommendation for a RSE and = decides to reject it. An IAB member steps down and sets up a LLC. = There is another RFP and, based on the recommendation of RSOC, the IAB = approves the contract for the LLC. Would that be an appropriate course = of action? It depends on when the second RFP is issued (another time issue). If = within 1 year (typically), then the member would be ineligible from = leading, collaborating, or even advising an applicant to the new RFP. The concept is =E2=80=9Cunfair advantage=E2=80=9D because the member has = inside information that *could be perceived* to provide unfair insight = into responding to the new RFP. Joe= --Apple-Mail=_809AD86C-31B7-4F66-BA74-B275DB9AE662 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 9, 2020, at 11:17 PM, S Moonesamy <sm+ietf@elandsys.com> wrote:

4) = The policy should indicate a time frame

I didn't understand what you = meant in (4).

Most of the examples imply current = employer/collaborator. That association should be declared even into the = recent past, for some number of years.

Some = examples from other COI policies include:

- = no current student/teacher relationship
- no PhD graduate = / PhD primary advisor *forever*
- no current or recent = proposal or paper co-author (whether granted or not) for 4 years
- not in any way associated with a current employer *and its = subsidiaries*
- agree to not accept compensation = (financial or not) for at least 1 year *after* participation

The last one is about "revolving door" rules.  I'll = reuse an example which Ted posted.  The IAB is considering a = recommendation for a RSE and decides to reject it.  An IAB member = steps down and sets up a LLC.  There is another RFP and, based on = the recommendation of RSOC, the IAB approves the contract for the LLC. =  Would that be an appropriate course of = action?

It depends on when the second RFP is issued (another time = issue). If within 1 year (typically), then the member would be = ineligible from leading, collaborating, or even advising an applicant to = the new RFP.

The= concept is =E2=80=9Cunfair advantage=E2=80=9D because the member has = inside information that *could be perceived* to provide unfair insight = into responding to the new RFP.

Joe
= --Apple-Mail=_809AD86C-31B7-4F66-BA74-B275DB9AE662-- From nobody Fri Jan 10 10:42:37 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7576F120AC4; Fri, 10 Jan 2020 10:42:13 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 mCIHi-1gyBvK; Fri, 10 Jan 2020 10:42:09 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09ED61208F5; Fri, 10 Jan 2020 10:42:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 656CB9AE102D; Fri, 10 Jan 2020 12:42:05 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFbuNK0yJB4D; Fri, 10 Jan 2020 12:42:02 -0600 (CST) Received: from [172.16.1.18] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 6FC2F9AE1023; Fri, 10 Jan 2020 12:42:02 -0600 (CST) From: "Pete Resnick" To: "Eric Rescorla" Cc: "Joe Touch" , "Richard Barnes" , "IAB Chair" , IAB , "IETF discussion list" , architecture-discuss@ietf.org Date: Fri, 10 Jan 2020 12:42:02 -0600 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <2377bee131af6f5a6f5a1104bc25e056@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 18:42:14 -0000 On 9 Jan 2020, at 17:59, Eric Rescorla wrote: > On Thu, Jan 9, 2020 at 2:40 PM Joe Touch wrote: > >> On 2020-01-09 10:46, Eric Rescorla wrote: >> >> The IETF is most successful when we get >> input from people who are directly involved in the technologies that >> we are standardizing, but of course that very often means that they >> are working on those technologies for their employer. >> >> But it is dangerous to have those parties directly involved in >> decision >> making. The actual and potential COI (esp. perceived potential COI) >> undermine the decisions made - even when those decisions are >> otherwise >> reasonable. >> >> I.e., think of this as protecting the value of IAB decisions (and, as >> Ben >> noted, there are many, esp. during appeals, that are of a substantive >> nature that COI benefits). > > And yet we routinely allow have WG chairs and ADs who are deeply > involved > (and whose employers are deeply involved) in the technologies that are > being standardized. One important difference with chairs (and even ADs) is that their technical/standardization decisions can be appealed, where potential conflicts of interest can presumably be removed from the equation. That's not true of the IAB. So while I agree with Richard that it's the mainly the personnel and finance decisions that need a CoI policy, it's probably also useful to have it apply in those relatively few discussions of the IAB that result in an actual *decision* (handling appeals, perhaps some odd liaison activities). So it's really the third bullet in the proposal that needs to be reduced. That said, for all of this I think transparency is the most important bit, not the recusal. So long as everyone is open about their possible biases, the others in the discussion can take those into account and adjust. The NomCom processes can be used for people who do not appropriately disclose. And on that note: It's not just recusal that should be minuted; if someone discloses a perceived or potential CoI, whether or not they recuse, that should be noted (appropriately redacted if necessary). pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Sat Jan 11 00:57:03 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84F120033; Sat, 11 Jan 2020 00:57:02 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA2_q_jZyBaw; Sat, 11 Jan 2020 00:56:58 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 293D012004A; Sat, 11 Jan 2020 00:56:58 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id t2so3981597wrr.1; Sat, 11 Jan 2020 00:56:58 -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=3jgeuovyseLNj4znrOaGYf8ASCW8Au2GVt9izeT5qXw=; b=KCUmk3Pc5kv8hn2AdghOtZ9ucEhOizBPZYPzqUIAWdKDayZOI4QVgJQ5eo+27CZFTD vYBa+iKaehVvtRaxv3EdMfDTbg7mPMQT68wQrb44+gpJOxU+n+VxrLLxji6X8RsMwFn8 7glugXsgLa6DcvGlyscb9gNrGATKFfCF/wAQLur8aYIYZ87Dz1EqW1+oZ/FR/tbVQ2nx 4xtjYoDUq4BvI5FqElgAPE9AhFhtJ6pD+UZGNoJzJs9SrOjyBCiC94+l92qwd3+5ejkm Tq004R0RwfO2gkywT6w57pmS6T+tFL/8UrM3B9Ehksm7p+huyXq4BkFpecqe5ynoDPkM mutA== 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=3jgeuovyseLNj4znrOaGYf8ASCW8Au2GVt9izeT5qXw=; b=cwulcp0KBdHrO03cZP9aLVrmzGyqcESVRUJWWKg/Xj1JwDZ12i+WKKbp/O2xlUcec1 GCWXIoYh9Owus5ikrl4xjgn3ka5yRpxnrfTwPZ/rT4Mto3MxMSHS/+DMsRxGge3/Y8rO sW4yKsasTTMgWNQ/xoa0uFyGjyNokzdAdpkpPV3+/jg3pKyxWlgEEp6p2V5PnQrYhbAI orC3imSkm64ffQZCIfqKBndVR4jeLzHa6vQ2xSLCRXeBJLr/glrccU5DC7et6Gg+M8b7 qqNp3GfIqHsvrij+jQkpubys1EFrMi1PxQofji8in+7TbSJZDcQz/ZZWgWn3FoSA+A97 QI3g== X-Gm-Message-State: APjAAAUjl5itOLd1n2CPA5z1sM0aqXNW5EUcXSkKAEw5pxbVN52KrX1T d0Ob64NwyAvDUodlyGeQ3OA= X-Google-Smtp-Source: APXvYqyltk5WrhtQ02coNyWQywGS5daKRGoQ5vIUYQf4Y8fsI2oAVH18imgR48yfAcLM24InMeBkhw== X-Received: by 2002:adf:ef10:: with SMTP id e16mr7579534wro.336.1578733015496; Sat, 11 Jan 2020 00:56:55 -0800 (PST) Received: from [192.168.178.46] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id u14sm5507503wrm.51.2020.01.11.00.56.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Jan 2020 00:56:54 -0800 (PST) From: Stewart Bryant Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0D99ABA9-A960-406B-A8AD-AED44064A0CD" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Sat, 11 Jan 2020 08:56:23 +0000 In-Reply-To: Cc: Eric Rescorla , Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org To: Joe Touch References: X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 08:57:02 -0000 --Apple-Mail=_0D99ABA9-A960-406B-A8AD-AED44064A0CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 .. and that is why we run two-in-a-box in most roles so that the = conflicted person can step aside. Stewart > On 10 Jan 2020, at 01:33, Joe Touch wrote: >=20 > Yes. And it at times has been an issue. >=20 > Joe >=20 >> On Jan 9, 2020, at 3:59 PM, Eric Rescorla wrote: >>=20 >> =EF=BB=BF >>=20 >>=20 >> On Thu, Jan 9, 2020 at 2:40 PM Joe Touch > wrote: >> On 2020-01-09 10:46, Eric Rescorla wrote: >>=20 >>> I concur with Richard here. The IETF is most successful when we get >>> input from people who are directly involved in the technologies that >>> we are standardizing, but of course that very often means that they >>> are working on those technologies for their employer. And indeed >>> one of the criteria we often use to ask whether someone is a good >>> fit for leadership is whether they have this kind of non-standards >>> "day job" expertise. >> =20 >> =20 >> That, IMO, is why we encourage their participation in WG discussions = and on lists. >> =20 >> But it is dangerous to have those parties directly involved in = decision making. The actual and potential COI (esp. perceived potential = COI) undermine the decisions made - even when those decisions are = otherwise reasonable. >> =20 >> I.e., think of this as protecting the value of IAB decisions (and, as = Ben noted, there are many, esp. during appeals, that are of a = substantive nature that COI benefits). >>=20 >> And yet we routinely allow have WG chairs and ADs who are deeply = involved (and whose employers are deeply involved) in the technologies = that are being standardized. >>=20 >> -Ekr >>=20 >> =20 >> Joe >>=20 >>=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail=_0D99ABA9-A960-406B-A8AD-AED44064A0CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 .. = and that is why we run two-in-a-box in most roles so that the conflicted = person can step aside.

Stewart

On 10 Jan 2020, at 01:33, Joe = Touch <touch@strayalpha.com> wrote:

Yes. =  And it at times has been an issue.

Joe

On Jan 9, 2020, at 3:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:

=EF=BB=BF


On Thu, Jan 9, 2020 at 2:40 PM Joe Touch <touch@strayalpha.com> wrote:

On 2020-01-09 10:46, Eric Rescorla wrote:

I concur with Richard here. The IETF is most = successful when we get
input from people who are directly = involved in the technologies that
we are standardizing, = but of course that very often means that they
are working on those technologies for their employer. = And indeed
one of the criteria we often use to ask whether someone = is a good
fit for leadership is whether they have this kind of = non-standards
"day job" expertise.
 
 
That, IMO, is why we encourage their participation in WG = discussions and on lists.
 
But it is dangerous to have those parties directly = involved in decision making. The actual and potential COI (esp. = perceived potential COI) undermine the decisions made - even when those = decisions are otherwise reasonable.
 
I.e., think of this as protecting the value of IAB = decisions (and, as Ben noted, there are many, esp. during appeals, that = are of a substantive nature that COI = benefits).

And yet we routinely allow have WG = chairs and ADs who are deeply involved (and whose employers are deeply = involved) in the technologies that are being standardized.

-Ekr

 
Joe


=
_______________________________________________Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss

= --Apple-Mail=_0D99ABA9-A960-406B-A8AD-AED44064A0CD-- From nobody Sun Jan 12 09:37:41 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579A7120048 for ; Sun, 12 Jan 2020 09:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 cyHboebJy8Xw for ; Sun, 12 Jan 2020 09:37:33 -0800 (PST) Received: from smtp105.ord1c.emailsrvr.com (smtp105.ord1c.emailsrvr.com [108.166.43.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFD312001B for ; Sun, 12 Jan 2020 09:37:32 -0800 (PST) X-Auth-ID: fluffy@iii.ca Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0443AA00F9; Sun, 12 Jan 2020 12:37:31 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (d75-159-246-1.abhsia.telus.net [75.159.246.1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sun, 12 Jan 2020 12:37:32 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_A54FF262-997F-4750-A0E4-9AEEC6C0DC27" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Cullen Jennings In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Date: Sun, 12 Jan 2020 10:37:31 -0700 Cc: IETF Crazy , architecture-discuss@ietf.org, iab@iab.org Message-Id: <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> To: IAB Chair X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 17:37:35 -0000 --Apple-Mail=_A54FF262-997F-4750-A0E4-9AEEC6C0DC27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 8, 2020, at 4:14 PM, IAB Chair wrote: >=20 > The IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates. Say one of my sources of income involved dead fish and does not have any = COI with work of IETF. I don=E2=80=99t think it is reasonable to expect = disclosure of that. If at some point a COI did arise from this, then I = think it would be reasonable to disclose at that time. This may just be = a bit confusing on how to I should read =E2=80=9Cmain=E2=80=9D and = =E2=80=9Cother sources of incoming=E2=80=9D=20 --Apple-Mail=_A54FF262-997F-4750-A0E4-9AEEC6C0DC27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 8, 2020, at 4:14 PM, IAB Chair <iab-chair@iab.org> = wrote:

The IAB requires that all = Covered Individuals disclose their main employment, sponsorship, = consulting customer, or other sources of income when joining the IAB or = whenever there are updates.

Say one of my sources of income involved dead = fish and does not have any COI with work of IETF. I don=E2=80=99t think = it is reasonable to expect disclosure of that. If at some point a COI = did arise from this, then I think it would be reasonable to disclose at = that time. This may just be a bit confusing on how to I should read =  =E2=80=9Cmain=E2=80=9D and =E2=80=9Cother sources of = incoming=E2=80=9D 




= --Apple-Mail=_A54FF262-997F-4750-A0E4-9AEEC6C0DC27-- From nobody Sun Jan 12 10:31:35 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCDD120046; Sun, 12 Jan 2020 10:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, 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 GA2lOp3A80HE; Sun, 12 Jan 2020 10:31:33 -0800 (PST) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 E828E12001B; Sun, 12 Jan 2020 10:31:32 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id u63so2847857pjb.0; Sun, 12 Jan 2020 10:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=TM0tBlsxPcgI/1jVtS+Q/TDf6a32j6PGEDxjzYHVQOw=; b=mEGRwFJq02foFUOZ6EnYUx54iK0GSP0x5Qvc6mV/nJJ9dXn4XMnTcHWgB86y8ROlY7 /C47xJGq16glp4JCDAu5/S/JdDOUq2myUgj64ILtnK7kdUOE6LkQA5dpUvCxwsUWwIEv Culf/oL2p1zAyGJwYhWWfeWhgqJfdbA7ekXI66Hfd4YgBX47lCAmGtUgDYz3YcsR9B8H AC3N1XrAIN/LESLEKOjdFknrrXUWWtkzo1Gd3wGrwGMIJFwzvsRV2hli1eLV126uab1u NBBc6rMJuBd2yHHKHreeqH2P44aroLB9Fj+YJF8+CfyJEKnE4Db6+mrw2mGy/zfJuR+K W/ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=TM0tBlsxPcgI/1jVtS+Q/TDf6a32j6PGEDxjzYHVQOw=; b=coHUisl2JZGQh7szaS+VxJCm+LErBoXaIXiMiHjIj2cfgOT9YYmk6P2YXAbIvEHK7S 6CwUEMqdE0+9bldfmJMpkHZV7TiTvB8yPUIl38gzn9hNy2invV6ms++S5XIGFPRLHMuK T0T9yGPMnx+FuNcgvmoMQEeBEchMf+ZPkRY4phwX245UpTWEO9oMA5HidAROeiZoL4M2 i/3vb7q/3Cm4VCNZsMo/BOlPZe8Op4SS3n0Bx8/DRqfXvqb5crX9EeTvxPNiIPRmtiDZ sJTq2671JPimo9u/tC8FVdRDhqPMkiwwze7s0OCg1gIrzJl9WffGPpMvKsgP+2E8rMsC 6g7w== X-Gm-Message-State: APjAAAV5Uw8FWLxE5pvZn7/HiE3X28JsnALy3xUyK4JOeV8lDKB5rzQE 3B4UVwcYqiXQE1FpPZAgAS1ZuJyP X-Google-Smtp-Source: APXvYqxiD8cAZkNT4fs3O5zK53MBPiOKrTsARqae8pXyWvlBzVylsHD66+3N9AMVIsfg+8CClMm2Vw== X-Received: by 2002:a17:902:788d:: with SMTP id q13mr10550037pll.210.1578853892257; Sun, 12 Jan 2020 10:31:32 -0800 (PST) Received: from ?IPv6:2600:380:7047:e822:4d0e:6173:5c4e:a9ab? ([2600:380:7047:e822:4d0e:6173:5c4e:a9ab]) by smtp.gmail.com with ESMTPSA id d14sm11657852pfq.117.2020.01.12.10.31.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jan 2020 10:31:31 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-36C6C27F-0354-4DFC-B198-2DE446AB9082 Content-Transfer-Encoding: 7bit From: Bernard Aboba Mime-Version: 1.0 (1.0) Date: Sun, 12 Jan 2020 10:31:30 -0800 Message-Id: References: <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> Cc: IAB Chair , iab@iab.org, IETF Crazy , architecture-discuss@ietf.org In-Reply-To: <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> To: Cullen Jennings X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 18:31:34 -0000 --Apple-Mail-36C6C27F-0354-4DFC-B198-2DE446AB9082 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Under the US Federal Advisory Committee Act (FACA) there is no general requi= rement for financial disclosure, except where it is relevant to Committee bu= siness. So if we were talking about an Internet-related committee (e.g. not f= ish and wildlife) income from =E2=80=9Cfish processing=E2=80=9D would not be= relevant so would not need to be disclosed. > On Jan 12, 2020, at 9:38 AM, Cullen Jennings wrote: >=20 > =EF=BB=BF >=20 >> On Jan 8, 2020, at 4:14 PM, IAB Chair wrote: >>=20 >> The IAB requires that all Covered Individuals disclose their main employm= ent, sponsorship, consulting customer, or other sources of income when joini= ng the IAB or whenever there are updates. >=20 > Say one of my sources of income involved dead fish and does not have any C= OI with work of IETF. I don=E2=80=99t think it is reasonable to expect discl= osure of that. If at some point a COI did arise from this, then I think it w= ould be reasonable to disclose at that time. This may just be a bit confusin= g on how to I should read =E2=80=9Cmain=E2=80=9D and =E2=80=9Cother sources= of incoming=E2=80=9D=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail-36C6C27F-0354-4DFC-B198-2DE446AB9082 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Under the US Federal Advis= ory Committee Act (FACA) there is no general requirement for financial discl= osure, except where it is relevant to Committee business. So if we were talk= ing about an Internet-related committee (e.g. not fish and wildlife) income f= rom =E2=80=9Cfish processing=E2=80=9D would not be relevant so would not nee= d to be disclosed.

On Ja= n 12, 2020, at 9:38 AM, Cullen Jennings <fluffy@iii.ca> wrote:

=
=EF=BB=BF

On Jan 8, 2020, at 4:14 PM, IAB Chair <iab-chair@iab.org> wrote:

The IAB requires that all Covered Indivi= duals disclose their main employment, sponsorship, consulting customer, or o= ther sources of income when joining the IAB or whenever there are updates.

Say one of my s= ources of income involved dead fish and does not have any COI with work of I= ETF. I don=E2=80=99t think it is reasonable to expect disclosure of that. If= at some point a COI did arise from this, then I think it would be reasonabl= e to disclose at that time. This may just be a bit confusing on how to I sho= uld read  =E2=80=9Cmain=E2=80=9D and =E2=80=9Cother sources of incoming= =E2=80=9D 



_______________________________________________=
Architecture-discuss mailing list
Architecture-dis= cuss@ietf.org
https://www.ietf.org/mailman/listinfo/architec= ture-discuss
= --Apple-Mail-36C6C27F-0354-4DFC-B198-2DE446AB9082-- From nobody Sun Jan 12 11:20:25 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C417B120044; Sun, 12 Jan 2020 11:20:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 d-WhK9GKJ4up; Sun, 12 Jan 2020 11:20:22 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 C2694120046; Sun, 12 Jan 2020 11:20:22 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id x185so3803760pfc.5; Sun, 12 Jan 2020 11:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PWwVRRPbGPN9ADVD9ua4/rOT+yBkYnq8eo3ZNPOSmGI=; b=GA3Fcf3CraadI5mtTkmdGQqN1SJpbn0xvifs8y4MRSIZFXcUKfXViEfXL1jZ1Mae9c k9S3DJbzHeCfHH4tT4lW2UVsUceNPaTdKaQ9sYdgfS80k3E0qMzs0luci2mdXOsS67BY xNG5dWF4FH/qZg3SlPDXk7Rn3s/OBlBXz7QeNvycnrH+5CQEyJV8KucMw6m2/neExFJw UzCoLxAdTN+NTAHeW60VeqoCx7qakKgA71ygYlVEQw2hJqE2JgV++HVCtwJ9wvjTQuo3 wRh3JgBczXFH6iyMlq/Zpip6inhx8t6J53xuSjkOUYhwWncitgyY+AReiSwRdPfuO2Yq SWug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PWwVRRPbGPN9ADVD9ua4/rOT+yBkYnq8eo3ZNPOSmGI=; b=fMJe1iTJVN5e84CejnhvhP5+SVtNCeM4ofhk69eF5vblmSj9VUYg1AlbYzmw950aXd vziJpIaosFGWKpuVssDsc6WRT2bexHlAf3S/XtH5B128xueD30pOd0uxYOeSj/Q9bpmc i52arxV4dten5oc8aLwBIbzG3qbb6yX3yeQM0jmWwW308cEHQyqSGLOzzlMMdoBk2ZfF vmQoG+OwHxuf/qZu9GPZcryE5x1ygw67DHgz7acwXlJukt3+IJSgu1QMfCTtwoE+7d07 Q/zCMlYOhLy5Eofb3xm7kBcKXCQNuWPyfkAwnTKevz4iz4ERvedhyUeoPb4evixJ6fzz mNZA== X-Gm-Message-State: APjAAAXB3RqwSHiEFjfLZ3HYI3o8Mi+JecO23oTkS50599sO0M2mQ7xl +E+XzkmnV5wKekrmgNYulouwyEXD X-Google-Smtp-Source: APXvYqyJUusl6YuofC9xkcNMTe7/KYoElLoo2yB1uoffrJeuoBV8g6cSw8NxMf8RComs2aU+21lD/A== X-Received: by 2002:a63:6c09:: with SMTP id h9mr16863821pgc.34.1578856821969; Sun, 12 Jan 2020 11:20:21 -0800 (PST) Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id e9sm10655700pgn.49.2020.01.12.11.20.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jan 2020 11:20:21 -0800 (PST) To: Cullen Jennings , IAB Chair Cc: iab@iab.org, IETF Crazy , architecture-discuss@ietf.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> From: Brian E Carpenter Message-ID: Date: Mon, 13 Jan 2020 08:20:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 19:20:25 -0000 On 13-Jan-20 06:37, Cullen Jennings wrote: >=20 >=20 >> On Jan 8, 2020, at 4:14 PM, IAB Chair > wrote: >> >> The IAB requires that all Covered Individuals disclose their main empl= oyment, sponsorship, consulting customer, or other sources of income when= joining the IAB or whenever there are updates. >=20 > Say one of my sources of income involved dead fish and does not have an= y COI with work of IETF. I don=E2=80=99t think it is reasonable to expect= disclosure of that. If at some point a COI did arise from this, then I t= hink it would be reasonable to disclose at that time. This may just be a = bit confusing on how to I should read =C2=A0=E2=80=9Cmain=E2=80=9D and =E2= =80=9Cother sources of incoming=E2=80=9D=C2=A0 If the IAB signed contracts or employed people, that question might even = be worth discussion. As it is, I think this whole discussion is massive o= verkill and possibly exposes IAB members to new risk. As long as IETF LLC= , which actually executes contracts and pays staff, has an adequate COI p= olicy, I think we are fine as we are. BCP 39 makes it fairly clear that the IAB does not need a separate COI po= licy. This text was inserted on legal advice from Jorge Contreras, as the= IETF's pro bono counsel at the time, who said it was intended to 'protec= t IAB members from personal liability for IAB decisions (particularly in = view of the last paragraph, stating that they serve as "individuals")': > Members of the IAB shall serve as individuals, and not as > representatives of any company, agency, or other organization. > Members of the IAB shall owe no fiduciary duty of loyalty or care to= > IAB, IETF, IRTF or IESG. The last sentence in particular seems to make a formal COI policy unneces= sary and possibly harmful. Wouldn't such a policy nullify that protection= that IAB members have had since May 2000? Can we see the legal advice that led to the current proposal? Regards and IANAL, Brian From nobody Sun Jan 12 12:29:01 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5B912006D for ; Sun, 12 Jan 2020 12:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 R3qa23TtdLhp for ; Sun, 12 Jan 2020 12:28:57 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 C0A8712006F for ; Sun, 12 Jan 2020 12:28:56 -0800 (PST) Received: from xse476.mail2web.com ([66.113.197.222] helo=xse.mail2web.com) by mx61.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iqjqf-0007Y2-Ax for architecture-discuss@ietf.org; Sun, 12 Jan 2020 21:28:52 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 47wpFm2R9zz1kkR for ; Sun, 12 Jan 2020 12:28:28 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iqjqW-0000PY-7T for architecture-discuss@ietf.org; Sun, 12 Jan 2020 12:28:28 -0800 Received: (qmail 29712 invoked from network); 12 Jan 2020 20:28:27 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Jan 2020 20:28:27 -0000 To: Brian E Carpenter , Cullen Jennings , IAB Chair Cc: iab@iab.org, IETF Crazy , architecture-discuss@ietf.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <2f9704f7-60e2-7894-46df-72a26c2f21fd@huitema.net> Date: Sun, 12 Jan 2020 10:28:25 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------73315C047853C911CC97B2D7" Content-Language: en-US X-Originating-IP: 66.113.197.222 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0c2Pj46HODYmpAMVAv0J1pOpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX7YpnlShaQoNiK1N4Q+fTxqlO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PuWgeIrczWdOwnaj/ijHxo0EwGrNHnZgdqv8gUap0GPVqOo0r3 6TvtZGZKJo7Ywel+UOUPX0VHiKUyAtskn6r56i8KMZYGrZmgW9KwYivcW5A61Ks3CiInn/dDFS2W PS2yGYffiENaEvSwZ91SD/eSc+7o0ZSfcEjJYb2rnSV2fRCARv6mkfvK/UihTJjyS3/OdDr2WLJq FULjiIcCiyuiCgTQeC2dL1Bxyk8yV+29SYS0kEOL0o9EBIpturfzKMtFD1+RO9x9UH6x/+ZJK1fw q9G5tr1naPLrD+uYvNqtQnWYBq6S+OMHcfXl6o0I271KKTjECb0PwpN4olPuA0AI937kIM09yvSV B0zYhsH8AJsJUcR4Jn7GeElVrOvBLg6zUcHvWdIJk341Nqr9aUhF8I+I72mtxWGlsUlL26CSJwyN VoTJPnv++/plQC3PshnYfINnxlPOnErMIpfpA3rVH7bWyx3TYYlKtowRLzFS5WeBk4QknL1NHAiI h0kG5nFSaACXNRISCVggyzW2LS/7U9bP2MaWF1k3be8N1C1x76Zz1ePYrSnQ3xeKcIJB0CWX5Y8S skiIwYo93Yp+364MkVz1pRXWhjh9fdbl44I0Df0U2mEy1I/0RYXJ690JLXHYFU0SicLCEVSiBpZ3 g7Sp8dbxIx8r0tkGYkfgGWL38RL2RSrvmTNpgdQqU4ccmgaW3jR5NeVaJQBh0uawl0Cg8gkFJY4U lg4VofOxwUi4TVKOKogdFzFUBtke4lHzswE2heUd4UCZPAsMlEWCkNGHtIkd2x35zAiBFPp64JaI ysCWp33KKvSLEepfzmW/VTBD X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 20:29:00 -0000 This is a multi-part message in MIME format. --------------73315C047853C911CC97B2D7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/12/2020 9:20 AM, Brian E Carpenter wrote: > BCP 39 makes it fairly clear that the IAB does not need a separate COI = policy. This text was inserted on legal advice from Jorge Contreras, as t= he IETF's pro bono counsel at the time, who said it was intended to 'prot= ect IAB members from personal liability for IAB decisions (particularly i= n view of the last paragraph, stating that they serve as "individuals")':= > >> Members of the IAB shall serve as individuals, and not as >> representatives of any company, agency, or other organization. >> Members of the IAB shall owe no fiduciary duty of loyalty or care t= o >> IAB, IETF, IRTF or IESG. > The last sentence in particular seems to make a formal COI policy unnec= essary and possibly harmful. Wouldn't such a policy nullify that protecti= on that IAB members have had since May 2000? Brian, it is not obvious that this paragraph in RFC2850/BCP39 implies that "a formal COI policy is unnecessary and possibly harmful". I understand why you would say that, but it requires some level of reading between the lines. You are implicitly suggesting that the current attempt at writing a COI policy for the IAB be scrapped. That may well be very good advice. After all, we might say that what is expected from members of the IAB is exactly the same as what is expected from participants in the IETF in general. But, however well founded that advice may be, we will need some more explanation. > Can we see the legal advice that led to the current proposal? Similarly, if the text in RFC 2850 comes from past debates in the IAB, can you point us to the minutes of these debates? -- Christian Huitema --------------73315C047853C911CC97B2D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 1/12/2020 9:20 AM, Brian E Carpenter wrote:
BCP 39 makes it fairly clear that the IAB does not need a separate COI policy. This text was inserted on legal advice from Jorge Contreras, as the IETF's pro bono counsel at the time, who said it was intended to 'protect IAB members from personal liability for IAB decisions (particularly in view of the last paragraph, stating that they serve as "individuals")':


   Members of the IAB shall serve as individuals, and not as
   representatives of any company, agency, or other organization.
   Members of the IAB shall owe no fiduciary duty of loyalty or care to
   IAB, IETF, IRTF or IESG.

The last sentence in particular seems to make a formal COI policy unnecessary and possibly harmful. Wouldn't such a policy nullify that protection that IAB members have had since May 2000?

Brian, it is not obvious that this paragraph in RFC2850/BCP39 implies that "a formal COI policy is unnecessary and possibly harmful". I understand why you would say that, but it requires some level of reading between the lines.

You are implicitly suggesting that the current attempt at writing a COI policy for the IAB be scrapped. That may well be very good advice. After all, we might say that what is expected from members of the IAB is exactly the same as what is expected from participants in the IETF in general. But, however well founded that advice may be, we will need some more explanation.

Can we see the legal advice that led to the current proposal?

Similarly, if the text in RFC 2850 comes from past debates in the IAB, can you point us to the minutes of these debates?

-- Christian Huitema

--------------73315C047853C911CC97B2D7-- From nobody Sun Jan 12 14:06:27 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8902212081F; Sun, 12 Jan 2020 14:06: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 z3FgexXnTNLe; Sun, 12 Jan 2020 14:06:15 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 2BA3812082E; Sun, 12 Jan 2020 14:06:11 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id 2so3896459pfg.12; Sun, 12 Jan 2020 14:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BkM0JBNkO7ySPuj7qnClC6Ayp57nfxthGFKscsIRDDU=; b=YNXT4PvaEA6KFR0i5QV297l1k6uVaskdUToAWUdT7unq7aO8ahUssL7SDaR6Uk5fB9 nQiHvNhTOgCA9cO+MXutol6CbIKolW0ptq4+4T9ZCBMgt2bsG7t2oaGwG9aaBj2q9pYN pmBul/eOUnATEWSxvPckcOEqi9VERLNHSgLKjwIYZQBFMOh9h1/FPgg0uXGES9qXRZcK TdVbFfs2mPlXk/NY7NKK+opTwMnWhogUeSdlB/kLXDnG3N+WqnKggkVNlEYRTRKEU2jh QCORt0sNi5Gpk+2dtq9f5dXZ9LGl0xoBy0WB5pIsTB7qOVhhZRczzs9Ftx013KsmDbjG pqCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BkM0JBNkO7ySPuj7qnClC6Ayp57nfxthGFKscsIRDDU=; b=AzH2PlI2lTUryFvXqdkp+bFFVwaTpSLQO8eR652+/S+GUju2jJndf4kAMJsSlgmz9j tN2EnEJ6xtez1RR10iFLziSVcW63UcYn31YLqMiLHpK1BkvnsxRlJAUmEH6Y6WshEwTM Hm9HulNfz/XDjhfhIxK8cIrbsM9x7C3yMye0tiNlOhhhhk3ESTDmLWYvuxiNwloXhx4U wCeBXjxqlcHZzmlG+owxlEi+s3GefrGug1Ii61kYT3SC6mSf0MdZwxnX0AHr7cqNc+aw fgN+9yCjkQ1OgVA+yDQCRWxREokqPm9A55EoMhNpupasEVNoJROPP2mljLNuCWNLRRVQ 7Edg== X-Gm-Message-State: APjAAAV4GXReZcjGJ4uZZuUJHVMlQ1NUDggNyEzPGZq7eTBYiClQfbKx 54usg1UKPm1slKenH0s9WRRzC0c0 X-Google-Smtp-Source: APXvYqwRZR62VuCr4FkRBvRD3EVaTvADaV1og/wUevxh/Ly3w/1phtaDlZp2G2F2x1+CM6rYc864CQ== X-Received: by 2002:a63:211f:: with SMTP id h31mr16900867pgh.299.1578866770171; Sun, 12 Jan 2020 14:06:10 -0800 (PST) Received: from [192.168.220.65] (219-88-101-13.adsl.xtra.co.nz. [219.88.101.13]) by smtp.gmail.com with ESMTPSA id j8sm10998106pfe.182.2020.01.12.14.06.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jan 2020 14:06:09 -0800 (PST) To: Christian Huitema , Cullen Jennings , IAB Chair Cc: iab@iab.org, IETF Crazy , architecture-discuss@ietf.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> <2f9704f7-60e2-7894-46df-72a26c2f21fd@huitema.net> From: Brian E Carpenter Message-ID: Date: Mon, 13 Jan 2020 11:06:03 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2f9704f7-60e2-7894-46df-72a26c2f21fd@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 22:06:18 -0000 On 13-Jan-20 09:28, Christian Huitema wrote: > > On 1/12/2020 9:20 AM, Brian E Carpenter wrote: >> BCP 39 makes it fairly clear that the IAB does not need a separate COI policy. This text was inserted on legal advice from Jorge Contreras, as the IETF's pro bono counsel at the time, who said it was intended to 'protect IAB members from personal liability for IAB decisions (particularly in view of the last paragraph, stating that they serve as "individuals")': >> >>> Members of the IAB shall serve as individuals, and not as >>> representatives of any company, agency, or other organization. >>> Members of the IAB shall owe no fiduciary duty of loyalty or care to >>> IAB, IETF, IRTF or IESG. >> The last sentence in particular seems to make a formal COI policy unnecessary and possibly harmful. Wouldn't such a policy nullify that protection that IAB members have had since May 2000? > > Brian, it is not obvious that this paragraph in RFC2850/BCP39 implies that "a formal COI policy is unnecessary and possibly harmful". I understand why you would say that, but it requires some level of reading between the lines. > > You are implicitly suggesting that the current attempt at writing a COI policy for the IAB be scrapped. That may well be very good advice. After all, we might say that what is expected from members of the IAB is exactly the same as what is expected from participants in the IETF in general. But, however well founded that advice may be, we will need some more explanation. Exactly why I asked about legal advice. The *ethical* aspect is probably not contentious, and is indeed right there in the charter already. > >> Can we see the legal advice that led to the current proposal? > > Similarly, if the text in RFC 2850 comes from past debates in the IAB, can you point us to the minutes of these debates? I'm on travel, so I can't easily search the archives, but it would have been late 1999 or early 2000. I did quote verbatim Jorge's comment from my own email archive, and I doubt if any of us would have gone against his advice in those days. Brian From nobody Mon Jan 13 06:32:06 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CA41200D6 for ; Mon, 13 Jan 2020 06:32: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrHegKlREsG8 for ; Mon, 13 Jan 2020 06:32:03 -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 E1A94120072 for ; Mon, 13 Jan 2020 06:32:02 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 3D3D728011B; Mon, 13 Jan 2020 15:32:00 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 36ADD2802D6; Mon, 13 Jan 2020 15:32:00 +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 2EB8C28011B; Mon, 13 Jan 2020 15:32:00 +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 27B38663E720; Mon, 13 Jan 2020 15:32:00 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 1F3B8433B4; Mon, 13 Jan 2020 15:32:00 +0100 (CET) Date: Mon, 13 Jan 2020 15:32:00 +0100 From: Stephane Bortzmeyer To: Dan York Cc: Lucy Lynch , "architecture-discuss@iab.org" Message-ID: <20200113143200.GA7767@nic.fr> References: <7020A5C7-6D06-4D6B-85DD-3FCE9CFC03C7@isoc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7020A5C7-6D06-4D6B-85DD-3FCE9CFC03C7@isoc.org> X-Operating-System: Debian GNU/Linux 10.2 X-Kernel: Linux 4.19.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.000167, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 14:32:04 -0000 On Wed, Jan 01, 2020 at 06:44:21PM +0000, Dan York wrote a message of 480 lines which said: > For example, at Amazon’s recent re:Invent conference they promoted a > way to directly connect enterprise data centers to Amazon’s global > AWS network (“Outposts”) and also a way to connect telco > points-of-presence to Amazon’s network (“Wavelength”). My > understanding is that Microsoft has similar functionality for Azure > (“Stack”, I believe) and Google either has or is working on > something similar for their Google Cloud Platform. Similarly, large > entities such as Facebook and Netflix have built their own global, > private networks that interconnect to local data centers (where > those data centers are also connected to the public Internet). Some people here are probably aware of it, but I think it is an opportunity to mention Geoff Huston's articles about the "death of transit" . I don't agree with him but these articles seem relevant for this specific part of the discussion. From nobody Mon Jan 13 07:37:52 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5A81200F1 for ; Mon, 13 Jan 2020 07:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOx7B3TKo-zu for ; Mon, 13 Jan 2020 07:37:49 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D146A120033 for ; Mon, 13 Jan 2020 07:37:48 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D01D4548043; Mon, 13 Jan 2020 16:37:41 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C541B440059; Mon, 13 Jan 2020 16:37:41 +0100 (CET) Date: Mon, 13 Jan 2020 16:37:41 +0100 From: Toerless Eckert To: Lucy Lynch Cc: Stephen Farrell , architecture-discuss@iab.org Message-ID: <20200113153741.GH14549@faui48f.informatik.uni-erlangen.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 15:37:51 -0000 On Tue, Dec 31, 2019 at 07:27:17PM +0000, Lucy Lynch wrote: > As an example - an Internet optimized for the web may not be the same > internet that supports real time data collection and shared computation in > the context of big science. How do we avoid closing out capabilities as we > optimize for others? Narrowing of choices looks like a path to a limited and > more brittle model to me. Indeed. With the new unique value propositions of new applications like mobile phones and video streaming, the network layer quality and availability acceptable to users deteriorated quite a bit over pre-IP solutions. There was a lot of growth of more network service reliability/quality demanding applications, but it all happened in vertical industries and mostly private networks and is IMHO still heavily discriminated against by the way the IETF operates. The IETF only has "Internet best (lousy) effort" as the gold standard: Every new standard is forced to argue how it would behave well if unintentionally leaking onto the BE Internet, no new standard is harrassed to support better quality/reliability network layer services (IntServ, DiffServ, DetNet, etc. pp). To me, this is really like asking new transportation standards to explain how they are compatible with horse manure because horses are still the golden standard for transportation. So we continuously reinforce this historic lowest common denominator and do not encourage really systematically the value proposition of better quality/resilience network infrastructures. Toerless From nobody Mon Jan 13 07:47:38 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6EC12011F; Mon, 13 Jan 2020 07:47:36 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOKT7Vt3kaoJ; Mon, 13 Jan 2020 07:47:32 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4728D12010C; Mon, 13 Jan 2020 07:47:32 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id p125so8625070oif.10; Mon, 13 Jan 2020 07:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iI6HbzmDJ6xVCMyHCx9D6DsV++R1dNYdMgBZPxpg8Ns=; b=HIxVwNvzgGlZa0M+/iDruxymADMqeVgdSVg5vA+Gfl5CbM3T9SReR8k4UXPC5gkjay zF0slP6Z60ybfj41zgjiAxAYq2RReztD8mSmryXC6ywamhIM54D8Yk9srtMqq5dUAFcY SFJeGjh2zMmqoF4VTBMCWdGTHx2BopVhS2e2obQtx/WBw6F2NqRvwQ58qm+/g+miV96n 1FX3f6F+eAb+hSIGRMY2H8V58TOfC91hIUmTvrkaLD/JAlH8lotCYbUoKUtJyLlGbMF4 7yFQELcJL+nTEqoO2UyUTYy9cDY/5FHJdrn3f7a8m1qOFOXXc3ilWn2y/esOBNJ6uGFG KI5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iI6HbzmDJ6xVCMyHCx9D6DsV++R1dNYdMgBZPxpg8Ns=; b=h8HnvPw1d0Frff3NakHwxtTkrqGyDdJBeCS3FopV66sjRZFhTvWpAeDTza26YHkZmg R7oocbWeKA/K1e4Cw265YKl6Zpg6l7l08VTvEDWtQaXI10m3Cz4JQ4qF6rUWnmMU4YgS P4a0M+YG38pJkR7qN5+tJzPxtGQwO9LaMpSe2F4ph5mO3JRNyAmr/J0vz097JgSrFFLB Aj95TbJNb96ueMkaUjNuUpG/KQa3hvvSVvDY0tApJOtEyh4Qbiq9Aru91CvT1Q0u5GtM q1QI3Z6ERs76eWs4cKq+gp0WNYbHuWaJ8rl5fZCtSNtClzgT1+1oaPQXua00qFtfBHAE yt2Q== X-Gm-Message-State: APjAAAV4YrnyqBKMLR7njLfdphvfVzSDMym8eODZqGsLOrNIsPciu7Gg N95isfWkXBA7mgCNzX4C8DrW9uPldzM1fDwByk0= X-Google-Smtp-Source: APXvYqyGIsEQ9OxqFAGR9SNi3TO6HDZsASIE932Dy/7Zq+ezILkhh91TaYmmNsiAJJ3TkB5lLqjrxQMz/inbY4qhgaM= X-Received: by 2002:a54:468b:: with SMTP id k11mr12565033oic.134.1578930451567; Mon, 13 Jan 2020 07:47:31 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Mon, 13 Jan 2020 07:47:30 -0800 (PST) In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> <2f9704f7-60e2-7894-46df-72a26c2f21fd@huitema.net> From: Guntur Wiseno Putra Date: Mon, 13 Jan 2020 22:47:30 +0700 Message-ID: To: Brian E Carpenter Cc: Christian Huitema , Cullen Jennings , IAB Chair , "iab@iab.org" , IETF Crazy , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b0da49059c0764c7" Archived-At: Subject: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 15:47:36 -0000 --000000000000b0da49059c0764c7 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, (I am reading on "Architecture in Cyberspace":) Networks of Interests in Cyberspace, in Internet: The conflict of interest policy above attempted by IAB means an attempt for a resources management, that is about managing conflicts of interests in such a way of defining tolerances if there are those conflicts happening among "covered members" of an organizational bodies working on Internet technologies...--an attempt that is exclusive to "covered members" of an organizational body... Yet, as what was mentioned above is about the ethic, architecture comes with aesthetic considerations also: such appreciations for, with considerations on laws and principles of, beauties realized in arts: architecture in cyberscape is spatialized music. There are compositional filters made up by the intentions of the architects and perceptual capacity of the viewers. Together the aesthetic and the ethic set values, interests, of the beholders, for a liquid architecture in cyberspace: it is about places of welcomes and defences of "me"...(1) (1) Novak, Marcos, "Liquid Architecture in Cyberspace" https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf Regard, Guntur Wiseno Putra Pada Senin, 13 Januari 2020, Brian E Carpenter menulis: > On 13-Jan-20 09:28, Christian Huitema wrote: > > > > On 1/12/2020 9:20 AM, Brian E Carpenter wrote: > >> BCP 39 makes it fairly clear that the IAB does not need a separate COI > policy. This text was inserted on legal advice from Jorge Contreras, as the > IETF's pro bono counsel at the time, who said it was intended to 'protect > IAB members from personal liability for IAB decisions (particularly in view > of the last paragraph, stating that they serve as "individuals")': > >> > >>> Members of the IAB shall serve as individuals, and not as > >>> representatives of any company, agency, or other organization. > >>> Members of the IAB shall owe no fiduciary duty of loyalty or care to > >>> IAB, IETF, IRTF or IESG. > >> The last sentence in particular seems to make a formal COI policy > unnecessary and possibly harmful. Wouldn't such a policy nullify that > protection that IAB members have had since May 2000? > > > > Brian, it is not obvious that this paragraph in RFC2850/BCP39 implies > that "a formal COI policy is unnecessary and possibly harmful". I > understand why you would say that, but it requires some level of reading > between the lines. > > > > You are implicitly suggesting that the current attempt at writing a COI > policy for the IAB be scrapped. That may well be very good advice. After > all, we might say that what is expected from members of the IAB is exactly > the same as what is expected from participants in the IETF in general. But, > however well founded that advice may be, we will need some more explanation. > > Exactly why I asked about legal advice. The *ethical* aspect is probably > not contentious, and is indeed right there in the charter already. > > > > >> Can we see the legal advice that led to the current proposal? > > > > Similarly, if the text in RFC 2850 comes from past debates in the IAB, > can you point us to the minutes of these debates? > > I'm on travel, so I can't easily search the archives, but it would have > been late 1999 or early 2000. I did quote verbatim Jorge's comment from my > own email archive, and I doubt if any of us would have gone against his > advice in those days. > > Brian > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000b0da49059c0764c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

(I am reading on "Archit= ecture in Cyberspace":)


Networks of Interests in Cyberspace, in Internet:

The conflict of interest policy above attempted by IAB means an attempt for= a resources management, that is about managing conflicts of interests in s= uch a way of defining tolerances if there are those conflicts happening amo= ng "covered members" of an organizational bodies working on Inter= net technologies...--an attempt that is exclusive to "covered members&= quot; of an organizational body...

Yet, as what was mentioned above is about the ethic, architecture comes wit= h aesthetic considerations also: such appreciations for, with consideration= s on laws and principles of, beauties realized in arts: architecture in cyb= erscape is spatialized music. There are compositional filters made up by th= e intentions of the architects and perceptual capacity of the viewers. Toge= ther the aesthetic and the ethic set values, interests, of the beholders, f= or a liquid architecture in cyberspace: it is about places of welcomes and = defences of "me"...(1)


(1) Novak, Marcos, "Liquid Architecture in Cyberspace"


Regard,
Gun= tur Wiseno Putra

Pada Senin, 13 Januari 2020, Brian E Carpenter <= brian.e.ca= rpenter@gmail.com> menulis:
On 13-= Jan-20 09:28, Christian Huitema wrote:
>
> On 1/12/2020 9:20 AM, Brian E Carpenter wrote:
>> BCP 39 makes it fairly clear that the IAB does not need a separate= COI policy. This text was inserted on legal advice from Jorge Contreras, a= s the IETF's pro bono counsel at the time, who said it was intended to = 'protect IAB members from personal liability for IAB decisions (particu= larly in view of the last paragraph, stating that they serve as "indiv= iduals")':
>>
>>>=C2=A0 =C2=A0 Members of the IAB shall serve as individuals, an= d not as
>>>=C2=A0 =C2=A0 representatives of any company, agency, or other = organization.
>>>=C2=A0 =C2=A0 Members of the IAB shall owe no fiduciary duty of= loyalty or care to
>>>=C2=A0 =C2=A0 IAB, IETF, IRTF or IESG.
>> The last sentence in particular seems to make a formal COI policy = unnecessary and possibly harmful. Wouldn't such a policy nullify that p= rotection that IAB members have had since May 2000?
>
> Brian, it is not obvious that this paragraph in RFC2850/BCP39 implies = that "a formal COI policy is unnecessary and possibly harmful". I= understand why you would say that, but it requires some level of reading b= etween the lines.
>
> You are implicitly suggesting that the current attempt at writing a CO= I policy for the IAB be scrapped. That may well be very good advice. After = all, we might say that what is expected from members of the IAB is exactly = the same as what is expected from participants in the IETF in general. But,= however well founded that advice may be, we will need some more explanatio= n.

Exactly why I asked about legal advice. The *ethical* aspect is probably no= t contentious, and is indeed right there in the charter already.

>
>> Can we see the legal advice that led to the current proposal?
>
> Similarly, if the text in RFC 2850 comes from past debates in the IAB,= can you point us to the minutes of these debates?

I'm on travel, so I can't easily search the archives, but it would = have been late 1999 or early 2000. I did quote verbatim Jorge's comment= from my own email archive, and I doubt if any of us would have gone agains= t his advice in those days.

=C2=A0 =C2=A0Brian


_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--000000000000b0da49059c0764c7-- From nobody Mon Jan 13 22:48:22 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7689512006E; Mon, 13 Jan 2020 22:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 qG-EDZZeKNmt; Mon, 13 Jan 2020 22:48:17 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 30334120052; Mon, 13 Jan 2020 22:48:17 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DCD74E766399E78A8842; Tue, 14 Jan 2020 06:48:13 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 14 Jan 2020 06:48:13 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.174]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Tue, 14 Jan 2020 14:48:06 +0800 From: "Roni Even (A)" To: IAB Chair , "ietf@ietf.org" , "architecture-discuss@ietf.org" , "iab@iab.org" Thread-Topic: Draft IAB conflict of interest policy Thread-Index: AQHVxnmcMA59x5ePZEqHjbTI+oboiafpvZYQ Date: Tue, 14 Jan 2020 06:48:05 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD27D56B76@DGGEMM506-MBX.china.huawei.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.63] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD27D56B76DGGEMM506MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 06:48:21 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD27D56B76DGGEMM506MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpBZnRlciByZWFkaW5nIGNhcmVmdWxseSB0aGlzIHByb3Bvc2FsIGFuZCB0aGUgZGlzY3Vz c2lvbiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgdGhpcyBwcm9wb3NhbCBpcyB2ZXJ5IHJlYXNv bmFibGUuDQpJIGV4cGVjdCBmcm9tIHRoZSAgSUFCIG1lbWJlcnMgYW5kIGFsc28gYW55IHBlcnNv biBpbiBsZWFkZXJzaGlwIHBvc2l0aW9uIGluIHRoZSBJRVRGIHRvIGJlaGF2ZSBiYXNlZCBvbiB0 aGVzZSBndWlkZWxpbmVzLg0KSSBzZWUgdGhpcyBwcm9wb3NhbCBhcyBndWlkZWxpbmVzICwgdGhl cmUgYXJlIG5vIHBlbmFsdGllcyBmb3Igbm90IGZvbGxvd2luZyB0aGVzZSBndWlkZWxpbmVzIGFu ZCAgaXQgaXMgZ29vZC4gSSBleHBlY3QgdGhhdCBwZXJzb25zIGluIGxlYWRlcnNoaXAgcG9zaXRp b24gd2lsbCBmb2xsb3dzIHN1Y2ggQ09JIHBvbGljeSBldmVuIGlmIGl0IGlzIG5vdCB3cml0dGVu Lg0KDQpSb25pIEV2ZW4NCg0KRnJvbTogaWV0ZiBbbWFpbHRvOmlldGYtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIElBQiBDaGFpcg0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMDksIDIw MjAgMToxNSBBTQ0KVG86IGlldGZAaWV0Zi5vcmc7IGFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYu b3JnOyBpYWJAaWFiLm9yZw0KU3ViamVjdDogRHJhZnQgSUFCIGNvbmZsaWN0IG9mIGludGVyZXN0 IHBvbGljeQ0KDQoNCkRlYXIgQ29sbGVhZ3VlcywNCg0KVGhlIElBQiBpcyBjb25zaWRlcmluZyBh ZG9wdGlvbiBvZiB0aGUgY29uZmxpY3Qgb2YgaW50ZXJlc3QgcG9saWN5IGJlbG93LiAgSWYgeW91 IGhhdmUgY29tbWVudHMgb24gdGhpcyBkcmFmdCBwb2xpY3ksIHBsZWFzZSBzZW5kIHRoZW0gdG8g aWFiQGlhYi5vcmc8bWFpbHRvOmlhYkBpYWIub3JnPi4NCg0KYmVzdCByZWdhcmRzLA0KVGVkIEhh cmRpZQ0KZm9yIHRoZSBJQUINCg0KDQpJTlRFUk5FVCBBUkNISVRFQ1RVUkUgQk9BUkQgQ09ORkxJ Q1QgT0YgSU5URVJFU1QgUE9MSUNZDQoNClRoaXMgcG9saWN5IGNvdmVycyB0aGUgbm9tY29tLXNl bGVjdGVkIEludGVybmV0IEFyY2hpdGVjdHVyZSBCb2FyZCAoSUFCKSBtZW1iZXJzIGFuZCBleC1v ZmZpY2lvIG1lbWJlcnMgKGNvbGxlY3RpdmVseSwg4oCcQ292ZXJlZCBJbmRpdmlkdWFsc+KAnSku IFRoaXMgcG9saWN5IGhhcyBubyBpbXBhY3Qgb24gYW55IG90aGVyIHBhcnRpY2lwYW50cyBpbiBJ QUIgYWN0aXZpdGllcywgZm9yIGluc3RhbmNlIGxpYWlzb25zIHRvIGFuZCBmcm9tIHRoZSBJQUIg b3IgSUFCIHByb2dyYW0gbWVtYmVycy4NCg0KSW4gY2Fycnlpbmcgb3V0IHRoZWlyIElBQiByb2xl LCBDb3ZlcmVkIEluZGl2aWR1YWxzIG11c3QgYWN0IGluIHRoZSBiZXN0IGludGVyZXN0IG9mIHRo ZSBJbnRlcm5ldCBjb21tdW5pdHkuIE9jY2FzaW9uYWxseSB0aGlzIGR1dHkgbWF5IGJl4oCUb3Ig bWF5IGFwcGVhciB0byBiZeKAlGluY29tcGF0aWJsZSBvciBpbiBjb25mbGljdCB3aXRoIGEgQ292 ZXJlZCBJbmRpdmlkdWFs4oCZcyBwZXJzb25hbCBpbnRlcmVzdHMgKGluY2x1ZGluZyBpbnRlcmVz dHMgb2YgdGhlaXIgZmFtaWx5IG1lbWJlcnMpLCBvciB0aGUgaW50ZXJlc3RzIG9mIGFuIG9yZ2Fu aXphdGlvbiBvZiB3aGljaCB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsIGlzIGFuIGVtcGxveWVlLCBk aXJlY3Rvciwgb3duZXIsIG9yIG90aGVyd2lzZSBoYXMgYnVzaW5lc3Mgb3IgZmluYW5jaWFsIGlu dGVyZXN0LiBJZiBhIENvdmVyZWQgSW5kaXZpZHVhbCBoYXMgYSBjb25mbGljdCBvZiBpbnRlcmVz dCBmb3Igd2hhdGV2ZXIgcmVhc29uLCB0aGF0IGluZGl2aWR1YWwgbXVzdCBhdm9pZCBwYXJ0aWNp cGF0aW5nIGluIHRoZSB3b3JrIG9mIHRoZSBJQUIgdGhhdCB0b3VjaGVzIG9uIHRoZSByZWxhdGVk IG1hdHRlci4NCg0KVGhlIElBQiBkb2VzIG5vdCBkaXJlY3RseSBkZWFsIHdpdGggbWF0dGVycyBy ZWxhdGluZyB0byBjb250cmFjdHMgb3IgZmluYW5jZS4gVGhlIElBQiBkb2VzLCBob3dldmVyLCBo YXZlIGEgcm9sZSBpbiBwZXJzb25uZWwgZGVjaXNpb25zLCBhbmQgaXRzIGRlY2lzaW9ucyBhbmQg b3V0cHV0cyBoYXZlIGEgcG90ZW50aWFsIHRvIGluZGlyZWN0bHkgYWZmZWN0IGNvbnRyYWN0cyB3 aXRoaW4gdGhlIElFVEYgc3lzdGVtLiBJQUIncyB0ZWNobmljYWwgZGVjaXNpb25zIGFuZCBvdXRw dXRzIGhhdmUgYWxzbyBhIHBvdGVudGlhbCB0byBpbXBhY3QgYm90aCB3b3JrIGVsc2V3aGVyZSBp biB0aGUgSUVURiBhbmQgYnVzaW5lc3NlcyB0aGF0IGVtcGxveSBvciBkZXZlbG9wIEludGVybmV0 IHRlY2hub2xvZ3kuDQoNCkNvdmVyZWQgSW5kaXZpZHVhbHMgc2hhbGwgbm90IHVzZSB0aGUgSUFC 4oCZcyByZXNvdXJjZXMgb3IgZGVjaXNpb25zIGFzIGEgbWVhbnMgZm9yIHBlcnNvbmFsIG9yIHRo aXJkLXBhcnR5IGdhaW4uDQoNCkRpc2Nsb3N1cmUgb2YgQWN0dWFsIG9yIFBvdGVudGlhbCBDb25m bGljdHMNCg0KVGhlIElBQiByZXF1aXJlcyB0aGF0IGFsbCBDb3ZlcmVkIEluZGl2aWR1YWxzIGRp c2Nsb3NlIHRoZWlyIG1haW4gZW1wbG95bWVudCwgc3BvbnNvcnNoaXAsIGNvbnN1bHRpbmcgY3Vz dG9tZXIsIG9yIG90aGVyIHNvdXJjZXMgb2YgaW5jb21lIHdoZW4gam9pbmluZyB0aGUgSUFCIG9y IHdoZW5ldmVyIHRoZXJlIGFyZSB1cGRhdGVzLg0KDQpJbiBhZGRpdGlvbiwgd2hlbiBhIHRvcGlj IGlzIGRpc2N1c3NlZCBhdCB0aGUgSUFCLCB0aGUgQ292ZXJlZCBJbmRpdmlkdWFscyBhcmUgcmVx dWlyZWQgdG8gcHJvbXB0bHkgZGlzY2xvc2UgaWYgdGhhdCB0b3BpYyBjb25zdGl0dXRlcyBhIHBl cmNlaXZlZCBvciBwb3RlbnRpYWwgY29uZmxpY3Qgb2YgaW50ZXJlc3QuIE9uY2UgZGlzY2xvc2Vk LCBDb3ZlcmVkIEluZGl2aWR1YWxzIG1heSByZWN1c2UgZnJvbSBwYXJ0aWNpcGF0aW9uIGluIGRp c2N1c3Npb25zIG9yIGRlY2lzaW9ucyBhdCB0aGVpciBkaXNjcmV0aW9uLg0KDQpUaGUgc3BlY2lm aWMgY29uZmxpY3RzIHRoYXQgbWF5IGNhdXNlIGEgcGVyY2VpdmVkIG9yIHBvdGVudGlhbCBjb25m bGljdCBvZiBpbnRlcmVzdCBhcmUgbWF0dGVycyBmb3IgaW5kaXZpZHVhbCBhbmQgSUFCIGp1ZGdt ZW50LCBidXQgZ2VuZXJhbGx5IGNvbWUgaW4gdGhlIGZvbGxvd2luZyBmb3JtczoNCg0KwrcgICAg ICBBIHBlcnNvbm5lbCBkZWNpc2lvbiByZWxhdGVzIHRvIHRoZSBDb3ZlcmVkIEluZGl2aWR1YWws IGEgY29sbGVhZ3VlIHRoYXQgdGhlIENvdmVyZWQgSW5kaXZpZHVhbCdzIHdvcmtzIGNsb3NlbHkg d2l0aCwgb3IgYSBmYW1pbHkgbWVtYmVyLiBGb3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMgcG9saWN5 LCBhICJwZXJzb24gd29ya2luZyBjbG9zZWx5IHdpdGgiIGlzIHNvbWVvbmUgd29ya2luZyBpbiB0 aGUgc2FtZSB0ZWFtIG9yIHByb2plY3QsIG9yIGEgZGlyZWN0IG1hbmFnZXIgb3IgZW1wbG95ZWUg b2YgdGhlIENvdmVyZWQgSW5kaXZpZHVhbC4gQW5kICJmYW1pbHkiIG1lYW5zIGEgc3BvdXNlLCBk b21lc3RpYyBwYXJ0bmVyLCBjaGlsZCwgc2libGluZywgcGFyZW50LCBzdGVwY2hpbGQsIHN0ZXBw YXJlbnQsIGFuZCBtb3RoZXItLCBmYXRoZXItLCBzb24tLCBkYXVnaHRlci0sIGJyb3RoZXItLCBv ciBzaXN0ZXItaW4tbGF3LCBhbmQgYW55IG90aGVyIHBlcnNvbiBsaXZpbmcgaW4gdGhlIHNhbWUg aG91c2Vob2xkLCBleGNlcHQgdGVuYW50cyBhbmQgaG91c2Vob2xkIGVtcGxveWVlcy4NCg0Kwrcg ICAgICBBIGRlY2lzaW9uIG9yIG91dHB1dCBmcm9tIHRoZSBJQUIgaW1wYWN0cyBhIGNvbnRyYWN0 IHRoYXQgdGhlIElFVEYgZW50ZXJzIGludG8gd2l0aCBhIHBhcnR5LCBhbmQgdGhhdCBwYXJ0eSBy ZWxhdGVzIHRvIHRoZSBDb3ZlcmVkIEluZGl2aWR1YWwsIGEgY29sbGVhZ3VlIHRoYXQgdGhlIENv dmVyZWQgSW5kaXZpZHVhbCdzIHdvcmtzIGNsb3NlbHkgd2l0aCwgb3IgYSBmYW1pbHkgbWVtYmVy Lg0KDQrCtyAgICAgIEFjdGl2aXR5IG9uIHRoZSBJQUIgaW52b2x2ZXMgZGlzY3Vzc2lvbiBhbmQg ZGVjaXNpb25zIHJlZ2FyZGluZyB0ZWNobmljYWwgbWF0dGVycywgbWFpbmx5IHJlbGF0ZWQgdG8g SUVURiBhY3Rpdml0aWVzLiBBcyBhbiBhY3Rpdml0eSBhZGphY2VudCB0byBhIHN0YW5kYXJkaXph dGlvbiBwcm9jZXNzLCBpdCBpcyBvZnRlbiB0aGUgY2FzZSB0aGF0IENvdmVyZWQgSW5kaXZpZHVh bHMgd2lsbCBoYXZlIHNvbWUgKGZyZXF1ZW50bHkgbm9uLWZpbmFuY2lhbCkgc3Rha2UgaW4gdGhl IG91dGNvbWUgb2YgZGlzY3Vzc2lvbnMgb3IgZGVjaXNpb25zIHRoYXQgcmVsYXRlIHRvIHRlY2hu aWNhbCBtYXR0ZXJzLiBUaGlzIHBvbGljeSBkb2VzIG5vdCByZXF1aXJlIHRoYXQgQ292ZXJlZCBJ bmRpdmlkdWFscyBkaXNjbG9zZSBzdWNoIGNvbmZsaWN0cyBvZiBpbnRlcmVzdCBhcyB0aGV5IHJl bGF0ZSB0byB0ZWNobmljYWwgbWF0dGVycy4gSG93ZXZlciwgQ292ZXJlZCBJbmRpdmlkdWFscyBu ZWVkIHRvIGV4ZXJjaXNlIHRoZWlyIGp1ZGdtZW50IGFuZCwgaW4gZXh0cmFvcmRpbmFyeSBjYXNl cyBiZSB3aWxsaW5nIHRvIGRpc2Nsb3NlIHBvdGVudGlhbCBvciBwZXJjZWl2ZWQgY29uZmxpY3Rz IG9mIGludGVyZXN0IGV2ZW4gYXMgdGhleSByZWxhdGUgdG8gdGVjaG5pY2FsIG1hdHRlcnMuIEZv ciBleGFtcGxlLCBpZiBhIENvdmVyZWQgSW5kaXZpZHVhbCdzIHNwb25zb3Igd2VyZSBpbiB0aGUg cHJvY2VzcyBvZiBlbnRlcmluZyBhIG5ldyBtYXJrZXQgd2hlcmUgdGhlcmUgaXMgYW4gb25nb2lu ZyBJQUIgZGlzY3Vzc2lvbiwgdGhlbiBkaXNjbG9zdXJlLCBvciBldmVuIHJlY3VzYWwsIG1pZ2h0 IGJlIGFwcHJvcHJpYXRlLCBldmVuIGlmIGRpZmZpY3VsdC4NCg0KRGlzY2xvc3VyZSBUcmFuc3Bh cmVuY3kNCg0KQSBwZXJzb24ncyByZWN1c2FsIHRvIHBhcnRpY2lwYXRlIGluIHRoZSBkaXNjdXNz aW9uIG9mIGEgdG9waWMgaXMgYWx3YXlzIG5vdGVkIGluIHRoZSBwdWJsaWMgSUFCIG1pbnV0ZXMu IEluIGFkZGl0aW9uLCB0aGUgSUFCIHdpbGwgbWFpbnRhaW4gYSByZXBvc2l0b3J5IG9mIGFsbCBn ZW5lcmFsIGRpc2Nsb3N1cmVzIG9mIGVtcGxveW1lbnQgYW5kIG90aGVyIHNwb25zb3JzaGlwLiBJ dCBpcyBleHBlY3RlZCB0aGF0IG11Y2ggb2YgdGhpcyByZXBvc2l0b3J5IGlzIHB1YmxpYywgYnV0 IHRoZXJlIGNhbiBiZSBzaXR1YXRpb25zIHdoZXJlIHNvbWUgZGlzY2xvc3VyZXMgKHN1Y2ggYXMg Y3VzdG9tZXJzIG9mIGNvbnN1bHRhbnRzKSBhcmUgcHJpdmF0ZS4NCg0KDQo8aHR0cHM6Ly9naXRo dWIuY29tL2phcmlhcmtrby9hbHRlcm5hdGUtaWFiLWNvaS1wb2xpY3kvYmxvYi9tYXN0ZXIvY29p LXBvbGljeS5tZCNzdGF0dXM+DQoNCg0K --_000_6E58094ECC8D8344914996DAD28F1CCD27D56B76DGGEMM506MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmgxDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1z by1zdHlsZS1saW5rOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjI0LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KaDMNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5oYg0K CXttc28tc3R5bGUtbmFtZTpoYjt9DQpzcGFuLmcyDQoJe21zby1zdHlsZS1uYW1lOmcyO30NCnNw YW4uSGVhZGluZzNDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDMgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyI7DQoJZm9udC1m YW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpi b2xkO30NCnNwYW4uSGVhZGluZzFDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDEgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSI7 DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzM2NUY5MTsNCglmb250 LXdlaWdodDpib2xkO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxNzQ5MDMzNjA3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMTE1 MjUzNzg2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZnRlciByZWFkaW5nIGNh cmVmdWxseSB0aGlzIHByb3Bvc2FsIGFuZCB0aGUgZGlzY3Vzc2lvbiBteSBwZXJzb25hbCB2aWV3 IGlzIHRoYXQgdGhpcyBwcm9wb3NhbCBpcyB2ZXJ5IHJlYXNvbmFibGUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgZXhwZWN0IGZyb20gdGhlICZuYnNwO0lBQiBtZW1iZXJzIGFuZCBh bHNvIGFueSBwZXJzb24gaW4gbGVhZGVyc2hpcCBwb3NpdGlvbiBpbiB0aGUgSUVURiB0byBiZWhh dmUgYmFzZWQgb24gdGhlc2UgZ3VpZGVsaW5lcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIHNlZSB0aGlzIHByb3Bvc2FsIGFzIGd1aWRlbGluZXMgLCB0aGVyZSBhcmUgbm8gcGVu YWx0aWVzIGZvciBub3QgZm9sbG93aW5nIHRoZXNlIGd1aWRlbGluZXMgYW5kICZuYnNwO2l0IGlz IGdvb2QuIEkgZXhwZWN0IHRoYXQgcGVyc29ucyBpbiBsZWFkZXJzaGlwIHBvc2l0aW9uDQogd2ls bCBmb2xsb3dzIHN1Y2ggQ09JIHBvbGljeSBldmVuIGlmIGl0IGlzIG5vdCB3cml0dGVuLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Um9uaSBFdmVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IGlldGYgW21haWx0bzppZXRmLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPklBQiBDaGFpcjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAwOSwgMjAy MCAxOjE1IEFNPGJyPg0KPGI+VG86PC9iPiBpZXRmQGlldGYub3JnOyBhcmNoaXRlY3R1cmUtZGlz Y3Vzc0BpZXRmLm9yZzsgaWFiQGlhYi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gRHJhZnQgSUFC IGNvbmZsaWN0IG9mIGludGVyZXN0IHBvbGljeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMyMjIyMjIiPkRlYXIgQ29sbGVhZ3Vlcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Zm9udC12 YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFu czogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo Og0KICAgICAgMHB4O3RleHQtZGVjb3JhdGlvbi1zdHlsZToNCiAgICAgIGluaXRpYWw7dGV4dC1k ZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5UaGUgSUFCIGlzIGNvbnNpZGVyaW5nIGFkb3B0 aW9uIG9mIHRoZSBjb25mbGljdCBvZiBpbnRlcmVzdCBwb2xpY3kgYmVsb3cuJm5ic3A7IElmIHlv dSBoYXZlIGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQgcG9saWN5LCBwbGVhc2Ugc2VuZCB0aGVtIHRv Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmlhYkBpYWIub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxMTU1Q0MiPmlhYkBpYWIub3JnPC9zcGFuPjwvYT4uPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IDI7LXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDoNCiAgICAgIDBweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6DQog ICAgICBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+YmVzdCByZWdh cmRzLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+VGVk IEhhcmRpZTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+Zm9yIHRo ZSBJQUI8YnI+DQo8L3NwYW4+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8aDM+SU5URVJO RVQgQVJDSElURUNUVVJFIEJPQVJEIENPTkZMSUNUIE9GIElOVEVSRVNUIFBPTElDWTxvOnA+PC9v OnA+PC9oMz4NCjxwPlRoaXMgcG9saWN5IGNvdmVycyB0aGUgbm9tY29tLXNlbGVjdGVkIEludGVy bmV0IEFyY2hpdGVjdHVyZSBCb2FyZCAoSUFCKSBtZW1iZXJzIGFuZCBleC1vZmZpY2lvIG1lbWJl cnMgKGNvbGxlY3RpdmVseSwg4oCcQ292ZXJlZCBJbmRpdmlkdWFsc+KAnSkuIFRoaXMgcG9saWN5 IGhhcyBubyBpbXBhY3Qgb24gYW55IG90aGVyIHBhcnRpY2lwYW50cyBpbiBJQUIgYWN0aXZpdGll cywgZm9yIGluc3RhbmNlIGxpYWlzb25zIHRvIGFuZCBmcm9tIHRoZSBJQUINCiBvciBJQUIgcHJv Z3JhbSBtZW1iZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHA+SW4gY2Fycnlpbmcgb3V0IHRoZWlyIElB QiByb2xlLCBDb3ZlcmVkIEluZGl2aWR1YWxzIG11c3QgYWN0IGluIHRoZSBiZXN0IGludGVyZXN0 IG9mIHRoZSBJbnRlcm5ldCBjb21tdW5pdHkuIE9jY2FzaW9uYWxseSB0aGlzIGR1dHkgbWF5IGJl 4oCUb3IgbWF5IGFwcGVhciB0byBiZeKAlGluY29tcGF0aWJsZSBvciBpbiBjb25mbGljdCB3aXRo IGEgQ292ZXJlZCBJbmRpdmlkdWFs4oCZcyBwZXJzb25hbCBpbnRlcmVzdHMgKGluY2x1ZGluZyBp bnRlcmVzdHMNCiBvZiB0aGVpciBmYW1pbHkgbWVtYmVycyksIG9yIHRoZSBpbnRlcmVzdHMgb2Yg YW4gb3JnYW5pemF0aW9uIG9mIHdoaWNoIHRoZSBDb3ZlcmVkIEluZGl2aWR1YWwgaXMgYW4gZW1w bG95ZWUsIGRpcmVjdG9yLCBvd25lciwgb3Igb3RoZXJ3aXNlIGhhcyBidXNpbmVzcyBvciBmaW5h bmNpYWwgaW50ZXJlc3QuIElmIGEgQ292ZXJlZCBJbmRpdmlkdWFsIGhhcyBhIGNvbmZsaWN0IG9m IGludGVyZXN0IGZvciB3aGF0ZXZlciByZWFzb24sIHRoYXQgaW5kaXZpZHVhbA0KIG11c3QgYXZv aWQgcGFydGljaXBhdGluZyBpbiB0aGUgd29yayBvZiB0aGUgSUFCIHRoYXQgdG91Y2hlcyBvbiB0 aGUgcmVsYXRlZCBtYXR0ZXIuPG86cD48L286cD48L3A+DQo8cD5UaGUgSUFCIGRvZXMgbm90IGRp cmVjdGx5IGRlYWwgd2l0aCBtYXR0ZXJzIHJlbGF0aW5nIHRvIGNvbnRyYWN0cyBvciBmaW5hbmNl LiBUaGUgSUFCIGRvZXMsIGhvd2V2ZXIsIGhhdmUgYSByb2xlIGluIHBlcnNvbm5lbCBkZWNpc2lv bnMsIGFuZCBpdHMgZGVjaXNpb25zIGFuZCBvdXRwdXRzIGhhdmUgYSBwb3RlbnRpYWwgdG8gaW5k aXJlY3RseSBhZmZlY3QgY29udHJhY3RzIHdpdGhpbiB0aGUgSUVURiBzeXN0ZW0uIElBQidzIHRl Y2huaWNhbA0KIGRlY2lzaW9ucyBhbmQgb3V0cHV0cyBoYXZlIGFsc28gYSBwb3RlbnRpYWwgdG8g aW1wYWN0IGJvdGggd29yayBlbHNld2hlcmUgaW4gdGhlIElFVEYgYW5kIGJ1c2luZXNzZXMgdGhh dCBlbXBsb3kgb3IgZGV2ZWxvcCBJbnRlcm5ldCB0ZWNobm9sb2d5LjxvOnA+PC9vOnA+PC9wPg0K PHA+Q292ZXJlZCBJbmRpdmlkdWFscyBzaGFsbCBub3QgdXNlIHRoZSBJQULigJlzIHJlc291cmNl cyBvciBkZWNpc2lvbnMgYXMgYSBtZWFucyBmb3IgcGVyc29uYWwgb3IgdGhpcmQtcGFydHkgZ2Fp bi48bzpwPjwvbzpwPjwvcD4NCjxoMz5EaXNjbG9zdXJlIG9mIEFjdHVhbCBvciBQb3RlbnRpYWwg Q29uZmxpY3RzPG86cD48L286cD48L2gzPg0KPHA+VGhlIElBQiByZXF1aXJlcyB0aGF0IGFsbCBD b3ZlcmVkIEluZGl2aWR1YWxzIGRpc2Nsb3NlIHRoZWlyIG1haW4gZW1wbG95bWVudCwgc3BvbnNv cnNoaXAsIGNvbnN1bHRpbmcgY3VzdG9tZXIsIG9yIG90aGVyIHNvdXJjZXMgb2YgaW5jb21lIHdo ZW4gam9pbmluZyB0aGUgSUFCIG9yIHdoZW5ldmVyIHRoZXJlIGFyZSB1cGRhdGVzLjxvOnA+PC9v OnA+PC9wPg0KPHA+SW4gYWRkaXRpb24sIHdoZW4gYSB0b3BpYyBpcyBkaXNjdXNzZWQgYXQgdGhl IElBQiwgdGhlIENvdmVyZWQgSW5kaXZpZHVhbHMgYXJlIHJlcXVpcmVkIHRvIHByb21wdGx5IGRp c2Nsb3NlIGlmIHRoYXQgdG9waWMgY29uc3RpdHV0ZXMgYSBwZXJjZWl2ZWQgb3IgcG90ZW50aWFs IGNvbmZsaWN0IG9mIGludGVyZXN0LiBPbmNlIGRpc2Nsb3NlZCwgQ292ZXJlZCBJbmRpdmlkdWFs cyBtYXkgcmVjdXNlIGZyb20gcGFydGljaXBhdGlvbiBpbiBkaXNjdXNzaW9ucw0KIG9yIGRlY2lz aW9ucyBhdCB0aGVpciBkaXNjcmV0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlIHNwZWNpZmlj IGNvbmZsaWN0cyB0aGF0IG1heSBjYXVzZSBhIHBlcmNlaXZlZCBvciBwb3RlbnRpYWwgY29uZmxp Y3Qgb2YgaW50ZXJlc3QgYXJlIG1hdHRlcnMgZm9yIGluZGl2aWR1YWwgYW5kIElBQiBqdWRnbWVu dCwgYnV0IGdlbmVyYWxseSBjb21lIGluIHRoZSBmb2xsb3dpbmcgZm9ybXM6PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+QSBwZXJzb25uZWwgZGVjaXNpb24gcmVs YXRlcyB0byB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsLCBhIGNvbGxlYWd1ZSB0aGF0IHRoZSBDb3Zl cmVkIEluZGl2aWR1YWwncyB3b3JrcyBjbG9zZWx5IHdpdGgsIG9yIGEgZmFtaWx5IG1lbWJlci4g Rm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlzIHBvbGljeSwgYSAmcXVvdDtwZXJzb24gd29ya2luZyBj bG9zZWx5IHdpdGgmcXVvdDsNCiBpcyBzb21lb25lIHdvcmtpbmcgaW4gdGhlIHNhbWUgdGVhbSBv ciBwcm9qZWN0LCBvciBhIGRpcmVjdCBtYW5hZ2VyIG9yIGVtcGxveWVlIG9mIHRoZSBDb3ZlcmVk IEluZGl2aWR1YWwuIEFuZCAmcXVvdDtmYW1pbHkmcXVvdDsgbWVhbnMgYSBzcG91c2UsIGRvbWVz dGljIHBhcnRuZXIsIGNoaWxkLCBzaWJsaW5nLCBwYXJlbnQsIHN0ZXBjaGlsZCwgc3RlcHBhcmVu dCwgYW5kIG1vdGhlci0sIGZhdGhlci0sIHNvbi0sIGRhdWdodGVyLSwgYnJvdGhlci0sIG9yIHNp c3Rlci1pbi1sYXcsDQogYW5kIGFueSBvdGhlciBwZXJzb24gbGl2aW5nIGluIHRoZSBzYW1lIGhv dXNlaG9sZCwgZXhjZXB0IHRlbmFudHMgYW5kIGhvdXNlaG9sZCBlbXBsb3llZXMuPG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+QSBkZWNpc2lvbiBvciBvdXRwdXQg ZnJvbSB0aGUgSUFCIGltcGFjdHMgYSBjb250cmFjdCB0aGF0IHRoZSBJRVRGIGVudGVycyBpbnRv IHdpdGggYSBwYXJ0eSwgYW5kIHRoYXQgcGFydHkgcmVsYXRlcyB0byB0aGUgQ292ZXJlZCBJbmRp dmlkdWFsLCBhIGNvbGxlYWd1ZSB0aGF0IHRoZSBDb3ZlcmVkIEluZGl2aWR1YWwncyB3b3JrcyBj bG9zZWx5IHdpdGgsDQogb3IgYSBmYW1pbHkgbWVtYmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBkaXI9IkxUUiI+PC9zcGFuPkFjdGl2aXR5IG9uIHRoZSBJQUIgaW52b2x2ZXMgZGlzY3Vz c2lvbiBhbmQgZGVjaXNpb25zIHJlZ2FyZGluZyB0ZWNobmljYWwgbWF0dGVycywgbWFpbmx5IHJl bGF0ZWQgdG8gSUVURiBhY3Rpdml0aWVzLiBBcyBhbiBhY3Rpdml0eSBhZGphY2VudCB0byBhIHN0 YW5kYXJkaXphdGlvbiBwcm9jZXNzLCBpdCBpcyBvZnRlbiB0aGUgY2FzZSB0aGF0IENvdmVyZWQN CiBJbmRpdmlkdWFscyB3aWxsIGhhdmUgc29tZSAoZnJlcXVlbnRseSBub24tZmluYW5jaWFsKSBz dGFrZSBpbiB0aGUgb3V0Y29tZSBvZiBkaXNjdXNzaW9ucyBvciBkZWNpc2lvbnMgdGhhdCByZWxh dGUgdG8gdGVjaG5pY2FsIG1hdHRlcnMuIFRoaXMgcG9saWN5IGRvZXMgbm90IHJlcXVpcmUgdGhh dCBDb3ZlcmVkIEluZGl2aWR1YWxzIGRpc2Nsb3NlIHN1Y2ggY29uZmxpY3RzIG9mIGludGVyZXN0 IGFzIHRoZXkgcmVsYXRlIHRvIHRlY2huaWNhbCBtYXR0ZXJzLg0KIEhvd2V2ZXIsIENvdmVyZWQg SW5kaXZpZHVhbHMgbmVlZCB0byBleGVyY2lzZSB0aGVpciBqdWRnbWVudCBhbmQsIGluIGV4dHJh b3JkaW5hcnkgY2FzZXMgYmUgd2lsbGluZyB0byBkaXNjbG9zZSBwb3RlbnRpYWwgb3IgcGVyY2Vp dmVkIGNvbmZsaWN0cyBvZiBpbnRlcmVzdCBldmVuIGFzIHRoZXkgcmVsYXRlIHRvIHRlY2huaWNh bCBtYXR0ZXJzLiBGb3IgZXhhbXBsZSwgaWYgYSBDb3ZlcmVkIEluZGl2aWR1YWwncyBzcG9uc29y IHdlcmUgaW4gdGhlDQogcHJvY2VzcyBvZiBlbnRlcmluZyBhIG5ldyBtYXJrZXQgd2hlcmUgdGhl cmUgaXMgYW4gb25nb2luZyBJQUIgZGlzY3Vzc2lvbiwgdGhlbiBkaXNjbG9zdXJlLCBvciBldmVu IHJlY3VzYWwsIG1pZ2h0IGJlIGFwcHJvcHJpYXRlLCBldmVuIGlmIGRpZmZpY3VsdC48bzpwPjwv bzpwPjwvcD4NCjxoMz5EaXNjbG9zdXJlIFRyYW5zcGFyZW5jeTxvOnA+PC9vOnA+PC9oMz4NCjxw PkEgcGVyc29uJ3MgcmVjdXNhbCB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGlzY3Vzc2lvbiBvZiBh IHRvcGljIGlzIGFsd2F5cyBub3RlZCBpbiB0aGUgcHVibGljIElBQiBtaW51dGVzLiBJbiBhZGRp dGlvbiwgdGhlIElBQiB3aWxsIG1haW50YWluIGEgcmVwb3NpdG9yeSBvZiBhbGwgZ2VuZXJhbCBk aXNjbG9zdXJlcyBvZiBlbXBsb3ltZW50IGFuZCBvdGhlciBzcG9uc29yc2hpcC4gSXQgaXMgZXhw ZWN0ZWQgdGhhdCBtdWNoIG9mIHRoaXMgcmVwb3NpdG9yeQ0KIGlzIHB1YmxpYywgYnV0IHRoZXJl IGNhbiBiZSBzaXR1YXRpb25zIHdoZXJlIHNvbWUgZGlzY2xvc3VyZXMgKHN1Y2ggYXMgY3VzdG9t ZXJzIG9mIGNvbnN1bHRhbnRzKSBhcmUgcHJpdmF0ZS48bzpwPjwvbzpwPjwvcD4NCjxoMT48YSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vamFyaWFya2tvL2FsdGVybmF0ZS1pYWItY29pLXBvbGlj eS9ibG9iL21hc3Rlci9jb2ktcG9saWN5Lm1kI3N0YXR1cyIgaWQ9InVzZXItY29udGVudC1zdGF0 dXMiPjxicj4NCjwvYT48bzpwPjwvbzpwPjwvaDE+DQo8cD48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD27D56B76DGGEMM506MBXchi_-- From nobody Tue Jan 14 06:06:55 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1361200D7 for ; Tue, 14 Jan 2020 06:06:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=elandsys.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 og7Z92oYOwQi for ; Tue, 14 Jan 2020 06:06:47 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 229731200F3 for ; Tue, 14 Jan 2020 06:06:47 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.199.103]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00EE6KAI011625 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2020 06:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579010793; x=1579097193; i=@elandsys.com; bh=sV15PrQSBQ/6U96fQ2v3RtSZylrtbva+TVCk/88F1QA=; h=Date:To:From:Subject:In-Reply-To:References; b=cI7rKc6VBAnG++MUOWbYutjLTMdcFoA4Duc/xuwlsDvo0E7+Gh+glt/Be5sMA7wF6 GVsOM5Z3B4Hgb37TmKvkdQmuSw/Xn6cTeufRxN1MZDiJV0fO5kCM4us9NAwthP5Sg4 nNikdGicw/VpcgWxhkuB5YO7j0K00tOdGfoDZAW8= Message-Id: <6.2.5.6.2.20200114030935.0befd4d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 14 Jan 2020 04:42:56 -0800 To: Bernard Aboba , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 14:06:53 -0000 Hi Bernard, At 02:59 PM 09-01-2020, Bernard Aboba wrote: >Agree with Richard here. Much of the IAB work is technical in >nature. The IAB should therefore not need a conflict-of-interest >policy as heavy weight as that required to assume a senior role >within government, a legislature or a governmental advisory committee. I took at a look at the requirements for the IAB. From what I understand, an IAB member is expected to act at the "Board" level. There are also other desirable qualities such as experience in Internet governance. I have some experience of the former. Some situations related to conflict of interest issues can be resolved without too much difficulty as it is matter of understanding how such matters are generally managed. issues. There are pros and cons to having that in written form. For example, if a committee consists of people from very different backgrounds, the committee might view it as easier to have some (written) guidance. One of the disadvantages is that some people might be of the view that they only have to follow what is written. There are other issues I can think of. I doubt anyone on this mailing list would be interested in them. There have been a few comments about the work being technical in nature. The IAB minutes show, for example, an item which is described as a "hot topic". As it does not look directly related to engineering, I don't see how the topic could be described as being technical in nature. Is the IAB an advisory committee? That does not match some announcements, e.g. the request for feedback on the selection of an individual to a board. Regards, S. Moonesamy From nobody Tue Jan 14 16:49:32 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C80120046 for ; Tue, 14 Jan 2020 16:49:30 -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_HELO_NONE=0.001, 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 T9PMe0FcfIGR for ; Tue, 14 Jan 2020 16:49:28 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 5408B12002F for ; Tue, 14 Jan 2020 16:49:28 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id m2so9733554otq.3 for ; Tue, 14 Jan 2020 16:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cvTSX72KBbFQ1TmwtzTXDKzpP2dBN6GINgMs9j3Ub1c=; b=f3oG4LHUF4l/3R6AZJdUEvi0xaNjGmDlOQctVjieR0hBt9q3GtLmdxAzS2NlhJxygo Us3uTAdBlSl3Zscy4+BEBuOwj+pcbPnqqfNW3ZfepjGd+MZGNSYJcTajYESIU0JRr/ST +NJbsdKfzeFWsF12kaAZuEDz1HxMeCqzLPavgc+e11JZ8l7yStFj1j7wSG1oWt81/GJ5 pgujxwBVz9SMgy+06sQB6jcHn3WetNgBfT2n4f8bL/h7T+qNQIJ69947xOvTSzuJ0/np 0mvBcMjBXevSi8Yv2IAdWbclamkiS+540CQIuGCYkItTN8QkbTI6uvtteUHf+92KQYyA kiDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cvTSX72KBbFQ1TmwtzTXDKzpP2dBN6GINgMs9j3Ub1c=; b=T2uIlaoNdQJtq+Ck+yB14JndU/zSfiV2PAni9P6OPgsxw8gDVGLWugivJMkzrOwE1G KhSHv+CKganmUh0IAveP1/PkuqyWX/YKojq4MCWJN7onW60cV+z8G/EP4iyhJPXiDck4 ZH4IYsC4ge8VbQb42R7L3c/JnkV3RjtFNZ49+0W3aEWyPwrUhYgIA6jYCfHejWko5FIn NqceNY3tre7keUrvutii954knIVg2H/QTs6UISceytv0pboW5Jf7YLTnWVvu2cIqNONE rl3qahBVixF0+V81TSCt72BREqvApchAsXSs2UpSusfMa7z01mqnulWppa0e4qRV8muF Cu6Q== X-Gm-Message-State: APjAAAUSXUAsKCSq5Iap2lRXI0cFc9icKrGkT9HLfOx/TJfMbVv81OGr JNYlH8tWEimr5MF3rYsPdZnfxjsmZ52cA2YZW5w= X-Google-Smtp-Source: APXvYqxBBqt1YSm12ou4/24cXylSCpVggp/I776JWVXR7dW4CCaFoLJvaK40ec0Ft8s+pb7x2JJ5hxkSG2r3nL5KjWE= X-Received: by 2002:a9d:65da:: with SMTP id z26mr868283oth.197.1579049367638; Tue, 14 Jan 2020 16:49:27 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Tue, 14 Jan 2020 16:49:26 -0800 (PST) In-Reply-To: <6.2.5.6.2.20200114030935.0befd4d0@elandnews.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <6.2.5.6.2.20200114030935.0befd4d0@elandnews.com> From: Guntur Wiseno Putra Date: Wed, 15 Jan 2020 07:49:26 +0700 Message-ID: To: S Moonesamy Cc: Bernard Aboba , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a417f0059c23143f" Archived-At: Subject: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 00:49:30 -0000 --000000000000a417f0059c23143f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss, Analogies and contextualizations/adaptations: These works may inspire others what ara better than me --as I tried in the previous message to"read architecturally on esthetics and ethics in cyberspace, in Internet" - "Esthetique et ethique de l'environement" which was part of readings on "sustainable development": "Developmment durable, durability d'un concept". Jon Postel himself used the term "Internet environment" on RFC 791-Internet Protocol. Nathalie Blanc , =C2=AB =C3=89thique et esth=C3=A9tique de l=E2=80=99environnement. =C2=BB, = *EspacesTemps.net * [En ligne], Works, 2008 | Mis en ligne le 31 January 2008, consult=C3=A9 le 31.01.2008. URL : https://www.espacestemps.net/ en/articles/Ethique-et-esthetique-de-environnement/ ; - Section "La forme de la raison est un e(sthe)tique de l'espace" in "Le concept de toust est une forme; le pensee spatiale de Peter Sloterdijk": "Cyberspace" is a way to say about "Internet". Herv=C3=A9 Regnauld ,= =C2=AB Le concept de tout est une forme : la pens=C3=A9e spatiale de Peter Sloterdijk= . =C2=BB, *EspacesTemps.net* [En ligne], Travaux, 2011 | Mis en ligne le 2 mai 2011, consult=C3=A9 le 02.05.2011. URL : https://www.espacestemps.net/articles/le-concept-de-tout-est-une-forme-la-p= ensee-spatiale-de-peter-sloterdijk/ ; Regard, Guntur Wiseno Putra Pada Selasa, 14 Januari 2020, S Moonesamy menulis: > Hi Bernard, > At 02:59 PM 09-01-2020, Bernard Aboba wrote: > >> Agree with Richard here. Much of the IAB work is technical in nature. >> The IAB should therefore not need a conflict-of-interest policy as heavy >> weight as that required to assume a senior role within government, a >> legislature or a governmental advisory committee. >> > > I took at a look at the requirements for the IAB. From what I understand= , > an IAB member is expected to act at the "Board" level. There are also > other desirable qualities such as experience in Internet governance. I > have some experience of the former. Some situations related to conflict = of > interest issues can be resolved without too much difficulty as it is matt= er > of understanding how such matters are generally managed. issues. There a= re > pros and cons to having that in written form. For example, if a committe= e > consists of people from very different backgrounds, the committee might > view it as easier to have some (written) guidance. One of the > disadvantages is that some people might be of the view that they only hav= e > to follow what is written. There are other issues I can think of. I doub= t > anyone on this mailing list would be interested in them. > > There have been a few comments about the work being technical in nature. > The IAB minutes show, for example, an item which is described as a "hot > topic". As it does not look directly related to engineering, I don't see > how the topic could be described as being technical in nature. > > Is the IAB an advisory committee? That does not match some announcements= , > e.g. the request for feedback on the selection of an individual to a boar= d. > > Regards, > S. Moonesamy > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000a417f0059c23143f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

Analogies and contextualizati= ons/adaptations: These works may inspire others what ara better than me --a= s I tried in the previous message to"read architecturally on esthetics= and ethics in cyberspace, in Internet"

- &qu= ot;Esthetique et ethique de l'environement" which was part of read= ings on "sustainable development": "Developmment durable, du= rability d'un concept". Jon Postel himself used the term "Int= ernet environment" on RFC 791-Internet Protocol.

<= div>
Nathalie Bla= nc, =C2=AB=C2=A0=C3=89thique et esth= =C3=A9tique de l=E2=80=99environnement.=C2=A0=C2=BB,=C2=A0EspacesTemps.net<= span style=3D"color:rgb(51,51,51);font-family:verdana;font-size:11px;line-h= eight:16.5px;text-align:justify">=C2=A0[En ligne], Works, 2008 | Mis en lig= ne le 31 January 2008, consult=C3=A9 le 31.01.2008. URL : https://www.espacestemps.net/en/articles/Ethique-et= -esthetique-de-environnement/ ;

- Section "La forme de la raison est un e(sthe)tique de l'espace= " in "Le concept de toust est une forme; le pensee spatiale de Pe= ter Sloterdijk": "Cyberspace" is a way to say about "In= ternet".


<= div>Regard,
Guntur Wiseno Putra

Pada Selasa, 14 Januari 20= 20, S Moonesamy <sm+ietf@elandsys.com> menulis:
Agree with Richard here.=C2=A0 Much of the IAB work is technical in nature.= =C2=A0 The IAB should therefore not need a conflict-of-interest policy as h= eavy weight as that required to assume a senior role within government, a l= egislature or a governmental advisory committee.

I took at a look at the requirements for the IAB.=C2=A0 From what I underst= and, an IAB member is expected to act at the "Board" level.=C2=A0= There are also other desirable qualities such as experience in Internet go= vernance.=C2=A0 I have some experience of the former.=C2=A0 Some situations= related to conflict of interest issues can be resolved without too much di= fficulty as it is matter of understanding how such matters are generally ma= naged. issues.=C2=A0 There are pros and cons to having that in written form= .=C2=A0 For example, if a committee consists of people from very different = backgrounds, the committee might view it as easier to have some (written) g= uidance.=C2=A0 One of the disadvantages is that some people might be of the= view that they only have to follow what is written.=C2=A0 There are other = issues I can think of. I doubt anyone on this mailing list would be interes= ted in them.

There have been a few comments about the work being technical in nature.=C2= =A0 The IAB minutes show, for example, an item which is described as a &quo= t;hot topic".=C2=A0 As it does not look directly related to engineerin= g, I don't see how the topic could be described as being technical in n= ature.

Is the IAB an advisory committee?=C2=A0 That does not match some announceme= nts, e.g. the request for feedback on the selection of an individual to a b= oard.

Regards,
S. Moonesamy
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--000000000000a417f0059c23143f-- From nobody Tue Jan 14 17:08:30 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD57120803 for ; Tue, 14 Jan 2020 17:08:29 -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_HELO_NONE=0.001, 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 ljUdQKteTABU for ; Tue, 14 Jan 2020 17:08:27 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2DC120058 for ; Tue, 14 Jan 2020 17:08:23 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id j1so16555381lja.2 for ; Tue, 14 Jan 2020 17:08:23 -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=5bhaEB01WEI0uUHy7fD13ku6bToQgBDdWjAcB1uMh3M=; b=lk3yG0PtbhqX4iGcGTjm2hVQqgSy+xlANEdezr2Tuwae1P7Z/Zhc7barlBb+XbpL4g zEs+5EjmedvLhtm7vQIQatfwn56X6r27lo4tthdMn+RI2oztpo3q78iFFhj0zZRW/GvK z1ER2SzQnVcMDy4CMQMcK2nV15+XCnyjuzQzVJtx/BJPmhGp4ylZPHqgqDrkWxNSfDmY J73eXcTxmFNeosp2SjPBJnkM/I1GIVkl7lsFSRNrdcYE1oiD8y8pYlPXPSkMqFnBfTvF 1LF1VMVs4bYU1NiNozGD0nPj/VQ+wRyuEpyvIqPhujdaqVWdA+I7x0rYuaH3Z5a3GNFb j0tw== 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=5bhaEB01WEI0uUHy7fD13ku6bToQgBDdWjAcB1uMh3M=; b=VveLLLmEkOndDTAKQy5Z9qASC8rHnRD9eGV2/l2b0m6HPy5tSczGtXBlu+3YZVFJzn Yk+RT5LB1B+c7+19CBk+1YYkmQWW5BumZdy2D/erqd54D75jfI7EztCEMp68BUfV96bb JKHyUhiHVGvt5LgiLs/psZxYtnKZni2uwRqi02o+FJl0o9/Bq2EyTk6OiKtHcsSq/UsJ DrQoczRkcx1/i7+Qcfm1kVjX4lab9RFfznFsAf/peO5bul5vLl0nkoX0kjimmKyy7y6z /NzvCEoHZL2FdHyO6+m1Aqk+xOc9xNpeGbDu70dveFgbFqPkjWn3Y1cXfcf4tFqnvdeY 3a6A== X-Gm-Message-State: APjAAAU9JVvDDfvIofv79iWGeOQHZbC0O3hc8eHErK8XHVrZiSFaeysA gORc6eM7UNS1WJl8eG8kdJXCMr7QmxflmiK4DAY= X-Google-Smtp-Source: APXvYqzvGtJb4m7hmoaDgbpP7F1z0xtX5fSn8oFOP0S6Pn/dNDih6r6C3CiSNK8MfmKGMZpejgxJMmscliCFkD4v4tw= X-Received: by 2002:a2e:7313:: with SMTP id o19mr148628ljc.131.1579050501912; Tue, 14 Jan 2020 17:08:21 -0800 (PST) MIME-Version: 1.0 References: <20200113153741.GH14549@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200113153741.GH14549@faui48f.informatik.uni-erlangen.de> From: Spencer Dawkins at IETF Date: Wed, 15 Jan 2020 10:07:55 +0900 Message-ID: To: Toerless Eckert Cc: Lucy Lynch , architecture-discuss@iab.org Content-Type: multipart/alternative; boundary="0000000000003fbabe059c2358ac" Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 01:08:29 -0000 --0000000000003fbabe059c2358ac Content-Type: text/plain; charset="UTF-8" Replying to one point here ... On Tue, Jan 14, 2020 at 12:38 AM Toerless Eckert wrote: > On Tue, Dec 31, 2019 at 07:27:17PM +0000, Lucy Lynch wrote: > > As an example - an Internet optimized for the web may not be the same > > internet that supports real time data collection and shared computation > in > > the context of big science. How do we avoid closing out capabilities as > we > > optimize for others? Narrowing of choices looks like a path to a limited > and > > more brittle model to me. > > Indeed. With the new unique value propositions of new applications > like mobile phones and video streaming, the network layer quality and > availability acceptable to users deteriorated quite a bit over pre-IP > solutions. > > There was a lot of growth of more network service reliability/quality > demanding applications, but it all happened in vertical industries and > mostly private networks and is IMHO still heavily discriminated against > by the way the IETF operates. > > The IETF only has "Internet best (lousy) effort" as the gold standard: > Every > new standard is forced to argue how it would behave well if > unintentionally leaking onto the BE Internet, no new standard is harrassed > to support better quality/reliability network layer services (IntServ, > DiffServ, DetNet, etc. pp). > This was probably true when I joined the IESG in 2013, which seems like just yesterday in IETF timelines, but after the MPLS-in-UDP kerfluffle, the TSV ADs and RTG ADs agreed that for specifications that might not behave well on the open Internet, what we would ask was that these proposals include a description of what safety mechanisms needed to be in place if the protocol being described WAS running over the open Internet. We put together a design team to figure out what to do, and that eventually led to Transport Circuit Breakers, as in https://tools.ietf.org/html/rfc8084, also BCP 208, which built on https://tools.ietf.org/html/rfc7510#section-5, an early example of the kind of "congestion considerations" I'm talking about, and produced by that design team. I agree that this is hard, but it is possible to do better than best effort. Best, Spencer > To me, this is really like asking new transportation standards to explain > how > they are compatible with horse manure because horses are still the > golden standard for transportation. So we continuously reinforce this > historic > lowest common denominator and do not encourage really systematically > the value proposition of better quality/resilience network infrastructures. > > Toerless > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000003fbabe059c2358ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Replyin= g to one point here ...

On Tue, Jan 14, 2020 at 12:38 AM Toerless Eckert <= ;tte@cs.fau.de> w= rote:
On Tue, Dec 31, 2019 at 07:27:17PM +0000, L= ucy Lynch wrote:
> As an example - an Internet optimized for the web may not be the same<= br> > internet that supports real time data collection and shared computatio= n in
> the context of big science. How do we avoid closing out capabilities a= s we
> optimize for others? Narrowing of choices looks like a path to a limit= ed and
> more brittle model to me.

Indeed. With the new unique value propositions of new applications
like mobile phones and video streaming, the network layer quality and
availability acceptable to users deteriorated quite a bit over pre-IP
solutions.

There was a lot of growth of more network service reliability/quality
demanding applications, but it all happened in vertical industries and
mostly private networks and is IMHO still heavily discriminated against
by the way the IETF operates.

The IETF only has "Internet best (lousy) effort" as the gold stan= dard: Every
new standard is forced to argue how it would behave well if
unintentionally leaking onto the BE Internet, no new standard is harrassed<= br> to support better quality/reliability network layer services (IntServ,
DiffServ, DetNet, etc. pp).

This was p= robably true when I joined the IESG in 2013, which seems like just yesterda= y in IETF timelines, but after the MPLS-in-UDP kerfluffle, the TSV ADs and = RTG ADs agreed that for specifications that might not behave well on the op= en Internet, what we would ask was that these proposals include a descripti= on of what safety mechanisms needed to be in place if the protocol being de= scribed WAS running over the open Internet.=C2=A0

= We put together a design team to figure out what to do, and that eventually= led to Transport Circuit Breakers, as in=C2=A0https://tools.ietf.org/html/rfc8084, also BCP 208, = which built on=C2=A0https://tools.ietf.org/html/rfc7510#section-5, an early example of t= he kind of "congestion considerations" I'm talking about, and= produced by that design team.=C2=A0

I agree that = this is hard, but it is possible to do better than best effort.
<= br>
Best,

Spencer
=C2=A0
=
To me, this is really like asking new transportation stand= ards to explain how
they are compatible with horse manure because horses are still the
golden standard for transportation.=C2=A0 So we continuously reinforce this= historic
lowest common denominator and do not encourage really systematically
the value proposition of better quality/resilience network infrastructures.=

Toerless

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arch= itecture-discuss
--0000000000003fbabe059c2358ac-- From nobody Wed Jan 15 08:14:29 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9043D120111 for ; Wed, 15 Jan 2020 08:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR3ApfRXG7Km for ; Wed, 15 Jan 2020 08:13:36 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F6212009E for ; Wed, 15 Jan 2020 08:13:36 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A51D0548049; Wed, 15 Jan 2020 17:13:29 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9CEE8440059; Wed, 15 Jan 2020 17:13:29 +0100 (CET) Date: Wed, 15 Jan 2020 17:13:29 +0100 From: Toerless Eckert To: Spencer Dawkins at IETF Cc: architecture-discuss@iab.org Message-ID: <20200115161329.GQ14549@faui48f.informatik.uni-erlangen.de> References: <20200113153741.GH14549@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 16:13:40 -0000 On Wed, Jan 15, 2020 at 10:07:55AM +0900, Spencer Dawkins at IETF wrote: > This was probably true when I joined the IESG in 2013, which seems like > just yesterday in IETF timelines, but after the MPLS-in-UDP kerfluffle, the > TSV ADs and RTG ADs agreed that for specifications that might not behave > well on the open Internet, what we would ask was that these proposals > include a description of what safety mechanisms needed to be in place if > the protocol being described WAS running over the open Internet. > > We put together a design team to figure out what to do, and that eventually > led to Transport Circuit Breakers, as in https://tools.ietf.org/html/rfc8084, > also BCP 208, which built on https://tools.ietf.org/html/rfc7510#section-5, > an early example of the kind of "congestion considerations" I'm talking > about, and produced by that design team. > > I agree that this is hard, but it is possible to do better than best effort. If i may stay to me naming best effort (BE) Internet traffic as horses then i agree that this was very good work to ensure horses will not be harmed on 2030 internet highways. Alas, i can not really see what else IETF is doing for a 2030 internet higway to support anything more than horses. [rant] I really wished the IETF would wake up to the need to not only bother about horses and work more on better than BE modes of transport for those future networks. CC work is still regurgitating the "all flows are equal" mantra and "we don't define exactly what equal means", and we know forever this is not sufficient. DetNet is already a decade behind IEEE TSN without any ability to build products, IP doesn't even have all the pieces to support it (only MPLS), switched ethernets networks widely replacing IP networks in growth markets such as metropolitan networks, any form of traffic differentiation is immediately faced with more "net neutrality" misinterpretation in the IETF than encouragement to actually work on it, and the expectation of the IETF for new work to adopt itself to the historic structure of the IETF, its magically closed IAB, fine grained subdivision of work across WGs and the like is just mindboggingly unhelpful to strategic future work. [/rant] Cheers Toerless > Best, > > Spencer > > > > To me, this is really like asking new transportation standards to explain > > how > > they are compatible with horse manure because horses are still the > > golden standard for transportation. So we continuously reinforce this > > historic > > lowest common denominator and do not encourage really systematically > > the value proposition of better quality/resilience network infrastructures. > > > > Toerless > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Wed Jan 15 09:26:28 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FA91208AF for ; Wed, 15 Jan 2020 09:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsNcSzuzF9BR for ; Wed, 15 Jan 2020 09:25:34 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890211208AC for ; Wed, 15 Jan 2020 09:25:33 -0800 (PST) Received: from [10.0.0.129] (c-68-40-189-22.hsd1.mi.comcast.net [68.40.189.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 77A1D540119; Wed, 15 Jan 2020 12:25:30 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Jared Mauch In-Reply-To: <20200113143200.GA7767@nic.fr> Date: Wed, 15 Jan 2020 12:25:29 -0500 Cc: Dan York , "architecture-discuss@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: <84C97E02-CF60-4D89-A673-0887DE80CD99@puck.nether.net> References: <7020A5C7-6D06-4D6B-85DD-3FCE9CFC03C7@isoc.org> <20200113143200.GA7767@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [arch-d] possible new IAB programme on Internet resilience X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 17:25:39 -0000 > On Jan 13, 2020, at 9:32 AM, Stephane Bortzmeyer = wrote: >=20 > Some people here are probably aware of it, but I think it is an > opportunity to mention Geoff Huston's articles about the "death of > transit" > = . I > don't agree with him but these articles seem relevant for this > specific part of the discussion. I think it=E2=80=99s perhaps less about resilience and more about = diversity and some natural monopolies that will always exist. I=E2=80=99v= e always said things like =E2=80=9Cphysical access =3D root=E2=80=9D, = and the same is true with many of these things. You may not have = diversity until you reach the major aggregation points, which in my home = are either Southfield, MI or Chicago. It=E2=80=99s extremely unlikely = my packets go anywhere else due to the underlying physical topology and = costs. We have seen large volumes of data be privatized as a result, including = the network at my employer. - Jared= From nobody Wed Jan 15 14:16:53 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE6A1209F1; Wed, 15 Jan 2020 14:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCvf9s52c9Oe; Wed, 15 Jan 2020 14:16:45 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD631209E3; Wed, 15 Jan 2020 14:16:44 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 79E9154802F; Wed, 15 Jan 2020 23:16:37 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7239E440059; Wed, 15 Jan 2020 23:16:37 +0100 (CET) Date: Wed, 15 Jan 2020 23:16:37 +0100 From: Toerless Eckert To: IAB Chair Cc: ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org Message-ID: <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 22:16:46 -0000 On Wed, Jan 08, 2020 at 03:14:57PM -0800, IAB Chair wrote: [...] > Covered Individuals shall not use the IAB???s resources or decisions as a > means for personal or third-party gain. I really do not know how to judge this. I am thining about the following question to (candidate) IAB members: "Can the work of the IAB that you contribute to impact future financial results of your employer / sponsor ?" If one would answer YES, does that constitute a COI ? If not, then what would be a good reference example for the most minor COI that one should be concerned about ? Thanks Toerless > > Disclosure of Actual or Potential Conflicts > > The IAB requires that all Covered Individuals disclose their main > employment, sponsorship, consulting customer, or other sources of income > when joining the IAB or whenever there are updates. > > In addition, when a topic is discussed at the IAB, the Covered Individuals > are required to promptly disclose if that topic constitutes a perceived or > potential conflict of interest. Once disclosed, Covered Individuals may > recuse from participation in discussions or decisions at their discretion. > > The specific conflicts that may cause a perceived or potential conflict of > interest are matters for individual and IAB judgment, but generally come in > the following forms: > > * > > A personnel decision relates to the Covered Individual, a colleague > that the Covered Individual's works closely with, or a family > member. For the purposes of this policy, a "person working closely > with" is someone working in the same team or project, or a direct > manager or employee of the Covered Individual. And "family" means a > spouse, domestic partner, child, sibling, parent, stepchild, > stepparent, and mother-, father-, son-, daughter-, brother-, or > sister-in-law, and any other person living in the same household, > except tenants and household employees. > > * > > A decision or output from the IAB impacts a contract that the IETF > enters into with a party, and that party relates to the Covered > Individual, a colleague that the Covered Individual's works closely > with, or a family member. > > * > > Activity on the IAB involves discussion and decisions regarding > technical matters, mainly related to IETF activities. As an activity > adjacent to a standardization process, it is often the case that > Covered Individuals will have some (frequently non-financial) stake > in the outcome of discussions or decisions that relate to technical > matters. This policy does not require that Covered Individuals > disclose such conflicts of interest as they relate to technical > matters. However, Covered Individuals need to exercise their > judgment and, in extraordinary cases be willing to disclose > potential or perceived conflicts of interest even as they relate to > technical matters. For example, if a Covered Individual's sponsor > were in the process of entering a new market where there is an > ongoing IAB discussion, then disclosure, or even recusal, might be > appropriate, even if difficult. > > > Disclosure Transparency > > A person's recusal to participate in the discussion of a topic is always > noted in the public IAB minutes. In addition, the IAB will maintain a > repository of all general disclosures of employment and other sponsorship. > It is expected that much of this repository is public, but there can be > situations where some disclosures (such as customers of consultants) are > private. > > > > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Wed Jan 15 17:15:25 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747BE120807 for ; Wed, 15 Jan 2020 17:15:18 -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, SPF_HELO_NONE=0.001, 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=raszuk.net 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 dHkWy1fk4dz0 for ; Wed, 15 Jan 2020 17:15:15 -0800 (PST) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 6483112088C for ; Wed, 15 Jan 2020 17:15:15 -0800 (PST) Received: by mail-qv1-xf2d.google.com with SMTP id z3so8357362qvn.0 for ; Wed, 15 Jan 2020 17:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WzgQvDn++ZCcu3rcaOXx7AfjmuYYAmuMiO+RX+PgBTo=; b=JPfY/h0FPr00k2CgJwhgq0BI3WfDUWVMLPlCt16PR8nI6tX+3HagoZp3Gwy6GDpu+Z c0zkwJ0X4SlV7HZ2WZWitgnzjxJ/tV+UDpM90j9L6+ewrEscYhLSntLNCowKXbJn5tFO xB6FsOEIiq7gRBjcRvsQzu+IoNMZzaIzSgtHXOK0Y8VnjDcgKO4A2tBC7BA+eHuUVgTw xD7zxnC+k4duZ/OGALJqn/jEyzbenRk/1uj5UYjp7K77+y3eAMJ7jkQxBEZAAt8vUfQv mXusDHxE8XZuVTXtcru8prub8Q83ySzxRU4HlWU3GxVCYlo97zpg5s17pAkBXl4fhztB MQaw== 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=WzgQvDn++ZCcu3rcaOXx7AfjmuYYAmuMiO+RX+PgBTo=; b=okIUgp/RcNYOQV4HFWSJFPFw5Bq6YThdr79812/5A8TEBE1wsvCO4pJDf7oNgwNN4O HI/+Re9eJtyiOQpDZjctHpaKOLNiXxz2CSg6Vj5swZTjkmEmM6Q8YHA22xLbruU4igba gXdaFiRlYPyiNXvlYPVpjtT2yFILw5zx2x/6aB29/II3ZAfgWvd3102xouIPz4Sxx28Y HzA56LB0/PUQgU4gDYU2DcjdW1iubhj7IwC21tN6DqTtrscHCifye3v0YTkb9ZAsaFzQ ul2vHNZ7GzI0HCUTHSTJVvivMA7srQpk8yWvxd0Q108g+TLiamBrRGRljg9CZ1WvECcL ZCJg== X-Gm-Message-State: APjAAAVJLcFt41CAG7A+znbQ62XFDC5FfEf8nxTHRfBn7SJ4+OLafr7H Mab2INWw+8SuYnaIGUAcmYa9Fm8pvWWJXqH0FY9nUw== X-Google-Smtp-Source: APXvYqzLAgRpcBqiVwGJ5j+56RCmNbglXpUj8tyEAQbvIu2STVrkuDXiuwtbIOPnFznINBJGTkic/CbpGb2jvIMb7lc= X-Received: by 2002:ad4:408c:: with SMTP id l12mr227085qvp.164.1579137314409; Wed, 15 Jan 2020 17:15:14 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> From: Robert Raszuk Date: Wed, 15 Jan 2020 20:15:03 -0500 Message-ID: To: Toerless Eckert Cc: IAB Chair , iab@iab.org, ietf@ietf.org, architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000ad635d059c378eea" Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 01:15:18 -0000 --000000000000ad635d059c378eea Content-Type: text/plain; charset="UTF-8" Toerless, Considering that not that many of us are really good in predicting the future you post a pretty tough question to answer ;) Cheers, R. "Can the work of the IAB that you contribute to impact future > financial results of your employer / sponsor ?" > > If one would answer YES, does that constitute a COI ? > > If not, then what would be a good reference example for the most minor COI > that one should be concerned about ? > > Thanks > Toerless > > > > > Disclosure of Actual or Potential Conflicts > > > > The IAB requires that all Covered Individuals disclose their main > > employment, sponsorship, consulting customer, or other sources of income > > when joining the IAB or whenever there are updates. > > > > In addition, when a topic is discussed at the IAB, the Covered > Individuals > > are required to promptly disclose if that topic constitutes a perceived > or > > potential conflict of interest. Once disclosed, Covered Individuals may > > recuse from participation in discussions or decisions at their > discretion. > > > > The specific conflicts that may cause a perceived or potential conflict > of > > interest are matters for individual and IAB judgment, but generally come > in > > the following forms: > > > > * > > > > A personnel decision relates to the Covered Individual, a colleague > > that the Covered Individual's works closely with, or a family > > member. For the purposes of this policy, a "person working closely > > with" is someone working in the same team or project, or a direct > > manager or employee of the Covered Individual. And "family" means a > > spouse, domestic partner, child, sibling, parent, stepchild, > > stepparent, and mother-, father-, son-, daughter-, brother-, or > > sister-in-law, and any other person living in the same household, > > except tenants and household employees. > > > > * > > > > A decision or output from the IAB impacts a contract that the IETF > > enters into with a party, and that party relates to the Covered > > Individual, a colleague that the Covered Individual's works closely > > with, or a family member. > > > > * > > > > Activity on the IAB involves discussion and decisions regarding > > technical matters, mainly related to IETF activities. As an activity > > adjacent to a standardization process, it is often the case that > > Covered Individuals will have some (frequently non-financial) stake > > in the outcome of discussions or decisions that relate to technical > > matters. This policy does not require that Covered Individuals > > disclose such conflicts of interest as they relate to technical > > matters. However, Covered Individuals need to exercise their > > judgment and, in extraordinary cases be willing to disclose > > potential or perceived conflicts of interest even as they relate to > > technical matters. For example, if a Covered Individual's sponsor > > were in the process of entering a new market where there is an > > ongoing IAB discussion, then disclosure, or even recusal, might be > > appropriate, even if difficult. > > > > > > Disclosure Transparency > > > > A person's recusal to participate in the discussion of a topic is always > > noted in the public IAB minutes. In addition, the IAB will maintain a > > repository of all general disclosures of employment and other > sponsorship. > > It is expected that much of this repository is public, but there can be > > situations where some disclosures (such as customers of consultants) are > > private. > > > > > > > > < > https://github.com/jariarkko/alternate-iab-coi-policy/blob/master/coi-policy.md#status > > > > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > -- > --- > tte@cs.fau.de > > --000000000000ad635d059c378eea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Toerless,
<= br>
Considering that not that ma= ny of us are really good in predicting the future you post a pretty tough q= uestion to answer ;)

<= div dir=3D"ltr" class=3D"gmail_attr">Cheers,
R.

"Can the work of the IAB that you contribute = to impact future
financial results of your employer / sponsor ?"

If one would answer YES, does that constitute a COI ?

If not, then what would be a good reference example for the most minor COI =
that one should be concerned about ?

Thanks
=C2=A0 =C2=A0 Toerless

>
>=C2=A0 =C2=A0 =C2=A0 Disclosure of Actual or Potential Conflicts
>
> The IAB requires that all Covered Individuals disclose their main
> employment, sponsorship, consulting customer, or other sources of inco= me
> when joining the IAB or whenever there are updates.
>
> In addition, when a topic is discussed at the IAB, the Covered Individ= uals
> are required to promptly disclose if that topic constitutes a perceive= d or
> potential conflict of interest. Once disclosed, Covered Individuals ma= y
> recuse from participation in discussions or decisions at their discret= ion.
>
> The specific conflicts that may cause a perceived or potential conflic= t of
> interest are matters for individual and IAB judgment, but generally co= me in
> the following forms:
>
>=C2=A0 *
>
>=C2=A0 =C2=A0 A personnel decision relates to the Covered Individual, a= colleague
>=C2=A0 =C2=A0 that the Covered Individual's works closely with, or = a family
>=C2=A0 =C2=A0 member. For the purposes of this policy, a "person w= orking closely
>=C2=A0 =C2=A0 with" is someone working in the same team or project= , or a direct
>=C2=A0 =C2=A0 manager or employee of the Covered Individual. And "= family" means a
>=C2=A0 =C2=A0 spouse, domestic partner, child, sibling, parent, stepchi= ld,
>=C2=A0 =C2=A0 stepparent, and mother-, father-, son-, daughter-, brothe= r-, or
>=C2=A0 =C2=A0 sister-in-law, and any other person living in the same ho= usehold,
>=C2=A0 =C2=A0 except tenants and household employees.
>
>=C2=A0 *
>
>=C2=A0 =C2=A0 A decision or output from the IAB impacts a contract that= the IETF
>=C2=A0 =C2=A0 enters into with a party, and that party relates to the C= overed
>=C2=A0 =C2=A0 Individual, a colleague that the Covered Individual's= works closely
>=C2=A0 =C2=A0 with, or a family member.
>
>=C2=A0 *
>
>=C2=A0 =C2=A0 Activity on the IAB involves discussion and decisions reg= arding
>=C2=A0 =C2=A0 technical matters, mainly related to IETF activities. As = an activity
>=C2=A0 =C2=A0 adjacent to a standardization process, it is often the ca= se that
>=C2=A0 =C2=A0 Covered Individuals will have some (frequently non-financ= ial) stake
>=C2=A0 =C2=A0 in the outcome of discussions or decisions that relate to= technical
>=C2=A0 =C2=A0 matters. This policy does not require that Covered Indivi= duals
>=C2=A0 =C2=A0 disclose such conflicts of interest as they relate to tec= hnical
>=C2=A0 =C2=A0 matters. However, Covered Individuals need to exercise th= eir
>=C2=A0 =C2=A0 judgment and, in extraordinary cases be willing to disclo= se
>=C2=A0 =C2=A0 potential or perceived conflicts of interest even as they= relate to
>=C2=A0 =C2=A0 technical matters. For example, if a Covered Individual&#= 39;s sponsor
>=C2=A0 =C2=A0 were in the process of entering a new market where there = is an
>=C2=A0 =C2=A0 ongoing IAB discussion, then disclosure, or even recusal,= might be
>=C2=A0 =C2=A0 appropriate, even if difficult.
>
>
>=C2=A0 =C2=A0 =C2=A0 Disclosure Transparency
>
> A person's recusal to participate in the discussion of a topic is = always
> noted in the public IAB minutes. In addition, the IAB will maintain a<= br> > repository of all general disclosures of employment and other sponsors= hip.
> It is expected that much of this repository is public, but there can b= e
> situations where some disclosures (such as customers of consultants) a= re
> private.
>
>
>
>=C2=A0 <https://github.com/jariarkko/alternate-iab-coi-policy/blob/mast= er/coi-policy.md#status>
>
>

> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailm= an/listinfo/architecture-discuss


--
---
tte@c= s.fau.de

--000000000000ad635d059c378eea-- From nobody Wed Jan 15 17:16:24 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C2F120882 for ; Wed, 15 Jan 2020 17:16: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=elandsys.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 ur1zFLLeQcFt for ; Wed, 15 Jan 2020 17:16:22 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 104C712085E for ; Wed, 15 Jan 2020 17:16:22 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.166.51]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00G1FnSN015497 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jan 2020 17:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579137360; x=1579223760; i=@elandsys.com; bh=InT+MLmXQGnmrZVXBofM+UeR72z0dK5sX2dQKf3F6nA=; h=Date:To:From:Subject:In-Reply-To:References; b=4vAdSB5sEMtv05jCuOgh2hIb5+ykcG3GE+bvbI7ZGK7WG0xjWAFaeyheE1/eMafuO i3m2ZqN2VRGRkcVfgaMFKkNZ6zKFtImB4DXpl1WTV4uvpVprqDS67FAUJD1H65ju72 6RNoq1CvPJNtpdpt+UrL2ltnUbqRwLL5AGP6m5dU= Message-Id: <6.2.5.6.2.20200115161607.12cc9b50@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 15 Jan 2020 17:12:46 -0800 To: Toerless Eckert , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 01:16:23 -0000 Hi Toerless, At 02:16 PM 15-01-2020, Toerless Eckert wrote: >I really do not know how to judge this. > >I am thining about the following question to (candidate) IAB members: > >"Can the work of the IAB that you contribute to impact future >financial results of your employer / sponsor ?" > >If one would answer YES, does that constitute a COI ? > >If not, then what would be a good reference example for the most minor COI >that one should be concerned about ? The text which you quoted is a standard clause. It is usually about misuse of corporate resources. It would likely be difficult to substantiate that there was a breach related to the second part of the text. The reply to the last question could be "not applicable" [1]. Regards, S. Moonesamy 1. John submitted a draft about 15 years ago. The draft could shine some light on why it is not applicable. From nobody Wed Jan 15 19:10:29 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB6012002F; Wed, 15 Jan 2020 19:10:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 dySnMb5Sitn9; Wed, 15 Jan 2020 19:10:24 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 D506F120803; Wed, 15 Jan 2020 19:10:24 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id z16so9505045pfk.0; Wed, 15 Jan 2020 19:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=S6IeIDtMvL5kiP94t+YJRN/YO2X9fJWfepShvvLd9+o=; b=SelC3UfyPzDtCJvfC85g99xvJYwoZSVZ6SSb6DZkdKTiniZ2NSs5eajxehdRNOzLKo eLhtBpIAh066YV/ZSEwBqwDjGFD+1i3eR1xCaxVdv/lmOalPuoa/NWM2mybCpaFusjKd 6DrTYlI/B3SYs1Bq34NLI9bGXermDMHg7afJsGPcQguaMZzjSWw1KzyNQmropkoMHcDa o24MgdhTuuYYzxG5upzrWfD3/LZdYRc8DtX3n25kBCbQS6Irog9waoX4mqJUmMI0MgSp C1HzhsaHc+dVVFYleiFr0HhUJ3SWW3MO0BORfHjPffo+9xyK6rXQ0GXAjwH+1kROLHUZ IDXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=S6IeIDtMvL5kiP94t+YJRN/YO2X9fJWfepShvvLd9+o=; b=XCvzPKEDK3XW26AyYZDPIb4u/NDmo2yjKj+s+hQDTKYU6Fpn9NbhF3BQHU/rflYI/I P50GaodkGcEkWAt0byS+P8+T0YnCfltRo4h1YBkpEAJLycvkuii2Og1/YlQnUUJarj+P xtKNLwqQIafiYtB38rwenrnlM7/WzCGo/Hu9A13yLtyj66KAjB6SQmPhaDH2nwLjwhYh Qu9lEXal/ARClKSHZ9n6nMb4XNDVjLdhxc9gn+9nu4/7RI2BKY1dBw7/Z0gYFSaDP89Y wP3Zy60hNj1/F6xHVyDmLQ8dW6weDZ8ixlzETMdMuocHNS6PY1hUGM1kPjY6oxzfKH2j h52Q== X-Gm-Message-State: APjAAAXFIek83bYcdsqe/PdzQMibB+P/eRnn/BFkIgDrxTyEyyN4JbXH EnxqQou+zZtpIJWmSisj0cXVgtdm X-Google-Smtp-Source: APXvYqzoojUHDuC9rjABvmp3KaRO2665jshX+Oa5rd8xyqvP8yakjKDXlStb/Df9NaBEcNkcTBHmHg== X-Received: by 2002:a62:1cd6:: with SMTP id c205mr34760353pfc.179.1579144224025; Wed, 15 Jan 2020 19:10:24 -0800 (PST) Received: from [172.17.0.82] ([111.69.8.186]) by smtp.gmail.com with ESMTPSA id 12sm23770423pfn.177.2020.01.15.19.10.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jan 2020 19:10:23 -0800 (PST) To: Robert Raszuk , Toerless Eckert Cc: IAB Chair , iab@iab.org, ietf@ietf.org, architecture-discuss@ietf.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Thu, 16 Jan 2020 16:10:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 03:10:27 -0000 On 16-Jan-20 14:15, Robert Raszuk wrote: >=20 >=20 > Toerless, >=20 > Considering that not that many of us are really good in predicting the = future you post a pretty tough question to answer ;) >=20 > Cheers, > R. >=20 > "Can the work of the IAB that you contribute to impact future > financial results of your employer / sponsor ?" I think that's easy. Read the arguments that you, as a candidate, made to= your employer to justify you spending time and travel budget on IAB memb= ership. If those arguments do not explain how IAB membership will positiv= ely affect your employer, answer "No". But in that case, I rather doubt t= hat your employer would have allowed you to accept the nomination. Mine c= ertainly wouldn't have. In other words, the only credible answer to this question is "Yes". =20 > If one would answer YES, does that constitute a COI ? Poetntially, yes. Even a self-employed engineer has this potential COI. I= t's something I lived with as a WG chair, IAB member, IESG member, ISOC B= oard member, and for that matter in completely other non-profit roles at = various times. =20 > If not, then what would be a good reference example for the most mi= nor COI > that one should be concerned about ? IMHO: arguing in a WG for a bit position when your company's running code= or hardware already assumes that bit position. Or arguing for a strange = new protocol feature that your company's business model relies on. That's= probably only happened a few hundred times in the IETF's history. There'= s nothing special about IAB (or even IESG) membership from this point of = view. It's potentially all of us. As long as it's argued in public, we ca= n resolve it. That's why I don't get the point of an IAB COI policy. We don't have an I= ETF COI policy, but I believe that's because the IETF process rules were = themselves designed around avoiding the standards process being damaged b= y COI. As long as the standards process is fully open, and HR and budget = COI is covered by IETF LLC rules, why bother? Regards Brian >=20 > Thanks > =C2=A0 =C2=A0 Toerless >=20 > > > >=C2=A0 =C2=A0 =C2=A0 Disclosure of Actual or Potential Conflicts > > > > The IAB requires that all Covered Individuals disclose their main= > > employment, sponsorship, consulting customer, or other sources of= income > > when joining the IAB or whenever there are updates. > > > > In addition, when a topic is discussed at the IAB, the Covered In= dividuals > > are required to promptly disclose if that topic constitutes a per= ceived or > > potential conflict of interest. Once disclosed, Covered Individua= ls may > > recuse from participation in discussions or decisions at their di= scretion. > > > > The specific conflicts that may cause a perceived or potential co= nflict of > > interest are matters for individual and IAB judgment, but general= ly come in > > the following forms: > > > >=C2=A0 * > > > >=C2=A0 =C2=A0 A personnel decision relates to the Covered Individu= al, a colleague > >=C2=A0 =C2=A0 that the Covered Individual's works closely with, or= a family > >=C2=A0 =C2=A0 member. For the purposes of this policy, a "person w= orking closely > >=C2=A0 =C2=A0 with" is someone working in the same team or project= , or a direct > >=C2=A0 =C2=A0 manager or employee of the Covered Individual. And "= family" means a > >=C2=A0 =C2=A0 spouse, domestic partner, child, sibling, parent, st= epchild, > >=C2=A0 =C2=A0 stepparent, and mother-, father-, son-, daughter-, b= rother-, or > >=C2=A0 =C2=A0 sister-in-law, and any other person living in the sa= me household, > >=C2=A0 =C2=A0 except tenants and household employees. > > > >=C2=A0 * > > > >=C2=A0 =C2=A0 A decision or output from the IAB impacts a contract= that the IETF > >=C2=A0 =C2=A0 enters into with a party, and that party relates to = the Covered > >=C2=A0 =C2=A0 Individual, a colleague that the Covered Individual'= s works closely > >=C2=A0 =C2=A0 with, or a family member. > > > >=C2=A0 * > > > >=C2=A0 =C2=A0 Activity on the IAB involves discussion and decision= s regarding > >=C2=A0 =C2=A0 technical matters, mainly related to IETF activities= =2E As an activity > >=C2=A0 =C2=A0 adjacent to a standardization process, it is often t= he case that > >=C2=A0 =C2=A0 Covered Individuals will have some (frequently non-f= inancial) stake > >=C2=A0 =C2=A0 in the outcome of discussions or decisions that rela= te to technical > >=C2=A0 =C2=A0 matters. This policy does not require that Covered I= ndividuals > >=C2=A0 =C2=A0 disclose such conflicts of interest as they relate t= o technical > >=C2=A0 =C2=A0 matters. However, Covered Individuals need to exerci= se their > >=C2=A0 =C2=A0 judgment and, in extraordinary cases be willing to d= isclose > >=C2=A0 =C2=A0 potential or perceived conflicts of interest even as= they relate to > >=C2=A0 =C2=A0 technical matters. For example, if a Covered Individ= ual's sponsor > >=C2=A0 =C2=A0 were in the process of entering a new market where t= here is an > >=C2=A0 =C2=A0 ongoing IAB discussion, then disclosure, or even rec= usal, might be > >=C2=A0 =C2=A0 appropriate, even if difficult. > > > > > >=C2=A0 =C2=A0 =C2=A0 Disclosure Transparency > > > > A person's recusal to participate in the discussion of a topic is= always > > noted in the public IAB minutes. In addition, the IAB will mainta= in a > > repository of all general disclosures of employment and other spo= nsorship. > > It is expected that much of this repository is public, but there = can be > > situations where some disclosures (such as customers of consultan= ts) are > > private. > > > > > > > >=C2=A0 > > > > >=20 > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 >=20 > --=20 > --- > tte@cs.fau.de >=20 From nobody Wed Jan 15 20:31:27 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFD1120855; Wed, 15 Jan 2020 20:31: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvCFJaN7dlwb; Wed, 15 Jan 2020 20:31:18 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4B1FC120803; Wed, 15 Jan 2020 20:31:18 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1irwoO-0008TN-GC; Thu, 16 Jan 2020 04:31:16 +0000 Date: Wed, 15 Jan 2020 20:31:15 -0800 Message-ID: From: Randy Bush To: Brian E Carpenter Cc: IETF Rinse Repeat , architecture-discuss@ietf.org In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 04:31:20 -0000 > I think that's easy. Read the arguments that you, as a candidate, made > to your employer to justify you spending time and travel budget on IAB > membership. If those arguments do not explain how IAB membership will > positively affect your employer, answer "No". But in that case, I > rather doubt that your employer would have allowed you to accept the > nomination. Mine certainly wouldn't have. > > In other words, the only credible answer to this question is "Yes". i know this is terribly old fashioned and silly of me. but some see roles as public service for the good of the internet. and some of us are spoiled brats whose employers support them willy nilly. randy From nobody Wed Jan 15 20:52:53 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245B21208AE; Wed, 15 Jan 2020 20:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 yJYfHiydNPoQ; Wed, 15 Jan 2020 20:52:50 -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 BDBF31208AC; Wed, 15 Jan 2020 20:52:50 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 00G4nBGv004943; Thu, 16 Jan 2020 04:52:49 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=cpPhLxS9ATT6Jr/rtGYFpEzQsSsCRJmZ5Z/vaO45E5s=; b=CX1nMr9Cue3EovBG5ldbwCjAB2fBWY2MVNdVr9waGBo0PAlVnZ/msNDXtV9wX/iiRljF MvT1i35pnso4vO2h/o4ze+m5D1lze/pHizURjEZZgzDs9HjhvFJkAJjGHU6N9E09ru4Z qiYgLcpXzPfD5jjPL6wYkHAza8yBDw9YToe68i/0dKbjpJdcTG1gJnMYhVk8puivkjpS yj/GpXjkxBlV9SQjXHWjtJJbbwqe8XvFS4iQkGO5d3MjV8FPRkpvg191ErIiHgQ4u5eP ShiXC3dgiEl3V7DMJ3yEHv4hRkA9AoJrmq9+BXltzKQJqC9UV7/KkuA/giyaybo4yObE nA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2xhpsn5nyb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 04:52:49 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 00G4l21o023439; Wed, 15 Jan 2020 23:52:48 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2xfajyw0yu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 23:52:48 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 23:52:47 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 15 Jan 2020 23:52:47 -0500 From: "Salz, Rich" To: Randy Bush , Brian E Carpenter CC: IETF Rinse Repeat , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmMup37bT2dZUClj9/F6vIplqfsqcaAgAAx24CAACA0gIAAFp2A//+yMQA= Date: Thu, 16 Jan 2020 04:52:46 +0000 Message-ID: <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.80.50] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-16_02:, , 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=418 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001160038 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-16_02:2020-01-16, 2020-01-15 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 clxscore=1015 mlxlogscore=393 phishscore=0 malwarescore=0 suspectscore=0 priorityscore=1501 adultscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001160038 Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 04:52:52 -0000 PiAgICBpIGtub3cgdGhpcyBpcyB0ZXJyaWJseSBvbGQgZmFzaGlvbmVkIGFuZCBzaWxseSBvZiBt ZS4gIGJ1dCBzb21lIHNlZQ0KICAgIHJvbGVzIGFzIHB1YmxpYyBzZXJ2aWNlIGZvciB0aGUgZ29v ZCBvZiB0aGUgaW50ZXJuZXQuICBhbmQgc29tZSBvZiB1cw0KICAgIGFyZSBzcG9pbGVkIGJyYXRz IHdob3NlIGVtcGxveWVycyBzdXBwb3J0IHRoZW0gd2lsbHkgbmlsbHkuDQogIA0KWWVzLCBidXQg dGhhdCB0ZW5kcyB0byBwZXJwZXR1YXRlIHRoZSBzaXR1YXRpb24gdGhhdCBvbmx5IGJpZ2dlciBv cmdhbml6YXRpb25zIGNhbiBhZmZvcmQgdG8gc3BvbnNvciBtb3N0IG9mIHRoZSBJRVRGIGxlYWRl cnNoaXAgcG9zaXRpb25zLiBNYW55IChwcm9iYWJseSBpbmNsdWRpbmcgUmFuZHkgYW5kIEJyaWFu KSBzZWUgdGhhdCBhcyBhIHByb2JsZW0uDQoNCg== From nobody Wed Jan 15 20:55:19 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18D6120899; Wed, 15 Jan 2020 20:55:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 CgKs08P-1fdS; Wed, 15 Jan 2020 20:55:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) (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 C6376120807; Wed, 15 Jan 2020 20:55:11 -0800 (PST) Received: from [198.180.150.2] (helo=mail.rg.net) by psg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1irxBW-000OkX-Fo; Thu, 16 Jan 2020 04:55:10 +0000 Received: from c-24-16-172-3.hsd1.wa.comcast.net ([24.16.172.3] helo=[192.168.0.157]) by mail.rg.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1irxBV-00055r-Ds; Thu, 16 Jan 2020 04:55:09 +0000 From: "Randy Bush" To: "Salz, Rich" Cc: "Brian E Carpenter" , "IETF Rinse Repeat" , architecture-discuss@ietf.org Date: Wed, 15 Jan 2020 20:55:06 -0800 X-Mailer: MailMate (1.13.1r5671) Message-ID: <343C5DC4-9B53-4E6A-BB17-1578E601B94C@psg.com> In-Reply-To: <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 04:55:13 -0000 >> i know this is terribly old fashioned and silly of me. but some see >> roles as public service for the good of the internet. and some >> of us are spoiled brats whose employers support them willy nilly. > Yes, but that tends to perpetuate the situation that only bigger > organizations can afford to sponsor most of the IETF leadership > positions. Many (probably including Randy and Brian) see that as a > problem. neither of my two full time jobs are for large corps. one is an isp research lab, and the other a startup routing stack dev. randy From nobody Wed Jan 15 21:02:52 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678671208AC; Wed, 15 Jan 2020 21:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ns7su8bVOkyS; Wed, 15 Jan 2020 21:02:44 -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 2150912089D; Wed, 15 Jan 2020 21:02:44 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 00G4xT3H032074; Thu, 16 Jan 2020 05:02:41 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=eCAc2LTXBl3xh219Z8WM7+yArdpqDhZfwWX+F3AxRWU=; b=ZtSo0Of5ksMbVsUWwtuyUE9vrKnv8UKMe2yza33swkb081UBxymEcPSDoakUkh3ZTYqX QjnOdzsHORfqsA5SIzOq5W8LQzEmO6bIpnqR0bFutY3Iuw66xGld4SLCoE27XfYehvrd YbvbAoEvWKfB9I3K0VxMTft+DvsdTYvZTN+jAStZCXts30M9QhaSvo9MCRZMXpxGMzZo 47TSp0BX918RPsTGaBQz8VGwZKeoEQRsmmU3mzDpiWVgFLWRzR7JuNZW90NCyxovRnDH 50fz+wecEpwS5K1ShIoaFSu7CQyGGW102bgGVmwi+uK6tFT/t0zxTxhLJAELuBGOEcj3 Nw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2xhpsn5pt4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 05:02:41 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 00G52fJB004763; Thu, 16 Jan 2020 00:02:41 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2xfak0n1ph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 00:02:40 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 Jan 2020 00:02:39 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 16 Jan 2020 00:02:38 -0500 From: "Salz, Rich" To: Randy Bush CC: Brian E Carpenter , IETF Rinse Repeat , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmMup37bT2dZUClj9/F6vIplqfsqcaAgAAx24CAACA0gIAAFp2A//+yMQCAAFR5AP//rkkA Date: Thu, 16 Jan 2020 05:02:38 +0000 Message-ID: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> <343C5DC4-9B53-4E6A-BB17-1578E601B94C@psg.com> In-Reply-To: <343C5DC4-9B53-4E6A-BB17-1578E601B94C@psg.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.80.50] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-16_02:, , 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=641 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001160041 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-16_02:2020-01-16, 2020-01-15 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 clxscore=1011 mlxlogscore=616 phishscore=0 malwarescore=0 suspectscore=0 priorityscore=1501 adultscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001160040 Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 05:02:50 -0000 PiAgICBuZWl0aGVyIG9mIG15IHR3byBmdWxsIHRpbWUgam9icyBhcmUgZm9yIGxhcmdlIGNvcnBz LiAgb25lIGlzIGFuIGlzcA0KICAgIHJlc2VhcmNoIGxhYiwgYW5kIHRoZSBvdGhlciBhIHN0YXJ0 dXAgcm91dGluZyBzdGFjayBkZXYuDQogIA0KSSBzZW5kICIqdGVuZHMqIHRvIHBlcnBldHVhdGUu IiAgVGhlcmUncyBhbHdheXMgZXhjZXB0aW9uczsgZ2xhZCB5b3UncmUgb25lLg0KDQo= From nobody Thu Jan 16 01:58:34 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FB9120024; Thu, 16 Jan 2020 01:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbsVN6epC1Ev; Thu, 16 Jan 2020 01:58:25 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5871A120019; Thu, 16 Jan 2020 01:58:25 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7309E54804C; Thu, 16 Jan 2020 10:58:20 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6AD04440059; Thu, 16 Jan 2020 10:58:20 +0100 (CET) Date: Thu, 16 Jan 2020 10:58:20 +0100 From: Toerless Eckert To: Randy Bush Cc: Brian E Carpenter , IETF Rinse Repeat , architecture-discuss@ietf.org Message-ID: <20200116095820.GA20495@faui48f.informatik.uni-erlangen.de> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 09:58:27 -0000 On Wed, Jan 15, 2020 at 08:31:15PM -0800, Randy Bush wrote: > i know this is terribly old fashioned and silly of me. but some see > roles as public service for the good of the internet. and some of us > are spoiled brats whose employers support them willy nilly. My take: The only way to prove that there is no conflict of interest is when i can prove that i will harm my own interests through what i do. Maybe a reference to Exodus 22:28. That was fun. Now, can we move beyond sillyness ? I hope that most participants in IETF honestly think that what they work towards is not morally evil, but many of us hopefully are also aware that our work is in support of one of potentially multiple competing commercial options whose outcomes do impact revenue and market experience of different group of market participants. Politicians are regularily accused of COI when they change from/to a job in the industry that relates to their political work, so they do not even do both things in parallel like most of us do. Let me repeat my original question: I want user stories: What would be a good reference example for the most minor COI that one should be concerned about in an IAB candidate/member ? Toerless From nobody Thu Jan 16 02:06:15 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D7120024; Thu, 16 Jan 2020 02:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asLmaswWaav1; Thu, 16 Jan 2020 02:06:03 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FD9120019; Thu, 16 Jan 2020 02:06:02 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3748C54804C; Thu, 16 Jan 2020 11:05:54 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2E85D440059; Thu, 16 Jan 2020 11:05:54 +0100 (CET) Date: Thu, 16 Jan 2020 11:05:54 +0100 From: Toerless Eckert To: "Salz, Rich" Cc: Randy Bush , Brian E Carpenter , IETF Rinse Repeat , "architecture-discuss@ietf.org" Message-ID: <20200116100554.GB20495@faui48f.informatik.uni-erlangen.de> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 10:06:10 -0000 On Thu, Jan 16, 2020 at 04:52:46AM +0000, Salz, Rich wrote: > Yes, but that tends to perpetuate the situation that only bigger organizations can afford to sponsor most of the IETF leadership positions. Many (probably including Randy and Brian) see that as a problem. Does this include owners of one-man shops on contract by big organizations like governments or divisions thereof ? What is an actually small organization in your opinion ? (don't answer). I would say: Candidates supporting "well funded interests" (forget how the emoney flow is orchestrated). We had this discussion maybe even on this list in the past and i asked why ISOC is not providing funding for candidates to leadership positions, and that seemed to have all type of pitfalls too (not too persuading to me though..). Cheers Toerless From nobody Thu Jan 16 06:26:28 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493EF120089 for ; Thu, 16 Jan 2020 06:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, 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 8Budmypc65Yv for ; Thu, 16 Jan 2020 06:26: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 D472712004F for ; Thu, 16 Jan 2020 06:26:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 601E5BE2F; Thu, 16 Jan 2020 14:26:17 +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 SIWGOLcM_LAz; Thu, 16 Jan 2020 14:26:12 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B0176BE20; Thu, 16 Jan 2020 14:26:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579184772; bh=LyEVXOTO6Nbxx0cSdBnPUgZfQ+ANiI8go51OJR/Ng3E=; h=To:Cc:From:Subject:Date:From; b=V1l38MKlJoAi3FyHJWpb7FNATt9pwTqopUSlf2L3IHFBJTCbKHR5iEDWagQ7Y95rO g92xM+mwvgMoRn/+1NmtVWpxfEE/VTRhh5Dp6zHuisrTL9q2gIvgFSLcBabJMukMEW FVZvx9DRTqVGA9Arc5uS42lhH56Zvf2Ly/dR5zWQ= To: "architecture-discuss@ietf.org" Cc: chirp@iab.org From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: <7770358c-e8ad-4c5c-71f8-a520f7b5a390@cs.tcd.ie> Date: Thu, 16 Jan 2020 14:26:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="37s1tb2BE3xH4BDNaoN39wwo5Zi0UFNbB" Archived-At: Subject: [arch-d] chirp list (was: my summary of resilience thread ) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 14:26:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --37s1tb2BE3xH4BDNaoN39wwo5Zi0UFNbB Content-Type: multipart/mixed; boundary="IHvE3or0ipke2GDU4kaEsH6Nj9W93Celx"; protected-headers="v1" From: Stephen Farrell To: "architecture-discuss@ietf.org" Cc: chirp@iab.org Message-ID: <7770358c-e8ad-4c5c-71f8-a520f7b5a390@cs.tcd.ie> Subject: chirp list (was: my summary of resilience thread ) --IHvE3or0ipke2GDU4kaEsH6Nj9W93Celx Content-Type: multipart/mixed; boundary="------------11CDB22B1B786EC5FD99116B" Content-Language: en-US This is a multi-part message in MIME format. --------------11CDB22B1B786EC5FD99116B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Thanks again for all the discussion on the resilience topic [1] over the holidays. The IAB discussed that on our Jan 8th call and have setup a list [2] where we can continue discussion on this topic, so if you're interested please subscribe there and we can continue the discussion in a few days once people have had a chance to sign up. For the moment, the IAB figured we'd keep this as an informal discussion list and maybe formally turn it into an IAB program later when/if we see that there's enough meaty work that people want to (and do:-) do. Cheers, S. [1] https://mailarchive.ietf.org/arch/msg/architecture-discuss/2oihgWQ0I1kahS= 5UG-dorHXCnTE [2] https://www.iab.org/mailman/listinfo/chirp --------------11CDB22B1B786EC5FD99116B 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------11CDB22B1B786EC5FD99116B-- --IHvE3or0ipke2GDU4kaEsH6Nj9W93Celx-- --37s1tb2BE3xH4BDNaoN39wwo5Zi0UFNbB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4gcoQACgkQWrL68XsX K+p3Pg//csp+PA3BNsM/zc5UUN8Qvh2qRt5gIHoctpM4hst4NKHXb99FBqMCO/nF WTVERhhYzCiJvcCbSame0qZUcS9J8KvLj656yauTHB16wGoZqe3Y3q8qvFIDIuSM SGN5DHjhf+IFYmzW7FysecgKcX+lIwCTrimVcH++NYIE2mszy7xncwJarfSIa7dV X3xjLKHyXDRPYbKAaq3i2X4Jup0TcQGcIydhrH4J3fvdGlB8+Dy/bEOqWl7MMezg 4PHFHvvKp1PMgCT966/C/ClB6uriItf4x3YRb0Cp/d3hDL8L/wdVm+n4cvbtc9J0 rLN1DYiHKmHf8bStybuLsCflkoV2+vIQ9vVbpSVkxLtZJwGClLG2cAkqyiQWt3De sk5y+Qnh+Naq2P3H8hYlgziQGlP5//syKJLflY/0XM/jDA4Qa/iogIN3Efk/Qnlh 5BFPLFW3WFMfAvM2gLI7Zm+5xZmUfAiPR7yzxeVQxlrA7XJD218BIKuWpW+Y3X4q S+1DYrmkyWhduZYlsOAQ456oT1zOqazQ/5WnAlebX7zsFJxAv+duopecrpgFuYcn 1wu3GuBnSVOOfKYRos7zIjJzncnGjkVol0pzy/nT/DALBrGJ0MZ88gv5pofMx0Ng +7Hui81AOLYHoWDHk6qaYbqtbRs6YLGcX9bSHYu/dNTjP8ya854= =SZeh -----END PGP SIGNATURE----- --37s1tb2BE3xH4BDNaoN39wwo5Zi0UFNbB-- From nobody Thu Jan 16 15:59:20 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D64A1200BA; Thu, 16 Jan 2020 15:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 M37_VzC7oCVh; Thu, 16 Jan 2020 15:59:11 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE773120059; Thu, 16 Jan 2020 15:59:10 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1isF2Z-000KdK-Qr; Thu, 16 Jan 2020 18:59:07 -0500 Date: Thu, 16 Jan 2020 18:59:02 -0500 From: John C Klensin To: Brian E Carpenter cc: IAB Chair , iab@iab.org, ietf@ietf.org, architecture-discuss@ietf.org Message-ID: In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 23:59:14 -0000 --On Thursday, January 16, 2020 16:10 +1300 Brian E Carpenter wrote: >> "Can the work of the IAB that you contribute to impact >> future financial results of your employer / sponsor ?" > > I think that's easy. Read the arguments that you, as a > candidate, made to your employer to justify you spending time > and travel budget on IAB membership. If those arguments do not > explain how IAB membership will positively affect your > employer, answer "No". But in that case, I rather doubt that > your employer would have allowed you to accept the nomination. > Mine certainly wouldn't have. > > In other words, the only credible answer to this question is > "Yes". >> If one would answer YES, does that constitute a COI ? > > Poetntially, yes. Even a self-employed engineer has this > potential COI. It's something I lived with as a WG chair, IAB > member, IESG member, ISOC Board member, and for that matter in > completely other non-profit roles at various times. Brian, I think you are right, but I also have to agree with Randy. Someone working for an organization that is willing to have them participate in the IETF because of a commitment to the general health of the Internet and that is willing to accept their acting against the best short-term interests of the company's products is a rare situation, but one that several of us have been in at one time or another. In some ways, that is the ideal, at least as long as we don't increase costs of participation enough that only the largest organizations can play. But, even then, if the individual is nearly as opportunistic as some of the comments in this thread imply that a policy needs to look out for, then the individual might still reason that, if the company's products do well this year, then there will be bigger bonuses next year and therefore be biased toward those products. I stopped commenting several days ago because I tried to write an explanation of why someone with projects or clients that could not be made public might still be an appropriate participant in the IAB. I realized that the explanation is too complicated if the policies have to be simple. I also realized that, if I were working for a company whose primary business was the making of soap or breakfast cereal, it might be hard to identify conflicts of interest without an in-depth job and departmental description and companies often consider that sort of information (and organization charts beyond some level of detail) to be sensitive ... a situation not very different from a consulting contract that barred either party from disclosing the relationship without mutual agreement (and that might have been insisted on by the consultant rather than the company). FWIW, I have never had any trouble getting permission to disclose arrangements that are, formally, non-public or confidential to Nomcoms: but the rules and the culture there have seemed offer more than adequate protection of the information. Where this all leads me is back to a point that others have made in different ways. For the technical work of the IAB, we want and need as much diversity of opinions, technical expertise, and perspective as we can get. That is, as long as the people involved really are experts and their expertise includes knowing what they don't know. IAB members might be biased as much or more because of personal technical preferences than because of financial interests (however described or measured). If we decide the former are ok and the latter aren't, we are not only going to find ourselves splitting hairs and exploring rat holes, but do each other --and the IAB's historical core technical mission-- a disservice. As an extreme, and I hope silly, example, if the Nomcom, in its wisdom, decided to appoint someone to the IAB who was the main advocate of a protocol or device that claimed to make physical limits on IP based on the speed or protons or electrons in a vacuum irrelevant, in technical discussions, I'd want the IAB to hear and evaluate that perspective and to do so independent of whether the individual stood to make zillions of dollars if the protocol proved successful. I'd also want the IAB to hear from the members best equipped to explain why, for Internet purposes at least, protocols or devices that require trans-light speeds to work properly are not going anywhere, independent of what they might stand to gain from upholding those positions. If either or both of those types of positions should not be represented in IAB discussions, then we are a problem with the way nomcoms work or with that absence of an effective recall mechanism, neither of which will be helped by a complex and hair-splitting COI policy. If we need very different policies for the IAB's technical and architectural work than for its more administrative or representational functions, it is likely that there are different skill sets for those functions as well. And maybe someone who has real or imagined conflicts should be isolated from the latter even while being a valuable asset for the technical and architectural work. If that is the case, maybe it is time to reconsider the IAB and whether some of its functions belong somewhere else. The perceived need for a formalized COI policy may be another argument that it is time to rethink the IAB, but it is not a solution. I think the bottom line is that this policy, at least as currently written, is unlikely to be helpful in difficult cases and may easily be damaging. Nomcoms need to select IAB members who hold openness and transparency in sufficient respect, and who have a strong enough of personal ethics, that issues that might affect their judgment on technical issues will be disclosed to other IAB members and, if appropriate, the community and who are willing to keep in confidence anything that is told them in confidence. If Nomcoms can't be counted on to do that, probably nothing else matters because people with less integrity (a problem I don't think we have seen) can always lie about their conflict. If Nomcoms cannot do that reliably with the tools they have available, then we have a different kind of problem, but, again, complex COI policy statements are not going to fix it. And, again, if we have given the IAB responsibilities --financial, administrative, or otherwise and direct or indirect-- that do require this sort of statement, let's work at separating those responsibilities as incompatible with what I still believe is the IAB's primary role, rather than things it ended up with post-POISED because we didn't have a better plan and other non-architectural tasks that have accumulated since. regards, john From nobody Thu Jan 16 23:50:42 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A3F1207FC for ; Thu, 16 Jan 2020 23:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 M-_DOAga9c4C for ; Thu, 16 Jan 2020 23:50:36 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 20FF9120273 for ; Thu, 16 Jan 2020 23:50:36 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id 77so21818104oty.6 for ; Thu, 16 Jan 2020 23:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GyFk986cX8c7Rkgh+txBJjeJ8Ba05DVc/osekxZ0Lcg=; b=aJxW1Dp7BTOu3OitsDOo7yP9eqC/CfXAek9Bc+Ln1KRVZwxtc9eEjKzYfYz7cbB9KQ a6wUxClbGYVAe/XVGuZVUM93krQbv0vC1BhmkJFwGXslA7ly/tKqEVwOQOJ0VJO9mFPI r8H4cE65mpImXlgL7pufIpVcqQJhXy4QTkU4Y9uaJQoAc4xZiiCEM+1KIvUfhQbwDTKz eeaIogp5XyRCHiBwy5davDAq3F8u5gV1zsDscqCnrOZscMDGk/feYhBXQ/kkMtQxPxH6 YZquyi/kGmpdfs8spsEovtmAiHvoVYVTV+1dRfbk2lgoq7pRAXGZLSo/ZAu24pnvgjeM vrCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GyFk986cX8c7Rkgh+txBJjeJ8Ba05DVc/osekxZ0Lcg=; b=pUA7CSKvnvl9TiGFzlzdfg6JUTvja7WJIDbdUcQCFXI2RF3rg4JQMeG6HvDNT7DBh/ NkwL/pCTK+zFG7yGYavejpEpXSLxoWJh+CII5VPsxzsmuuuzejukL0GKDQ9MKCyDjtQg nTdTsVpES6j0YkE/lUj6YOiedCPjTqurCLqXtqcaEBwpKTkr6fhAHNf4LS4FjcYFQxf+ wQgIETZ/uf8vZpJDRRj8RE6nUSf7Mm2T8QwQmIpeLt4I5tqJvpw8srsbC2/bEocKUmTR HztwQBJ4C4ZwgZQgGGPG7mRlCoaZUBPwpAIi4b3zP7S49b/TNHHqWtyGACWvef+5363A JOgA== X-Gm-Message-State: APjAAAUZZjHCAJwf8wpbCyCYTwAOaOGVmQhOhWDTYeq6Cinh8fwwzCKy lEfNE/7bujpQyFex8YOSnIcKHBxA+9mcP/feaWw= X-Google-Smtp-Source: APXvYqx8NAvcugBfDv+auQCCVRce2dxoR5yOkvkZqltsaDYRGVDK/Hhd98Lfw/QU9VkRP6LKJF2cSXNeMHtBdKvwqck= X-Received: by 2002:a9d:198b:: with SMTP id k11mr5351279otk.295.1579247435340; Thu, 16 Jan 2020 23:50:35 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Thu, 16 Jan 2020 23:50:34 -0800 (PST) In-Reply-To: References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> <265A560E-F07F-4CB8-8D5F-6077D1419CE5@comcast.net> <20200109094537.GY8801@faui48f.informatik.uni-erlangen.de> From: Guntur Wiseno Putra Date: Fri, 17 Jan 2020 14:50:34 +0700 Message-ID: To: Toerless Eckert Cc: John Day , Andrew Campling , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000655f1c059c51327a" Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 07:50:41 -0000 --000000000000655f1c059c51327a Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, I think these posts have relevances, as approaches and perspectives (for interpretations and evaluations), to this issue "Centralization or Diversity ("Centralized Architecture of Internet Infrastructure") ": They were about "Networks of Interests in Cyberspace, in Internet" and "Aesthetics and Ethics of Cyberspace, of Internet" with a horizon of layers of the social and engineering: https://mailarchive.ietf.org/arch/msg/architecture-discuss/1qsfPOKu2TqbmstHg6UOAfU7NoM https://mailarchive.ietf.org/arch/msg/architecture-discuss/lP1_e4ZqEYkNTFlb6N6fommrGy0 Regard, Guntur Wiseno Putra Pada Jumat, 10 Januari 2020, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > Adding what I mentioned in the previous message (in trying to learn on > "Networks conditions"): > > "diversity/heterogeneity" seems contradictory to "centralization" when the > latter is about "uniformity"...? > > Of "blobs" (1) there are moments of active elements or primitives, a > corresponding force of attractions, of fusions, of inflection, and of > deformations: Does "centralization" in Internet infrastructure not > represent those moments...? > > Thinking also about disciplinary interactions (thus, moments of > disciplines) having a moment of complexity and flexibility: does such an > analogue works for "networks conditions" to say that moments of diversities > have also moments of uniformities...? > > > (1) The quotation is fully presented below (it is how Brian Massumi define > what Greg Lynn speaks as "blob"): > "active elements or 'primitives' which combine to generate their own > space. Each blob is differentiated. It is assigned (by the programmer) a > circumference, a mass, and a corresponding force of atttaction. The force > of attraction defines a field of influence outside the perimeter of the > blob, and that field is in turn differentiated into zones. Closest to the > perimeter is a zone of fusion. Any blob entering it will combine with the > first blob to form a larger blob. Beyond the fusion zone is a zone of > inflection, the area within which the atttactive force of the blob will > alter the shape, and therefore the field of influence, of a neighbouring > blob. Put a number of blob together, and their differential influenced on > each other produce unpredictable reciprocal deformations. (Massumi 1995) > > > Regard, > Guntur Wiseno Putra > > Pada Jumat, 10 Januari 2020, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> (It seems contradictory yet happen: "centralization" to >> "diversity/heterogeneity" as a network condition...?) >> >> Toward the problematic issues on "centralization" on Internet practice, >> such a way to arrive there is about (re)considering "network conditions": >> here we meet with diversity/heterogeneity as the Internet draft mentioned >> "Centralized Architecture on Internet Infrastructure". What does it mean by >> "centralization" thus...? --how does it work/mean/value for >> diversity/heterogeneity...? >> >> For diversity/heterogeneity as a network condition we may refer to >> "liquid architecture" (1) of which other things with nuances deserve to >> mention: "bloobs"(2), "plasm"(3), "plasmatic"(4) and "plasmatics"(5). Thus >> we are also saying about a spatial analysis of a network condition as it >> is about cyberspace, about Internet --and we may plan things strategically >> about the space... >> >> - we may think of Internet as one among other collective matters yet it >> is also one among other personal matters: those matters are maintaining >> dialogues. Is it not so...in considering Internet sustainability? --at >> least we find that Internet has a significance for planning societies of >> nations initiated by the United Nations (see "Leveraging Tech...") >> >> >> (1) "...Liquid architecture makes liquid cities, cities that change at >> the shift of a value, where visitors with different backgrounds sec >> different landmarks, where neighborhoods vary with ideas held in common, >> and evolve as the ideas mature or dissolve". (Novak, Marcos, "Liquid >> Architecture in Cyberspace" (1991) >> https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf) >> >> (2) "bloobs" refers to "active element or primitive generatiing their own >> spaces... (with possibilities of) unpredictable reciprocal deformations". >> (Massumi, Brian, "Interface and Active Space", in Cheetam, M. A, "Kant, >> Art and Art History: Moments of Disciplines, Cambridge University Press, >> Cambridge et all., 2001, p. 25; Cheetam refered Massumi's "Interface and >> Active Space: Human-Machine Design" available at http://www >> anu.edu/HRC/first_and_last/links/massumi_works.htm) >> >> (3) plasm refers to "a mould of matrix in which something is cast or >> formed"; "plasma" refers to "living matter of a cell" and to "liquid part >> of blood in which corpuscles float"; then, plasmatic refers to what is >> related with "plasm" or "plasma". "Plasmatic" may be applied to refer to >> "disciplinary interactions ...(having) ...multidimensional and shifting >> cultural intensities, and that the specific contours of this matric are >> inflected historically by the forces of which it is comprised ... (--) ...a >> model of complexity and flexibility allowing us to understand how an active >> element in the system... can shape and be shaped by disciplines. (Cheetam, >> M. A, "Kant, Art and Art History: Moments of Disciplines, Cambridge >> University Press, Cambridge et all., 2001, p. 25) >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Kamis, 09 Januari 2020, Toerless Eckert menulis: >> >>> Good insights about the outcome of PICS. >>> >>> To clarify, i am primarily interested to see if we can do something >>> to better support static network planning and protocol evolution. >>> >>> Something which is more a self-declaration than a (broken) conformance >>> suite "verified" testing result. Something which always must be >>> followed by appropriate testing (interop, deployment) depending >>> on the goal. But something that can help to faster get to that >>> step. Something to to help avoid horrenduously repetitive RFP questions >>> by poor customers (does your IETF FOO protocol on your product support >>> the optional BAR feature). >>> >>> One could think of another axis of information in our yang models, >>> a subset of "implementation defined" behavior whose values can be >>> statically exposed without access to a live system and hence be >>> published and then used in netork planning for example >>> (or auto-collection by a curious WG trying to progress some >>> standard to full internet ;-)). >>> >>> I was interested in the type of information i remember to have seen >>> in the 90th in PICS, i am horrified about the process i learn >>> about it here in te thread ;-) >>> >>> Cheers >>> Toerless >>> >>> On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote: >>> > FWIW, there were also problems with keeping the test suites up-to-date >>> with the errata. Bugs could be fixed in the standards and incorporated >>> into implementations faster than the people developing the test suites >>> could keep up (or wanted to). Of course the fixes were in the >>> implementations before they were in the standards. And what was worse, when >>> pointed out to them that their test-suited didn???t conform to the spec, >>> they didn???t care. They still insisted they were right. >>> > >>> > For some standards, it was possible to develop utilities that did a >>> specific function and used part of a standard to do that function but >>> didn???t need the rest of the standard. But the people running the test >>> suites couldn???t deal with it. If it didn???t implement the entire >>> protocol, it didn???t pass. The utility couldn???t cause any of the rest of >>> the protocol to be generated. It conformed to the standard for everything >>> it did. They were using the standard as it had been intended. >>> > >>> > But the testers were effectively bean-counters and totally stupid. >>> > >>> > Conformance fell under the ANSI committee I chaired and I remember >>> writing them (some military base in Arizona whose name I have thankfully >>> forgotten) nasty letters telling them to get their act together or get out. >>> They were doing more harm than good. Wish we had known about the IS-IS >>> issues as well to add to the list. >>> > >>> > One needs some way to test implementations before trying them live. >>> But one has to treat them (and it has to be instilled in the testers) that >>> the purpose is to help: obey Postel???s rule, find problems, and then >>> determine whether it is the tests, the ???standard??? or the new >>> implementation that is at fault. And above all if it isn???t externally >>> visible, it is none of the tester???s business. Even if there is ???formal >>> specification???, one can???t be sure that a bug is in the prose, the >>> formal spec, the tests, or the implementation. They are all suspect. (Often >>> formal specifications are more complex than the code. And we know what that >>> means!) >>> > >>> > Years before the standards issues arose, I did a survey of testing >>> methods for our own use. I expected to find that two or three were pretty >>> effective, pick one or two. What I found were 20 or 25 that were all >>> pretty effective and the advice was pick 2 or 3 and it didn???t really >>> matter which ones as long as they were different. (Not the result I was >>> looking for.) ;-) >>> > >>> > Take care, >>> > John >>> > >>> > > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote: >>> > > >>> > > >>> > >> Yes, i was thinking of ISO PICS. But i lost track of those ISO >>> standards >>> > >> since the 90th. I guess i would have to see a successfull and still >>> > >> currently used standard and how its PICS do or do not help. Just >>> > >> not alot of those ISO specs left in wide deployments, right. >>> > >> X.500 ? Maybe i can get more insight from the security community. >>> > > >>> > > >>> > > You need not go that far. Remember IS-IS? Still thriving. >>> > > >>> > > And yes, my experience with PICs and test suites comes from that. >>> > > >>> > > >>> > >>> What it does do is to encourage people to write ???conformance >>> test suites???. These then get sold to unsuspecting customers and >>> end-users. Unfortunately, the quality of such suites is so low that you >>> spend way, way, way more time debugging the test suite and you never find >>> bugs in your implementation. >>> > >> >>> > >> This is just the worst possible outcome, and i am sure one can learn >>> > >> from those bad experiences. Just think of taking a more organized >>> > >> step towards being able to collect protocol implementation >>> information >>> > >> from the industry. Right now every WG who wants to raise the level >>> of >>> > >> an IETF protocol, e.g.: to(wards) full standard is coming up with a >>> > >> questionaire in an ad-hoc fashion (we're just doing this in >>> Multicast >>> > >> for IGMP/MLD). >>> > > >>> > > >>> > > You can do that if you like, but the one proven, effective method is >>> interoperability testing. >>> > > >>> > > Running code trumps questionaires, conformance test suites, theory, >>> and mandate. >>> > > >>> > > >>> > >> My point was: If the only murphy you have is competitive pressure, >>> it works not >>> > >> it there is only limited competition, such as a total of maybe no >>> > >> more than 3 competing national infrastructures. >>> > > >>> > > >>> > > And countries that stifle competition inflict vendor lock on >>> themselves. >>> > > >>> > > >>> > >> See above. The best i think we (IETF) can do is to educate better >>> about >>> > >> this by appropriate documents. Certainly some additional protocol >>> work >>> > >> will result from that. I for once had simple slides 10 years ago >>> how to fixup >>> > >> non-dual plane networks to be dual-plane. And maybe we can come up >>> with >>> > >> questionaires to get better numbers from actual deployments (the >>> > >> PICS discussion). >>> > > >>> > > >>> > > The IETF???s job is not education. It does not work as the education >>> is not requested >>> > > and not welcome. The IETF???s job is standards and it needs to focus >>> on that. >>> > > >>> > > >>> > >> Figuring out ideas for a complete ecosystem of monetization and >>> > >> deployment between competition and regulation is better left for >>> > >> an ongoing bar-bof with emphasis on bar. >>> > > >>> > > >>> > > I concur. Let???s stop fooling ourselves into thinking that anything >>> that the IAB/IETF writes has any impact >>> > > on regulation or economics. >>> > > >>> > > >>> > >> Actually one of the interesting conclusions was that dual-plane in >>> > >> many cases is really free but deployments often just don't fully >>> > >> utilize it. >>> > > >>> > > >>> > > I???d agree that it???s close to free. If you accept that you need >>> a dual-plane approach for resiliency, then >>> > > adding a second vendor to the mix is relatively easy. There???s >>> additional cost because of decreased >>> > > purchasing volume. There???s additional costs in management and >>> operations. >>> > > >>> > > However, as compared to the costs of an unnecessary outage, it???s >>> still trivial. >>> > > >>> > > Tony >>> > > >>> > > _______________________________________________ >>> > > Architecture-discuss mailing list >>> > > Architecture-discuss@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >>> -- >>> --- >>> tte@cs.fau.de >>> >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >> --000000000000655f1c059c51327a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

I think these posts have rele= vances, as approaches and perspectives (for interpretations and evaluations= ), to this issue "Centralization or Diversity ("Centralized Archi= tecture of Internet Infrastructure") ": They were about "Net= works of Interests in Cyberspace, in Internet" and =C2=A0"Aesthet= ics and Ethics of Cyberspace, of Internet" with a horizon of layers of= the social and engineering:




Regard,
= Guntur Wiseno Putra

Pada Jumat, 10 Januari 2020, Guntur Wiseno Putra= <gsenopu@gmail.com> menulis= :
Dear architecture-discuss,

Adding what I mentioned in the previous message (in trying to= learn on "Networks conditions"):=C2=A0

"diversity/heterogeneity" seems contradictory to "central= ization" when the latter is about "uniformity"...?

Of "blobs" (1) there are moments of active elem= ents or primitives, a corresponding force of attractions, of fusions, of in= flection, and of deformations: Does "centralization" in Internet = infrastructure not represent those moments...?=C2=A0

<= div style=3D"color:rgb(34,34,34);font-size:14px;line-height:22.120000839233= 4px">Thinking also about disciplinary interactions (thus, moments of discip= lines) having a moment of complexity and flexibility: does such an analogue= works for "networks conditions" to say that moments of diversiti= es have also moments of uniformities...?


(1) The quotation is fully presented below (it is how Brian Massum= i define what Greg Lynn speaks as "blob"):
"activ= e elements or 'primitives' which combine to generate their own spac= e. Each blob is differentiated. It is assigned (by the programmer) a circum= ference, a mass, and a corresponding force of atttaction. The force of attr= action defines a field of influence outside the perimeter of the blob, and = that field is in turn differentiated into zones. Closest to the perimeter i= s a zone of fusion. Any blob entering it will combine with the first blob t= o form a larger blob. Beyond the fusion zone is a zone of inflection, the a= rea within which the atttactive force of the blob will alter the shape, and= therefore the field of influence, of a neighbouring blob. Put a number of = blob together, and their differential influenced on each other produce unpr= edictable reciprocal deformations. (Massumi 1995)


Regard,
Guntur Wiseno Putra

Pada Juma= t, 10 Januari 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

(It seems c= ontradictory yet happen: "centralization" to "diversity/hete= rogeneity" as a network condition...?)

Toward= the problematic issues on "centralization" on Internet practice,= such a way to arrive there is about (re)considering "network conditio= ns": here we meet with diversity/heterogeneity as the Internet draft m= entioned "Centralized Architecture on Internet Infrastructure". W= hat does it mean by "centralization" thus...? --how does it work/= mean/value for diversity/heterogeneity...?

For div= ersity/heterogeneity as a network condition we may refer to "liquid ar= chitecture" (1) of which other things with nuances deserve to mention:= "bloobs"(2), "plasm"(3), "plasmatic"(4) and = "plasmatics"(5). Thus we are also =C2=A0saying about a spatial an= alysis of a network condition as it is about cyberspace, about Internet --a= nd we may plan things strategically about the space...

=
- we may think of Internet as one among other collective matters yet i= t is also one among other personal matters: =C2=A0those matters are maintai= ning dialogues. Is it not so...in considering Internet sustainability? --at= least we find that Internet has a significance for planning societies of n= ations initiated by the United Nations (see "Leveraging Tech...")=


(1) "...Liquid = architecture makes liquid cities, cities that change at the shift of a valu= e, where visitors with different backgrounds sec different landmarks, where= neighborhoods vary with ideas held in common, and evolve as the ideas matu= re or dissolve". (Novak, Marcos, "Liquid Architecture in Cyberspa= ce" (1991) =C2=A0=C2=A0

(2) "bloobs" refers to "= active element or primitive generatiing their own spaces... (with possibili= ties of) unpredictable reciprocal deformations".=C2=A0
(Mass= umi, Brian, "Interface and Active Space", =C2=A0in Cheetam, M. A,= "Kant, Art and Art History: Moments of Disciplines, Cambridge Univers= ity Press, Cambridge et all., 2001, p. 25; Cheetam refered Massumi's &q= uot;Interface and Active Space: Human-Machine Design" available at=C2= =A0http://www=C2=A0anu.edu/HRC/firs= t_and_last/links/massumi_works.htm)

(3) p= lasm refers to "a mould of matrix in which something is cast or formed= "; "plasma" refers to "living matter of a cell" an= d to "liquid part of blood in which corpuscles float"; then, plas= matic refers to what is related with "plasm" or "plasma"= ;. "Plasmatic" may be applied to refer to "disciplinary inte= ractions ...(having) ...multidimensional and shifting cultural intensities,= and that the specific contours of this matric are inflected historically b= y the forces of which it is comprised ... (--) ...a model of complexity and= flexibility allowing us to understand how an active element in the system.= .. can shape and be shaped by disciplines. (Cheetam, M. A, "Kant, Art = and Art History: Moments of Disciplines, Cambridge University Press, Cambri= dge et all., 2001, p. 25)

Regard,
Guntur= Wiseno Putra

Pada Kamis, 09 Januari 2020, Toerless Eckert <tte@cs.fau.de> menulis= :
Good insights about the outcome of PICS= .

To clarify, i am primarily interested to see if we can do something
to better support static network planning and protocol evolution.

Something which is more a self-declaration than a (broken) conformance
suite "verified" testing result. Something which always must be followed by appropriate testing (interop, deployment) depending
on the goal. But something that can help to faster get to that
step. Something to to help avoid horrenduously repetitive RFP questions
by poor customers (does your IETF FOO protocol on your product support
the optional BAR feature).

One could think of another axis of information in our yang models,
a subset of "implementation defined" behavior whose values can be=
statically exposed without access to a live system and hence be
published and then used in netork planning for example
(or auto-collection by a curious WG trying to progress some
standard to full internet ;-)).

I was interested in the type of information i remember to have seen
in the 90th in PICS, i am horrified about the process i learn
about it here in te thread ;-)

Cheers
=C2=A0 =C2=A0 Toerless

On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote:
> FWIW, there were also problems with keeping the test suites up-to-date= with the errata.=C2=A0 Bugs could be fixed in the standards and incorporat= ed into implementations faster than the people developing the test suites c= ould keep up (or wanted to). Of course the fixes were in the implementation= s before they were in the standards. And what was worse, when pointed out t= o them that their test-suited didn???t conform to the spec, they didn???t c= are. They still insisted they were right.
>
> For some standards, it was possible to develop utilities that did a sp= ecific function and used part of a standard to do that function but didn???= t need the rest of the standard. But the people running the test suites cou= ldn???t deal with it. If it didn???t implement the entire protocol, it didn= ???t pass. The utility couldn???t cause any of the rest of the protocol to = be generated. It conformed to the standard for everything it did. They were= using the standard as it had been intended.
>
> But the testers were effectively bean-counters and totally stupid.
>
> Conformance fell under the ANSI committee I chaired and I remember wri= ting them (some military base in Arizona whose name I have thankfully forgo= tten) nasty letters telling them to get their act together or get out. They= were doing more harm than good. Wish we had known about the IS-IS issues a= s well to add to the list.
>
> One needs some way to test implementations before trying them live.=C2= =A0 But one has to treat them (and it has to be instilled in the testers) t= hat the purpose is to help:=C2=A0 obey Postel???s rule, find problems, and = then determine whether it is the tests, the ???standard??? or the new imple= mentation that is at fault. And above all if it isn???t externally visible,= it is none of the tester???s business.=C2=A0 Even if there is ???formal sp= ecification???, one can???t be sure that a bug is in the prose, the formal = spec, the tests, or the implementation. They are all suspect. (Often formal= specifications are more complex than the code. And we know what that means= !)
>
> Years before the standards issues arose, I did a survey of testing met= hods for our own use. I expected to find that two or three were pretty effe= ctive, pick one or two.=C2=A0 What I found were 20 or 25 that were all pret= ty effective and the advice was pick 2 or 3 and it didn???t really matter w= hich ones as long as they were different. (Not the result I was looking for= .)=C2=A0 ;-)
>
> Take care,
> John
>
> > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote:
> >
> >
> >> Yes, i was thinking of ISO PICS. But i lost track of those IS= O standards
> >> since the 90th. I guess i would have to see a successfull and= still
> >> currently used standard and how its PICS do or do not help. J= ust
> >> not alot of those ISO specs left in wide deployments, right.<= br> > >> X.500 ? Maybe i can get more insight from the security commun= ity.
> >
> >
> > You need not go that far.=C2=A0 Remember IS-IS?=C2=A0 Still thriv= ing.=C2=A0
> >
> > And yes, my experience with PICs and test suites comes from that.=
> >
> >
> >>> What it does do is to encourage people to write ???confor= mance test suites???.=C2=A0 These then get sold to unsuspecting customers a= nd end-users.=C2=A0 Unfortunately, the quality of such suites is so low tha= t you spend way, way, way more time debugging the test suite and you never = find bugs in your implementation.
> >>
> >> This is just the worst possible outcome, and i am sure one ca= n learn
> >> from those bad experiences. Just think of taking a more organ= ized
> >> step towards being able to collect protocol implementation in= formation
> >> from the industry. Right now every WG who wants to raise the = level of
> >> an IETF protocol, e.g.: to(wards) full standard is coming up = with a
> >> questionaire in an ad-hoc fashion (we're just doing this = in Multicast
> >> for IGMP/MLD).
> >
> >
> > You can do that if you like, but the one proven, effective method= is interoperability testing.
> >
> > Running code trumps questionaires, conformance test suites, theor= y, and mandate.
> >
> >
> >> My point was: If the only murphy you have is competitive pres= sure, it works not
> >> it there is only limited competition, such as a total of mayb= e no
> >> more than 3 competing national infrastructures.
> >
> >
> > And countries that stifle competition inflict vendor lock on them= selves.
> >
> >
> >> See above. The best i think we (IETF) can do is to educate be= tter about
> >> this by appropriate documents. Certainly some additional prot= ocol work
> >> will result from that. I for once had simple slides 10 years = ago how to fixup
> >> non-dual plane networks to be dual-plane. And maybe we can co= me up with
> >> questionaires to get better numbers from actual deployments (= the
> >> PICS discussion).
> >
> >
> > The IETF???s job is not education. It does not work as the educat= ion is not requested
> > and not welcome. The IETF???s job is standards and it needs to fo= cus on that.
> >
> >
> >> Figuring out ideas for a complete ecosystem of monetization a= nd
> >> deployment between competition and regulation is better left = for
> >> an ongoing bar-bof with emphasis on bar.
> >
> >
> > I concur. Let???s stop fooling ourselves into thinking that anyth= ing that the IAB/IETF writes has any impact
> > on regulation or economics.
> >
> >
> >> Actually one of the interesting conclusions was that dual-pla= ne in
> >> many cases is really free but deployments often just don'= t fully
> >> utilize it.
> >
> >
> > I???d agree that it???s close to free.=C2=A0 If you accept that y= ou need a dual-plane approach for resiliency, then
> > adding a second vendor to the mix is relatively easy. There???s a= dditional cost because of decreased
> > purchasing volume. There???s additional costs in management and o= perations.
> >
> > However, as compared to the costs of an unnecessary outage, it???= s still trivial.
> >
> > Tony
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architec= ture-discuss

--
---
tte@cs.fau.de

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--000000000000655f1c059c51327a-- From nobody Fri Jan 17 00:48:26 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E49A120236 for ; Fri, 17 Jan 2020 00:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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=elandsys.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 iP0JyOuVBGTW for ; Fri, 17 Jan 2020 00:48:19 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id CB24F120273 for ; Fri, 17 Jan 2020 00:48:19 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.116.6]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00H8m5uY029474 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jan 2020 00:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579250897; x=1579337297; i=@elandsys.com; bh=fX7QFbJ1JvA82+NZVb8mAHA1kl4li2xFTVwC+ZZIzwc=; h=Date:To:From:Subject:In-Reply-To:References; b=nuW3CfLUWoDBpJkPbxoFb0oCUrsGCV+Tr/X6TkAjAjrB5FsiOVmZuhKiROg9+Tk8i hSTTQGVGdqC+T7fnBgB5hwo4MzDo0Ce5sIDTg+n3PHe/OETr4Nm41GQm3lpCuxLzET eUscMdATWt2F0Fd8tJ0QLECLRci+rTq+RPR/ZLAg= Message-Id: <6.2.5.6.2.20200116201401.1077dc18@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 Jan 2020 00:44:15 -0800 To: John C Klensin , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 08:48:24 -0000 Hi John, At 03:59 PM 16-01-2020, John C Klensin wrote: >I stopped commenting several days ago because I tried to write >an explanation of why someone with projects or clients that >could not be made public might still be an appropriate >participant in the IAB. I realized that the explanation is too >complicated if the policies have to be simple. I also realized A policy helps to ensure consistency. It is sometimes applied mechanically by people in a junior position. The information published by the IAB does not show anyone affiliated with a soap-making or breakfast cereal business. I don't recall seeing anyone raising such cases during the IASA2 discussions about the topic. I did not miss the fact that, based on what you wrote, you considered the matter under discussion. There is a principle which may be applicable here. I used "may" as I am not familiar with U.S. laws. >Where this all leads me is back to a point that others have made >in different ways. For the technical work of the IAB, we want >and need as much diversity of opinions, technical expertise, and >perspective as we can get. That is, as long as the people Whether the IAB work is technical depends on the meaning of that word. If there are IAB members reading this mailing list, I would be interested in reading their explanation about why the following is considered as technical: http:/r.elandsys.com/r/41848 I came across a statement from the IETF legal counsel about standardization and the impact of EAR. Would such a topic be technical [1]? >involved really are experts and their expertise includes knowing >what they don't know. IAB members might be biased as much or >more because of personal technical preferences than because of >financial interests (however described or measured). If we >decide the former are ok and the latter aren't, we are not only >going to find ourselves splitting hairs and exploring rat holes, >but do each other --and the IAB's historical core technical >mission-- a disservice. Would it be a problem if an IAB member does not disclose any his/her financial interest? Regards, S. Moonesamy 1. I asked a similar question on an unrelated topic to an IAB member. The question remains unanswered. From nobody Fri Jan 17 08:13:41 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2144F1200A4 for ; Fri, 17 Jan 2020 08:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 QHzyDForXMRy for ; Fri, 17 Jan 2020 08:13:38 -0800 (PST) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0: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 48F231200A3 for ; Fri, 17 Jan 2020 08:13:38 -0800 (PST) Received: by mail-oi1-x231.google.com with SMTP id 18so22640176oin.9 for ; Fri, 17 Jan 2020 08:13:38 -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=dSq37+DaZzlm7U2bLHcqyXL0PbsmsUQUYn2AK+hZdiQ=; b=XJmQdlvGQ59M6wYOzrMdPvp7qEe/671QdAUfu1F4vCtrI+amN/zgKx3k+c+LxBelhi dMdi53yOQzzLI2qZHG/0ZegJdWVHvMQg5cvkmrCR1wO9RFENuiaVwYQfI9EbBcnPLmkh /K4+IKgj6xAOyGeu0FYWFmoB5PZLdU+FKMfCJdeaTZlPrFT4OtO+rARwHLxNxddraZgM nZg+yJeSsbTaRMDRbtqzj6hZrCwZzjZ1EaQyBoLVIJOEXqNCQLuMVBqGIGuCGdaBr3Em fxZrvxP5sbwsyweDA8ZjRmBT4WPlSUY5NNgErxGRjHfLcPr9N+RcZtV2ExXNxGispJ4n obNg== 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=dSq37+DaZzlm7U2bLHcqyXL0PbsmsUQUYn2AK+hZdiQ=; b=jBHdzsqC/5fsF5YzJvAR/NpVPdSD1XL3Z+248UZ28mx1rEzfwN1Yi2tBfhrb3IoMRC 1uaWwOy97fxx4EwoLmbnndm6BMPL5jKZk3fJhLiFgh3fU2pHuV+eq5vnLzvkz5SpPwXi vJLfZlQY28ZA24w9+NMkrDmiG6en3vkk58l2n6hnU+f98pvlBpl3ibpJVtYbcKOmTRLM DgsavdWZGJd29daI3Ze5/iP2Pvb+vFk56I52VuYqec6kmbosrhhi5jt4+i4WA0OqOmDn AHtEo3D0S/0sZjbNcPyuu+8YJhw4CGYgSafZvAe7ookGOiG73MPf5f8zDWNmc/9ctckJ 5Wcg== X-Gm-Message-State: APjAAAWEOv4yKzNmEdIn9QffEI0jtrUtZvPYkW9CbdnUEcWsZDT21ake 8pe+wGir3dLmoW8PeA+dH27yo8+V3DCTcrzY4ijTEVj/ X-Google-Smtp-Source: APXvYqypgid+/942IBi107qsZebQ9rUXHA3hOEALB6Ahz2Vi00r+XTs92vss7yJYgbbNEpLkBMON6yiZiGW+00/3zq0= X-Received: by 2002:aca:ba88:: with SMTP id k130mr4037092oif.167.1579277617441; Fri, 17 Jan 2020 08:13:37 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200116201401.1077dc18@elandnews.com> In-Reply-To: <6.2.5.6.2.20200116201401.1077dc18@elandnews.com> From: Ted Hardie Date: Fri, 17 Jan 2020 08:13:10 -0800 Message-ID: To: S Moonesamy Cc: John C Klensin , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000063b1cc059c58393a" Archived-At: Subject: Re: [arch-d] Draft IAB conflict of interest policy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 16:13:40 -0000 --00000000000063b1cc059c58393a Content-Type: text/plain; charset="UTF-8" Howdy, On Fri, Jan 17, 2020 at 12:48 AM S Moonesamy wrote: > > >Where this all leads me is back to a point that others have made > >in different ways. For the technical work of the IAB, we want > >and need as much diversity of opinions, technical expertise, and > >perspective as we can get. That is, as long as the people > > Whether the IAB work is technical depends on the meaning of that > word. If there are IAB members reading this mailing list, I would be > interested in reading their explanation about why the following is > considered as technical: http:/r.elandsys.com/r/41848 The title of the original appeal is "An appeal to make the procedure related toIndependent Submission Stream more transparent". Though the documents under discussion are, of course, technical, this was primarily a process appeal. regards, Ted Hardie --00000000000063b1cc059c58393a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Fri, Jan 17, 2020 at 12:48 AM S Moonesam= y <sm+ietf@elandsys.com>= ; wrote:

>Where this all leads me is back to a point that others have made
>in different ways.=C2=A0 For the technical work of the IAB, we want
>and need as much diversity of opinions, technical expertise, and
>perspective as we can get.=C2=A0 That is, as long as the people

Whether the IAB work is technical depends on the meaning of that
word.=C2=A0 If there are IAB members reading this mailing list, I would be =
interested in reading their explanation about why the following is
considered as technical: http:/r.elandsys.com/r/41848=C2=A0


Though the docum= ents under discussion are, of course, technical, this was primarily a proce= ss appeal.

regards,

= Ted Hardie

--00000000000063b1cc059c58393a-- From nobody Sun Jan 19 18:13:18 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33481120071 for ; Sun, 19 Jan 2020 18:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=G3tBlq4A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ven0lpDA 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 cQX9MGjvc2BD for ; Sun, 19 Jan 2020 18:13:15 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9268512001E for ; Sun, 19 Jan 2020 18:13:15 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 881E021F14; Sun, 19 Jan 2020 21:13:14 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 19 Jan 2020 21:13:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=y yWnVuGS5dwJIsigPJKqpiAeuqUhsaT+3tv9HT/Jnl4=; b=G3tBlq4Ad3371novt 9VSPICaph0izasP/+BURf1CG6gBKbd1JqDpKGR3oPJIVF9kUXWtiLMgVBKh2SQ/2 OxWfFTDz/xRbqluhu/fucDUtPzAsUsYshkasnGrf+bMT24Zvh53/2LD28BwEZopO povmhydaGqqM14wx7DMoHnv+6lnWmpzGm4AF0jIG3sK3E7oHw/LFfhY6PcEsmVCb qVNiL8Cc1Tk2A6ZY0ARQpTR3qQZreDtYJ7wA8nq9hyRXCSY5NvR0zvqyPV8E/IO5 D8nE5yVt9i36u69rr7ymVuo45aEyAJyrvCXsAKuBQt4571y6Xoo3pwjwyjEi0/gZ 2knbg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=yyWnVuGS5dwJIsigPJKqpiAeuqUhsaT+3tv9HT/Jn l4=; b=Ven0lpDACVZ9Rj17peanwsAn549lMPN1PiUs+OJEsJIt9piJUnTWkMY8p 8GoSm+FpAZvl7DGEkH3fFCBn7UXaKdroKUk1j9z7tkOqen4TgEZpostUFPCm47iL Rv0J67AdiTou0CDFh+44Ba2OaUd0mK2HF7NrexGDkKFVEFgtQuDsbyNDyljCr6oz 2XLKXRT2P+S2kCLddb+vLfam+eW6lfEY57Gx20BwyxXDmGudmCrP/kVl+LICr6ds x8B+5xe6mzGPSKzhOo73gbgcpIt476tvCXIgpAZDpg4MfLk4nBN7tQtP2J1WmA1q uD5swh7wQbgryvMuapsa9S/9Mp3Fg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeggdegvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrdduje drudehkedrvdehudenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdr nhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 0CFF13060B12; Sun, 19 Jan 2020 21:13:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Mark Nottingham In-Reply-To: <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> Date: Mon, 20 Jan 2020 13:13:10 +1100 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [arch-d] New Version Notification for draft-iab-for-the-users-01.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 02:13:17 -0000 Hi SM, Well spotted.=20 I've modified the text in my copy: "Even before the IETF was established, the Internet technical community = has focused on user needs since at least {{?RFC0001}}, which stated..." Cheers and thanks, > On 15 Dec 2019, at 2:22 am, S Moonesamy wrote: >=20 > Hi Mark, >=20 > There is the following in Section 3: "The IETF has focused on user = needs since [RFC0001] ..." That is like stating that the IETF has = focused on user needs since 1969. How could that be possible if the = first IETF meeting was held in 1986? >=20 > Regards, > S. Moonesamy >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jan 20 16:40:27 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4988120835 for ; Mon, 20 Jan 2020 16:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 Z6yXzQtSgxst for ; Mon, 20 Jan 2020 16:40:24 -0800 (PST) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25646120831 for ; Mon, 20 Jan 2020 16:40:24 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id p125so1006290oif.10 for ; Mon, 20 Jan 2020 16:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=phPPcFHEzjbWtQ4d2WGC8Lyg/BgcX9jM2M1J7BVVQr4=; b=dnoCExlRAV3Aj3+OMqKWer8pr9Osu/rJzK8BYnMZF2rDfQ4X3LUC865+aXoJp5rmf5 4aKn9hRQz7HP+8rqZNZv2y4hEYDpE6iRZ2Dngbc9GrUgSx0dhtYgpVxwcWpALOX5MbYb +8sEFpQfiAQB57C3uexT4QvF9mhIE7vzyCzitUV4Wn1ZLYSugtc3GP5vmolBw0RwLLyE x4tZOGxsPgFIx6lurf4/+yEFUSRwE58QjzgfjupCyAmzpYa4iGETqa+Jiqr0M6/TE9JS snxN0Dan5RaBlt9acyY4SNjSIWEj2O553Ws4AsdWm6sqr1QF63OYbObwjOAqexg3O17a E78Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=phPPcFHEzjbWtQ4d2WGC8Lyg/BgcX9jM2M1J7BVVQr4=; b=rukUf2S+hU5zcVhLSPV7uZToqV/DWaI8F+wcMsmL9D3KEpQJkTmsXivKw1XJHUG/Vd qZADHqXMJrGQwsZ0vlmEX0JDaPkApueNzxHdGoNVwjilSJ03nYVJ0vRLaSGtJuiZxrj3 XLDkK4nSXqvHT94OgnkZcFWXdMp2SMvUREHAlUN/+mClsVtYTYC0BOirfnCOQ2CDa8iU zm0FyRpB19Si1GHT4qPnsXE4VJOR9J9DtIqV6NzsFIdNYoOgY7fMEiHt4qdZZDNZLHsB bfMurXfpgF+rJJF+DyIVY6VTxpLcPpAliXFJcthL5Wtnza0dDKEKdkM2mKmOPQaHk9ff 5IXQ== X-Gm-Message-State: APjAAAU1ZxOoyqPZzLiqwzsbpnZGO1g8icFYeqorhuJ219PJM9YpVu2q wrajkJIWvQ2nj19NPIMxH2z7lO90BL8akrBlrPw= X-Google-Smtp-Source: APXvYqyXsK0cywwzreqrqlO0qRFaPADZ8XiyinZXwGOp3Wrtiz49cs/4A42AHO+q+RaoRp09UsThoP8DEobw1yIh180= X-Received: by 2002:aca:f354:: with SMTP id r81mr1101418oih.90.1579567223447; Mon, 20 Jan 2020 16:40:23 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Mon, 20 Jan 2020 16:40:22 -0800 (PST) In-Reply-To: <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> From: Guntur Wiseno Putra Date: Tue, 21 Jan 2020 07:40:22 +0700 Message-ID: To: Mark Nottingham Cc: S Moonesamy , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="00000000000040a25d059c9ba7d7" Archived-At: Subject: [arch-d] Fwd: New Version Notification for draft-iab-for-the-users-01.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 00:40:27 -0000 --00000000000040a25d059c9ba7d7 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, I finded this program concerned with "User": "Design Expectations vs Deployment Reality" (IAB. June 2019)--one, as I could remember, has not been mentioned/announced explicitly/exclusively but can be traced with the issue "Centralizaton or diversity" in this architecture-discuss list: a concern with "User" was a point of departure as it said about deployment models have potentials to users and future protocol evolution: https://www.iab.org/activities/workshops/dedr-workshop/ One of its papers presented was "Great Expectations: Protocol Design and Socio-economic Realities" (Dirk Kutscher) attempted to touch the real world conditions, socio-economic initiatives, of the Internet architecture, thus "Users" of the Internet technology made possible by the architecture. https://www.iab.org/wp-content/IAB-uploads/2019/05/p14- kutscher-internet-design-kutscher.pdf Regard, Guntur Wiseno Putra Pada Senin, 20 Januari 2020, Mark Nottingham menulis: > Hi SM, > > Well spotted. > > I've modified the text in my copy: > > "Even before the IETF was established, the Internet technical community > has focused on user needs since at least {{?RFC0001}}, which stated..." > > Cheers and thanks, > > > > On 15 Dec 2019, at 2:22 am, S Moonesamy wrote: > > > > Hi Mark, > > > > There is the following in Section 3: "The IETF has focused on user needs > since [RFC0001] ..." That is like stating that the IETF has focused on > user needs since 1969. How could that be possible if the first IETF > meeting was held in 1986? > > > > Regards, > > S. Moonesamy > > > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --00000000000040a25d059c9ba7d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

I finded this program concern= ed with "User": "Design Expectations vs Deployment Reality&q= uot; (IAB. June 2019)--one, as I could remember, has not been mentioned/ann= ounced explicitly/exclusively but can be traced with the issue "Centra= lizaton or diversity" in this architecture-discuss list: a concern wit= h "User" was a point of departure as it said about deployment mod= els have potentials to users and future protocol evolution:

<= /div>


One of its papers presen= ted was "Great Expectations: Protocol Design and Socio-economic Realit= ies" (Dirk Kutscher) attempted to touch the real world conditions, soc= io-economic initiatives, of the Internet architecture, thus "Users&quo= t; of the Internet technology made possible by the architecture.
=

Regard,
Gun= tur Wiseno Putra

Pada Senin, 20 Januari 2020, Mark Nottingham <mnot@mnot.net> menu= lis:
Hi SM,

Well spotted.

I've modified the text in my copy:

"Even before the IETF was established, the Internet technical communit= y has focused on user needs since at least {{?RFC0001}}, which stated...&qu= ot;

Cheers and thanks,


> On 15 Dec 2019, at 2:22 am, S Moonesamy <sm+ietf@elandsys.com> wrote:
>
> Hi Mark,
>
> There is the following in Section 3: "The IETF has focused on use= r needs since [RFC0001] ..."=C2=A0 That is like stating that the IETF = has focused on user needs since 1969.=C2=A0 How could that be possible if t= he first IETF meeting was held in 1986?
>
> Regards,
> S. Moonesamy
>

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

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--00000000000040a25d059c9ba7d7-- From nobody Tue Jan 21 18:23:30 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1821812002F for ; Tue, 21 Jan 2020 18:23:29 -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_HELO_NONE=0.001, 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 XCOy_UkehcS1 for ; Tue, 21 Jan 2020 18:23:25 -0800 (PST) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (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 17C41120013 for ; Tue, 21 Jan 2020 18:23:25 -0800 (PST) Received: by mail-ot1-x343.google.com with SMTP id r27so4922528otc.8 for ; Tue, 21 Jan 2020 18:23:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cEGmK7y/UCH3ZIGfwfo6oaNfZrqwXkqx5+KwGxbUHfs=; b=oIJdpQm1jafq/J3+huadPYPCXRdCGTUDBK4g1fFQbQAKVY/Gex2UcQe69hpNnCxvX0 DTnWeidpSKx23F3fa9htUYEp5im5A77AHdSYKagTEVGrebzbzSiUWg0pdLXazYmHVXDL 5LB+/5XdRwpBZZ/RInORPBxfGQntj0AW0sTXEw/Bk8dSPQOpwsZw1s8sDg0t+N6RwnFX lLNY9CSnzEs8ckQJ2lYCLL4eGvTtZTNiaO7LLXmUck1mDbf/Z/SCZlV1BlAb6Kb9ObbZ 2Y93fFVHF98fFZQDWTT1R8dhzZQg28pfj5HLPWwfuewYKRRKUlHB2y7TiN9jP6vxM9fW gB2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cEGmK7y/UCH3ZIGfwfo6oaNfZrqwXkqx5+KwGxbUHfs=; b=qggLt0Uh1jyImoUIij/8yWGOJSayZHglfJanK64VeYrlAR+3EQ/ym50zBVZbvbbcTl Vlx22tJBCjBejzSWkbBXFUVNnhcbTIpT6WsKthIm2qmqQloqNjv1qRrh76ztGAglNcmX wRiWhiRmdcBB0zZrusJuTcYg/XScX75KZU0Fuifs81qc4aedA+3JOfzZcMGtEiiyNORg wcOY6bCfkjtvqArhsP+zALBCVRMyEQ4wSh2KIxJuJ6UKtqHFe6vKsLKIadu3+/8v2xTn D4htZzAn21o9y6F3rF6dWi/Cs5UwsI7bHeYEnNPLYmD0kEig6X1Mfnc2KTaOYO8AcAUz 0Iuw== X-Gm-Message-State: APjAAAVe36ogNLiYWU2VJ4mM645KMr1RW9GhTE4tJNxw/lN3fMOI9Kmu YrQ7EA55wRwHecG7Hc6iiXHVPZ7usTU+ILGbl9E= X-Google-Smtp-Source: APXvYqyDxUxq1ksS+eilQYiMEWilhtlZMYEy61CmiVOin3bCiGi46A4AbGYNQSUeNco5opt+nGfcpzB3+/6Yqov5QrU= X-Received: by 2002:a9d:7519:: with SMTP id r25mr5782096otk.284.1579659804131; Tue, 21 Jan 2020 18:23:24 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Tue, 21 Jan 2020 18:23:23 -0800 (PST) In-Reply-To: References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> <265A560E-F07F-4CB8-8D5F-6077D1419CE5@comcast.net> <20200109094537.GY8801@faui48f.informatik.uni-erlangen.de> From: Guntur Wiseno Putra Date: Wed, 22 Jan 2020 09:23:23 +0700 Message-ID: To: Toerless Eckert Cc: John Day , Andrew Campling , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007dc85d059cb135d1" Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 02:23:29 -0000 --0000000000007dc85d059cb135d1 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, The Feasible: Aesthetics and Ethics of the Internet Architecture...? Actualities to consider: what are called "consolidation in the Internet economy" or "concentration in open protocols" or "Centralized Architecture of Internet Infrastructure" (1). To the actuality mentioned above, feasibility of protocols is about particular cases and contexts and solutions when aesthetics and ethics of (social and technical/the Internet) environments is to be the plan: that is what we find in one of the past/2013 IAB "Framework for Analyzing Feasibility of Internet Protocols" (Leva, T. & H. Suommi): It proposed steps to deal with/to attempt an analysis of the feasibility of protocols of which it mentioned about "technical architecture", "value networks" and "deployment environment" in its steps. (2) (1) https ISOC https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf Sullivan, Andrew, "Three Kinds of Concentration in Open Protocols", IAB-DEDR Workshop 2019 https://www.iab.org/wp-content/IAB-uploads/2019/05/p7-sulllivan-three_kinds_concentration_ajs_dedr.pdf Arkko, Jarri, "Centralized Architecture inInternet Architecture", Internet Draft, 2019 https://www.ietf.org/id/draft-arkko-arch-infrastructure-centralisation-00.txt (2) https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submission_4.pdf It is part of the IAB-ITAT 2013 https://iab.org/activities/workshops/itat/ To add, there are meanings and values in human existences/experiences; here, "value networks" is a similar phrase to "networks of interests" --among others aesthetic and ethic ones and socio-economic ones mentioned in "Protocol Design and Socio-economic Realities" (Kurtscher, D. in the IAB-DEDR Workshop 2019) https://www.iab.org/wp-content/IAB-uploads/2019/05/p14-kutscher-internet-design-kutscher.pdf Regard, Guntur Wiseno Putra Pada Jumat, 17 Januari 2020, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > I think these posts have relevances, as approaches and perspectives (for > interpretations and evaluations), to this issue "Centralization or > Diversity ("Centralized Architecture of Internet Infrastructure") ": They > were about "Networks of Interests in Cyberspace, in Internet" and > "Aesthetics and Ethics of Cyberspace, of Internet" with a horizon of > layers of the social and engineering: > > https://mailarchive.ietf.org/arch/msg/architecture-discuss/ > 1qsfPOKu2TqbmstHg6UOAfU7NoM > > https://mailarchive.ietf.org/arch/msg/architecture-discuss/ > lP1_e4ZqEYkNTFlb6N6fommrGy0 > > > Regard, > Guntur Wiseno Putra > > Pada Jumat, 10 Januari 2020, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> Adding what I mentioned in the previous message (in trying to learn on >> "Networks conditions"): >> >> "diversity/heterogeneity" seems contradictory to "centralization" when >> the latter is about "uniformity"...? >> >> Of "blobs" (1) there are moments of active elements or primitives, a >> corresponding force of attractions, of fusions, of inflection, and of >> deformations: Does "centralization" in Internet infrastructure not >> represent those moments...? >> >> Thinking also about disciplinary interactions (thus, moments of >> disciplines) having a moment of complexity and flexibility: does such an >> analogue works for "networks conditions" to say that moments of diversities >> have also moments of uniformities...? >> >> >> (1) The quotation is fully presented below (it is how Brian Massumi >> define what Greg Lynn speaks as "blob"): >> "active elements or 'primitives' which combine to generate their own >> space. Each blob is differentiated. It is assigned (by the programmer) a >> circumference, a mass, and a corresponding force of atttaction. The force >> of attraction defines a field of influence outside the perimeter of the >> blob, and that field is in turn differentiated into zones. Closest to the >> perimeter is a zone of fusion. Any blob entering it will combine with the >> first blob to form a larger blob. Beyond the fusion zone is a zone of >> inflection, the area within which the atttactive force of the blob will >> alter the shape, and therefore the field of influence, of a neighbouring >> blob. Put a number of blob together, and their differential influenced on >> each other produce unpredictable reciprocal deformations. (Massumi 1995) >> >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Jumat, 10 Januari 2020, Guntur Wiseno Putra >> menulis: >> >>> Dear architecture-discuss, >>> >>> (It seems contradictory yet happen: "centralization" to >>> "diversity/heterogeneity" as a network condition...?) >>> >>> Toward the problematic issues on "centralization" on Internet practice, >>> such a way to arrive there is about (re)considering "network conditions": >>> here we meet with diversity/heterogeneity as the Internet draft mentioned >>> "Centralized Architecture on Internet Infrastructure". What does it mean by >>> "centralization" thus...? --how does it work/mean/value for >>> diversity/heterogeneity...? >>> >>> For diversity/heterogeneity as a network condition we may refer to >>> "liquid architecture" (1) of which other things with nuances deserve to >>> mention: "bloobs"(2), "plasm"(3), "plasmatic"(4) and "plasmatics"(5). Thus >>> we are also saying about a spatial analysis of a network condition as it >>> is about cyberspace, about Internet --and we may plan things strategically >>> about the space... >>> >>> - we may think of Internet as one among other collective matters yet it >>> is also one among other personal matters: those matters are maintaining >>> dialogues. Is it not so...in considering Internet sustainability? --at >>> least we find that Internet has a significance for planning societies of >>> nations initiated by the United Nations (see "Leveraging Tech...") >>> >>> >>> (1) "...Liquid architecture makes liquid cities, cities that change at >>> the shift of a value, where visitors with different backgrounds sec >>> different landmarks, where neighborhoods vary with ideas held in common, >>> and evolve as the ideas mature or dissolve". (Novak, Marcos, "Liquid >>> Architecture in Cyberspace" (1991) >>> https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf) >>> >>> (2) "bloobs" refers to "active element or primitive generatiing their >>> own spaces... (with possibilities of) unpredictable reciprocal >>> deformations". >>> (Massumi, Brian, "Interface and Active Space", in Cheetam, M. A, "Kant, >>> Art and Art History: Moments of Disciplines, Cambridge University Press, >>> Cambridge et all., 2001, p. 25; Cheetam refered Massumi's "Interface and >>> Active Space: Human-Machine Design" available at http://www >>> anu.edu/HRC/first_and_last/links/massumi_works.htm) >>> >>> (3) plasm refers to "a mould of matrix in which something is cast or >>> formed"; "plasma" refers to "living matter of a cell" and to "liquid part >>> of blood in which corpuscles float"; then, plasmatic refers to what is >>> related with "plasm" or "plasma". "Plasmatic" may be applied to refer to >>> "disciplinary interactions ...(having) ...multidimensional and shifting >>> cultural intensities, and that the specific contours of this matric are >>> inflected historically by the forces of which it is comprised ... (--) ...a >>> model of complexity and flexibility allowing us to understand how an active >>> element in the system... can shape and be shaped by disciplines. (Cheetam, >>> M. A, "Kant, Art and Art History: Moments of Disciplines, Cambridge >>> University Press, Cambridge et all., 2001, p. 25) >>> >>> Regard, >>> Guntur Wiseno Putra >>> >>> Pada Kamis, 09 Januari 2020, Toerless Eckert menulis: >>> >>>> Good insights about the outcome of PICS. >>>> >>>> To clarify, i am primarily interested to see if we can do something >>>> to better support static network planning and protocol evolution. >>>> >>>> Something which is more a self-declaration than a (broken) conformance >>>> suite "verified" testing result. Something which always must be >>>> followed by appropriate testing (interop, deployment) depending >>>> on the goal. But something that can help to faster get to that >>>> step. Something to to help avoid horrenduously repetitive RFP questions >>>> by poor customers (does your IETF FOO protocol on your product support >>>> the optional BAR feature). >>>> >>>> One could think of another axis of information in our yang models, >>>> a subset of "implementation defined" behavior whose values can be >>>> statically exposed without access to a live system and hence be >>>> published and then used in netork planning for example >>>> (or auto-collection by a curious WG trying to progress some >>>> standard to full internet ;-)). >>>> >>>> I was interested in the type of information i remember to have seen >>>> in the 90th in PICS, i am horrified about the process i learn >>>> about it here in te thread ;-) >>>> >>>> Cheers >>>> Toerless >>>> >>>> On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote: >>>> > FWIW, there were also problems with keeping the test suites >>>> up-to-date with the errata. Bugs could be fixed in the standards and >>>> incorporated into implementations faster than the people developing the >>>> test suites could keep up (or wanted to). Of course the fixes were in the >>>> implementations before they were in the standards. And what was worse, when >>>> pointed out to them that their test-suited didn???t conform to the spec, >>>> they didn???t care. They still insisted they were right. >>>> > >>>> > For some standards, it was possible to develop utilities that did a >>>> specific function and used part of a standard to do that function but >>>> didn???t need the rest of the standard. But the people running the test >>>> suites couldn???t deal with it. If it didn???t implement the entire >>>> protocol, it didn???t pass. The utility couldn???t cause any of the rest of >>>> the protocol to be generated. It conformed to the standard for everything >>>> it did. They were using the standard as it had been intended. >>>> > >>>> > But the testers were effectively bean-counters and totally stupid. >>>> > >>>> > Conformance fell under the ANSI committee I chaired and I remember >>>> writing them (some military base in Arizona whose name I have thankfully >>>> forgotten) nasty letters telling them to get their act together or get out. >>>> They were doing more harm than good. Wish we had known about the IS-IS >>>> issues as well to add to the list. >>>> > >>>> > One needs some way to test implementations before trying them live. >>>> But one has to treat them (and it has to be instilled in the testers) that >>>> the purpose is to help: obey Postel???s rule, find problems, and then >>>> determine whether it is the tests, the ???standard??? or the new >>>> implementation that is at fault. And above all if it isn???t externally >>>> visible, it is none of the tester???s business. Even if there is ???formal >>>> specification???, one can???t be sure that a bug is in the prose, the >>>> formal spec, the tests, or the implementation. They are all suspect. (Often >>>> formal specifications are more complex than the code. And we know what that >>>> means!) >>>> > >>>> > Years before the standards issues arose, I did a survey of testing >>>> methods for our own use. I expected to find that two or three were pretty >>>> effective, pick one or two. What I found were 20 or 25 that were all >>>> pretty effective and the advice was pick 2 or 3 and it didn???t really >>>> matter which ones as long as they were different. (Not the result I was >>>> looking for.) ;-) >>>> > >>>> > Take care, >>>> > John >>>> > >>>> > > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote: >>>> > > >>>> > > >>>> > >> Yes, i was thinking of ISO PICS. But i lost track of those ISO >>>> standards >>>> > >> since the 90th. I guess i would have to see a successfull and still >>>> > >> currently used standard and how its PICS do or do not help. Just >>>> > >> not alot of those ISO specs left in wide deployments, right. >>>> > >> X.500 ? Maybe i can get more insight from the security community. >>>> > > >>>> > > >>>> > > You need not go that far. Remember IS-IS? Still thriving. >>>> > > >>>> > > And yes, my experience with PICs and test suites comes from that. >>>> > > >>>> > > >>>> > >>> What it does do is to encourage people to write ???conformance >>>> test suites???. These then get sold to unsuspecting customers and >>>> end-users. Unfortunately, the quality of such suites is so low that you >>>> spend way, way, way more time debugging the test suite and you never find >>>> bugs in your implementation. >>>> > >> >>>> > >> This is just the worst possible outcome, and i am sure one can >>>> learn >>>> > >> from those bad experiences. Just think of taking a more organized >>>> > >> step towards being able to collect protocol implementation >>>> information >>>> > >> from the industry. Right now every WG who wants to raise the level >>>> of >>>> > >> an IETF protocol, e.g.: to(wards) full standard is coming up with a >>>> > >> questionaire in an ad-hoc fashion (we're just doing this in >>>> Multicast >>>> > >> for IGMP/MLD). >>>> > > >>>> > > >>>> > > You can do that if you like, but the one proven, effective method >>>> is interoperability testing. >>>> > > >>>> > > Running code trumps questionaires, conformance test suites, theory, >>>> and mandate. >>>> > > >>>> > > >>>> > >> My point was: If the only murphy you have is competitive pressure, >>>> it works not >>>> > >> it there is only limited competition, such as a total of maybe no >>>> > >> more than 3 competing national infrastructures. >>>> > > >>>> > > >>>> > > And countries that stifle competition inflict vendor lock on >>>> themselves. >>>> > > >>>> > > >>>> > >> See above. The best i think we (IETF) can do is to educate better >>>> about >>>> > >> this by appropriate documents. Certainly some additional protocol >>>> work >>>> > >> will result from that. I for once had simple slides 10 years ago >>>> how to fixup >>>> > >> non-dual plane networks to be dual-plane. And maybe we can come up >>>> with >>>> > >> questionaires to get better numbers from actual deployments (the >>>> > >> PICS discussion). >>>> > > >>>> > > >>>> > > The IETF???s job is not education. It does not work as the >>>> education is not requested >>>> > > and not welcome. The IETF???s job is standards and it needs to >>>> focus on that. >>>> > > >>>> > > >>>> > >> Figuring out ideas for a complete ecosystem of monetization and >>>> > >> deployment between competition and regulation is better left for >>>> > >> an ongoing bar-bof with emphasis on bar. >>>> > > >>>> > > >>>> > > I concur. Let???s stop fooling ourselves into thinking that >>>> anything that the IAB/IETF writes has any impact >>>> > > on regulation or economics. >>>> > > >>>> > > >>>> > >> Actually one of the interesting conclusions was that dual-plane in >>>> > >> many cases is really free but deployments often just don't fully >>>> > >> utilize it. >>>> > > >>>> > > >>>> > > I???d agree that it???s close to free. If you accept that you need >>>> a dual-plane approach for resiliency, then >>>> > > adding a second vendor to the mix is relatively easy. There???s >>>> additional cost because of decreased >>>> > > purchasing volume. There???s additional costs in management and >>>> operations. >>>> > > >>>> > > However, as compared to the costs of an unnecessary outage, it???s >>>> still trivial. >>>> > > >>>> > > Tony >>>> > > >>>> > > _______________________________________________ >>>> > > Architecture-discuss mailing list >>>> > > Architecture-discuss@ietf.org >>>> > > https://www.ietf.org/mailman/listinfo/architecture-discuss >>>> >>>> -- >>>> --- >>>> tte@cs.fau.de >>>> >>>> _______________________________________________ >>>> Architecture-discuss mailing list >>>> Architecture-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>>> >>> --0000000000007dc85d059cb135d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,



The Feasible:
Aesthetics and Ethics of the Internet Architecture...?


Actualities to consider: what are called "consolidation in the Interne= t economy" or "concentration in open protocols" or "Cen= tralized Architecture of Internet Infrastructure" (1).


To the actuality mentioned above, feasibility of protocols is about particu= lar cases and contexts and solutions when aesthetics and ethics of (social = and technical/the Internet) environments is to be the plan: that is what we= find in one of the past/2013 IAB "Framework for Analyzing Feasibility= of Internet Protocols" (Leva, T. & H. Suommi): It proposed steps = to deal with/to attempt an analysis of the feasibility of protocols of whic= h it mentioned about "technical architecture", "value networ= ks" and "deployment environment" in its steps. (2)





(1) https ISOC
https://future.internetsociety.org/2019/wp-content/uploads/site= s/2/2019/04/InternetSociety-GlobalInternetReport-ConsolidationintheInternet= Economy.pdf

Sullivan, Andrew, "Three Kinds of Concentration in Open Protocols"= ;, IAB-DEDR Workshop 2019
https://www.iab.org/wp-content/IAB-= uploads/2019/05/p7-sulllivan-three_kinds_concentration_ajs_dedr.pdf

Arkko, Jarri, "Centralized Architecture inInternet Architecture",= Internet Draft, 2019
https://www.ietf.org/id/draft-arkko-arch-infrastructure-cent= ralisation-00.txt


(2) https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-= 2013_submission_4.pdf
It is part of the IAB-ITAT 2013
https://iab.org/acti= vities/workshops/itat/
To add, there are meanings and values in human existences/experiences; here= , "value networks" is a similar phrase to "networks of inter= ests" --among others aesthetic and ethic ones and socio-economic ones = mentioned in "Protocol Design and Socio-economic Realities" (Kurt= scher, D. in the IAB-DEDR Workshop 2019)
https://www.iab.org/wp-content/IAB-uploads/20= 19/05/p14-kutscher-internet-design-kutscher.pdf


Regard,
Guntur Wiseno Putra

Pada Juma= t, 17 Januari 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
= Dear architecture-discuss,

I think these posts have rele= vances, as approaches and perspectives (for interpretations and evaluations= ), to this issue "Centralization or Diversity ("Centralized Archi= tecture of Internet Infrastructure") ": They were about "Net= works of Interests in Cyberspace, in Internet" and =C2=A0"Aesthet= ics and Ethics of Cyberspace, of Internet" with a horizon of layers of= the social and engineering:


https://mailarchive.ietf.org/arch/msg/architecture-discuss/lP1_e4ZqEYkNTFlb6N6fommrGy0


Regard,
Guntur Wiseno Putra=

Pada Jumat, 10 Januari 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:=
Dear architecture-discuss,

Adding what I mentioned in the previous message (in trying to = learn on "Networks conditions"):=C2=A0

"diversity/heterogeneity" seems contradictory to "centrali= zation" when the latter is about "uniformity"...?

Of "blobs" (1) there are moments of active eleme= nts or primitives, a corresponding force of attractions, of fusions, of inf= lection, and of deformations: Does "centralization" in Internet i= nfrastructure not represent those moments...?=C2=A0

Thinking also about disciplinary interactions (thus, moments of discipl= ines) having a moment of complexity and flexibility: does such an analogue = works for "networks conditions" to say that moments of diversitie= s have also moments of uniformities...?


(1) The quotation is fully presented below (it is how Brian Massumi= define what Greg Lynn speaks as "blob"):
"active= elements or 'primitives' which combine to generate their own space= . Each blob is differentiated. It is assigned (by the programmer) a circumf= erence, a mass, and a corresponding force of atttaction. The force of attra= ction defines a field of influence outside the perimeter of the blob, and t= hat field is in turn differentiated into zones. Closest to the perimeter is= a zone of fusion. Any blob entering it will combine with the first blob to= form a larger blob. Beyond the fusion zone is a zone of inflection, the ar= ea within which the atttactive force of the blob will alter the shape, and = therefore the field of influence, of a neighbouring blob. Put a number of b= lob together, and their differential influenced on each other produce unpre= dictable reciprocal deformations. (Massumi 1995)

=

Regard,
Guntur Wiseno Putra

Pada Jumat= , 10 Januari 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

(It seems co= ntradictory yet happen: "centralization" to "diversity/heter= ogeneity" as a network condition...?)

Toward = the problematic issues on "centralization" on Internet practice, = such a way to arrive there is about (re)considering "network condition= s": here we meet with diversity/heterogeneity as the Internet draft me= ntioned "Centralized Architecture on Internet Infrastructure". Wh= at does it mean by "centralization" thus...? --how does it work/m= ean/value for diversity/heterogeneity...?

For dive= rsity/heterogeneity as a network condition we may refer to "liquid arc= hitecture" (1) of which other things with nuances deserve to mention: = "bloobs"(2), "plasm"(3), "plasmatic"(4) and &= quot;plasmatics"(5). Thus we are also =C2=A0saying about a spatial ana= lysis of a network condition as it is about cyberspace, about Internet --an= d we may plan things strategically about the space...

<= div>- we may think of Internet as one among other collective matters yet it= is also one among other personal matters: =C2=A0those matters are maintain= ing dialogues. Is it not so...in considering Internet sustainability? --at = least we find that Internet has a significance for planning societies of na= tions initiated by the United Nations (see "Leveraging Tech...")<= br>


(1) "...Liquid a= rchitecture makes liquid cities, cities that change at the shift of a value= , where visitors with different backgrounds sec different landmarks, where = neighborhoods vary with ideas held in common, and evolve as the ideas matur= e or dissolve". (Novak, Marcos, "Liquid Architecture in Cyberspac= e" (1991) =C2=A0=C2=A0

(2) "bloobs" refers to "a= ctive element or primitive generatiing their own spaces... (with possibilit= ies of) unpredictable reciprocal deformations".=C2=A0
(Massu= mi, Brian, "Interface and Active Space", =C2=A0in Cheetam, M. A, = "Kant, Art and Art History: Moments of Disciplines, Cambridge Universi= ty Press, Cambridge et all., 2001, p. 25; Cheetam refered Massumi's &qu= ot;Interface and Active Space: Human-Machine Design" available at=C2= =A0http://www=C2=A0anu.edu/HRC/firs= t_and_last/links/massumi_works.htm)

(3) p= lasm refers to "a mould of matrix in which something is cast or formed= "; "plasma" refers to "living matter of a cell" an= d to "liquid part of blood in which corpuscles float"; then, plas= matic refers to what is related with "plasm" or "plasma"= ;. "Plasmatic" may be applied to refer to "disciplinary inte= ractions ...(having) ...multidimensional and shifting cultural intensities,= and that the specific contours of this matric are inflected historically b= y the forces of which it is comprised ... (--) ...a model of complexity and= flexibility allowing us to understand how an active element in the system.= .. can shape and be shaped by disciplines. (Cheetam, M. A, "Kant, Art = and Art History: Moments of Disciplines, Cambridge University Press, Cambri= dge et all., 2001, p. 25)

Regard,
Guntur= Wiseno Putra

Pada Kamis, 09 Januari 2020, Toerless Eckert <tte@cs.fau.de> menulis= :
Good insights about the outcome of PICS= .

To clarify, i am primarily interested to see if we can do something
to better support static network planning and protocol evolution.

Something which is more a self-declaration than a (broken) conformance
suite "verified" testing result. Something which always must be followed by appropriate testing (interop, deployment) depending
on the goal. But something that can help to faster get to that
step. Something to to help avoid horrenduously repetitive RFP questions
by poor customers (does your IETF FOO protocol on your product support
the optional BAR feature).

One could think of another axis of information in our yang models,
a subset of "implementation defined" behavior whose values can be=
statically exposed without access to a live system and hence be
published and then used in netork planning for example
(or auto-collection by a curious WG trying to progress some
standard to full internet ;-)).

I was interested in the type of information i remember to have seen
in the 90th in PICS, i am horrified about the process i learn
about it here in te thread ;-)

Cheers
=C2=A0 =C2=A0 Toerless

On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote:
> FWIW, there were also problems with keeping the test suites up-to-date= with the errata.=C2=A0 Bugs could be fixed in the standards and incorporat= ed into implementations faster than the people developing the test suites c= ould keep up (or wanted to). Of course the fixes were in the implementation= s before they were in the standards. And what was worse, when pointed out t= o them that their test-suited didn???t conform to the spec, they didn???t c= are. They still insisted they were right.
>
> For some standards, it was possible to develop utilities that did a sp= ecific function and used part of a standard to do that function but didn???= t need the rest of the standard. But the people running the test suites cou= ldn???t deal with it. If it didn???t implement the entire protocol, it didn= ???t pass. The utility couldn???t cause any of the rest of the protocol to = be generated. It conformed to the standard for everything it did. They were= using the standard as it had been intended.
>
> But the testers were effectively bean-counters and totally stupid.
>
> Conformance fell under the ANSI committee I chaired and I remember wri= ting them (some military base in Arizona whose name I have thankfully forgo= tten) nasty letters telling them to get their act together or get out. They= were doing more harm than good. Wish we had known about the IS-IS issues a= s well to add to the list.
>
> One needs some way to test implementations before trying them live.=C2= =A0 But one has to treat them (and it has to be instilled in the testers) t= hat the purpose is to help:=C2=A0 obey Postel???s rule, find problems, and = then determine whether it is the tests, the ???standard??? or the new imple= mentation that is at fault. And above all if it isn???t externally visible,= it is none of the tester???s business.=C2=A0 Even if there is ???formal sp= ecification???, one can???t be sure that a bug is in the prose, the formal = spec, the tests, or the implementation. They are all suspect. (Often formal= specifications are more complex than the code. And we know what that means= !)
>
> Years before the standards issues arose, I did a survey of testing met= hods for our own use. I expected to find that two or three were pretty effe= ctive, pick one or two.=C2=A0 What I found were 20 or 25 that were all pret= ty effective and the advice was pick 2 or 3 and it didn???t really matter w= hich ones as long as they were different. (Not the result I was looking for= .)=C2=A0 ;-)
>
> Take care,
> John
>
> > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote:
> >
> >
> >> Yes, i was thinking of ISO PICS. But i lost track of those IS= O standards
> >> since the 90th. I guess i would have to see a successfull and= still
> >> currently used standard and how its PICS do or do not help. J= ust
> >> not alot of those ISO specs left in wide deployments, right.<= br> > >> X.500 ? Maybe i can get more insight from the security commun= ity.
> >
> >
> > You need not go that far.=C2=A0 Remember IS-IS?=C2=A0 Still thriv= ing.=C2=A0
> >
> > And yes, my experience with PICs and test suites comes from that.=
> >
> >
> >>> What it does do is to encourage people to write ???confor= mance test suites???.=C2=A0 These then get sold to unsuspecting customers a= nd end-users.=C2=A0 Unfortunately, the quality of such suites is so low tha= t you spend way, way, way more time debugging the test suite and you never = find bugs in your implementation.
> >>
> >> This is just the worst possible outcome, and i am sure one ca= n learn
> >> from those bad experiences. Just think of taking a more organ= ized
> >> step towards being able to collect protocol implementation in= formation
> >> from the industry. Right now every WG who wants to raise the = level of
> >> an IETF protocol, e.g.: to(wards) full standard is coming up = with a
> >> questionaire in an ad-hoc fashion (we're just doing this = in Multicast
> >> for IGMP/MLD).
> >
> >
> > You can do that if you like, but the one proven, effective method= is interoperability testing.
> >
> > Running code trumps questionaires, conformance test suites, theor= y, and mandate.
> >
> >
> >> My point was: If the only murphy you have is competitive pres= sure, it works not
> >> it there is only limited competition, such as a total of mayb= e no
> >> more than 3 competing national infrastructures.
> >
> >
> > And countries that stifle competition inflict vendor lock on them= selves.
> >
> >
> >> See above. The best i think we (IETF) can do is to educate be= tter about
> >> this by appropriate documents. Certainly some additional prot= ocol work
> >> will result from that. I for once had simple slides 10 years = ago how to fixup
> >> non-dual plane networks to be dual-plane. And maybe we can co= me up with
> >> questionaires to get better numbers from actual deployments (= the
> >> PICS discussion).
> >
> >
> > The IETF???s job is not education. It does not work as the educat= ion is not requested
> > and not welcome. The IETF???s job is standards and it needs to fo= cus on that.
> >
> >
> >> Figuring out ideas for a complete ecosystem of monetization a= nd
> >> deployment between competition and regulation is better left = for
> >> an ongoing bar-bof with emphasis on bar.
> >
> >
> > I concur. Let???s stop fooling ourselves into thinking that anyth= ing that the IAB/IETF writes has any impact
> > on regulation or economics.
> >
> >
> >> Actually one of the interesting conclusions was that dual-pla= ne in
> >> many cases is really free but deployments often just don'= t fully
> >> utilize it.
> >
> >
> > I???d agree that it???s close to free.=C2=A0 If you accept that y= ou need a dual-plane approach for resiliency, then
> > adding a second vendor to the mix is relatively easy. There???s a= dditional cost because of decreased
> > purchasing volume. There???s additional costs in management and o= perations.
> >
> > However, as compared to the costs of an unnecessary outage, it???= s still trivial.
> >
> > Tony
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architec= ture-discuss

--
---
tte@cs.fau.de

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--0000000000007dc85d059cb135d1-- From nobody Thu Jan 23 03:28:37 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A310C12003E for ; Thu, 23 Jan 2020 03:28:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=elandsys.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 8r5uIkLBBZlI for ; Thu, 23 Jan 2020 03:28:34 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id C5FBD12001E for ; Thu, 23 Jan 2020 03:28:34 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.1.174]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00NBSKjl003112 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jan 2020 03:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579778912; x=1579865312; i=@elandsys.com; bh=BpIVQTTqUro+XsJ5VldEWcbOPmCzMScFNl0XA/4cTY0=; h=Date:To:From:Subject:In-Reply-To:References; b=USe1MsisKes9r3Lb+GRgEfMyKdS34G6Gz4AUSScq75kJSlN9PcRSDa4PSR4ZyAL+F oFCfDdW488RzV3KeoNAC8ZxUbapVAb7oOdx3GG78CLucAgpMQkPvCBn1Wthopa7lz1 Sfw6R/zDPt+hiur5Nf+fm+0ck4UKjM6JjSyu8ReA= Message-Id: <6.2.5.6.2.20200123013903.0be41930@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Jan 2020 03:25:55 -0800 To: Mark Nottingham , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] New Version Notification for draft-iab-for-the-users-01.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 11:28:36 -0000 Hi Mark, At 06:13 PM 19-01-2020, Mark Nottingham wrote: >Well spotted. > >I've modified the text in my copy: > >"Even before the IETF was established, the Internet technical >community has focused on user needs since at least {{?RFC0001}}, >which stated..." Thanks for the feedback. I took a look at -02. I would like to clarify my opinion is not representative of the views of the users from any region. There is an ongoing discussion in an IRTF Research Group about the third paragraph in Section 1 (re. it has unavoidably become profoundly political ...) Section 3 adds a question mark on RFC 3935. Section 4.1 uses the terms "broader Internet community" and "greater Internet community". Do those qualifiers change the meaning of "Internet community"? If so, why are they not used in Section 4? There is the following text in Section 4.1: "Government representatives sometimes participate in the IETF community." When are those representatives representative of end-users? There is the following near the end of Section 4.1: "we should remember that the RFC series are Requests For Comments". I requested that my comments on a draft be ignored as an IETF Area Director gave me a very original response. If that were to reflect the Internet Engineering Steering Group's position on comments, I doubt that IETF Stream could be viewed as conducive for request for comments. I agree that merely saying that something is harmful (Section 4.3) is not a convincing argument. However, is it reasonable to expect an end-user to explain how the technical specification causes, or might cause, "harm"? Regards, S. Moonesamy From nobody Thu Jan 23 21:36:37 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BC0120041 for ; Thu, 23 Jan 2020 21:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=1py7UIfF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jQ/geIkx 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 e_i6ZWcLOJwc for ; Thu, 23 Jan 2020 21:36:33 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56578120020 for ; Thu, 23 Jan 2020 21:36:33 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 8174B736; Fri, 24 Jan 2020 00:36:32 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 24 Jan 2020 00:36:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=C +7YeXfrPazoh9hkQhajgZdzX/5KiX2LgWgnkgC3YaY=; b=1py7UIfFXAMhMC3QM 9Kpa+CgBb7nuusgWre19V+xuoWI/Yk0Onghx+mjMauvifYvM3gjJTd+wB/abmH6O yc6BZcRoFUInCsjJYGZeaQ+0qkHHXu3ihP1QmBlcjnrqvdrf0WB99nOXz0nxholM gnqJlriJW3RkJzN2wKgmFCiBHXm8XVKHNP5LOQknJKup751UwpAXCG8NqY/PHwyK 7wllS0Zizc0UBTbfgf4AGONOablZ9Iv+7lBCEQCEU5KGxVzFTw7U5T2x3ZZ0mxRb +1YML6Ma/UbtlB+hU8mL/1BLlFffIkdSxIIA+voYjK8+Ry70O/Hkj2/O9KVaDsh/ N0NIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=C+7YeXfrPazoh9hkQhajgZdzX/5KiX2LgWgnkgC3Y aY=; b=jQ/geIkxelEdLSonPb3B8AbGDuZ/1RqIQ8d69zlm2S+EpPALTIzGzd7UZ b1Wyjeqyv48O8uPQE5v8HGAIY4yUmGof5liZUWNNQOsepr1TbYxWA6ekHNA0/SuE UN0VIH2QO49v5c9N+ySFW/p0Gkn4GBGE1E+BK2D5+U+41iLpi5cSZOyiwen1GdE+ UrxdeNiIonfca7ZCrDMaAM+e+mEiSd9ORtJhoscLbO4fquEEDRx0KlSR1L6fcnhW mg4Dz9wf6J97rHims1jdrc7UCDZc0LL6O7eUimHRgC7RXaYw53XiO5ZePvEv5Lc+ mef2fO1ZbVhtzJc+HjMlR2wrdDT7Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrvdefgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrdduje drudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 048613280059; Fri, 24 Jan 2020 00:36:29 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Mark Nottingham In-Reply-To: <6.2.5.6.2.20200123013903.0be41930@elandnews.com> Date: Fri, 24 Jan 2020 16:36:26 +1100 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> <6.2.5.6.2.20200123013903.0be41930@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [arch-d] New Version Notification for draft-iab-for-the-users-01.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 05:36:36 -0000 > On 23 Jan 2020, at 10:25 pm, S Moonesamy wrote: >=20 > Hi Mark, > At 06:13 PM 19-01-2020, Mark Nottingham wrote: >> Well spotted. >>=20 >> I've modified the text in my copy: >>=20 >> "Even before the IETF was established, the Internet technical = community has focused on user needs since at least {{?RFC0001}}, which = stated..." >=20 > Thanks for the feedback. >=20 > I took a look at -02. I would like to clarify my opinion is not = representative of the views of the users from any region. Thank you. > There is an ongoing discussion in an IRTF Research Group about the = third paragraph in Section 1 (re. it has unavoidably become profoundly = political ...) >=20 > Section 3 adds a question mark on RFC 3935. I'm not sure what you mean. I don't see a literal question mark near the = reference in the published text document. > Section 4.1 uses the terms "broader Internet community" and "greater = Internet community". Do those qualifiers change the meaning of = "Internet community"? If so, why are they not used in Section 4? They are contrasting the IETF community with the (broader, greater) = Internet community. > There is the following text in Section 4.1: "Government = representatives sometimes participate in the IETF community." When are = those representatives representative of end-users? I think they're representative of governments.=20 > There is the following near the end of Section 4.1: "we should = remember that the RFC series are Requests For Comments". I requested = that my comments on a draft be ignored as an IETF Area Director gave me = a very original response. If that were to reflect the Internet = Engineering Steering Group's position on comments, I doubt that IETF = Stream could be viewed as conducive for request for comments. I'm not sure there's anything actionable in your statement here, so I'll = just move on. > I agree that merely saying that something is harmful (Section 4.3) is = not a convincing argument. However, is it reasonable to expect an = end-user to explain how the technical specification causes, or might = cause, "harm"? As explained elsewhere in the document, we don't rely on end users = coming to present their case in person, as it were.=20 Cheers and thanks for the feedback, -- Mark Nottingham https://www.mnot.net/ From nobody Fri Jan 24 01:54:53 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD12F1200CC for ; Fri, 24 Jan 2020 01:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 SCovf3SM2OXh for ; Fri, 24 Jan 2020 01:54:49 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3451200BA for ; Fri, 24 Jan 2020 01:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4926; q=dns/txt; s=iport; t=1579859689; x=1581069289; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=JFSwpJYFwU/Ft0jj/cUCxX4y5lYO2NtauW1raWLCsUU=; b=IH/RmdiZrDsF4HDG08ks8yJhCIEA8sa1DAj+fcyx5ilUbpe1IJSwOPZY yBkY9DgZg3fOQq/gpUv719KgFjK45aMankN4F6t7Rk9pFx3OZMwVk9407 W09hgb+yphMLN0fQhBRDRjwPzGnPt0/iZGezRnofoP8AYgIJJlxpUdRcP E=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQAHvipe/xbLJq1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoEAQELAYEkgQSBYRIqhBKJA4g0hz2LcIgLAgcBAQEJAwEBLwE?= =?us-ascii?q?BhEACgkY3Bg4CAw0BAQQBAQECAQUEbYVDhV4BAQEBAgEjSAwCBQsLBAoKKgI?= =?us-ascii?q?CVwYTFIMSAYJbIKtjdYEyhUqEaBCBOAGBUopeggCBOCCCTD6HWTKCLASXNJg?= =?us-ascii?q?kgkOCTIEckk4bmnymPoMuAgQGBQIVgWgjPoEaMxoIGxVlAYFZaD4SGA2WSEA?= =?us-ascii?q?DMI0pAQE?= X-IronPort-AV: E=Sophos;i="5.70,357,1574121600"; d="asc'?scan'208,217";a="22515532" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jan 2020 09:54:45 +0000 Received: from dhcp-10-61-103-205.cisco.com (dhcp-10-61-103-205.cisco.com [10.61.103.205]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00O9siH5001421 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Jan 2020 09:54:45 GMT From: Eliot Lear Message-Id: <9A005BFA-105F-4A2F-B746-9455B41AB843@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D1401990-1902-4CD3-9EE2-D640167E1DC6"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Fri, 24 Jan 2020 10:54:44 +0100 In-Reply-To: <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> Cc: S Moonesamy , architecture-discuss@ietf.org To: Mark Nottingham References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> <6.2.5.6.2.20200123013903.0be41930@elandnews.com> <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.103.205, dhcp-10-61-103-205.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [arch-d] New Version Notification for draft-iab-for-the-users-01.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 09:54:52 -0000 --Apple-Mail=_D1401990-1902-4CD3-9EE2-D640167E1DC6 Content-Type: multipart/alternative; boundary="Apple-Mail=_3751423A-455E-4F4D-A641-B3FBB93B2BCD" --Apple-Mail=_3751423A-455E-4F4D-A641-B3FBB93B2BCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mark, > On 24 Jan 2020, at 06:36, Mark Nottingham wrote: >=20 >> There is the following text in Section 4.1: "Government = representatives sometimes participate in the IETF community." When are = those representatives representative of end-users? >=20 > I think they're representative of governments. None of our processes assume that this is the case, but rather that they = are individuals just like anybody else. Moreover, if governments = believe that sending someone to the IETF means that they are = representing government positions, those people will be hampered in = participating in constructive dialogs. I would change the terminology a bit to say something like =E2=80=9Cgovern= ment experts=E2=80=9D, or otherwise add something of an explanatory note = to address the above. Eliot --Apple-Mail=_3751423A-455E-4F4D-A641-B3FBB93B2BCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mark,

On 24 Jan 2020, at 06:36, Mark Nottingham = <mnot@mnot.net> = wrote:

There = is the following text in Section 4.1: "Government representatives = sometimes participate in the IETF community."  When are those = representatives representative of end-users?

I think they're representative of governments. 


None of our processes assume that this is the case, but = rather that they are individuals just like anybody else.  Moreover, = if governments believe that sending someone to the IETF means that they = are representing government positions, those people will be hampered in = participating in constructive dialogs.

I would change the terminology a bit to = say something like =E2=80=9Cgovernment experts=E2=80=9D, or otherwise = add something of an explanatory note to address the above.

Eliot
= --Apple-Mail=_3751423A-455E-4F4D-A641-B3FBB93B2BCD-- --Apple-Mail=_D1401990-1902-4CD3-9EE2-D640167E1DC6 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4qvuQACgkQh7ZrRtnS ejMQMwf/V10CGg7GLgICLOsO6IUp98NPCYawkfJtOo+wTi+xW7CToAaqmL+nzPmS lo5m78AGSmIG7kNPOQYyuO3oFPnGO7aEvSAaXlb4z8/AG1eWT0ASBvvs99g16vMa f9zJHrN4gNaXUTXDlqZ3MHbo/nIU/kdBAy3xaHMng2irV7/teOj7PMGbSNEBWuuh 5ks+cyQvhNnkKv2NaJroGZLGTSpy7NTJdzaKGoPOc8o+5fiVP/woUUemgeea5PUa BbQ3CBoGmkQoJP9/pkxBHZ4IiekX13yurgULfff5tTYb0IGqsA9uLfCY0ievt2fk 9TbmCgVSoWRcn4+qMQ7qlogKqC/3RQ== =fW8m -----END PGP SIGNATURE----- --Apple-Mail=_D1401990-1902-4CD3-9EE2-D640167E1DC6-- From nobody Fri Jan 24 02:30:46 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2827E1200BA for ; Fri, 24 Jan 2020 02:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=rz4VZuXG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Zin6l1Br 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 feI2rrv2DMnj for ; Fri, 24 Jan 2020 02:30:41 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386EC1200A1 for ; Fri, 24 Jan 2020 02:30:40 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id BFE027FB; Fri, 24 Jan 2020 05:30:39 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 24 Jan 2020 05:30:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:content-transfer-encoding:from:mime-version:subject :date:message-id:references:cc:in-reply-to:to; s=fm1; bh=vzxH4LX 5Cij8qfdR0jCvFKBGhHrlwpB5vnPnOq8vN4c=; b=rz4VZuXGGtevqjUBRByJT3b fqI1uhLUTcEv9gufsnQByZPZoYopaNY+0rv1fwFJ2SITn8QhP/clqUHbYPFWl/BP GABvZ4pPgLVS1wMq0LaOOCVDTYx7cjTluaUxRto3WhuoH6RENOzlI/345uVNk8tI 48dhdTVZezDFOmWeVjCa4O1lN//OR5PVj7/uNeNH2CgCvdA11xaWOW4jScLRTU6M 7Zglrktu4ik1tkTj3RRhSeQDSrRTn+x9YCuiFweRJ/Ep4PZooxUaLVYF/aRO5ec9 jAEnrA2v6nZC5ZWzsfpWNsdN4uNRpzC1Z56bGseau3nu4JJAKjzs3CjLXdVmPgA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=vzxH4LX5Cij8qfdR0jCvFKBGhHrlwpB5vnPnOq8vN 4c=; b=Zin6l1BranP8bgE/DU+60Lj8tApFBgmayUCB8Rbu8QZw9mqyv5YVklyNp X9IWk6APHkeUrRTF+YwPLyNXomnS3GtruuummLb8euYUC0in0fTnEFyDjKo/GHAB kD5gaOo0VnOK7QUyjEPAl++709dwqN4NhW5ehNZv1UPQQkj+87NRdIfNDs/jJ8aV vdG9CGaCk67UZObb0DUi8z2YI4Th3b7Xy14QwiXSw0XbaVX/9Y4Ha+toE46c5pso HCGRy3CsDUQyRffg5goQcgK3+3YpwqDJYSU1bV4sGpYuIT0pApiE9igQ8E6QSOY/ YEDUTK4uDVz1D+O4GXQGlc/g1doXg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrvdeggdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtgffhggfufffkfhgjvffosegrjehmrehhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecukfhppeduudelrd dujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from [192.168.7.28] (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id B658030608F5; Fri, 24 Jan 2020 05:30:37 -0500 (EST) Content-Type: multipart/alternative; boundary=Apple-Mail-750B0237-511D-42F0-99A8-76B4B343F66D Content-Transfer-Encoding: 7bit From: Mark Nottingham Mime-Version: 1.0 (1.0) Date: Fri, 24 Jan 2020 21:30:34 +1100 Message-Id: <8605E6BD-485E-431C-AAC6-29DB5C769813@mnot.net> References: <9A005BFA-105F-4A2F-B746-9455B41AB843@cisco.com> Cc: S Moonesamy , architecture-discuss@ietf.org In-Reply-To: <9A005BFA-105F-4A2F-B746-9455B41AB843@cisco.com> To: Eliot Lear X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [arch-d] New Version Notification for draft-iab-for-the-users-01.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 10:30:44 -0000 --Apple-Mail-750B0237-511D-42F0-99A8-76B4B343F66D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable That=E2=80=99s better - thanks.=20 Sent from my iPhone > On 24 Jan 2020, at 8:54 pm, Eliot Lear wrote: >=20 > =EF=BB=BFHi Mark, >=20 >>> On 24 Jan 2020, at 06:36, Mark Nottingham wrote: >>>=20 >>> There is the following text in Section 4.1: "Government representatives s= ometimes participate in the IETF community." When are those representatives= representative of end-users? >>=20 >> I think they're representative of governments.=20 >=20 >=20 > None of our processes assume that this is the case, but rather that they a= re individuals just like anybody else. Moreover, if governments believe tha= t sending someone to the IETF means that they are representing government po= sitions, those people will be hampered in participating in constructive dial= ogs. >=20 > I would change the terminology a bit to say something like =E2=80=9Cgovern= ment experts=E2=80=9D, or otherwise add something of an explanatory note to a= ddress the above. >=20 > Eliot --Apple-Mail-750B0237-511D-42F0-99A8-76B4B343F66D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable That=E2=80=99s better - thanks. 
Sent from my iPhone

On 24 Jan 2020, at 8:54 pm, Eliot Lear <lear@cisco.com>= wrote:

=EF=BB=BFHi Mark,

On 24 Jan 2020, at 06:36, Mark Nottingham <mnot@mnot.net> wrote:
There is the following text in Section 4.1: "Government rep= resentatives sometimes participate in the IETF community."  When are th= ose representatives representative of end-users?
=
I think they're representative of governm= ents. 
<= /blockquote>


None of our processes assume that this is the case, but rather tha= t they are individuals just like anybody else.  Moreover, if government= s believe that sending someone to the IETF means that they are representing g= overnment positions, those people will be hampered in participating in const= ructive dialogs.

I= would change the terminology a bit to say something like =E2=80=9Cgovernmen= t experts=E2=80=9D, or otherwise add something of an explanatory note to add= ress the above.

El= iot
= --Apple-Mail-750B0237-511D-42F0-99A8-76B4B343F66D-- From nobody Fri Jan 24 03:50:02 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C3C1200EC for ; Fri, 24 Jan 2020 03:50:00 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 6Vx4uvmzok84 for ; Fri, 24 Jan 2020 03:49:58 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id ECD9E1200E6 for ; Fri, 24 Jan 2020 03:49:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F12C46601B7; Fri, 24 Jan 2020 13:49:55 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAkLnfGbrkag; Fri, 24 Jan 2020 13:49:54 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 1D8EB660135; Fri, 24 Jan 2020 13:49:54 +0200 (EET) From: Jari Arkko Content-Type: multipart/alternative; boundary="Apple-Mail=_54E228B8-94C2-46F6-A765-C9416EB4DF3F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 24 Jan 2020 13:49:53 +0200 To: model-t@iab.org, architecture-discuss@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 11:50:00 -0000 --Apple-Mail=_54E228B8-94C2-46F6-A765-C9416EB4DF3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The IAB are considering starting up a programme on Internet trust model evolution as described in the link at the bottom of this email. We'd like to get feedback on that idea and the text. As you may be aware, in 2019 a number of documents were published on this topic and discussions held (on the mailing list, SAAG, side meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual meeting coming up on February 14th. To be clear, any output from this program would be text offered=20 to the IETF for consideration - it is not within the IAB's remit, nor=20 that of an IAB program, to modify a BCP. Nonetheless, an IAB=20 program offers a good venue for this work, as it perhaps allows=20 for more focus on the evolving architecture aspect within this space. The plan is for the new program to be entirely open for participation, similar to how the current work has already been. That is, the mailing list is open for all interested to join, meetings are open and listed in the public agendas. The IAB will find a chair or chairs for the group to stay organised. There's no specific deadline for this, but the IAB will consider this further in the next few weeks, so if you could take a few minutes=20 to share your thoughts on this that'd be great. = https://github.com/intarchboard/model-t-charter/blob/master/model-t-charte= r-00.md = https://www.iab.org/mailman/listinfo/model-t = Stephen & Jari --Apple-Mail=_54E228B8-94C2-46F6-A765-C9416EB4DF3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

The IAB are considering starting up a = programme on Internet
trust model evolution as described = in the link at the bottom of this
email.

We'd like to get feedback on that idea and the text. As you = may
be aware, in 2019 a number of documents were published = on
this topic and discussions held (on the mailing list, = SAAG, side
meeting at IETF-106, workshops, etc). There=E2=80= =99s also a virtual
meeting coming up on February 14th.

To be clear, any output from this program = would be text offered 
to the IETF for consideration = - it is not within the IAB's remit, nor 
that of an = IAB program, to modify a BCP. Nonetheless, an IAB 
program offers a good venue for this work, as it perhaps = allows 
for more focus on the evolving architecture = aspect within this space.

The plan is for = the new program to be entirely open for participation,
similar to how the current work has already been. That is, = the mailing
list is open for all interested to join, = meetings are open and listed
in the public agendas. The = IAB will find a chair or chairs for the
group to stay = organised.

There's no specific deadline for = this, but the IAB will consider this
further in the = next few weeks, so if you could take a few minutes 
to share your thoughts on this that'd be great.

https://github.com/intarchboard/model-t-charter/blob/master/mod= el-t-charter-00.md
https://www.iab.org/mailman/listinfo/model-t

Stephen & = Jari

= --Apple-Mail=_54E228B8-94C2-46F6-A765-C9416EB4DF3F-- From nobody Fri Jan 24 05:49:57 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96EC120137; Fri, 24 Jan 2020 05:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 r6FDF3UiAguD; Fri, 24 Jan 2020 05:49:44 -0800 (PST) Received: from secgw1.intern.tuwien.ac.at (secgw1.intern.tuwien.ac.at [IPv6:2001:629:1005:30::71]) (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 5418E1200F4; Fri, 24 Jan 2020 05:49:43 -0800 (PST) Received: from totemomail (localhost [127.0.0.1]) by secgw1.intern.tuwien.ac.at (8.14.7/8.14.7) with ESMTP id 00ODnaWv011233; Fri, 24 Jan 2020 14:49:36 +0100 Received: from localhost ([127.0.0.1]) by totemomail (Totemo SMTP Server) with SMTP ID 719; Fri, 24 Jan 2020 14:49:36 +0100 (CET) Received: from edge13b.intern.tuwien.ac.at (edge13b.intern.tuwien.ac.at [IPv6:2001:629:1005:30::67]) by secgw1.intern.tuwien.ac.at (8.14.7/8.14.7) with ESMTP id 00ODnZDW011218 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 24 Jan 2020 14:49:35 +0100 Received: from mbx13c.intern.tuwien.ac.at (2001:629:1005:30::63) by edge13b.intern.tuwien.ac.at (2001:629:1005:30::67) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jan 2020 14:49:35 +0100 Received: from [10.0.0.11] (193.154.92.83) by mbx13c.intern.tuwien.ac.at (2001:629:1005:30::63) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jan 2020 14:49:35 +0100 To: Jari Arkko , , References: From: Joachim Fabini Autocrypt: addr=joachim.fabini@tuwien.ac.at; keydata= xsFNBFzP9YwBEADLSwTOJGpr6+y+UQ2tko4lnJLfcazo3MHJq6w8CoOAeBhgvxHvksx48RpB JOculUcAP+Sr/dAsVJRvbrd3ZVFl5X+5rq5HqZtEER64JkZN3ZWwuZJ2cIPe8UrmPUCCSdDm Q2Ss3jWRYq+5bg9xG9pgRdfXQj4EzocE5+vnq1TEx5skuAK2pmntE29gCO8ICIO0qOtlNMyz UNPyb/wvVR/+8Umj5xO3kJrEjq7NpYCPP+I2nmRmrCVNQ+ruQGjHFbFzLCzeQj/Ln+vHJy3C O5qbBs/8aae2+7g/N642ODgXv78mg6k4r/yA2uCoeqirj9P6d/8qyhdU247oe+96FLwd4ly5 cHjmS5FEBhNsZKB3yPwod8phWwMZhPDro+ttkTRjL9CTmXspLFPlYwDqkuyEVMOHh24toFVI 0QukzYWLrMwY3ae0ni8DM5fcTQaFDWr4rqRcfGRhA66xxT4uUAX20q1VzWBO2fVUr0eB3Hwr FjCS7URAlsPFebuevgt1/pjSbcRk20TXPp//1qwh8GU03C6qy5iHB8coAsCwZec3S92YEdgM obdYgVhLPHOMd89IfldRASAConvQzI8WkiabzkMpL0donUUErNQ9RVFQ1NRoLJYIx2D0CMFN RW01q0xZFEKci+r/S2/YUkhXTXD4cEx4y3A4WCJPi0teSUW8owARAQABzSxKb2FjaGltIEZh YmluaSA8am9hY2hpbS5mYWJpbmlAdHV3aWVuLmFjLmF0PsLBgAQTAQgAKgIbIwUJCWYBgAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCXM/2+wIZAQAKCRCbDicB0srp1dEXEACLpHerJzi7 684Ixo6sgwQ0TM/oVV7unXIqFZuuZLMf4r609La++l0BXSmj6LtrIqZVXoFVRwIutEADmaKZ k2kc2zVaKWN/BM4/o8r0db/jOdElv8bbqsui1HYCA1KIKu2nNEMQd1axH0mzBUEFQaIoEPQP mQszQhKHw1ZgAjrsyvU7ZH9aHTboPvLURIAH0CBfgvnm+feFxl/rMBSLu5CJpff9cWA1inKX 1eEexy2tFR80NUSaLauRLC9j9Xe2q+7DLNAT16+5dgRt16bXlkUh4IMpG5k6vpyFu12vSfcB VHJZEKld9APoHoHdjgq7QSeyENfZU+XeAzT/U0fDvF7v392/Fnw7UfVNi5TW2DjiR1cf5ahG YNzfJlIRmiFAkGAxjA6LV6tidpr+KtKvgTh00JZoHVpd4f26/bRTuHXzZh/G36r1bo3qYaQQ mebj6HocdFofh4dN08zv9tiYfrn9uAScZ8JeNQQWb1fg8a2a3nnGLAQiqyFKiuklczA/wkcV ZklezqdO/8nhEhSmiGOLiVwCCdMOBwwBhhJc3iXNYt+pp/v+X/T6m10wwJrwF0JVaPsKqk/m XwCw3jCjcu6iBHPwxS5qmCyJJmBwqq8RtA+Bjdp4J1CIJN3cb+fDoteXBJHYSWYFNGSa9wC4 kSGpw/5LyucT7vSCSolwdC0YVc7BTQRcz/WMARAAyMkUJLJo7g0HwerlxK2kzncvpN0ACN+b Dq89kxJPpbUivE/5I8CTpYQUVBEIq7mvk5/vZj7NWiOdBqW7yx3pmnSuzVtIy7+SB9nVm4mZ InnHij8g1IQ5267C2x1jv93PdbGXFFeEHHg0h/4GjN//3ScyhKt0vf6tDPjGwkUe5tvpvTx7 NiCW2D5hk+tQf5FcvKhwFYCKC6b9DaIb19QgjuANo/g6is/n5M4CYiX+Pqx5j+J6NjG9hMLc 4GTSQur8Ix7LZ3G78z7zB1AdiJMCyeaqrYKTVWNsz1DB5MRiGl9Wz5Q9LZu070neMuoOHD+0 Aaud5JbI8YozvxwTbNN8/fV6byVWvCCmtd8ZZDKfQXgav2HvtejFlm0ix9MTl87+OUGbpLtm WIS/2qZtamrTVfv5dVlCM9ziHkkhV75nMr6X6h+tAaedboC7xIWR8bAC4HGk3KN1cmwjgy4D G87X+tYNmzhAQHioHEEvfklNXOIvU5coDzpdp/n9OxQxPlA5qC+BDSixQqsu5iTcPaA0iGij Ja3A7Wg69ybigctY22ICCvyUv8WgRoCWcHNfjI3sJULLk+SfygEALfgWQ9xKQI+L0M5h+Tq4 2RUpYVC2HKGtzQZ7YhSQcHu9NobA/4qVJcCF+tZXV5mPeMg5LHpmNhfSQRYgbk2KBvaqJw2D MbsAEQEAAcLBZQQYAQgADwUCXM/1jAIbDAUJCWYBgAAKCRCbDicB0srp1YnTD/0Qao7t3YNk Rc04ed1slc22Ned54huNF10TD5+QVSjfdjiMrlUNYznjqnMEdWDaHKclQS7WaBJO2GetSPFr Etk/IJ0bM+C9GjYh+kfqA0X45X8KC4/XLoARd4I+B4uLk+i0UbhlnL9sibVaIGG6IC6S1HGN M0yA9RJ0FPXl4/QV5JAkLNSDKCiyeFjACqExLk7HHNACrLO8Jr7IH8RDE3rlIEgdWxwTIs+9 GeLvMdtasnfEloZCsGb2proOu1QhMZlqoftLhtMzW+4lEmJnUAfxHZRivpjjlQVtWIQ03t6f txnqh4plL3gJsGV+y4ty4emTN9MJsDAyphkqKPqv29hJTyHoeixSG7G0KT/gO+JqTWm/7wwU d7xOW+WtjsXhNM5k5aJtTGpGAwC6QkKnodu+WUkYxpXJKU4cmEBguFQPCwTlFzh7+Jo98Vbh N9cJUQ5iJau00lDU3qJIcbsD06ccy1EoBjIiqAH59DnumrnP99J6iNj8yCxStc1TjA3dRReu +iOGwyoUlp48c3UlpK4BkSegtd2CA37xkiesebEUoRYiAld410PETVlHCQX/kBa6iAx4oEoG lS4E9h1XOCVa0fnJZfwq00WHUbT+P3E3/svKw63HccEuLHBETuowX1ECcGf7s6E9aaexLqbV jVz9rWWAUFG680+ewfjVKZjb5Q== Message-ID: <27d65034-22be-e2b1-bdb1-f2cbc05ec663@tuwien.ac.at> Date: Fri, 24 Jan 2020 14:49:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US X-ClientProxiedBy: mbx13a.intern.tuwien.ac.at (2001:629:1005:30::61) To mbx13c.intern.tuwien.ac.at (2001:629:1005:30::63) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by secgw1.intern.tuwien.ac.at id 00ODnZDW011218 Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 13:49:52 -0000 Jari, Stephen, all, I support the IAB initiative. As a detailed reply to some aspects mentioned in the draft charter: imo - it's needed that these threat/trust model activities find a home. The IAB taking the lead can help in covering a wide variety of perspectives (including aspects that some may consider research). - the potential impact of the threat model on future activities is too high to handle it within a closed group and/or side-meetings. Being open for public participation and becoming more visible (by listing the sessions in the program) can help to include perspectives of all affected parties. - the major challenge (imho) is an appropriate scope of the new model while keeping it simple, usable and relevant for most of us (as your draft and the charter both mention). Various areas/stakeholders/systems may have conflicting views and priorities at architectural/structural/protocol/security/privacy levels. - An unbiased discussion/review on (explicit and, in particular, implicit) prerequisites that RFC3552 relies on and if/how they changed within the last 17 years may be a good start (fitting topic 2 of the expected outputs). At a technical level the term "compromised" (*) may benefit from a refined perspective and definition. It sounds simple, but thinking of group communications (multicast, broadcast) it becomes a challenge. thanks Joachim PS: (*): or "compromisable"? The safe (realistic) assumption is to consider any system to be vulnerable. On 24/01/2020 12:49, Jari Arkko wrote: >=20 > The IAB are considering starting up a programme on Internet > trust model evolution as described in the link at the bottom of this > email. >=20 > We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on > this topic and discussions held (on the mailing list, SAAG, side > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th. >=20 > To be clear, any output from this program would be text offered=C2=A0 > to the IETF for consideration - it is not within the IAB's remit, nor=C2= =A0 > that of an IAB program, to modify a BCP. Nonetheless, an IAB=C2=A0 > program offers a good venue for this work, as it perhaps allows=C2=A0 > for more focus on the evolving architecture aspect within this space. >=20 > The plan is for the new program to be entirely open for participation, > similar to how the current work has already been. That is, the mailing > list is open for all interested to join, meetings are open and listed > in the public agendas. The IAB will find a chair or chairs for the > group to stay organised. >=20 > There's no specific deadline for this, but the IAB will=C2=A0consider t= his > further in the next few weeks, so if you could=C2=A0take a few minutes=C2= =A0 > to share your thoughts on this=C2=A0that'd be great. >=20 > https://github.com/intarchboard/model-t-charter/blob/master/model-t-cha= rter-00.md > https://www.iab.org/mailman/listinfo/model-t >=20 > Stephen & Jari >=20 >=20 --=20 --------------------------------------- Dr. Joachim Fabini Senior Scientist Institute of Telecommunications TU Wien Gusshausstrasse 25/E389 A-1040 Vienna, Austria Tel: +43 1 58801-38813 mailto: Joachim.Fabini@tuwien.ac.at --------------------------------------- From nobody Fri Jan 24 11:47:01 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025C212011E for ; Fri, 24 Jan 2020 11:46:55 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a5P2bMU_wtu for ; Fri, 24 Jan 2020 11:46:52 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 53EE9120858 for ; Fri, 24 Jan 2020 11:46:52 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id s64so1636026pgb.9 for ; Fri, 24 Jan 2020 11:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Az2Kkbjs2kzUtVWge3eLMIk1jN0NnpaYkKw/6D/hvAE=; b=epazG/oqJLxe5Zes4PBGz/QqxgulCiU17ConJMS3r5f/8E+q4ctzBchEqcC+5x3uU5 Kx6nguBKB+tWSmN6mkTsBzBVPINDgYz7emHsPQqsJY96Qsm1qIIVboUbU6kjBK3BwJLE IeVEVYCRN4OZPzOXlhm8qf13d6O3ccIRLnEatGRgcvFf+eddRCbxG/LyhkEJrlXZiu8f 9NHOKkQLkWMTGw4jXJM40uviKHo9ah3+u1KutCcEarr0eUVqsfZKH89CqvqvaLtrJedL WLG45+a7XX9/iTOnO5gcc96YnKL55TjXbN3TbMuwEiMju+Y3XaQ36nySJJfHJEUy1O0h ojMQ== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Az2Kkbjs2kzUtVWge3eLMIk1jN0NnpaYkKw/6D/hvAE=; b=SXdGAbByOMlWFFOxJOuD7Mdfivl6fTETLMzl8OfYNtAilM0uUhz0PPOUGkGm26OGPG nr0xp3VMBp60EzFvHE4DpIRMvtic4oF2/l4b5FQ2FGV0NqKz7IXd/xkLZI1HQXPQgxDM qbZZ97NTCYS33mKWuLcuxuKl+3wkzxBd7tvmNoyoO9CWjfm/Zfckdt2WyJqg2aw92Oxa x9U853SiNpy0V6C4AVFXn65RGb3jukqui+1fBD9iflglzd8ihQr8AqPx76eJHBb5H0/K 3A1vlc9gCuyhqzVkn5IH8nnADtht+p9cyxH1CbF6SLxJ864v5yTK7IMGXnUe0Bc3SrTd 5jTw== X-Gm-Message-State: APjAAAW6XGVkayrC94GGs+qioK+v7mJIQXEtQkTqHhuDaRs1hBnfV7LC rTYu1qyh96aMqULhiqBJYEhK1q/J X-Google-Smtp-Source: APXvYqzy7HU6gQc6/gBl4/JL/F9NWhA/w2Vf+gMptDEgYWnQ6YaKeYuMF2vz8R1t3ItrtA0xkWlb5A== X-Received: by 2002:a65:4c82:: with SMTP id m2mr5656645pgt.432.1579895211390; Fri, 24 Jan 2020 11:46:51 -0800 (PST) Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id 136sm7343202pgg.74.2020.01.24.11.46.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jan 2020 11:46:50 -0800 (PST) To: Jari Arkko , model-t@iab.org, architecture-discuss@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 25 Jan 2020 08:46:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 19:46:55 -0000 Hi, I'm confused. What we have in RFC3552 is very intentionally guidance for RFC writers on what they need to cover in their RFCs. Its specific purpos= e was to get rid of "Security considerations are not discussed in this memo= =2E"=20 Its purpose was not primarily to define an abstraction like a "trust mode= l" or a "threat model" (the draft charter seems a bit vague about which of t= hose it means). I really do not want to see the pragmatic purpose of RFC3552 lost in the effort to define these abstractions. I don't think that is the intention,= but the text seems to imply that RFC3552 was mainly a description of a generic threat model, which it wasn't. I am not against an IAB effort to analyse how the threat and trust models= (plural) have evolved since the security workshop [RFC2316] that ultimate= ly led to RFC3552. That seems like a good idea. An update of "Guidelines for= Writing RFC Text on Security Considerations" also seems like a good idea.= But the draft charter text seems to conflate these two separate lines of action. Incidentally, while writing the above it occurred to me why the phrase "IAB program" has always slightly disturbed me. Really the proposal is a virtual IAB workshop (whereas RFC2316 came from three days in a room together in Murray Hill, NJ). A good idea, but not a program. Regards Brian On 25-Jan-20 00:49, Jari Arkko wrote: >=20 > The IAB are considering starting up a programme on Internet > trust model evolution as described in the link at the bottom of this > email. >=20 > We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on > this topic and discussions held (on the mailing list, SAAG, side > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th. >=20 > To be clear, any output from this program would be text offered=C2=A0 > to the IETF for consideration - it is not within the IAB's remit, nor=C2= =A0 > that of an IAB program, to modify a BCP. Nonetheless, an IAB=C2=A0 > program offers a good venue for this work, as it perhaps allows=C2=A0 > for more focus on the evolving architecture aspect within this space. >=20 > The plan is for the new program to be entirely open for participation, > similar to how the current work has already been. That is, the mailing > list is open for all interested to join, meetings are open and listed > in the public agendas. The IAB will find a chair or chairs for the > group to stay organised. >=20 > There's no specific deadline for this, but the IAB will=C2=A0consider t= his > further in the next few weeks, so if you could=C2=A0take a few minutes=C2= =A0 > to share your thoughts on this=C2=A0that'd be great. >=20 > https://github.com/intarchboard/model-t-charter/blob/master/model-t-cha= rter-00.md > https://www.iab.org/mailman/listinfo/model-t >=20 > Stephen & Jari >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Fri Jan 24 12:03:59 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA603120BB1 for ; Fri, 24 Jan 2020 12:03:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 lIEjElMwgR_t for ; Fri, 24 Jan 2020 12:03:49 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 505F412087B for ; Fri, 24 Jan 2020 12:03:49 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id 9so1971252lfq.10 for ; Fri, 24 Jan 2020 12:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HcV+gfYMBzK6IBaq6FqQOOYlUYk47nORjhgCERFbyM4=; b=Cyv3NcTznk8Qws0KlrPIj7grcEo4IETDyHgM5LOrDC4dwvhPMIAE5Cqmb9ZV2dCBMk 6jIujoCRpY0aq8B4bFaWwpPIknC6GFTp5/FSL5Zvl4Qhd8I8hjsxYtMbN/T5hUei96cn /AdHUJ/fWUnCa8dYM5UiIVe/4PdnPYpPl1KjFonl0+/70tkgC5xuA8IMv+onQ4LD+v2A KoiUoDcBnF69gFHve3B4fJrxm/Ht9Bear2lq6ApaP8yHYGRNFFsy21wGB6+brzR+CH7O yZsVKaIsp4wCgH1NGUauWIqR2ggL8G+t9SF4KUFhy9jpcbE7TqNELR99deSbyJzem8RO d+gg== 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=HcV+gfYMBzK6IBaq6FqQOOYlUYk47nORjhgCERFbyM4=; b=JZ4Are5XPoWAIbhNGQnKFfav83n0UHYxakiSCLwTj/Fs1s1OvteiAIlF+yDUHzvzXQ bmEirg7sVNk3jJreomqgzs+n3Pp+2pOi51xfwU1UJbyL+T/WsuEO/PTIRzb1mdHpr45r rTIcRDfADuhGDH3+vynOqxQBlMxrK2kz3dw14jJDXuu+D80jUlT6OV6gKMmuJo7+vCil i14wDqFVbCKccW/6nLvhqK5n4WTiwXse2LU1KvVE/vqqbvoDtwV8BViiumVySxccgNP6 T91Vtu8RtIrYe/iBnRFNr+8E1Z/TVOwlO0JlkWscxTDQmhs4sDVAdiYb6J4DnPlr5GDt 19UQ== X-Gm-Message-State: APjAAAVAxA0BdFu5MhoK7dzqgfpardVUplf/mR3kmblKQXeBxepaoprg PS7Rba0o9zWBModVkpmYWopAmeJBGAzl17jmhratHg== X-Google-Smtp-Source: APXvYqwgpeO9Pt8sru2nXD+c3/UzapxNmLMnnce0Kbr2DUAeMPk6m62O1VyMfpfDulnapFHQp/0VdYSDUrIJtELVUuQ= X-Received: by 2002:a05:6512:64:: with SMTP id i4mr2138908lfo.55.1579896227417; Fri, 24 Jan 2020 12:03:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 24 Jan 2020 12:03:11 -0800 Message-ID: To: Brian E Carpenter Cc: Jari Arkko , model-t@iab.org, architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000006ae7b9059ce841c8" Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 20:03:59 -0000 --0000000000006ae7b9059ce841c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian's comments match my recollection. Specifically, we didn't think we were *defining* a threat model as much as documenting a consensus model that already existed. Incidentally, it's not clear to me what a "trust model" is. This is not a term that appears in 3552 nor is it a real term of art that I am familiar with. Taking a step back, I remain unpersuaded that the 3552 threat model is really out of data. The two main deficiencies I have heard floated are: 1. That it doesn't take into account traffic analysis and pervasive monitoring. 2. That the assumption that endpoints are uncompromised is unrealistic. I can see some merit in the first point, but this seems to really be more a matter of emphasis: 3552 already specifies a Dolev-Yao style attacker, which means that it can observe all communications. So really what has happened is that we have a clearer picture of just how realistic that is and what you can do with that kind of access. I can see some kind of update, but again it's less about threat model than about modern examples. As far as the second point goes, I think that when you are thinking about comsec protocols it's still true that you can't do much if you don't trust the endpoints. I think 3552 could be a bit better about recognizing that there are malicious actors in the system, though obviously that's implicit in the discussion of DoS. Anyway, this doesn't seem like much of an update to the threat model. What does feel dated in 3552 (at least to me) is the emphasis on a bunch of very old school protocols and the more or less total elision of the Web. In particular, if we're talking in terms of threat model, the idea that you have a lot of different untrusted programs running on your machine (i.e., in the JS VM) and that you need to secure them from each other really is new and could use some documenting. It's worth noting, however, that (a) that's largely about implementation and (b) that that system strives to achieve the kind of "each endpoint its own isolated unit" ideal that 3552 asumes. -Ekr On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > I'm confused. What we have in RFC3552 is very intentionally guidance for > RFC writers on what they need to cover in their RFCs. Its specific purpos= e > was to get rid of "Security considerations are not discussed in this > memo." > Its purpose was not primarily to define an abstraction like a "trust mode= l" > or a "threat model" (the draft charter seems a bit vague about which of > those > it means). > > I really do not want to see the pragmatic purpose of RFC3552 lost in the > effort to define these abstractions. I don't think that is the intention, > but the text seems to imply that RFC3552 was mainly a description of a > generic threat model, which it wasn't. > > I am not against an IAB effort to analyse how the threat and trust models > (plural) have evolved since the security workshop [RFC2316] that ultimate= ly > led to RFC3552. That seems like a good idea. An update of "Guidelines for > Writing RFC Text on Security Considerations" also seems like a good idea. > But the draft charter text seems to conflate these two separate lines of > action. > > Incidentally, while writing the above it occurred to me why the phrase > "IAB program" has always slightly disturbed me. Really the proposal is > a virtual IAB workshop (whereas RFC2316 came from three days in a room > together in Murray Hill, NJ). A good idea, but not a program. > > Regards > Brian > > On 25-Jan-20 00:49, Jari Arkko wrote: > > > > The IAB are considering starting up a programme on Internet > > trust model evolution as described in the link at the bottom of this > > email. > > > > We'd like to get feedback on that idea and the text. As you may > > be aware, in 2019 a number of documents were published on > > this topic and discussions held (on the mailing list, SAAG, side > > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > > meeting coming up on February 14th. > > > > To be clear, any output from this program would be text offered > > to the IETF for consideration - it is not within the IAB's remit, nor > > that of an IAB program, to modify a BCP. Nonetheless, an IAB > > program offers a good venue for this work, as it perhaps allows > > for more focus on the evolving architecture aspect within this space. > > > > The plan is for the new program to be entirely open for participation, > > similar to how the current work has already been. That is, the mailing > > list is open for all interested to join, meetings are open and listed > > in the public agendas. The IAB will find a chair or chairs for the > > group to stay organised. > > > > There's no specific deadline for this, but the IAB will consider this > > further in the next few weeks, so if you could take a few minutes > > to share your thoughts on this that'd be great. > > > > > https://github.com/intarchboard/model-t-charter/blob/master/model-t-chart= er-00.md > > https://www.iab.org/mailman/listinfo/model-t > > > > Stephen & Jari > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > -- > Model-t mailing list > Model-t@iab.org > https://www.iab.org/mailman/listinfo/model-t > --0000000000006ae7b9059ce841c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian's comments match my recollection. Specifica= lly, we didn't think we were *defining* a threat model as much as docum= enting a consensus model that already existed. Incidentally, it's not c= lear to me what a "trust model" is. This is not a term that appea= rs in 3552 nor is it a real term of art that I am familiar with.
=
Taking a step back, I remain unpersuaded that the 3552 threa= t model is really out of data. The two main deficiencies I have heard float= ed are:

1. That it doesn't take into account t= raffic analysis and pervasive monitoring.
2. That the assumption = that endpoints are uncompromised is unrealistic.

I= can see some merit in the first point, but this seems to really be more a = matter of emphasis: 3552 already specifies a Dolev-Yao style attacker, whic= h means that it can observe all communications. So really what has happened= is that we have a clearer picture of just how realistic that is and what y= ou can do with that kind of access. I can see some kind of update, but agai= n it's less about threat model than about modern examples.
As far as the second point goes, I think that when you are thi= nking about comsec protocols it's still true that you can't do much= if you don't trust the endpoints. I think 3552 could be a bit better a= bout recognizing that there are malicious actors in the system, though obvi= ously that's implicit in the discussion of DoS. Anyway, this doesn'= t seem like much of an update to the threat model.

What does feel dated in 3552 (at least to me) is the emphasis on a bu= nch of very old school protocols and the more or less total elision of the = Web. In particular, if we're talking in terms of threat model, the idea= that you have a lot of different untrusted programs running on your machin= e (i.e., in the JS VM) and that you need to secure them from each other rea= lly is new and could use some documenting. It's worth noting, however, = that (a) that's largely about implementation and (b) that that system s= trives to achieve the kind of "each endpoint its own isolated unit&quo= t; ideal that 3552 asumes.

-Ekr

=

= On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi,=

I'm confused. What we have in RFC3552 is very intentionally guidance fo= r
RFC writers on what they need to cover in their RFCs. Its specific purpose<= br> was to get rid of "Security considerations are not discussed in this m= emo."
Its purpose was not primarily to define an abstraction like a "trust m= odel"
or a "threat model" (the draft charter seems a bit vague about wh= ich of those
it means).

I really do not want to see the pragmatic purpose of RFC3552 lost in the effort to define these abstractions. I don't think that is the intentio= n,
but the text seems to imply that RFC3552 was mainly a description of a
generic threat model, which it wasn't.

I am not against an IAB effort to analyse how the threat and trust models (plural) have evolved since the security workshop [RFC2316] that ultimately=
led to RFC3552. That seems like a good idea. An update of "Guidelines = for
Writing RFC Text on Security Considerations" also seems like a good id= ea.
But the draft charter text seems to conflate these two separate lines of action.

Incidentally, while writing the above it occurred to me why the phrase
"IAB program" has always slightly disturbed me. Really the propos= al is
a virtual IAB workshop (whereas RFC2316 came from three days in a room
together in Murray Hill, NJ). A good idea, but not a program.

Regards
=C2=A0 =C2=A0Brian

On 25-Jan-20 00:49, Jari Arkko wrote:
>
> The IAB are considering starting up a programme on Internet
> trust model evolution as described in the link at the bottom of this > email.
>
> We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on
> this topic and discussions held (on the mailing list, SAAG, side
> meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th.
>
> To be clear, any output from this program would be text offered=C2=A0<= br> > to the IETF for consideration - it is not within the IAB's remit, = nor=C2=A0
> that of an IAB program, to modify a BCP. Nonetheless, an IAB=C2=A0
> program offers a good venue for this work, as it perhaps allows=C2=A0<= br> > for more focus on the evolving architecture aspect within this space.<= br> >
> The plan is for the new program to be entirely open for participation,=
> similar to how the current work has already been. That is, the mailing=
> list is open for all interested to join, meetings are open and listed<= br> > in the public agendas. The IAB will find a chair or chairs for the
> group to stay organised.
>
> There's no specific deadline for this, but the IAB will=C2=A0consi= der this
> further in the next few weeks, so if you could=C2=A0take a few minutes= =C2=A0
> to share your thoughts on this=C2=A0that'd be great.
>
> https://github= .com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md
> https://www.iab.org/mailman/listinfo/model-t >
> Stephen & Jari
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss
>

--
Model-t mailing list
Model-t@iab.org https://www.iab.org/mailman/listinfo/model-t
--0000000000006ae7b9059ce841c8-- From nobody Fri Jan 24 12:22:16 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0CA1209AC for ; Fri, 24 Jan 2020 12:22:13 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 33_in70TtBIO for ; Fri, 24 Jan 2020 12:22:11 -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 13C1D120858 for ; Fri, 24 Jan 2020 12:22:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 77803BE20; Fri, 24 Jan 2020 20:22:07 +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 bjOesnX3O1bB; Fri, 24 Jan 2020 20:22:05 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 308BCBDCF; Fri, 24 Jan 2020 20:22:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579897325; bh=drW5tHtfG+FZtA+si0PKrtKJ2lG/IkFiFYJoLtCqSIg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AYtgyWV64XmawGFAcARB3EqkIgJg8R/kJPmCXm00jzxSrhKONAzoRkJuO29SU8qPX 7rNg3KDDpeMeKbrTxtSVzQ3iFQ1iq/ZglTl5SuKzPhcPCZjaPBs8GZuFZ+Ep6w04Cj vLYjasmSzYaOtrYYWyHzQVbkA7J3+8esdnlIoPx8= To: Eric Rescorla , Brian E Carpenter Cc: architecture-discuss@ietf.org, model-t@iab.org References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: Fri, 24 Jan 2020 20:22:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9moab8tQIcFis3ak8beZLk3LF8zL26CUf" Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 20:22:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9moab8tQIcFis3ak8beZLk3LF8zL26CUf Content-Type: multipart/mixed; boundary="guGERX3toLMsQMfHoSUHsooiYhny92aEc"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , Brian E Carpenter Cc: architecture-discuss@ietf.org, model-t@iab.org Message-ID: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution References: In-Reply-To: --guGERX3toLMsQMfHoSUHsooiYhny92aEc Content-Type: multipart/mixed; boundary="------------326BFE266DA53FDAA8728883" Content-Language: en-US This is a multi-part message in MIME format. --------------326BFE266DA53FDAA8728883 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 24/01/2020 20:03, Eric Rescorla wrote: > Incidentally, it's not clear to me what a "trust > model" is. This is not a term that appears in 3552 nor is it a real ter= m of > art that I am familiar with. Crap! Checking back to the initial text, that was my fault - must've been some form of Freudian typo though 'cause I also don't know what a "trust model" might be. Please read s/trust model/threat model/ everywhere relevant, and apologies for the slip up. I've modified [1] to fix at least that, Sorry again, S. [1] https://github.com/intarchboard/model-t-charter/blob/master/model-t-chart= er-00.md --------------326BFE266DA53FDAA8728883 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------326BFE266DA53FDAA8728883-- --guGERX3toLMsQMfHoSUHsooiYhny92aEc-- --9moab8tQIcFis3ak8beZLk3LF8zL26CUf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4rUewACgkQWrL68XsX K+ondw/+JftYaMoMKBOW0+8VgoDbbpSr509trCqeCUsdSWSVxpmmBfF3rw0tdlKX R7opKRZGuOslJTkgP2j1z7OlKgAwN2nmpIGjHal7JFPS71VuibzaHtTgzLMi8SZu AdJ+D/livTiMyRtpWfR2rP3ATw3fjT/b432e25so09EvctEsva4yb2saGejh0H7V XiIpjfcP8fc6QW0+yOLO5mQ7jW0UesU0Crd4keO3B+gAs3HGmleyG9idBPlIahF4 FCdvP69ZFR8jaCxsvpKYSyli5CzLKeIXcL/OSU51HmWsMeC3fPaQVl+618GCbd8B gnjWvJ/uC5dnin4rzjrG3/XjhaN3ypnYI63xVqfZafvXxLLL68rz1gOte6BUGFdE J+pmOwSUd5bnb5gk0YpeQ97ZLfyCpm1EXBGTcS5q85cucyIN0/PWUAP+d1yrwRpE CC/L/WybeFJDac5s6QDeKr4HcyA1sxR26hQPWfSMFHpRSsnEfH+xxGuYuCw8yX3y vtIBFSBAZJmCq17vp8Jn8/tzSwAZ52WTlZKuei9e+Hu1Afz6bBI6HGNfKWqPF342 8kGarfOoShQ6nHUSmmt28pSU42QJBQYMewV3tAufmK5ShHt/30FBJshsmC1Anpon kXKl5tx2R2ZA4+iaCANhadMdhZNCZ+GBthzmDQu8u/lyxSK1wMI= =DtlX -----END PGP SIGNATURE----- --9moab8tQIcFis3ak8beZLk3LF8zL26CUf-- From nobody Fri Jan 24 12:25:47 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B762120090 for ; Fri, 24 Jan 2020 12:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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, 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 1KFIKsC1uJ-B for ; Fri, 24 Jan 2020 12:25:42 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799AA1209F4 for ; Fri, 24 Jan 2020 12:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23260; q=dns/txt; s=iport; t=1579897541; x=1581107141; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=qOCPSnh35USgOSN7RiLO9iMol9DUtjCA5bDmOCuvYJk=; b=cBOQ5lS33mb97ZE03Lw1p/nQkKyMnbxevCTb7lpegTeieryM3lyEJYh9 xurHiancj2ddP5HXBUQmYuYsGlM0+mpRBKggqvOpxdZCJ/egyyiy0nPpG 2kX+rQitFTubZ2bxO535ycbKr5t+dIxYIWS5MXmitGx5wB1XcXewU14mA o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCBwBkUite/xbLJq1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBJYFwVSASKoQSiQOIN4EBhjyCJI9wgWcCBwEBAQkDAQEYAQw?= =?us-ascii?q?KAQGDCnFFAoJGOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQIBAQEhSwsFCws?= =?us-ascii?q?OBAYVEgMCAiEGHwMOBhODJgGCSgMOIA+tEnWBMoVKgk0NghAKBoE4gVOKXoI?= =?us-ascii?q?AgREnIIFOEjcHLj6CG0kBAYEeEgESAVUJglEygiwElzSXYESCQ4JMgRyDWop?= =?us-ascii?q?MhCkbgkiMKIwMkCqHGoIkjFeDLgIEBgUCFYFpIio9cTMaCBsVOyoBgkE+Ehg?= =?us-ascii?q?NV4cGMBcVgzuFFIU+AkADMAKLIoIyAQE?= X-IronPort-AV: E=Sophos;i="5.70,358,1574121600"; d="asc'?scan'208,217";a="22534795" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jan 2020 20:25:38 +0000 Received: from [10.61.171.81] ([10.61.171.81]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 00OKPb4e019325 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Jan 2020 20:25:38 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9FB7251E-477E-443A-AA64-AEBB2602FE0A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Fri, 24 Jan 2020 21:25:37 +0100 In-Reply-To: Cc: Brian E Carpenter , architecture-discuss@ietf.org, model-t@iab.org To: Eric Rescorla References: X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.171.81, [10.61.171.81] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 20:25:46 -0000 --Apple-Mail=_9FB7251E-477E-443A-AA64-AEBB2602FE0A Content-Type: multipart/alternative; boundary="Apple-Mail=_302D8F54-40AB-4EF2-9505-7537A093C282" --Apple-Mail=_302D8F54-40AB-4EF2-9505-7537A093C282 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, I appreciate your specificity. It really helps to focus the discussion. I would say that the world is a more complex place than it was when 3552 = was written. That is not to say that the document is out of date, but = rather that it is reasonable to explore what confidentiality means in = various contexts and how that relates to integrity. Also, I do think it=E2=80=99s worthy addressing a slightly different = threat model: when the endpoint that you purchased may be a threat to = you, and whether there is something to be done about that. I gave an = example on another list of an Internet toy that has an undisclosed = microphone and camera that invade=E2=80=99s a child=E2=80=99s privacy. We discussed another case in which there needs to be auditing of train = signaling systems. And there are very complex cases involving medical = devices that are probably worthy of discussion. Does any of this require an update to 3552? I think that would be = premature to say. But they=E2=80=99re probably worthy of discussion. Eliot > On 24 Jan 2020, at 21:03, Eric Rescorla wrote: >=20 > Brian's comments match my recollection. Specifically, we didn't think = we were *defining* a threat model as much as documenting a consensus = model that already existed. Incidentally, it's not clear to me what a = "trust model" is. This is not a term that appears in 3552 nor is it a = real term of art that I am familiar with. >=20 > Taking a step back, I remain unpersuaded that the 3552 threat model is = really out of data. The two main deficiencies I have heard floated are: >=20 > 1. That it doesn't take into account traffic analysis and pervasive = monitoring. > 2. That the assumption that endpoints are uncompromised is = unrealistic. >=20 > I can see some merit in the first point, but this seems to really be = more a matter of emphasis: 3552 already specifies a Dolev-Yao style = attacker, which means that it can observe all communications. So really = what has happened is that we have a clearer picture of just how = realistic that is and what you can do with that kind of access. I can = see some kind of update, but again it's less about threat model than = about modern examples. >=20 > As far as the second point goes, I think that when you are thinking = about comsec protocols it's still true that you can't do much if you = don't trust the endpoints. I think 3552 could be a bit better about = recognizing that there are malicious actors in the system, though = obviously that's implicit in the discussion of DoS. Anyway, this doesn't = seem like much of an update to the threat model. >=20 > What does feel dated in 3552 (at least to me) is the emphasis on a = bunch of very old school protocols and the more or less total elision of = the Web. In particular, if we're talking in terms of threat model, the = idea that you have a lot of different untrusted programs running on your = machine (i.e., in the JS VM) and that you need to secure them from each = other really is new and could use some documenting. It's worth noting, = however, that (a) that's largely about implementation and (b) that that = system strives to achieve the kind of "each endpoint its own isolated = unit" ideal that 3552 asumes. >=20 > -Ekr >=20 >=20 > On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter = > = wrote: > Hi, >=20 > I'm confused. What we have in RFC3552 is very intentionally guidance = for > RFC writers on what they need to cover in their RFCs. Its specific = purpose > was to get rid of "Security considerations are not discussed in this = memo." > Its purpose was not primarily to define an abstraction like a "trust = model" > or a "threat model" (the draft charter seems a bit vague about which = of those > it means). >=20 > I really do not want to see the pragmatic purpose of RFC3552 lost in = the > effort to define these abstractions. I don't think that is the = intention, > but the text seems to imply that RFC3552 was mainly a description of a > generic threat model, which it wasn't. >=20 > I am not against an IAB effort to analyse how the threat and trust = models > (plural) have evolved since the security workshop [RFC2316] that = ultimately > led to RFC3552. That seems like a good idea. An update of "Guidelines = for > Writing RFC Text on Security Considerations" also seems like a good = idea. > But the draft charter text seems to conflate these two separate lines = of > action. >=20 > Incidentally, while writing the above it occurred to me why the phrase > "IAB program" has always slightly disturbed me. Really the proposal is > a virtual IAB workshop (whereas RFC2316 came from three days in a room > together in Murray Hill, NJ). A good idea, but not a program. >=20 > Regards > Brian >=20 > On 25-Jan-20 00:49, Jari Arkko wrote: > > > > The IAB are considering starting up a programme on Internet > > trust model evolution as described in the link at the bottom of this > > email. > > > > We'd like to get feedback on that idea and the text. As you may > > be aware, in 2019 a number of documents were published on > > this topic and discussions held (on the mailing list, SAAG, side > > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > > meeting coming up on February 14th. > > > > To be clear, any output from this program would be text offered > > to the IETF for consideration - it is not within the IAB's remit, = nor > > that of an IAB program, to modify a BCP. Nonetheless, an IAB > > program offers a good venue for this work, as it perhaps allows > > for more focus on the evolving architecture aspect within this = space. > > > > The plan is for the new program to be entirely open for = participation, > > similar to how the current work has already been. That is, the = mailing > > list is open for all interested to join, meetings are open and = listed > > in the public agendas. The IAB will find a chair or chairs for the > > group to stay organised. > > > > There's no specific deadline for this, but the IAB will consider = this > > further in the next few weeks, so if you could take a few minutes > > to share your thoughts on this that'd be great. > > > > = https://github..com/intarchboard/model-t-charter/blob/master/model-t-chart= er-00.md = > > https://www.iab.org/mailman/listinfo/model-t = > > > > Stephen & Jari > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss = > > >=20 > -- > Model-t mailing list > Model-t@iab.org > https://www.iab.org/mailman/listinfo/model-t = > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss = --Apple-Mail=_302D8F54-40AB-4EF2-9505-7537A093C282 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

I appreciate = your specificity.  It really helps to focus the = discussion.

I = would say that the world is a more complex place than it was when 3552 = was written.  That is not to say that the = document is out of date, but rather that it is reasonable to explore = what confidentiality means in various contexts and how that relates to = integrity.

Also,= I do think it=E2=80=99s worthy addressing a slightly different threat = model: when the endpoint that you purchased may be a threat to you, and = whether there is something to be done about that.  I gave an = example on another list of an Internet toy that has an undisclosed = microphone and camera that invade=E2=80=99s a child=E2=80=99s = privacy.

We = discussed another case in which there needs to be auditing of train = signaling systems.  And there are very complex cases involving = medical devices that are probably worthy of discussion.

Does any of this require = an update to 3552?  I think that would be premature to say. =  But they=E2=80=99re probably worthy of discussion.

Eliot

On 24 Jan 2020, at 21:03, Eric Rescorla <ekr@rtfm.com> = wrote:

Brian's comments match my = recollection. Specifically, we didn't think we were *defining* a threat = model as much as documenting a consensus model that already existed. = Incidentally, it's not clear to me what a "trust model" is. This is not = a term that appears in 3552 nor is it a real term of art that I am = familiar with.

Taking a step back, I remain unpersuaded that the 3552 threat = model is really out of data. The two main deficiencies I have heard = floated are:

1. = That it doesn't take into account traffic analysis and pervasive = monitoring.
2. That the assumption that endpoints = are uncompromised is unrealistic.

I can see some merit in the first = point, but this seems to really be more a matter of emphasis: 3552 = already specifies a Dolev-Yao style attacker, which means that it can = observe all communications. So really what has happened is that we have = a clearer picture of just how realistic that is and what you can do with = that kind of access. I can see some kind of update, but again it's less = about threat model than about modern examples.

As far as the second point goes, I = think that when you are thinking about comsec protocols it's still true = that you can't do much if you don't trust the endpoints. I think 3552 = could be a bit better about recognizing that there are malicious actors = in the system, though obviously that's implicit in the discussion of = DoS. Anyway, this doesn't seem like much of an update to the threat = model. 

What= does feel dated in 3552 (at least to me) is the emphasis on a bunch of = very old school protocols and the more or less total elision of the Web. = In particular, if we're talking in terms of threat model, the idea that = you have a lot of different untrusted programs running on your machine = (i.e., in the JS VM) and that you need to secure them from each other = really is new and could use some documenting. It's worth noting, = however, that (a) that's largely about implementation and (b) that that = system strives to achieve the kind of "each endpoint its own isolated = unit" ideal that 3552 asumes.

-Ekr


On Fri, Jan 24, 2020 at 11:47 AM Brian = E Carpenter <brian.e.carpenter@gmail.com> = wrote:
Hi,

I'm confused. What = we have in RFC3552 is very intentionally guidance for
RFC = writers on what they need to cover in their RFCs. Its specific = purpose
was to get rid of "Security considerations are not = discussed in this memo." 
Its purpose = was not primarily to define an abstraction like a "trust model"
or a "threat model" (the draft charter seems a bit vague = about which of those
it means).

I really do not want to see the pragmatic purpose of RFC3552 = lost in the
effort to define these abstractions. I don't = think that is the intention,
but the text seems to imply = that RFC3552 was mainly a description of a
generic threat = model, which it wasn't.

I am not against an = IAB effort to analyse how the threat and trust models
(plural) have evolved since the security workshop [RFC2316] = that ultimately
led to RFC3552. That seems like a good = idea. An update of "Guidelines for
Writing RFC Text on = Security Considerations" also seems like a good idea.
But = the draft charter text seems to conflate these two separate lines of
action.

Incidentally, while = writing the above it occurred to me why the phrase
"IAB = program" has always slightly disturbed me. Really the proposal is
a virtual IAB workshop (whereas RFC2316 came from three days = in a room
together in Murray Hill, NJ). A good idea, but = not a program.

Regards
  =  Brian

On 25-Jan-20 00:49, Jari Arkko = wrote:
> 
> The IAB = are considering starting up a programme on Internet
> = trust model evolution as described in the link at the bottom of this
> email.
> 
> We'd = like to get feedback on that idea and the text. As you may
> be aware, in 2019 a number of documents were published = on
> this topic and discussions held (on the mailing = list, SAAG, side
> meeting at IETF-106, workshops, = etc). There=E2=80=99s also a virtual
> meeting coming = up on February 14th.
> 
> To be = clear, any output from this program would be text offered 
> to the IETF for consideration - it is not within the = IAB's remit, nor 
> that of an IAB program, to = modify a BCP. Nonetheless, an IAB 
> program = offers a good venue for this work, as it perhaps allows 
> for more focus on the evolving architecture aspect = within this space.
> 
> The = plan is for the new program to be entirely open for participation,
> similar to how the current work has already been. That = is, the mailing
> list is open for all interested to = join, meetings are open and listed
> in the public = agendas. The IAB will find a chair or chairs for the
> = group to stay organised.
> 
> There's = no specific deadline for this, but the IAB will consider this
> further in the next few weeks, so if you could take = a few minutes 
> to share your thoughts on = this that'd be great.
> 
> https://github..com/intarchboard/model-t-charter/blob/master/mo= del-t-charter-00.md
> https://www.iab.org/mailman/listinfo/model-t
> 
> Stephen & Jari
> 
> 
> = _______________________________________________
> = Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss<= br class=3D"">> 

-- 
Model-t = mailing list
Model-t@iab.org
https://www.iab.org/mailman/listinfo/model-t
_______________________________________________
Architecture-discuss mailing = list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss<= /div>

= --Apple-Mail=_302D8F54-40AB-4EF2-9505-7537A093C282-- --Apple-Mail=_9FB7251E-477E-443A-AA64-AEBB2602FE0A 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4rUsEACgkQh7ZrRtnS ejM1NggA2r3oAAi2x9j8jeKVFF7xKLSF/wdqSH18rYomJRtw7JRrRqFJRRvV6BQe /HMaCDUWcYwIkLhud4X9sQQYHdIerzns0T2qcOUA1e9VaNyJPsH2rK6Dv16IKRLe hr9KoAS3BPNq4klRnDdm7Vqq8feydzxa+I0jRRLzppMqKXbvTBNxk+RfKu4yEeaO OPYyeUnzZH6vzVn5jn/RB1RXQmSLtGlIps8CmlwiASo0Ns6IIjyNs8cePTO0RgO8 rfZ4fDO7EaErs0F2UKji+KpIiQwbsCKAU3EO15ewPUg1T5U1brNHTYRVaytu2o3d ATvNfEsYRxmkFm3zcoUabmRWA/9ItQ== =Qip7 -----END PGP SIGNATURE----- --Apple-Mail=_9FB7251E-477E-443A-AA64-AEBB2602FE0A-- From nobody Fri Jan 24 12:36:25 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BF1120884 for ; Fri, 24 Jan 2020 12:36:23 -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_HELO_NONE=0.001, 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 3UQQ0ijYmVab for ; Fri, 24 Jan 2020 12:36:21 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 EA7F1120090 for ; Fri, 24 Jan 2020 12:36:20 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id 77so2893654oty.6 for ; Fri, 24 Jan 2020 12:36:20 -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=szcwpKI+94ZldwtQcSE9NSE712HPSzRQdXfA/6GL+kA=; b=R4CEpB5kV/N0WyzoaKz5Q8IdkHLoQkUsM9WhVfMwizI0PMYRYrQPKFIKVhK2GpBUQe qIsDCVpVCi3lBsTTXtIp8o1mBfmGXJ6gDEl3PXmXrrOSSYnvCvSJYgkTamhsNqMb/dWc 8wba/GKKIbeQkjMUEnzJiWX+XD3yTSGI2ETxfjgnBXTpiFO43GXDc6gl0ISDJKwXrxMV QHVK0i8PYHHN+vNSxA7K6Z3O5PnxbDCQpMw5a4cg2IoG1uuTAeN7fCwqZkc6/jdXbSdu U9YrAa3hxQIqpd/kvA7ub0y57Yq9p8LKCGfUHGo1XjNsN9neus3SZQunbK0d4PRNOz7K /fZQ== 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=szcwpKI+94ZldwtQcSE9NSE712HPSzRQdXfA/6GL+kA=; b=NWS3OUpwpq209SZ7Tw7p5/WtEWmH19JBrnM9pTdqD9+U/vUJzkA9paOHAJeEa0pkC1 keKSbgeSDzEYuVZwt99iTqEXKmbvbe5o5mXEkLc84m71vuJaiSRwz8gsI/pNEPagJ8o3 sjagrUXdYRvo0H+/0t5l6uIZ6jHwqcUnbH6/wA5YXhKYLKvscn1+N5fu88dSD0fkOI5u qen4Xbvg7n5Wws/07RBtTlhYNox6J8lybu7+aJcMvb6o1bMi82DCLwi6BZ1lR2mz7xJH 1AnXb41B5KhIyoDJ8NLIOjVsjwHkFw/+96xLBsHGs8YXJQSMMecZVt5eOiTCfbl951c5 +UTQ== X-Gm-Message-State: APjAAAUOlTX0EILNbetdy4few2MhR4O3zuJPwOUIpKLDfGsjl0w9bFjJ m238ccUbEvYXnCo7QdKuUC9jrk3rAObF/eiSGUY= X-Google-Smtp-Source: APXvYqzdFTtkp3j04Ycp5SbKGT4j0tUwbP4N/FYWieXOTb758Vd6CbkQog6UonvOpu9fYE4ZjSqqDcbhtCa6/ysfMdk= X-Received: by 2002:a9d:6f0a:: with SMTP id n10mr4229965otq.54.1579898180165; Fri, 24 Jan 2020 12:36:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Fri, 24 Jan 2020 12:35:54 -0800 Message-ID: To: Eric Rescorla Cc: Brian E Carpenter , Jari Arkko , architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="000000000000cf64ed059ce8b57b" Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 20:36:24 -0000 --000000000000cf64ed059ce8b57b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2020 at 12:03 PM Eric Rescorla wrote: > Brian's comments match my recollection. Specifically, we didn't think we > were *defining* a threat model as much as documenting a consensus model > that already existed. Incidentally, it's not clear to me what a "trust > model" is. This is not a term that appears in 3552 nor is it a real term = of > art that I am familiar with. > > Taking a step back, I remain unpersuaded that the 3552 threat model is > really out of data. The two main deficiencies I have heard floated are: > > 1. That it doesn't take into account traffic analysis and pervasive > monitoring. > 2. That the assumption that endpoints are uncompromised is unrealistic. > > I can see some merit in the first point, but this seems to really be more > a matter of emphasis: 3552 already specifies a Dolev-Yao style attacker, > which means that it can observe all communications. > So really what has happened is that we have a clearer picture of just how > realistic that is and what you can do with that kind of access. I can see > some kind of update, but again it's less about threat model than about > modern examples. > One of the changes I'm interested in seeing is a shift away from seeing this in terms of a single communication channel, which I believe is inherent in this text: By contrast, we assume that the attacker has nearly complete control of the communications channel over which the end-systems communicate. This means that the attacker can read any PDU (Protocol Data Unit) on the network and undetectably remove, change, or inject forged packets onto the wire. This includes being able to generate packets that appear to be from a trusted machine. Thus, even if the end-system with which you wish to communicate is itself secure, the Internet environment provides no assurance that packets which claim to be from that system in fact are. One of the biggest shifts in the pervasive surveillance case is that the attacker is both likely to be present on any alternative communication channel and likely has sufficient context over time to cross-correlate communications. We're moving from an omnipotent attacker to one that is also both omnipresent and eternal. While that may have been obvious to those specifying RFC 3552, it is hard to read in the current document for those who were once more na=C3=AFve. That doesn't really mean RFC 3552 is wrong, just that explaining the implications in the current context may be useful. As far as the second point goes, I think that when you are thinking about > comsec protocols it's still true that you can't do much if you don't trus= t > the endpoints. I think 3552 could be a bit better about recognizing that > there are malicious actors in the system, though obviously that's implici= t > in the discussion of DoS. Anyway, this doesn't seem like much of an updat= e > to the threat model. > > Here, I think the point is really to move the IETF away from thinking in terms of host requirements. I agree with you that there are pieces to this that are very similar whether you think of JS code in a sandboxed tab or about an IoT device or about TOPS-20 device connected to an IMP. But if you assume that the PC running the browser hosting that tab is the unit of analysis, you might have a very bad time. Again, not really a change in the threat model, but a change in the context. This may be a way of saying that I agree with your point below. regards, Ted > What does feel dated in 3552 (at least to me) is the emphasis on a bunch > of very old school protocols and the more or less total elision of the We= b. > In particular, if we're talking in terms of threat model, the idea that y= ou > have a lot of different untrusted programs running on your machine (i.e., > in the JS VM) and that you need to secure them from each other really is > new and could use some documenting. It's worth noting, however, that (a) > that's largely about implementation and (b) that that system strives to > achieve the kind of "each endpoint its own isolated unit" ideal that 3552 > asumes. > > -Ekr > > > On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Hi, >> >> I'm confused. What we have in RFC3552 is very intentionally guidance for >> RFC writers on what they need to cover in their RFCs. Its specific purpo= se >> was to get rid of "Security considerations are not discussed in this >> memo." >> Its purpose was not primarily to define an abstraction like a "trust >> model" >> or a "threat model" (the draft charter seems a bit vague about which of >> those >> it means). >> >> I really do not want to see the pragmatic purpose of RFC3552 lost in the >> effort to define these abstractions. I don't think that is the intention= , >> but the text seems to imply that RFC3552 was mainly a description of a >> generic threat model, which it wasn't. >> >> I am not against an IAB effort to analyse how the threat and trust model= s >> (plural) have evolved since the security workshop [RFC2316] that >> ultimately >> led to RFC3552. That seems like a good idea. An update of "Guidelines fo= r >> Writing RFC Text on Security Considerations" also seems like a good idea= . >> But the draft charter text seems to conflate these two separate lines of >> action. >> >> Incidentally, while writing the above it occurred to me why the phrase >> "IAB program" has always slightly disturbed me. Really the proposal is >> a virtual IAB workshop (whereas RFC2316 came from three days in a room >> together in Murray Hill, NJ). A good idea, but not a program. >> >> Regards >> Brian >> >> On 25-Jan-20 00:49, Jari Arkko wrote: >> > >> > The IAB are considering starting up a programme on Internet >> > trust model evolution as described in the link at the bottom of this >> > email. >> > >> > We'd like to get feedback on that idea and the text. As you may >> > be aware, in 2019 a number of documents were published on >> > this topic and discussions held (on the mailing list, SAAG, side >> > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual >> > meeting coming up on February 14th. >> > >> > To be clear, any output from this program would be text offered >> > to the IETF for consideration - it is not within the IAB's remit, nor >> > that of an IAB program, to modify a BCP. Nonetheless, an IAB >> > program offers a good venue for this work, as it perhaps allows >> > for more focus on the evolving architecture aspect within this space. >> > >> > The plan is for the new program to be entirely open for participation, >> > similar to how the current work has already been. That is, the mailing >> > list is open for all interested to join, meetings are open and listed >> > in the public agendas. The IAB will find a chair or chairs for the >> > group to stay organised. >> > >> > There's no specific deadline for this, but the IAB will consider this >> > further in the next few weeks, so if you could take a few minutes >> > to share your thoughts on this that'd be great. >> > >> > >> https://github..com/intarchboard/model-t-charter/blob/master/model-t-cha= rter-00.md >> >> > https://www.iab.org/mailman/listinfo/model-t >> > >> > Stephen & Jari >> > >> > >> > _______________________________________________ >> > Architecture-discuss mailing list >> > Architecture-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/architecture-discuss >> > >> >> -- >> Model-t mailing list >> Model-t@iab.org >> https://www.iab.org/mailman/listinfo/model-t >> > -- > Model-t mailing list > Model-t@iab.org > https://www.iab.org/mailman/listinfo/model-t > --000000000000cf64ed059ce8b57b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 24, 2020 at 12:03 PM Eric Res= corla <ekr@rtfm.com> wrote:
Brian's comments match my recollection. Spe= cifically, we didn't think we were *defining* a threat model as much as= documenting a consensus model that already existed. Incidentally, it's= not clear to me what a "trust model" is. This is not a term that= appears in 3552 nor is it a real term of art that I am familiar with.

Taking a step back, I remain unpersuaded that the 3552= threat model is really out of data. The two main deficiencies I have heard= floated are:

1. That it doesn't take into acc= ount traffic analysis and pervasive monitoring.
2. That the assum= ption that endpoints are uncompromised is unrealistic.

=
I can see some merit in the first point, but this seems to really be m= ore a matter of emphasis: 3552 already specifies a Dolev-Yao style attacker= , which means that it can observe all communications.
=
So really what has happened is that we have a clearer picture of just = how realistic that is and what you can do with that kind of access. I can s= ee some kind of update, but again it's less about threat model than abo= ut modern examples.

One of the = changes I'm interested in seeing is a shift away from seeing this in te= rms of a single communication channel, which I believe is inherent in this = text:

   By contrast,=
 we assume that the attacker has nearly complete control
   of the communications channel over which the end-systems communicate.
   This means that the attacker can read any PDU (Protocol Data Unit) on
   the network and undetectably remove, change, or inject forged packets
   onto the wire.  This includes being able to generate packets that
   appear to be from a trusted machine.  Thus, even if the end-system
   with which you wish to communicate is itself secure, the Internet
   environment provides no assurance that packets which claim to be from
   that system in fact are.
=C2=A0
One of the big= gest shifts in the pervasive surveillance case is that the attacker is both= likely to be present on any alternative communication channel and likely h= as sufficient context over time to cross-correlate communications.=C2=A0 We= 're moving from an omnipotent attacker to one that is also both omnipre= sent and eternal.=C2=A0 While that may have been obvious to those specifyin= g RFC 3552, it is hard to read in the current document for those who were o= nce more na=C3=AFve. =C2=A0 That doesn't really mean RFC 3552 is wrong,= just that explaining the implications in the current context may be useful= .

As far as the second point goes, I think = that when you are thinking about comsec protocols it's still true that = you can't do much if you don't trust the endpoints. I think 3552 co= uld be a bit better about recognizing that there are malicious actors in th= e system, though obviously that's implicit in the discussion of DoS. An= yway, this doesn't seem like much of an update to the threat model.


Here, I think = the point is really to move the IETF away from thinking in terms of host re= quirements. I agree with you that there are pieces to this that are very si= milar whether you think of=C2=A0 JS code in a sandboxed tab or about an IoT= device or about TOPS-20 device connected to an IMP.=C2=A0 But if you assum= e that the PC running the browser hosting that tab is the unit of analysis,= you might have a very bad time.=C2=A0 Again, not really a change in the th= reat model, but a change in the context.=C2=A0 This may be a way of saying = that I agree with your point below.

regards,

Ted
=C2=A0
What does fee= l dated in 3552 (at least to me) is the emphasis on a bunch of very old sch= ool protocols and the more or less total elision of the Web. In particular,= if we're talking in terms of threat model, the idea that you have a lo= t of different untrusted programs running on your machine (i.e., in the JS = VM) and that you need to secure them from each other really is new and coul= d use some documenting. It's worth noting, however, that (a) that's= largely about implementation and (b) that that system strives to achieve t= he kind of "each endpoint its own isolated unit" ideal that 3552 = asumes.

-Ekr


On Fri, Jan 24, 202= 0 at 11:47 AM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi,

I'm confused. What we have in RFC3552 is very intentionally guidance fo= r
RFC writers on what they need to cover in their RFCs. Its specific purpose<= br> was to get rid of "Security considerations are not discussed in this m= emo."
Its purpose was not primarily to define an abstraction like a "trust m= odel"
or a "threat model" (the draft charter seems a bit vague about wh= ich of those
it means).

I really do not want to see the pragmatic purpose of RFC3552 lost in the effort to define these abstractions. I don't think that is the intentio= n,
but the text seems to imply that RFC3552 was mainly a description of a
generic threat model, which it wasn't.

I am not against an IAB effort to analyse how the threat and trust models (plural) have evolved since the security workshop [RFC2316] that ultimately=
led to RFC3552. That seems like a good idea. An update of "Guidelines = for
Writing RFC Text on Security Considerations" also seems like a good id= ea.
But the draft charter text seems to conflate these two separate lines of action.

Incidentally, while writing the above it occurred to me why the phrase
"IAB program" has always slightly disturbed me. Really the propos= al is
a virtual IAB workshop (whereas RFC2316 came from three days in a room
together in Murray Hill, NJ). A good idea, but not a program.

Regards
=C2=A0 =C2=A0Brian

On 25-Jan-20 00:49, Jari Arkko wrote:
>
> The IAB are considering starting up a programme on Internet
> trust model evolution as described in the link at the bottom of this > email.
>
> We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on
> this topic and discussions held (on the mailing list, SAAG, side
> meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th.
>
> To be clear, any output from this program would be text offered=C2=A0<= br> > to the IETF for consideration - it is not within the IAB's remit, = nor=C2=A0
> that of an IAB program, to modify a BCP. Nonetheless, an IAB=C2=A0
> program offers a good venue for this work, as it perhaps allows=C2=A0<= br> > for more focus on the evolving architecture aspect within this space.<= br> >
> The plan is for the new program to be entirely open for participation,=
> similar to how the current work has already been. That is, the mailing=
> list is open for all interested to join, meetings are open and listed<= br> > in the public agendas. The IAB will find a chair or chairs for the
> group to stay organised.
>
> There's no specific deadline for this, but the IAB will=C2=A0consi= der this
> further in the next few weeks, so if you could=C2=A0take a few minutes= =C2=A0
> to share your thoughts on this=C2=A0that'd be great.
>
> https://github= ..com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md > https://www.iab.org/mailman/listinfo/model-t >
> Stephen & Jari
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss
>

--
Model-t mailing list
Model-t@iab.org https://www.iab.org/mailman/listinfo/model-t
--
Model-t mailing list
Model-t@iab.org https://www.iab.org/mailman/listinfo/model-t
--000000000000cf64ed059ce8b57b-- From nobody Fri Jan 24 12:51:23 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E64E120884 for ; Fri, 24 Jan 2020 12:51:21 -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_HELO_NONE=0.001, 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 HHU0r7Le_U7M for ; Fri, 24 Jan 2020 12:51:18 -0800 (PST) Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 AE03A120858 for ; Fri, 24 Jan 2020 12:51:18 -0800 (PST) Received: by mail-vk1-xa2e.google.com with SMTP id w67so1033180vkf.1 for ; Fri, 24 Jan 2020 12:51:18 -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=yrSrtigg4k7RLwed//yyNsKSqLbNzbDjSQNJA8wwlvY=; b=vPO1g3wi06cnn3cgxkYWmDuMAPp6hfHnu1+AYcsySq8jnLDtTzzBAmci1I44yv3U3e tmb4GTHhYARHnCQ7Nmho7bzV3N4yOwn+6Ugv54bIdLDyAKk63jE7p1kH9linfPNE09Nz fzS4kkvmJNEXoDh7Tk38CHbYRKN/R6Hl1vlFHA2Zz4b+kIEcK5+mSPkqCkXGa2bz/0Ft POEHA/knwRrlWPYkvEytmsBTnB6gQ2yku5Lhq26mtjceSGA623s73EzenrtmfBQNjfdH pg2b0QQHVFxuJGPfOIiD0C8OYIR30m4LgnLh2CMfAfC3Uecx01J578M3KSCvVxxsumFx GOsQ== 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=yrSrtigg4k7RLwed//yyNsKSqLbNzbDjSQNJA8wwlvY=; b=p/8kKKtBE9qWJxGfxczTJJaBmHu2YY/nOM6gaEDu8YNOftP8+g/RyyvTvm3HZ6tTZf Pp3L6+J1SRHGAn41b+E488uxRLLm7hlEJ26GN4GW95Nbv1A7V+d9hebj83GPj9A/GaQ5 aYgMRm+UMfozfR7OFLM7DSK2Rg7C/+aPMaLFdQkdTl+qUCAONRDFWJiX2c3X7Kdl3l9V K5L/kQ0j5DfN1o+p8nFJ1sIYRV11Er3xi/8UYqsbWwhtAizQOJ/x3E6IEreNbPFdWWZ1 BfIAWuPI5ZduijJQeJ+7QsbwrSXBWPpx4ukIJe7pCwDmd9lNRiT49hSidD+Yto33E1LP VWBA== X-Gm-Message-State: APjAAAUn2mdxdgoQ1qjyq6lJIS3EFiTVAEC0Bq0tLft1DV2ohC2DHw+C 7PTGzN46Oajkkn0mFhMFK414ahILzxCPiOnLJFo= X-Google-Smtp-Source: APXvYqySmj6ZH8OHaVEYLTAJTPx1bRpkQl75PUDevmSrdBdah5aEHJ0Uuk87ql29NJOqlUPK+9dTzam77sClaUzthjU= X-Received: by 2002:a1f:bd87:: with SMTP id n129mr3339771vkf.23.1579899077298; Fri, 24 Jan 2020 12:51:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Fri, 24 Jan 2020 12:51:06 -0800 Message-ID: To: Eric Rescorla Cc: Brian E Carpenter , architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="000000000000488df8059ce8eb55" Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 20:51:22 -0000 --000000000000488df8059ce8eb55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable EKR said: "What does feel dated in 3552 (at least to me) is the emphasis on a bunch of very old school protocols and the more or less total elision of the Web. In particular, if we're talking in terms of threat model, the idea that you have a lot of different untrusted programs running on your machine (i.e., in the JS VM) and that you need to secure them from each other really is new and could use some documenting. It's worth noting, however, that (a) that's largely about implementation and (b) that that system strives to achieve the kind of "each endpoint its own isolated unit" ideal that 3552 asumes." [BA] I agree that RFC 3552 does feel dated with respect to today's Web. In a number of cases, it has become clear that the term "endpoint" is too general, and that we may need to define much more precisely what endpoint elements (e.g. JS applications, native browser code, trusted hardware modules, etc.) are trusted with what data. On Fri, Jan 24, 2020 at 12:04 PM Eric Rescorla wrote: > Brian's comments match my recollection. Specifically, we didn't think we > were *defining* a threat model as much as documenting a consensus model > that already existed. Incidentally, it's not clear to me what a "trust > model" is. This is not a term that appears in 3552 nor is it a real term = of > art that I am familiar with. > > Taking a step back, I remain unpersuaded that the 3552 threat model is > really out of data. The two main deficiencies I have heard floated are: > > 1. That it doesn't take into account traffic analysis and pervasive > monitoring. > 2. That the assumption that endpoints are uncompromised is unrealistic. > > I can see some merit in the first point, but this seems to really be more > a matter of emphasis: 3552 already specifies a Dolev-Yao style attacker, > which means that it can observe all communications. So really what has > happened is that we have a clearer picture of just how realistic that is > and what you can do with that kind of access. I can see some kind of > update, but again it's less about threat model than about modern examples= . > > As far as the second point goes, I think that when you are thinking about > comsec protocols it's still true that you can't do much if you don't trus= t > the endpoints. I think 3552 could be a bit better about recognizing that > there are malicious actors in the system, though obviously that's implici= t > in the discussion of DoS. Anyway, this doesn't seem like much of an updat= e > to the threat model. > > What does feel dated in 3552 (at least to me) is the emphasis on a bunch > of very old school protocols and the more or less total elision of the We= b. > In particular, if we're talking in terms of threat model, the idea that y= ou > have a lot of different untrusted programs running on your machine (i.e., > in the JS VM) and that you need to secure them from each other really is > new and could use some documenting. It's worth noting, however, that (a) > that's largely about implementation and (b) that that system strives to > achieve the kind of "each endpoint its own isolated unit" ideal that 3552 > asumes. > > -Ekr > > > On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Hi, >> >> I'm confused. What we have in RFC3552 is very intentionally guidance for >> RFC writers on what they need to cover in their RFCs. Its specific purpo= se >> was to get rid of "Security considerations are not discussed in this >> memo." >> Its purpose was not primarily to define an abstraction like a "trust >> model" >> or a "threat model" (the draft charter seems a bit vague about which of >> those >> it means). >> >> I really do not want to see the pragmatic purpose of RFC3552 lost in the >> effort to define these abstractions. I don't think that is the intention= , >> but the text seems to imply that RFC3552 was mainly a description of a >> generic threat model, which it wasn't. >> >> I am not against an IAB effort to analyse how the threat and trust model= s >> (plural) have evolved since the security workshop [RFC2316] that >> ultimately >> led to RFC3552. That seems like a good idea. An update of "Guidelines fo= r >> Writing RFC Text on Security Considerations" also seems like a good idea= . >> But the draft charter text seems to conflate these two separate lines of >> action. >> >> Incidentally, while writing the above it occurred to me why the phrase >> "IAB program" has always slightly disturbed me. Really the proposal is >> a virtual IAB workshop (whereas RFC2316 came from three days in a room >> together in Murray Hill, NJ). A good idea, but not a program. >> >> Regards >> Brian >> >> On 25-Jan-20 00:49, Jari Arkko wrote: >> > >> > The IAB are considering starting up a programme on Internet >> > trust model evolution as described in the link at the bottom of this >> > email. >> > >> > We'd like to get feedback on that idea and the text. As you may >> > be aware, in 2019 a number of documents were published on >> > this topic and discussions held (on the mailing list, SAAG, side >> > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual >> > meeting coming up on February 14th. >> > >> > To be clear, any output from this program would be text offered >> > to the IETF for consideration - it is not within the IAB's remit, nor >> > that of an IAB program, to modify a BCP. Nonetheless, an IAB >> > program offers a good venue for this work, as it perhaps allows >> > for more focus on the evolving architecture aspect within this space. >> > >> > The plan is for the new program to be entirely open for participation, >> > similar to how the current work has already been. That is, the mailing >> > list is open for all interested to join, meetings are open and listed >> > in the public agendas. The IAB will find a chair or chairs for the >> > group to stay organised. >> > >> > There's no specific deadline for this, but the IAB will consider this >> > further in the next few weeks, so if you could take a few minutes >> > to share your thoughts on this that'd be great. >> > >> > >> https://github..com/intarchboard/model-t-charter/blob/master/model-t-cha= rter-00.md >> >> > https://www.iab.org/mailman/listinfo/model-t >> > >> > Stephen & Jari >> > >> > >> > _______________________________________________ >> > Architecture-discuss mailing list >> > Architecture-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/architecture-discuss >> > >> >> -- >> Model-t mailing list >> Model-t@iab.org >> https://www.iab.org/mailman/listinfo/model-t >> > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000488df8059ce8eb55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
EKR said:=C2=A0

"= What does feel dated in 3552 (at least to me) is the emphasis on a bunch of= very old school protocols and the more or less total elision of the Web. I= n particular, if we're talking in terms of threat model, the idea that = you have a lot of different untrusted programs running on your machine (i.e= ., in the JS VM) and that you need to secure them from each other really is= new and could use some documenting. It's worth noting, however, that (= a) that's largely about implementation and (b) that that system strives= to achieve the kind of "each endpoint its own isolated unit" ide= al that 3552 asumes."

[BA] I agree that RFC 3= 552 does feel dated with respect to today's Web.=C2=A0 In a number of c= ases, it has become clear that the term "endpoint" is too general= , and that we may need to define much more precisely what endpoint elements= (e.g. JS applications, native browser code, trusted hardware modules, etc.= ) are trusted with what data.

On Fri, Jan 24, 2020 at 12:04 PM E= ric Rescorla <ekr@rtfm.com> wrote= :
Brian's comments match my recollection. Specifically, we didn&#= 39;t think we were *defining* a threat model as much as documenting a conse= nsus model that already existed. Incidentally, it's not clear to me wha= t a "trust model" is. This is not a term that appears in 3552 nor= is it a real term of art that I am familiar with.

Taking a step back, I remain unpersuaded that the 3552 threat model is rea= lly out of data. The two main deficiencies I have heard floated are:
<= div>
1. That it doesn't take into account traffic analysi= s and pervasive monitoring.
2. That the assumption that endpoints= are uncompromised is unrealistic.

I can see some = merit in the first point, but this seems to really be more a matter of emph= asis: 3552 already specifies a Dolev-Yao style attacker, which means that i= t can observe all communications. So really what has happened is that we ha= ve a clearer picture of just how realistic that is and what you can do with= that kind of access. I can see some kind of update, but again it's les= s about threat model than about modern examples.

A= s far as the second point goes, I think that when you are thinking about co= msec protocols it's still true that you can't do much if you don= 9;t trust the endpoints. I think 3552 could be a bit better about recognizi= ng that there are malicious actors in the system, though obviously that'= ;s implicit in the discussion of DoS. Anyway, this doesn't seem like mu= ch of an update to the threat model.

What doe= s feel dated in 3552 (at least to me) is the emphasis on a bunch of very ol= d school protocols and the more or less total elision of the Web. In partic= ular, if we're talking in terms of threat model, the idea that you have= a lot of different untrusted programs running on your machine (i.e., in th= e JS VM) and that you need to secure them from each other really is new and= could use some documenting. It's worth noting, however, that (a) that&= #39;s largely about implementation and (b) that that system strives to achi= eve the kind of "each endpoint its own isolated unit" ideal that = 3552 asumes.

-Ekr


On Fri, Jan 24= , 2020 at 11:47 AM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi,

I'm confused. What we have in RFC3552 is very intentionally guidance fo= r
RFC writers on what they need to cover in their RFCs. Its specific purpose<= br> was to get rid of "Security considerations are not discussed in this m= emo."
Its purpose was not primarily to define an abstraction like a "trust m= odel"
or a "threat model" (the draft charter seems a bit vague about wh= ich of those
it means).

I really do not want to see the pragmatic purpose of RFC3552 lost in the effort to define these abstractions. I don't think that is the intentio= n,
but the text seems to imply that RFC3552 was mainly a description of a
generic threat model, which it wasn't.

I am not against an IAB effort to analyse how the threat and trust models (plural) have evolved since the security workshop [RFC2316] that ultimately=
led to RFC3552. That seems like a good idea. An update of "Guidelines = for
Writing RFC Text on Security Considerations" also seems like a good id= ea.
But the draft charter text seems to conflate these two separate lines of action.

Incidentally, while writing the above it occurred to me why the phrase
"IAB program" has always slightly disturbed me. Really the propos= al is
a virtual IAB workshop (whereas RFC2316 came from three days in a room
together in Murray Hill, NJ). A good idea, but not a program.

Regards
=C2=A0 =C2=A0Brian

On 25-Jan-20 00:49, Jari Arkko wrote:
>
> The IAB are considering starting up a programme on Internet
> trust model evolution as described in the link at the bottom of this > email.
>
> We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on
> this topic and discussions held (on the mailing list, SAAG, side
> meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th.
>
> To be clear, any output from this program would be text offered=C2=A0<= br> > to the IETF for consideration - it is not within the IAB's remit, = nor=C2=A0
> that of an IAB program, to modify a BCP. Nonetheless, an IAB=C2=A0
> program offers a good venue for this work, as it perhaps allows=C2=A0<= br> > for more focus on the evolving architecture aspect within this space.<= br> >
> The plan is for the new program to be entirely open for participation,=
> similar to how the current work has already been. That is, the mailing=
> list is open for all interested to join, meetings are open and listed<= br> > in the public agendas. The IAB will find a chair or chairs for the
> group to stay organised.
>
> There's no specific deadline for this, but the IAB will=C2=A0consi= der this
> further in the next few weeks, so if you could=C2=A0take a few minutes= =C2=A0
> to share your thoughts on this=C2=A0that'd be great.
>
> https://github= ..com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md > https://www.iab.org/mailman/listinfo/model-t >
> Stephen & Jari
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss
>

--
Model-t mailing list
Model-t@iab.org https://www.iab.org/mailman/listinfo/model-t
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000488df8059ce8eb55-- From nobody Fri Jan 24 15:59:19 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E74C120047 for ; Fri, 24 Jan 2020 15:59:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=elandsys.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 E6XJFn2wW3_E for ; Fri, 24 Jan 2020 15:59:16 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0112001B for ; Fri, 24 Jan 2020 15:59:16 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.146.21]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00ONx3ig002308 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jan 2020 15:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579910354; x=1579996754; i=@elandsys.com; bh=1pxOdHbHsV8BDFTGeMW9u5m77jINHGTC96I6aCXHR0A=; h=Date:To:From:Subject:In-Reply-To:References; b=a2NF4GHjOlX6kiJ0fOhIsw1aL3uZxL2l5CBjum/zghmWJ5pSjwqqYiyNRuKwvHRAA 9smAwjTsIM2orsA7w6w7kPPlHbb23CZHqQVDxDtvbv8cbs2lV0XumPkVRbuvG1SeTa DrBPDcz2aHQmdXxsaTvqAb9CRVGZCu9np4VhvHfU= Message-Id: <6.2.5.6.2.20200124145657.13907ec8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Jan 2020 15:58:50 -0800 To: Mark Nottingham , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> <6.2.5.6.2.20200123013903.0be41930@elandnews.com> <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] New Version Notification for draft-iab-for-the-users-01.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 23:59:18 -0000 Hi Mark, At 09:36 PM 23-01-2020, Mark Nottingham wrote: >I'm not sure what you mean. I don't see a literal question mark near >the reference in the published text document. Sorry for not being clear. There isn't a literal question mark. I'll try and explain the point. There is the following text: "We embrace technical concepts such as decentralized control ..." The reality is that the "control" has moved in the opposite direction, i.e. there is centralization. The "social good" is being challenged because of significant cases of misuse. The misuse range from the impact on the individual to impact at country level. >They are contrasting the IETF community with the (broader, greater) >Internet community. Ok. >I'm not sure there's anything actionable in your statement here, so >I'll just move on. Ok. >As explained elsewhere in the document, we don't rely on end users >coming to present their case in person, as it were. On whom does the IAB rely on to present the case? Is it the governments which represent the users as that is usually what governments do? There is text in the draft which states that it is not automatic. Is it the advocacy groups which participate in the Internet Engineering Task Force? Is it the engineer who participates in the Internet Engineering Task Force? Regards, S. Moonesamy From nobody Fri Jan 24 17:56:22 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EFB120BEE for ; Fri, 24 Jan 2020 17:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In6tUvTdd4x0 for ; Fri, 24 Jan 2020 17:56:09 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 9FF00120AAD for ; Fri, 24 Jan 2020 17:56:09 -0800 (PST) Received: from xse155.mail2web.com ([66.113.196.155] helo=xse.mail2web.com) by mx63.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1ivAg9-0001Ir-GP for architecture-discuss@ietf.org; Sat, 25 Jan 2020 02:56:07 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 484JyB3SzjzVp4 for ; Fri, 24 Jan 2020 17:56:02 -0800 (PST) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1ivAg6-0001Ox-BL for architecture-discuss@ietf.org; Fri, 24 Jan 2020 17:56:02 -0800 Received: (qmail 14932 invoked from network); 25 Jan 2020 01:56:02 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.58.46.251]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Jan 2020 01:56:01 -0000 To: Ted Hardie , Eric Rescorla Cc: model-t@iab.org, Jari Arkko , Brian E Carpenter , architecture-discuss@ietf.org References: From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> Date: Fri, 24 Jan 2020 17:56:02 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2F492A55B3B95B4109930A8F" Content-Language: en-US X-Originating-IP: 66.113.196.155 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.155/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.155/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Xm17NJf4el5vffImWwWrhCpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX7cIPTurxi+anoa7d21Zj8H1O05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PuWgeIrczWdOwnaj/ijHxo0Dy4QU4b3YMjzePcsw0M0R2Oo0r3 6TvtZGZKJo7Ywel+UOUPX0VHiKUyAtskn6r56i8KMZYGrZmgW9KwYivcW5A61Ks3CiInn/dDFS2W PS2yGYffiENaEvSwZ91SD/eSc+7o0ZSfcEjJYb2rnSV2fRCARv6mkfvK/UihTJjyS3/OdDr2WLJq FULjiIcCiyuiCgTQeC2dL1Bxyk8yV+29SYS0kEOL0o9EBIpturfzKMtFD1+RO9x9UH6x/+ZJK1fw q9G5tr1naPLrD+uYvNqtQnWYBq6S+OMHcfXl6o0I271KKTjECb0PwpN4olPuA0AI937kIM09yvSV B0zYhsH8AJv1sZ6A4UiMLncqmlNSYHCjDluApI7WQQfRBNZVOkD17qrHW4mAQpSSPjTGz7eIGToH mFDqewO9xyOqCYO8P1aH7p0Yfjtn1vCWVsHan3G4FeAaplS5yHZ5tN0/4QM1AVRdeu+6D1xe6+c7 Ft92TZYqs8BEt2tFC1DQGhfOMeiY98yfZPNx4cTaQXTBLR6bqlnUPOEBvPSTejL6TXcy6lu6RfCf KaAJdeRTWASHqAEqZRxwEiTVJqDh0qKoKsXx5lkVnK0YS3gd+LN4VG99hjvtkLrbJKXDgkqcbIfE GI9mKNPEFdzaPktprEQ3qb+cP5JBtL9ewJnoHKUNLZpf7DfZZjMv6PN41V03H2/ZNJy1m5Scu7sV encPI85bGjWXuocpzCXI8Q8ncbCRI7u+gO19UCFcnal6WejB4YisLPSIrrdvK/cKOEqlCIPGIfYQ DNJ9yy88fxdoE98JfCUCbwYa X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 01:56:16 -0000 This is a multi-part message in MIME format. --------------2F492A55B3B95B4109930A8F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/24/2020 12:35 PM, Ted Hardie wrote: > As far as the second point goes, I think that when you are > thinking about comsec protocols it's still true that you can't do > much if you don't trust the endpoints. I think 3552 could be a bit > better about recognizing that there are malicious actors in the > system, though obviously that's implicit in the discussion of DoS. > Anyway, this doesn't seem like much of an update to the threat mode= l. > > > Here, I think the point is really to move the IETF away from thinking > in terms of host requirements. I agree with you that there are pieces > to this that are very similar whether you think of=C2=A0 JS code in a > sandboxed tab or about an IoT device or about TOPS-20 device connected > to an IMP.=C2=A0 But if you assume that the PC running the browser host= ing > that tab is the unit of analysis, you might have a very bad time.=C2=A0= > Again, not really a change in the threat model, but a change in the > context.=C2=A0 This may be a way of saying that I agree with your point= below. Phrasing that as "don't trust the endpoints" is probably inappropriate. My personal worry is the cascading impact of end-point compromise. Take the example of a large network. Large network means multiple routers. If the multiple is high enough, we have strong risks that one of those will be compromised at some point. If we merely "trust the endpoints", then a single compromise of one of the endpoints means the game is over. But it does not have to be so. In an ideal world, implementations of the routing protocol should be able to detect aberrant behavior and isolate the compromised node. In practice, that's really hard. But there are still general principles like "least amount of privilege" or "need to know basis" that could help. I would really like that protocol designers think about that too, instead of merely asserting trust in the endpoints.= And I would really like to get rid of the assumption about isolated networks being secure... -- Christian Huitema --------------2F492A55B3B95B4109930A8F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 1/24/2020 12:35 PM, Ted Hardie wrote:

As far as the second point goes, I think that when you are thinking about comsec protocols it's still true that you can't do much if you don't trust the endpoints. I think 3552 could be a bit better about recognizing that there are malicious actors in the system, though obviously that's implicit in the discussion of DoS. Anyway, this doesn't seem like much of an update to the threat model.


Here, I think the point is really to move the IETF away from thinking in terms of host requirements. I agree with you that there are pieces to this that are very similar whether you think of  JS code in a sandboxed tab or about an IoT device or about TOPS-20 device connected to an IMP.  But if you assume that the PC running the browser hosting that tab is the unit of analysis, you might have a very bad time.  Again, not really a change in the threat model, but a change in the context.  This may be a way of saying that I agree with your point below.


Phrasing that as "don't trust the endpoints" is probably inappropriate. My personal worry is the cascading impact of end-point compromise. Take the example of a large network. Large network means multiple routers. If the multiple is high enough, we have strong risks that one of those will be compromised at some point. If we merely "trust the endpoints", then a single compromise of one of the endpoints means the game is over. But it does not have to be so. In an ideal world, implementations of the routing protocol should be able to detect aberrant behavior and isolate the compromised node. In practice, that's really hard. But there are still general principles like "least amount of privilege" or "need to know basis" that could help. I would really like that protocol designers think about that too, instead of merely asserting trust in the endpoints.

And I would really like to get rid of the assumption about isolated networks being secure...

-- Christian Huitema

--------------2F492A55B3B95B4109930A8F-- From nobody Sat Jan 25 02:13:38 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F422120072 for ; Sat, 25 Jan 2020 02:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, 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 4qCAEZGTLmMQ for ; Sat, 25 Jan 2020 02:13: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 3D6B1120099 for ; Sat, 25 Jan 2020 02:13:33 -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 E5A606A27C; Sat, 25 Jan 2020 11:13:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1579947210; bh=i6opt6G4ttZ9OGPdj3gmQkR6/yYhWmcMm841x6ZDWpg=; h=Date:From:To:In-Reply-To:References:Subject:From; b=i00gVBYNpRUWimAQNFA9IZBAjhwtSRl91svnAfk1L5kKADurR2fIkosK7ByFS2PuM w1dWrpfygcSFxIwC6Rjn/xAScZW7hpyWHLgvbtIDHek45vlXdGoOUsXADIjyzhrfaT WtGYmSZzldBwJRRFBSR6+hHQTh65chX9Snu0m8oexXqVQ04H858HgCrpptLhjejGU3 QTfzfBKOWtiXlnWQtnd2Yo1WfPN+RpNT/UZHH5g1eias1q7zVS/G7wkMhqQZAUtWwi dfpAWCo2UlKUocbErqZ2xm6Lm1eYm4myMWevYFphaIpctU//x2swWiAnv5M1bxfRs3 sqD3Kvv7lL3SQ== 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 CBA7A3C0487; Sat, 25 Jan 2020 11:13:30 +0100 (CET) Date: Sat, 25 Jan 2020 11:13:30 +0100 (CET) From: Vittorio Bertola To: S Moonesamy , architecture-discuss@ietf.org Message-ID: <2045272851.58869.1579947210706@appsuite-gw1.open-xchange.com> In-Reply-To: <6.2.5.6.2.20200124145657.13907ec8@elandnews.com> References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com> <6.2.5.6.2.20191214065306.11c9aa98@elandnews.com> <61975615-0DB9-4683-84B5-A4BB5441C467@mnot.net> <6.2.5.6.2.20200123013903.0be41930@elandnews.com> <22E03B8F-8026-43EE-BDC6-96130DBD1877@mnot.net> <6.2.5.6.2.20200124145657.13907ec8@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev3 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [arch-d] New Version Notification for draft-iab-for-the-users-01.txt X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 10:13:36 -0000 > Il 25/01/2020 00:58 S Moonesamy ha scritto: > > >As explained elsewhere in the document, we don't rely on end users > >coming to present their case in person, as it were. > > On whom does the IAB rely on to present the case? > > Is it the governments which represent the users as that is usually > what governments do? There is text in the draft which states that it > is not automatic. Is it the advocacy groups which participate in the > Internet Engineering Task Force? Is it the engineer who participates > in the Internet Engineering Task Force? I also do not get the logic of this part of the text. If - as you said - even governmental representatives cannot represent users and advocate their views because everyone in the IETF participates as an individual, then how come that "civil society organisations specialise[d] in technology and Internet policy", or "industry associations, user groups, or a set of individuals", as mentioned in 4.1, should instead be able to do so? If people really participate in the IETF as individuals, as a minimum only end-users are able to advocate for themselves, and as a maximum there is no such thing as "end-user views", opposed to the views of other stakeholders, because there are no stakeholders and we are all equal human beings (which IMHO is a super-naive view). Otherwise, if there are conflicting stakeholder needs and the IETF needs to prioritize one stakeholder over others, then participants are not individuals but part and representatives of a stakeholder group, and then we have to enter into the definition and organization of stakeholders and of their representativeness (which is what all other I* organizations have been doing for the last 20 years). Just pick one - we can't have both at the same time. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Sat Jan 25 09:58:12 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7276C12006E for ; Sat, 25 Jan 2020 09:58:11 -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_HIGH=-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=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 kQa5f3l6549I for ; Sat, 25 Jan 2020 09:58:09 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77002120048 for ; Sat, 25 Jan 2020 09:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5232; q=dns/txt; s=iport; t=1579975089; x=1581184689; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=MHVGZLB2YwMloGKtvfsM2b0yls7IiDU5qHSXBdcigm0=; b=YWDUeVzbpPys8BXKky2ityE/3H9sgy0DinSumMyQYrkFDHojhCqn2fjW pHfyVYb5LeyjlwYf8VHatN73UAm45j5iySbPeKXx0jFs3s3nDtRa5vY5O cKAaCDqdJykFx7LlSVO265MCdxkj1kViGE4zbnu0cK1t8HklcObsQ3ZIF 8=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAwD9gCxe/xbLJq1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBfYEYVSASKo0XiBIlky2ICwIHAQEBCQMBAS8BAYRAAoJGOBM?= =?us-ascii?q?CAw0BAQQBAQECAQUEbYVDhV4BAQEBAgF5BQsLBBQuVwYTgyYBglsgqiaCJ4V?= =?us-ascii?q?KhGMQgTiBU4h4gW2CAIE4DBSCHi4+iAuCLASNchmJKYhwjzSCQ4JMgRySTxu?= =?us-ascii?q?OcIwMpj+DLgIEBgUCFYFpIoFYMxoIGxVlAYJBPhIYDZQkbwEOjRFAAzCOKgE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.70,362,1574121600"; d="asc'?scan'208,217";a="22509684" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jan 2020 17:58:05 +0000 Received: from [10.61.171.81] ([10.61.171.81]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 00PHw4mK021104 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 25 Jan 2020 17:58:05 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2E0DD6A3-D239-4CDD-AA6B-D714DD4F25C5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Sat, 25 Jan 2020 18:58:04 +0100 In-Reply-To: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> Cc: Ted Hardie , Eric Rescorla , architecture-discuss@ietf.org, model-t@iab.org To: Christian Huitema References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.171.81, [10.61.171.81] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 17:58:11 -0000 --Apple-Mail=_2E0DD6A3-D239-4CDD-AA6B-D714DD4F25C5 Content-Type: multipart/alternative; boundary="Apple-Mail=_46788426-AAE0-4B30-8333-71B80983E56E" --Apple-Mail=_46788426-AAE0-4B30-8333-71B80983E56E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 25 Jan 2020, at 02:56, Christian Huitema = wrote: >=20 >=20 > Phrasing that as "don't trust the endpoints" is probably = inappropriate. >=20 Why? They are the source of just about all compromise attacks. > My personal worry is the cascading impact of end-point compromise. = Take the example of a large network. Large network means multiple = routers. If the multiple is high enough, we have strong risks that one = of those will be compromised at some point. If we merely "trust the = endpoints", then a single compromise of one of the endpoints means the = game is over. But it does not have to be so. In an ideal world, = implementations of the routing protocol should be able to detect = aberrant behavior and isolate the compromised node. In practice, that's = really hard. >=20 We sell product that does this today. But it is hard, which is why = people pay us. Of course, it gets harder with encryption, but we even = have product for that. I prefer the other approach: tell us what good = behavior looks like (manufacturer usage descriptions). > But there are still general principles like "least amount of = privilege" or "need to know basis" that could help. >=20 Indeed. > I would really like that protocol designers think about that too, = instead of merely asserting trust in the endpoints. >=20 How much is this the protocol and how much is the application? The = protocols most apps are using today are, ermmm, HTTP. Eliot --Apple-Mail=_46788426-AAE0-4B30-8333-71B80983E56E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

On 25 Jan 2020, at 02:56, Christian Huitema <huitema@huitema.net> wrote:


Phrasing that as "don't trust the endpoints" is probably inappropriate.


Why?  They are the source of just about all compromise attacks.

My personal worry is the cascading impact of end-point compromise. Take the example of a large network. Large network means multiple routers. If the multiple is high enough, we have strong risks that one of those will be compromised at some point. If we merely "trust the endpoints", then a single compromise of one of the endpoints means the game is over. But it does not have to be so. In an ideal world, implementations of the routing protocol should be able to detect aberrant behavior and isolate the compromised node. In practice, that's really hard.

We sell product that does this today.  But it is hard, which is why people pay us.  Of course, it gets harder with encryption, but we even have product for that.  I prefer the other approach: tell us what good behavior looks like (manufacturer usage descriptions).

But there are still general principles like "least amount of privilege" or "need to know basis" that could help.

Indeed.

I would really like that protocol designers think about that too, instead of merely asserting trust in the endpoints.


How much is this the protocol and how much is the application?  The protocols most apps are using today are, ermmm, HTTP.

Eliot
--Apple-Mail=_46788426-AAE0-4B30-8333-71B80983E56E-- --Apple-Mail=_2E0DD6A3-D239-4CDD-AA6B-D714DD4F25C5 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4sgawACgkQh7ZrRtnS ejPhhwf+ORR05p1brRtkXimar2aDLnR5BsZUpKU6ISnpcMNgw2SarsF2YlXPXqIa hBJ2iPczL5Xmo6bTxbAKjVhTWJyOjJvXRZAuvv6rzv5YG8SVCJQthk4rTy1mmhbi /x3GzpsqFzijfZMm9l/00t5leCHOO7jHiTWB4FwTZh9/B4DzeDnJloafiAqdaIpR IL7N38wwB63BsAmxYfNs31F1Zpg73EuF5KeQdh90CUfIGpn0nxaCBVwh78TOo0P/ mih0ONd1v/8UWne3gjxVUDYHVf8REuWuspMRlxML+kkoA5Lddc5lP3ZXZ/ZHyMbp pzliqFNz7RpzLJ1E5TyftcMFWXkcKw== =EjvB -----END PGP SIGNATURE----- --Apple-Mail=_2E0DD6A3-D239-4CDD-AA6B-D714DD4F25C5-- From nobody Sat Jan 25 23:37:22 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A75012008F for ; Sat, 25 Jan 2020 23:37:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 6iIncPReHjkg for ; Sat, 25 Jan 2020 23:37:18 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9BF12008D for ; Sat, 25 Jan 2020 23:37:18 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id y4so7317781ljj.9 for ; Sat, 25 Jan 2020 23:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nJ+2sH6Ku6+ZEBXMaY+ZBK+Rg8pgD0aCC6wgz27G68Y=; b=pLQcheJrxL0KKpTqZGvkhurXmEqUM0RsCe4AsoAmyNgJG/vydkCuztvuiRgG/6Hemt 600fKQs8IeggEQFU3loUw2dE3uZ1Sq9bJHrpiGiKsk7hueKfmxB39ZvsxObssxAjuxej lSjnKBs2C6eJUUbTdDnmdRchQQayadCHsD+STlhoUQ+3NP0Wh1W4vxn9QLzTXLEmIcLl m0EGe2cEOg7ZTq6lEDafqLtnvS3d8ryvYjUcDxB/ehv95ip2Zf22FePwe+KZ1M8c6J5h ohFebSx3Ah0FtHjaisn/iH0UNU/DkQYqWfGXsYwPvGmp0UoVhOwguMzkEXj8yo0POvYF UNsg== 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=nJ+2sH6Ku6+ZEBXMaY+ZBK+Rg8pgD0aCC6wgz27G68Y=; b=Zvw/qSUDWqi+2oQ92AxO7Kk5p4P06Jf4nEZpgnxu5J8A7So1o/Vx6MijyzuVAUI2vy G5vSiWts4MMVz0od/MvlYN6FP6foTIdN9AnHtT4NY7mcE5jfgiNy85dfUMtWi8DEG9WI PUAqebIVkajyxBcy11rRKyi6VjHivHZmqfjgkRFw9eoP8xOxFgt9sAHTOXKulbgnfoJJ P4soeiMQaNlm0Q5JsFcdiFT7fCooZANIslh9YQmkjLSW4S9WV/JZ2OC/5pGjY8NUiurx IFROVUdDfvMaL/vRgzfsXEKD8Co/sYKYTpZO6U1klwT5Fhkxhu29Vb893TjURlbH3FR4 N/sA== X-Gm-Message-State: APjAAAUA7FlQfNbq2GKEkWIaJGclIenSKQp1BrkFsaN5V97Xbok0NaZf EG02ex11C+Tp8Bt0+C1kVepGacrtsiJaScZSzEHtqw== X-Google-Smtp-Source: APXvYqwETYtdkryvbWSHtFG+kmJSqEe7bYcaLM89AzWDkIC7/YJiyMNrJ/Td+7qzEjJMP5lWogNXXP2s5NH5mm83uN4= X-Received: by 2002:a05:651c:448:: with SMTP id g8mr6949631ljg.35.1580024236474; Sat, 25 Jan 2020 23:37:16 -0800 (PST) MIME-Version: 1.0 References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> In-Reply-To: From: Eric Rescorla Date: Sat, 25 Jan 2020 23:36:39 -0800 Message-ID: To: Eliot Lear Cc: Christian Huitema , Ted Hardie , architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="0000000000005a13c0059d060f22" Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 07:37:20 -0000 --0000000000005a13c0059d060f22 Content-Type: text/plain; charset="UTF-8" It's probably useful to put the text in 3552 in context, which was primarily about designing COMSEC protocols. Our ability to build two party protocols which survive one of the parties being compromised is fairly limited. We *do* have some praxis for building N party protocols which gracefully degrade when some of the nodes are compromised (for instance consensus protocols). Of course, the exact properties of those protocols can be difficult to succinctly state. I'm not quite sure I understand what you mean when you say "They are the source of just about all compromise attacks." I'm not saying it's not true, but perhaps you could elaborate. -Ekr On Sat, Jan 25, 2020 at 9:58 AM Eliot Lear wrote: > > > On 25 Jan 2020, at 02:56, Christian Huitema wrote: > > > Phrasing that as "don't trust the endpoints" is probably inappropriate. > > > Why? They are the source of just about all compromise attacks. > > My personal worry is the cascading impact of end-point compromise. Take > the example of a large network. Large network means multiple routers. If > the multiple is high enough, we have strong risks that one of those will be > compromised at some point. If we merely "trust the endpoints", then a > single compromise of one of the endpoints means the game is over. But it > does not have to be so. In an ideal world, implementations of the routing > protocol should be able to detect aberrant behavior and isolate the > compromised node. In practice, that's really hard. > > We sell product that does this today. But it is hard, which is why people > pay us. Of course, it gets harder with encryption, but we even have > product for that. I prefer the other approach: tell us what good behavior > looks like (manufacturer usage descriptions). > > But there are still general principles like "least amount of privilege" or > "need to know basis" that could help. > > Indeed. > > I would really like that protocol designers think about that too, instead > of merely asserting trust in the endpoints. > > > How much is this the protocol and how much is the application? The > protocols most apps are using today are, ermmm, HTTP. > > Eliot > --0000000000005a13c0059d060f22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's probably useful to put the text in 3552 in c= ontext, which was primarily about designing COMSEC protocols. Our ability t= o build two party protocols which survive one of the parties being compromi= sed is fairly limited. We *do* have some praxis for building N party protoc= ols which gracefully degrade when some of the nodes are compromised (for in= stance consensus protocols). Of course, the exact properties of those proto= cols can be difficult to succinctly state.

I'm= not quite sure I understand what you mean when you say "They are the = source of just about all compromise attacks." I'm not saying it= 9;s not true, but perhaps you could elaborate.

-Ek= r


On Sat, Jan 25, 2020 at 9:58 AM Eliot Lear <lear@cisco.com> wrote:


On 25 Jan 2020, at 02:= 56, Christian Huitema <huitema@huitema.net> wrote:


Phrasing that as "don't trust the endpoints" is pr= obably inappropriate.


Why?=C2=A0 = They are the source of just about all compromise attacks.

My personal worry is the cascading impact = of end-point compromise. Take the example of a large network. Large network means multiple routers. If the multiple is high enough, we have strong risks that one of those will be compromised at some point. If we merely "trust the endpoints", then a single compromise of one of the endpoints means the game is over. But it does not have to be so. In an ideal world, implementations of the routing protocol should be able to detect aberrant behavior and isolate the compromised node. In practice, that's really hard.

We sell product that does this today.=C2=A0 = But it is hard, which is why people pay us.=C2=A0 Of course, it gets harder= with encryption, but we even have product for that.=C2=A0 I prefer the oth= er approach: tell us what good behavior looks like (manufacturer usage desc= riptions).

But there are still general principles like "least amount of privilege" or "need to know basis" that could help.

Indeed.
=

I would really like that protocol designers think about that too, instead of merely asserting trust in the endpoints.

=

How much is this the protocol and how much is the appli= cation?=C2=A0 The protocols most apps are using today are, ermmm, HTTP.

Eliot
--0000000000005a13c0059d060f22-- From nobody Sun Jan 26 01:44:13 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC73120026 for ; Sun, 26 Jan 2020 01:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.502 X-Spam-Level: X-Spam-Status: No, score=-12.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_SCAM=1.999, HTML_MESSAGE=0.001, 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 iC2DrbfWGaTm for ; Sun, 26 Jan 2020 01:44:09 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CD0120018 for ; Sun, 26 Jan 2020 01:44:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12445; q=dns/txt; s=iport; t=1580031848; x=1581241448; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=gVDMRgcq3YygyADpK+ahQPoSuY4H3p2qoJaxNk9vKHY=; b=MmBg+oKzSzmtVjQzKy/y/wVTnowhGNe57oLn+N+yRra1KyW4cU1qIjiZ ocbAFwVwpSQELkmazT6Rzq8ttIctNNktg0LTJex2w33d96F8ElkcuS2Gp jeuGY9lJcW6UzmjSd8RukCY65u4NV/+jY0PE3s1RWcUTDt2VmeyVYz11O g=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjAwAkXi1e/xbLJq1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuDFVQBIBIqhBSJA4g5gQGSLIgLAgcBAQEJAwEBJQoBAYRAAoJ?= =?us-ascii?q?GOBMCAw0BAQQBAQECAQUEbYULAQUBJQyFXgEBAQECASNWBQsLDgoqAgJXBhM?= =?us-ascii?q?UBYMNAYJbIA+pB3WBMoQ1AYEUhGgKBoE4gVOIeIFtggCBEScggU5JBy4+gmQ?= =?us-ascii?q?BAYE8gzcygiwEhWOIDwuJN4hwjzSCQ4JMgRyDWo51G4JIjCgni2WXRI57gy4?= =?us-ascii?q?CBAYFAhWBaSKBWDMaCBsVZQGCQRMrEhgNjA+DKIRBFxWDO4pSAkADMA2LaIJ?= =?us-ascii?q?DAQE?= X-IronPort-AV: E=Sophos;i="5.70,365,1574121600"; d="asc'?scan'208,217";a="22534129" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jan 2020 09:44:06 +0000 Received: from [10.61.171.81] ([10.61.171.81]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00Q9i5dI031990 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 26 Jan 2020 09:44:06 GMT From: Eliot Lear Message-Id: <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CD420CE8-71BB-456B-A0DC-7DED7143036E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Sun, 26 Jan 2020 10:44:05 +0100 In-Reply-To: Cc: architecture-discuss@ietf.org, model-t@iab.org To: Eric Rescorla References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.171.81, [10.61.171.81] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 09:44:11 -0000 --Apple-Mail=_CD420CE8-71BB-456B-A0DC-7DED7143036E Content-Type: multipart/alternative; boundary="Apple-Mail=_7350C2A6-1291-42F2-99E4-65F29C318364" --Apple-Mail=_7350C2A6-1291-42F2-99E4-65F29C318364 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, I apologize for the length of this missive. I=E2=80=99ve included = examples that are either from real life or plausible to the point of = inevitability. > On 26 Jan 2020, at 08:36, Eric Rescorla wrote: >=20 > It's probably useful to put the text in 3552 in context, which was = primarily about designing COMSEC protocols. Our ability to build two = party protocols which survive one of the parties being compromised is = fairly limited. Indeed. > We *do* have some praxis for building N party protocols which = gracefully degrade when some of the nodes are compromised (for instance = consensus protocols). Of course, the exact properties of those protocols = can be difficult to succinctly state. They are, and they are hard to build, and they have their own failure = modes.(*). But I really wasn=E2=80=99t going there, at least not = directly. Let=E2=80=99s look at three specific examples that I=E2=80=99ve= mentioned: 1. Train signaling system needs to be audited both live and = retrospectively in the case of accidents. This has to happen in such a = way that the auditor sees precisely what was sent by one endpoint and = received by the other. 2. The case of =E2=80=9Cparent doesn=E2=80=99t want Internet toy to = send video of child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s= an analog to the privacy analysis on Alexa[1] and the now infamous NEST = episode[2]). 3. CPAP machine or an AED/pace maker provide a control interface to the = doctor but the patient or his next of kin wants the data. Each example has a slightly different threat model, in addition to what = you stated in 3552. In the first case, we add mistakes on the part of = the operator (certainly the most common at this point**), and endpoint = compromises. In the second case, it is the manufacturer themselves that = is the threat, for failing to have disclosed what they are doing. The third case is more difficult. Let=E2=80=99s say a patient died. = Did the patient die (a) of natural causes, (b) due to a mistake made by = the patient or a care giver at home, (c) due to a mistake made by the = healthcare professional on the other end, or (d) due to an cyberattack? = It may be impossible for the next of kin to know if there is no network = audit capability. Yes, this is a messy case, which makes it a good one = to explore. The program can explore COMSEC, UX, and higher level issues as well, = like economics. That latter one is actually important because if in the = end the use cases above are going to get trumped by economics on the = part of manufacturers, what=E2=80=99s the point of specifying mechanism? = This also goes to another point about which the IAB has had concern: = concentration and control points. That can be explored as well here. = This does look to relax the assumption you laid down in 3552 about = endpoints, but I don=E2=80=99t think it dramatically changes things. Also, when you wrote 3552, there was really only the theoretical notion = of a cyberwar, ruling out attacks with infinite or near infinite = resources. That=E2=80=99s now an every day reality. In RFC 7958, we = sort of ruled them back in, but I think it=E2=80=99s worth exploring a = bit more what that means. A program for that is a very good idea. >=20 > I'm not quite sure I understand what you mean when you say "They are = the source of just about all compromise attacks." I'm not saying it's = not true, but perhaps you could elaborate. >=20 With apologies, I was shamelessly stating the obvious: the vast source = of bugs are on end devices, not because middle boxes are better designed = (some are, some aren=E2=80=99t), but because of sheer numbers. Well, if = endpoints are where the problems are, that=E2=80=99s where we need to = spend time as a community. Eliot (*) My favorite example of a consensus protocol that had =E2=80=9Cgood = intentions" was BSD timed. =E2=80=9CIt was a dark and stormy night=E2=80=9D= , when every participant had an unstable ticker in a different way, = leading to time storms. (**) For a very interesting read for anyone interested in IoT, I highly = recommend =E2=80=9CFamous British Railway Disasters, Ian Allan Pub, = 2000. https://www.amazon.com/British-Railway-Disasters/dp/0711024707 [1] Malkin, et. al., =E2=80=9CPrivacy Attitudes Toward Smark Speaker = Users=E2=80=9D, Proceedings of Privacy Enhancing Technologies, 2019. [2] = https://arstechnica.com/gadgets/2019/02/googles-nest-security-system-shipp= ed-with-a-secret-microphone/ --Apple-Mail=_7350C2A6-1291-42F2-99E4-65F29C318364 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

I apologize = for the length of this missive.  I=E2=80=99ve included examples = that are either from real life or plausible to the point of = inevitability.

On 26 Jan 2020, at 08:36, Eric Rescorla = <ekr@rtfm.com> = wrote:

It's probably = useful to put the text in 3552 in context, which was primarily about = designing COMSEC protocols. Our ability to build two party protocols = which survive one of the parties being compromised is fairly limited. =

Indeed.

We *do* have some praxis for building N party protocols which = gracefully degrade when some of the nodes are compromised (for instance = consensus protocols). Of course, the exact properties of those protocols = can be difficult to succinctly = state.

They are, = and they are hard to build, and they have their own failure modes.(*). = But I really wasn=E2=80=99t going there, at least not directly. =  Let=E2=80=99s look at three specific examples that I=E2=80=99ve = mentioned:

1.  Train signaling system = needs to be audited both live and retrospectively in the case of = accidents.  This has to happen in such a way that the auditor sees = precisely what was sent by one endpoint and received by the = other.

2.  The case of = =E2=80=9Cparent doesn=E2=80=99t want Internet toy to send video of = child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s an analog = to the privacy analysis on Alexa[1] and the now infamous NEST = episode[2]).

3. CPAP machine or an = AED/pace maker provide a control interface to the doctor but the patient = or his next of kin wants the data.

Each example has a slightly different threat = model, in addition to what you stated in 3552. In the first case, we add = mistakes on the part of the operator (certainly the most common at this = point**), and endpoint compromises.  In the second case, it is the = manufacturer themselves that is the threat, for failing to have = disclosed what they are doing.  

The third case is more difficult.  Let=E2=80=99= s say a patient died.  Did the patient die (a) of natural causes, = (b) due to a mistake made by the patient or a care giver at home, (c) = due to a mistake made by the healthcare professional on the other end, = or (d) due to an cyberattack?  It may be impossible for the next of = kin to know if there is no network audit capability.  Yes, this is = a messy case, which makes it a good one to explore.

The program can explore COMSEC, UX, and = higher level issues as well, like economics.  That latter one is = actually important because if in the end the use cases above are going = to get trumped by economics on the part of manufacturers, what=E2=80=99s = the point of specifying mechanism?   This also goes to another = point about which the IAB has had concern: concentration and control = points.  That can be explored as well here. This does look to relax = the assumption you laid down in 3552 about endpoints, but I don=E2=80=99t = think it dramatically changes things.

Also, when you wrote 3552, there was = really only the theoretical notion of a cyberwar, ruling out attacks = with infinite or near infinite resources.  That=E2=80=99s now an = every day reality.  In RFC 7958, we sort of ruled them back in, but = I think it=E2=80=99s worth exploring a bit more what that means.  A = program for that is a very good idea.


I'm not quite sure I understand what you mean when you say = "They are the source of just about all compromise attacks." I'm not = saying it's not true, but perhaps you could elaborate.


With apologies, I was shamelessly stating the obvious: = the vast source of bugs are on end devices, not because middle boxes are = better designed (some are, some aren=E2=80=99t), but because of sheer = numbers.  Well, if endpoints are where the problems are, that=E2=80=99= s where we need to spend time as a community.

Eliot

(*) My = favorite example of a consensus protocol that had =E2=80=9Cgood = intentions" was BSD timed.  =E2=80=9CIt was a dark and stormy = night=E2=80=9D, when every participant had an unstable ticker in a = different way, leading to time storms.
(**) For a very = interesting read for anyone interested in IoT, I highly recommend = =E2=80=9CFamous British Railway Disasters, Ian Allan Pub, 2000.  https://www.amazon.com/British-Railway-Disasters/dp/0711024707<= /a>
= --Apple-Mail=_7350C2A6-1291-42F2-99E4-65F29C318364-- --Apple-Mail=_CD420CE8-71BB-456B-A0DC-7DED7143036E 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4tX2UACgkQh7ZrRtnS ejNajwf+OrBXbEPRwiDg0fvCIUuZGcbDDYYn/r5GmioA3fwwssYj6qWKGdQEf2yh Z6Bi0Rs/P0VHdniintOkkPzeUHMrIdVvVzSYNFJZHeqjtUUkD0yuGHBzbCxZhuPJ tSaBGhZz3agoSzU6Q8LNiXtbBLqnAKqrVrqlHeKEGoR/1l/mYiO6RHX+bIXy/B9y 1EyhMYhuj8EaBdDGmm/FeelcukdCnym1AYr4dlf550DkURCFNND0hSFKbmvZ8nkC wmGYiNSZ5JY/84GOnh56exi24uSOXgWdMkzBGX/XQHz7DMRk6qBK+JKGfn6rejjA xzuqRi8SWSDjcLUnZtMM/8U/KpcqzA== =glaq -----END PGP SIGNATURE----- --Apple-Mail=_CD420CE8-71BB-456B-A0DC-7DED7143036E-- From nobody Sun Jan 26 05:06:01 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BBB12006D for ; Sun, 26 Jan 2020 05:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 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, HK_SCAM=1.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 E9g2wnqlrwAF for ; Sun, 26 Jan 2020 05:05:53 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 3D475120041 for ; Sun, 26 Jan 2020 05:05:53 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id i6so2048175otr.7 for ; Sun, 26 Jan 2020 05:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ss5xAP5CgqNU5svEZ4fcsdryAr555dl+LZvYEUVD5po=; b=nMAFiyUNizlyqKyE0fBUXsMhuGa2DYD63BCHrsC8hQcfiVWSqjsVLC47NybDbb6IGd YO/VXl/9grJoiMosMehqdSr/+0YSh08Hs5r6HX53BhjACoIq6RWh4j4y61nm8xT2YObK VonnB1Xy1qayYkI/fqyG/Voxc9Z/Z7Kk8tArlH20+0zg8SAEFcSmVV7RF8Tkrl3Mz/rE oCmCk2LpsWypd7UMF/Omc/yEwYnX1rLSb8p5VtIHsdC1wSUsOP3sCE916AdPOFY5g7KU 3vv77nFw7jytgQQTO5ktuq/uawYM6zInALZgeoQnyHeVmuKeJZUk1tt7yRCMES02bVZ9 Yd/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ss5xAP5CgqNU5svEZ4fcsdryAr555dl+LZvYEUVD5po=; b=KIXuPLYBQeJGKyTM9WZjub19/zC5vvdzD2TpgyIA7+EsLyUH0EUGX6lr+aWrDutox9 M15KWYIOCdOmSpD7byvrn06/WNtG5Ue01SBTiu9KGww+6U+Em2tnjWjwQ0rJrFyXAKJC DqPC51mkawZCcVWQrHkLcqdksKgyfN2vyMbCI8VWHboX8BlT/vcA2UFKVTMLIj+L+rOO 3uJhWfG6FI/7lsRC8FfWbpmt0gN7O7NnkKJHhArBLdF2I5+Yf1XnnjotU0dZMqRMaIu9 pqFheUgdspNj+TETU2BnmWYZuW4OYrlYCTGAMuHQv62f+/LuPRH2hVUgD/+hc1OASsiT 88LQ== X-Gm-Message-State: APjAAAW3WfQSezHKguFrT0CN6p+1wEEJukkcNt+ySqt7ckikxpmXjGP9 2StTR5KvcHlCbq5S4SJD7eEAjePabZNJod7l64o= X-Google-Smtp-Source: APXvYqz3Zvz2S8nAVmCqvS3PgZ1oMvIelImiHAbX2zJL0hBO13JObEGTIwihrq6IjPpei85ttJEg9YR7cAGSKTqoOdc= X-Received: by 2002:a9d:6c52:: with SMTP id g18mr9322339otq.356.1580043952555; Sun, 26 Jan 2020 05:05:52 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sun, 26 Jan 2020 05:05:51 -0800 (PST) In-Reply-To: <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> From: Guntur Wiseno Putra Date: Sun, 26 Jan 2020 20:05:51 +0700 Message-ID: To: Eliot Lear Cc: Eric Rescorla , "architecture-discuss@ietf.org" , "model-t@iab.org" Content-Type: multipart/alternative; boundary="000000000000858ada059d0aa6e7" Archived-At: Subject: Re: [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 13:05:55 -0000 --000000000000858ada059d0aa6e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss, Networks of Interests: Trusts and Distrusts...? In trying to follow the fluxes of the discussion, I begin with such basic understandings below: Networks of Interests: Trust and Distrust... - when the interests are understood by either/all parties involved there are (networks of) trusts. - when the interests are not understood/accepted by either/all parties involved there are (networks of) suspicions/threats/distrusts. For the Internet: As it is about networks of computers, of communications, so it is about identifying critical points of security: those threats and trusts --actual and potential (1) Two levels/layers to consider of analyzing the securities of the networks of communications: technical architecture --which is about design environment, (about "arstechnica"?)-- and the architecture's deployment environments... RFC 2316 and 3552 is considered as they are references of information and best current practice of the Internet engineering (2). The ITU of the UN report "Leveraging Tech..." and the Internet Society Report "Consolidation in the Internet Economy" as kinds of analytical tools to mapping a context (of problems, thus about real social conditions). (3) (1) The identifications depends on interpretations and evaluations (approaches and perspectives). (2) https://www.rfc-editor.org/info/rfc2316; https://www.rfc-editor.org/info/rfc3552 (3) The ITU of the UN report =E2=80=9CFast-forward Progress: Leveraging tec= h to achieve the global goals=E2=80=9D https://www.itu.int/en/sustainable-world/Documents/Fast-forward_progress_re= port_414709%20FINAL.pdf 2019 ISOC Global Internet Report "Consolidation in the Internet Economy" https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/= InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf Regard, Guntur Wiseno Putra Pada Minggu, 26 Januari 2020, Eliot Lear menulis: > Hi Eric, > > I apologize for the length of this missive. I=E2=80=99ve included exampl= es that > are either from real life or plausible to the point of inevitability. > > On 26 Jan 2020, at 08:36, Eric Rescorla wrote: > > It's probably useful to put the text in 3552 in context, which was > primarily about designing COMSEC protocols. Our ability to build two part= y > protocols which survive one of the parties being compromised is fairly > limited. > > > Indeed. > > We *do* have some praxis for building N party protocols which gracefully > degrade when some of the nodes are compromised (for instance consensus > protocols). Of course, the exact properties of those protocols can be > difficult to succinctly state. > > > They are, and they are hard to build, and they have their own failure > modes.(*). But I really wasn=E2=80=99t going there, at least not directly= . Let=E2=80=99s > look at three specific examples that I=E2=80=99ve mentioned: > > 1. Train signaling system needs to be audited both live and > retrospectively in the case of accidents. This has to happen in such a w= ay > that the auditor sees precisely what was sent by one endpoint and receive= d > by the other. > > 2. The case of =E2=80=9Cparent doesn=E2=80=99t want Internet toy to send= video of child=E2=80=9D, > when the camera is undisclosed (it=E2=80=99s an analog to the privacy ana= lysis on > Alexa[1] and the now infamous NEST episode[2]). > > 3. CPAP machine or an AED/pace maker provide a control interface to the > doctor but the patient or his next of kin wants the data. > > Each example has a slightly different threat model, in addition to what > you stated in 3552. In the first case, we add mistakes on the part of the > operator (certainly the most common at this point**), and endpoint > compromises. In the second case, it is the manufacturer themselves that = is > the threat, for failing to have disclosed what they are doing. > > The third case is more difficult. Let=E2=80=99s say a patient died. Did= the > patient die (a) of natural causes, (b) due to a mistake made by the patie= nt > or a care giver at home, (c) due to a mistake made by the healthcare > professional on the other end, or (d) due to an cyberattack? It may be > impossible for the next of kin to know if there is no network audit > capability. Yes, this is a messy case, which makes it a good one to > explore. > > The program can explore COMSEC, UX, and higher level issues as well, like > economics. That latter one is actually important because if in the end t= he > use cases above are going to get trumped by economics on the part of > manufacturers, what=E2=80=99s the point of specifying mechanism? This a= lso goes > to another point about which the IAB has had concern: concentration and > control points. That can be explored as well here. This does look to rel= ax > the assumption you laid down in 3552 about endpoints, but I don=E2=80=99t= think it > dramatically changes things. > > Also, when you wrote 3552, there was really only the theoretical notion o= f > a cyberwar, ruling out attacks with infinite or near infinite resources. > That=E2=80=99s now an every day reality. In RFC 7958, we sort of ruled t= hem back > in, but I think it=E2=80=99s worth exploring a bit more what that means. = A program > for that is a *very* good idea. > > > I'm not quite sure I understand what you mean when you say "They are the > source of just about all compromise attacks." I'm not saying it's not tru= e, > but perhaps you could elaborate. > > > With apologies, I was shamelessly stating the obvious: the vast source of > bugs are on end devices, not because middle boxes are better designed (so= me > are, some aren=E2=80=99t), but because of sheer numbers. Well, if endpoi= nts are > where the problems are, that=E2=80=99s where we need to spend time as a c= ommunity. > > Eliot > > (*) My favorite example of a consensus protocol that had =E2=80=9Cgood in= tentions" > was BSD timed. =E2=80=9CIt was a dark and stormy night=E2=80=9D, when ev= ery participant > had an unstable ticker in a different way, leading to time storms. > (**) For a very interesting read for anyone interested in IoT, I highly > recommend =E2=80=9CFamous British Railway Disasters, Ian Allan Pub, 2000. > https://www.amazon.com/British-Railway-Disasters/dp/0711024707 > [1] Malkin, et. al., =E2=80=9CPrivacy Attitudes Toward Smark Speaker User= s=E2=80=9D, > Proceedings of Privacy Enhancing Technologies, 2019. > [2] https://arstechnica.com/gadgets/2019/02/googles-nest- > security-system-shipped-with-a-secret-microphone/ > --000000000000858ada059d0aa6e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

Networks of Interests: Trusts= and Distrusts...?


In trying to fol= low the fluxes of the discussion, I begin with such basic understandings be= low:

Networks of Interests: Trust and Distrust...

- when the interests are understood by either/all parties involved there ar= e (networks of) trusts.

- when the interests are not understood/accepted by either/all parties invo= lved there are (networks of) suspicions/threats/distrusts.

For the Internet:

As it is about networks of computers, of communications, so it is about ide= ntifying=C2=A0 critical points of security: those threats and trusts --actu= al and potential (1)

Two levels/layers to consider of analyzing the securities of the networks o= f communications: technical architecture --which is about design environmen= t, (about "arstechnica"?)-- and the architecture's deployment= environments...

RFC 2316 and 3552 is considered as they are references of information and b= est current practice of the Internet engineering (2).

The ITU of the UN report "Leveraging Tech..." and the Internet So= ciety Report "Consolidation in the Internet Economy" as kinds of = analytical tools to mapping a context (of problems, thus about real social = conditions). (3)

(1) The identifications depends on interpretations and evaluations (approac= hes and perspectives).

(2) https://www.rfc-edi= tor.org/info/rfc2316; https://www.rfc-editor.org/info/rfc3552


(3) The ITU of the UN report =E2=80=9CFast-forward Progress: Leveraging tec= h to achieve the global goals=E2=80=9D
https://www.itu.int/en/sustainable-worl= d/Documents/Fast-forward_progress_report_414709%20FINAL.pdf

2019 ISOC Global Internet Report "Consolidation in the Internet Econom= y"
https://future.internetsociety.org/2019/wp-content/uploads/site= s/2/2019/04/InternetSociety-GlobalInternetReport-ConsolidationintheInternet= Economy.pdf



= Regard,
Guntur Wiseno Putra


Pada Minggu, 26= Januari 2020, Eliot Lear <lear@cisco.= com> menulis:
Hi Eric,

I = apologize for the length of this missive.=C2=A0 I=E2=80=99ve included examp= les that are either from real life or plausible to the point of inevitabili= ty.

On 26 Jan 2020, at 08:36, Er= ic Rescorla <ekr@rtfm.= com> wrote:

It's probably us= eful to put the text in 3552 in context, which was primarily about designin= g COMSEC protocols. Our ability to build two party protocols which survive = one of the parties being compromised is fairly limited.
<= /blockquote>

Indeed.

=
We *do* have some praxis for building N party pr= otocols which gracefully degrade when some of the nodes are compromised (fo= r instance consensus protocols). Of course, the exact properties of those p= rotocols can be difficult to succinctly state.

They are, and they are hard to build, and they have their = own failure modes.(*). But I really wasn=E2=80=99t going there, at least no= t directly.=C2=A0 Let=E2=80=99s look at three specific examples that I=E2= =80=99ve mentioned:

1.=C2=A0 Train signaling system need= s to be audited both live and retrospectively in the case of accidents.=C2= =A0 This has to happen in such a way that the auditor sees precisely what w= as sent by one endpoint and received by the other.

2.=C2=A0 The case of =E2=80=9Cparent doesn=E2=80=99t want Internet toy to = send video of child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s = an analog to the privacy analysis on Alexa[1] and the now infamous NEST epi= sode[2]).

3. CPAP machine or an AED/pace maker pro= vide a control interface to the doctor but the patient or his next of kin w= ants the data.

Each example has a slightly differe= nt threat model, in addition to what you stated in 3552. In the first case,= we add mistakes on the part of the operator (certainly the most common at = this point**), and endpoint compromises.=C2=A0 In the second case, it is th= e manufacturer themselves that is the threat, for failing to have disclosed= what they are doing. =C2=A0

The third case is mor= e difficult.=C2=A0 Let=E2=80=99s say a patient died.=C2=A0 Did the patient = die (a) of natural causes, (b) due to a mistake made by the patient or a ca= re giver at home, (c) due to a mistake made by the healthcare professional = on the other end, or (d) due to an cyberattack?=C2=A0 It may be impossible = for the next of kin to know if there is no network audit capability.=C2=A0 = Yes, this is a messy case, which makes it a good one to explore.
=
The program can explore COMSEC, UX, and higher level is= sues as well, like economics.=C2=A0 That latter one is actually important b= ecause if in the end the use cases above are going to get trumped by econom= ics on the part of manufacturers, what=E2=80=99s the point of specifying me= chanism? =C2=A0 This also goes to another point about which the IAB has had= concern: concentration and control points.=C2=A0 That can be explored as w= ell here. This does look to relax the assumption you laid down in 3552 abou= t endpoints, but I don=E2=80=99t think it dramatically changes things.

Also, when you wrote 3552, there was really only the t= heoretical notion of a cyberwar, ruling out attacks with infinite or near i= nfinite resources.=C2=A0 That=E2=80=99s now an every day reality.=C2=A0 In = RFC 7958, we sort of ruled them back in, but I think it=E2=80=99s worth exp= loring a bit more what that means.=C2=A0 A program for that is a very good idea.


I'm not quite sure I understand what you mean when= you say "They are the source of just about all compromise attacks.&qu= ot; I'm not saying it's not true, but perhaps you could elaborate.<= /div>


With apologies,= I was shamelessly stating the obvious: the vast source of bugs are on end = devices, not because middle boxes are better designed (some are, some aren= =E2=80=99t), but because of sheer numbers.=C2=A0 Well, if endpoints are whe= re the problems are, that=E2=80=99s where we need to spend time as a commun= ity.

Eliot

(*) My favorit= e example of a consensus protocol that had =E2=80=9Cgood intentions" w= as BSD timed. =C2=A0=E2=80=9CIt was a dark and stormy night=E2=80=9D, when = every participant had an unstable ticker in a different way, leading to tim= e storms.
(**) For a very interesting read for anyone interested = in IoT, I highly recommend =E2=80=9CFamous British Railway Disasters, Ian A= llan Pub, 2000. =C2=A0https://www.amazon.com/British= -Railway-Disasters/dp/0711024707
[1] Malkin, et. al., = =E2=80=9CPrivacy Attitudes Toward Smark Speaker Users=E2=80=9D, Proceedings= of Privacy Enhancing Technologies, =C2=A02019.
--000000000000858ada059d0aa6e7-- From nobody Mon Jan 27 01:54:38 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C6C12001B for ; Mon, 27 Jan 2020 01:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_SCAM=1.999, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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=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 tmzkLd2FSui8 for ; Mon, 27 Jan 2020 01:54:30 -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 1454A12012E for ; Mon, 27 Jan 2020 01:54:30 -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 39E4A6A272; Mon, 27 Jan 2020 10:54:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1580118868; bh=dbjMyVBx2W0rKbGVZy2bqeKa19hGd/Ge4qqn/cMgMhg=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=9ytS+fjNCyiY+XO4HXqIub60BZaz8lsxFCMnXgFdoGZOZSS0T/mH8KRiKWX/jviMo WJnXQ8h6JMptiHkiFx3uJqA0bkO5bcrqZW+GYZKKoU06vw8QvuxfGOM331UWSwujGh Jk5ak5kmD9+aT6L/XH8nnPnerZcfuQkRxfDjDv+coCFt1ZUKqyjJ5iKIkjvWY+MwkM dN1czgfqG3axalrPzflcJ3fQVIGkTF5FoHjGfgI5k226gnSLCiNsntwUBcYVQR26Ly gtRm/YAwMfNbaeqUSmZLWudJ3Egr1rQrIXiT3uNjSXrEzYLZbZPfehKtfoZTBqZ9fq qfh6h9ZL/AZgw== 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 22B8B3C0424; Mon, 27 Jan 2020 10:54:28 +0100 (CET) Date: Mon, 27 Jan 2020 10:54:27 +0100 (CET) From: Vittorio Bertola To: Eliot Lear Cc: architecture-discuss@ietf.org, model-t@iab.org Message-ID: <509170201.60518.1580118868021@appsuite-gw1.open-xchange.com> In-Reply-To: <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev3 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 09:54:34 -0000 =20 =20

Il 26/01/2020 10:44 Eliot Lear <lear@cisco.com> ha scritto:

They are, and they are hard to build, and they have their own failure = modes.(*). But I really wasn=E2=80=99t going there, at least not directly. =  Let=E2=80=99s look at three specific examples that I=E2=80=99ve menti= oned:

1.  Train signaling system needs to be audited both live and ret= rospectively in the case of accidents.  This has to happen in such a w= ay that the auditor sees precisely what was sent by one endpoint and receiv= ed by the other.

2.  The case of =E2=80=9Cparent doesn=E2=80=99t want Internet to= y to send video of child=E2=80=9D, when the camera is undisclosed (it=E2=80= =99s an analog to the privacy analysis on Alexa[1] and the now infamous NES= T episode[2]).

3. CPAP machine or an AED/pace maker provide a control interface to t= he doctor but the patient or his next of kin wants the data.

Each example has a slightly different threat model, in addition to wh= at you stated in 3552. In the first case, we add mistakes on the part of th= e operator (certainly the most common at this point**), and endpoint compro= mises.  In the second case, it is the manufacturer themselves that is = the threat, for failing to have disclosed what they are doing.  

The third case is more difficult.  Let=E2=80=99s say a patient d= ied.  Did the patient die (a) of natural causes, (b) due to a mistake = made by the patient or a care giver at home, (c) due to a mistake made by t= he healthcare professional on the other end, or (d) due to an cyberattack? =  It may be impossible for the next of kin to know if there is no netwo= rk audit capability.  Yes, this is a messy case, which makes it a good= one to explore.

The program can explore COMSEC, UX, and higher level issues as well,= like economics.  That latter one is actually important because if in = the end the use cases above are going to get trumped by economics on the pa= rt of manufacturers, what=E2=80=99s the point of specifying mechanism? &nbs= p; This also goes to another point about which the IAB has had concern: con= centration and control points.  That can be explored as well here. Thi= s does look to relax the assumption you laid down in 3552 about endpoints, = but I don=E2=80=99t think it dramatically changes things.
Part of the issue is, when you have to write "security considerations", = what do you mean by "security". If that means "security of the protocol", I= can see why you end up with a theoretical approach that defines the securi= ty of the endpoints as out of scope. However, if that means "security of th= e applications that will be built over the protocol", or "security of the u= sers of the protocol", and if security includes privacy and data protection= (or even human rights, as the people in HRPC would argue), then the scope = becomes much broader. Given the desired focus on prioritizing end-user need= s, the meaning should be the latter.

In that case, in the almost 20 years that have passed since RFC 3552, th= e scenario has changed significantly. For example, 20 years ago end-users w= ere, at least in theory, fully in control of what ran on their endpoints, w= hich basically consisted of personal computers; nowadays, most end-users ac= cess the Internet via smartphones, where their control is much more limited= - and let alone IoT devices; both smartphones and IoT devices are categori= es of endpoints that did not exist at the time. 20 years ago there was no "= cloud" or "edge computing", and even if the cloud is just someone else's co= mputer, still the location of personal information over the network has sig= nificantly changed. 20 years ago the Internet was the Internet, i.e. a perm= issionless innovation network of networks where lots of people produced con= tent and services even on a very small scale; nowadays, apart from email an= d the web, many of the most popular services consist of walled gardens, and= even network infrastructure is remarkably centralised, not in topological = terms but in terms of ownership and control.

I think that it would be good to discuss how these things impact the sec= urity of the user, and how they should be considered when writing new proto= cols. Perhaps, after the discussion, we could conclude that they do not aff= ect protocol design. But I think that in some cases they could, and so the = discussion would be useful.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open=
-Xchange
vittorio.b=
ertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Ital=
y
=20 From nobody Tue Jan 28 03:33:55 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9BF120013 for ; Tue, 28 Jan 2020 03:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 Y_H6RYOa__ok for ; Tue, 28 Jan 2020 03:33:46 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94E5120018 for ; Tue, 28 Jan 2020 03:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9936; q=dns/txt; s=iport; t=1580211226; x=1581420826; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=g2IFCPFvMfy6H/Xk+gZlDj9RF4gQu3lnR3qCqEwddjk=; b=aXnTh6yiGgqFRc5Ty2aBEZAJku65PKaUGB0xKlxgrONJMkQp24EyWu7l FvkO9oqDrFi/K7jjO4296wwBw61vZDhDWmOWTPE50W5TpPo2Y0qFm5j/r 2bIoDvcBVGZg1pz1Y/RhnsQlCyUn7v+BarVbHRV9QTR6kfZuakH+a9t8D o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAwC5GzBe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuEChIqhBSJA4gVJZMtiAsCBwEBAQkDAQEvAQGEQAKCSjgTAgM?= =?us-ascii?q?NAQEEAQEBAgEFBG2FQ4VeAQECAgEjVgULIyMHAgJXBhODJgGCWyCrYHWBMoV?= =?us-ascii?q?KhGkQgTiBU4plggCBEScMFIFOUGyHWTKCLASXNJgkgkOCTIEckk8bljeERaY?= =?us-ascii?q?/gy4CBAYFAhWBaSKBWDMaCBsVZQGCQT4SGA2OKRcVjg9AAzCLay2CFAEB?= X-IronPort-AV: E=Sophos;i="5.70,373,1574121600"; d="asc'?scan'208,217";a="22687500" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jan 2020 11:33:43 +0000 Received: from ams3-vpn-dhcp4134.cisco.com (ams3-vpn-dhcp4134.cisco.com [10.61.80.37]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00SBXhf0001230 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jan 2020 11:33:43 GMT From: Eliot Lear Message-Id: <2B1BEC89-D6DF-4E7A-9171-63257BDCFFA6@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_27B9B0D0-26F5-4F1A-9EBB-93BBB904C3AE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 28 Jan 2020 12:33:42 +0100 In-Reply-To: <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> Cc: "architecture-discuss@ietf.org" , model-t@iab.org To: Stephen Farrell References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.80.37, ams3-vpn-dhcp4134.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [arch-d] Yes, building blocks ; -) Re: not building blocks (was: Re: [Model-t] Possible new IAB program on Internet trust model evolution) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 11:33:50 -0000 --Apple-Mail=_27B9B0D0-26F5-4F1A-9EBB-93BBB904C3AE Content-Type: multipart/alternative; boundary="Apple-Mail=_62297430-9B3C-4C58-8CCD-8CA14841E0FF" --Apple-Mail=_62297430-9B3C-4C58-8CCD-8CA14841E0FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Last message of the day for me, promise. Thanks for your patience.] Hi Stephen, I know I=E2=80=99ve said this in the past, but I hope we=E2=80=99re = actually agreeing more than disagreeing here. See below. > On 28 Jan 2020, at 11:02, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 28/01/2020 06:44, Eliot Lear wrote: >> =46rom an IAB program standpoint, the real question here is this: = what >> are the architectural building blocks that are required? > I'm not sure I agree. ISTM you envisage a programme that > tries to establish that existing IETF consensus as to the > use of e2e encryption needs to be changed, which I don't > think is a goal here. Personally, I think of this as a > place to work on whether or not it's possible to extend > (not replace) the 3552 threat model to cater for changes > since 3552 was written. (I do think that's an interesting > question and it's unclear to me if the answer is "yes" or > "would like to, but it's not usefully feasible.") 3552 a great document! It provides great guidance for a very common = usage pattern. As such, we should tread very carefully, but tread we = must, no? I do not suggest we replace it, but rather examine = assumptions and its applicability. Christian=E2=80=99s comment is apt: = do we assume that devices are safe because they are disconnected? >=20 > Now, it's of course valid to point out that comsec (as > ekr may put it) if applied e2e doesn't by itself meet > all requirements stated in your examples, to which I'd > maybe argue to extend the Internet threat model with > some statement along the lines of: "if an endpoint > does need to see traffic content or significant meta- > data, then you need to design your protocol so that that > endpoint is an endpoint at which relevant cryptographic > mechanisms are validly terminated, according to the > expectations of the cryptographic protocol(s) in use (e.g. > TLS, IPsec). I really don=E2=80=99t know what expectations a protocol has, but if = part of an existing code base / specification can reasonably satisfy = clear and well justified requirements, I would rather beg, borrow, and = steal than rewrite, so as to capitalize on past experience. That=E2=80=99= s not to say we should change any existing protocol, but rather depend = on the parts we can leverage. > So I don't think, for the purposes of this exercise, > we're considering existing widely deployed protocols as > malleable building blocks, whether that protocol is > TLS or some (deployed) train signalling system. Building blocks must be stable and not malleable so that others can = depend on their behavior. I hope we don=E2=80=99t look at any single = example to design those blocks, which is why I raised several; I hope = others would raise others, as Watson did; and I would suggest that this = program take a walk before run approach. In summary (otherwise known as burying the lede), my suggestion is to = test / validate these sorts of examples, maybe decompose as required a = bit of what we have =E2=80=9Con the truck=E2=80=9D into various = components that could prove useful, pick from the best, create the rest, = and then demonstrate value.(*) Eliot (*) There is probably a separate more general question hiding here as to = how we build protocols, and what is the right granularity for their = constituent parts. --Apple-Mail=_62297430-9B3C-4C58-8CCD-8CA14841E0FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[Last message of the day for me, promise.  Thanks for = your patience.]

Hi = Stephen,

I know = I=E2=80=99ve said this in the past, but I hope we=E2=80=99re actually = agreeing more than disagreeing here.  See below.

On 28 Jan 2020, at 11:02, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 28/01/2020 06:44, Eliot = Lear wrote:
=46rom an = IAB program standpoint, the real question here is this: what
are the architectural building blocks that are required?
I'm not sure I agree. ISTM you envisage a = programme that
tries to establish that existing IETF = consensus as to the
use of e2e encryption needs to be = changed, which I don't
think is a goal here. Personally, I = think of this as a
place to work on whether or not it's = possible to extend
(not replace) the 3552 threat model to = cater for changes
since 3552 was written. (I do think = that's an interesting
question and it's unclear to me if = the answer is "yes" or
"would like to, but it's not = usefully feasible.")

3552 a great document! It provides great guidance for a = very common usage pattern. As such, we should tread very carefully, but = tread we must, no?  I do not suggest we replace it, but rather = examine assumptions and its applicability.  Christian=E2=80=99s = comment is apt: do we assume that devices are safe because they are = disconnected?


Now, it's of course valid to point out that comsec (as
ekr may put it) if applied e2e doesn't by itself meet
all requirements stated in your examples, to which I'd
maybe argue to extend the Internet threat model with
some statement along the lines of: "if an endpoint
does need to see traffic content or significant meta-
data, then you need to design your protocol so that that
endpoint is an endpoint at which relevant cryptographic
mechanisms are validly terminated, according to the
expectations of the cryptographic protocol(s) in use (e.g.
TLS, IPsec).

I really don=E2=80=99t know what expectations a = protocol has, but if part of an existing code base / specification can = reasonably satisfy clear and well justified requirements, I would rather = beg, borrow, and steal than rewrite, so as to capitalize on past = experience.  That=E2=80=99s not to say we should change any existing protocol, but rather depend on the parts we = can leverage.

So I don't think, for the = purposes of this exercise,
we're considering existing = widely deployed protocols as
malleable building blocks, = whether that protocol is
TLS or some (deployed) train = signalling system.

Building = blocks must be stable and not malleable so that others can depend on their = behavior.  I hope we don=E2=80=99t look at any single example to = design those blocks, which is why I raised several; I hope others would = raise others, as Watson did; and I would suggest that this program take = a walk before run approach.

In summary (otherwise known as burying the lede), my = suggestion is to test / validate these sorts of examples, maybe = decompose as required a bit of what we have =E2=80=9Con the truck=E2=80=9D= into various components that could prove useful, pick from the best, = create the rest, and then demonstrate value.(*)

Eliot

(*) There is probably a separate more = general question hiding here as to how we build protocols, and what is = the right granularity for their constituent parts.
= --Apple-Mail=_62297430-9B3C-4C58-8CCD-8CA14841E0FF-- --Apple-Mail=_27B9B0D0-26F5-4F1A-9EBB-93BBB904C3AE 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4wHBYACgkQh7ZrRtnS ejMuyQf9EgBdP6un6pm/icAMIzoi7OiRTDDJPHlTjY2oyw6OCmdXddtXWlHxUHKC 7HyVyGjxp/D2cgvz+wAznrCOj+LO6YMwXDOHi3Gfj45axu57a0cGODiyIdmAeX6i VRoCvJYTuI5tbPS2FRq5gdTs3Oxch4mkMhRg8lVhIHIX63Hw3JqJ4RNrXSXMB9fn IKGuswAYihmDKgXhjQc1squiKOuyaLJZTjxP6VdFFmTpn2XYNvVUTyDYqfHLNRFa f/GMd73M0DGViA0u/Iki7fxRGeqMW5kCSEdYssZ+9VbaT/P05i+ak6lvxEUOleic KMrmzVUL/O/is86UbTiwObuJJaI0DA== =0POA -----END PGP SIGNATURE----- --Apple-Mail=_27B9B0D0-26F5-4F1A-9EBB-93BBB904C3AE-- From nobody Tue Jan 28 06:36:28 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A6D1208F9 for ; Tue, 28 Jan 2020 06:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 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, HK_SCAM=1.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 ARjtwpUCpiah for ; Tue, 28 Jan 2020 06:36:22 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 7C7301208B2 for ; Tue, 28 Jan 2020 06:36:21 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id 66so12157625otd.9 for ; Tue, 28 Jan 2020 06:36:21 -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=QcEIZrHARenQsSkTQtm8ihAzX67XWsrmL73q1ifHG9Y=; b=nyyKYaTfRQ+GWUdb5pi++gFcoCn/imujy1j26YTr0GUf0sbQmA1MAD0Cu0YlTFm9jQ yUiWbEQA57bybjFX6iuAM6f0Gxto8bCud/JnYDbNP4ZTsHO1wBXOBzkEAhQaLgdb/Gmp jvXuktQbDwu40HznstWdU+3iW2EAWO1cP25Z6MIC2VbWr4FaVrvIAAysTUiLfUcMANeX FOKtftm2CuKt8wPBsHDPshEbnyj0sMvn2I5FVdulZODkitTwgUPC1jBLUTAbTom/AnVU GrDTMqas0NDAV28DFE2mD5KihxMEFRChbePhIewS4vcfhr8LA7vv69rf5gi2AqzTNk4w ODtQ== 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=QcEIZrHARenQsSkTQtm8ihAzX67XWsrmL73q1ifHG9Y=; b=GMnIFRGe8Vfu20GV7aNu4C6u4pxfhed84WQ67Nk2tSrfUWvmBTbnEvIw3n3KmQG8C1 aIhck+BDeiKFiMK+xPK0agoeALtkKi4wOyVXnZn2RVfBAbbhHDN3sNANuows+AteFi+C F8yrm0a+LVERK+JNQG9xsinZ/bio5juUOnc4czlWXjA7/lIm9FDAfgFSwaQ5FlAC6O/Z uwIbXDGzvKwYNTrqXNMk0b8ELR2mv3PCHtQoBETu+Q3E8aFSBePUspL3NLK6hh5s/6hJ 63jWhYlsy2fRL8lwZTChoBfnMJ5pROeBqJ5EQbSHQ4RDwCaZnS2AGXSWqMjoZK8d492r o6TQ== X-Gm-Message-State: APjAAAWKrNK01kEUN42ohflCjnZmDmsAJzWsF9bFwKJKlHoKWDDHFhSp TCuCJ0LqBRcjqidv4nWM6SBnWDjps89UuvjF/GU= X-Google-Smtp-Source: APXvYqwQ9u5GsnJpGZ2q7/Ad8NLtP2Xb8xSrcwqFjBGXINSccZ58Qg10RvIMqu/W+juimB7CEVEQVTNDpUaAY4dtOFs= X-Received: by 2002:a9d:dc1:: with SMTP id 59mr16928287ots.250.1580222180791; Tue, 28 Jan 2020 06:36:20 -0800 (PST) MIME-Version: 1.0 References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> In-Reply-To: From: Kathleen Moriarty Date: Tue, 28 Jan 2020 09:35:44 -0500 Message-ID: To: Eliot Lear Cc: Watson Ladd , architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="000000000000c09d75059d3425af" Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 14:36:26 -0000 --000000000000c09d75059d3425af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 28, 2020 at 1:44 AM Eliot Lear wrote: > Hi Watson, > > On 28 Jan 2020, at 02:35, Watson Ladd wrote: > > > > On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear wrote: > >> Let=E2=80=99s look at three specific examples that I=E2=80=99ve mentio= ned: >> >> 1. Train signaling system needs to be audited both live and >> retrospectively in the case of accidents. This has to happen in such a = way >> that the auditor sees precisely what was sent by one endpoint and receiv= ed >> by the other. >> >> 2. The case of =E2=80=9Cparent doesn=E2=80=99t want Internet toy to sen= d video of >> child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s an analog t= o the privacy >> analysis on Alexa[1] and the now infamous NEST episode[2]). >> >> 3. CPAP machine or an AED/pace maker provide a control interface to the >> doctor but the patient or his next of kin wants the data. >> > > I've got a few more examples from real life: > > 4: We need to see who is sending pictures of Winnie the Pooh. > > 5: We don't want pictures of the inside of our detention centers to appea= r > online. > > 6: I want to see everyone's credit card number at the coffee shop I run. > > Any discussion of tapping network communications because endpoints can't > be trusted needs to take these cases seriously. > > > > Absolutely. What I am suggesting is a relatively new twist on an old > problem(*). It=E2=80=99s important to understand the economic and policy= aspects > of how/whether to avoid [4] and [5], how to avoid [6] while at the same > time addressing use cases I mentioned. > > So=E2=80=A6 today=E2=80=99s new information comes courtesy of the EFF. > > > https://www.eff.org/deeplinks/2020/01/ring-doorbell-app-packed-third-part= y-trackers > > Here we have yet another IoT device that, from at least one person=E2=80= =99s > perspective is invading home privacy. And again, it is the device itself > that is the threat. In this case, it=E2=80=99s probably a more manageabl= e threat, > because one can simply not get a NEST. Try not getting a CPAP machine. > > And this brings us around to what layer to solve the problem at. Some of > this may need to be dealt with at layer 9 rather than at lower layers. W= e > should have that discussion too. > > > > Increasingly corporate networks are moving away from network layer access > controls and using user authentication over TLS, so-called BeyondCorp > model, including checking endpoint posture through management. > > > The endpoint being the focus for attacks is very important. As we shore the endpoint up further, attacks may reduce in number, but will likely increase in severity due to state sponsored actors. Work in RATS, TEEP, SUIT, and MUD should be considered in terms of how assurance of systems is provided and also looking at the use cases to ensure there are sometimes when you don't want that level of attestation. User ownership of data is another area. These build on zero-trust/BeyondCorp/data-centric models and are examples of active work in the IETF on the end point. They also have the potential to shift management and architectural models within the enterprise. Best regards, Kathleen > I don=E2=80=99t think this solves the railroad case. Do you? Just to cl= arify the > example: > > According to their logs, two separate signals received =E2=80=9Cset your= lights > to green=E2=80=9D at the same time, causing two trains to crash into each= other. > According to the signal controller=E2=80=99s logs, it sent =E2=80=9Cset y= our lights to > green=E2=80=9D to only one signal. What happened? > > All of the cases we are discussing have slightly different flavors of > threats. From an IAB program standpoint, the real question here is this: > what are the architectural building blocks that are required? Keep in > mind, some of those blocks could be code and some could be policy. > > One goal should be code reuse. It is probably best that the people > building the train signal *not* reinvent everything, but rather benefit > as much as they can from the experience and results that you, EKR, and a > great many other people have brought to society. > > Eliot > > (*) It=E2=80=99s also important to not fall into old tribal communication > patterns, while recognizing the realities of the concerns raised by you, > Watson, and me. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --=20 Best regards, Kathleen --000000000000c09d75059d3425af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 28, 2020 at 1:44 AM Eliot= Lear <lear=3D40cisco.com@= dmarc.ietf.org> wrote:
Hi Watson,
=
On 28 Jan 2020, at 02:35, Watson Ladd &l= t;watsonbladd@gm= ail.com> wrote:



On Sun, = Jan 26, 2020 at 1:44 AM Eliot Lear <lear@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0 Let= =E2=80=99s look at three specific examples that I=E2=80=99ve mentioned:
=

1.=C2=A0 Train signaling system needs to be audited bot= h live and retrospectively in the case of accidents.=C2=A0 This has to happ= en in such a way that the auditor sees precisely what was sent by one endpo= int and received by the other.

2.=C2=A0 The case o= f =E2=80=9Cparent doesn=E2=80=99t want Internet toy to send video of child= =E2=80=9D, when the camera is undisclosed (it=E2=80=99s an analog to the pr= ivacy analysis on Alexa[1] and the now infamous NEST episode[2]).

3. CPAP machine or an AED/pace maker provide a control inte= rface to the doctor but the patient or his next of kin wants the data.

I've got a few more= examples from real life:

4: We need to see who is= sending pictures of Winnie the Pooh.

5: We don= 9;t want pictures of the inside of our detention centers to appear online.<= /div>

6: I want to see everyon= e's credit card number at the coffee shop I run.

Any discussion of tapping network communicatio= ns because endpoints can't be trusted needs to take these cases serious= ly.=C2=A0


Absol= utely.=C2=A0 What I am suggesting is a relatively new twist on an old probl= em(*).=C2=A0 It=E2=80=99s important to understand the economic and policy a= spects of how/whether to avoid [4] and [5], how to avoid [6] while at the s= ame time addressing use cases I mentioned.

So=E2= =80=A6 today=E2=80=99s new information comes courtesy of the EFF.


Here we have yet another IoT device that, from at least o= ne person=E2=80=99s perspective is invading home privacy.=C2=A0 And again, = it is the device itself that is the threat.=C2=A0 In this case, it=E2=80=99= s probably a more manageable threat, because one can simply not get a NEST.= =C2=A0 Try not getting a CPAP machine.

And this br= ings us around to what layer to solve the problem at.=C2=A0 Some of this ma= y need to be dealt with at layer 9 rather than at lower layers.=C2=A0 We sh= ould have that discussion too.



Increasingly corporate networks are moving aw= ay from network layer access controls and using user authentication over TL= S, so-called BeyondCorp model, including checking endpoint posture through = management.

The endpoint being the focus for attacks is very important.=C2= =A0 As we shore the endpoint up further, attacks may reduce in number, but = will likely increase in severity due to state sponsored actors.=C2=A0 Work = in RATS, TEEP, SUIT, and MUD should be considered in terms of how assurance= of systems is provided and also looking at the use cases to ensure there a= re sometimes when you don't want that level of attestation.=C2=A0 User = ownership of data is another area.=C2=A0 These build on zero-trust/BeyondCo= rp/data-centric models and are examples of active work in the IETF on the e= nd point.=C2=A0 They also have the potential to shift management and archit= ectural models within the enterprise.

Best regards= ,
Kathleen=C2=A0
I don=E2= =80=99t think this solves the railroad case.=C2=A0 Do you?=C2=A0 Just to cl= arify the example:

According to their logs, two se= parate signals received =C2=A0=E2=80=9Cset your lights to green=E2=80=9D at= the same time, causing two trains to crash into each other.=C2=A0 Accordin= g to the signal controller=E2=80=99s logs, it sent =E2=80=9Cset your lights= to green=E2=80=9D to only one signal.=C2=A0 What happened?

<= /div>
All of the cases we are discussing have slightly different flavor= s of threats.=C2=A0 From an IAB program standpoint, the real question here = is this: what are the architectural building blocks that are required?=C2= =A0 Keep in mind, some of those blocks could be code and some could be poli= cy.

One goal should be code reuse. It is probably = best that the people building the train signal not reinvent everythi= ng, but rather benefit as much as they can from the experience and results = that you, EKR, and a great many other people have brought to society.
=

Eliot

(*) It=E2=80=99s also im= portant to not fall into old tribal communication patterns, while recognizi= ng the realities of the concerns raised by you, Watson, and me.
<= br>
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss


--

Best regards,
Kathleen
--000000000000c09d75059d3425af-- From nobody Tue Jan 28 07:16:17 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04783120808 for ; Tue, 28 Jan 2020 07:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.635 X-Spam-Level: ** X-Spam-Status: No, score=2.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_SCAM=1.999, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 4l9iQl_HP2NY for ; Tue, 28 Jan 2020 07:16:14 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 F1492120124 for ; Tue, 28 Jan 2020 07:16:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 486VZ56Tmfz1nyXc; Tue, 28 Jan 2020 07:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1580224573; bh=AS8X3yB4C40Zm3JG2J3nrwqwmjGRhDSQxHaTMZ7cybg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=oIG+MUGdrTVEQs1hpmkgBaFnansUzbWiE++M+Y+Tqjismo/xoxH3sT1AqGVgLNU6N 7wRU1GPpCS0VJaHF0M+VEW1yq1weV+jyavVAL0Beks1ZVlDwT+zIdxgD9+eQ+OX5PF MGZq3/d2uNP4/tCw244vMEzjCBp+QVF99bvHgOfg= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 486VZ51y9rz1ny8c; Tue, 28 Jan 2020 07:16:13 -0800 (PST) To: Eliot Lear Cc: architecture-discuss@ietf.org, model-t@iab.org References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> From: "Joel M. Halpern" Message-ID: <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> Date: Tue, 28 Jan 2020 10:16:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 15:16:15 -0000 I am a bit concerned by the emphasis on what appear to be application policy, business policy, or government policy. To the degree that these are decoupled from the technology we define, my impression is that the IETF is neither skilled at nor influential with regard to these topics. We can spend a lot of time and energy on them. They are interesting topics. But are they really our business? Yours, Joel On 1/28/2020 1:44 AM, Eliot Lear wrote: > Hi Watson, > >> On 28 Jan 2020, at 02:35, Watson Ladd > > wrote: >> >> >> >> On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear > > wrote: >> >>   Let’s look at three specific examples that I’ve mentioned: >> >> 1.  Train signaling system needs to be audited both live and >> retrospectively in the case of accidents.  This has to happen in >> such a way that the auditor sees precisely what was sent by one >> endpoint and received by the other. >> >> 2.  The case of “parent doesn’t want Internet toy to send video of >> child”, when the camera is undisclosed (it’s an analog to the >> privacy analysis on Alexa[1] and the now infamous NEST episode[2]). >> >> 3. CPAP machine or an AED/pace maker provide a control interface >> to the doctor but the patient or his next of kin wants the data. >> >> >> I've got a few more examples from real life: >> >> 4: We need to see who is sending pictures of Winnie the Pooh. >> >> 5: We don't want pictures of the inside of our detention centers to >> appear online. >> >> 6: I want to see everyone's credit card number at the coffee shop I run. >> >> Any discussion of tapping network communications because endpoints >> can't be trusted needs to take these cases seriously. > > > Absolutely.  What I am suggesting is a relatively new twist on an old > problem(*).  It’s important to understand the economic and policy > aspects of how/whether to avoid [4] and [5], how to avoid [6] while at > the same time addressing use cases I mentioned. > > So… today’s new information comes courtesy of the EFF. > > https://www.eff.org/deeplinks/2020/01/ring-doorbell-app-packed-third-party-trackers > > Here we have yet another IoT device that, from at least one person’s > perspective is invading home privacy.  And again, it is the device > itself that is the threat.  In this case, it’s probably a more > manageable threat, because one can simply not get a NEST.  Try not > getting a CPAP machine. > > And this brings us around to what layer to solve the problem at.  Some > of this may need to be dealt with at layer 9 rather than at lower > layers.  We should have that discussion too. > > >> >> Increasingly corporate networks are moving away from network layer >> access controls and using user authentication over TLS, so-called >> BeyondCorp model, including checking endpoint posture through management. > > I don’t think this solves the railroad case.  Do you?  Just to clarify > the example: > > According to their logs, two separate signals received  “set your lights > to green” at the same time, causing two trains to crash into each other. >  According to the signal controller’s logs, it sent “set your lights to > green” to only one signal.  What happened? > > All of the cases we are discussing have slightly different flavors of > threats.  From an IAB program standpoint, the real question here is > this: what are the architectural building blocks that are required? >  Keep in mind, some of those blocks could be code and some could be policy. > > One goal should be code reuse. It is probably best that the people > building the train signal *not* reinvent everything, but rather benefit > as much as they can from the experience and results that you, EKR, and a > great many other people have brought to society. > > Eliot > > (*) It’s also important to not fall into old tribal communication > patterns, while recognizing the realities of the concerns raised by you, > Watson, and me. > > From nobody Tue Jan 28 08:20:57 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E411D120A14; Tue, 28 Jan 2020 08:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 SdvSTlfS1Jyp; Tue, 28 Jan 2020 08:20:53 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0055120A06; Tue, 28 Jan 2020 08:20:53 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1iwTbe-000Ico-Hz; Tue, 28 Jan 2020 11:20:50 -0500 Date: Tue, 28 Jan 2020 11:20:45 -0500 From: John C Klensin To: "Joel M. Halpern" , Eliot Lear cc: architecture-discuss@ietf.org, model-t@iab.org Message-ID: <78E09CC1706F7D66D5F8DE1E@PSB> In-Reply-To: <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 16:20:56 -0000 --On Tuesday, January 28, 2020 10:16 -0500 "Joel M. Halpern" wrote: > I am a bit concerned by the emphasis on what appear to be > application policy, business policy, or government policy. To > the degree that these are decoupled from the technology we > define, my impression is that the IETF is neither skilled at > nor influential with regard to these topics. We can spend a > lot of time and energy on them. They are interesting topics. > But are they really our business? Joel, I've been trying, not very successfully, to follow this very lively discussion, but two observations which I hope are not out of context: (1) I think that "neither skilled nor influential ... [and therefore] not our business" leads us down a path whose destination is irrelevancy. Even for link encryption (and perhaps more so when the scope is broadened), we should probably recognize that mounting pressures from law enforcement (both associated with governments some of us like if they like any governments at all and those they don't like or who are viewed with more suspicion) could easily lead to regulations for government access to keys or other backdoors or even to outright bans on public use of cryptography. Even noting that arguments from the technical community had major influence on killing the Clipper Chip effort and that making those arguments was very far from "not our business", it seems to me that good engineering requires that we not put our heads in the sand and pretend that the world is different then it actually is or might be becoming when we design protocols. In particular, that may mean that, in some places, we should be writing specifications less in terms of "if you want to have privacy, you MUST do X" and more in terms of "...SHOULD do X unless that is not feasible but, if it isn't, then the fallback approach SHOULD include Y and Z". In the real world, "feasible" may include political of other constraints, not just constraints imposed by physics. We may not always be able to figure out good alternatives to our preferred recommendations, but I suggest that making a balanced and good faith effort to understand the problems and the environments in which we expect our protocols will be used will lead to better design even when we don't have good solutions. Or, to put it more negatively, if we fail to understand and try to account for those environments, we risk being put in a position in which _we_ are the ones responsible for Internet fragmentation and/or for protocol work moving to bodies other than the IETF because regulators make conforming implementations of IETF protocols illegal or commercial firms discover that conforming implementations cannot be developed and sold. (2) If I correctly understand the issues that Eliot, Watson, and Kathleen are exploring, the key involves the rather classic security issues of authorization and authentication --who should have access to particular information and how do we tell they are who they claim to be? In a way, maintaining and enforcing a non-trivial list of authorized parties but keeping everyone and everything else out (the example of some doctors and the patients themselves is very helpful for thinking about this) is a lot harder than keeping everyone out except those who control the endpoints (whatever that means). But most of that problem is technical and, if we don't have the expertise (I'm tempted to say "any more") that is a problem for us. In both cases, it seems to me that an IAB Program (or at least one or more serious workshops) are exactly the right model for addressing these problems for at least two reasons: The IAB is in a much better position than, say, an IETF WG, to recruit specific expertise to cover perspectives and areas of expertise that are not widely available in the IETF. It is also perfectly reasonable for such a program to produce recommendations about issues that need to be considered even if they have no good solutions or even if they are convinced that there are no solutions out there. I can only hope that the IAB will hold itself to a very high standard of including multiple perspectives (even perspectives with which IAB members and their perception of IETF consensus are in significant disagreement) and a broad range of expertise in the Program and that the community will hold the IAB accountable if they do not. If the way the IAB were to recruit Program members involved asking for volunteers from within the IETF community and then further narrowing the Program's perspective by selecting people from among those volunteers who agreed with the IAB's own views, the Program would likely be a waste of time or worse. john From nobody Tue Jan 28 08:50:47 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D9D1200E5 for ; Tue, 28 Jan 2020 08:50:45 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ch33kIGrqu5Q for ; Tue, 28 Jan 2020 08:50:40 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C30D1200D5 for ; Tue, 28 Jan 2020 08:50:39 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id v19so1053582oic.12 for ; Tue, 28 Jan 2020 08:50:39 -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=SRb/egMzVdOTxvAMMVZoAOxEQLeBQjT63w6Pj3H8Guo=; b=XnA3rOpEGlLCGxJ5LizuYC9Lo5NSGdCUXxsA3Qix+cv5cEzXVOozZCZ1jAEQt8vf3W yFEuOY4vQCapEgyhc83YbNYEE+c/ooDVK5CFul6eX9y8w4nYv4g4ouRrUEhxRlW1+y0J 2WeIZn5VVQw06Pwso/qRLGePsqJOYEgleTgTDIFL0ARs0XT8zBbLc3lNOkPsJA/rAoUt XWi0IftufhKlK3c+PBej8ANiU4A2XIIrRDvOuGp8GaBj3fROxs1ySVhSUE3lqkgWbcdZ U6FSzyEf9L1AZh/PWWGH6poPSSscwjLNbZkj48Awda1eJaR621XtyKPk1tEbhrCP8cN5 QQkw== 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=SRb/egMzVdOTxvAMMVZoAOxEQLeBQjT63w6Pj3H8Guo=; b=A6GNiQDNvUE/1gvR15ITpvYMLncFP4DUhY+0gvGLqcW56ue28udiuDxU0SjsWCoco2 Ig2sdRskE3fNVlJrWUQHOsMNYkcSCzwXRWONYX1F04KsQFnwWZ0T3vC6voONdglK3HpE mXP8Eiv2wYV+CSVRjk7x5R5gQrrtyoapGa2QicxSyf7RagrkTWRW6Mx+OcnGfBd4zL1Z AhRIR2VkIM/fNRcm+bHHQCDia4drcTs+Ex5FNrRM1cR8m5gUjELLsb3aFx9hl9c6tAN3 XoYXu4AYZDh0dugUW8L812FX/FKn0k4cL7zpFk+jSjZdmm3G/3kaI3W95B2AJq7QMiQg drkQ== X-Gm-Message-State: APjAAAVHUpbTCNQDROz0E+oBPsv0rso5VHh2mXj5jnP19DtrTNTU//e/ ifWuFDZl2ARLfqfoIQQ3rkZYeaH1sVf04KQhROk= X-Google-Smtp-Source: APXvYqy6X86IIaM+SILpTaPA+OKTKBuvjt+BffdwCRvFwRG89+3u+UaR3r8hOJq09opRgLdLPqNconSXtD0D5Jtgubg= X-Received: by 2002:a54:4f04:: with SMTP id e4mr3268167oiy.111.1580230238340; Tue, 28 Jan 2020 08:50:38 -0800 (PST) MIME-Version: 1.0 References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> <78E09CC1706F7D66D5F8DE1E@PSB> In-Reply-To: <78E09CC1706F7D66D5F8DE1E@PSB> From: Kathleen Moriarty Date: Tue, 28 Jan 2020 11:50:02 -0500 Message-ID: To: John C Klensin Cc: "Joel M. Halpern" , Eliot Lear , architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="000000000000050a88059d3606a6" Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 16:50:45 -0000 --000000000000050a88059d3606a6 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 28, 2020 at 11:21 AM John C Klensin wrote: > > > --On Tuesday, January 28, 2020 10:16 -0500 "Joel M. Halpern" > wrote: > > > I am a bit concerned by the emphasis on what appear to be > > application policy, business policy, or government policy. To > > the degree that these are decoupled from the technology we > > define, my impression is that the IETF is neither skilled at > > nor influential with regard to these topics. We can spend a > > lot of time and energy on them. They are interesting topics. > > But are they really our business? > > Joel, > > I've been trying, not very successfully, to follow this very > lively discussion, but two observations which I hope are not out > of context: > > (1) I think that "neither skilled nor influential ... [and > therefore] not our business" leads us down a path whose > destination is irrelevancy. Even for link encryption (and > perhaps more so when the scope is broadened), we should probably > recognize that mounting pressures from law enforcement (both > associated with governments some of us like if they like any > governments at all and those they don't like or who are viewed > with more suspicion) could easily lead to regulations for > government access to keys or other backdoors or even to outright > bans on public use of cryptography. Even noting that arguments > from the technical community had major influence on killing the > Clipper Chip effort and that making those arguments was very far > from "not our business", it seems to me that good engineering > requires that we not put our heads in the sand and pretend that > the world is different then it actually is or might be becoming > when we design protocols. In particular, that may mean that, > in some places, we should be writing specifications less in > terms of "if you want to have privacy, you MUST do X" and more > in terms of "...SHOULD do X unless that is not feasible but, if > it isn't, then the fallback approach SHOULD include Y and Z". > In the real world, "feasible" may include political of other > constraints, not just constraints imposed by physics. We may > not always be able to figure out good alternatives to our > preferred recommendations, but I suggest that making a balanced > and good faith effort to understand the problems and the > environments in which we expect our protocols will be used will > lead to better design even when we don't have good solutions. > > Or, to put it more negatively, if we fail to understand and try > to account for those environments, we risk being put in a > position in which _we_ are the ones responsible for Internet > fragmentation and/or for protocol work moving to bodies other > than the IETF because regulators make conforming implementations > of IETF protocols illegal or commercial firms discover that > conforming implementations cannot be developed and sold. > > (2) If I correctly understand the issues that Eliot, Watson, and > Kathleen are exploring, the key involves the rather classic > security issues of authorization and authentication --who should > have access to particular information and how do we tell they > are who they claim to be? In a way, maintaining and enforcing a > non-trivial list of authorized parties but keeping everyone and > everything else out (the example of some doctors and the > patients themselves is very helpful for thinking about this) is > a lot harder than keeping everyone out except those who control > the endpoints (whatever that means). But most of that problem > is technical and, if we don't have the expertise (I'm tempted to > say "any more") that is a problem for us. > A number with expertise in this area are engaged in the SACM, RATS, TEEP, and SUIT working groups. More were starting to come for SMART, but that was shutdown. Personally, I think engaging those who have expertise in this area is important and some draft authors who came for SMART should be engaged. They are on the front lines of malware and other system level attacks. Best regards, Kathleen > In both cases, it seems to me that an IAB Program (or at least > one or more serious workshops) are exactly the right model for > addressing these problems for at least two reasons: The IAB is > in a much better position than, say, an IETF WG, to recruit > specific expertise to cover perspectives and areas of expertise > that are not widely available in the IETF. It is also perfectly > reasonable for such a program to produce recommendations about > issues that need to be considered even if they have no good > solutions or even if they are convinced that there are no > solutions out there. I can only hope that the IAB will hold > itself to a very high standard of including multiple > perspectives (even perspectives with which IAB members and their > perception of IETF consensus are in significant disagreement) > and a broad range of expertise in the Program and that the > community will hold the IAB accountable if they do not. If the > way the IAB were to recruit Program members involved asking for > volunteers from within the IETF community and then further > narrowing the Program's perspective by selecting people from > among those volunteers who agreed with the IAB's own views, the > Program would likely be a waste of time or worse. > > john > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > -- Best regards, Kathleen --000000000000050a88059d3606a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 28, 2020 at 11:21 AM John= C Klensin <john-ietf@jck.com&g= t; wrote:


--On Tuesday, January 28, 2020 10:16 -0500 "Joel M. Halpern"
<jmh@joelhalper= n.com> wrote:

> I am a bit concerned by the emphasis on what appear to be
> application policy, business policy, or government policy.=C2=A0 To > the degree that these are decoupled from the technology we
> define, my impression is that the IETF is neither skilled at
> nor influential with regard to these topics. We can spend a
> lot of time and energy on them.=C2=A0 They are interesting topics.
> But are they really our business?

Joel,

I've been trying, not very successfully, to follow this very
lively discussion, but two observations which I hope are not out
of context:

(1) I think that "neither skilled nor influential ... [and
therefore] not our business" leads us down a path whose
destination is irrelevancy.=C2=A0 Even for link encryption (and
perhaps more so when the scope is broadened), we should probably
recognize that mounting pressures from law enforcement (both
associated with governments some of us like if they like any
governments at all and those they don't like or who are viewed
with more suspicion) could easily lead to regulations for
government access to keys or other backdoors or even to outright
bans on public use of cryptography.=C2=A0 Even noting that arguments
from the technical community had major influence on killing the
Clipper Chip effort and that making those arguments was very far
from "not our business", it seems to me that good engineering
requires that we not put our heads in the sand and pretend that
the world is different then it actually is or might be becoming
when we design protocols.=C2=A0 =C2=A0In particular, that may mean that, in some places, we should be writing specifications less in
terms of "if you want to have privacy, you MUST do X" and more in terms of "...SHOULD do X unless that is not feasible but, if
it isn't, then the fallback approach SHOULD include Y and Z".
In the real world, "feasible" may include political of other
constraints, not just constraints imposed by physics.=C2=A0 We may
not always be able to figure out good alternatives to our
preferred recommendations, but I suggest that making a balanced
and good faith effort to understand the problems and the
environments in which we expect our protocols will be used will
lead to better design even when we don't have good solutions.=C2=A0
Or, to put it more negatively, if we fail to understand and try
to account for those environments, we risk being put in a
position in which _we_ are the ones responsible for Internet
fragmentation and/or for protocol work moving to bodies other
than the IETF because regulators make conforming implementations
of IETF protocols illegal or commercial firms discover that
conforming implementations cannot be developed and sold.

(2) If I correctly understand the issues that Eliot, Watson, and
Kathleen are exploring, the key involves the rather classic
security issues of authorization and authentication --who should
have access to particular information and how do we tell they
are who they claim to be?=C2=A0 In a way, maintaining and enforcing a
non-trivial list of authorized parties but keeping everyone and
everything else out (the example of some doctors and the
patients themselves is very helpful for thinking about this) is
a lot harder than keeping everyone out except those who control
the endpoints (whatever that means).=C2=A0 =C2=A0But most of that problem is technical and, if we don't have the expertise (I'm tempted to say "any more") that is a problem for us.
A number with expertise in this area are engaged in the SACM, = RATS, TEEP, and SUIT working groups.=C2=A0 More were starting to come for S= MART, but that was shutdown.=C2=A0 Personally, I think engaging those who h= ave expertise in this area is important and some draft authors who came for= SMART should be engaged.=C2=A0 They are on the front lines of malware and = other system level attacks.

Best regards,
Kathleen


In both cases, it seems to me that an IAB Program (or at least
one or more serious workshops) are exactly the right model for
addressing these problems for at least two reasons:=C2=A0 The IAB is
in a much better position than, say, an IETF WG, to recruit
specific expertise to cover perspectives and areas of expertise
that are not widely available in the IETF.=C2=A0 It is also perfectly
reasonable for such a program to produce recommendations about
issues that need to be considered even if they have no good
solutions or even if they are convinced that there are no
solutions out there.=C2=A0 I can only hope that the IAB will hold
itself to a very high standard of including multiple
perspectives (even perspectives with which IAB members and their
perception of IETF consensus are in significant disagreement)
and a broad range of expertise in the Program and that the
community will hold the IAB accountable if they do not.=C2=A0 If the
way the IAB were to recruit Program members involved asking for
volunteers from within the IETF community and then further
narrowing the Program's perspective by selecting people from
among those volunteers who agreed with the IAB's own views, the
Program would likely be a waste of time or worse.

=C2=A0 =C2=A0 john

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss


--

Best regards,
Kathleen
--000000000000050a88059d3606a6-- From nobody Tue Jan 28 10:46:41 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB93120025 for ; Tue, 28 Jan 2020 10:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 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, FREEMAIL_REPLY=1, HK_SCAM=1.999, SPF_HELO_NONE=0.001, 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 4CV_YvdsYRQb for ; Tue, 28 Jan 2020 10:46:35 -0800 (PST) Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) (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 60D51120026 for ; Tue, 28 Jan 2020 10:46:35 -0800 (PST) Received: by mail-pj1-x1043.google.com with SMTP id r67so1460823pjb.0 for ; Tue, 28 Jan 2020 10:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0SrB4nT6nvVgikt51fyxXvGZBYxHZY3MRaweNo0Zyto=; b=ce1X36c1m/BCYnbO2YGeW5Vll7NhcxbVtDj6ExZsF13yviF1KA0bv5VRfummhklHcH CU8i9Zuz9Cd7dmc5souq3YYmev4S2rTpfdim8prE587E7faw/iYfQbJSXrQoDn+b+QsV IWy8wRlXoC3vz66Chi3cjKtoVGYVAReJshgn03LCOmlogLHWdzR2oWqQuYAu2RQFJpRV vEL6uNh5VBbP6tv0aBEyrf5AnvwO9/SBB6l+SEomci6UEMtPzfYHtzHs34rRgJ+DmlUm n+vZIcZk9kBYRUXyF1Af3SI//PsvlEy9B04I782qy33zUDlB/krqzMYz9XTbLQXpM4ip pVdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0SrB4nT6nvVgikt51fyxXvGZBYxHZY3MRaweNo0Zyto=; b=CvbSM2rbrN8k0EaDSrKM+z5gK8SzByWe9FXLjmDkCMuix1KJWWZbju6lGujUxmtp/Z F4q4pLQgN7GgROBjbXXcV8/3+OYAq2MmUXWcg82W6EWbom+6Q9V6hGIXmenkxYET7YTQ iG8kT6+Wr/Zf8kHP669R8FMWMl5giweYAvP72vTMbDdyDWzNmy496QB+zXQhZLA9QOFc 5Vv0TvP0P8Hs29RzQIyc5ys/AP1242oX/p8+Hv4/vYBKDxyhheQExulQexCRo0RPseyb 6JMJzCfpYkBN4FWJ+lwcX2jOT/Zs24bpT43DvxtHE0kz7LMtyu56KmXPzvCfmTEqGcKl poqg== X-Gm-Message-State: APjAAAUj7JKCvVTeng1gkzTwwTS/QGfqVcN1ld46U7FmDjd7UXVTwpbZ ET6QIFx0waEF5tTDKReihG8= X-Google-Smtp-Source: APXvYqynwVjckXfblZmG9skSugL53pDbqHTVUMN56FW40SXdwE25Tzfc6G8liP2mTgPCStWHK51y2w== X-Received: by 2002:a17:90a:8a08:: with SMTP id w8mr6338953pjn.125.1580237194672; Tue, 28 Jan 2020 10:46:34 -0800 (PST) Received: from [10.1.2.245] ([43.251.155.206]) by smtp.gmail.com with ESMTPSA id i127sm21165952pfe.54.2020.01.28.10.46.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jan 2020 10:46:34 -0800 (PST) To: "Joel M. Halpern" , Eliot Lear Cc: architecture-discuss@ietf.org, model-t@iab.org References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6d587cdf-5d93-2c38-0160-ddd2a41a5c41@gmail.com> Date: Wed, 29 Jan 2020 07:46:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 18:46:37 -0000 On 29-Jan-20 04:16, Joel M. Halpern wrote: > I am a bit concerned by the emphasis on what appear to be application=20 > policy, business policy, or government policy. To the degree that thes= e=20 > are decoupled from the technology we define, my impression is that the = > IETF is neither skilled at nor influential with regard to these topics.= =20 > We can spend a lot of time and energy on them. They are interesting=20 > topics. But are they really our business? Joel, I think they are part of the threat model (exactly as we have argue= d in RFC1984, RFC2804 and RFC7258). In that sense they are absolutely our b= usiness. Just in the last few days, key escrow has been back in the news, for exam= ple. Ultimately, technology influences policy, so our choices are not without impact. Regards Brian >=20 > Yours, > Joel >=20 > On 1/28/2020 1:44 AM, Eliot Lear wrote: >> Hi Watson, >> >>> On 28 Jan 2020, at 02:35, Watson Ladd >> > wrote: >>> >>> >>> >>> On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear >> > wrote: >>> >>> =C2=A0 Let=E2=80=99s look at three specific examples that I=E2=80= =99ve mentioned: >>> >>> 1.=C2=A0 Train signaling system needs to be audited both live and= >>> retrospectively in the case of accidents.=C2=A0 This has to happe= n in >>> such a way that the auditor sees precisely what was sent by one >>> endpoint and received by the other. >>> >>> 2.=C2=A0 The case of =E2=80=9Cparent doesn=E2=80=99t want Interne= t toy to send video of >>> child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s an a= nalog to the >>> privacy analysis on Alexa[1] and the now infamous NEST episode[2]= ). >>> >>> 3. CPAP machine or an AED/pace maker provide a control interface >>> to the doctor but the patient or his next of kin wants the data. >>> >>> >>> I've got a few more examples from real life: >>> >>> 4: We need to see who is sending pictures of Winnie the Pooh. >>> >>> 5: We don't want pictures of the inside of our detention centers to=20 >>> appear online. >>> >>> 6: I want to see everyone's credit card number at the coffee shop I r= un. >>> >>> Any discussion of tapping network communications because endpoints=20 >>> can't be trusted needs to take these cases seriously.=20 >> >> >> Absolutely. =C2=A0What I am suggesting is a relatively new twist on an= old=20 >> problem(*). =C2=A0It=E2=80=99s important to understand the economic an= d policy=20 >> aspects of how/whether to avoid [4] and [5], how to avoid [6] while at= =20 >> the same time addressing use cases I mentioned. >> >> So=E2=80=A6 today=E2=80=99s new information comes courtesy of the EFF.= >> >> https://www.eff.org/deeplinks/2020/01/ring-doorbell-app-packed-third-p= arty-trackers >> >> Here we have yet another IoT device that, from at least one person=E2=80= =99s=20 >> perspective is invading home privacy. =C2=A0And again, it is the devic= e=20 >> itself that is the threat. =C2=A0In this case, it=E2=80=99s probably a= more=20 >> manageable threat, because one can simply not get a NEST. =C2=A0Try no= t=20 >> getting a CPAP machine. >> >> And this brings us around to what layer to solve the problem at. =C2=A0= Some=20 >> of this may need to be dealt with at layer 9 rather than at lower=20 >> layers. =C2=A0We should have that discussion too. >> >> >>> >>> Increasingly corporate networks are moving away from network layer=20 >>> access controls and using user authentication over TLS, so-called=20 >>> BeyondCorp model, including checking endpoint posture through managem= ent. >> >> I don=E2=80=99t think this solves the railroad case. =C2=A0Do you? =C2= =A0Just to clarify=20 >> the example: >> >> According to their logs, two separate signals received =C2=A0=E2=80=9C= set your lights=20 >> to green=E2=80=9D at the same time, causing two trains to crash into e= ach other.=20 >> =C2=A0According to the signal controller=E2=80=99s logs, it sent =E2=80= =9Cset your lights to=20 >> green=E2=80=9D to only one signal. =C2=A0What happened? >> >> All of the cases we are discussing have slightly different flavors of = >> threats. =C2=A0From an IAB program standpoint, the real question here = is=20 >> this: what are the architectural building blocks that are required?=20 >> =C2=A0Keep in mind, some of those blocks could be code and some could= be policy. >> >> One goal should be code reuse. It is probably best that the people=20 >> building the train signal *not* reinvent everything, but rather benefi= t=20 >> as much as they can from the experience and results that you, EKR, and= a=20 >> great many other people have brought to society. >> >> Eliot >> >> (*) It=E2=80=99s also important to not fall into old tribal communicat= ion=20 >> patterns, while recognizing the realities of the concerns raised by yo= u,=20 >> Watson, and me. >> >> >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Tue Jan 28 11:23:14 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADC512003E for ; Tue, 28 Jan 2020 11:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDG-jn-sUr9S for ; Tue, 28 Jan 2020 11:23:11 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7E1120033 for ; Tue, 28 Jan 2020 11:23:11 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2D00454804A; Tue, 28 Jan 2020 20:23:05 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 26E0B440059; Tue, 28 Jan 2020 20:23:05 +0100 (CET) Date: Tue, 28 Jan 2020 20:23:05 +0100 From: Toerless Eckert To: Stephen Farrell Cc: Eliot Lear , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org Message-ID: <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] not building blocks (was: Re: [Model-t] Possible new IAB program on Internet trust model evolution) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 19:23:13 -0000 Stephen, I totally do not get how you read Eliots text as being about TLS. I read Eliot/Watsons mails to be in the same direction as what i was pointing out yesterday. Let me try to abstract maybe better: In the past, we have primarily looked at the security implications of individual protocols, communicating mostly between two endpoints and attacks against this communication by observers, MitM, or malicious endpoints. Of course, we went beyond that but not systematically to the point that instead of concentrating only on the communication channels, we would instead concentrate also on the properties of modules whose complete external behavior is defined through a set of interfaces. And then define security properties observing that superset of interfaces. Once you have this model, Watson/Eliots examples are easy translated into propagation properties between these interfaes. My yesterdays mail points was more about the problem of having modules that are small enough or implemented in a way that at least specific properties can be verified instead of just having to trust the module vendor. Or having interfaces that allows another module to verify/control behavior. Of course, the fun difference with this model is that in the most simple of cases, you could try to view a complete router as one of those modules, because vendors of such gear have a great interest to well define and expose all interfaces of such a device, wheras a typical communications endpoint such as an application server in a data-center is more often than not built around a business model where exposure/ definition of all interfaces would expose bad business practices. Hence also political approaches like GDPR to start addressing that problem. Cheers Toerless On Tue, Jan 28, 2020 at 10:02:43AM +0000, Stephen Farrell wrote: > > Hiya, > > On 28/01/2020 06:44, Eliot Lear wrote: > > From an IAB program standpoint, the real question here is this: what > > are the architectural building blocks that are required? > I'm not sure I agree. ISTM you envisage a programme that > tries to establish that existing IETF consensus as to the > use of e2e encryption needs to be changed, which I don't > think is a goal here. Personally, I think of this as a > place to work on whether or not it's possible to extend > (not replace) the 3552 threat model to cater for changes > since 3552 was written. (I do think that's an interesting > question and it's unclear to me if the answer is "yes" or > "would like to, but it's not usefully feasible.") > > Now, it's of course valid to point out that comsec (as > ekr may put it) if applied e2e doesn't by itself meet > all requirements stated in your examples, to which I'd > maybe argue to extend the Internet threat model with > some statement along the lines of: "if an endpoint > does need to see traffic content or significant meta- > data, then you need to design your protocol so that that > endpoint is an endpoint at which relevant cryptographic > mechanisms are validly terminated, according to the > expectations of the cryptographic protocol(s) in use (e.g. > TLS, IPsec). Changing the security properties of widely > deployed cryptographic protocols is not likely to be a > useful approach to attempt, as there are too many > deleterious side-effects of such proposed changes." > > So I don't think, for the purposes of this exercise, > we're considering existing widely deployed protocols as > malleable building blocks, whether that protocol is > TLS or some (deployed) train signalling system. > > Cheers, > S. > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) > sub RSA 4096/36CB8BB6 2017-12-22 > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Tue Jan 28 11:34:04 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E611120059 for ; Tue, 28 Jan 2020 11:33: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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 4wkZBciH58_e for ; Tue, 28 Jan 2020 11:33:55 -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 508FD120044 for ; Tue, 28 Jan 2020 11:33:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 34CF6BE39; Tue, 28 Jan 2020 19:33:53 +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 vB9iCe6W59HG; Tue, 28 Jan 2020 19:33:51 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F837BE2E; Tue, 28 Jan 2020 19:33:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1580240031; bh=gNIaoq2gQPozLAH1XZUrLMf6mRLk6DXGkQwNndQjBi4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OXRA3mvv6LdK8PeDyyHRMCKH35du0a3PyicGxWG/XMBj4JyIaxoPAGMhwbiyM9Yex Yb3c90C6j8dRp6u5M1YjmASb/LoYjxTmwtMfL3Qo0NO5sBFrZEaUHz2yitmh6bUViI vlQ6jBV8zukAm8rsHExAaO3qD0yJE2T+4eGsQ3NY= To: Kathleen Moriarty , John C Klensin Cc: model-t@iab.org, architecture-discuss@ietf.org References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> <78E09CC1706F7D66D5F8DE1E@PSB> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: <9cec50fa-cb7c-ef75-95b3-c85f9f255c6d@cs.tcd.ie> Date: Tue, 28 Jan 2020 19:33:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Yl1LipH1FYBCGBTpZ0kDSSYYMp1HPIyQf" Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet threat model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 19:33:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Yl1LipH1FYBCGBTpZ0kDSSYYMp1HPIyQf Content-Type: multipart/mixed; boundary="DAzfZbsTA95unbNNEUI7pK2PiaWMgf1L9"; protected-headers="v1" From: Stephen Farrell To: Kathleen Moriarty , John C Klensin Cc: model-t@iab.org, architecture-discuss@ietf.org Message-ID: <9cec50fa-cb7c-ef75-95b3-c85f9f255c6d@cs.tcd.ie> Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet threat model evolution References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> <78E09CC1706F7D66D5F8DE1E@PSB> In-Reply-To: --DAzfZbsTA95unbNNEUI7pK2PiaWMgf1L9 Content-Type: multipart/mixed; boundary="------------5F55455BB80CAAD27DFAE213" Content-Language: en-US This is a multi-part message in MIME format. --------------5F55455BB80CAAD27DFAE213 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John, Kathleen, Just on comments related to participation: "Participation in this program is open to all interested parties, and considered analysis of diverse inputs is important" is what [1] already says. If you think some rewording is needed be good to know what, or if it's just a case of that text not having been noticed, then we're good I guess. Cheers, S. PS: I fixed the typo in the subject line that was my fault in the first place:-) [1] https://github.com/intarchboard/model-t-charter/blob/master/model-t-chart= er-00.md --------------5F55455BB80CAAD27DFAE213 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------5F55455BB80CAAD27DFAE213-- --DAzfZbsTA95unbNNEUI7pK2PiaWMgf1L9-- --Yl1LipH1FYBCGBTpZ0kDSSYYMp1HPIyQf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4wjJ4ACgkQWrL68XsX K+rJCA/+NVGfNeVb2hSTBYXt0VxAV/9NVqGOVZ8aEJThfplAf8fa49Y6h3K0DoPc zeLFv9Oq4CXlbVdMtI+YlmKAS99gNyQjzcM0npby2l5PqTmW1D0jzDCLT5YozDvL v+juAg26s+m2hTaXmqq1P1geQ6tT+g2uETBNQRQ6oeXciQ8slyRmWo77gdNU33Tn IpmQokAO5T51HSNX9oUPI8bZKscw2R0LbHq2oEI9Q7h6XYqB+viLxlMv/ama1J94 qACANiZxGKi+KzvsJGd28MHbq5h4ImI4712mdgqIbCBs7jsbH+a4soUNvIvBqB92 7LPtI5TCFJ7vH2XCAVsm7NzPfdG+sho6vrTKnUnmAEOvx+7IjuWJ2xP6o6oycadf L9zUZY90KtyM/LTZfAvUMgwkLJQ8/Jmb9YFjxpZDCrmIs4k+KcorrJQXtD4Ht8RF dqSkSmk3Km9rNvrdCECmz24U/SbcX+gtFFrQPM6sjyTOrS/pFJNTDstW85oa4MQW 6p11JvuoGQTe/h//YosijsE69tDgKM2q6eekI47OShHFxkYG0R9JaSpyV8ZSblq/ +V9F9ktTWUjxKFYeWVr5b8zNicm880V7MKSTg7aPfv51yhoqs8SvSWEuQEKmKIb8 O5MSeKM5yJzUrlHcXmL0iF+LJ4pRV0ye+ZN2EqOhXMi7iQNk3CU= =PVri -----END PGP SIGNATURE----- --Yl1LipH1FYBCGBTpZ0kDSSYYMp1HPIyQf-- From nobody Tue Jan 28 11:46:48 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBC3120044 for ; Tue, 28 Jan 2020 11:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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, 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 LRSEhVcSJqwJ for ; Tue, 28 Jan 2020 11:46:42 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5FA1120024 for ; Tue, 28 Jan 2020 11:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29004; q=dns/txt; s=iport; t=1580240802; x=1581450402; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ALpnn1WB9+Q+BsQ3Ic7jr2bENzynhqpvCPJGH953nH4=; b=Z8vYlMT55XRXo3cTgl1TYQmX23NCV9iQUWK/TOy32bWf6TR4bHeXS2X8 p/NMoxlkv5OHI6UEgPHZpdZpMiYYq9LYBtxbvDyut+jwouWn7OBgKJofb ut3f9zISUq/tBK1c5+aWYq6mRe0lHnej5EgudPocBkj0fPwEudNyuKJO4 U=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAQBtjjBe/xbLJq1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4ElU4EddRIqhBSJA4g7hz2SFIFjBAIHAQEBCQMBARg?= =?us-ascii?q?BCgwBAYN7RQKCSjgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECAQEBIUsLBQs?= =?us-ascii?q?LEgYgAQIHAgInIg4GExuDCwGCWyAPrS11gTKFSoRxCgaBOIFTiSaBP4IAgRE?= =?us-ascii?q?nIIFOfj6CZAEBgSccAQEIgyYygiwEjg6JJpgkgkOCTIEckk8bgkiMT4tlpj+?= =?us-ascii?q?DLgIEBgUCFYFpIoFYMxoIGxU7KgGCQT4SGA2OVYhPhUBAAzCMAoIyAQE?= X-IronPort-AV: E=Sophos;i="5.70,375,1574121600"; d="asc'?scan'208,217";a="22644635" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jan 2020 19:46:39 +0000 Received: from ams3-vpn-dhcp4134.cisco.com (ams3-vpn-dhcp4134.cisco.com [10.61.80.37]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00SJkcsT030850 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jan 2020 19:46:39 GMT From: Eliot Lear Message-Id: <26E2222F-93B0-4E3C-9C4F-F75A119BB109@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_05435614-0E6D-4AF7-81F1-361A8ED88299"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 28 Jan 2020 20:46:38 +0100 In-Reply-To: Cc: Toerless Eckert , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org To: Stephen Farrell References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.80.37, ams3-vpn-dhcp4134.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [arch-d] not building blocks (was: Re: [Model-t] Possible new IAB program on Internet trust model evolution) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 19:46:46 -0000 --Apple-Mail=_05435614-0E6D-4AF7-81F1-361A8ED88299 Content-Type: multipart/alternative; boundary="Apple-Mail=_5E61AF67-2A6D-4568-9286-52AAC88F86FA" --Apple-Mail=_5E61AF67-2A6D-4568-9286-52AAC88F86FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Jan 2020, at 20:39, Stephen Farrell = wrote: >=20 >=20 > Hiya >=20 > Offlist for two reasons... >=20 > On 28/01/2020 19:23, Toerless Eckert wrote: >> Stephen, >>=20 >> I totally do not get how you read Eliots text as being about TLS. >=20 > He and I have chatted about this before - one of the > options he maybe like for his train example is a NULL > encryption ciphersuite to be standardised/recommended > (as opposed to defined) for TLS1.3. I think that'd be > a bad plan. That is not my preferred solution, Stephen. While industrial automation = doesn=E2=80=99t really require encryption for most uses, I don=E2=80=99t = think it can hurt, so long as the necessary auditing can take place. = Let=E2=80=99s focus on the problem first. If we can agree on that, then = let=E2=80=99s move on from there. Eliot >=20 >>=20 >> I read Eliot/Watsons mails to be in the same direction as what i was >> pointing out yesterday. >=20 > 2nd reason for offlist is that I'm not getting what you > mean below, but I'm pushed for time right now, so maybe > reading it later will make it clear;-) In any case, it'll > be a while 'till I get to respond, sorry. >=20 > Cheers, > S. >=20 >>=20 >> Let me try to abstract maybe better: >>=20 >> In the past, we have primarily looked at the security implications >> of individual protocols, communicating mostly between two endpoints >> and attacks against this communication by observers, MitM, or >> malicious endpoints. >>=20 >> Of course, we went beyond that but not systematically to the point = that >> instead of concentrating only on the communication channels, we would >> instead concentrate also on the properties of modules whose complete >> external behavior is defined through a set of interfaces. And then >> define security properties observing that superset of interfaces. >>=20 >> Once you have this model, Watson/Eliots examples are easy translated >> into propagation properties between these interfaes. >>=20 >> My yesterdays mail points was more about the problem of having >> modules that are small enough or implemented in a way that at >> least specific properties can be verified instead of just having to >> trust the module vendor. Or having interfaces that allows another >> module to verify/control behavior. >>=20 >> Of course, the fun difference with this model is that in the most >> simple of cases, you could try to view a complete router as one >> of those modules, because vendors of such gear have a great interest >> to well define and expose all interfaces of such a device, wheras a = typical >> communications endpoint such as an application server in a = data-center >> is more often than not built around a business model where exposure/ >> definition of all interfaces would expose bad business practices. >> Hence also political approaches like GDPR to start addressing >> that problem. >>=20 >> Cheers >> Toerless >>=20 >> On Tue, Jan 28, 2020 at 10:02:43AM +0000, Stephen Farrell wrote: >>>=20 >>> Hiya, >>>=20 >>> On 28/01/2020 06:44, Eliot Lear wrote: >>>> =46rom an IAB program standpoint, the real question here is this: = what >>>> are the architectural building blocks that are required? >>> I'm not sure I agree. ISTM you envisage a programme that >>> tries to establish that existing IETF consensus as to the >>> use of e2e encryption needs to be changed, which I don't >>> think is a goal here. Personally, I think of this as a >>> place to work on whether or not it's possible to extend >>> (not replace) the 3552 threat model to cater for changes >>> since 3552 was written. (I do think that's an interesting >>> question and it's unclear to me if the answer is "yes" or >>> "would like to, but it's not usefully feasible.") >>>=20 >>> Now, it's of course valid to point out that comsec (as >>> ekr may put it) if applied e2e doesn't by itself meet >>> all requirements stated in your examples, to which I'd >>> maybe argue to extend the Internet threat model with >>> some statement along the lines of: "if an endpoint >>> does need to see traffic content or significant meta- >>> data, then you need to design your protocol so that that >>> endpoint is an endpoint at which relevant cryptographic >>> mechanisms are validly terminated, according to the >>> expectations of the cryptographic protocol(s) in use (e.g. >>> TLS, IPsec). Changing the security properties of widely >>> deployed cryptographic protocols is not likely to be a >>> useful approach to attempt, as there are too many >>> deleterious side-effects of such proposed changes." >>>=20 >>> So I don't think, for the purposes of this exercise, >>> we're considering existing widely deployed protocols as >>> malleable building blocks, whether that protocol is >>> TLS or some (deployed) train signalling system. >>>=20 >>> Cheers, >>> S. >>>=20 >>=20 >> pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) = >>> sub RSA 4096/36CB8BB6 2017-12-22 >>>=20 >>=20 >>=20 >>=20 >>=20 >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>=20 >>=20 > <0x5AB2FAF17B172BEA.asc> --Apple-Mail=_5E61AF67-2A6D-4568-9286-52AAC88F86FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 28 Jan 2020, at 20:39, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya

Offlist for two = reasons...

On 28/01/2020 = 19:23, Toerless Eckert wrote:
Stephen,

I= totally do not get how you read Eliots text as being about TLS.

He and I have chatted about this before - one of = the
options he = maybe like for his train example is a NULL
encryption ciphersuite to be = standardised/recommended
(as opposed to defined) for TLS1.3. I think that'd = be
a bad = plan.

That is = not my preferred solution, Stephen.  While = industrial automation doesn=E2=80=99t really require encryption for most = uses, I don=E2=80=99t think it can hurt, so long as the necessary = auditing can take place.  Let=E2=80=99s focus on the problem first. =  If we can agree on that, then let=E2=80=99s move on from = there.

Eliot


I read Eliot/Watsons = mails to be in the same direction as what i was
pointing = out yesterday.

2nd reason for offlist is that I'm not getting what = you
mean below, = but I'm pushed for time right now, so maybe
reading it later will make it = clear;-) In any case, it'll
be a while 'till I get to respond, sorry.

Cheers,
S.


Let me try to abstract = maybe better:

In the past, we have = primarily looked at the security implications
of = individual protocols, communicating mostly between two endpoints
and attacks against this communication by observers, MitM, = or
malicious endpoints.

Of = course, we went beyond that but not systematically to the point that
instead of concentrating only on the communication channels, = we would
instead concentrate also on the properties of = modules whose complete
external behavior is defined = through a set of interfaces. And then
define security = properties observing that superset of interfaces.

Once you have this model, Watson/Eliots examples are easy = translated
into propagation properties between these = interfaes.

My yesterdays mail points was = more about the problem of having
modules that are small = enough or implemented in a way that at
least specific = properties can be verified instead of just having to
trust = the module vendor. Or having interfaces that allows another
module to verify/control behavior. 

Of course, the fun difference with this model is that in the = most
simple of cases, you could try to view a complete = router as one
of those modules, because vendors of such = gear have a great interest
to well define and expose all = interfaces of such a device, wheras a typical
communications= endpoint such as an application server in a data-center
is = more often than not built around a business model where exposure/
definition of all interfaces would expose bad business = practices.
Hence also political approaches like GDPR to = start addressing
that problem.

Cheers
   Toerless

On Tue, Jan 28, 2020 at 10:02:43AM +0000, = Stephen Farrell wrote:

Hiya,

On = 28/01/2020 06:44, Eliot Lear wrote:
=46rom an IAB program standpoint, the real = question here is this: what
are the architectural building = blocks that are required?
I'm not sure I = agree. ISTM you envisage a programme that
tries to = establish that existing IETF consensus as to the
use of = e2e encryption needs to be changed, which I don't
think is = a goal here. Personally, I think of this as a
place to = work on whether or not it's possible to extend
(not = replace) the 3552 threat model to cater for changes
since = 3552 was written. (I do think that's an interesting
question= and it's unclear to me if the answer is "yes" or
"would = like to, but it's not usefully feasible.")

Now, it's of course valid to point out that comsec (as
ekr may put it) if applied e2e doesn't by itself meet
all requirements stated in your examples, to which I'd
maybe argue to extend the Internet threat model with
some statement along the lines of: "if an endpoint
does need to see traffic content or significant meta-
data, then you need to design your protocol so that that
endpoint is an endpoint at which relevant cryptographic
mechanisms are validly terminated, according to the
expectations of the cryptographic protocol(s) in use (e.g.
TLS, IPsec). Changing the security properties of widely
deployed cryptographic protocols is not likely to be a
useful approach to attempt, as there are too many
deleterious side-effects of such proposed changes."

So I don't think, for the purposes of this = exercise,
we're considering existing widely deployed = protocols as
malleable building blocks, whether that = protocol is
TLS or some (deployed) train signalling = system.

Cheers,
S.


pub =   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <stephen.farrell@cs.tcd.ie>
sub   RSA 4096/36CB8BB6 2017-12-22





_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss


<0x5AB2FAF17B= 172BEA.asc>

= --Apple-Mail=_5E61AF67-2A6D-4568-9286-52AAC88F86FA-- --Apple-Mail=_05435614-0E6D-4AF7-81F1-361A8ED88299 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4wj54ACgkQh7ZrRtnS ejM8HwgAvh4fMUL6JrUlJCisdShcGHgzdeYUmRvc+nmI2bzv8JLSgJMnc3F5Mx28 TduIdvSpXHpDosqZHQSdh9Z7nys0w5SX4P9eAcn5IKnt/EtcsOqUrz30Fsmtyy5T F8nZFpmeUPA57MLPrIZwvUD7RFidphLnVYvBBv+MuosNzIPQ6eD1oWdbru0dim9B 5nFUllz2ZX2ByvrZS5b12HRG+LNhnytRIIrggoPcmN8NwMgQzursPuSeZhYEJgBU kKxNNlSiXA2G5P2VItxeSs8OA5VFjb9+DE8t1A0o33t6YqNrkZsjidT21JByHbiW VcK3VNk+g0vu3T6HQf46cjuiMK9y8w== =QIkG -----END PGP SIGNATURE----- --Apple-Mail=_05435614-0E6D-4AF7-81F1-361A8ED88299-- From nobody Tue Jan 28 11:48:34 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB2E120045 for ; Tue, 28 Jan 2020 11:48:23 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 HXTn-Xn-_q2q for ; Tue, 28 Jan 2020 11:48:20 -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 7BB8C120033 for ; Tue, 28 Jan 2020 11:48:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1BF47BE20; Tue, 28 Jan 2020 19:39:15 +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 uj_TMlJ7erSR; Tue, 28 Jan 2020 19:39:12 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A01B3BDCF; Tue, 28 Jan 2020 19:39:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1580240352; bh=Wg2AcaYs3/k4+9JtzMGkjUwQnIl+FEqaRz80j5n1O3U=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=sPnWa5HvTyPPdIb/6nRwQ5yWTJwjkwPyEPPa8qr+HhiKPEPqHDN6isP6bdZtBfdET Xkcm2Ssldc6ddlzbaxQVgus/UN9I1iLKgWdLNV2uAiabpsvVyAH29H8cSHJzUGIcTr NMAPrU5ZHaJXI6ENiRuY2496ekalQp5wHgF8xMRM= To: Toerless Eckert Cc: Eliot Lear , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: Tue, 28 Jan 2020 19:39:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rdtr0Cl7sTrpaKKxkSDxvIXIPgwQbLbqN" Archived-At: Subject: Re: [arch-d] not building blocks (was: Re: [Model-t] Possible new IAB program on Internet trust model evolution) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 19:48:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rdtr0Cl7sTrpaKKxkSDxvIXIPgwQbLbqN Content-Type: multipart/mixed; boundary="8DFszHmDSUM9b2H8Y4iU2G4vLrfG2QUhj"; protected-headers="v1" From: Stephen Farrell To: Toerless Eckert Cc: Eliot Lear , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org Message-ID: Subject: Re: [arch-d] not building blocks (was: Re: [Model-t] Possible new IAB program on Internet trust model evolution) References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> --8DFszHmDSUM9b2H8Y4iU2G4vLrfG2QUhj Content-Type: multipart/mixed; boundary="------------C20916BFF6EC90EF4FE22867" Content-Language: en-US This is a multi-part message in MIME format. --------------C20916BFF6EC90EF4FE22867 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya Offlist for two reasons... On 28/01/2020 19:23, Toerless Eckert wrote: > Stephen, >=20 > I totally do not get how you read Eliots text as being about TLS. He and I have chatted about this before - one of the options he maybe like for his train example is a NULL encryption ciphersuite to be standardised/recommended (as opposed to defined) for TLS1.3. I think that'd be a bad plan. >=20 > I read Eliot/Watsons mails to be in the same direction as what i was > pointing out yesterday. 2nd reason for offlist is that I'm not getting what you mean below, but I'm pushed for time right now, so maybe reading it later will make it clear;-) In any case, it'll be a while 'till I get to respond, sorry. Cheers, S. >=20 > Let me try to abstract maybe better: >=20 > In the past, we have primarily looked at the security implications > of individual protocols, communicating mostly between two endpoints > and attacks against this communication by observers, MitM, or > malicious endpoints. >=20 > Of course, we went beyond that but not systematically to the point that= > instead of concentrating only on the communication channels, we would > instead concentrate also on the properties of modules whose complete > external behavior is defined through a set of interfaces. And then > define security properties observing that superset of interfaces. >=20 > Once you have this model, Watson/Eliots examples are easy translated > into propagation properties between these interfaes. >=20 > My yesterdays mail points was more about the problem of having > modules that are small enough or implemented in a way that at > least specific properties can be verified instead of just having to > trust the module vendor. Or having interfaces that allows another > module to verify/control behavior.=20 >=20 > Of course, the fun difference with this model is that in the most > simple of cases, you could try to view a complete router as one > of those modules, because vendors of such gear have a great interest > to well define and expose all interfaces of such a device, wheras a typ= ical > communications endpoint such as an application server in a data-center > is more often than not built around a business model where exposure/ > definition of all interfaces would expose bad business practices. > Hence also political approaches like GDPR to start addressing > that problem. >=20 > Cheers > Toerless >=20 > On Tue, Jan 28, 2020 at 10:02:43AM +0000, Stephen Farrell wrote: >> >> Hiya, >> >> On 28/01/2020 06:44, Eliot Lear wrote: >>> From an IAB program standpoint, the real question here is this: what >>> are the architectural building blocks that are required? >> I'm not sure I agree. ISTM you envisage a programme that >> tries to establish that existing IETF consensus as to the >> use of e2e encryption needs to be changed, which I don't >> think is a goal here. Personally, I think of this as a >> place to work on whether or not it's possible to extend >> (not replace) the 3552 threat model to cater for changes >> since 3552 was written. (I do think that's an interesting >> question and it's unclear to me if the answer is "yes" or >> "would like to, but it's not usefully feasible.") >> >> Now, it's of course valid to point out that comsec (as >> ekr may put it) if applied e2e doesn't by itself meet >> all requirements stated in your examples, to which I'd >> maybe argue to extend the Internet threat model with >> some statement along the lines of: "if an endpoint >> does need to see traffic content or significant meta- >> data, then you need to design your protocol so that that >> endpoint is an endpoint at which relevant cryptographic >> mechanisms are validly terminated, according to the >> expectations of the cryptographic protocol(s) in use (e.g. >> TLS, IPsec). Changing the security properties of widely >> deployed cryptographic protocols is not likely to be a >> useful approach to attempt, as there are too many >> deleterious side-effects of such proposed changes." >> >> So I don't think, for the purposes of this exercise, >> we're considering existing widely deployed protocols as >> malleable building blocks, whether that protocol is >> TLS or some (deployed) train signalling system. >> >> Cheers, >> S. >> >=20 > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) >> sub RSA 4096/36CB8BB6 2017-12-22 >> >=20 >=20 >=20 >=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 >=20 --------------C20916BFF6EC90EF4FE22867 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------C20916BFF6EC90EF4FE22867-- --8DFszHmDSUM9b2H8Y4iU2G4vLrfG2QUhj-- --rdtr0Cl7sTrpaKKxkSDxvIXIPgwQbLbqN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4wjeAACgkQWrL68XsX K+o0thAAkTDAwfnDUlG1IsLnk3ARqE0zIH04NUZ9uN+z5dzmIR1jQqyBEk1S32HE cExHvoRCt8a2ElqXz+xzdK2J5TUQ/JiHcNCyS45X7KrV+ANZ+kRSv9oWd7HBkoUf 1/jLTO8T5ahjp1IaYPTUGGrrwNRmCLSbclD+j6EP97k0FHft4yIC6LxdVIHuJCkI oh37dqDPfSBvkN3zHDt83/Pf4t2B++zVcOeney+IKyASLjFs5zQECZWIDIYc2ZHd nDYJNoqGTI3Ja72mgnD1yeXxAGEDdvm3cu7hsWDTUpI4Vb141axS3bVY8u2pBzDq 7urDES09pypweceP1FlLTSPj6TK3miCbMo7KobBetLWBiXy04tdsa8UmrBccEs1P tK1H+pn2pXmQtK9TwmEudwtaKqhdPcUrHPLltX6IOxDQstIozSaK2jtBxmUmqG0C VjPY4Tdbw8lNLfp9PIhIvnniLc7h0Gwfkbr5wJ5jlLdcQsHtcT9AKcZ+Wke8z/0D CVrC9ZAGMVAfBagxovxCfZ6R6/SzkvUy1zBmSUMESAUqKJmBgunlWHb9GNZgvF9R SgLNsytGLRMyqjDbHaeYE6CL4SRMVmwJjh5r/W2VUnKoqWvdQ9wAYxJ11VX+Mj3w 3BznhmAZk++xp91k1muSF4jN+J7KX1/slCPR0XB9UMO/DIqv3xQ= =CH4V -----END PGP SIGNATURE----- --rdtr0Cl7sTrpaKKxkSDxvIXIPgwQbLbqN-- From nobody Tue Jan 28 11:58:24 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C18A12007C for ; Tue, 28 Jan 2020 11:58:22 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 pVyYP-NLkvOo for ; Tue, 28 Jan 2020 11:58: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 E0F2C12008C for ; Tue, 28 Jan 2020 11:58:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CED39BE39; Tue, 28 Jan 2020 19:40:06 +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 nY_tNlMAusRF; Tue, 28 Jan 2020 19:40:05 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 442C3BE2E; Tue, 28 Jan 2020 19:40:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1580240405; bh=pG1b8Du94+uuXokxWJ8jkQKZv1ag4EoCTNGQoyW7y68=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=0beyzcSSW1p3qysfdWgWYGPiPqF7gkbVZrPKP0ITfOe69aA0SnO8yzq+QUeOcnfHB bjm/3D3YKs6PDaa4nLQ0IkvQJ7fZ76C/eyi5EdLxQd+k0EIk+CP6/1XTaOpEpjZCZX lM1rZb97FxfJhMEDgB7+rIkDS4COpPkJI6v19IwE= From: Stephen Farrell To: Toerless Eckert Cc: Eliot Lear , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: <9aedcfe1-dec5-d999-a82f-2c8e21dae578@cs.tcd.ie> Date: Tue, 28 Jan 2020 19:40:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OZRC1pEGCirNLllBa69AS9z5M0rYkgjX1" Archived-At: Subject: Re: [arch-d] not building blocks (was: Re: [Model-t] Possible new IAB program on Internet trust model evolution) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 19:58:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OZRC1pEGCirNLllBa69AS9z5M0rYkgjX1 Content-Type: multipart/mixed; boundary="TnUzCaqXwwSNhTD7QMzB4blTaIjrBfRxW"; protected-headers="v1" From: Stephen Farrell To: Toerless Eckert Cc: Eliot Lear , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org Message-ID: <9aedcfe1-dec5-d999-a82f-2c8e21dae578@cs.tcd.ie> Subject: Re: [arch-d] not building blocks (was: Re: [Model-t] Possible new IAB program on Internet trust model evolution) References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> In-Reply-To: --TnUzCaqXwwSNhTD7QMzB4blTaIjrBfRxW Content-Type: multipart/mixed; boundary="------------E36D456075787F6C0247EB7D" Content-Language: en-US This is a multi-part message in MIME format. --------------E36D456075787F6C0247EB7D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28/01/2020 19:39, Stephen Farrell wrote: > Offlist for two reasons... oops, sorry all, but no major harm done S. --------------E36D456075787F6C0247EB7D 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------E36D456075787F6C0247EB7D-- --TnUzCaqXwwSNhTD7QMzB4blTaIjrBfRxW-- --OZRC1pEGCirNLllBa69AS9z5M0rYkgjX1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4wjhQACgkQWrL68XsX K+pDQxAAln7tgMRHdwko/G15eQSkYB9+bBA/+gmJHwbizvVeUn5dHdfzSaSUOXxz BVa0bs10cfEsVZrpwf3npBuB6rJf4BLP4x2UQH+NrcDOkmPWuvC/bb1RuJpRdae3 /tjcMtqLQ+gi4m7Mj6PCFQjZhFU6CgzXbjVLbtsG640bvGW3SBJCfe289Zjx2v2r UmTbFiDF3XYqd+tWXr+jnrwPVuFB5aQ9uW6a3deS8rK/94cmbHqRs2e2R9VRg71C drymhleC/PDJ8FifnIUkiCj4qqsQApwIu9mH505iJ06QPks8PQdBehoLAOb+97bM utwvr3Ptz3VUZkyHbpW+VyE5GLMjVkOvClwZDda6yktG+SFRtt3cbVgctKRgEbCQ ALjI5dGs0BlpANnpIkIV6W82Mgk+YmNT9lYxqI2L5T8f5JRkQl0sdxqdwDQ9l17V FVMYKpbphRmDoWauUDkV16SgeKzaaWxdlQxC7Gp1zbrCm1wJQiUv4R0FFjzWc6Ny R6znylaBH3wjC5yeROQzT133O4VmBouUZhBTlH8szD41a9n2VooFo8FvRb6XxRD2 sbZ2ZUiDfcfzeG4d7ScUR+tHYQEF4x3kT6wd3UunbjNjNNpqp9Hk8wquveHDpnUL /roTao7vYlY5nPOGvbpsa3hRe7pxdI1NYtqm4WD1fGEEurxBqCo= =whcO -----END PGP SIGNATURE----- --OZRC1pEGCirNLllBa69AS9z5M0rYkgjX1-- From nobody Tue Jan 28 12:12:07 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FAA1200B2; Tue, 28 Jan 2020 12:12:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=elandsys.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 jevY6aIVDPdO; Tue, 28 Jan 2020 12:12:04 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 776EE120099; Tue, 28 Jan 2020 12:12:04 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.75.85]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00SKBpsf022954 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jan 2020 12:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1580242323; x=1580328723; i=@elandsys.com; bh=IjnsAWJ9xe1yCMIBIK3V69nHQ6tQdUwakkqjgVhw9s0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=q9oyPVMQCfnLQOBSdimLzzeaM9h9++Nw5T8J/vXHGSA4+VqrQbrLfIbWgU1zlpTGo vN+wsdTmt5TLF4PWFE7qgr4KIk+mUTwomoIWvIHCTiDs1V7XZaqjF5fPvzL3KLFxAs C3GAdWy6P2mz/Uhgqtfgav+rbIYQT0QHh7mDB+YQ= Message-Id: <6.2.5.6.2.20200128115720.10bc9178@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Jan 2020 12:11:32 -0800 To: "Joel M. Halpern" , model-t@iab.org From: S Moonesamy Cc: architecture-discuss@ietf.org In-Reply-To: <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 20:12:05 -0000 Hi Joel, At 07:16 AM 28-01-2020, Joel M. Halpern wrote: >I am a bit concerned by the emphasis on what appear to be >application policy, business policy, or government policy. To the >degree that these are decoupled from the technology we define, my >impression is that the IETF is neither skilled at nor influential >with regard to these topics. We can spend a lot of time and energy >on them. They are interesting topics. But are they really our business? I'll reply to the question first. The answer is no. Application policy might be decoupled from, for example, regulations. However, regulations can have an impact on how the application works. I agree that the IETF is neither skilled nor does it have any influence on those topics. That is applicable if the intention of this (IAB) effort is to have something similar to what is done in an IETF WG. Regards, S. Moonesamy From nobody Tue Jan 28 12:53:11 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6691200B2 for ; Tue, 28 Jan 2020 12:53:06 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XD322-C035X for ; Tue, 28 Jan 2020 12:53:03 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986EC1200C3 for ; Tue, 28 Jan 2020 12:53:03 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id z64so11761809oia.4 for ; Tue, 28 Jan 2020 12:53:03 -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=+rh7/3QBdFMgeZ37UdrpO6c7ctzkJ6qWxCd485/gYog=; b=N2oaTB6OJoRz1tJZoZZNlixme6zCnSdKVlWp5clZfcKiSFDnif2Fpo+NTct0SjOii0 hL43JeSq4dFy2Cce/Kqj/Mm/DIeVKz2ebxzIJ07cciieTVaTwZUTOOKLCqtK/yJvqmQT PTmpKV5aJ3up7dH6VLiPZpLmJ8g7gId5fmZPPygn+WemLg8L36a/TQ7fX6wsff6YEDqG cnGqJj7a9hbhr95F7cGrfTy78qZD2EEb1fBWHHojPujcOUI6BHP3TaxCran/if9u87Sb p5vqxvPwWlZzJDql83YvyAC/pH/RnPSxI/gty0NU8YzHKAyGQTEe+CGGUlYKq+5HwGTV imDw== 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=+rh7/3QBdFMgeZ37UdrpO6c7ctzkJ6qWxCd485/gYog=; b=uGNNClzhb2pAARYcFVowC8MLb6SCXPYHiUbSg7DU2CisNqxYoAcZ2TwfKcjb9acrd4 NETAARtzGY/+Grh1fC5S9auS+OLhiymOf7P+1SQqzJGHNDB3ooqpBdLHsJFcq8NhEDkO pWqvOTA5drHKiJfQxwoROVlEVNpLPZFBprWIFbrGUwUk7kUp7W3Kocu23kHMDZ6kCqg4 7sksHhzZuPmxpusTGo6DJgNCatgXQhuQf/77eiB7NW33d2SpR6tGXWYtMN4V2jy54ysM B706jpgeN6MKFFiEftBEBjtYdxYfvDVRA+fWkUvolCxVDkP3unTXhZO1Cjq+LvNEmjHp A4HQ== X-Gm-Message-State: APjAAAXgMIsZvLkN955IXDOjqITAdB+E5rOhq5dnXH0HQ2eHNa659d11 MWvoP8k9kpRBVHM1DbK42ws+F2KwC/urXIfNlsY= X-Google-Smtp-Source: APXvYqwltWrsScejYSbI4Ky3lXg2Y2e7R65iNh4J1bFSmJTmac+lmYRq1P41Ci5JcWfb1BcqZewVnuATXGku7/EZtQY= X-Received: by 2002:aca:32c3:: with SMTP id y186mr4331228oiy.114.1580244782811; Tue, 28 Jan 2020 12:53:02 -0800 (PST) MIME-Version: 1.0 References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> <78E09CC1706F7D66D5F8DE1E@PSB> <9cec50fa-cb7c-ef75-95b3-c85f9f255c6d@cs.tcd.ie> In-Reply-To: <9cec50fa-cb7c-ef75-95b3-c85f9f255c6d@cs.tcd.ie> From: Kathleen Moriarty Date: Tue, 28 Jan 2020 15:52:26 -0500 Message-ID: To: Stephen Farrell Cc: John C Klensin , model-t@iab.org, architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000f00e41059d3968ea" Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet threat model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 20:53:06 -0000 --000000000000f00e41059d3968ea Content-Type: text/plain; charset="UTF-8" On Tue, Jan 28, 2020 at 2:33 PM Stephen Farrell wrote: > > John, Kathleen, > > Just on comments related to participation: "Participation > in this program is open to all interested parties, and > considered analysis of diverse inputs is important" is > what [1] already says. If you think some rewording is > needed be good to know what, or if it's just a case of > that text not having been noticed, then we're good I > guess. > That's very good, but I'm not sure how that community is feeling, it would be good to make sure they know their participation is welcome. Perhaps a message about this posted to SMART to redirect to this list would be helpful. Best regards, Kathleen > Cheers, > S. > > PS: I fixed the typo in the subject line that was my > fault in the first place:-) > > [1] > > https://github.com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md > -- Best regards, Kathleen --000000000000f00e41059d3968ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 28, 2020 at 2:33 PM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

John, Kathleen,

Just on comments related to participation: "Participation
in this program is open to all interested parties, and
considered analysis of diverse inputs is important" is
what [1] already says. If you think some rewording is
needed be good to know what, or if it's just a case of
that text not having been noticed, then we're good I
guess.

That's very good, but I'= m not sure how that community is feeling, it would be good to make sure the= y know their participation is welcome. Perhaps a message about this posted = to SMART to redirect to this list would be helpful.

Best regards,
Kathleen


Cheers,
S.

PS: I fixed the typo in the subject line that was my
fault in the first place:-)

[1]
https://github.com/= intarchboard/model-t-charter/blob/master/model-t-charter-00.md


--

Best regards,
Kathleen
--000000000000f00e41059d3968ea-- From nobody Tue Jan 28 14:50:27 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC6D1200FE for ; Tue, 28 Jan 2020 14:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 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, HK_SCAM=1.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 mwJ5ZcdIMnvO for ; Tue, 28 Jan 2020 14:50:20 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 DA53912006D for ; Tue, 28 Jan 2020 14:50:19 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id k188so9223746vsc.8 for ; Tue, 28 Jan 2020 14:50:19 -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=pvZ1P5DZNl1I9cVSXz4OEbwS0CK10QqOU/MyprSpfSA=; b=idVaEIYwCtUg1Cq3IaU1ex6DUwo+/gI57FOD6vuGMMvPnXEYJFW3MeueAkglO8y/Mb 8donCNSQ1UbliZ91y4GrNFBDTcReNtYyx6MiQDy8T8OHo26xpSJ10fY+g97x1WsNUNgn zeVtrZMjBQzV3O7mEjWN27yOe6X6GZW2JC1lidz5oltYj8n+GRBlYoy8HRwaeSaYMOJA TwKW4jtSIJbxnBeLCwlpBw68Ysc+W2mLK680Z+e2YEjTXthYjnCe3wb18va9fAkGNGPZ 79eKcXnol337O4mGevyqwSwi1qRVHS4r8/O3GV/S2hOpEPibAR/gYEHGSSnM7NVvWOnb AZ2g== 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=pvZ1P5DZNl1I9cVSXz4OEbwS0CK10QqOU/MyprSpfSA=; b=Smuqus3fFp7ZDL9jg1oRvZZQGe4o46+IMSDX6wQiB7S5kDJY0Y2kwIQeXYUiH0QHwR K8SlmoXQeRhTK04GdjhhmrEjzGxH96BZhMTtLo7heZCmsCCkMk9zSzFMcQO/buzTi7mm HI5birT74JbLjs/ouP6Skr/ZJZG+7rEWGioglj73v/9XFsMY9W9wilexNnITETWy0RDo bbhwpmSn5xf+il7hBRmYoSmTDsTtd7EE2ClHQbe/5r+XaLl2YbkJ3pEVL+T6mMnaAqeA avuZ9CfqX2pvGKr19+KOQdLWMudDl/mWBfxzKlA/zRJRyur0EDqPwvPBAAMjZvdYiNwj k1Iw== X-Gm-Message-State: APjAAAWQLPmIpTLUt6J+BY9UFNpNQ0gcDP1mW86g0eKPwfVnytv4SJAV uCUxjan2A8fsrskG1CKid9qucvNMlY4uR44975vrjStO X-Google-Smtp-Source: APXvYqyQNVpMsiVqbSKLjy6pBtaR3jEFUoLdnRj7mdc/TDbyetrSHiA3UvZX7c58hCRTb2nalJYVRFEwB9zCeiDsrV0= X-Received: by 2002:a67:f1ca:: with SMTP id v10mr15299209vsm.180.1580251818630; Tue, 28 Jan 2020 14:50:18 -0800 (PST) MIME-Version: 1.0 References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> In-Reply-To: From: Bernard Aboba Date: Tue, 28 Jan 2020 14:50:08 -0800 Message-ID: To: Eliot Lear Cc: architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="0000000000004e21b9059d3b0c86" Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 22:50:22 -0000 --0000000000004e21b9059d3b0c86 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eliot -- The examples you describe are difficult to capture within protocol-specific threat models (RFC 3552) or privacy considerations (RFC 6973). For practicality, those analyses need to maintain a narrow focus, yet at the same time we understand that systemic privacy and security issues can only be understood when analyzing the system that a protocol is embedded in. As a result, even protocols that successfully address the original threat models can be the source of major systemic vulnerabilities. For example, we could not have expected the authors of RFC 1945 (HTTP 1.0) to have anticipated the security and privacy problems arising from today's social media implementations - some of which were discussed during the Internet Privacy Workshop summarized in RFC 6462. However, I do think that you're on to something important that is worth IAB consideration. It strikes me that in a number of the examples you cite the "endpoint" is not acting in the interest of the "end user", at least in the sense described in draft-iab-for-the-users. As was noted in Section 4.2: In contrast, the Internet of Things (IoT) has not yet seen the emergence of a natural role for representing the needs of the end user. Perhaps as a result of this, that ecosystem and its users face serious challenges. For example, consider how some of the IoT behavior you describe might be handled within a permission model implemented in a browser or a mobile device: 1. Would a user grant permission to access to camera or microphone? In the example of the device that did not advertise that it contained a microphone, presumably, the answer would be "no" (although the microphone was not initially enabled so perhaps permission might not have been requested). 2. Would the user grant permission to access personal information such as location? In the example of the device with embedded trackers, again the user would probably not have granted access to location and other data (although we know that location can easily be obtained in circumvention of browser or mobile device protections). On Mon, Jan 27, 2020 at 10:44 PM Eliot Lear wrote: > Hi Watson, > > On 28 Jan 2020, at 02:35, Watson Ladd wrote: > > > > On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear wrote: > >> Let=E2=80=99s look at three specific examples that I=E2=80=99ve mentio= ned: >> >> 1. Train signaling system needs to be audited both live and >> retrospectively in the case of accidents. This has to happen in such a = way >> that the auditor sees precisely what was sent by one endpoint and receiv= ed >> by the other. >> >> 2. The case of =E2=80=9Cparent doesn=E2=80=99t want Internet toy to sen= d video of >> child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s an analog t= o the privacy >> analysis on Alexa[1] and the now infamous NEST episode[2]). >> >> 3. CPAP machine or an AED/pace maker provide a control interface to the >> doctor but the patient or his next of kin wants the data. >> > > I've got a few more examples from real life: > > 4: We need to see who is sending pictures of Winnie the Pooh. > > 5: We don't want pictures of the inside of our detention centers to appea= r > online. > > 6: I want to see everyone's credit card number at the coffee shop I run. > > Any discussion of tapping network communications because endpoints can't > be trusted needs to take these cases seriously. > > > > Absolutely. What I am suggesting is a relatively new twist on an old > problem(*). It=E2=80=99s important to understand the economic and policy= aspects > of how/whether to avoid [4] and [5], how to avoid [6] while at the same > time addressing use cases I mentioned. > > So=E2=80=A6 today=E2=80=99s new information comes courtesy of the EFF. > > > https://www.eff.org/deeplinks/2020/01/ring-doorbell-app-packed-third-part= y-trackers > > Here we have yet another IoT device that, from at least one person=E2=80= =99s > perspective is invading home privacy. And again, it is the device itself > that is the threat. In this case, it=E2=80=99s probably a more manageabl= e threat, > because one can simply not get a NEST. Try not getting a CPAP machine. > > And this brings us around to what layer to solve the problem at. Some of > this may need to be dealt with at layer 9 rather than at lower layers. W= e > should have that discussion too. > > > > Increasingly corporate networks are moving away from network layer access > controls and using user authentication over TLS, so-called BeyondCorp > model, including checking endpoint posture through management. > > > I don=E2=80=99t think this solves the railroad case. Do you? Just to cl= arify the > example: > > According to their logs, two separate signals received =E2=80=9Cset your= lights > to green=E2=80=9D at the same time, causing two trains to crash into each= other. > According to the signal controller=E2=80=99s logs, it sent =E2=80=9Cset y= our lights to > green=E2=80=9D to only one signal. What happened? > > All of the cases we are discussing have slightly different flavors of > threats. From an IAB program standpoint, the real question here is this: > what are the architectural building blocks that are required? Keep in > mind, some of those blocks could be code and some could be policy. > > One goal should be code reuse. It is probably best that the people > building the train signal *not* reinvent everything, but rather benefit > as much as they can from the experience and results that you, EKR, and a > great many other people have brought to society. > > Eliot > > (*) It=E2=80=99s also important to not fall into old tribal communication > patterns, while recognizing the realities of the concerns raised by you, > Watson, and me. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000004e21b9059d3b0c86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eliot --

The examples = you describe are difficult to capture within protocol-specific threat model= s (RFC 3552) or privacy considerations (RFC 6973).=C2=A0 For practicality, = those analyses need to maintain a narrow focus, yet at the same time we und= erstand that systemic privacy and security issues can only be understood wh= en analyzing the system that a protocol is embedded in.=C2=A0 As a result, = even protocols that successfully=C2=A0address the original threat models ca= n be the source=C2=A0of major systemic vulnerabilities. For example, we cou= ld not have expected the authors of RFC 1945 (HTTP 1.0) to have anticipated= the security and privacy problems arising from today's social media im= plementations - some of which were discussed during the Internet Privacy Wo= rkshop summarized in RFC 6462.=C2=A0

However, I do= think that you're on to something important that is worth IAB consider= ation.=C2=A0

It strikes me that in a number of the= examples you cite the "endpoint" is not acting in the interest o= f the "end user", at least in the sense described in draft-iab-fo= r-the-users.=C2=A0 As was noted in Section 4.2:

In contrast, the Inter= net of Things (IoT) has not yet seen the emergence of a natural role for representing the needs of the end user. Perhaps as a result of this, that ecosystem and its users face serious challenges.

For example, consider= how some of the IoT behavior you describe might be handled within a permis= sion model implemented in a browser or a mobile device:=C2=A0

1. Would a user grant permission to access to camera o= r microphone?=C2=A0 =C2=A0In the example of the device that did not adverti= se that it contained a microphone, presumably, the answer would be "no= " (although the microphone was not initially enabled so perhaps permis= sion might not have been requested).=C2=A0
2. Would=C2=A0the user= grant=C2=A0permission to access personal information such as location?=C2= =A0 In the example of the device with embedded trackers, again the user wou= ld probably not have granted access to location and other data (although we= know that location can easily be obtained in circumvention of browser or m= obile device protections).


On Mon, Jan 27, = 2020 at 10:44 PM Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:
Hi Watson,

On 28 Jan 2020, at= 02:35, Watson Ladd <watsonbladd@gmail.com> wrote:


I've got a few more examples from real life:




So=E2=80=A6 today=E2=80=99s new information comes courtesy= of the EFF.


Here we have yet another IoT device= that, from at least one person=E2=80=99s perspective is invading home priv= acy.=C2=A0 And again, it is the device itself that is the threat.=C2=A0 In = this case, it=E2=80=99s probably a more manageable threat, because one can = simply not get a NEST.=C2=A0 Try not getting a CPAP machine.

=
And this brings us around to what layer to solve the problem at.= =C2=A0 Some of this may need to be dealt with at layer 9 rather than at low= er layers.=C2=A0 We should have that discussion too.



Increasingly corporate = networks are moving away from network layer access controls and using user = authentication over TLS, so-called BeyondCorp model, including checking end= point posture through management.

I don=E2=80=99t think this solves the railroad case.=C2=A0 Do you?=C2= =A0 Just to clarify the example:

According to thei= r logs, two separate signals received =C2=A0=E2=80=9Cset your lights to gre= en=E2=80=9D at the same time, causing two trains to crash into each other.= =C2=A0 According to the signal controller=E2=80=99s logs, it sent =E2=80=9C= set your lights to green=E2=80=9D to only one signal.=C2=A0 What happened?<= /div>

All of the cases we are discussing have slightly d= ifferent flavors of threats.=C2=A0 From an IAB program standpoint, the real= question here is this: what are the architectural building blocks that are= required?=C2=A0 Keep in mind, some of those blocks could be code and some = could be policy.

One goal should be code reuse. It= is probably best that the people building the train signal not rein= vent everything, but rather benefit as much as they can from the experience= and results that you, EKR, and a great many other people have brought to s= ociety.

Eliot

(*) It=E2= =80=99s also important to not fall into old tribal communication patterns, = while recognizing the realities of the concerns raised by you, Watson, and = me.

_____________________________________________= __
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000004e21b9059d3b0c86-- From nobody Wed Jan 29 01:38:01 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E94112026E for ; Wed, 29 Jan 2020 01:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 39pnmwPr5PsU for ; Wed, 29 Jan 2020 01:37:59 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 1CE38120130 for ; Wed, 29 Jan 2020 01:37:59 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id p8so14903204oth.10 for ; Wed, 29 Jan 2020 01:37:59 -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=RlKAVd5i/2ssK5BBxofZvXKR1DcG9DU7mi653M5lpO0=; b=fD5wyBmaKYo7er7YMazJU5PYX+lGGfRknWHJ8mno9tVKeEHqEFckL94RO5PamxfP62 V4SjpWHFm+VbP4drM/VXBcx1XdV6qLS8qtrK7uGiqxrE7OB+i13kX5MhAkvzu/yR9PYT C/x8l8SCaCv5Quu3XS++PslYAWIyCgTNx+q7csEp+6oknXyDpQiBPbhz5NB9D1DIOlL3 D7yjIkZLECbE/vg3AOCvWNcecbEk+Kq0w9APgrBvKUoOxY3HE6wyTa6Uuvzv46xwNmot PTZOYvtXIP1Otp6FLB8SyYagcy9o+0c7fFt45K/+sK6VAoLNT7ygdnbprVHiPGpdQe+L ZQ8A== 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=RlKAVd5i/2ssK5BBxofZvXKR1DcG9DU7mi653M5lpO0=; b=ufWi3tfI5lOjt5Ngvaf1p0EFP1Te14aJUgAcP9f20GfAkpzVsH34BIo7TKOfxkEmpk gjVi2X+FkL4esfggofv+qp19SYTIhpwwHW0DAmFxasTNUlHlH/6RSrpUcItccs/VRAoS WtglSvAeC6mFBgrMNahokviOlnhrol2viV6rSzsYwR16Kx6+XzSY4+LbRTN2FI45m1jk Dm/gcCOHAnsYRRrXEUm6M+lUyIl0UNZSRXtPpC/khZ6KaUCLJXddByQ6BEqEq9C97v2I M7+edSCqoCpkomst5EUgEJrjkQpeZ2cYMZ5WkEFU0QzmRT5erHRJe/BIjl7lOusne4SD N8DQ== X-Gm-Message-State: APjAAAXXDHnYCSRV1MI60EN2cey9Bem49sAEw5YGocSJoqmHJYuGY7UN fL+OiaX865oJ7g4ECVq3AUq1LsRqirXDapJMMs2E5w== X-Google-Smtp-Source: APXvYqzx3b5cH36KxU0eRFSrss+dikpEmJ/z6TDomIKzNQ/XrIzcp9lxdnul3mDkwZBJRrjwbzHEfLVeqdx+0qeo0QM= X-Received: by 2002:a9d:831:: with SMTP id 46mr8250833oty.295.1580290678296; Wed, 29 Jan 2020 01:37:58 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Wed, 29 Jan 2020 01:37:57 -0800 (PST) From: Guntur Wiseno Putra Date: Wed, 29 Jan 2020 16:37:57 +0700 Message-ID: To: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000008593bb059d441836" Archived-At: Subject: [arch-d] Network Architecture in the Internet Society X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 09:38:01 -0000 --0000000000008593bb059d441836 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, Documents related with the current issues on "consolidation of the Internet" saved in the "Open Forum" community of the Internet Society: https://connect.internetsociety.org/viewdocument/consolidation-of-the-internet-from?CommunityKey=3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=librarydocuments#ItemCommentPanel Regard, Guntur Wiseno Putra --0000000000008593bb059d441836 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

Documents related with the cu= rrent issues on "consolidation of the Internet" saved in the &quo= t;Open Forum" community of the Internet Society:

<= div>

Regard,
Guntur W= iseno Putra
--0000000000008593bb059d441836-- From nobody Wed Jan 29 01:48:41 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7380F12026E for ; Wed, 29 Jan 2020 01:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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, 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 efKmXHgqHOuF for ; Wed, 29 Jan 2020 01:48:36 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEEEB12081F for ; Wed, 29 Jan 2020 01:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9988; q=dns/txt; s=iport; t=1580291316; x=1581500916; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=afumTtU1ff+fMfKCgGo7KUZObPySDVgTD0fuDqnYhzc=; b=VVsduxouV7rPicGLwyuIpuvTxRqEYgWL8DEgC99QbGhQTLvOqJqKmAfi TMQsX4yXLWg3u9YydgcDwbVdipO2wQ0uV7rVlY3Z2J7UZ5wguXzW8VvOk Q6de/6z+0VCbbhvfHlU7rJ9pvKp0qL3BYja8+9GZo416SvU+7TCxI0MYH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrGACNVDFe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXsCgSOBcFQBIBIqhBSJA4d0JYlhiUyGEYF6CQEBAQwBAS8BAYR?= =?us-ascii?q?AAoJMOwMNAgMNAQEEAQEBAgEFBG2FQ4VeAQEBAQIBI1YFCwsYKgICITYGExQ?= =?us-ascii?q?HgwsBgkoDDiCrXnWBMoVKgk8NgiCBOAGMOYIAgTgMFIIeLj6CG4U+MoIsBI1?= =?us-ascii?q?YATKSGY4+MkSCQ4JMj0KEKRuWOoRFmWiMV4MuAgQGBQIVgXwDDIFYMxoIGxV?= =?us-ascii?q?lAYJBPhIYDY4pFxWOD0ADMI5HAQE?= X-IronPort-AV: E=Sophos; i="5.70,377,1574121600"; d="scan'208,217"; a="22732074" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jan 2020 09:48:33 +0000 Received: from ams3-vpn-dhcp4134.cisco.com (ams3-vpn-dhcp4134.cisco.com [10.61.80.37]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00T9mW5M019746 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Jan 2020 09:48:33 GMT From: Eliot Lear Message-Id: <16390A67-B502-4278-B93E-2642025F356D@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E6E548D7-8843-48BF-88A9-1E7BB8B41791" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Wed, 29 Jan 2020 10:48:32 +0100 In-Reply-To: Cc: architecture-discuss@ietf.org, model-t@iab.org, Toerless Eckert To: Bernard Aboba References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.80.37, ams3-vpn-dhcp4134.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 09:48:38 -0000 --Apple-Mail=_E6E548D7-8843-48BF-88A9-1E7BB8B41791 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bernard and thanks for your valuable thoughts. > On 28 Jan 2020, at 23:50, Bernard Aboba = wrote: >=20 > Eliot -- >=20 > The examples you describe are difficult to capture within = protocol-specific threat models (RFC 3552) or privacy considerations = (RFC 6973). For practicality, those analyses need to maintain a narrow = focus, yet at the same time we understand that systemic privacy and = security issues can only be understood when analyzing the system that a = protocol is embedded in. As a result, even protocols that successfully = address the original threat models can be the source of major systemic = vulnerabilities. For example, we could not have expected the authors of = RFC 1945 (HTTP 1.0) to have anticipated the security and privacy = problems arising from today's social media implementations - some of = which were discussed during the Internet Privacy Workshop summarized in = RFC 6462.=20 I really cannot say what, if any, protocol changes I would suggest at = this point to handle some of the cases I mentioned. Assuming there is = interest in this approach, I would suggest a bit of a collection and a = culling. I want to address one related point: Joel doesn=E2=80=99t think the = program should get up into layer 9 too much, and I would say that it = would be necessary to do so to figure out where we as a community want = to make some Lessiguesque law, and when perhaps we need to leave that to = others, but see below. >=20 > However, I do think that you're on to something important that is = worth IAB consideration.=20 >=20 > It strikes me that in a number of the examples you cite the "endpoint" = is not acting in the interest of the "end user", at least in the sense = described in draft-iab-for-the-users. As was noted in Section 4.2: >=20 > In contrast, the Internet of Things (IoT) has not yet seen the > emergence of a natural role for representing the needs of the end > user. Perhaps as a result of this, that ecosystem and its users = face > serious challenges. >=20 > For example, consider how some of the IoT behavior you describe might = be handled within a permission model implemented in a browser or a = mobile device:=20 >=20 > 1. Would a user grant permission to access to camera or microphone? = In the example of the device that did not advertise that it contained a = microphone, presumably, the answer would be "no" (although the = microphone was not initially enabled so perhaps permission might not = have been requested).=20 > 2. Would the user grant permission to access personal information such = as location? In the example of the device with embedded trackers, again = the user would probably not have granted access to location and other = data (although we know that location can easily be obtained in = circumvention of browser or mobile device protections). >=20 Very well put. I think that leads us into a bit of futuristic scenario planning about = how that permission model would work, what the control points are, then = how they interact, etc. The L9 discussions come in the form, I think, = of incentive modeling to address the for-the-users point. But that=E2=80=99= s for later. For now, what are the problems? To Toerless=E2=80=99 point: > Yes, i think we can agree that we would like all Internet end-to-end > transport must not even allow for a misconfigured option to use null > encryption, but i think when TLS 1.3 was standardized, there should = have > been a better solution than to completely oppress the needs of those > other use-cases. And my suggestion is that we take three steps back before we even go = there. Let=E2=80=99s not treat this like an IETF working group, but = pause and take deep breaths and work the problem space just a bit. Eliot --Apple-Mail=_E6E548D7-8843-48BF-88A9-1E7BB8B41791 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Bernard and thanks for your valuable thoughts.

On 28 = Jan 2020, at 23:50, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Eliot = --

The examples you = describe are difficult to capture within protocol-specific threat models = (RFC 3552) or privacy considerations (RFC 6973).  For practicality, = those analyses need to maintain a narrow focus, yet at the same time we = understand that systemic privacy and security issues can only be = understood when analyzing the system that a protocol is embedded = in.  As a result, even protocols that successfully address the = original threat models can be the source of major systemic = vulnerabilities. For example, we could not have expected the authors of = RFC 1945 (HTTP 1.0) to have anticipated the security and privacy = problems arising from today's social media implementations - some of = which were discussed during the Internet Privacy Workshop summarized in = RFC 6462. 

I really cannot say what, if any, protocol changes I = would suggest at this point to handle some of the cases I mentioned. =  Assuming there is interest in this approach, I would suggest a bit = of a collection and a culling.

I = want to address one related point: Joel doesn=E2=80=99t think the = program should get up into layer 9 too much, and I would say that it = would be necessary to do so to figure out where we as a community want = to make some Lessiguesque law, and when perhaps we need to leave that to = others, but see below.


However, = I do think that you're on to something important that is worth IAB = consideration. 

It strikes me that in a number of the examples you cite the = "endpoint" is not acting in the interest of the "end user", at least in = the sense described in draft-iab-for-the-users.  As was noted in = Section 4.2:

   In =
contrast, the Internet of Things (IoT) has not yet seen the
   emergence of a natural role for representing the needs of the end
   user.  Perhaps as a result of this, that ecosystem and its users face
   serious challenges.

For example, consider how some of the = IoT behavior you describe might be handled within a permission model = implemented in a browser or a mobile device: 

1. Would a user grant permission to access to camera or = microphone?   In the example of the device that did not = advertise that it contained a microphone, presumably, the answer would = be "no" (although the microphone was not initially enabled so perhaps = permission might not have been requested). 
2. = Would the user grant permission to access personal information = such as location?  In the example of the device with embedded = trackers, again the user would probably not have granted access to = location and other data (although we know that location can easily be = obtained in circumvention of browser or mobile device = protections).



Very well = put.

I think that leads us into a = bit of futuristic scenario planning about how that permission model = would work, what the control points are, then how = they interact, etc.  The L9 discussions come in the form, I = think, of incentive modeling to address the for-the-users point. =  But that=E2=80=99s for later.  For now, what are the = problems?

To Toerless=E2=80=99 = point:

Yes, i think we can agree that we would like all Internet = end-to-end
transport must not even allow for a = misconfigured option to use null
encryption, but i think = when TLS 1.3 was standardized, there should have
been a = better solution than to completely oppress the needs of those
other use-cases.

And my = suggestion is that we take three steps back before we even go there. =  Let=E2=80=99s not treat this like an IETF working group, but pause = and take deep breaths and work the problem space just a = bit.

Eliot

= --Apple-Mail=_E6E548D7-8843-48BF-88A9-1E7BB8B41791-- From nobody Wed Jan 29 09:48:17 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4477012011B for ; Wed, 29 Jan 2020 09:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 MN1gjx7xeLdO for ; Wed, 29 Jan 2020 09:48:09 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 893271200F7 for ; Wed, 29 Jan 2020 09:48:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4A22B6601DF; Wed, 29 Jan 2020 19:48:07 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJioIbG64MsG; Wed, 29 Jan 2020 19:48:06 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id AFC78660135; Wed, 29 Jan 2020 19:48:05 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Wed, 29 Jan 2020 18:48:04 +0100 Cc: model-t@iab.org, architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 17:48:13 -0000 Brian, > I really do not want to see the pragmatic purpose of RFC3552 lost in = the > effort to define these abstractions. I don't think that is the = intention, > but the text seems to imply that RFC3552 was mainly a description of a > generic threat model, which it wasn=E2=80=99t. I agree of course. This is a small part of 3552. We are only considering trends in the world that may affect that small part. > Incidentally, while writing the above it occurred to me why the phrase > "IAB program" has always slightly disturbed me. Really the proposal is > a virtual IAB workshop (whereas RFC2316 came from three days in a room > together in Murray Hill, NJ). A good idea, but not a program. Perhaps, but it is worth stating that at least from my perspective the concept of an IAB program has differed depending on the topic at hand, and perhaps more importantly, has evolved over time. Right now the topics under consideration are mostly entirely open. This is fitting for = the two topics that we have brought up, but it is also at least in my = impression a shift in thinking, for openness obviously but also maybe bit of short = term goal of addressing a specific issue vs. very long-running programs. The experiences from the latter haven=E2=80=99t always been promising. Jari From nobody Wed Jan 29 09:59:50 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BDA1208C9 for ; Wed, 29 Jan 2020 09:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 GMKSkflp8DRu for ; Wed, 29 Jan 2020 09:59:43 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 877A0120837 for ; Wed, 29 Jan 2020 09:59:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D34DB6601DF; Wed, 29 Jan 2020 19:59:42 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c17HkwnHBIeu; Wed, 29 Jan 2020 19:59:40 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 6667E660135; Wed, 29 Jan 2020 19:59:40 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <16390A67-B502-4278-B93E-2642025F356D@cisco.com> Date: Wed, 29 Jan 2020 18:59:39 +0100 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <385267B3-5524-44A1-825B-EC5AD22EE8E0@piuha.net> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <16390A67-B502-4278-B93E-2642025F356D@cisco.com> To: model-t@iab.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 17:59:47 -0000 It occurs to me that Stephen and I made some assumptions that were not = made explicit, and this has lead to some of the questions we=E2=80=99ve = received. Perhaps it would be useful to be more explicit. In particular, = we really want to extend the threat model, not take away anything that = already exists, or start to reconsider the hugely important role of = comsec.=20 Maybe this change would better describe the scope: OLD: The model-t program provides an open venue for analysis of the Internet threat model and has as a goal to produce a potential update to BCP72 that defines an Internet threat model that better matches today's reality. NEW: The model-t program provides an open venue for analysis of the Internet threat model and has as a goal to produce a potential update to BCP72 that defines an Internet threat model that better matches today's reality. Specifically, the intent is to document why an update = is needed and provide a suggested update that could be considered by the IETF. A potential BCP72 update would likely extend the set of threats considered. Reducing the protection offered by current comsec mechanisms is a non-goal. Similarly, re-consideration of the parts of BCP72 that are outside the very narrow part on Internet threat model is not in scope. Jari From nobody Wed Jan 29 11:14:44 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DF3120953 for ; Wed, 29 Jan 2020 11:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 LtLdfpYFkAfo for ; Wed, 29 Jan 2020 11:14:36 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF6712095C for ; Wed, 29 Jan 2020 11:14:34 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B044C548005; Wed, 29 Jan 2020 20:14:28 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A7859440059; Wed, 29 Jan 2020 20:14:28 +0100 (CET) Date: Wed, 29 Jan 2020 20:14:28 +0100 From: Toerless Eckert To: Jari Arkko Cc: model-t@iab.org, architecture-discuss@ietf.org Message-ID: <20200129191428.GT14549@faui48f.informatik.uni-erlangen.de> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <16390A67-B502-4278-B93E-2642025F356D@cisco.com> <385267B3-5524-44A1-825B-EC5AD22EE8E0@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <385267B3-5524-44A1-825B-EC5AD22EE8E0@piuha.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 19:14:39 -0000 Thanks, Jari Now i read from the text you a) want more security not less, but that you b) do not want to expand the scope outside the Internet thread model, which i read from BCP72 section 3/3.1 as being about secure point to point transport connections (*), maybe with secure discovery/naming of the peer, but not including any multi-hop transitive security of distributed applications such as web-proxies. Right ? section 3.1 doesn't really shine on defining a clear model to scope the Internet thread model. How about the transitive security of systems like DNS or BGP ? And if thats in scope, then why not web proxies or other distributed applications ? (there are feasible answers, but those answers would have to be part of a BCP72bis better explanation of the thread model, and if the answers are as i think, then so too would be security considerations of SDN controllers). I think the charter scope you would like to see would be easier explained by providing also two examples: something in-scope and missing in BCP72, and an example that just barely is outside the scope of your intended charter. Cheers Toerless On Wed, Jan 29, 2020 at 06:59:39PM +0100, Jari Arkko wrote: > It occurs to me that Stephen and I made some assumptions that were not made explicit, and this has lead to some of the questions we???ve received. Perhaps it would be useful to be more explicit. In particular, we really want to extend the threat model, not take away anything that already exists, or start to reconsider the hugely important role of comsec. > > Maybe this change would better describe the scope: > > OLD: > > The model-t program provides an open venue for analysis of the > Internet threat model and has as a goal to produce a potential update > to BCP72 that defines an Internet threat model that better matches > today's reality. > > NEW: > > The model-t program provides an open venue for analysis of the > Internet threat model and has as a goal to produce a potential update > to BCP72 that defines an Internet threat model that better matches > today's reality. Specifically, the intent is to document why an update is > needed and provide a suggested update that could be considered by the > IETF. A potential BCP72 update would likely extend the set of threats > considered. Reducing the protection offered by current comsec > mechanisms is a non-goal. Similarly, re-consideration of the parts > of BCP72 that are outside the very narrow part on Internet threat > model is not in scope. > > Jari > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Wed Jan 29 13:17:51 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263A9120047 for ; Wed, 29 Jan 2020 13:17:46 -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, 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 (1024-bit key) header.d=isoc.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9IcauEx721I for ; Wed, 29 Jan 2020 13:17:40 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::627]) (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 697C2120045 for ; Wed, 29 Jan 2020 13:17:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MdKzXCLpwTW3rcEyQfENAKsUNcmRaxX2Vu4IXB1IxUXwryE4vL/n5dr/ju42iKnQgjDQ4x3hh/uUZBZxg7FnYJDRFH8CXauwGdkimEjbem6E0/7ERa0+pTO0K7Cd0+ZBGtO4sTXynINfD+lR/NO1SwkMwDnB+ds/KUmrR4WEeTlH+gq+1x2NDFb9ZSnve3TznFEOmCAL0dSDr4y64vEKQiTQxhPKcNmfY8mtKCswSS1PVEmIDJAUlwr9rDIDAWclN9etUY9tg8O+yX9CHIzP1eLBUxWc8H6wW6tM3vI34nCsdVI+fgtOYelBSoaxLSc9AMJX65OGoGw4THAUVOlP2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+R4UbNOEb9SCinrTMmtEyg12OOrsLSB9AIjuEmf+CLQ=; b=YEwdx/szug7WTVEuun7bxTQ3PfLPwNhh+GlxnFm1TDXJj5zBs9l3OdiU8twC8Aa+mnag6vi7esdI0NbYM0HWBAxueFuSu9Qp0JT/vkRnpvEy4kZ8//VH/7lBAZBCPsbloNwWyPkvF9eIAiFTdBTMKPss897Lulwxdonbp5GTVb6BxBYpmm7S/btoCNDnQcDpyMKG44zyxJxUfvZdwXmcs2Sirj8evp8eNUFZgUE8kqPF4FIuE8fAL5SYdW4AmZU9lTK+2r4xN2huQBW3GaSBdchZjxEkXhLmxKRRJA1jivtXDOJkrYbmPFCUtOZl+oOqN0ItRRNk7lGnhMhoBdlsTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+R4UbNOEb9SCinrTMmtEyg12OOrsLSB9AIjuEmf+CLQ=; b=s5ddc7E6yBu+UwhEVnsXdbxgYcuLZraCved0CFQxcZkQuPctXezmtLC7cXHEtanO750RxuFhCU4MXhgKyFtKnZcaJrM0f9Wpu9NJw1BEjChWSQDtL2ceqly0Z4ALeOMQ5wXtWBZvO3ktyVBrvXKvSJ28qxS0IuvrzgOFSvxzqJk= Received: from BL0PR06MB4772.namprd06.prod.outlook.com (52.132.0.222) by BL0PR06MB4914.namprd06.prod.outlook.com (10.167.240.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.26; Wed, 29 Jan 2020 21:17:38 +0000 Received: from BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::bcb1:34ae:3c82:185c]) by BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::bcb1:34ae:3c82:185c%6]) with mapi id 15.20.2665.026; Wed, 29 Jan 2020 21:17:38 +0000 From: Robin Wilton To: Eliot Lear , Bernard Aboba CC: "architecture-discuss@ietf.org" , "model-t@iab.org" , Toerless Eckert Thread-Topic: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution Thread-Index: AQHV1thkVQ/MZmJpQkC8KjQJYwIVSqgCJFli Date: Wed, 29 Jan 2020 21:17:38 +0000 Message-ID: References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> , <16390A67-B502-4278-B93E-2642025F356D@cisco.com> In-Reply-To: <16390A67-B502-4278-B93E-2642025F356D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-originating-ip: [95.175.104.159] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9e33f99b-01fe-4ab0-faa1-08d7a500ab04 x-ms-traffictypediagnostic: BL0PR06MB4914: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(199004)(189003)(33656002)(5660300002)(7696005)(498600001)(66574012)(76116006)(91956017)(66476007)(26005)(186003)(9686003)(55016002)(66446008)(2906002)(64756008)(66556008)(66946007)(8676002)(6506007)(71200400001)(81156014)(81166006)(53546011)(8936002)(54906003)(110136005)(52536014)(86362001)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR06MB4914; H:BL0PR06MB4772.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YFc+X9c6hTTqGQ+zd/XU/G5vltjTPlanvAVQVNzbBKIRjeV3fGGfOGSdIK8B8bQsVaPLPB3gJG4EqtbKSG+JNGgp/ury/M6P9UqOud11vriyCaWXXsC7li4A3Xvece9Sh5mifoWv8A3ld1tXgFemQbDjcNtLiptY/F1MR+gVCUF4fBrBIMM4RdYLNBkfzFC3gs2Za7w7wMI17qPgHN9j7/b38+OryZPpE1rSnpFQkPqUzffz3cGERVB/B9Qt/Edx+KFuJvslu0AVQrLI/TiV4ZC03VnqZDFk6h88O3q2M/iu7qj+/NBwcf1LEqJpNbHp9tWGajw+/A12BX8+Af3EMc7EYhFTjiOEdkxARCBlnwrFDwoMvMLiuz7uJQlJuLW2NpdX6+5jVo7W9wbYGgdNo/G3VwmoIpSk/1b4J958atwdcYw7RAfy5CumEhcn4Q/5 x-ms-exchange-antispam-messagedata: 4bKvFSBJ1pvZjYcm4IEq6aQ0VJKZf0+5EgORHHWw/GY8opyUD+cQwwz3lWZzLhy89DLmaKakfkCD30fwrxnTgitGPcurCVat7zzvwciHvnN56Yp3CDeIx9NeZvQ2nxekvx5cdzfi/4/YsGPszXNp6g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR06MB4772046AA2FD38C48F5C75BBBF050BL0PR06MB4772namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 9e33f99b-01fe-4ab0-faa1-08d7a500ab04 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 21:17:38.3658 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nv9bTGDUo3vovCjTC0g7P6S6hMK1fomBlNoB5LjE/wX3IXGN7M1YAIiqRWsBZT61 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4914 Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 21:17:46 -0000 --_000_BL0PR06MB4772046AA2FD38C48F5C75BBBF050BL0PR06MB4772namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks, both. As I read your comments, one phrase kept presenting itself to= me... =93user agency=94. What is it, in the system, that is giving effect to the = user=92s intention and preferences. I=92m not even going to try and guess w= hich layer(s) that thing (or those things) reside, at this point, and I ent= irely agree that this is an opportunity to take a few deep breaths and cons= ider the problem space. Best wishes, Robin ________________________________ From: Eliot Lear Sent: Wednesday, January 29, 2020 9:48:32 AM To: Bernard Aboba Cc: architecture-discuss@ietf.org ; model-t@= iab.org ; Toerless Eckert Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust = model evolution Hi Bernard and thanks for your valuable thoughts. On 28 Jan 2020, at 23:50, Bernard Aboba > wrote: Eliot -- The examples you describe are difficult to capture within protocol-specific= threat models (RFC 3552) or privacy considerations (RFC 6973). For practi= cality, those analyses need to maintain a narrow focus, yet at the same tim= e we understand that systemic privacy and security issues can only be under= stood when analyzing the system that a protocol is embedded in. As a resul= t, even protocols that successfully address the original threat models can = be the source of major systemic vulnerabilities. For example, we could not = have expected the authors of RFC 1945 (HTTP 1.0) to have anticipated the se= curity and privacy problems arising from today's social media implementatio= ns - some of which were discussed during the Internet Privacy Workshop summ= arized in RFC 6462. I really cannot say what, if any, protocol changes I would suggest at this = point to handle some of the cases I mentioned. Assuming there is interest = in this approach, I would suggest a bit of a collection and a culling. I want to address one related point: Joel doesn=92t think the program shoul= d get up into layer 9 too much, and I would say that it would be necessary = to do so to figure out where we as a community want to make some Lessiguesq= ue law, and when perhaps we need to leave that to others, but see below. However, I do think that you're on to something important that is worth IAB= consideration. It strikes me that in a number of the examples you cite the "endpoint" is n= ot acting in the interest of the "end user", at least in the sense describe= d in draft-iab-for-the-users. As was noted in Section 4.2: In contrast, the Internet of Things (IoT) has not yet seen the emergence of a natural role for representing the needs of the end user. Perhaps as a result of this, that ecosystem and its users face serious challenges. For example, consider how some of the IoT behavior you describe might be ha= ndled within a permission model implemented in a browser or a mobile device= : 1. Would a user grant permission to access to camera or microphone? In th= e example of the device that did not advertise that it contained a micropho= ne, presumably, the answer would be "no" (although the microphone was not i= nitially enabled so perhaps permission might not have been requested). 2. Would the user grant permission to access personal information such as l= ocation? In the example of the device with embedded trackers, again the us= er would probably not have granted access to location and other data (altho= ugh we know that location can easily be obtained in circumvention of browse= r or mobile device protections). Very well put. I think that leads us into a bit of futuristic scenario planning about how = that permission model would work, what the control points are, then how the= y interact, etc. The L9 discussions come in the form, I think, of incentiv= e modeling to address the for-the-users point. But that=92s for later. Fo= r now, what are the problems? To Toerless=92 point: Yes, i think we can agree that we would like all Internet end-to-end transport must not even allow for a misconfigured option to use null encryption, but i think when TLS 1.3 was standardized, there should have been a better solution than to completely oppress the needs of those other use-cases. And my suggestion is that we take three steps back before we even go there.= Let=92s not treat this like an IETF working group, but pause and take dee= p breaths and work the problem space just a bit. Eliot --_000_BL0PR06MB4772046AA2FD38C48F5C75BBBF050BL0PR06MB4772namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks, both. As I read your comments, one phrase kept presenting itself to= me...
=93user agency=94. What is it, in the system, that is giving effect to the = user=92s intention and preferences. I=92m not even going to try and guess w= hich layer(s) that thing (or those things) reside, at this point, and I ent= irely agree that this is an opportunity to take a few deep breaths and consider the problem space.

Best wishes,
Robin
From: Eliot Lear <lear@c= isco.com>
Sent: Wednesday, January 29, 2020 9:48:32 AM
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: architecture-discuss@ietf.org <architecture-discuss@ietf.org&= gt;; model-t@iab.org <model-t@iab.org>; Toerless Eckert <tte@cs.fa= u.de>
Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet= trust model evolution
 

On 28 Jan 2020, at 23:50, Bernard Aboba <bernard.aboba@gmail.com> wrot= e:

Eliot --

The examples you describe are difficult to capture within p= rotocol-specific threat models (RFC 3552) or privacy considerations (RFC 69= 73).  For practicality, those analyses need to maintain a narrow focus= , yet at the same time we understand that systemic privacy and security issues can only be understood when analyzing= the system that a protocol is embedded in.  As a result, even protoco= ls that successfully address the original threat models can be the sou= rce of major systemic vulnerabilities. For example, we could not have expected the authors of RFC 1945 (HTTP 1.0) to = have anticipated the security and privacy problems arising from today's soc= ial media implementations - some of which were discussed during the Interne= t Privacy Workshop summarized in RFC 6462. 

I really cannot say what, if any, protocol changes I would suggest at this = point to handle some of the cases I mentioned.  Assuming there is inte= rest in this approach, I would suggest a bit of a collection and a culling.=

I want to address one related point: Joel doesn=92t think the program = should get up into layer 9 too much, and I would say that it would be neces= sary to do so to figure out where we as a community want to make some Lessi= guesque law, and when perhaps we need to leave that to others, but see below.


However, I do think that you're on to something important t= hat is worth IAB consideration. 

It strikes me that in a number of the examples you cite the= "endpoint" is not acting in the interest of the "end user&q= uot;, at least in the sense described in draft-iab-for-the-users.  As = was noted in Section 4.2:

   In contrast, the Internet of Thi=
ngs (IoT) has not yet seen the
   emergence of a natural role for representing the needs of the end
   user.  Perhaps as a result of this, that ecosystem and its users face
   serious challenges.

For example, consider how some of the IoT behavior you desc= ribe might be handled within a permission model implemented in a browser or= a mobile device: 

1. Would a user grant permission to access to camera or mic= rophone?   In the example of the device that did not advertise th= at it contained a microphone, presumably, the answer would be "no"= ; (although the microphone was not initially enabled so perhaps permission might not have been requested). 
2. Would the user grant permission to access pers= onal information such as location?  In the example of the device with = embedded trackers, again the user would probably not have granted access to= location and other data (although we know that location can easily be obtained in circumvention of browser or mobile device protec= tions).



Very well put.

I think that leads us into a bit of futuristic scenario planning about= how that permission model would work, what the control points are, then how they interact, etc.  The L9 discu= ssions come in the form, I think, of incentive modeling to address the for-= the-users point.  But that=92s for later.  For now, what are the = problems?

To Toerless=92 point:

Yes, i think we can agree that we woul= d like all Internet end-to-end
transport must not even allow for a misconfigured option to use null
encryption, but i think when TLS 1.3 was standardized, there should have been a better solution than to completely oppress the needs of those
other use-cases.

And my suggestion is that we take three steps back before we even go t= here.  Let=92s not treat this like an IETF working group, but pause an= d take deep breaths and work the problem space just a bit.

Eliot

--_000_BL0PR06MB4772046AA2FD38C48F5C75BBBF050BL0PR06MB4772namp_-- From nobody Wed Jan 29 20:42:17 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8560512006B for ; Wed, 29 Jan 2020 20:42:15 -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_HELO_NONE=0.001, 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 Xo2tv-K24G4V for ; Wed, 29 Jan 2020 20:42:13 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9D012006E for ; Wed, 29 Jan 2020 20:42:13 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id q81so2300253oig.0 for ; Wed, 29 Jan 2020 20:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OJqZacWtpuJza1KTqLi0ZSy1hP2aitzufnhGbBOyWFk=; b=dHa2rSa40szLrn+sBAJ4zyp86cYqSEjlnH8YQeL6o83DkwdlSX4iDUorLNoRdcZDLH mU3aTUqOZm2B4jPa6QjhhX0hbkRrFczV60BiTc2zgTCLv4wY1WSWgpmJp5j+TwkEMiUk rae56Rhyg0uKNZEEMp07pKSjNZDcwOBvDGESFnEjrUBox7J6Tn2ven+79fciNrg+TzBR UUKza72hqBgZrRONsW6pbQglUkKJuApbe4j5g4T9bHU7KI8Dx8Tmd9cakZp16zjdkM5t hx620M8qWBDXi6Eb8uJAm+qEsr3OCuLVgshdBUPUqMIEeOPNI6FU4KfbXSL/fgeNkTtl grzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OJqZacWtpuJza1KTqLi0ZSy1hP2aitzufnhGbBOyWFk=; b=qbajN0//cYYqTzFleRpVUN9Ux/z/rraOPaQj/cg+cRqwn7L6oQHzXvlUiTWeBmgaTD trodOXaA00CNpVc3wroPKzeKvCI6vQ0CLwRDmM5N9GZLewPURV5+nwg7vmCc6Ru3hHuW SLZr1hPvmi8lZO+6Ti17Y03WEGQt45r8vW4CixGcj1/V1s1BTMDMMhLlC2AzfofG9/B2 D82vjBkul47TtrGPeg+7zVCV/xrNQa8Ve1JNx1Tqp1yGS2rLJPBc9TGr8TudvtnLfW4s 7u4qjEFnWrCK+hsTj8yGMs0ZxMCGBtKpzEi7+clkJV2mG5vuuPdOCa7dGEKktIYpS6Sp B0jQ== X-Gm-Message-State: APjAAAXYIKOP062e3mXzxJjk6bCgoBReHlgMNG8ALyyoGQlVCsSnXQjc wUioVXGGg0vYbzQiEavfxSrR36Ff4F2QPrHzjV8= X-Google-Smtp-Source: APXvYqzQBrKyyjFqOr+jS6qNRVd/Hde8CRDpp820mLx+mHuqaZCK1YizVfprAOjtI+CujKIa2RIt6XuJC7n8YVcdHjQ= X-Received: by 2002:a54:4396:: with SMTP id u22mr1749677oiv.128.1580359332329; Wed, 29 Jan 2020 20:42:12 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Wed, 29 Jan 2020 20:42:11 -0800 (PST) In-Reply-To: References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <16390A67-B502-4278-B93E-2642025F356D@cisco.com> From: Guntur Wiseno Putra Date: Thu, 30 Jan 2020 11:42:11 +0700 Message-ID: To: Robin Wilton Cc: Eliot Lear , Bernard Aboba , Toerless Eckert , "architecture-discuss@ietf.org" , "model-t@iab.org" Content-Type: multipart/alternative; boundary="0000000000009efe48059d541407" Archived-At: Subject: Re: [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 04:42:15 -0000 --0000000000009efe48059d541407 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Mr. Wilton and architecture-discuss, "User", "agency", "intentions" and "preferences" and "system": do phrases made by those words refer to, exemplified by the Web operation, networks of languages...? "The Internet works because of interoperability between different computers, despite different hardware, operating systems, local language context, and software supplier. Users of the web sign on to the use of these languages when they use the Internet". (Tim Berners-Lee, "Stack of Specifications" in "Design Issues: Architectural and Philosophical Points) That was ever to be part of the discussion: Re: [arch-d] Fwd: New Version Notification for draft-iab-for-the-users-01.txt (December 15th 2019) (2) Note: (1) https://w3.org/DesignIssues/Stack.html That to which I so far understand that: In network societies, an individual/person is a synthesis, or a conflict domain, of networks of things/languages with/for/to/among which s/he celebrates/affirmes her/his life/existence... (2) https://mailarchive.ietf.org/arch/msg/architecture-discuss/7LSyY0nB_HyPPRdB= kLpfmd5joeQ Regard, Guntur Wiseno Putra Pada Kamis, 30 Januari 2020, Robin Wilton menulis: > Thanks, both. As I read your comments, one phrase kept presenting itself > to me... > =E2=80=9Cuser agency=E2=80=9D. What is it, in the system, that is giving = effect to the > user=E2=80=99s intention and preferences. I=E2=80=99m not even going to t= ry and guess which > layer(s) that thing (or those things) reside, at this point, and I entire= ly > agree that this is an opportunity to take a few deep breaths and consider > the problem space. > > Best wishes, > Robin > ------------------------------ > *From:* Eliot Lear > *Sent:* Wednesday, January 29, 2020 9:48:32 AM > *To:* Bernard Aboba > *Cc:* architecture-discuss@ietf.org ; > model-t@iab.org ; Toerless Eckert > *Subject:* Re: [Model-t] [arch-d] Possible new IAB program on Internet > trust model evolution > > Hi Bernard and thanks for your valuable thoughts. > > On 28 Jan 2020, at 23:50, Bernard Aboba wrote: > > Eliot -- > > The examples you describe are difficult to capture within > protocol-specific threat models (RFC 3552) or privacy considerations (RFC > 6973). For practicality, those analyses need to maintain a narrow focus, > yet at the same time we understand that systemic privacy and security > issues can only be understood when analyzing the system that a protocol i= s > embedded in. As a result, even protocols that successfully address the > original threat models can be the source of major systemic vulnerabilitie= s. > For example, we could not have expected the authors of RFC 1945 (HTTP 1.0= ) > to have anticipated the security and privacy problems arising from today'= s > social media implementations - some of which were discussed during the > Internet Privacy Workshop summarized in RFC 6462. > > > I really cannot say what, if any, protocol changes I would suggest at thi= s > point to handle some of the cases I mentioned. Assuming there is interes= t > in this approach, I would suggest a bit of a collection and a culling. > > I want to address one related point: Joel doesn=E2=80=99t think the progr= am should > get up into layer 9 too much, and I would say that it would be necessary = to > do so to figure out where we as a community want to make some Lessiguesqu= e > law, and when perhaps we need to leave that to others, but see below. > > > However, I do think that you're on to something important that is worth > IAB consideration. > > It strikes me that in a number of the examples you cite the "endpoint" is > not acting in the interest of the "end user", at least in the sense > described in draft-iab-for-the-users. As was noted in Section 4.2: > > In contrast, the Internet of Things (IoT) has not yet seen the > emergence of a natural role for representing the needs of the end > user. Perhaps as a result of this, that ecosystem and its users face > serious challenges. > > > For example, consider how some of the IoT behavior you describe might be > handled within a permission model implemented in a browser or a mobile > device: > > 1. Would a user grant permission to access to camera or microphone? In > the example of the device that did not advertise that it contained a > microphone, presumably, the answer would be "no" (although the microphone > was not initially enabled so perhaps permission might not have been > requested). > 2. Would the user grant permission to access personal information such as > location? In the example of the device with embedded trackers, again the > user would probably not have granted access to location and other data > (although we know that location can easily be obtained in circumvention o= f > browser or mobile device protections). > > > > Very well put. > > I think that leads us into a bit of futuristic scenario planning about ho= w > that permission model would work, what the control points are, *then* how > they interact, etc. The L9 discussions come in the form, I think, of > incentive modeling to address the for-the-users point. But that=E2=80=99= s for > later. For now, what are the problems? > > To Toerless=E2=80=99 point: > > Yes, i think we can agree that we would like all Internet end-to-end > transport must not even allow for a misconfigured option to use null > encryption, but i think when TLS 1.3 was standardized, there should have > been a better solution than to completely oppress the needs of those > other use-cases. > > > And my suggestion is that we take three steps back before we even go > there. Let=E2=80=99s not treat this like an IETF working group, but paus= e and take > deep breaths and work the problem space just a bit. > > Eliot > > --0000000000009efe48059d541407 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Mr. Wilton and architecture-discuss,=C2=A0

"User", "agency", "intentions" and &qu= ot;preferences" and "system": do phrases made by those words= =C2=A0refer to, exemplified by the Web operation, networks of languages...= ?

"The Internet works because of interoperability between different comp= uters, despite different hardware, operating systems, local language contex= t, and software supplier. Users of the web sign on to the use of these lang= uages when they use the Internet".
=C2=A0(Tim Berners-Lee, &= quot;Stack of Specifications" in "Design Issues: Architectural an= d Philosophical Points)=C2=A0

That was ever to be part of the discussion:
Re: [arch-d] Fwd: New Version Notification for draft-iab-for-the-users-01.t= xt (December 15th 2019) (2)





Note:=C2=A0=

That to which I so far understand that:=C2=A0
In network = societies, an individual/person is a synthesis, or a conflict domain, of ne= tworks of things/languages with/for/to/among which s/he celebrates/affirmes= her/his life/existence...=C2=A0

(2)=C2=A0https://mailarchive.ietf.org/arch/msg/architecture-di= scuss/7LSyY0nB_HyPPRdBkLpfmd5joeQ=C2=A0 =C2=A0


Regard,
Guntur Wiseno Putra

Pada Kamis, 30= Januari 2020, Robin Wilton <wilton@i= soc.org> menulis:
Thanks, both. As I read your comments, one phrase kept presenting itself to= me...
=E2=80=9Cuser agency=E2=80=9D. What is it, in the system, that is giving ef= fect to the user=E2=80=99s intention and preferences. I=E2=80=99m not even = going to try and guess which layer(s) that thing (or those things) reside, = at this point, and I entirely agree that this is an opportunity to take a few deep breaths and consider the problem space.

Best wishes,
Robin
From: Eliot Lear <lear@cisco.com>
Sent: Wednesday, January 29, 2020 9:48:32 AM
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: architecture-discuss@ietf.org <architecture-discuss@ietf.org>= ; model-t@iab.org = <model-t@iab.org>; Toerless Eckert <tte@cs.fau.de>
Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet= trust model evolution
=C2=A0
Hi Bernard= and thanks for your valuable thoughts.

On 28 Jan 2020, at 23:50, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Eliot --

The examples you describe are difficult to capture within protocol-spe= cific threat models (RFC 3552) or privacy considerations (RFC 6973).=C2=A0 = For practicality, those analyses need to maintain a narrow focus, yet at th= e same time we understand that systemic privacy and security issues can only be understood when analyzing= the system that a protocol is embedded in.=C2=A0 As a result, even protoco= ls that successfully=C2=A0address the original threat models can be the sou= rce=C2=A0of major systemic vulnerabilities. For example, we could not have expected the authors of RFC 1945 (HTTP 1.0) to = have anticipated the security and privacy problems arising from today's= social media implementations - some of which were discussed during the Int= ernet Privacy Workshop summarized in RFC 6462.=C2=A0

I really cannot say what, if any, protocol changes I would suggest at this = point to handle some of the cases I mentioned.=C2=A0 Assuming there is inte= rest in this approach, I would suggest a bit of a collection and a culling.=

I want to address one related point: Joel doesn=E2=80=99t think the pr= ogram should get up into layer 9 too much, and I would say that it would be= necessary to do so to figure out where we as a community want to make some= Lessiguesque law, and when perhaps we need to leave that to others, but see below.


However, I do think that you're on to something important that is = worth IAB consideration.=C2=A0

It strikes me that in a number of the examples you cite the "endp= oint" is not acting in the interest of the "end user", at le= ast in the sense described in draft-iab-for-the-users.=C2=A0 As was noted i= n Section 4.2:

   In c=
ontrast, the Internet of Things (IoT) has not yet seen the
   emergence of a natural role for representing the needs of the end
   user.  Perhaps as a result of this, that ecosystem and its users face
   serious challenges.

For example, consider how some of the IoT behavior you describe might = be handled within a permission model implemented in a browser or a mobile d= evice:=C2=A0

1. Would a user grant permission to access to camera or microphone?=C2= =A0 =C2=A0In the example of the device that did not advertise that it conta= ined a microphone, presumably, the answer would be "no" (although= the microphone was not initially enabled so perhaps permission might not have been requested).=C2=A0
2. Would=C2=A0the user grant=C2=A0permission to access personal inform= ation such as location?=C2=A0 In the example of the device with embedded tr= ackers, again the user would probably not have granted access to location a= nd other data (although we know that location can easily be obtained in circumvention of browser or mobile device protec= tions).



Very well put.

I think that leads us into a bit of futuristic scenario planning about= how that permission model would work, what the control points are, then=C2=A0how they interact,=C2=A0etc.=C2=A0 The L9 discussions come= in the form, I think, of incentive modeling to address the for-the-users p= oint.=C2=A0 But that=E2=80=99s for later.=C2=A0 For now, what are the probl= ems?

To Toerless=E2=80=99 point:

Yes, i think we can agree that we would like all = Internet end-to-end
transport must not even allow for a misconfigured option to use null
encryption, but i think when TLS 1.3 was standardized, there should have been a better solution than to completely oppress the needs of those
other use-cases.

And my suggestion is that we take three steps back before we even go t= here.=C2=A0 Let=E2=80=99s not treat this like an IETF working group, but pa= use and take deep breaths and work the problem space just a bit.

Eliot

--0000000000009efe48059d541407-- From nobody Wed Jan 29 22:48:49 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC08E1200C5 for ; Wed, 29 Jan 2020 22:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=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 JNkGY8rhIFqe for ; Wed, 29 Jan 2020 22:48:42 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5941200C3 for ; Wed, 29 Jan 2020 22:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=568; q=dns/txt; s=iport; t=1580366922; x=1581576522; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HeNBIjft5V5acj+IxncyVEwJiavy7bf9AZ3PVR34dDY=; b=fqShJXvZttaRYyGoILpDI1fes+WPhBye2WECHqmSh5E6g54pjgWXrqEA GPMRtEZub30Dz49Yi2UcTJ2iFjU4yqc2MB9WFWDySof/286SXiUgY90Qp teXFHRGJANP84/NQNeMeYzNobfmA7tywtp0CU3aYP6dn7M3iadJwFG8yc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAwAIezJe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuDaiASKoQUiQOHcyWbOAkBAQEMAQEvAQGEQAKCTjgTAgMNAQE?= =?us-ascii?q?EAQEBAgEFBG2FQ4VeAQEBAQIBI1YFCwsYAgImAgJXBhODJoJcIKs/dYEyijm?= =?us-ascii?q?BDiqMOoIAgTgMFIIeLj6ESYMQMoIsBKAmjzSCQ4JMk24bgjgQjCsni2amRIM?= =?us-ascii?q?uAgQGBQIVgWkigVgzGggbFWUBgkE+EhgNjlWOD0ADMI4pAQE?= X-IronPort-AV: E=Sophos;i="5.70,380,1574121600"; d="scan'208";a="22709939" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jan 2020 06:48:38 +0000 Received: from [10.61.193.95] ([10.61.193.95]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 00U6mbrZ025607 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Jan 2020 06:48:37 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Eliot Lear In-Reply-To: Date: Thu, 30 Jan 2020 07:48:37 +0100 Cc: Bernard Aboba , "architecture-discuss@ietf.org" , "model-t@iab.org" , Toerless Eckert Content-Transfer-Encoding: quoted-printable Message-Id: <9D008EE8-7796-4A19-A4FE-6189C279A6A1@cisco.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <16390A67-B502-4278-B93E-2642025F356D@cisco.com> To: Robin Wilton X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Outbound-SMTP-Client: 10.61.193.95, [10.61.193.95] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 06:48:45 -0000 Hi Robin > On 29 Jan 2020, at 22:17, Robin Wilton wrote: >=20 > Thanks, both. As I read your comments, one phrase kept presenting = itself to me... > =E2=80=9Cuser agency=E2=80=9D. What is it, in the system, that is = giving effect to the user=E2=80=99s intention and preferences. Good point. I was going to write out an example of how this would play out, but I am = beginning to wonder if an I-D would do better, so as to memorialize a = bit better the discussion. This assumes it=E2=80=99s where the IAB = wants to go. Eliot From nobody Wed Jan 29 23:11:26 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EE91200D5 for ; Wed, 29 Jan 2020 23:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 vGMKDPWGehPz for ; Wed, 29 Jan 2020 23:11:24 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 5177412006B for ; Wed, 29 Jan 2020 23:11:24 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id g15so2212138otp.3 for ; Wed, 29 Jan 2020 23:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jXwtvzOk5ivW5PZqMIRRDHtmq7PrFrNuhiRI6rNkKCw=; b=nLqybvRXR1s2l15wXrfiqVAIJs0Mj06miEMhfbupWaqpM17gnB3iE7AEmpFAoRxGbh 8p7146J2mga9iBnJveX+FBQBPRxEb5ghelEqtXlZ5i3H2JBGf7jQDN84OkNbNX/aHzS5 DIg88iH40wMFOvM90eTzX/n8oCovN9BkmiJErbNfxYQQqkM5khwIpogT8wjYKiGtDAym YQlEjZBPLNXvQBTbp4MUH3r0B2In4F8xareRaA4ptzB0QtS2nWkWEJOg0+8j4u+332X/ 5VoZ3mq5l17sAX7BFWKp3usEeuKFDlyb90oz5DJoPWishv10erJOTY/BFP+VDT1gTtaf FcUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jXwtvzOk5ivW5PZqMIRRDHtmq7PrFrNuhiRI6rNkKCw=; b=EGB+jAr17zemBo7qaBB/zaChUUD1lQCvvjZcJpUDGvBUb0+lYO3MIs/zkMO4UD0VLM jvSYuQV5o2YIjHlmdBdJ3aiTQII6ekcanB1Epc/BWWwl/cDh9o8EmWXgUAPnsvcv3U6C sSc5UUFZWqMQXux2KD3KmA2OO+ViGu5NkNLZgEUA+Padf/RZO+kMUnO431mV45xP1m9X e5nltkBPe29lmc+9HSqMwBMcZ0Nbheokrx1Y/NAL23+i523/o/tDd+JcFjnKqYy6SW6A lPOpP3XauwKaqyRKZBco82s+OnU5v0ACmnau8MJt8l4thdpj+q6+1alNc8+BuDtD0DEz JgAg== X-Gm-Message-State: APjAAAV6unzfqa0QiyGfpfqoGoHFcitkC2kqdGAvzmQb34+henHMTSDQ 70PA2EJvtmc7k6df4i/dQv93q1aVtWjnq1Rj/4M= X-Google-Smtp-Source: APXvYqz8jARkvGjXceGTRQbjHDxJF6M3/Qa6zhxlVA0ryanc1la752ISiduUAx8VJghYF0z3Bohb/T+mYPJomQE19I4= X-Received: by 2002:a9d:170a:: with SMTP id i10mr2479698ota.284.1580368283618; Wed, 29 Jan 2020 23:11:23 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Wed, 29 Jan 2020 23:11:23 -0800 (PST) In-Reply-To: <9D008EE8-7796-4A19-A4FE-6189C279A6A1@cisco.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <16390A67-B502-4278-B93E-2642025F356D@cisco.com> <9D008EE8-7796-4A19-A4FE-6189C279A6A1@cisco.com> From: Guntur Wiseno Putra Date: Thu, 30 Jan 2020 14:11:23 +0700 Message-ID: To: Eliot Lear Cc: Robin Wilton , Toerless Eckert , "model-t@iab.org" , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="00000000000028d2be059d562a3d" Archived-At: Subject: Re: [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 07:11:25 -0000 --00000000000028d2be059d562a3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss, To add the note I made in the previous message: An Individual/person, by network society with ICTs as a structural matrix, is a momentous synthesis, or a conflict domain --there may be still existed conflicts accompanying her/his choices of acts--, of networks of things/languages with/for/to/among which s/he celebrates/affirmes her/his life/existence... I am referring to notions on "Network Society" and "Networks of Languages" worked in: - "Informationalism, Technology and Network Society" (Manuel Catells) https://annenberg.usc.edu/sites/default/files/2015/04/28/Informationalism%2= C%20Networks%20and%20the%20Network%20Society.pdf - here, it may deserve to note that in its forweword to "Leveraging Tech..." report Antonio Gueterez beginned with the term "networked society" "Our networked society is changing the way we live. The impact and implications of the digital revolution are becoming more evident with each passing hour. The 2030 Agenda for Sustainable Development recognizes the great potential of global connectivity to spur human progress. It challenges us to ensure universal and affordable Internet access for all". https://www.itu.int/en/sustainable-world/Documents/Fast-forward_progress_re= port_414709%20FINAL.pdf - J. F. Lyotard, "The Postmodern Conditions: a Report on Knowledge" section "Elementary Nature of Social Ties: Posmodern Perspective" as there was mentioned about society defined by "networks of language" Regard, Guntur Wiseno Putra Pada Kamis, 30 Januari 2020, Eliot Lear menulis: > Hi Robin > > > On 29 Jan 2020, at 22:17, Robin Wilton wrote: > > > > Thanks, both. As I read your comments, one phrase kept presenting itsel= f > to me... > > =E2=80=9Cuser agency=E2=80=9D. What is it, in the system, that is givin= g effect to the > user=E2=80=99s intention and preferences. > > Good point. > > I was going to write out an example of how this would play out, but I am > beginning to wonder if an I-D would do better, so as to memorialize a bit > better the discussion. This assumes it=E2=80=99s where the IAB wants to = go. > > Eliot > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --00000000000028d2be059d562a3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,



To add the note I made in the previous message:


An Individual/person, by network society with ICTs as a structural matrix, = is a momentous synthesis, or a conflict domain --there may be still existed= conflicts accompanying her/his choices of acts--, of networks of things/la= nguages with/for/to/among which s/he celebrates/affirmes her/his life/exist= ence...


I am referring to notions on "Network Society" and "Networks= of Languages" worked in:


- "Informationalism, Technology and Network Society" (Manuel Cate= lls)

https://annenb= erg.usc.edu/sites/default/files/2015/04/28/Informationalism%2C%20Networks%2= 0and%20the%20Network%20Society.pdf

- here, it may deserve to note that in its forweword to "Leveraging Te= ch..." report Antonio Gueterez beginned with the term "networked = society"

"Our networked society is changing the way we live. The impact and imp= lications=20
of the digital revolution are becoming more evident with each passing hour.= =20

The 2030 Agenda for Sustainable Development recognizes the great potential= =20
of global connectivity to spur human progress. It challenges us to ensure= =20
universal and affordable Internet access for all".

https://www.itu.int/en/sustainable-worl= d/Documents/Fast-forward_progress_report_414709%20FINAL.pdf

- J. F. Lyotard, "The Postmodern Conditions: a Report on Knowledge&quo= t; section "Elementary Nature of Social Ties: Posmodern Perspective&qu= ot; as there was mentioned about society defined by "networks of langu= age"



Regard,
Guntur Wiseno Putra


Pada Kamis, 30 Janua= ri 2020, Eliot Lear <lear@cisco.com> menulis:
Hi Robin

> On 29 Jan 2020, at 22:17, Robin Wilton <wilton@isoc.org> wrote:
>
> Thanks, both. As I read your comments, one phrase kept presenting itse= lf to me...
> =E2=80=9Cuser agency=E2=80=9D. What is it, in the system, that is givi= ng effect to the user=E2=80=99s intention and preferences.

Good point.

I was going to write out an example of how this would play out, but I am be= ginning to wonder if an I-D would do better, so as to memorialize a bit bet= ter the discussion.=C2=A0 This assumes it=E2=80=99s where the IAB wants to = go.

Eliot

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.= org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--00000000000028d2be059d562a3d-- From nobody Thu Jan 30 07:32:26 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC32212016E for ; Thu, 30 Jan 2020 07:32:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 uprrGk0_DCJE for ; Thu, 30 Jan 2020 07:32:22 -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 B0151120168 for ; Thu, 30 Jan 2020 07:32:21 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id q8so3841159ljb.2 for ; Thu, 30 Jan 2020 07:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j4nCUOGO355Rg8aizbNf0dL09lv/yafEyTjrX7icBAU=; b=m4TwXyftWbb07OTNJyENFAj7lbRZogp0uZu779O0SG5nKdgd6mfXsl49ZTX2CRqAiP jlTtCOf6fXP1IWsreKT5yYPft5yv0U7K7ydHCyC38vHXy65eil0TSXIHQAnXZz5W9NqZ Lps6QIA9rLm3lspmSFnWlHxR8rk6EQwyM03ocwHCCK+/muwxRZZIsQ3/vKrnwPqFB3ND W1+49rOA+E6nB/BTywNpmCJWK7ylcJqniHKlCiu13gSuR50mQZoofQFQ8QLayF7HHmSH uBADcGfAV7J93thMMj6aYtFXCZouRRNIcZOoaxYTVaPVbBQ/sbooZQXOivq7a9NlgKRL hNeA== 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=j4nCUOGO355Rg8aizbNf0dL09lv/yafEyTjrX7icBAU=; b=FMlKqKZLFve7WFHsKtYkKT2w7NVb+PtKvyeCG01L4N0wPFbVHDA2W+Y3+EPhCcF6JE ABqWmZfneXGYtKvf5uPDPWOOn10nHUzmdqBQJzWbsvTZ8Xp8xhbuUpYG4hnRru9Rd+nK H4CDEmbcwmu8U73XI8AgGLcDGbOEtg2SvibeKwWGlnre3oV3U59GvuJSEPsvi2w/aqgb tJTFqxXMq0Utk4v6N4VxZhgFbJkYiQBghZX5FUeukiJOlVU9XH5H2+B5ZuaQ7+Qb7zVI W4p9QjQtvugX+k+nEiOz4TFDs//JJP/nb9rEoviBmPKHCqCSitcAwGmpkYmMkMZb7dJn 0ObQ== X-Gm-Message-State: APjAAAVBxF8QetRVTTuqzm1zU814zj6CDYny3ZcK64O+wTkVXgPLJVPJ aFLNOzg3SNIEOevmNDoTEOPk4ZwXqO7vhtVSnlZF0h2wAeK0Nw== X-Google-Smtp-Source: APXvYqykCM3n6eRC652luis3NmHyg9/PKJeRQVjD/CRUuPRbvdJxmTYGZM2aj/p/dvPEoV4pLnLyYS9yZRbvpHiNo6k= X-Received: by 2002:a2e:b5a5:: with SMTP id f5mr3132179ljn.162.1580398339850; Thu, 30 Jan 2020 07:32:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Thu, 30 Jan 2020 07:31:42 -0800 Message-ID: To: Jari Arkko Cc: model-t@iab.org, architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000a69801059d5d2930" Archived-At: Subject: Re: [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 15:32:24 -0000 --000000000000a69801059d5d2930 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > There is relatively broad agreement that the roles and trustwortiness > of different endpoints in a protocol exchange are important > considerations. In specific cases there may be quite different > perspectives on the tradeoffs involved, e.g., to what extent privacy, > information centralisation, or the needs of enterprise networks should > be considered as the highest priority. And no doubt, other equally > valid perspectives exist. Actually, it's not clear to me that *any* of these are valid things to put in a threat model. Recall what 3552 says a threat model is: A THREAT MODEL describes the capabilities that an attacker is assumed to be able to deploy against a resource. It should contain such information as the resources available to an attacker in terms of information, computing capability, and control of the system. The purpose of a threat model is twofold. First, we wish to identify the threats we are concerned with. Second, we wish to rule some threats explicitly out of scope. Nearly every security system is vulnerable to a sufficiently dedicated and resourceful attacker. But none of the things you list are really part of a threat model. Rather, they are weights one applies to various design considerations, but that's a consideration but that's a form of analysis that happens *after* you have a threat model, not part of the threat model itself. For instance, I don't think anyone thinks that privacy threats (e.g., traffic analysis) aren't part of our threat model (and they're clearly part of the 3552 threat model). Now, as a matter of protocol design, we have often opted not to do much about these threats for practical reasons, but that's a different matter. As Brian said, the purpose of 3552 is to force protocol designers to describe the security properties of their protocols and the purpose the threat model section is to provide a common starting point for that analysis. IOW, it is an essentially tutorial function So to the extent to which an update for 3552 is needed, its purpose should be to make clear considerations which aren't otherwise obvious from the text in 3552. But that's not about a new threat model or about balancing but rather about documentation. -Ekr On Fri, Jan 24, 2020 at 3:50 AM Jari Arkko wrote: > > The IAB are considering starting up a programme on Internet > trust model evolution as described in the link at the bottom of this > email. > > We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on > this topic and discussions held (on the mailing list, SAAG, side > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th. > > To be clear, any output from this program would be text offered > to the IETF for consideration - it is not within the IAB's remit, nor > that of an IAB program, to modify a BCP. Nonetheless, an IAB > program offers a good venue for this work, as it perhaps allows > for more focus on the evolving architecture aspect within this space. > > The plan is for the new program to be entirely open for participation, > similar to how the current work has already been. That is, the mailing > list is open for all interested to join, meetings are open and listed > in the public agendas. The IAB will find a chair or chairs for the > group to stay organised. > > There's no specific deadline for this, but the IAB will consider this > further in the next few weeks, so if you could take a few minutes > to share your thoughts on this that'd be great. > > > https://github.com/intarchboard/model-t-charter/blob/master/model-t-chart= er-00.md > https://www.iab.org/mailman/listinfo/model-t > > Stephen & Jari > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000a69801059d5d2930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> There is relatively broad agreement that the roles an= d trustwortiness
> of different endpoints in a protocol exchange are = important
> considerations. In specific cases there may be quite diff= erent
> perspectives on the tradeoffs involved, e.g., to what extent = privacy,
> information centralisation, or the needs of enterprise net= works should
> be considered as the highest priority. And no doubt, o= ther equally
> valid perspectives exist. =C2=A0

Actually, it&#= 39;s not clear to me that *any* of these are valid
things to put in a th= reat model. Recall what 3552 says a threat
model is:

=C2=A0 =C2= =A0A THREAT MODEL describes the capabilities that an attacker is assumed=C2=A0 =C2=A0to be able to deploy against a resource.=C2=A0 It should cont= ain such
=C2=A0 =C2=A0information as the resources available to an attac= ker in terms of
=C2=A0 =C2=A0information, computing capability, and cont= rol of the system.=C2=A0 The
=C2=A0 =C2=A0purpose of a threat model is t= wofold.=C2=A0 First, we wish to identify the
=C2=A0 =C2=A0threats we are= concerned with.=C2=A0 Second, we wish to rule some threats
=C2=A0 =C2= =A0explicitly out of scope.=C2=A0 Nearly every security system is vulnerabl= e
=C2=A0 =C2=A0to a sufficiently dedicated and resourceful attacker.
=
But none of the things you list are really part of a threat model.
<= br>Rather, they are weights one applies to various design considerations,but that's a consideration but that's a form of analysis that hap= pens
*after* you have a threat model, not part of the threat model itsel= f.
For instance, I don't think anyone thinks that privacy threats (e= .g.,
traffic analysis) aren't part of our threat model (and they'= ;re clearly
part of the 3552 threat model). Now, as a matter of protocol= design,
we have often opted not to do much about these threats for prac= tical
reasons, but that's a different matter.

As Brian said, = the purpose of 3552 is to force protocol designers
to describe the secur= ity properties of their protocols and the purpose
the threat model secti= on is to provide a common starting point for
that analysis. IOW, it is a= n essentially tutorial function So to the
extent to which an update for = 3552 is needed, its purpose should be to
make clear considerations which= aren't otherwise obvious from the text
in 3552. But that's not = about a new threat model or about balancing
but rather about documentati= on.

-Ekr




On Fri, Jan 24, 2020 at 3:50 AM Jari Arkko &= lt;jari.arkko@piuha.net> wro= te:
<= br>The IAB are considering starting up a programme on Internet
trust mod= el evolution as described in the link at the bottom of this
email.
We'd like to get feedback on that idea and the text. As you may
be= aware, in 2019 a number of documents were published on
this topic and d= iscussions held (on the mailing list, SAAG, side
meeting at IETF-106, wo= rkshops, etc). There=E2=80=99s also a virtual
meeting coming up on Febru= ary 14th.

To be clear, any output from this program would be text of= fered=C2=A0
to the IETF for consideration - it is not within the IAB'= ;s remit, nor=C2=A0
that of an IAB program, to modify a BCP. Nonetheless= , an IAB=C2=A0
program offers a good venue for this work, as it perhaps = allows=C2=A0
for more focus on the evolving architecture aspect within t= his space.

The plan is for the new program to be entirely open for p= articipation,
similar to how the current work has already been. That is,= the mailing
list is open for all interested to join, meetings are open = and listed
in the public agendas. The IAB will find a chair or chairs fo= r the
group to stay organised.

There's no specific deadline = for this, but the IAB will=C2=A0consider this
further in the next few w= eeks, so if you could=C2=A0take a few minutes=C2=A0
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000a69801059d5d2930-- From nobody Thu Jan 30 11:27:28 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3639120170 for ; Thu, 30 Jan 2020 11:27:26 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 EiAJojpd3GLx for ; Thu, 30 Jan 2020 11:27:25 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4CC12013D for ; Thu, 30 Jan 2020 11:27:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 06481300B22 for ; Thu, 30 Jan 2020 14:00:44 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SEhvv7xgIrWv for ; Thu, 30 Jan 2020 14:00:42 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id BD23330078C; Thu, 30 Jan 2020 14:00:42 -0500 (EST) From: Russ Housley Message-Id: <64D42558-19A2-469E-B027-B67FB52A5279@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_48F0FFCF-0300-4042-8591-036C39DA5823" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 30 Jan 2020 14:27:23 -0500 In-Reply-To: Cc: architecture-discuss@ietf.org To: Guntur Wiseno Putra References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] Network Architecture in the Internet Society X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 19:27:27 -0000 --Apple-Mail=_48F0FFCF-0300-4042-8591-036C39DA5823 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Is there a way to see the document without creating an account? Russ > On Jan 29, 2020, at 4:37 AM, Guntur Wiseno Putra = wrote: >=20 > Dear architecture-discuss, >=20 > Documents related with the current issues on "consolidation of the = Internet" saved in the "Open Forum" community of the Internet Society: >=20 >=20 > = https://connect.internetsociety.org/viewdocument/consolidation-of-the-inte= rnet-from?CommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=3Dlibrar= ydocuments#ItemCommentPanel = >=20 > Regard, > Guntur Wiseno Putra --Apple-Mail=_48F0FFCF-0300-4042-8591-036C39DA5823 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Is = there a way to see the document without creating an account?

Russ


On Jan 29, 2020, at 4:37 AM, Guntur Wiseno = Putra <gsenopu@gmail.com> wrote:

Dear = architecture-discuss,

Documents related with the current issues on "consolidation = of the Internet" saved in the "Open Forum" community of the Internet = Society:


https://connect.internetsociety.org/viewdocument/consolidation-= of-the-internet-from?CommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&a= mp;tab=3Dlibrarydocuments#ItemCommentPanel

Regard,
Guntur Wiseno Putra

= --Apple-Mail=_48F0FFCF-0300-4042-8591-036C39DA5823-- From nobody Thu Jan 30 18:35:58 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA288120048 for ; Thu, 30 Jan 2020 18:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 Fyo6WIAVnNQC for ; Thu, 30 Jan 2020 18:35:54 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 8A83C120019 for ; Thu, 30 Jan 2020 18:35:54 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id h9so5160511otj.11 for ; Thu, 30 Jan 2020 18:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pYVCPUTbEIi8uh1XZoTriSoefXArtuwGFZDUFwhNH2A=; b=LxURaiPMP17D9ZbBWot3OPfwtsgYI/3Dq2a93ycx1utdlwn/ESff7Zo2hsA/FJWG// bSZCAyTCOPMrZLh/NrLu9289EJLj/3HPx/a3q9pIgwLbo5RrRMQZRO5KYFyKhl5h6kMk GNLmR5IAA8ZckKeOnr3XmBJZxpA0+ICZzqTlGGBIIYCT1Y53XM5e/3tFW2dzlK/AlGxh 7lgBcZSZ6suEDjBfP2sysVKGBqOGleg6qkOz48EuOo3iR/cNkNzP1C4FSih4Hhio06b/ Cxo3bEFR/X3ZQx9r6inLv6pwznaxLYwYQcYo06dSzFFJOv5EKoC5E76Zs1nKxucdQuSJ K20A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pYVCPUTbEIi8uh1XZoTriSoefXArtuwGFZDUFwhNH2A=; b=lzHgvKCLcCBg+z+Fu6AYWcwX1pKWF90ddOUXWrgUhX9dJfRdEDvIxsMHverK5DGI1w FGpXTkd9dKAVOL09GhG5wVXvuOgwbzSnXgcs2wpxwhPUOaGt5hkEfih29cH+j53FNG4o Y94Eq0I4vuUtaW1GimNmCbtUC3gcsv0MfARRIZpIh9lSu1QwTD3+frIAMl/Bmjkfhf1H /UT8eM4umgY1coPMbLL9pkR/U5SRJN32JC+XH2wMktqCLpg4CaNzaS1i8YPpZRpkKsp1 N4Os4mG13FRDpzErNvHLyuqn2CDtGMJHDAKxhOOGTp2v9hmNGM5OFdEY3DPnLqlKHnP6 f24A== X-Gm-Message-State: APjAAAWaUsEpH9ngSR6ZLthAzMdvYvE6KsREG5sbjWht+ErSXJfqQv8b 3tp/+b2ltwvFOEc80Y1TH9bfHxt9JdRak/ERT6w= X-Google-Smtp-Source: APXvYqx8+PsoTxJnK39AxyCuzixyUzzzPQvcCtS9cWG9dpdcaa2JA/xqShYeuwY5tgz3QwniaKayudomINbU3Q9d3f4= X-Received: by 2002:a9d:6c52:: with SMTP id g18mr6090091otq.356.1580438153790; Thu, 30 Jan 2020 18:35:53 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Thu, 30 Jan 2020 18:35:53 -0800 (PST) In-Reply-To: <64D42558-19A2-469E-B027-B67FB52A5279@vigilsec.com> References: <64D42558-19A2-469E-B027-B67FB52A5279@vigilsec.com> From: Guntur Wiseno Putra Date: Fri, 31 Jan 2020 09:35:53 +0700 Message-ID: To: Russ Housley Cc: "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bf09bf059d666ebf" Archived-At: Subject: [arch-d] Network Architecture in the Internet Society X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 02:35:57 -0000 --000000000000bf09bf059d666ebf Content-Type: text/plain; charset="UTF-8" Dear Russ and architecture-discuss, I am new there, I have not know muc "how to": I think one needs to create an account in the Internet Society to join with OPEN FORUM Community to access its features: https://www.internetsociety.org/become-a-member/ But at this architecture-discuss, where we are now, one may simply access its mail archives for the documents on "Consolidation of the Internet" --so it is nothing new but such a networked community of reading, such a networked library: https://mailarchive.ietf.org/arch/msg/architecture-discuss/sdTkLd7q7wXyfAnjJQlNceWPr8U I find no search engine facility for documents at OPEN FORUM community Library while there is one at architecture-discuss mail archive. Regard, Guntur Wiseno Putra Pada Jumat, 31 Januari 2020, Russ Housley menulis: > Is there a way to see the document without creating an account? > > Russ > > > On Jan 29, 2020, at 4:37 AM, Guntur Wiseno Putra > wrote: > > Dear architecture-discuss, > > Documents related with the current issues on "consolidation of the > Internet" saved in the "Open Forum" community of the Internet Society: > > > https://connect.internetsociety.org/viewdocument/consolidati > on-of-the-internet-from?CommunityKey=3a9fa082-a518- > 475d-9e7f-ecec4ffe56dd&tab=librarydocuments#ItemCommentPanel > > Regard, > Guntur Wiseno Putra > > > --000000000000bf09bf059d666ebf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Russ and architecture-discuss,=C2=A0


I am = new there, I have not know muc "how to": I think one needs to cre= ate an account in the Internet Society to join with OPEN FORUM Community to= access its features:

https://www.in= ternetsociety.org/become-a-member/


But at this architecture-discuss, where we are now, one may simply acce= ss its mail archives for the documents on "Consolidation of the Intern= et" --so it is nothing new but such a networked community of reading, = such a networked library:

https://mailarchive.ietf.org/arch/msg/architecture-= discuss/sdTkLd7q7wXyfAnjJQlNceWPr8U

I find no search engine facility for documents at OPEN FORUM community Libr= ary while there is one at architecture-discuss mail archive.
=
Regard,
Guntur Wiseno Putra

Pada Jum= at, 31 Januari 2020, Russ Housley <housley@vigilsec.com> menulis:
Is there a way to see the document without creating an account?
Russ


= On Jan 29, 2020, at 4:37 AM, Guntur Wiseno Putra <gsenopu@gmail.com> wrote:

=
Dear architecture-discuss,

Documents related with t= he current issues on "consolidation of the Internet" saved in the= "Open Forum" community of the Internet Society:

--000000000000bf09bf059d666ebf-- From nobody Thu Jan 30 21:05:06 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C6812003E for ; Thu, 30 Jan 2020 21:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 e2fwhNEwawMV for ; Thu, 30 Jan 2020 21:05:01 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 0E62512001E for ; Thu, 30 Jan 2020 21:05:00 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id z9so5442161oth.5 for ; Thu, 30 Jan 2020 21:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g69LJokNmCcH7WSLBPmL5CNi+8CXZfBieGDpyI1UXmc=; b=unRPZRjGQUSssiuewUuCymNvDvBKFyrJe+Wz5Se+di8lXhCk2sZ09lQENPgB/M3A72 CxUAcefC8u0Gm4DSfR571CcswQpy5DTgCjO5A8llivEUwmro80jcAsnLw+ie+QfjlwV1 79kbtJWs1OBa8oyAxBIPcOKMvzUuareklrXM7zs8fED+xR5aHWvjE9pYR2lKmLY6P9V2 5nQWywp17uSXs0BnFqBD6vAtM7Aenfl7+7XQxlfzxE/2YbNvd+tBb/Hn1HHZyPSJF/OI d3n+8Drz33w9W+CB3GxFZasQA2rlnLRrGYipouty3nQ1nOVv5tnYWhR1ntl6xyEQNlL/ F9uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g69LJokNmCcH7WSLBPmL5CNi+8CXZfBieGDpyI1UXmc=; b=MFJAsRrryscqGN8tyNUnx3dPdEaEpemqFR3xp5lgZNVi2XkgibZ9C0DBU8DMXQ1JKz liH3I6q7FUy9fbxJng3+fHs+XpFEFGAiHk8MUh4HTOeeuzza96d/w9dyvnAOr6t7dleY NX3JUtuCoC+Wv7RiiJ/KdA7gq0+4NPYDdsi+IC3y8CmiShn3md7CCTncOylm2vwdgoVx ZcgnmmZJCLykn5/NueHGjXZtMZFOOK4r/fUD1y5Omxlg3gQXw9wm0s7smAIEMv8sZoR6 d78IGXr5DZQEhDPzijBRYQn9Jq2yCtl7A+Seea209J+OWW2sBkv2bzN3Y87dmWlymVUU cWUQ== X-Gm-Message-State: APjAAAVe28QxVjTX39QWFNqjktGM4a+tGpglQknSrbpqSK7+TJO3QLqC H8rJqacDGYgTTrDCKSKz4MQCFUeqEcaY8ixMz6m5bg== X-Google-Smtp-Source: APXvYqwQ2u21BPHpIpza/MjnYQae7thlRwnFu0zfatXqOr36YYqwtGe/01iJhtXw7KaTEvMCxYFo+j01JdHVSez91+c= X-Received: by 2002:a9d:65da:: with SMTP id z26mr6299342oth.197.1580447100199; Thu, 30 Jan 2020 21:05:00 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Thu, 30 Jan 2020 21:04:59 -0800 (PST) In-Reply-To: References: <64D42558-19A2-469E-B027-B67FB52A5279@vigilsec.com> From: Guntur Wiseno Putra Date: Fri, 31 Jan 2020 12:04:59 +0700 Message-ID: To: Russ Housley Cc: "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fe6903059d688341" Archived-At: Subject: Re: [arch-d] Network Architecture in the Internet Society X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 05:05:05 -0000 --000000000000fe6903059d688341 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Russ and architecture-discuss, The post in OPEN Forum Community Library is about those document saved in the architecture-discuss mailarchive I mentioned above plus Arkko, Jarri et all., "Considerations on the Internet Consolidation and the Internet Architecture", Internet-Draft, IETF, Expired April 2019 https://tools.ietf.org/html/draft-arkko-iab-internet-consolidation-00 While, I have not included yet that of T. Leva and H. Suommi's... I emphasized on socio-economic and architectural learnings attempted by those documents there--while the post at architecture-discuss emphazised on feasibility of the Internet architecture in relation with aesthetic and ethic experiences. This is what I saved in OPEN FORUM Community Library: "Consolidation of the Internet: From the Socio-Economic to the Architectural" This documents refer to "Consolidation in the Internet" which is of economic and architectural approaches and perspectives: - ISOC Global Internet Report Consolidation in the Internet Economy https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/= InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf - Arkko, Jarri et all., "Considerations on the Internet Consolidation and the Internet Architecture", Internet-Draft, IETF, Expired April 2019 https://tools.ietf.org/html/draft-arkko-iab-internet-consolidation-00 - Sullivan, Andrew, "Three Kinds of Concentration in Open Protocols", IAB-DEDR Workshop 2019 https://www.iab.org/wp-content/IAB-uploads/2019/05/p7-sulllivan-three_kinds= _concentration_ajs_dedr.pdf - Arkko, Jarri, "Centralized Architecture in Internet Architecture", Internet Draft, 2019 https://www.ietf.org/id/draft-arkko-arch-infrastructure-centralisation-00.t= xt Kutscher, Dirk, "Protocol Design and Socio-economic Realities", in the IAB-DEDR Workshop 2019 https://www.iab.org/wp-content/IAB-uploads/2019/05/p14-kutscher-internet-de= sign-kutscher.pdf Note: This post is related with another one in this "Open Forum": Restream: Internet Consolidation: What Lies beneath the Application Layer..." (December 14th 2019) https://connect.internetsociety.org/communities/community-home/digestviewer= /viewthread?GroupId=3D67&MessageKey=3D426220c6-e41e-45c8-8872-7f0cc455f492&= CommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=3Ddigestviewer&Retu= rnUrl=3D%2fcommunities%2fcommunity-home%2fdigestviewer%3fCommunityKey%3d3a9= fa082-a518-475d-9e7f-ecec4ffe56dd Regard, Guntur Wiseno Putra Pada Jumat, 31 Januari 2020, Guntur Wiseno Putra menulis: > Dear Russ and architecture-discuss, > > > I am new there, I have not know muc "how to": I think one needs to create > an account in the Internet Society to join with OPEN FORUM Community to > access its features: > > https://www.internetsociety.org/become-a-member/ > > > But at this architecture-discuss, where we are now, one may simply access > its mail archives for the documents on "Consolidation of the Internet" --= so > it is nothing new but such a networked community of reading, such a > networked library: > > https://mailarchive.ietf.org/arch/msg/architecture-discuss/ > sdTkLd7q7wXyfAnjJQlNceWPr8U > > I find no search engine facility for documents at OPEN FORUM community > Library while there is one at architecture-discuss mail archive. > > Regard, > Guntur Wiseno Putra > > Pada Jumat, 31 Januari 2020, Russ Housley menulis: > >> Is there a way to see the document without creating an account? >> >> Russ >> >> >> On Jan 29, 2020, at 4:37 AM, Guntur Wiseno Putra >> wrote: >> >> Dear architecture-discuss, >> >> Documents related with the current issues on "consolidation of the >> Internet" saved in the "Open Forum" community of the Internet Society: >> >> >> https://connect.internetsociety.org/viewdocument/consolidati >> on-of-the-internet-from?CommunityKey=3D3a9fa082-a518-475d- >> 9e7f-ecec4ffe56dd&tab=3Dlibrarydocuments#ItemCommentPanel >> >> Regard, >> Guntur Wiseno Putra >> >> >> --000000000000fe6903059d688341 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Russ and architecture-discuss,

The post =C2=A0in OP= EN Forum Community Library is about those document saved in the architectur= e-discuss mailarchive I mentioned above plus=C2=A0

=C2=A0Arkko, Jarri et all., "Considerations on t= he Internet Consolidation and the Internet Architecture", Internet-Dra= ft, IETF, Expired April 2019 https://tools.ietf.org/html/draft-arkko= -iab-internet-consolidation-00=C2=A0=

While, I have not included yet that of T. Leva and H. Suommi's...

I emphasized on socio-economic and architect= ural learnings attempted by those documents there--while the post at archit= ecture-discuss emphazised on feasibility of the Internet architecture in re= lation with aesthetic and ethic experiences.

This = is what I saved in OPEN FORUM Community Library:

&= quot;Consolidation of the Internet: From the Socio-Economic to the Architec= tural"

This documents refer to "Consolidation in the In= ternet" which is of economic and architectural approaches and perspect= ives:

- = ISOC Global Internet Report Consolidation in the Internet Economy https://future.internetsociety.org/2019/wp-content/uploads/sites/2/201= 9/04/InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy= .pdf=C2=A0
- Arkko, Jarri et all., "Considerations on the Internet Cons= olidation and the Internet Architecture", Internet-Draft, IETF, Expire= d April 2019 https://tools.ietf.org/html/draft-arkko-iab-internet-co= nsolidation-00=C2=A0
- Sullivan, Andrew, "Three Kinds of Concentration in= Open Protocols", IAB-DEDR Workshop 2019 https://www.iab.org/wp-content/IAB-uploads/2019/05/p7-sulllivan-= three_kinds_concentration_ajs_dedr.pdf=C2=A0
- Arkko, Jarri, "Centralized= Architecture in Internet Architecture", Internet Draft, 2019=C2=A0
https://www.ietf.org/id/draft-arkko-arch-infrastructure-centralisat= ion-00.txt
Kutscher, Dirk, "Protocol Design and Socio-economic Realitie= s", in the IAB-DEDR Workshop 2019
https://www.i= ab.org/wp-content/IAB-uploads/2019/05/p14-kutscher-internet-design-kutscher= .pdf


Note: This post is related with another one in this "Open Fo= rum": Restream: Internet Consolidation: What Lies beneath the Applicat= ion Layer..." (December 14th 2019) https://connect.internetsociety.org/communities/= community-home/digestviewer/viewthread?GroupId=3D67&MessageKey=3D426220= c6-e41e-45c8-8872-7f0cc455f492&CommunityKey=3D3a9fa082-a518-475d-9e7f-e= cec4ffe56dd&tab=3Ddigestviewer&ReturnUrl=3D%2fcommunities%2fcommuni= ty-home%2fdigestviewer%3fCommunityKey%3d3a9fa082-a518-475d-9e7f-ecec4ffe56d= d







Reg= ard,
Guntur Wiseno Putra

Pada Jumat, 31 Januari 2020, Gunt= ur Wiseno Putra <gsenopu@gmail.com<= /a>> menulis:
Dear Russ and architectu= re-discuss,=C2=A0


I am new there, I have not kn= ow muc "how to": I think one needs to create an account in the In= ternet Society to join with OPEN FORUM Community to access its features:
https://www.internetsociety.org/become-a-member/


But at this architecture-discuss, where we are now, one may simply acce= ss its mail archives for the documents on "Consolidation of the Intern= et" --so it is nothing new but such a networked community of reading, = such a networked library:

https://mailarchive.ietf.org/arch/msg/architecture-discuss/sdTkLd7q7wXyfAnjJQlNceWPr8U

I find no search engine facility for documents at OPEN FORUM community Libr= ary while there is one at architecture-discuss mail archive.
=
Regard,
Guntur Wiseno Putra

Pada Jum= at, 31 Januari 2020, Russ Housley <housley@vigilsec.com> menulis:
Is there a way to see the document without creating an account?
Russ


= On Jan 29, 2020, at 4:37 AM, Guntur Wiseno Putra <gsenopu@gmail.com> wrote:

=
Dear architecture-discuss,

Documents related with t= he current issues on "consolidation of the Internet" saved in the= "Open Forum" community of the Internet Society:

--000000000000fe6903059d688341-- From nobody Thu Jan 30 22:26:37 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6B912008A for ; Thu, 30 Jan 2020 22:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.502 X-Spam-Level: * X-Spam-Status: No, score=1.502 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_WP_DIRINDEX=3.499] 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 v_dLvZoC9akc for ; Thu, 30 Jan 2020 22:26:34 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 1218312001E for ; Thu, 30 Jan 2020 22:26:34 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id r16so5605978otd.2 for ; Thu, 30 Jan 2020 22:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mKmrGE3tT8VN5gwCkHReIg2J27xWW5uCF7tRt3NeeiA=; b=iHntxE+tBAZ6W4TCjLHTrkUP0gtJF0iBteZ/Fd0K3ZeWqrwyJBNQhDqIsD+JMej8Ve 2vjS0EWmwPVRfUS34Bnu/3ywzj6dNWl2s/d3W5KVhiMEbrXYcrz1S96piDmaaG8V8O8Z /qMk983JahS6jvNb3VH+5vQ/O8Pf8qDpAaKV4ghSPUTKgv4LJQbQyXTrsgwJ+E411sC9 dy5RGNjTqftVeYnPNf17sVJwVVaQm/j/KV01+VySW0Q10wCmzrhlu9gQF2PcFwVhXyaN 5vuQc/jBstlIlSjQyNFYSzsAbPKouAi9pSWN7WOGFo2Hj2XcQF94GLG1ByKS6DnOO+Em U6XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mKmrGE3tT8VN5gwCkHReIg2J27xWW5uCF7tRt3NeeiA=; b=suJSkqfnmLOh2Aq1QL5MZXyNU2dgpNA9gEl8eO9ak/s18K7As3IeX/kur3qSd4ezIM VDKJJnf34bB8O0IXWTwqM7qVcmjU7QHDjUZeAJCGTBN+gpb8BzaR32WA/Xr+gnh3nUVo ep/gd4yrFvOuhMQqQiL4hKh21bpjMN5ER3H+mP179p9BTz38dm2GmCwFkspgbWLJXOIm hwBhJ6a4mhpglU8N4N2z0BajhcV1QhcRSQKD9IIrjED4VCy72xlmRFmAymYVffYeGTEH JPqrNx0E1r5+5lNvrYTfIblkZT3A15HOm2YvatJh5JGWDsMmDNzGjBqZRefS1FAeAFtI NPsw== X-Gm-Message-State: APjAAAWAwLfahxWefOaNngI6xRbv3kai7Pfgd3pB0MTjG+PBcV+XaMcB 4dxGKSFldgOH/HbiRMujAJqYWQi0G54sgju456QxgQ== X-Google-Smtp-Source: APXvYqxl/G/CbFO38OyqV5rQhJAffq099CwhWuTtglSZ7zgzW7pNNLeA9n7JULx//OjipTZK8Sy1VTdfXKSwWMOX+XA= X-Received: by 2002:a9d:831:: with SMTP id 46mr6682268oty.295.1580451993255; Thu, 30 Jan 2020 22:26:33 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Thu, 30 Jan 2020 22:26:32 -0800 (PST) In-Reply-To: References: <64D42558-19A2-469E-B027-B67FB52A5279@vigilsec.com> From: Guntur Wiseno Putra Date: Fri, 31 Jan 2020 13:26:32 +0700 Message-ID: To: Russ Housley Cc: "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a4828c059d69a76a" Archived-At: Subject: Re: [arch-d] Network Architecture in the Internet Society X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 06:26:36 -0000 --000000000000a4828c059d69a76a Content-Type: text/plain; charset="UTF-8" Dear Russ & architecture-discuss, I have just added Leva. T & H. Suommi's "Framework of Analyzing Feasibility of Internet Protocols" to the before-mentioned list of readings by "Add Comment" Facility in the OPEN FORUM Community Library: ### To the list of readings above (Consolidation of the Internet: from the Socio-Economic to the Architectural) may I add "Framework of Analyzing Feasibility of Internet Potocols" (Leva, T. & H. Suommi, the IAB Workshop on Internet Technology Adootion and Transition 2013) which was ever to be part of architecture-discuss@ietf.org "Centralization or diversity?" January 22th 2020: https://mailarchive.ietf.org/arch/msg/architecture-discuss/sdTkLd7q7wXyfAnjJQlNceWPr8U ### Note: To clarify what I said in the previous message: I mean the architecture-discuss@ietf.org and the OPEN FORUM Community Library may be about a networked community of reading, a networked library. Regard, Guntur Wiseno Putra Pada Jumat, 31 Januari 2020, Guntur Wiseno Putra menulis: > Dear Russ and architecture-discuss, > > The post in OPEN Forum Community Library is about those document saved in > the architecture-discuss mailarchive I mentioned above plus > > Arkko, Jarri et all., "Considerations on the Internet Consolidation and > the Internet Architecture", Internet-Draft, IETF, Expired April 2019 > https://tools.ietf.org/html/draft-arkko-iab-internet-consolidation-00 > > While, I have not included yet that of T. Leva and H. Suommi's... > > I emphasized on socio-economic and architectural learnings attempted by > those documents there--while the post at architecture-discuss emphazised on > feasibility of the Internet architecture in relation with aesthetic and > ethic experiences. > > This is what I saved in OPEN FORUM Community Library: > > "Consolidation of the Internet: From the Socio-Economic to the > Architectural" > > This documents refer to "Consolidation in the Internet" which is of > economic and architectural approaches and perspectives: > > - ISOC Global Internet Report Consolidation in the Internet Economy > https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/ > 04/InternetSociety-GlobalInternetReport-ConsolidationintheInternetEcon > omy.pdf > - Arkko, Jarri et all., "Considerations on the Internet Consolidation and > the Internet Architecture", Internet-Draft, IETF, Expired April 2019 > https://tools.ietf.org/html/draft-arkko-iab-internet-consolidation-00 > - Sullivan, Andrew, "Three Kinds of Concentration in Open Protocols", > IAB-DEDR Workshop 2019 https://www.iab.org/wp-content/IAB-uploads/2019/05/ > p7-sulllivan-three_kinds_concentration_ajs_dedr.pdf > - Arkko, Jarri, "Centralized Architecture in Internet Architecture", > Internet Draft, 2019 > https://www.ietf.org/id/draft-arkko-arch-infrastructure- > centralisation-00.txt > Kutscher, Dirk, "Protocol Design and Socio-economic Realities", in the > IAB-DEDR Workshop 2019 > https://www.iab.org/wp-content/IAB-uploads/2019/05/ > p14-kutscher-internet-design-kutscher.pdf > > > Note: This post is related with another one in this "Open Forum": > Restream: Internet Consolidation: What Lies beneath the Application > Layer..." (December 14th 2019) https://connect.internetsociety.org/ > communities/community-home/digestviewer/viewthread?GroupId=67&MessageKey= > 426220c6-e41e-45c8-8872-7f0cc455f492&CommunityKey=3a9fa082-a518-475d-9e7f- > ecec4ffe56dd&tab=digestviewer&ReturnUrl=%2fcommunities%2fcommunity-home% > 2fdigestviewer%3fCommunityKey%3d3a9fa082-a518-475d-9e7f-ecec4ffe56dd > > > > > > > > > Regard, > Guntur Wiseno Putra > > Pada Jumat, 31 Januari 2020, Guntur Wiseno Putra > menulis: > >> Dear Russ and architecture-discuss, >> >> >> I am new there, I have not know muc "how to": I think one needs to create >> an account in the Internet Society to join with OPEN FORUM Community to >> access its features: >> >> https://www.internetsociety.org/become-a-member/ >> >> >> But at this architecture-discuss, where we are now, one may simply access >> its mail archives for the documents on "Consolidation of the Internet" --so >> it is nothing new but such a networked community of reading, such a >> networked library: >> >> https://mailarchive.ietf.org/arch/msg/architecture-discuss/s >> dTkLd7q7wXyfAnjJQlNceWPr8U >> >> I find no search engine facility for documents at OPEN FORUM community >> Library while there is one at architecture-discuss mail archive. >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Jumat, 31 Januari 2020, Russ Housley menulis: >> >>> Is there a way to see the document without creating an account? >>> >>> Russ >>> >>> >>> On Jan 29, 2020, at 4:37 AM, Guntur Wiseno Putra >>> wrote: >>> >>> Dear architecture-discuss, >>> >>> Documents related with the current issues on "consolidation of the >>> Internet" saved in the "Open Forum" community of the Internet Society: >>> >>> >>> https://connect.internetsociety.org/viewdocument/consolidati >>> on-of-the-internet-from?CommunityKey=3a9fa082-a518-475d-9e7f >>> -ecec4ffe56dd&tab=librarydocuments#ItemCommentPanel >>> >>> Regard, >>> Guntur Wiseno Putra >>> >>> >>> --000000000000a4828c059d69a76a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Russ & architecture-discuss,


I h= ave just added Leva. T & H. Suommi's "Framework of Analyzing F= easibility of Internet Protocols" to the before-mentioned list of read= ings by "Add Comment" Facility in the OPEN FORUM Community Librar= y:


###
To the list of re= adings above (Consolidation of the Internet: from the Socio-Economic to the= Architectural) may I add "Framework of Analyzing Feasibility of Inter= net Potocols" (Leva, T. & H. Suommi, the IAB Workshop on Internet = Technology Adootion and Transition 2013) which was ever to be part of architecture-discuss@ietf.org "Centralization or diversity?" January 22th 2020:

https://mailar= chive.ietf.org/arch/msg/architecture-discuss/sdTkLd7q7wXyfAnjJQlNceWPr8U






Note:=C2=A0
T= o clarify what I said in the previous message:=C2=A0
I mean the <= a href=3D"mailto:architecture-discuss@ietf.org">architecture-discuss@ietf.o= rg and the OPEN FORUM Community Library may be about a networked commun= ity of reading, a networked library.






Regard,
=
Guntur Wiseno Putra

Pada Jumat, 31 Januari 2020, Guntur Wiseno = Putra <gsenopu@gmail.com> me= nulis:
Dear Russ and architecture-discuss= ,

The post =C2=A0in OPEN Forum Community Library is abou= t those document saved in the architecture-discuss mailarchive I mentioned = above plus=C2=A0

=C2=A0Arkko,= Jarri et all., "Considerations on the Internet Consolidation and the = Internet Architecture", Internet-Draft, IETF, Expired April 2019 https://tools.ietf.org/html/draft-arkko-iab-intern= et-consolidation-00=C2=A0

Wh= ile, I have not included yet that of T. Leva and H. Suommi's...<= /div>

I emphasized on socio-economic and architectural l= earnings attempted by those documents there--while the post at architecture= -discuss emphazised on feasibility of the Internet architecture in relation= with aesthetic and ethic experiences.

This is wha= t I saved in OPEN FORUM Community Library:

"C= onsolidation of the Internet: From the Socio-Economic to the Architectural&= quot;

This d= ocuments refer to "Consolidation in the Internet" which is of eco= nomic and architectural approaches and perspectives:

- ISOC Global Internet Report Consolidation in the I= nternet Economy https://future.internets= ociety.org/2019/wp-content/uploads/sites/2/2019/04/InternetSociet= y-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf= =C2=A0
- Arkko, Jarri et = all., "Considerations on the Internet Consolidation and the Internet A= rchitecture", Internet-Draft, IETF, Expired April 2019 https://tools.ietf.org/html/draft-arkko-iab-internet-= consolidation-00=C2=A0
- = Sullivan, Andrew, "Three Kinds of Concentration in Open Protocols"= ;, IAB-DEDR Workshop 2019 https://www.iab.org/wp-content/IAB-uploads/2019/05/p7-su= lllivan-three_kinds_concentration_ajs_dedr.pdf=C2=A0
- Arkko, Jarri, "Centralized Architec= ture in Internet Architecture", Internet Draft, 2019=C2=A0
https:/= /www.ietf.org/id/draft-arkko-arch-infrastructure-centralisation-0= 0.txt
Kutscher, Dirk, &qu= ot;Protocol Design and Socio-economic Realities", in the IAB-DEDR Work= shop 2019
https://www.iab.org/wp-content/IAB-upload= s/2019/05/p14-kutscher-internet-design-kutscher.pdf

= Note: This post is related with another one in this "Open Forum":= Restream: Internet Consolidation: What Lies beneath the Application Layer.= .." (December 14th 2019) https://connect.internetsociety.org= /communities/community-home/digestviewer/viewthread?GroupId= =3D67&MessageKey=3D426220c6-e41e-45c8-8872-7f0cc455f492&C= ommunityKey=3D3a9fa082-a518-475d-9e7f-ecec4ffe56dd&tab=3Ddige= stviewer&ReturnUrl=3D%2fcommunities%2fcommunity-home%2fd= igestviewer%3fCommunityKey%3d3a9fa082-a518-475d-9e7f-ecec4ffe56dd=




=




Rega= rd,
Guntur Wiseno Putra

Pada Jumat, 31 Januari 2020, Guntu= r Wiseno Putra <g= senopu@gmail.com> menulis:
Dear Ru= ss and architecture-discuss,=C2=A0


I am new the= re, I have not know muc "how to": I think one needs to create an = account in the Internet Society to join with OPEN FORUM Community to access= its features:

https://www.internetsociety.org/become-a-member/


But at this architecture-discuss, where we are now, one may simply acce= ss its mail archives for the documents on "Consolidation of the Intern= et" --so it is nothing new but such a networked community of reading, = such a networked library:

https://mailarchive.ietf.org/arch/msg/architecture-discuss/sdTkLd7q7wXyfAnjJQlNceWPr8U

I find no search engine facility for documents at OPEN FORUM community Libr= ary while there is one at architecture-discuss mail archive.
=
Regard,
Guntur Wiseno Putra

Pada Jum= at, 31 Januari 2020, Russ Housley <housley@vigilsec.com> menulis:
Is there a way to see the document without creating an account?
Russ


= On Jan 29, 2020, at 4:37 AM, Guntur Wiseno Putra <gsenopu@gmail.com> wrote:

=
Dear architecture-discuss,

Documents related with t= he current issues on "consolidation of the Internet" saved in the= "Open Forum" community of the Internet Society:

--000000000000a4828c059d69a76a-- From nobody Fri Jan 31 21:07:12 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F0012001A for ; Fri, 31 Jan 2020 21:07:08 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1nUn7B-82Bl for ; Fri, 31 Jan 2020 21:07:06 -0800 (PST) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508DB120048 for ; Fri, 31 Jan 2020 21:07:06 -0800 (PST) Received: by mail-oi1-x234.google.com with SMTP id q81so9574097oig.0 for ; Fri, 31 Jan 2020 21:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sch8ub/dQod7KZ8ggFeUL9LyHaCtvPwqU/NqziGECJ0=; b=HvVkxhOlpZRUR4kti/t2m64zvSZY9p5SPresuXOSi5ZSzWol+hblrykAdRK2xNVQAu zETbvZiQIl6LxOBt+1AjtXR6VS5JGyKOFRXXVxFb5RyeMWA8/0b9q+dqMUbPgLYZRhAT doRiW5/PW1cxE2U5wDiKXFJW47TybArfmh+eRzNdtTWoFTxBVoOc0ErB6ONkNneufwiD oaWmTmrhFtHMG9nhrHB9X9FjlnbVOlDU/so7jKlg5PURxlOn3y8YhYk+wPt0kCRt/BIF y3O1ipJtMDgjimAdaL6PvHSHbK7RTuLXfblT2Xmi4vsSZUY3QUMDBl6JeEHTIXCdbwPi a+HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Sch8ub/dQod7KZ8ggFeUL9LyHaCtvPwqU/NqziGECJ0=; b=ZmP8klKBFZoAAieGwAKkt1dHf4+kwElqwHQFKmN+CM8YPCJtk9oVO9ux9FlkViVCC4 1WZZJ4FfNjXgpGfDlombBMFmVIivT7r6AEJb0I56/O+pEoM36+mL6v6gyqnU2YIvekMH aWtB/UlslLLzh9DaI0HMM/TXuhmR5u/280yUmsbZgCTTmJ4+uPYEEHxf2eBjaiw1WekK /6rGEDAWTdpNQK2USAnyl68+6Nfx0No17vL0Psh913i36Kb0Qn/Xz+UF1yCHnrynxvmr uy0ErmwTkkhvhwO1E+9Z2XkEL5OXGWmZw2T2ymxrxYPuZShpfcpG5CySq9sRsUiP3vLx e6bA== X-Gm-Message-State: APjAAAU+vBhx3CLtGI47dmgPq50CSBJBFDARmaFgStX70nzLdpQDop5B WQOzx8pWuepO/2uCoOPKllKwf0JZEUupqVQT2VI1QA== X-Google-Smtp-Source: APXvYqyBasoZT0F1yA4t1BNYENYXg2BGKvSYtXqg9cP14SfDwbn6BHEQRbwti1XG6yvSn6IO5DlFMnmjRc4PcEBKEm0= X-Received: by 2002:aca:f587:: with SMTP id t129mr6733739oih.143.1580533625548; Fri, 31 Jan 2020 21:07:05 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Fri, 31 Jan 2020 21:07:04 -0800 (PST) In-Reply-To: References: From: Guntur Wiseno Putra Date: Sat, 1 Feb 2020 12:07:04 +0700 Message-ID: To: Eric Rescorla Cc: Jari Arkko , "architecture-discuss@ietf.org" , "model-t@iab.org" Content-Type: multipart/alternative; boundary="0000000000004e7382059d7ca917" Archived-At: Subject: Re: [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 05:07:09 -0000 --0000000000004e7382059d7ca917 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss, Parts concerning with "the Internet security" today at Internet Society: Internet Society 2020 Action Plan - We believe deeply that the Internet must be open, globally-connected, secure, and trustworthy. - In 2020, we will continue to work towards realizing our vision by building, promoting, and defending a bigger and stronger Internet. II. Strengthening the Internet -- Promoting the Internet way of networking -- Extending encryption -- Securing global routing -- Increasing time security -- Leading by example with open standards and protocols https://www.internetsociety.org/action-plan/2020/ 2020 Action Plan Projects Strengthening the Internet - Internet Way of Networking - Encryption - Securing Global Routing (MANRS) - Time Security - Open Standards Everywhere https://www.internetsociety.org/action-plan/2020/projects/ Regard, Guntur Wiseno Putra Pada Kamis, 30 Januari 2020, Eric Rescorla menulis: > > There is relatively broad agreement that the roles and trustwortiness > > of different endpoints in a protocol exchange are important > > considerations. In specific cases there may be quite different > > perspectives on the tradeoffs involved, e.g., to what extent privacy, > > information centralisation, or the needs of enterprise networks should > > be considered as the highest priority. And no doubt, other equally > > valid perspectives exist. > > Actually, it's not clear to me that *any* of these are valid > things to put in a threat model. Recall what 3552 says a threat > model is: > > A THREAT MODEL describes the capabilities that an attacker is assumed > to be able to deploy against a resource. It should contain such > information as the resources available to an attacker in terms of > information, computing capability, and control of the system. The > purpose of a threat model is twofold. First, we wish to identify the > threats we are concerned with. Second, we wish to rule some threats > explicitly out of scope. Nearly every security system is vulnerable > to a sufficiently dedicated and resourceful attacker. > > But none of the things you list are really part of a threat model. > > Rather, they are weights one applies to various design considerations, > but that's a consideration but that's a form of analysis that happens > *after* you have a threat model, not part of the threat model itself. > For instance, I don't think anyone thinks that privacy threats (e..g., > traffic analysis) aren't part of our threat model (and they're clearly > part of the 3552 threat model). Now, as a matter of protocol design, > we have often opted not to do much about these threats for practical > reasons, but that's a different matter. > > As Brian said, the purpose of 3552 is to force protocol designers > to describe the security properties of their protocols and the purpose > the threat model section is to provide a common starting point for > that analysis. IOW, it is an essentially tutorial function So to the > extent to which an update for 3552 is needed, its purpose should be to > make clear considerations which aren't otherwise obvious from the text > in 3552. But that's not about a new threat model or about balancing > but rather about documentation. > > -Ekr > > > > > On Fri, Jan 24, 2020 at 3:50 AM Jari Arkko wrote: > >> >> The IAB are considering starting up a programme on Internet >> trust model evolution as described in the link at the bottom of this >> email. >> >> We'd like to get feedback on that idea and the text. As you may >> be aware, in 2019 a number of documents were published on >> this topic and discussions held (on the mailing list, SAAG, side >> meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual >> meeting coming up on February 14th. >> >> To be clear, any output from this program would be text offered >> to the IETF for consideration - it is not within the IAB's remit, nor >> that of an IAB program, to modify a BCP. Nonetheless, an IAB >> program offers a good venue for this work, as it perhaps allows >> for more focus on the evolving architecture aspect within this space. >> >> The plan is for the new program to be entirely open for participation, >> similar to how the current work has already been. That is, the mailing >> list is open for all interested to join, meetings are open and listed >> in the public agendas. The IAB will find a chair or chairs for the >> group to stay organised. >> >> There's no specific deadline for this, but the IAB will consider this >> further in the next few weeks, so if you could take a few minutes >> to share your thoughts on this that'd be great. >> >> https://github.com/intarchboard/model-t-charter/ >> blob/master/model-t-charter-00.md >> https://www.iab.org/mailman/listinfo/model-t >> >> Stephen & Jari >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > --0000000000004e7382059d7ca917 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

Parts concerning with "t= he Internet security" today at Internet Society:

Internet Society 2020 Action Plan

- We believe deeply that the Internet must be open, globally-connected, sec= ure, and trustworthy.

- In 2020, we will continue to work towards realizing our vision by buildin= g, promoting, and defending a bigger and stronger Internet.

=C2=A0II. Strengthening the Internet

-- Promoting the Internet way of networking

-- Extending encryption

-- Securing global routing

-- Increasing time security

-- Leading by example with open standards and protocols


https://www.i= nternetsociety.org/action-plan/2020/


2020 Action Plan Projects

Strengthening the Internet

- Internet Way of Networking
- Encryption
- Securing Global Routing (MANRS)
- Time Security
- Open Standards Everywhere


http= s://www.internetsociety.org/action-plan/2020/projects/

Regard,
Guntur Wiseno Putra

Pa= da Kamis, 30 Januari 2020, Eric Rescorla <ekr@rtfm.com> menulis:
> There is relatively broad agreement that the roles and trustw= ortiness
> of different endpoints in a protocol exchange are importan= t
> considerations. In specific cases there may be quite different> perspectives on the tradeoffs involved, e.g., to what extent privacy,=
> information centralisation, or the needs of enterprise networks sh= ould
> be considered as the highest priority. And no doubt, other equ= ally
> valid perspectives exist. =C2=A0

Actually, it's not= clear to me that *any* of these are valid
things to put in a threat mod= el. Recall what 3552 says a threat
model is:

=C2=A0 =C2=A0A THREA= T MODEL describes the capabilities that an attacker is assumed
=C2=A0 = =C2=A0to be able to deploy against a resource.=C2=A0 It should contain such=
=C2=A0 =C2=A0information as the resources available to an attacker in t= erms of
=C2=A0 =C2=A0information, computing capability, and control of t= he system.=C2=A0 The
=C2=A0 =C2=A0purpose of a threat model is twofold.= =C2=A0 First, we wish to identify the
=C2=A0 =C2=A0threats we are concer= ned with.=C2=A0 Second, we wish to rule some threats
=C2=A0 =C2=A0explic= itly out of scope.=C2=A0 Nearly every security system is vulnerable
=C2= =A0 =C2=A0to a sufficiently dedicated and resourceful attacker.

But = none of the things you list are really part of a threat model.

Rathe= r, they are weights one applies to various design considerations,
but th= at's a consideration but that's a form of analysis that happens
= *after* you have a threat model, not part of the threat model itself.
Fo= r instance, I don't think anyone thinks that privacy threats (e..g.,traffic analysis) aren't part of our threat model (and they're cle= arly
part of the 3552 threat model). Now, as a matter of protocol design= ,
we have often opted not to do much about these threats for practicalreasons, but that's a different matter.

As Brian said, the pur= pose of 3552 is to force protocol designers
to describe the security pro= perties of their protocols and the purpose
the threat model section is t= o provide a common starting point for
that analysis. IOW, it is an essen= tially tutorial function So to the
extent to which an update for 3552 is= needed, its purpose should be to
make clear considerations which aren&#= 39;t otherwise obvious from the text
in 3552. But that's not about a= new threat model or about balancing
but rather about documentation.
=
-Ekr




On Fri, Jan 24, 2020 at 3:50 AM Jari Arkko <jari.arkko@piuha.net<= /a>> wrote:
<= div>

The IAB are considering starting up a programme on Internettrust model evolution as described in the link at the bottom of this
em= ail.

We'd like to get feedback on that idea and the text. As you= may
be aware, in 2019 a number of documents were published on
this t= opic and discussions held (on the mailing list, SAAG, side
meeting at IE= TF-106, workshops, etc). There=E2=80=99s also a virtual
meeting coming u= p on February 14th.

To be clear, any output from this program would = be text offered=C2=A0
to the IETF for consideration - it is not within t= he IAB's remit, nor=C2=A0
that of an IAB program, to modify a BCP. N= onetheless, an IAB=C2=A0
program offers a good venue for this work, as i= t perhaps allows=C2=A0
for more focus on the evolving architecture aspec= t within this space.

The plan is for the new program to be entirely = open for participation,
similar to how the current work has already been= . That is, the mailing
list is open for all interested to join, meetings= are open and listed
in the public agendas. The IAB will find a chair or= chairs for the
__________________________= _____________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinf= o/architecture-discuss
--0000000000004e7382059d7ca917-- From nobody Fri Jan 31 23:27:36 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0015D12004F for ; Fri, 31 Jan 2020 23:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.501 X-Spam-Level: * X-Spam-Status: No, score=1.501 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_HELO_NONE=0.001, SPF_PASS=-0.001, URI_WP_DIRINDEX=3.499] 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 0nWB1Z4cZg-0 for ; Fri, 31 Jan 2020 23:27:32 -0800 (PST) Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (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 1ABCE120018 for ; Fri, 31 Jan 2020 23:27:32 -0800 (PST) Received: by mail-ot1-x344.google.com with SMTP id r16so8900330otd.2 for ; Fri, 31 Jan 2020 23:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wBYUtreRou3RK3Q5gExw09u9wmTZ8flN2AR3iWDzWUw=; b=AMBWl3WCSpFUGqtspTEV3yvqklXK7mi35IFSLJEQoYMgMf7z89QV0xSJRWWqMMdQgI YfUi0NINB7Jera2f0dXaH6PgXU/jZs8JlqJ9cX4y7GqAVS4+esp27x93rc4vWQ6aaFcy 2JfOIhkdjWjjoEfcEuCM5iMXBX9IW/sCPUo+fLDIcKi8aiJ2TNBZtpXH28kgU6iF8YHk ObgY9MjUk3jQsOlYIdbVxvHou+Cky61SFGLIRIb2OXQoKLt+vU38TfXEiW2bnkcXCAJZ aNddR0ddMQmgxtswM6rriQjRJQYKDaMYoYtbv/Ly1Lh4HDcmRfxb2JDjzajEdovHiEOQ Qklg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wBYUtreRou3RK3Q5gExw09u9wmTZ8flN2AR3iWDzWUw=; b=pQ+BKAsn3Ko156aVJY1DqwmzoJPemUHV0T4hERTXI4sExcU/xCzoxkASF5LMwUDkcU XxVuUZZwU4SiaOKbB9G5mOrc5J68DqzgoqRkeNSAP1cfO40IWa+ZynP1lukqF21sxFMp sAOqzfahYz1bg0x6yi2dJ0TX74uNUGo5rh5xXdYdTV2ma8rLxaTSiH1Ma0JFAdIs7xfb DGG2Ve5JXSx9aV3y1s5h07TiLR9Lsm6STuNJg04ryZjGZNzv2z9C2Sq2eYwjFYY0jpBV b1dwdPLDPWZaIit7BvsRrj9hZvF1A831jrFq3hIG6xHPaWD43rLFiwG1wsYYExqUz1Eu ItcA== X-Gm-Message-State: APjAAAXLaizk5rMUvH+QuZwh7a4UkuRP/E5yIhldn4jqJ6Vzc5rZsenQ Xnz0VzDOaGj+YzG54+gAcL93OWdMTxwHRIT2B3s= X-Google-Smtp-Source: APXvYqy1Vv78ClL2wZ7kYcgv02HEdl84lNhflCNR+0xZph/kKN2FjsmIgSezrIOJNYoan879YXV4wem+mbwikKXD/SU= X-Received: by 2002:a9d:831:: with SMTP id 46mr10858287oty.295.1580542051167; Fri, 31 Jan 2020 23:27:31 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Fri, 31 Jan 2020 23:27:30 -0800 (PST) In-Reply-To: References: <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> <265A560E-F07F-4CB8-8D5F-6077D1419CE5@comcast.net> <20200109094537.GY8801@faui48f.informatik.uni-erlangen.de> From: Guntur Wiseno Putra Date: Sat, 1 Feb 2020 14:27:30 +0700 Message-ID: To: Toerless Eckert Cc: John Day , Andrew Campling , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000833302059d7e9f8e" Archived-At: Subject: Re: [arch-d] Centralization or diversity X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 07:27:35 -0000 --000000000000833302059d7e9f8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss, As it is about this thread of discussion: "Internet Way of Networking" Governments are increasingly moving towards sovereignty-based approaches to the Internet. At the same time, a winner-takes-all global economy means that a few major gatekeepers have control over Internet data and infrastructure. Both state and market-driven centralization are risks to the decentralized Internet way of networking. Centralization encourages single points of failure and moves away from the open and voluntary set of standards and practices that have sustained the Internet as a source of innovation and economic growth. These systemic risks to the global Internet=E2=80=99s future, and to the Internet Society=E2=80=99s core visio= n, require a broad and sustained response....". It is part of 2020 Internet Society Action Plan Projects: https://www.internetsociety.org/issues/internet-way-of-networking/ Regard, Guntur Wiseno Putra Pada Rabu, 22 Januari 2020, Guntur Wiseno Putra menulis= : > Dear architecture-discuss, > > > > The Feasible: > Aesthetics and Ethics of the Internet Architecture...? > > > Actualities to consider: what are called "consolidation in the Internet > economy" or "concentration in open protocols" or "Centralized Architectur= e > of Internet Infrastructure" (1). > > > To the actuality mentioned above, feasibility of protocols is about > particular cases and contexts and solutions when aesthetics and ethics of > (social and technical/the Internet) environments is to be the plan: that = is > what we find in one of the past/2013 IAB "Framework for Analyzing > Feasibility of Internet Protocols" (Leva, T. & H. Suommi): It proposed > steps to deal with/to attempt an analysis of the feasibility of protocols > of which it mentioned about "technical architecture", "value networks" an= d > "deployment environment" in its steps. (2) > > > > > > (1) https ISOC > https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/ > 04/InternetSociety-GlobalInternetReport-ConsolidationintheInternetEcon > omy.pdf > > Sullivan, Andrew, "Three Kinds of Concentration in Open Protocols", > IAB-DEDR Workshop 2019 > https://www.iab.org/wp-content/IAB-uploads/2019/05/ > p7-sulllivan-three_kinds_concentration_ajs_dedr.pdf > > Arkko, Jarri, "Centralized Architecture inInternet Architecture", Interne= t > Draft, 2019 > https://www.ietf.org/id/draft-arkko-arch-infrastructure- > centralisation-00.txt > > > (2) https://www.iab.org/wp-content/IAB-uploads/2013/06/ > itat-2013_submission_4.pdf > It is part of the IAB-ITAT 2013 > https://iab.org/activities/workshops/itat/ > To add, there are meanings and values in human existences/experiences; > here, "value networks" is a similar phrase to "networks of interests" > --among others aesthetic and ethic ones and socio-economic ones mentioned > in "Protocol Design and Socio-economic Realities" (Kurtscher, D. in the > IAB-DEDR Workshop 2019) > https://www.iab.org/wp-content/IAB-uploads/2019/05/ > p14-kutscher-internet-design-kutscher.pdf > > > Regard, > Guntur Wiseno Putra > > Pada Jumat, 17 Januari 2020, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> I think these posts have relevances, as approaches and perspectives (for >> interpretations and evaluations), to this issue "Centralization or >> Diversity ("Centralized Architecture of Internet Infrastructure") ": The= y >> were about "Networks of Interests in Cyberspace, in Internet" and >> "Aesthetics and Ethics of Cyberspace, of Internet" with a horizon of >> layers of the social and engineering: >> >> https://mailarchive.ietf.org/arch/msg/architecture-discuss/1 >> qsfPOKu2TqbmstHg6UOAfU7NoM >> >> https://mailarchive.ietf.org/arch/msg/architecture-discuss/l >> P1_e4ZqEYkNTFlb6N6fommrGy0 >> >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Jumat, 10 Januari 2020, Guntur Wiseno Putra >> menulis: >> >>> Dear architecture-discuss, >>> >>> Adding what I mentioned in the previous message (in trying to learn on >>> "Networks conditions"): >>> >>> "diversity/heterogeneity" seems contradictory to "centralization" when >>> the latter is about "uniformity"...? >>> >>> Of "blobs" (1) there are moments of active elements or primitives, a >>> corresponding force of attractions, of fusions, of inflection, and of >>> deformations: Does "centralization" in Internet infrastructure not >>> represent those moments...? >>> >>> Thinking also about disciplinary interactions (thus, moments of >>> disciplines) having a moment of complexity and flexibility: does such a= n >>> analogue works for "networks conditions" to say that moments of diversi= ties >>> have also moments of uniformities...? >>> >>> >>> (1) The quotation is fully presented below (it is how Brian Massumi >>> define what Greg Lynn speaks as "blob"): >>> "active elements or 'primitives' which combine to generate their own >>> space. Each blob is differentiated. It is assigned (by the programmer) = a >>> circumference, a mass, and a corresponding force of atttaction. The for= ce >>> of attraction defines a field of influence outside the perimeter of the >>> blob, and that field is in turn differentiated into zones. Closest to t= he >>> perimeter is a zone of fusion. Any blob entering it will combine with t= he >>> first blob to form a larger blob. Beyond the fusion zone is a zone of >>> inflection, the area within which the atttactive force of the blob will >>> alter the shape, and therefore the field of influence, of a neighbourin= g >>> blob. Put a number of blob together, and their differential influenced = on >>> each other produce unpredictable reciprocal deformations. (Massumi 1995= ) >>> >>> >>> Regard, >>> Guntur Wiseno Putra >>> >>> Pada Jumat, 10 Januari 2020, Guntur Wiseno Putra >>> menulis: >>> >>>> Dear architecture-discuss, >>>> >>>> (It seems contradictory yet happen: "centralization" to >>>> "diversity/heterogeneity" as a network condition...?) >>>> >>>> Toward the problematic issues on "centralization" on Internet practice= , >>>> such a way to arrive there is about (re)considering "network condition= s": >>>> here we meet with diversity/heterogeneity as the Internet draft mentio= ned >>>> "Centralized Architecture on Internet Infrastructure". What does it me= an by >>>> "centralization" thus...? --how does it work/mean/value for >>>> diversity/heterogeneity...? >>>> >>>> For diversity/heterogeneity as a network condition we may refer to >>>> "liquid architecture" (1) of which other things with nuances deserve t= o >>>> mention: "bloobs"(2), "plasm"(3), "plasmatic"(4) and "plasmatics"(5). = Thus >>>> we are also saying about a spatial analysis of a network condition as= it >>>> is about cyberspace, about Internet --and we may plan things strategic= ally >>>> about the space... >>>> >>>> - we may think of Internet as one among other collective matters yet i= t >>>> is also one among other personal matters: those matters are maintaini= ng >>>> dialogues. Is it not so...in considering Internet sustainability? --at >>>> least we find that Internet has a significance for planning societies = of >>>> nations initiated by the United Nations (see "Leveraging Tech...") >>>> >>>> >>>> (1) "...Liquid architecture makes liquid cities, cities that change at >>>> the shift of a value, where visitors with different backgrounds sec >>>> different landmarks, where neighborhoods vary with ideas held in commo= n, >>>> and evolve as the ideas mature or dissolve". (Novak, Marcos, "Liquid >>>> Architecture in Cyberspace" (1991) >>>> https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf= ) >>>> >>>> (2) "bloobs" refers to "active element or primitive generatiing their >>>> own spaces... (with possibilities of) unpredictable reciprocal >>>> deformations". >>>> (Massumi, Brian, "Interface and Active Space", in Cheetam, M. A, >>>> "Kant, Art and Art History: Moments of Disciplines, Cambridge Universi= ty >>>> Press, Cambridge et all., 2001, p. 25; Cheetam refered Massumi's "Inte= rface >>>> and Active Space: Human-Machine Design" available at http://www >>>> anu.edu/HRC/first_and_last/links/massumi_works.htm) >>>> >>>> (3) plasm refers to "a mould of matrix in which something is cast or >>>> formed"; "plasma" refers to "living matter of a cell" and to "liquid p= art >>>> of blood in which corpuscles float"; then, plasmatic refers to what is >>>> related with "plasm" or "plasma". "Plasmatic" may be applied to refer = to >>>> "disciplinary interactions ...(having) ...multidimensional and shiftin= g >>>> cultural intensities, and that the specific contours of this matric ar= e >>>> inflected historically by the forces of which it is comprised ... (--)= ...a >>>> model of complexity and flexibility allowing us to understand how an a= ctive >>>> element in the system... can shape and be shaped by disciplines. (Chee= tam, >>>> M. A, "Kant, Art and Art History: Moments of Disciplines, Cambridge >>>> University Press, Cambridge et all., 2001, p. 25) >>>> >>>> Regard, >>>> Guntur Wiseno Putra >>>> >>>> Pada Kamis, 09 Januari 2020, Toerless Eckert menulis: >>>> >>>>> Good insights about the outcome of PICS. >>>>> >>>>> To clarify, i am primarily interested to see if we can do something >>>>> to better support static network planning and protocol evolution. >>>>> >>>>> Something which is more a self-declaration than a (broken) conformanc= e >>>>> suite "verified" testing result. Something which always must be >>>>> followed by appropriate testing (interop, deployment) depending >>>>> on the goal. But something that can help to faster get to that >>>>> step. Something to to help avoid horrenduously repetitive RFP questio= ns >>>>> by poor customers (does your IETF FOO protocol on your product suppor= t >>>>> the optional BAR feature). >>>>> >>>>> One could think of another axis of information in our yang models, >>>>> a subset of "implementation defined" behavior whose values can be >>>>> statically exposed without access to a live system and hence be >>>>> published and then used in netork planning for example >>>>> (or auto-collection by a curious WG trying to progress some >>>>> standard to full internet ;-)). >>>>> >>>>> I was interested in the type of information i remember to have seen >>>>> in the 90th in PICS, i am horrified about the process i learn >>>>> about it here in te thread ;-) >>>>> >>>>> Cheers >>>>> Toerless >>>>> >>>>> On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote: >>>>> > FWIW, there were also problems with keeping the test suites >>>>> up-to-date with the errata. Bugs could be fixed in the standards and >>>>> incorporated into implementations faster than the people developing t= he >>>>> test suites could keep up (or wanted to). Of course the fixes were in= the >>>>> implementations before they were in the standards. And what was worse= , when >>>>> pointed out to them that their test-suited didn???t conform to the sp= ec, >>>>> they didn???t care. They still insisted they were right. >>>>> > >>>>> > For some standards, it was possible to develop utilities that did a >>>>> specific function and used part of a standard to do that function but >>>>> didn???t need the rest of the standard. But the people running the te= st >>>>> suites couldn???t deal with it. If it didn???t implement the entire >>>>> protocol, it didn???t pass. The utility couldn???t cause any of the r= est of >>>>> the protocol to be generated. It conformed to the standard for everyt= hing >>>>> it did. They were using the standard as it had been intended. >>>>> > >>>>> > But the testers were effectively bean-counters and totally stupid. >>>>> > >>>>> > Conformance fell under the ANSI committee I chaired and I remember >>>>> writing them (some military base in Arizona whose name I have thankfu= lly >>>>> forgotten) nasty letters telling them to get their act together or ge= t out. >>>>> They were doing more harm than good. Wish we had known about the IS-I= S >>>>> issues as well to add to the list. >>>>> > >>>>> > One needs some way to test implementations before trying them live. >>>>> But one has to treat them (and it has to be instilled in the testers)= that >>>>> the purpose is to help: obey Postel???s rule, find problems, and the= n >>>>> determine whether it is the tests, the ???standard??? or the new >>>>> implementation that is at fault. And above all if it isn???t external= ly >>>>> visible, it is none of the tester???s business. Even if there is ???= formal >>>>> specification???, one can???t be sure that a bug is in the prose, the >>>>> formal spec, the tests, or the implementation. They are all suspect. = (Often >>>>> formal specifications are more complex than the code. And we know wha= t that >>>>> means!) >>>>> > >>>>> > Years before the standards issues arose, I did a survey of testing >>>>> methods for our own use. I expected to find that two or three were pr= etty >>>>> effective, pick one or two. What I found were 20 or 25 that were all >>>>> pretty effective and the advice was pick 2 or 3 and it didn???t reall= y >>>>> matter which ones as long as they were different. (Not the result I w= as >>>>> looking for.) ;-) >>>>> > >>>>> > Take care, >>>>> > John >>>>> > >>>>> > > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote: >>>>> > > >>>>> > > >>>>> > >> Yes, i was thinking of ISO PICS. But i lost track of those ISO >>>>> standards >>>>> > >> since the 90th. I guess i would have to see a successfull and >>>>> still >>>>> > >> currently used standard and how its PICS do or do not help. Just >>>>> > >> not alot of those ISO specs left in wide deployments, right. >>>>> > >> X.500 ? Maybe i can get more insight from the security community= . >>>>> > > >>>>> > > >>>>> > > You need not go that far. Remember IS-IS? Still thriving. >>>>> > > >>>>> > > And yes, my experience with PICs and test suites comes from that. >>>>> > > >>>>> > > >>>>> > >>> What it does do is to encourage people to write ???conformance >>>>> test suites???. These then get sold to unsuspecting customers and >>>>> end-users. Unfortunately, the quality of such suites is so low that = you >>>>> spend way, way, way more time debugging the test suite and you never = find >>>>> bugs in your implementation. >>>>> > >> >>>>> > >> This is just the worst possible outcome, and i am sure one can >>>>> learn >>>>> > >> from those bad experiences. Just think of taking a more organize= d >>>>> > >> step towards being able to collect protocol implementation >>>>> information >>>>> > >> from the industry. Right now every WG who wants to raise the >>>>> level of >>>>> > >> an IETF protocol, e.g.: to(wards) full standard is coming up wit= h >>>>> a >>>>> > >> questionaire in an ad-hoc fashion (we're just doing this in >>>>> Multicast >>>>> > >> for IGMP/MLD). >>>>> > > >>>>> > > >>>>> > > You can do that if you like, but the one proven, effective method >>>>> is interoperability testing. >>>>> > > >>>>> > > Running code trumps questionaires, conformance test suites, >>>>> theory, and mandate. >>>>> > > >>>>> > > >>>>> > >> My point was: If the only murphy you have is competitive >>>>> pressure, it works not >>>>> > >> it there is only limited competition, such as a total of maybe n= o >>>>> > >> more than 3 competing national infrastructures. >>>>> > > >>>>> > > >>>>> > > And countries that stifle competition inflict vendor lock on >>>>> themselves. >>>>> > > >>>>> > > >>>>> > >> See above. The best i think we (IETF) can do is to educate bette= r >>>>> about >>>>> > >> this by appropriate documents. Certainly some additional protoco= l >>>>> work >>>>> > >> will result from that. I for once had simple slides 10 years ago >>>>> how to fixup >>>>> > >> non-dual plane networks to be dual-plane. And maybe we can come >>>>> up with >>>>> > >> questionaires to get better numbers from actual deployments (the >>>>> > >> PICS discussion). >>>>> > > >>>>> > > >>>>> > > The IETF???s job is not education. It does not work as the >>>>> education is not requested >>>>> > > and not welcome. The IETF???s job is standards and it needs to >>>>> focus on that. >>>>> > > >>>>> > > >>>>> > >> Figuring out ideas for a complete ecosystem of monetization and >>>>> > >> deployment between competition and regulation is better left for >>>>> > >> an ongoing bar-bof with emphasis on bar. >>>>> > > >>>>> > > >>>>> > > I concur. Let???s stop fooling ourselves into thinking that >>>>> anything that the IAB/IETF writes has any impact >>>>> > > on regulation or economics. >>>>> > > >>>>> > > >>>>> > >> Actually one of the interesting conclusions was that dual-plane = in >>>>> > >> many cases is really free but deployments often just don't fully >>>>> > >> utilize it. >>>>> > > >>>>> > > >>>>> > > I???d agree that it???s close to free. If you accept that you >>>>> need a dual-plane approach for resiliency, then >>>>> > > adding a second vendor to the mix is relatively easy. There???s >>>>> additional cost because of decreased >>>>> > > purchasing volume. There???s additional costs in management and >>>>> operations. >>>>> > > >>>>> > > However, as compared to the costs of an unnecessary outage, it???= s >>>>> still trivial. >>>>> > > >>>>> > > Tony >>>>> > > >>>>> > > _______________________________________________ >>>>> > > Architecture-discuss mailing list >>>>> > > Architecture-discuss@ietf.org >>>>> > > https://www.ietf.org/mailman/listinfo/architecture-discuss >>>>> >>>>> -- >>>>> --- >>>>> tte@cs.fau.de >>>>> >>>>> _______________________________________________ >>>>> Architecture-discuss mailing list >>>>> Architecture-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>>>> >>>> --000000000000833302059d7e9f8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

As it is about this thread of= discussion:

"Internet Way of Networking"= ;

Governments are= increasingly moving towards sovereignty-based approaches to the Internet. = At the same time, a winner-takes-all global economy means that a few major = gatekeepers have control over Internet data and infrastructure. Both state = and market-driven centralization are risks to the decentralized Internet wa= y of networking. Centralization encourages single points of failure and mov= es away from the open and voluntary set of standards and practices that hav= e sustained the Internet as a source of innovation and economic growth. The= se systemic risks to the global Internet=E2=80=99s future, and to the Inter= net Society=E2=80=99s core vision, require a broad and sustained response..= ..".


It is part of = 2020 Internet Society Action Plan Projects:

ht= tps://www.internetsociety.org/issues/internet-way-of-networking/



Regard,
Gunt= ur Wiseno Putra

Pada Rabu, 22 Januari 2020, Guntur Wiseno Putra <= gsenopu@gmail.com> menulis:
=
Dear architecture-discuss,



The Feasible:
Aesthetics and Ethics of the Internet Architecture...?


Actualities to consider: what are called "consolidation in the Interne= t economy" or "concentration in open protocols" or "Cen= tralized Architecture of Internet Infrastructure" (1).


To the actuality mentioned above, feasibility of protocols is about particu= lar cases and contexts and solutions when aesthetics and ethics of (social = and technical/the Internet) environments is to be the plan: that is what we= find in one of the past/2013 IAB "Framework for Analyzing Feasibility= of Internet Protocols" (Leva, T. & H. Suommi): It proposed steps = to deal with/to attempt an analysis of the feasibility of protocols of whic= h it mentioned about "technical architecture", "value networ= ks" and "deployment environment" in its steps. (2)





(1) https ISOC
https://future.internetsociety.org/2019/= wp-content/uploads/sites/2/2019/04/InternetSociety-GlobalInt= ernetReport-ConsolidationintheInternetEconomy.pdf

Sullivan, Andrew, "Three Kinds of Concentration in Open Protocols"= ;, IAB-DEDR Workshop 2019
https://www.iab.o= rg/wp-content/IAB-uploads/2019/05/p7-sulllivan-three_kinds_c= oncentration_ajs_dedr.pdf

Arkko, Jarri, "Centralized Architecture inInternet Architecture",= Internet Draft, 2019
https://www.ietf.org/id/draft-arkko-a= rch-infrastructure-centralisation-00.txt


(2) https://www.iab.org/wp-content/IA= B-uploads/2013/06/itat-2013_submission_4.pdf
It is part of the IAB-ITAT 2013
ht= tps://iab.org/activities/workshops/itat/
To add, there are meanings and values in human existences/experiences; here= , "value networks" is a similar phrase to "networks of inter= ests" --among others aesthetic and ethic ones and socio-economic ones = mentioned in "Protocol Design and Socio-economic Realities" (Kurt= scher, D. in the IAB-DEDR Workshop 2019)
https://www.iab.org/wp-content/IAB-uploads/2019/05/p14-kutscher-internet-design-kutsche= r.pdf


Regard,
Gun= tur Wiseno Putra

Pada Jumat, 17 Januari 2020, Guntur Wiseno Putra &l= t;gsenopu@gmail.com<= /a>> menulis:
Dear architecture-discus= s,

I think these posts have relevances, as approaches an= d perspectives (for interpretations and evaluations), to this issue "C= entralization or Diversity ("Centralized Architecture of Internet Infr= astructure") ": They were about "Networks of Interests in Cy= berspace, in Internet" and =C2=A0"Aesthetics and Ethics of Cybers= pace, of Internet" with a horizon of layers of the social and engineer= ing:



<= br>
Regard,
Guntur Wiseno Putra

Pada Jumat, 10 J= anuari 2020, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

Adding what= I mentioned in the previous message (in trying to learn on "Networks = conditions"):=C2=A0

"diversity/hetero= geneity" seems contradictory to "centralization" when the la= tter is about "uniformity"...?

Of &quo= t;blobs" (1) there are moments of active elements or primitives, a cor= responding force of attractions, of fusions, of inflection, and of deformat= ions: Does "centralization" in Internet infrastructure not repres= ent those moments...?=C2=A0

Thinking also about = disciplinary interactions (thus, moments of disciplines) having a moment of= complexity and flexibility: does such an analogue works for "networks= conditions" to say that moments of diversities have also moments of u= niformities...?


(1) The quotatio= n is fully presented below (it is how Brian Massumi define what Greg Lynn s= peaks as "blob"):
"active elements or 'primit= ives' which combine to generate their own space. Each blob is different= iated. It is assigned (by the programmer) a circumference, a mass, and a co= rresponding force of atttaction. The force of attraction defines a field of= influence outside the perimeter of the blob, and that field is in turn dif= ferentiated into zones. Closest to the perimeter is a zone of fusion. Any b= lob entering it will combine with the first blob to form a larger blob. Bey= ond the fusion zone is a zone of inflection, the area within which the attt= active force of the blob will alter the shape, and therefore the field of i= nfluence, of a neighbouring blob. Put a number of blob together, and their = differential influenced on each other produce unpredictable reciprocal defo= rmations. (Massumi 1995)


Rega= rd,
Guntur Wiseno Putra

Pada Jumat, 10 Januari 2020, Guntu= r Wiseno Putra <g= senopu@gmail.com> menulis:
Dear ar= chitecture-discuss,

(It seems contradictory yet happen: = "centralization" to "diversity/heterogeneity" as a netw= ork condition...?)

Toward the problematic issues o= n "centralization" on Internet practice, such a way to arrive the= re is about (re)considering "network conditions": here we meet wi= th diversity/heterogeneity as the Internet draft mentioned "Centralize= d Architecture on Internet Infrastructure". What does it mean by "= ;centralization" thus...? --how does it work/mean/value for diversity/= heterogeneity...?

For diversity/heterogeneity as a= network condition we may refer to "liquid architecture" (1) of w= hich other things with nuances deserve to mention: "bloobs"(2), &= quot;plasm"(3), "plasmatic"(4) and "plasmatics"(5)= . Thus we are also =C2=A0saying about a spatial analysis of a network condi= tion as it is about cyberspace, about Internet --and we may plan things str= ategically about the space...

- we may think of In= ternet as one among other collective matters yet it is also one among other= personal matters: =C2=A0those matters are maintaining dialogues. Is it not= so...in considering Internet sustainability? --at least we find that Inter= net has a significance for planning societies of nations initiated by the U= nited Nations (see "Leveraging Tech...")

<= /div>

(1) "...Liquid architecture makes liquid= cities, cities that change at the shift of a value, where visitors with di= fferent backgrounds sec different landmarks, where neighborhoods vary with = ideas held in common, and evolve as the ideas mature or dissolve". (No= vak, Marcos, "Liquid Architecture in Cyberspace" (1991) =C2=A0=C2= =A0

=
(2) "bloobs" refers to "active element or primiti= ve generatiing their own spaces... (with possibilities of) unpredictable re= ciprocal deformations".=C2=A0
(Massumi, Brian, "Interfa= ce and Active Space", =C2=A0in Cheetam, M. A, "Kant, Art and Art = History: Moments of Disciplines, Cambridge University Press, Cambridge et a= ll., 2001, p. 25; Cheetam refered Massumi's "Interface and Active = Space: Human-Machine Design" available at=C2=A0= http://www=C2=A0anu.edu/HRC/first_and_last/links/massumi_w= orks.htm)

(3) plasm refers to "a mou= ld of matrix in which something is cast or formed"; "plasma"= refers to "living matter of a cell" and to "liquid part of = blood in which corpuscles float"; then, plasmatic refers to what is re= lated with "plasm" or "plasma". "Plasmatic" m= ay be applied to refer to "disciplinary interactions ...(having) ...mu= ltidimensional and shifting cultural intensities, and that the specific con= tours of this matric are inflected historically by the forces of which it i= s comprised ... (--) ...a model of complexity and flexibility allowing us t= o understand how an active element in the system... can shape and be shaped= by disciplines. (Cheetam, M. A, "Kant, Art and Art History: Moments o= f Disciplines, Cambridge University Press, Cambridge et all., 2001, p. 25)<= /div>

Regard,
Guntur Wiseno Putra

Pada = Kamis, 09 Januari 2020, Toerless Eckert <tte@cs.fau.de> menulis:
Good insights about the outcome of PICS.

To clarify, i am primarily interested to see if we can do something
to better support static network planning and protocol evolution.

Something which is more a self-declaration than a (broken) conformance
suite "verified" testing result. Something which always must be followed by appropriate testing (interop, deployment) depending
on the goal. But something that can help to faster get to that
step. Something to to help avoid horrenduously repetitive RFP questions
by poor customers (does your IETF FOO protocol on your product support
the optional BAR feature).

One could think of another axis of information in our yang models,
a subset of "implementation defined" behavior whose values can be=
statically exposed without access to a live system and hence be
published and then used in netork planning for example
(or auto-collection by a curious WG trying to progress some
standard to full internet ;-)).

I was interested in the type of information i remember to have seen
in the 90th in PICS, i am horrified about the process i learn
about it here in te thread ;-)

Cheers
=C2=A0 =C2=A0 Toerless

On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote:
> FWIW, there were also problems with keeping the test suites up-to-date= with the errata.=C2=A0 Bugs could be fixed in the standards and incorporat= ed into implementations faster than the people developing the test suites c= ould keep up (or wanted to). Of course the fixes were in the implementation= s before they were in the standards. And what was worse, when pointed out t= o them that their test-suited didn???t conform to the spec, they didn???t c= are. They still insisted they were right.
>
> For some standards, it was possible to develop utilities that did a sp= ecific function and used part of a standard to do that function but didn???= t need the rest of the standard. But the people running the test suites cou= ldn???t deal with it. If it didn???t implement the entire protocol, it didn= ???t pass. The utility couldn???t cause any of the rest of the protocol to = be generated. It conformed to the standard for everything it did. They were= using the standard as it had been intended.
>
> But the testers were effectively bean-counters and totally stupid.
>
> Conformance fell under the ANSI committee I chaired and I remember wri= ting them (some military base in Arizona whose name I have thankfully forgo= tten) nasty letters telling them to get their act together or get out. They= were doing more harm than good. Wish we had known about the IS-IS issues a= s well to add to the list.
>
> One needs some way to test implementations before trying them live.=C2= =A0 But one has to treat them (and it has to be instilled in the testers) t= hat the purpose is to help:=C2=A0 obey Postel???s rule, find problems, and = then determine whether it is the tests, the ???standard??? or the new imple= mentation that is at fault. And above all if it isn???t externally visible,= it is none of the tester???s business.=C2=A0 Even if there is ???formal sp= ecification???, one can???t be sure that a bug is in the prose, the formal = spec, the tests, or the implementation. They are all suspect. (Often formal= specifications are more complex than the code. And we know what that means= !)
>
> Years before the standards issues arose, I did a survey of testing met= hods for our own use. I expected to find that two or three were pretty effe= ctive, pick one or two.=C2=A0 What I found were 20 or 25 that were all pret= ty effective and the advice was pick 2 or 3 and it didn???t really matter w= hich ones as long as they were different. (Not the result I was looking for= .)=C2=A0 ;-)
>
> Take care,
> John
>
> > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote:
> >
> >
> >> Yes, i was thinking of ISO PICS. But i lost track of those IS= O standards
> >> since the 90th. I guess i would have to see a successfull and= still
> >> currently used standard and how its PICS do or do not help. J= ust
> >> not alot of those ISO specs left in wide deployments, right.<= br> > >> X.500 ? Maybe i can get more insight from the security commun= ity.
> >
> >
> > You need not go that far.=C2=A0 Remember IS-IS?=C2=A0 Still thriv= ing.=C2=A0
> >
> > And yes, my experience with PICs and test suites comes from that.=
> >
> >
> >>> What it does do is to encourage people to write ???confor= mance test suites???.=C2=A0 These then get sold to unsuspecting customers a= nd end-users.=C2=A0 Unfortunately, the quality of such suites is so low tha= t you spend way, way, way more time debugging the test suite and you never = find bugs in your implementation.
> >>
> >> This is just the worst possible outcome, and i am sure one ca= n learn
> >> from those bad experiences. Just think of taking a more organ= ized
> >> step towards being able to collect protocol implementation in= formation
> >> from the industry. Right now every WG who wants to raise the = level of
> >> an IETF protocol, e.g.: to(wards) full standard is coming up = with a
> >> questionaire in an ad-hoc fashion (we're just doing this = in Multicast
> >> for IGMP/MLD).
> >
> >
> > You can do that if you like, but the one proven, effective method= is interoperability testing.
> >
> > Running code trumps questionaires, conformance test suites, theor= y, and mandate.
> >
> >
> >> My point was: If the only murphy you have is competitive pres= sure, it works not
> >> it there is only limited competition, such as a total of mayb= e no
> >> more than 3 competing national infrastructures.
> >
> >
> > And countries that stifle competition inflict vendor lock on them= selves.
> >
> >
> >> See above. The best i think we (IETF) can do is to educate be= tter about
> >> this by appropriate documents. Certainly some additional prot= ocol work
> >> will result from that. I for once had simple slides 10 years = ago how to fixup
> >> non-dual plane networks to be dual-plane. And maybe we can co= me up with
> >> questionaires to get better numbers from actual deployments (= the
> >> PICS discussion).
> >
> >
> > The IETF???s job is not education. It does not work as the educat= ion is not requested
> > and not welcome. The IETF???s job is standards and it needs to fo= cus on that.
> >
> >
> >> Figuring out ideas for a complete ecosystem of monetization a= nd
> >> deployment between competition and regulation is better left = for
> >> an ongoing bar-bof with emphasis on bar.
> >
> >
> > I concur. Let???s stop fooling ourselves into thinking that anyth= ing that the IAB/IETF writes has any impact
> > on regulation or economics.
> >
> >
> >> Actually one of the interesting conclusions was that dual-pla= ne in
> >> many cases is really free but deployments often just don'= t fully
> >> utilize it.
> >
> >
> > I???d agree that it???s close to free.=C2=A0 If you accept that y= ou need a dual-plane approach for resiliency, then
> > adding a second vendor to the mix is relatively easy. There???s a= dditional cost because of decreased
> > purchasing volume. There???s additional costs in management and o= perations.
> >
> > However, as compared to the costs of an unnecessary outage, it???= s still trivial.
> >
> > Tony
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architec= ture-discuss

--
---
tte@cs.fau.de

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--000000000000833302059d7e9f8e--