From nobody Wed Nov 4 15:45:23 2020 Return-Path: X-Original-To: architecture-discuss@ietf.org Delivered-To: architecture-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BBB3A116E; Wed, 4 Nov 2020 15:45:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF Announcement List" Cc: architecture-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: architecture-discuss@ietf.org, iab@iab.org Message-ID: <160453351752.27540.10771835509098701325@ietfa.amsl.com> Date: Wed, 04 Nov 2020 15:45:17 -0800 Archived-At: Subject: [arch-d] Call for Comment: (Report from the IAB workshop on Design Expectations vs. Deployment Reality in Protocol Development) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2020 23:45:18 -0000 This is an announcement of an IETF-wide Call for Comment on draft-iab-dedr-report-01. The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection at: The Call for Comment will last until 2020-12-02. Please send comments to architecture-discuss@ietf.org and iab@iab.org. Abstract The Design Expectations vs. Deployment Reality in Protocol Development Workshop was convened by the Internet Architecture Board (IAB) in June 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration. From nobody Mon Nov 9 09:09: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 B36D73A1237 for ; Mon, 9 Nov 2020 09:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=lastpresslabel-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 mU_hjNVqvR-v for ; Mon, 9 Nov 2020 09:09:27 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450: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 E7C933A0DDD for ; Mon, 9 Nov 2020 09:09:26 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id s13so78624wmh.4 for ; Mon, 09 Nov 2020 09:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lastpresslabel-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=k81asoZ2c6ULpyBdIwFvN0QuMWGfBJnsoM0wq/XOMXk=; b=oJ/13a3VkCpYVRtY6pAjUjNTYQlTBVzDuCb5sRScq43rOpUmFCiT0oEMNgSjI97GsE Luxsv8WvV9IP+6czwbP0V33RThss+3lNV1xvUdd9MspsWwZ9jA2Qkw2PyNPhpU2KfTM8 ygIOdnSJuZd6DYbs2RKo5ax56Jtf6KyGpArd/lnkY9u6/dv5dYnNF/W8C8ivLFxZpHh+ ZxiiNwddSQvdjiGAxebgwVPa676LAky0cfDjEem6qYQjb/TneBM6iRsH0s0Ap8l1qBG+ gbGuDko+6JAlfeJyCDhrSXSKhbEjo9qDe1zsCJdMciz3/SQA57kL0DAWPAQJSFXC8y0A MzVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=k81asoZ2c6ULpyBdIwFvN0QuMWGfBJnsoM0wq/XOMXk=; b=dFEpafXgg8RbzRc54BrUtob1SHWAk510aTq0pEAb8PTe4daqp/qXuMD4Sn9JNy4qUc 0FrcQ6XmmG1Gs3643alTOb0wrIqGQg62+b+5k3xrMyChLkSSX1dnMpuXVm8CQ9qe/UzH SKna7auqj3DapoM9VxwKYBC1AIDsKUIrJR7Y/cQRTl/dbJC2dE9r2L+2hupohdQckPHI VBzccnlQJzPHkCXmAo+3PZPE5NVB60XBLVAONQVKdCDryhg4gmlE+A/nx0rweXRYC9Bm YmmzH0YXWt9W6aE67z0cjXBNRrSfb9RF+9QRYDhsoo1gllvifdQJEGQhkQ1CZAcMSte8 CxFg== X-Gm-Message-State: AOAM533zhsTWLM+82Cw6HQShc59q+41gMxDRFNXiIxUxfMPS36hZtYc5 +mce1+FVutAhsqnYpfx9JN1/y9lTH9V1v6PikaI= X-Google-Smtp-Source: ABdhPJzwZvxVlwRgkMpeJxCFi4a0ufUsM/NY40bCK9hs+KzYmANqsZh0SoRwYD/bTTgx/N+L1CUOJw== X-Received: by 2002:a7b:c350:: with SMTP id l16mr109401wmj.135.1604941761910; Mon, 09 Nov 2020 09:09:21 -0800 (PST) Received: from broadband.bt.com ([2a00:23c7:2b0a:fa01:c45f:4db3:85d0:2b52]) by smtp.gmail.com with ESMTPSA id k81sm558676wma.2.2020.11.09.09.09.21 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2020 09:09:21 -0800 (PST) From: Dominique Lazanski Content-Type: multipart/alternative; boundary="Apple-Mail=_CB0C1042-735F-40F7-8C95-6212A211337C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> Date: Mon, 9 Nov 2020 17:09:19 +0000 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [arch-d] 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, 09 Nov 2020 17:09:29 -0000 --Apple-Mail=_CB0C1042-735F-40F7-8C95-6212A211337C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hey Mark and I have a draft on consolidation.=20 Protocol and Engineering Effects of Consolidation can be found here: = https://datatracker.ietf.org/doc/draft-lazanski-consolidation/ = If you have any thoughts or comments, we would love to have them! Dominique= --Apple-Mail=_CB0C1042-735F-40F7-8C95-6212A211337C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hey Mark and I have a draft on consolidation. 

Protocol and Engineering Effects of Consolidation can be found here: https://datatracker.ietf.org/doc/draft-lazanski-consolidation/

If you have any thoughts or comments, we would love to have them!

Dominique
--Apple-Mail=_CB0C1042-735F-40F7-8C95-6212A211337C-- From nobody Mon Nov 9 11:42: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 287B23A12EA for ; Mon, 9 Nov 2020 11:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 aZnK3AnGLjYm for ; Mon, 9 Nov 2020 11:42:10 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 9CDEF3A0EE6 for ; Mon, 9 Nov 2020 11:42:09 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kcD3D-0002hN-Mw for architecture-discuss@ietf.org; Mon, 09 Nov 2020 20:42:07 +0100 To: architecture-discuss@ietf.org References: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <2bfceb63-1b94-de6f-72e8-4d80eef356f5@digitaldissidents.org> Date: Mon, 9 Nov 2020 20:42:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: d40e2d9e04d28df092fb73f3743f8c9c Archived-At: Subject: Re: [arch-d] 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, 09 Nov 2020 19:42:13 -0000 Hi Dominique, Thanks for this well documented work! I hope you don't mind if I ask some questions. I am a bit confused by this argument: The QUIC protocol is an example of the consolidation between layers of the Internet - and not at the application layer. Designed and deployed as a transport layer protocol, it effectively replaces TCP at the network layer while also adding improved security. The result is the merging or consolidation of three layers. QUIC should improve efficiency and delivery of applications, but also forces all data to be managed at the endpoint, which in this case is a browser, making it more difficult to manage traffic at the network layer. The web browser is not one entity, right? So how does QUIC lead to consolidation? Further down you argue that: However, there was little multistakeholder consultation and discussion prior to the adoption of DoH. This was more of a rapid development and deployment process, without the market driving the use cases and uptake. Does this mean that you think that the IETF process in general is flawed or only in this case? Because I don't think this process have deviated from the standard IETF process. You also argue that: The market should be a regulating factor in consolidation. I am curious what you base this on, because almost no contemporary economic theory argues this. Would be nice to add some sources. For the purposes of this draft we view it from the perspective of the underlying architecture of the public Internet. What do you mean with 'the public Internet' here? Is that different from 'the Internet'? Or would you argue that global dependency bring about other responsibilities for the Internet architecture and hence the term 'public'? More discussion here would be welcome too. This will create not a network of networks, but a mesh. This differentiation could also benefit from some elaboration imho. The 'Actions for the IETF', largely seem actions for IRTF (1 and 4) and the IAB. Point 4 would be an interesting point of discussion for hrpc! Thanks again for this work, curious to see where it goes, and thanks for keeping this discussion going. Best, Niels On 11/9/20 6:09 PM, Dominique Lazanski wrote: > Hey Mark and I have a draft on consolidation.  > > Protocol and Engineering Effects of Consolidation can be found here: https://datatracker.ietf.org/doc/draft-lazanski-consolidation/ > > If you have any thoughts or comments, we would love to have them! > > Dominique > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > -- Niels ten Oever, PhD Postdoctoral Researcher - Media Studies Department - University of Amsterdam Postdoctoral Research Fellow - Communications Department - Texas A&M University Research Fellow - Centre for Internet and Human Rights - European University Viadrina Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas W: https://nielstenoever.net E: mail@nielstenoever.net T: @nielstenoever P/S/WA: +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 Read my disseration 'Wired Norms' here: https://pure.uva.nl/ws/files/50781961/Thesis.pdf From nobody Mon Nov 9 17:44: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 582553A15B9 for ; Mon, 9 Nov 2020 17:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=jAV/Npkk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=drMXP4CC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uosl1-8n5obk for ; Mon, 9 Nov 2020 17:44:20 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F0C3A1638 for ; Mon, 9 Nov 2020 17:44:03 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C93405C0280 for ; Mon, 9 Nov 2020 20:44:02 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Mon, 09 Nov 2020 20:44:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=Rlzey kGZE/m4MEk3z7mP5B4FegZ3WD0eO1b5rIpVkP4=; b=jAV/NpkkkfO9TUCZABNju 29ggKopZ0HVg9ZQQIeJ4AhMGxgA91jeRdjRIADqZhavfv5cRaqNZ8Lr1NDoe9J4X n9KSDzAJBLpxvUI7GkreZmS/DL6WEBZL8W+4OHdbp6+9tdQKmBfWgGtHD2tXp8wg Erg4wS1M1gZVaRs6jlM8OAPvPnXadXfgq8NXe0BhwM3ezXs6MyoxhoNbEsYTX+TU RTgxQdYQ4R+oLTR6Bpp9MPglcAxZlt2ToWIWHRJERhk6ulmg4sHt8Vl68d+mTXBD yLv2H4YZ1nogiiUXWMs7mn4fvpYjvnmNNqJ2zOcl0IVchac3H4I2yj3R+Mc/dJC1 g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=RlzeykGZE/m4MEk3z7mP5B4FegZ3WD0eO1b5rIpVk P4=; b=drMXP4CC+6EajPKXuQr7c6WYnhK6f/3e2dswvCS6x3fUgoFHZC4qby2Gp NE+rKqaqALyhjo9UrBCUuq6Qd0No55wTgdTmw0lqHJy84hNt+G8foS4cVyjZH7ly HG/e2WTEoFzFjEay27XBRFR7mCbZzwx6hPYtqVM4KvPO7FD6PYmmzhxXz8++JLse YZjLJR3UnXwzoZ9dGHDBTQAfwidEwZQqtrSUZN42FwPU5laHbv//MXT19VFvMxIu 8XveQdBjgwmkqA3+jOTOTdoijul7vWo6STuWGNwW8zo5ETJlbLxBAXTXb/MPMbNd WxkGdx12alpjf0yq+pRlRaAWvxqyg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudduiedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepteetteegleekteevke dvgeejiefhhffhvddttedugfejfffhveevudehuefgieevnecuffhomhgrihhnpehivght fhdrohhrghdpnhhivghlshhtvghnohgvvhgvrhdrnhgvthdpuhhvrgdrnhhlnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghn thhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 94FF52038B; Mon, 9 Nov 2020 20:44:02 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-570-gba0a262-fm-20201106.001-gba0a2623 Mime-Version: 1.0 Message-Id: In-Reply-To: <2bfceb63-1b94-de6f-72e8-4d80eef356f5@digitaldissidents.org> References: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> <2bfceb63-1b94-de6f-72e8-4d80eef356f5@digitaldissidents.org> Date: Tue, 10 Nov 2020 12:43:43 +1100 From: "Martin Thomson" To: architecture-discuss@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] 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, 10 Nov 2020 01:44:22 -0000 Hi Dominique, In addition to Dr. Niels' excellent questions and observations, I think = that you might want to think about the effects that attacks on these pro= tocols might have. I agree that there are consolidation effects exhibited by some of the ex= amples. Privacy Pass continues to bother me in this regard, for example= , but that doesn't necessarily render it irredeemable; it might just be = that the deployment models considered don't work in all cases. However, I think that it pays to understand the dynamics involved in the= standardization of these protocols better. For the QUIC example (which is not dominated in the implied fashion by G= oogle and Mozilla (who also don't make Safari)), I would prefer to say t= hat the effect is the opposite of what this draft claims. That is, tech= nology that was previously available only to Google and Facebook is now = available to others. There are many implementations, many of them good,= and many of them accessible to more than just a few. This function of = standardization remains a valuable defense against accretion of propriet= ary technologies that provide larger actors with greater advantage. The draft doesn't suggest any particular course of action in response fo= r these protocols (QUIC, TLS, DoH) in response to the implication that t= hey drive consolidation. If I were to infer that refusal to standardize= is an option, I posit that that would have a severe deleterious effect = on the playing field. It wouldn't remove the desire to deploy such mech= anisms, but it would affect the availability of technology to smaller pl= ayers. That isn't to say that QUIC isn't without its shortcomings when it comes= to power and resource disparities. The deployment complexities involve= d mean that - for the foreseeable future at least - small players are st= ill significantly disadvantaged. But that would be considerably worse h= ad the IETF not been involved at all. Separately, I find this reassuring: > [...] QUIC should improve > efficiency and delivery of applications, but also forces all data to= > be managed at the endpoint, which in this case is a browser, making > it more difficult to manage traffic at the network layer. This was a headline goal of QUIC and I'm glad you agree that we've achie= ved it. The document claims that DoH deployment was forced. The claim is that t= his was not market forces at work. I have to reject that thesis entirel= y. While I agree with the author of RFC 8890 that the development of RF= C 8484 had some issues (some of which were novel, all of which are worth= learning from), the progress toward deployment seems to me to be unrema= rkable. It's a deployment with a disruptive technical innovation that h= as a displacement effect on some incumbents, for sure, which are never p= ainless, but it's not like Microsoft or Apple or Google or Comcast or an= y of the other actors who have responded are responding to force. They = are responding to market pressures. This is FUD, and I'm disappointed to see it repeated here: > By routing the DNS over HTTPS, it becomes much easier to track user > activity through the use of cookies. Therefore a protocol that was > developed to enhance user privacy and security could actually > undermine both: privacy through the use of cookies and security by > consolidating DNS traffic onto far fewer resolver operators that are= > far more attractive targets for malicious actors of various types. Yes, cookies are terrible. Which is why no DoH implementation I'm aware= of pays any attention to them. That's a simplification, but the sugges= tion that client implementations don't take all reasonable steps to mana= ge privacy risks and the trade-offs involved demonstrates a lack of unde= rstanding. Cheers, Martin p.s., your drafting tool seems to have produced some weird errors. On Tue, Nov 10, 2020, at 06:42, Niels ten Oever wrote: > Hi Dominique, >=20 > Thanks for this well documented work! I hope you don't mind if I ask=20= > some questions. I am a bit confused by this argument: >=20 > The QUIC protocol is an example of the consolidation between layers= > of the Internet - and not at the application layer. Designed and > deployed as a transport layer protocol, it effectively replaces TCP= > at the network layer while also adding improved security. The resul= t > is the merging or consolidation of three layers. QUIC should improv= e > efficiency and delivery of applications, but also forces all data t= o > be managed at the endpoint, which in this case is a browser, making= > it more difficult to manage traffic at the network layer. >=20 > The web browser is not one entity, right? So how does QUIC lead to=20 > consolidation? >=20 > Further down you argue that: >=20 > However, > there was little multistakeholder consultation and discussion prior= > to the adoption of DoH. This was more of a rapid development and > deployment process, without the market driving the use cases and > uptake. >=20 > Does this mean that you think that the IETF process in general is=20 > flawed or only in this case? Because I don't think this process have=20= > deviated from the standard IETF process. >=20 > You also argue that: >=20 > The market should be a regulating factor in consolidation. >=20 > I am curious what you base this on, because almost no contemporary=20 > economic theory argues this. Would be nice to add some sources. >=20 > For the purposes of this draft we view it from the > perspective of the underlying architecture of the public Internet. >=20 > What do you mean with 'the public Internet' here? Is that different=20= > from 'the Internet'? Or would you argue that global dependency bring=20= > about other responsibilities for the Internet architecture and hence=20= > the term 'public'? More discussion here would be welcome too.=20 >=20 > This will > create not a network of networks, but a mesh.=20 >=20 > This differentiation could also benefit from some elaboration imho. >=20 > The 'Actions for the IETF', largely seem actions for IRTF (1 and 4) an= d=20 > the IAB. Point 4 would be an interesting point of discussion for hrpc!= >=20 >=20 > Thanks again for this work, curious to see where it goes, and thanks=20= > for keeping this discussion going. >=20 > Best, >=20 > Niels >=20 >=20 > On 11/9/20 6:09 PM, Dominique Lazanski wrote: > > Hey Mark and I have a draft on consolidation.=C2=A0 > >=20 > > Protocol and Engineering Effects of Consolidation can be found here:= =C2=A0https://datatracker.ietf.org/doc/draft-lazanski-consolidation/ > >=20 > > If you have any thoughts or comments, we would love to have them! > >=20 > > Dominique > >=20 > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > >=20 >=20 > --=20 > Niels ten Oever, PhD > Postdoctoral Researcher - Media Studies Department - University of=20 > Amsterdam > Postdoctoral Research Fellow - Communications Department - Texas A&M=20= > University > Research Fellow - Centre for Internet and Human Rights - European=20 > University Viadrina > Associated Scholar - Centro de Tecnologia e Sociedade - Funda=C3=A7=C3= =A3o=20 > Get=C3=BAlio Vargas >=20 > W: https://nielstenoever.net > E: mail@nielstenoever.net > T: @nielstenoever > P/S/WA: +31629051853 > PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 >=20 > Read my disseration 'Wired Norms' here:=20 > https://pure.uva.nl/ws/files/50781961/Thesis.pdf >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Wed Nov 11 04:37:40 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 B9F143A0A16 for ; Wed, 11 Nov 2020 04:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=BD+7VjIc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yaoPR2Sx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJNYY8qNGgrq for ; Wed, 11 Nov 2020 04:37:38 -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 1AFA23A09F9 for ; Wed, 11 Nov 2020 04:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4906; q=dns/txt; s=iport; t=1605098258; x=1606307858; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=aR83x5/t75AbAXrJ/LuMX12tLDpiXl/pVSlwvzSnja4=; b=BD+7VjIcrytdigFHpDW0euWwL9foXOZ/TBVF9eQOVoIrq8RgMX6WUILE AcUeMFZxwnsuU5Hly7evvGMnbCKg2hSD7kDoJSHiMAPy7YIbOrm+KJc5K 08JJqvc9CU16h2bdI6AUwSzWJkUhe4itqlJg/rUardXOWVw1B+9DQau+7 s=; X-IPAS-Result: =?us-ascii?q?A0DkCADT2atffYMNJK1igQmDIVGBVC8uCoQzg0kDjViZA?= =?us-ascii?q?4JTA1QLAQEBDQEBLQIEAQGESgIXgX8CJTgTAgMBAQEDAgMBAQEBBQEBAQIBB?= =?us-ascii?q?gQUAQGGPAyFcgEBAQEDEhERDAEBOAsEAgEIDgMBAwEBAwImAgICMBUCBggCB?= =?us-ascii?q?AESCBAKhVoDLgEDpHMCgTyIaHaBMoMEAQEFhRkYghAJgQ4qgnODdYUygSUbg?= =?us-ascii?q?UE/gRFDgk8+hCAggxUzgiyNTIYapEkKgm2HQZN1oXeTUaBPAgQCBAUCDgEBB?= =?us-ascii?q?YFrITmBIHAVgyRQFwINkhCKWHQ4AgYKAQEDCXyMOwGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3Ag6UAtxBhL8XbGRpOroRsUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw30A3NWprW7e5ejPLH9abtRT9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7WpWK/6yIIHQ?= =?us-ascii?q?3ucwx4Ore9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6yw?= =?us-ascii?q?DCpT1DfOEFyA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,469,1596499200"; d="scan'208";a="586645325" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2020 12:37:37 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ABCbaaG015069 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2020 12:37:37 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 06:37:36 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 07:37:35 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 11 Nov 2020 07:37:34 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QREyD4DbYJnF6MjktOLpnb5IEWWjyTky0p/laVG16Dypl9+0/ReXNo1rLE4ew5IH8Rkt9IUaahJqMaG8TYx7IJujAWUV4x2PJCINaEQgnwhFM+UOxPQTjXs2lrmyfUztQRdfPPTcL84vVPSyRTCB3decCDJ5K4Ow8I897kjx9iSEUckMXzP1hipMVClpxd37raUQwLEY06PNVxRUhfYaVsSF/6gFZeTKrum/fW1IXr7ii/alS2zG8om8QoshqUZ+kSlCQb2KVA3JBINelpZZf3Y1GoebqyIeT+d7kfTDplPmytVO4Peyuk9a7a6MYf+9DjOinKFE7pT4M/J6u4T+VA== 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=aR83x5/t75AbAXrJ/LuMX12tLDpiXl/pVSlwvzSnja4=; b=R8IWdmlpe4TyetKhDZgECV7j1f3ZYzERc5yIKDYRLaUGLvXThk8StpNNIT/Darx1i1fy80iHvdYlre0x/p6ZMDeeNugE+8fVKc9v04XMNBYdkmMeO+5hvIDMKdL2HgPkAb2p/DNGcwF1MEE2Dqj6wY1qfr6c5AUgNknEBucQxYZyVp6Mad6qU8gJKxF/TduBLAyFylmVh0MUF8hJ/4GuFdqBMwkIaLzdpAO6vkRxetGDms9lzXUsDzdffZIN6o6Sk3QnK+dUJDxgB9TdajJK08GCJ6Gs6cHCnM3D5BVuNfnP5HY+p5I0Q0YYv3Ul2UZH00aKc4FJvmY4MuM3fBGLkg== 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=aR83x5/t75AbAXrJ/LuMX12tLDpiXl/pVSlwvzSnja4=; b=yaoPR2SxXkqOEKMENEuMKoDA0kHMGpRbX+e+G8n0Gh29cF+qtEX8HXxSeJljCRJkf56adS7cAYYJ7N5PYAojh6akR8loohKZq0GP+UVJcOv/NCUiH8SEj+8iKw83ipiNCqzwyHDc+YB2BKjxD5mQ5aC490llIA0RM4Vfuw9/5lE= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB2995.namprd11.prod.outlook.com (2603:10b6:208:7a::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Wed, 11 Nov 2020 12:37:34 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e810:915b:8d03:e1f0]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e810:915b:8d03:e1f0%5]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 12:37:34 +0000 From: "Rob Wilton (rwilton)" To: Martin Thomson , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] Thread-Index: AQHWtrsuNzojq//1/kCIQ1QigkKle6nAM1MAgABlDoCAAiHfIA== Date: Wed, 11 Nov 2020 12:37:32 +0000 Message-ID: References: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> <2bfceb63-1b94-de6f-72e8-4d80eef356f5@digitaldissidents.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lowentropy.net; dkim=none (message not signed) header.d=none;lowentropy.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8486d679-2d36-4874-b69d-08d8863e905c x-ms-traffictypediagnostic: BL0PR11MB2995: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9uDebLpL7BwzQLXpRk7oFluK9UzbNF4VWizfHdQYAqBxwoptzKPwEDs1gUwmZc/mFveHdWXmMJTqYM9fSUA6DYqQ++1T9dHtrwNB6DRLs//Me1JulwRRyb+T1HFd6CAHNmlldUsf2HycUdTerF8wHO0FRF7t5nllHw7R6CkgVaBAw56bS2AEz4G7uJXzNkawg6rOpeguhgkzgA0Ti8G1Q/ORqm018im4oZLbVRrXHbAygDA5vHcKlkh6rsodlsAqRM0FkUyUqLsTEZR7SoALa9G64p181VozpeiIr2yIa0ztvkgRisf9zP01fJsz0emt/B1x1pwRSpx4Mse6t3tClA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(396003)(376002)(346002)(83380400001)(52536014)(66556008)(55016002)(5660300002)(71200400001)(186003)(9686003)(8676002)(66446008)(76116006)(64756008)(8936002)(2906002)(110136005)(316002)(66476007)(26005)(7696005)(6506007)(66946007)(86362001)(478600001)(66574015)(33656002)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 07KtTfjb8E4TPT2Yqd0luzLsi17fLuxoEpZwH2/1foQR4rpX+MII4/e54BsQF3TCbJ/HYLySoOBmtX31hXriw9t5h+KCzRES5SomeKAU4wkv2S8WKaJF9NpQSnjxCpZ/btJEV6g2NHqnjEdlAYbA64n/yUuQFSy+b6QSali/4PCqbyQ58qUsgZQ3q9i+MgX3Dajs8HkNEMdZVZbOFZz3HMvJEOx83eGL5tXu2iKGSWYC76l72nOm/cuYQ8x552B0vvPIE4kjAfkNbL1+DlK4bU0dOAa1QnYH4eG6f/owtI2/KUCa3lT2/YZIuuX4NhjfyfgbvsuOd+5LypwxDW/CDrz5B+bzPmLBElkqNbktEEwPQ3gG+ERa9SXI/7glh8zsYpVi96686gz2Fsn7vqv2yiTx5uNpNNBckV6HzrQ+YvV5ZRVeg/UJdQHKvTeiq0GoFdQL121xWMdfATxS317ruuczzuUAW1m451t4BiVIdtzqCf+HLXRAHwyiDSn+T+/NgpIwqZo4G93NZSv51f7M+Ucz3cMh5Fe5I/aICdQrCX5P68EPTIENtEaHIit19w21oWvMp+lZvy+GL+I5JgU857Quv0E2QX0nUZ76Lzwp5wTG6Nv/WJYlU09yMI+hmIhg1vN5bjaf1yH1MWP6xpxKIg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8486d679-2d36-4874-b69d-08d8863e905c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 12:37:32.2945 (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: pZnUmVEeMJv3oW4nBfpN+lsRhceQ+m2lwYGj5zRijcv9ux8mif8ejuCLzKCcJ9N/mukG02W9MoWUFqPmyiVwHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2995 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [arch-d] 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, 11 Nov 2020 12:37:40 -0000 SGkgTWFydGluLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFyY2hp dGVjdHVyZS1kaXNjdXNzIDxhcmNoaXRlY3R1cmUtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPiBP bg0KPiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NCj4gU2VudDogMTAgTm92ZW1iZXIgMjAyMCAw MTo0NA0KPiBUbzogYXJjaGl0ZWN0dXJlLWRpc2N1c3NAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFthcmNoLWRdIDxkcmFmdC1sYXphbnNraS1jb25zb2xpZGF0aW9uLTAwPg0KPiANCj4gSGkgRG9t aW5pcXVlLA0KPiANCj4gSW4gYWRkaXRpb24gdG8gRHIuIE5pZWxzJyBleGNlbGxlbnQgcXVlc3Rp b25zIGFuZCBvYnNlcnZhdGlvbnMsIEkgdGhpbmsNCj4gdGhhdCB5b3UgbWlnaHQgd2FudCB0byB0 aGluayBhYm91dCB0aGUgZWZmZWN0cyB0aGF0IGF0dGFja3Mgb24gdGhlc2UNCj4gcHJvdG9jb2xz IG1pZ2h0IGhhdmUuDQo+IA0KPiBJIGFncmVlIHRoYXQgdGhlcmUgYXJlIGNvbnNvbGlkYXRpb24g ZWZmZWN0cyBleGhpYml0ZWQgYnkgc29tZSBvZiB0aGUNCj4gZXhhbXBsZXMuICBQcml2YWN5IFBh c3MgY29udGludWVzIHRvIGJvdGhlciBtZSBpbiB0aGlzIHJlZ2FyZCwgZm9yDQo+IGV4YW1wbGUs IGJ1dCB0aGF0IGRvZXNuJ3QgbmVjZXNzYXJpbHkgcmVuZGVyIGl0IGlycmVkZWVtYWJsZTsgaXQg bWlnaHQNCj4ganVzdCBiZSB0aGF0IHRoZSBkZXBsb3ltZW50IG1vZGVscyBjb25zaWRlcmVkIGRv bid0IHdvcmsgaW4gYWxsIGNhc2VzLg0KPiANCj4gSG93ZXZlciwgSSB0aGluayB0aGF0IGl0IHBh eXMgdG8gdW5kZXJzdGFuZCB0aGUgZHluYW1pY3MgaW52b2x2ZWQgaW4gdGhlDQo+IHN0YW5kYXJk aXphdGlvbiBvZiB0aGVzZSBwcm90b2NvbHMgYmV0dGVyLg0KPiANCj4gRm9yIHRoZSBRVUlDIGV4 YW1wbGUgKHdoaWNoIGlzIG5vdCBkb21pbmF0ZWQgaW4gdGhlIGltcGxpZWQgZmFzaGlvbiBieQ0K PiBHb29nbGUgYW5kIE1vemlsbGEgKHdobyBhbHNvIGRvbid0IG1ha2UgU2FmYXJpKSksIEkgd291 bGQgcHJlZmVyIHRvIHNheQ0KPiB0aGF0IHRoZSBlZmZlY3QgaXMgdGhlIG9wcG9zaXRlIG9mIHdo YXQgdGhpcyBkcmFmdCBjbGFpbXMuICBUaGF0IGlzLA0KPiB0ZWNobm9sb2d5IHRoYXQgd2FzIHBy ZXZpb3VzbHkgYXZhaWxhYmxlIG9ubHkgdG8gR29vZ2xlIGFuZCBGYWNlYm9vayBpcw0KPiBub3cg YXZhaWxhYmxlIHRvIG90aGVycy4gIFRoZXJlIGFyZSBtYW55IGltcGxlbWVudGF0aW9ucywgbWFu eSBvZiB0aGVtDQo+IGdvb2QsIGFuZCBtYW55IG9mIHRoZW0gYWNjZXNzaWJsZSB0byBtb3JlIHRo YW4ganVzdCBhIGZldy4gIFRoaXMgZnVuY3Rpb24NCj4gb2Ygc3RhbmRhcmRpemF0aW9uIHJlbWFp bnMgYSB2YWx1YWJsZSBkZWZlbnNlIGFnYWluc3QgYWNjcmV0aW9uIG9mDQo+IHByb3ByaWV0YXJ5 IHRlY2hub2xvZ2llcyB0aGF0IHByb3ZpZGUgbGFyZ2VyIGFjdG9ycyB3aXRoIGdyZWF0ZXINCj4g YWR2YW50YWdlLg0KPiANCj4gVGhlIGRyYWZ0IGRvZXNuJ3Qgc3VnZ2VzdCBhbnkgcGFydGljdWxh ciBjb3Vyc2Ugb2YgYWN0aW9uIGluIHJlc3BvbnNlIGZvcg0KPiB0aGVzZSBwcm90b2NvbHMgKFFV SUMsIFRMUywgRG9IKSBpbiByZXNwb25zZSB0byB0aGUgaW1wbGljYXRpb24gdGhhdCB0aGV5DQo+ IGRyaXZlIGNvbnNvbGlkYXRpb24uICBJZiBJIHdlcmUgdG8gaW5mZXIgdGhhdCByZWZ1c2FsIHRv IHN0YW5kYXJkaXplIGlzIGFuDQo+IG9wdGlvbiwgSSBwb3NpdCB0aGF0IHRoYXQgd291bGQgaGF2 ZSBhIHNldmVyZSBkZWxldGVyaW91cyBlZmZlY3Qgb24gdGhlDQo+IHBsYXlpbmcgZmllbGQuICBJ dCB3b3VsZG4ndCByZW1vdmUgdGhlIGRlc2lyZSB0byBkZXBsb3kgc3VjaCBtZWNoYW5pc21zLA0K PiBidXQgaXQgd291bGQgYWZmZWN0IHRoZSBhdmFpbGFiaWxpdHkgb2YgdGVjaG5vbG9neSB0byBz bWFsbGVyIHBsYXllcnMuDQo+IA0KPiBUaGF0IGlzbid0IHRvIHNheSB0aGF0IFFVSUMgaXNuJ3Qg d2l0aG91dCBpdHMgc2hvcnRjb21pbmdzIHdoZW4gaXQgY29tZXMNCj4gdG8gcG93ZXIgYW5kIHJl c291cmNlIGRpc3Bhcml0aWVzLiAgVGhlIGRlcGxveW1lbnQgY29tcGxleGl0aWVzIGludm9sdmVk DQo+IG1lYW4gdGhhdCAtIGZvciB0aGUgZm9yZXNlZWFibGUgZnV0dXJlIGF0IGxlYXN0IC0gc21h bGwgcGxheWVycyBhcmUgc3RpbGwNCj4gc2lnbmlmaWNhbnRseSBkaXNhZHZhbnRhZ2VkLiAgQnV0 IHRoYXQgd291bGQgYmUgY29uc2lkZXJhYmx5IHdvcnNlIGhhZCB0aGUNCj4gSUVURiBub3QgYmVl biBpbnZvbHZlZCBhdCBhbGwuDQo+IA0KPiBTZXBhcmF0ZWx5LCBJIGZpbmQgdGhpcyByZWFzc3Vy aW5nOg0KPiANCj4gPiAgWy4uLl0gUVVJQyBzaG91bGQgaW1wcm92ZQ0KPiA+ICAgZWZmaWNpZW5j eSBhbmQgZGVsaXZlcnkgb2YgYXBwbGljYXRpb25zLCBidXQgYWxzbyBmb3JjZXMgYWxsIGRhdGEg dG8NCj4gPiAgIGJlIG1hbmFnZWQgYXQgdGhlIGVuZHBvaW50LCB3aGljaCBpbiB0aGlzIGNhc2Ug aXMgYSBicm93c2VyLCBtYWtpbmcNCj4gPiAgIGl0IG1vcmUgZGlmZmljdWx0IHRvIG1hbmFnZSB0 cmFmZmljIGF0IHRoZSBuZXR3b3JrIGxheWVyLg0KPiANCj4gVGhpcyB3YXMgYSBoZWFkbGluZSBn b2FsIG9mIFFVSUMgYW5kIEknbSBnbGFkIHlvdSBhZ3JlZSB0aGF0IHdlJ3ZlDQo+IGFjaGlldmVk IGl0Lg0KW1JXXSANCg0KSSB3b3VsZCBsaWtlIHRvIGNoZWNrIHRoYXQgSSBhbSByZWFkaW5nIGFu ZCB1bmRlcnN0YW5kaW5nIHlvdXIgY29tbWVudCBjb3JyZWN0bHkuDQoNCkFyZSB5b3UgcmVhbGx5 IGludGVuZGluZyB0byBzYXkgdGhhdCBhIGhlYWRsaW5lIGdvYWwgb2YgUVVJQyBpcyB0byBtYWtl IGl0IG1vcmUgZGlmZmljdWx0IHRvIG1hbmFnZSB0cmFmZmljIGF0IHRoZSBuZXR3b3JrIGxheWVy LCBhbmQgYnkgaW1wbGljYXRpb24gbWFrZSBpdCBtb3JlIGRpZmZpY3VsdCBmb3IgSVNQcyB0byBt YW5hZ2UgbmV0d29ya3M/DQoNCkknbSBub3QgdGhhdCBmYW1pbGlhciB3aXRoIFFVSUMgeWV0LCBi dXQgSSBoYWQgYXNzdW1lZCB0aGF0IHRoZSBnb2FsIHdhcyB0byBpbmNyZWFzZSB1c2VyIHByaXZh Y3kgYW5kIHJlZHVjZSB0aGUgbGVha2FnZSBvZiBwcml2YXRlIGluZm9ybWF0aW9uIHRoYXQgaXMg YXZhaWxhYmxlIGF0IHRoZSBuZXR3b3JrIGxheWVyLCBhbmQgdGhhdCBtYWtpbmcgaXQgaGFyZGVy IHRvIG1hbmFnZSB0cmFmZmljIGF0IHRoZSBuZXR3b3JrIGxheWVyIHdhcyBhbiB1bmZvcnR1bmF0 ZSBzaWRlIGVmZmVjdCBvZiB0aGF0IGluY3JlYXNlIG9mIHByaXZhY3kgcmF0aGVyIHRoYW4gYXMg YW4gZXhwbGljaXQgZ29hbC4NCg0KSSBhbSBtb3JlIGNvbmNlcm5lZCBhYm91dCB0aGUgbG9zcyBv ZiBwcml2YWN5IHRoYXQgc2VlbXMgdG8gYmUgb2NjdXJyaW5nIGF0IHRoZSBhcHBsaWNhdGlvbiBs YXllciB2aWEgZXh0ZW5zaXZlIHRyYWNraW5nIG9mIHVzZXJzIGFuZCBzaGFyaW5nIG9mIHVzZXIg aW5mb3JtYXRpb24sIHJhdGhlciB0aGFuIG15IHBlcmNlcHRpb24gb2Ygd2hhdCBpcyBub3cgb2Nj dXJyaW5nIGF0IHRoZSBuZXR3b3JrIGxheWVyLg0KDQpSZWdhcmRzLA0KUm9iDQoNCg0K From nobody Wed Nov 11 05:15: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 52FB63A10D2 for ; Wed, 11 Nov 2020 05:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 9MCDhE-SO17r for ; Wed, 11 Nov 2020 05:15:00 -0800 (PST) Received: from mx3.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 D0CB53A0D72 for ; Wed, 11 Nov 2020 05:14:59 -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)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 6615C6A23D; Wed, 11 Nov 2020 14:14:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1605100497; bh=H0uLja78fb7lJv86bWK7YLEDaeqnNBKOr87mGK1CClI=; h=Date:From:To:In-Reply-To:References:Subject:From; b=nqHbnt8ph2bcDeKNTs6xPYC/aTBi01HV2R0lDc7qctmSaG8VjiwvXjH1t5PGlO2hE Z1VHPegxj5ik1006IUK+C+Ik0cq5zD4zGZC53LkYRWBBwYj2BpakAfe3wa/WECI9Ba YE61e3JRxyNU2APEythHi5fz30wpPmOvZrPZtpz8AbfWwRECu1c1Z2Bz24P4CgxL3w uY0TIY2uiwg1M7+Vges5Q+QpEeX4iyPPfwZ9YIziTVbNt9S9P6/1Ht/rx+wR9UiiMC C2Hmb44Dfwc3F4lkwq19Tcq7UF9b8pLlVj2baf2xnifl9fJp3WItuqHdgZChgz+wSC f1cln9q2LRJ+w== 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 5599A3C001A; Wed, 11 Nov 2020 14:14:57 +0100 (CET) Date: Wed, 11 Nov 2020 14:14:57 +0100 (CET) From: Vittorio Bertola To: Martin Thomson , architecture-discuss@ietf.org Message-ID: <1559092599.16379.1605100497247@appsuite-gw1.open-xchange.com> In-Reply-To: References: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> <2bfceb63-1b94-de6f-72e8-4d80eef356f5@digitaldissidents.org> 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.4-Rev10 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] 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, 11 Nov 2020 13:15:03 -0000 > Il 10/11/2020 02:43 Martin Thomson ha scritto: > > The draft doesn't suggest any particular course of action in response for these protocols (QUIC, TLS, DoH) in response to the implication that they drive consolidation. If I were to infer that refusal to standardize is an option, I posit that that would have a severe deleterious effect on the playing field. It wouldn't remove the desire to deploy such mechanisms, but it would affect the availability of technology to smaller players. +1 to this. In fact, the (non-technical) problems do not come from having standardized a protocol, but from having failed to gather and address the non-technical requirements of all stakeholders before finalizing and deploying the standard. > The document claims that DoH deployment was forced. The claim is that this was not market forces at work. I have to reject that thesis entirely. While I agree with the author of RFC 8890 that the development of RFC 8484 had some issues (some of which were novel, all of which are worth learning from), the progress toward deployment seems to me to be unremarkable. It's a deployment with a disruptive technical innovation that has a displacement effect on some incumbents, for sure, which are never painless, but it's not like Microsoft or Apple or Google or Comcast or any of the other actors who have responded are responding to force. They are responding to market pressures. The problem, however, is that consolidation *is* the effect of market pressures. The global regulatory discussion around Internet platforms is indeed a discussion about rules that could prevent these market pressures from reaching a short-term optimal point which is damaging to the market itself in the long term, and that endangers fundamental rights and public policy needs. > This is FUD, and I'm disappointed to see it repeated here: > > > By routing the DNS over HTTPS, it becomes much easier to track user > > activity through the use of cookies. Therefore a protocol that was > > developed to enhance user privacy and security could actually > > undermine both: privacy through the use of cookies and security by > > consolidating DNS traffic onto far fewer resolver operators that are > > far more attractive targets for malicious actors of various types. > > Yes, cookies are terrible. Which is why no DoH implementation I'm aware of pays any attention to them. That's a simplification, but the suggestion that client implementations don't take all reasonable steps to manage privacy risks and the trade-offs involved demonstrates a lack of understanding. However, when you design a protocol, you should also take into consideration how it could be misused. If you design a protocol that gives an additional possibility for user tracking to a sector of the Internet industry that in many cases has user tracking and profiling as its main source of revenues, then there will be a natural business incentive for these companies to activate the tracking sooner or later. Of course you can rely on a pledge that they will never do so, but still, you created a new risk by design. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Wed Nov 11 05:26:10 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 B1B303A0DC8 for ; Wed, 11 Nov 2020 05:26:08 -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_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 dM7bEv5tL_XS for ; Wed, 11 Nov 2020 05:26:06 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 9A4423A0D40 for ; Wed, 11 Nov 2020 05:26:05 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id l2so3168526lfk.0 for ; Wed, 11 Nov 2020 05:26:05 -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=jOiiWBDq5iPHQwsg9QWkV0HTKKAjNWTwI7esuXAuuRY=; b=iR+vJAHsduBxPKRb3qCpxeAa6i1iRjJgT/Q22O05KCYEVB3FZKfWZEXmMw1YSL+QCF B4XDmJrLG18Uv8el8u1sc2RXvRvWA0XqK4YZxwgPRWuO2Gg6LiU8WzSKo8d2TRn6kCbK tqYUZu4e1VlcSHyJyVn3GltwyI+vhDK+JjdZbEvexLHtSBy+AUbcZzpSpjMU3Yd6smjo O1czRpfUSNJFqeyz8TSRIR4GX2K0JP4cWQFS5Dh4e1o7n9OTQAdUt+ui+tFbz4Ixklbp B3hq9mDAwBQYMcafMNCq+VUBF7v/9mn8wZTUMh9wg4zEC0mfKFHpCGnpBGvdbKJjjcgC WHkQ== 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=jOiiWBDq5iPHQwsg9QWkV0HTKKAjNWTwI7esuXAuuRY=; b=EyB58ckqlU6iZvShK1ycePqH05mnxtV9gggsgbsUoa9Ja5zaR/uifmX9Sc/ji1+hq9 U135LvSWvHUB2Uw5gJI68PSCZhUZH6jlB88PF22Kgife+RO6fFiD3JWJjAWD+e4J9xEb i6e0y3N3NNw7ERWBzuS/In06W5k1X5DSa0u4482m6Z3OWccsEfs473NyTfImvpRdCV2W hXCy4VUcYO9Y2u4T/N/9JYPbBNQB0PF6LhIzJ9Qn8l8YSaX548G90kNVBrLhEcyG8c/j PG8F4CX411pnBKcTSkYPLJJZj7vFtvTnlPkmHb2wO38SMqw60VezJhkByKhesfYfg1bl ql3w== X-Gm-Message-State: AOAM530H+qCzIIGliU1yW/iPZrAiKEjNcivmdFDOyGBjeYYIqUPY2q30 zuh/sJOTI8m3Q2dzSPrpWogZWKpqp3O7fFwa99+mhIJzwIVDgA== X-Google-Smtp-Source: ABdhPJzXRCsiKd/zZambPl8heX7iHXdBpxnu9tFZg/9FeN84f1mRfbet5KTBTe40MlwFr1l+oS4i0MoUsoiw1Xj5Z4c= X-Received: by 2002:a05:6512:110b:: with SMTP id l11mr8557964lfg.234.1605101163942; Wed, 11 Nov 2020 05:26:03 -0800 (PST) MIME-Version: 1.0 References: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> <2bfceb63-1b94-de6f-72e8-4d80eef356f5@digitaldissidents.org> In-Reply-To: From: Eric Rescorla Date: Wed, 11 Nov 2020 05:25:28 -0800 Message-ID: To: "Rob Wilton (rwilton)" Cc: Martin Thomson , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b4ae5b05b3d4bcef" Archived-At: Subject: Re: [arch-d] 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, 11 Nov 2020 13:26:09 -0000 --000000000000b4ae5b05b3d4bcef Content-Type: text/plain; charset="UTF-8" On Wed, Nov 11, 2020 at 4:37 AM Rob Wilton (rwilton) wrote: I am more concerned about the loss of privacy that seems to be occurring at > the application layer via extensive tracking of users and sharing of user > information, rather than my perception of what is now occurring at the > network layer. > The goals of reducing tracking at the application layer and at the network layer are complementary, rather than in tension. And in fact, there is extensive work happening on reducing application layer tracking (see, for instance, Intelligent Tracking Protection [Safari] and Enhanced Tracking Protection [Firefox]). -Ekr --000000000000b4ae5b05b3d4bcef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 11, 2020 at 4:37 AM Rob W= ilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:

I am more concerned about the loss of priv= acy that seems to be occurring at the application layer via extensive track= ing of users and sharing of user information, rather than my perception of = what is now occurring at the network layer.

=
The goals of reducing tracking at the application layer and at the net= work layer are complementary, rather than in tension. And in fact, there is= extensive work happening on reducing application layer tracking (see, for = instance, Intelligent Tracking Protection [Safari] and Enhanced Tracking Pr= otection [Firefox]).

-Ekr

=
--000000000000b4ae5b05b3d4bcef-- From nobody Wed Nov 11 16:38: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 2937D3A1273 for ; Wed, 11 Nov 2020 16:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=kg8zDiyS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EFJLc2pZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTrz2vOYASgl for ; Wed, 11 Nov 2020 16:38:19 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000B73A1274 for ; Wed, 11 Nov 2020 16:38:18 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D33199C2; Wed, 11 Nov 2020 19:38:17 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 11 Nov 2020 19:38:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=Fyuv+nLxL3X8rg0/xMwkpQzHsce2uiu z+1UeXASVDSM=; b=kg8zDiySjmGo2/fQzwUZESuzS6oNuxVrDK3xMbJ2zTWo/LN mTEj4/87iHdWDNVP59q7NPmb82Pux65/1bvnZQ27hIidwHIOG/o0Wa9DIApxxH9k HIjX4lJQEG5S0h8Nz3+awNTiMe8GvSv399mcJJDE4BD3dlBf3G8ykGutnyOF+4jk Da7YdsCtfy5PR5gq76/8pONzUzdVQwfGbCImLQZ9K1xNA8I1wsxKRBiREv81Z2gr yldfMp/z8ur6tcXZlCpwNu/icJMcyhxjbbC7IXNrlLTersqLgjL6V3bxJYv6jB33 ijRw7QYua+8hJaB/J2XeFamTlb5XZgiKngVx/aQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=Fyuv+n LxL3X8rg0/xMwkpQzHsce2uiuz+1UeXASVDSM=; b=EFJLc2pZ9PYvlUndi7XfAR wVEaSMK7LHcWRCLTYe5kvn3km9+oB3dCGDg0ysB0WICaJPT55rzr6KJZwf7/Coxt a6Ph78MUJ5BTAcqpJYR786iD1v/12EECbOF/5sk2kYrOoMEzHNqjtbLy4Mzb9HKE e8Rz03F044EdsVpHB4kT6cwlrtsOTwfsZtWOOJ7G55uCgIwF8m0oYBWnCKcSs84b UTCPlmJair8xqX3dIzvjjnRtZzntkOg3U5X2LjAJ4K8oFFnB4pHwFcdrqWfzhg/h wshaJiobfUf4K/UxQ1zuHLYGHN/zatAW6AqGA31thBvtgW/q2++B9NqTv+sVfHZQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvuddgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepkeetueeikedtkeelfeekvefhkeffvedvvefgkefgleeugfdvjeej geffieegtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4E96A20093; Wed, 11 Nov 2020 19:38:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-570-gba0a262-fm-20201106.001-gba0a2623 Mime-Version: 1.0 Message-Id: <76dada1c-652b-4d4d-8b7f-ba836660c1d0@www.fastmail.com> In-Reply-To: References: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> <2bfceb63-1b94-de6f-72e8-4d80eef356f5@digitaldissidents.org> Date: Thu, 12 Nov 2020 11:37:57 +1100 From: "Martin Thomson" To: "Rob Wilton (rwilton)" , "architecture-discuss@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [arch-d] 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, 12 Nov 2020 00:38:20 -0000 > Are you really intending to say that a headline goal of QUIC is to make > it more difficult to manage traffic at the network layer, and by > implication make it more difficult for ISPs to manage networks? No, I should have been more careful there. There were a couple of goals relevant to this. One was to reduce information exposure and improve privacy with respect to on-path attackers. The other was to limit active interference by an on-path attacker. The net effect is that ISPs are less able to manage the details of other people's interactions. But there are affordances in the protocol that should allow ISPs (and other network operators) to continue to manage their networks effectively. Of course, it's still a matter of debate how much information or control network operators need from endpoints, but at least QUIC provides end users (or at least end systems) greater ability to decide what happens. > I am more concerned about the loss of privacy that seems to be > occurring at the application layer via extensive tracking of users and > sharing of user information, rather than my perception of what is now > occurring at the network layer. A totally legitimate concern, but that line of argumentation sounds like whataboutism. Improvements in privacy with respect to the network do not drive privacy violations at the application layer. From nobody Wed Nov 11 19:29: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 A46A63A1380 for ; Wed, 11 Nov 2020 19:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsfHwcaBbvZv for ; Wed, 11 Nov 2020 19:29:18 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 DA0253A137F for ; Wed, 11 Nov 2020 19:29:17 -0800 (PST) Received: from xse289.mail2web.com ([66.113.197.35] helo=xse.mail2web.com) by mx170.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kd3IQ-00012K-Br for architecture-discuss@ietf.org; Thu, 12 Nov 2020 04:29:16 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4CWnBt2dffz1l02 for ; Wed, 11 Nov 2020 19:29:10 -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 1kd3IM-000837-8k for architecture-discuss@ietf.org; Wed, 11 Nov 2020 19:29:10 -0800 Received: (qmail 28382 invoked from network); 12 Nov 2020 03:29:08 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.90]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Nov 2020 03:29:08 -0000 To: Martin Thomson , "Rob Wilton (rwilton)" , "architecture-discuss@ietf.org" References: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> <2bfceb63-1b94-de6f-72e8-4d80eef356f5@digitaldissidents.org> <76dada1c-652b-4d4d-8b7f-ba836660c1d0@www.fastmail.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: Date: Wed, 11 Nov 2020 19:29:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <76dada1c-652b-4d4d-8b7f-ba836660c1d0@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------31A32B1E0BA24B8EDEB0168D" Content-Language: en-US X-Originating-IP: 66.113.197.35 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/gcnlw0cThwnZT+ODcFyeCwCHoUjupSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX7SvmMbusD8MAdJfTseGdhqVO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PutP0Dzal8myJ8vVhoWnSKP9MNEQeb4WXjUDFU/KbUpHy8pnvZ XWSe7jV34Pxn0vH1Lz/y+awqhw7CmTPsWtYsCV/oEQh3zFZ7AJOfdc5NLopVCPmS+MVojfDUugvn Zl+jhHQOLtWk4clq0P6Ltvr/5Zl+BJt+8hYKwgejR0Z9YPn97p3CKmEi95YYeXPNWMiahaC2TJpF rGrq1WX76kTmg5w7R2/M+XaT5BLifEp8KpWu41J1t4cteGI4vH6PuMQp0kaOEXLuWd+6zLg4wp8u XxPcpGyeyPXKNTABBN67jV7JvFCbAD7w3FUirQwmJIqD2OUMeHyTpNN0eXybX/w7/3ZCM0u5uBlK VwmNWN494pUPBFtmg5GCGtjOaQC74kK2pwFkX37ezuu5b0o/wSdkkLoi5ifCAfaw/iBTFFzjTc/a f+kM2U7Xb/97uLa8qeCAMYjMUqZL6iBLUS97OHj8b53ugII7ouYCgfwcsP8qn8jymNgFzWRkuRvd 2hsh/DKjJTkETFTHdBwnk7JDmeUy/EMJglQRMX745HX5paWB37c14O9uIBc4R2FHvu2iptL1hh2Y oFjD56mbgZ6ciM1h0E4vidrAbzPztKfs4s5XguJVPHw49Qp0cfq+G/9UPz2fnyYrcxSML4eIxZUn seMzuLzpwlGzT4HD3EMMzICh8kMVKPqpdskk5LxBR/9t1zMMNgZ00xRl+f8iOCsvtWSXGxqnOR+D xGR3qCP3ei1hX999s+yzMCxnaIvRTEOY/XUFLzItWCgLp9eSUEiS8gk+ZPjEzm1SsR8v3aJbN/NZ fa/X7fXWg6J5cHei57l/ibtd X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [arch-d] 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, 12 Nov 2020 03:29:20 -0000 This is a multi-part message in MIME format. --------------31A32B1E0BA24B8EDEB0168D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/11/2020 4:37 PM, Martin Thomson wrote: >> Are you really intending to say that a headline goal of QUIC is to mak= e=20 >> it more difficult to manage traffic at the network layer, and by=20 >> implication make it more difficult for ISPs to manage networks? > No, I should have been more careful there. There were a couple of goal= s relevant to this. One was to reduce information exposure and improve p= rivacy with respect to on-path attackers. The other was to limit active = interference by an on-path attacker. > > The net effect is that ISPs are less able to manage the details of othe= r people's interactions. But there are affordances in the protocol that = should allow ISPs (and other network operators) to continue to manage the= ir networks effectively. Of course, it's still a matter of debate how mu= ch information or control network operators need from endpoints, but at l= east QUIC provides end users (or at least end systems) greater ability to= decide what happens. This is not a new debate. The MARNEW workshop was very much dedicated to this topic: how does encryption affect network management. See the report in RFC 8462. Another reference directly related to this subject is RFC 8404, Effects of Pervasive Encryption on Operators. We learned something from MARNEW and from the review process of RFC 8404: "network management" is defined very loosely. When an operator say that they "need to manage the network", it covers a spectrum of things from "being able to debug an error condition" to "being able to extract additional revenues from the network". It is easier to get IETF consensus on some parts of that spectrum than on others. Encryption does not preclude network slices, priorities and other forms of QoS. Applications can absolutely be programmed to explicitly use a QoS API and request a specific form of network service. What encryption precludes is differentiated treatment of various applications without explicit agreement between network and endpoint. We could have a debate over the consequences, but this is a very different issue than concentration. >> I am more concerned about the loss of privacy that seems to be=20 >> occurring at the application layer via extensive tracking of users and= =20 >> sharing of user information, rather than my perception of what is now = >> occurring at the network layer. > A totally legitimate concern, but that line of argumentation sounds lik= e whataboutism. Improvements in privacy with respect to the network do no= t drive privacy violations at the application layer. What Martin says. The draft is supposedly about consolidation. There is definitely a relation between concentration and privacy: if traffic gets consolidated on a small number of big platforms, the owners of these platforms see a lot of data and metadata, which affects privacy. But the relation between that and end-to-end encryption is tenuous. For example, Google was getting just as many cookies before web pages started being sent over HTTPS. The differences is that before encryption other actors were also able to read these cookies. That was hardly a better privacy posture. -- Christian Huitema --------------31A32B1E0BA24B8EDEB0168D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 11/11/2020 4:37 PM, Martin Thomson wrote:

Are you really intending to say that a headline goal of QUIC is to make 
it more difficult to manage traffic at the network layer, and by 
implication make it more difficult for ISPs to manage networks?

No, I should have been more careful there.  There were a couple of goals relevant to this.  One was to reduce information exposure and improve privacy with respect to on-path attackers.  The other was to limit active interference by an on-path attacker.

The net effect is that ISPs are less able to manage the details of other people's interactions.  But there are affordances in the protocol that should allow ISPs (and other network operators) to continue to manage their networks effectively.  Of course, it's still a matter of debate how much information or control network operators need from endpoints, but at least QUIC provides end users (or at least end systems) greater ability to decide what happens.

This is not a new debate. The MARNEW workshop was very much dedicated to this topic: how does encryption affect network management. See the report in RFC 8462. Another reference directly related to this subject is RFC 8404, Effects of Pervasive Encryption on Operators. We learned something from MARNEW and from the review process of RFC 8404: "network management" is defined very loosely. When an operator say that they "need to manage the network", it covers a spectrum of things from "being able to debug an error condition" to "being able to extract additional revenues from the network". It is easier to get IETF consensus on some parts of that spectrum than on others.

Encryption does not preclude network slices, priorities and other forms of QoS. Applications can absolutely be programmed to explicitly use a QoS API and request a specific form of network service. What encryption precludes is differentiated treatment of various applications without explicit agreement between network and endpoint. We could have a debate over the consequences, but this is a very different issue than concentration. 

I am more concerned about the loss of privacy that seems to be 
occurring at the application layer via extensive tracking of users and 
sharing of user information, rather than my perception of what is now 
occurring at the network layer.

A totally legitimate concern, but that line of argumentation sounds like whataboutism. Improvements in privacy with respect to the network do not drive privacy violations at the application layer.

What Martin says. The draft is supposedly about consolidation. There is definitely a relation between concentration and privacy: if traffic gets consolidated on a small number of big platforms, the owners of these platforms see a lot of data and metadata, which affects privacy. But the relation between that and end-to-end encryption is tenuous. For example, Google was getting just as many cookies before web pages started being sent over HTTPS. The differences is that before encryption other actors were also able to read these cookies. That was hardly a better privacy posture.

-- Christian Huitema

--------------31A32B1E0BA24B8EDEB0168D-- From nobody Wed Nov 11 20:00: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 D72223A1392 for ; Wed, 11 Nov 2020 20:00:21 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzzhobgSsRcf for ; Wed, 11 Nov 2020 20:00:20 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 027F33A1391 for ; Wed, 11 Nov 2020 20:00:19 -0800 (PST) Received: from xse452.mail2web.com ([66.113.197.198] helo=xse.mail2web.com) by mx169.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kd3mM-000Gzf-RE for architecture-discuss@ietf.org; Thu, 12 Nov 2020 05:00:15 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CWntc0BjwzPK3 for ; Wed, 11 Nov 2020 20:00:08 -0800 (PST) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kd3mJ-0005hh-TH for architecture-discuss@ietf.org; Wed, 11 Nov 2020 20:00:07 -0800 Received: (qmail 7183 invoked from network); 12 Nov 2020 04:00:07 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.90]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Nov 2020 04:00:07 -0000 To: Dominique Lazanski , architecture-discuss@ietf.org References: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <16eba245-6af8-db43-0249-c94753e692a5@huitema.net> Date: Wed, 11 Nov 2020 20:00:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> Content-Type: multipart/alternative; boundary="------------D83D70428A068D64411AD7AC" Content-Language: en-US X-Originating-IP: 66.113.197.198 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/gcnlw0cThwnZT+ODcFyeCwCHoUjupSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX7v3RfxLkaFQQHea1/b7YbPVO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PutP0Dzal8myJ8vVhoWnSKP9Tn5/AwQYA8p32I/LmTkdq8pnvZ XWSe7jV34Pxn0vH1Lz/y+awqhw7CmTPsWtYsCV/oEQh3zFZ7AJOfdc5NLopVCPmS+MVojfDUugvn Zl+jhHQOLtWk4clq0P6Ltvr/5Zl+BJt+8hYKwgejR0Z9YPn97p3CKmEi95YYeXPNWMiahaC2TJpF rGrq1WX76kTmg5w7R2/M+XaT5BLifEp8KpWu41J1t4cteGI4vH6PuMQp0kaOEXLuWd+6zLg4wp8u XxPcpGyeyPXKNTABBN67jV7JvFCbAD7w3FUirQwmJIqD2OUMeHyTpNN0eXybX/w7/3ZCM0u5uBlK VwmNWN494pUPBFtmg5GCGtjOaQC74kK2uZ9agFNFUxUZLPnr1LybeJhBF+yOavR3Z+X3BZ1+bDW9 zM1SY+9whLXwyGokTgXhMYjMUqZL6iBLUS97OHj8b53ugII7ouYCgfwcsP8qn8jymNgFzWRkuRvd 2hsh/DKjJTkETFTHdBwnk7JDmeUy/CxTYSU7bOY3VNMQgkFetgU14O9uIBc4R2FHvu2iptL1aPVI 7SRheNMtfUmGm8f3604vidrAbzPztKfs4s5XguL2uhT3KQx41zCmSSvPnIYmHzVM9UIEoXM5sSSr Anu6iO3E7PNP9hZ2YPyDLCAHXnUsy647Mn0zwmGzAi3Zn+Ydr38cN0L29hpYqOQomv/Sn4OJCdFr QGG66XtzjgLUDW/OzgRwsx26JIrnuz41QdUugEEc+Eql4Tj+X3YkLe5buSZuZ5OAUoGBziSYFLZu u6wUZYupFCxOQUA2Zz77xVbE X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [arch-d] 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, 12 Nov 2020 04:00:22 -0000 This is a multi-part message in MIME format. --------------D83D70428A068D64411AD7AC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A specific point on the statement in the draft that "Both Christian Huitema and Julien Maisonneuve noted concentration, which leads to consolidation, as an effect of economies of scale and network effects in business models in the implementation of business practices."=A0 There ar= e lots of possible interpretations behind that statement, including the classic "natural monopoly" defense of, well, monopolies. It is very clear that both effects exist, but also that investors who explicitly seek to achieve monopoly do not rely on those two effects alone, and that standards have a role to play. The network effect is in full swing with social networks. Indeed, most of the upstarts social networks do fail rapidly, because they fail to achieve a critical mass of users. There is a long list there, including very well funded initiatives like Google+. The economies of scale effects are also very visible in e-mail services. Effective e-mail service requires big investments to manage spam. In practice, just two providers concentrate a huge part of mail service: Google's GMail and Microsoft's Outlook. Dismissing these effects would be very misleading. Scale also brings knowledge, be it technical knowledge of the application domain or the soft knowledge that comes from observing the behaviors of a large and diverse user base. The products of less=A0 knowledgeable competitors will often be perceived as inferior. Network effects and scale provide advantages to providers who achieve them, and contribute to "naturally" maintaining dominant positions. On the other hand, dominant positions bring lots of advantages to whoever achieves them. In the old industries, dominant positions translated into pricing power. For "free" services, dominant positions translate into gigantic accumulation of data on users, monetized through advertisements. In any case, dominant positions are known to bring big financial rewards. Investors will push entrepreneurs to achieve them with a variety of strategies including selling services at a loss or encouraging competitors to merge. I will stop there, but I have grown sensitive to the "natural monopoly" arguments, and I wanted to clarify my position. -- Christian Huitema On 11/9/2020 9:09 AM, Dominique Lazanski wrote: > Hey Mark and I have a draft on consolidation.=A0 > > Protocol and Engineering Effects of Consolidation can be found > here:=A0https://datatracker.ietf.org/doc/draft-lazanski-consolidation/ > > If you have any thoughts or comments, we would love to have them! > > Dominique > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --------------D83D70428A068D64411AD7AC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

A specific point on the statement in the draft that "Both Christian Huitema and Julien Maisonneuve noted concentration, which leads to consolidation, as an effect of economies of scale and network effects in business models in the implementation of business practices."  There are lots of possible interpretations behind that statement, including the classic "natural monopoly" defense of, well, monopolies. It is very clear that both effects exist, but also that investors who explicitly seek to achieve monopoly do not rely on those two effects alone, and that standards have a role to play.

The network effect is in full swing with social networks. Indeed, most of the upstarts social networks do fail rapidly, because they fail to achieve a critical mass of users. There is a long list there, including very well funded initiatives like Google+. The economies of scale effects are also very visible in e-mail services. Effective e-mail service requires big investments to manage spam. In practice, just two providers concentrate a huge part of mail service: Google's GMail and Microsoft's Outlook. Dismissing these effects would be very misleading. Scale also brings knowledge, be it technical knowledge of the application domain or the soft knowledge that comes from observing the behaviors of a large and diverse user base. The products of less  knowledgeable competitors will often be perceived as inferior. Network effects and scale provide advantages to providers who achieve them, and contribute to "naturally" maintaining dominant positions.

On the other hand, dominant positions bring lots of advantages to whoever achieves them. In the old industries, dominant positions translated into pricing power. For "free" services, dominant positions translate into gigantic accumulation of data on users, monetized through advertisements. In any case, dominant positions are known to bring big financial rewards. Investors will push entrepreneurs to achieve them with a variety of strategies including selling services at a loss or encouraging competitors to merge.

I will stop there, but I have grown sensitive to the "natural monopoly" arguments, and I wanted to clarify my position.

-- Christian Huitema

On 11/9/2020 9:09 AM, Dominique Lazanski wrote:
Hey Mark and I have a draft on consolidation. 

Protocol and Engineering Effects of Consolidation can be found here: https://datatracker.ietf.org/doc/draft-lazanski-consolidation/

If you have any thoughts or comments, we would love to have them!

Dominique

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss
--------------D83D70428A068D64411AD7AC-- From nobody Thu Nov 12 06:46: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 069FE3A11E5 for ; Thu, 12 Nov 2020 06:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=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 h1LFU5QIOJ9E for ; Thu, 12 Nov 2020 06:46:30 -0800 (PST) Received: from mx3.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 4D0533A114C for ; Thu, 12 Nov 2020 06:46:25 -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)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 2A9096A229; Thu, 12 Nov 2020 15:46:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1605192384; bh=Q1BMtVIiEDrBGMA3pTJnuK8lMJ2vPno+uxBKBu8O9zI=; h=Date:From:To:In-Reply-To:References:Subject:From; b=sPd6glAkBJNgTVBcHyhHO+K641G6e0lj8/kSq1j5Belya1Y9HaVmhJ7qsgeE2PcR2 IKj5uklQ6FORNYemwoSAEVrlai2UKMqrqS0TKmdtxHyrzypdlchjJIjpAcueDUcYMW bLWZvd6//2XkzBXA2+5wpfe2zKiLRD6ihCwLiF3GKL7CTTAEE4jyjbv3EWukAbAEiI r0SxZswqJIA/D1kKLo4/1k1KV0wfcFt4keRzQOMWHh5lS5fbDWRIo7dkex0KwsAycU 1xCIVsf9lvqkrTdIK5teEXL6MXlfaqh+SiY7bTBsTgbhiY4jE2lxk4HKnwOxJVuoTb 87QACQ4D29dag== 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 0B4133C0306; Thu, 12 Nov 2020 15:46:24 +0100 (CET) Date: Thu, 12 Nov 2020 15:46:23 +0100 (CET) From: Vittorio Bertola To: Christian Huitema , Martin Thomson , "Rob Wilton (rwilton)" , "architecture-discuss@ietf.org" Message-ID: <1455858417.18508.1605192383942@appsuite-gw1.open-xchange.com> In-Reply-To: References: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> <2bfceb63-1b94-de6f-72e8-4d80eef356f5@digitaldissidents.org> <76dada1c-652b-4d4d-8b7f-ba836660c1d0@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18506_1381525923.1605192383923" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev10 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] 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, 12 Nov 2020 14:46:32 -0000 ------=_Part_18506_1381525923.1605192383923 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 12/11/2020 04:29 Christian Huitema ha scritto: > > > > On 11/11/2020 4:37 PM, Martin Thomson wrote: > > > > > > > > > > > > > I am more concerned about the loss of privacy that seems to be > > > occurring at the application layer via extensive tracking of users and > > > sharing of user information, rather than my perception of what is now > > > occurring at the network layer. > > > > > > > > > > A totally legitimate concern, but that line of argumentation sounds like whataboutism. Improvements in privacy with respect to the network do not drive privacy violations at the application layer. > > > > > > What Martin says. The draft is supposedly about consolidation. There is definitely a relation between concentration and privacy: if traffic gets consolidated on a small number of big platforms, the owners of these platforms see a lot of data and metadata, which affects privacy. But the relation between that and end-to-end encryption is tenuous. For example, Google was getting just as many cookies before web pages started being sent over HTTPS. The differences is that before encryption other actors were also able to read these cookies. That was hardly a better privacy posture. > I note one big risk to privacy that is generated by the introduction of end-to-end encryption, together with the IoT and cloudification trends: end-users - not just network administrators - lose the ability to scrutinize what their applications and devices actually send to their makers, or - in case of self-masquerading technologies like DoH - even to detect that a communication is happening and to block it if they want so. There was a talk about this at the IETF 105 plenary: https://datatracker.ietf.org/meeting/105/materials/slides-105-ietf-sesse-lessons-from-privacy-measurement-arvind-narayanan-00 Indeed, one of the side effects of DoH for some (more technical) users is to disrupt their Pi-holes and other DNS-based tracker blockers. Consolidation underpins all of this, as in the "surveillance capitalism" business model whoever has more opportunities to acquire information wins. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_18506_1381525923.1605192383923 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 12/11/2020 04:29 Christian Huitema <huitema@huitema.net> ha scritto:


On 11/11/2020 4:37 PM, Martin Thomson wrote:

I am more concerned about the loss of privacy that seems to be 
occurring at the application layer via extensive tracking of users and 
sharing of user information, rather than my perception of what is now 
occurring at the network layer.

A totally legitimate concern, but that line of argumentation sounds like whataboutism. Improvements in privacy with respect to the network do not drive privacy violations at the application layer.

What Martin says. The draft is supposedly about consolidation. There is definitely a relation between concentration and privacy: if traffic gets consolidated on a small number of big platforms, the owners of these platforms see a lot of data and metadata, which affects privacy. But the relation between that and end-to-end encryption is tenuous. For example, Google was getting just as many cookies before web pages started being sent over HTTPS. The differences is that before encryption other actors were also able to read these cookies. That was hardly a better privacy posture.

I note one big risk to privacy that is generated by the introduction of end-to-end encryption, together with the IoT and cloudification trends: end-users - not just network administrators - lose the ability to scrutinize what their applications and devices actually send to their makers, or - in case of self-masquerading technologies like DoH - even to detect that a communication is happening and to block it if they want so. There was a talk about this at the IETF 105 plenary:
https://datatracker.ietf.org/meeting/105/materials/slides-105-ietf-sesse-lessons-from-privacy-measurement-arvind-narayanan-00

Indeed, one of the side effects of DoH for some (more technical) users is to disrupt their Pi-holes and other DNS-based tracker blockers.

Consolidation underpins all of this, as in the "surveillance capitalism" business model whoever has more opportunities to acquire information wins.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_18506_1381525923.1605192383923-- From nobody Thu Nov 12 08:18: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 4732C3A1384 for ; Thu, 12 Nov 2020 08:18:42 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSxp1MlPG-GM for ; Thu, 12 Nov 2020 08:18:40 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 1F12E3A1382 for ; Thu, 12 Nov 2020 08:18:39 -0800 (PST) Received: from xse477.mail2web.com ([66.113.197.223] helo=xse.mail2web.com) by mx105.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kdFIu-0007va-AB for architecture-discuss@ietf.org; Thu, 12 Nov 2020 17:18:38 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CX6GY2wtsz53BK for ; Thu, 12 Nov 2020 08:18:29 -0800 (PST) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kdFIr-0006Q3-9P for architecture-discuss@ietf.org; Thu, 12 Nov 2020 08:18:29 -0800 Received: (qmail 27017 invoked from network); 12 Nov 2020 16:11:48 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.90]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Nov 2020 16:11:48 -0000 To: Vittorio Bertola , Martin Thomson , "Rob Wilton (rwilton)" , "architecture-discuss@ietf.org" References: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> <2bfceb63-1b94-de6f-72e8-4d80eef356f5@digitaldissidents.org> <76dada1c-652b-4d4d-8b7f-ba836660c1d0@www.fastmail.com> <1455858417.18508.1605192383942@appsuite-gw1.open-xchange.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: Date: Thu, 12 Nov 2020 08:11:50 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <1455858417.18508.1605192383942@appsuite-gw1.open-xchange.com> Content-Type: multipart/alternative; boundary="------------D2085F4983AADEFEFA2FD346" Content-Language: en-US X-Originating-IP: 66.113.197.223 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/gcnlw0cThwnZT+ODcFyeCwCHoUjupSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX72RtenPYdNk8FG35Wb7HiAFO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PutP0Dzal8myJ8vVhoWnSKPxtCheh5C7lovH0u37yux7G8pnvZ XWSe7jV34Pxn0vH1Lz/y+awqhw7CmTPsWtYsCV/oEQh3zFZ7AJOfdc5NLopVCPmS+MVojfDUugvn Zl+jhHQOLtWk4clq0P6Ltvr/5Zl+BJt+8hYKwgejR0Z9YPn97p3CKmEi95YYeXPNWMiahaC2TJpF rGrq1WX76kTmg5w7R2/M+XaT5BLifEp8KpWu41J1t4cteGI4vH6PuMQp0kaOEXLuWd+6zLg4wp8u XxPcpGyeyPXKNTABBN67jV7JvFCbAD7w3FUirQwmJIqD2OUMeHyTpNN0eXybX/w7/3ZCM0u5uBlK VwmNWN494pVPbmg7CD5DvTXFdlFnYu62DYH7JT8ICzD3ld7Lkg0SVZ1+rsC5ZGVYG+AECQYSXUVY dGBMwvH1Yva9EPhd1Mo0MYjMUqZL6iBLUS97OHj8b53ugII7ouYCgfwcsP8qn8jymNgFzWRkuRvd 2hsh/DKjJTkETFTHdBwnk7JDmeUy/GQ+48t7tOgPZxfWe3xH0dE14O9uIBc4R2FHvu2iptL1qPwK bbuRXw5Q3vRBmasazU4vidrAbzPztKfs4s5XguL2uhT3KQx41zCmSSvPnIYmCmnFEKPAYhTMxt8K 3A07ru3E7PNP9hZ2YPyDLCAHXnUsy647Mn0zwmGzAi3Zn+Ydr38cN0L29hpYqOQomv/Sn4OJCdFr QGG66XtzjgLUDW/OzgRwsx26JIrnuz41QdUugEEc+Eql4Tj+X3YkLe5buSZuZ5OAUoGBziSYFLZu u6wUZYupFCxOQUA2Zz77xVbE X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [arch-d] 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, 12 Nov 2020 16:18:42 -0000 This is a multi-part message in MIME format. --------------D2085F4983AADEFEFA2FD346 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/12/2020 6:46 AM, Vittorio Bertola wrote: > >> Il 12/11/2020 04:29 Christian Huitema ha scritto= : >> >> >> On 11/11/2020 4:37 PM, Martin Thomson wrote: >> >>>> I am more concerned about the loss of privacy that seems to be=20 >>>> occurring at the application layer via extensive tracking of users a= nd=20 >>>> sharing of user information, rather than my perception of what is no= w=20 >>>> occurring at the network layer. >>> A totally legitimate concern, but that line of argumentation sounds l= ike whataboutism. Improvements in privacy with respect to the network do = not drive privacy violations at the application layer. >> >> What Martin says. The draft is supposedly about consolidation. There >> is definitely a relation between concentration and privacy: if >> traffic gets consolidated on a small number of big platforms, the >> owners of these platforms see a lot of data and metadata, which >> affects privacy. But the relation between that and end-to-end >> encryption is tenuous. For example, Google was getting just as many >> cookies before web pages started being sent over HTTPS. The >> differences is that before encryption other actors were also able to >> read these cookies. That was hardly a better privacy posture. >> > I note one big risk to privacy that is generated by the introduction > of end-to-end encryption, together with the IoT and cloudification > trends: end-users - not just network administrators - lose the ability > to scrutinize what their applications and devices actually send to > their makers, or - in case of self-masquerading technologies like DoH > - even to detect that a communication is happening and to block it if > they want so. There was a talk about this at the IETF 105 plenary: > https://datatracker.ietf.org/meeting/105/materials/slides-105-ietf-sess= e-lessons-from-privacy-measurement-arvind-narayanan-00 Device inspection is an interesting issue, but it is far to being as clear-cut as you present it. Take the example of a doorbell camera. It sends motion activated video streams to a cloud server, from which they can be accessed by the home owners using their cell phone. If the traffic was in the clear, inspection would reveal exactly that: motion activated video streams to a cloud server. It will not reveal whether the cloud servers provide a copy of the video streams to the police. It will not tell whether the servers perform face recognition on the incoming images, and use that for tracking the movement of people walking nearby. Encryption will prevent that inspection, but it will also prevent third parties from tapping into the video stream and performing their own parasitic surveillance. From a privacy point of view, encryption there is a net gain -- but the presence of the devices themselves may well be a huge los= s. The inspection performed by researchers revealed that some devices where performing extra tasks, not described in the public specification of the device. Maybe a child's toy also sending data about the children to its manufacturer. Inspection by researchers has revealed such shenanigans in the past, and the inspection was typically done by breaking the device encryption using spoofed server certificates. Should we then recommend that all devices should accept spoofed server certificates? That would be opening the gates to a free-for-all of hacking and banditry. It would also not solve the "cloud connection" problem shown with the doorbell cameras. The device problem is real, but the solution certainly is not to make the devices easy to break by third parties. Instead I would rather see consumer bureaus stepping in and providing "clean device" certification labels, after inspecting devices and services in which the protections have been lifted by the manufacturer. Or, law enforcement could step in and severely punish device manufacturers engaged in deceptive practices, either on the device or in the cloud servers. > > Indeed, one of the side effects of DoH for some (more technical) users > is to disrupt their Pi-holes and other DNS-based tracker blockers. > > Consolidation underpins all of this, as in the "surveillance > capitalism" business model whoever has more opportunities to acquire > information wins. There is definitely a relation between surveillance capitalism and consolidation, but you don't need to discuss the encryption of communication to make that point. -- Christian Huitema > --=20 > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com =20 > Office @ Via Treviso 12, 10144 Torino, Italy --------------D2085F4983AADEFEFA2FD346 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/12/2020 6:46 AM, Vittorio Bertola wrote:

Il 12/11/2020 04:29 Christian Huitema <huitema@huitema.net> ha scritto:


On 11/11/2020 4:37 PM, Martin Thomson wrote:

I am more concerned about the loss of privacy that seems to be 
occurring at the application layer via extensive tracking of users and 
sharing of user information, rather than my perception of what is now 
occurring at the network layer.

A totally legitimate concern, but that line of argumentation sounds like whataboutism. Improvements in privacy with respect to the network do not drive privacy violations at the application layer.

What Martin says. The draft is supposedly about consolidation. There is definitely a relation between concentration and privacy: if traffic gets consolidated on a small number of big platforms, the owners of these platforms see a lot of data and metadata, which affects privacy. But the relation between that and end-to-end encryption is tenuous. For example, Google was getting just as many cookies before web pages started being sent over HTTPS. The differences is that before encryption other actors were also able to read these cookies. That was hardly a better privacy posture.

I note one big risk to privacy that is generated by the introduction of end-to-end encryption, together with the IoT and cloudification trends: end-users - not just network administrators - lose the ability to scrutinize what their applications and devices actually send to their makers, or - in case of self-masquerading technologies like DoH - even to detect that a communication is happening and to block it if they want so. There was a talk about this at the IETF 105 plenary:
https://datatracker.ietf.org/meeting/105/materials/slides-105-ietf-sesse-lessons-from-privacy-measurement-arvind-narayanan-00

Device inspection is an interesting issue, but it is far to being as clear-cut as you present it.

Take the example of a doorbell camera. It sends motion activated video streams to a cloud server, from which they can be accessed by the home owners using their cell phone. If the traffic was in the clear, inspection would reveal exactly that: motion activated video streams to a cloud server. It will not reveal whether the cloud servers provide a copy of the video streams to the police. It will not tell whether the servers perform face recognition on the incoming images, and use that for tracking the movement of people walking nearby. Encryption will prevent that inspection, but it will also prevent third parties from tapping into the video stream and performing their own parasitic surveillance. From a privacy point of view, encryption there is a net gain -- but the presence of the devices themselves may well be a huge loss.

The inspection performed by researchers revealed that some devices where performing extra tasks, not described in the public specification of the device. Maybe a child's toy also sending data about the children to its manufacturer. Inspection by researchers has revealed such shenanigans in the past, and the inspection was typically done by breaking the device encryption using spoofed server certificates. Should we then recommend that all devices should accept spoofed server certificates? That would be opening the gates to a free-for-all of hacking and banditry. It would also not solve the "cloud connection" problem shown with the doorbell cameras.

The device problem is real, but the solution certainly is not to make the devices easy to break by third parties. Instead I would rather see consumer bureaus stepping in and providing "clean device" certification labels, after inspecting devices and services in which the protections have been lifted by the manufacturer. Or, law enforcement could step in and severely punish device manufacturers engaged in deceptive practices, either on the device or in the cloud servers.


Indeed, one of the side effects of DoH for some (more technical) users is to disrupt their Pi-holes and other DNS-based tracker blockers.

Consolidation underpins all of this, as in the "surveillance capitalism" business model whoever has more opportunities to acquire information wins.

There is definitely a relation between surveillance capitalism and consolidation, but you don't need to discuss the encryption of communication to make that point.

-- Christian Huitema





-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
--------------D2085F4983AADEFEFA2FD346-- From nobody Thu Nov 12 09:47: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 6F3EB3A145A; Thu, 12 Nov 2020 09:47:28 -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=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 Ar8kfpAWxScG; Thu, 12 Nov 2020 09:47:26 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 A6C2B3A1456; Thu, 12 Nov 2020 09:47:26 -0800 (PST) Received: from p200300dee707b600141061c179aad33d.dip0.t-ipconnect.de ([2003:de:e707:b600:1410:61c1:79aa:d33d]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kdGgs-0002tA-M8; Thu, 12 Nov 2020 18:47:22 +0100 From: Mirja Kuehlewind Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 12 Nov 2020 18:47:21 +0100 Message-Id: <3036D6C9-A1F4-4035-B039-0C9E75DE55C4@kuehlewind.net> To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1605203246;3e619cba; X-HE-SMSGID: 1kdGgs-0002tA-M8 Archived-At: Subject: [arch-d] Call for Feedback on the new proposed structure for Technical Programs and Administrative Support Groups 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, 12 Nov 2020 17:47:28 -0000 Hi all, The IAB has been working on refactoring its programs. You can find the = proposed description of the new structure and procedures on Github [1]. = The aim of this effort is to increase transparency, visibility, and = openness of the architectural work done by the IAB.=20 In analysing the current IAB programs, the IAB identified two kinds of = programs which are quite different in their needs and goals. Therefore, = the new structure proposes to separate today=E2=80=99s IAB programs into = Technical Programs and Administrative Support Groups.=20 Technical Programs are more short-lived activities (even though this = might be longer than one IAB cycle) and focus on specific technical or = architectural issues that require both input from experts as well as = community discussion. Current Technical Programs are model-t and EDM.=20 Administrative Support Groups are long-term activities that help the IAB = to fulfil their oversight or administrative responsibilities. Based on = the nature of their task these groups usually consist of a small, = dedicated set of experts that may have a need to handle matters = confidentially. Administrative Support Groups are the current technical = plenary program, the IANA program, and the liaison program. Please note = that the IAB is also in the progress of reviewing these activities.=20 RSOC could also be considered as an Administrative Support Group; = however, given the on-going process in the future RFC editor model = program, the IAB will not implement any changes or actions on RSOC until = this process has concluded. Further, the future RFC editor model program is not considered in this = new structure. The IAB is not intending to implement any changes or = intervene in any way with the work of the program. We believe that this new structure will better support the IAB=E2=80=99s = needs and hopefully clarify procedures and expectation. Further, we hope = that this will also help to increase the exchange with the community! Please provide feedback on this mailing list, on GitHub by raising an = issue, or directly to the IAB . Mirja K=C3=BChlewind IAB chair [1] = https://github.com/intarchboard/IAB-programs/blob/master/IAB-programs.md From nobody Thu Nov 12 11:58: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 DB0F83A03FC for ; Thu, 12 Nov 2020 11:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, 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=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StGO3pKq0XJi for ; Thu, 12 Nov 2020 11:58:14 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 BD42C3A03F3 for ; Thu, 12 Nov 2020 11:58:14 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id z24so5125075pgk.3 for ; Thu, 12 Nov 2020 11:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=9qyt+9AAi1xZliH3xsn18lC6D97V4PYaF2g1N+h6gHE=; b=AEG+R1294kJiZL5K5xdrheZlXnePdBb88Av/iDz9nw4K3PIsAarWJg8MN74X1pJjM8 Tx6/MhCXwTYOmuhltl9PpFEK1ysOD1+wfDzAMnjBKFAGgw3lAYLdHnNcplw4y8ZoB0el lSaGfx31XS+wbRZO+OhdKEn3WCmSMryOZNVmUGkChpa1cW/BdORx323KpHS5z53lH5ws ArHf16PZq1MLSE9bAhVTWBLZj+79B76Z1yxKxtqr739dTvuz61LyWpy2Fz02HSfJjOZE QXDhrFyl/QL9UsDdc3xgaLeqZJOuz7IevUfeiewS99W+x1aBt2XM7HYrXdfOk9ut8j7J WbCg== 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:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=9qyt+9AAi1xZliH3xsn18lC6D97V4PYaF2g1N+h6gHE=; b=bE0NNsldZnAjDNXj7skCisLFUmTX2zCDXHk5A01egzRKhOKnOQuqtVuM0mePlWmBaY fbanusxU4+dskvTr7yjzxNLjaOD+znxCRNRP0c+Q7Qu8QtzAgxn3sWo+p7g++oLcRoNI JufzqvjbmGRNooRpfTZB4NO3BMipT2NcdgSJ+a3Da5b0YaAclJQpxjr1fCv7ikbGUpJ0 WhvAPX+ZomtshSPveuUzjV7mHKkB8WbcS4lsUk7ik2tgKxLmSKGPgIZShJVyfbmvLl8E u6PWn3byL5RIgXSqjrfo4mEBJTTuD+XUotvit7HGi1ZP5Few5yx68DKLI6UtoOBhKi2x HRXw== X-Gm-Message-State: AOAM5303q0zGs0B9VxqF0VO8ujL5WHxvdNlDH3SMnHTSmPLy5qolpZbB pvcInhAxemFpg+fSQs5FOplqMxVK4dVY X-Google-Smtp-Source: ABdhPJygrrvLjQ61J8unbZ9Z6awVv5yq7YcQ1NyTpnhucyOJJXjXNSjb7+V0f+d0MlYXrNSJXU2cyQ== X-Received: by 2002:a63:f944:: with SMTP id q4mr935051pgk.98.1605211093891; Thu, 12 Nov 2020 11:58:13 -0800 (PST) Received: from [192.168.1.137] (63-140-65-5.dynamic.lte.acsalaska.net. [63.140.65.5]) by smtp.gmail.com with ESMTPSA id v23sm7511990pjh.46.2020.11.12.11.58.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Nov 2020 11:58:12 -0800 (PST) To: architecture-discuss@ietf.org References: <3036D6C9-A1F4-4035-B039-0C9E75DE55C4@kuehlewind.net> From: Melinda Shore Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: <5a803090-c188-088c-507d-4ff1f2ab78f9@nomountain.net> Date: Thu, 12 Nov 2020 10:57:52 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <3036D6C9-A1F4-4035-B039-0C9E75DE55C4@kuehlewind.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RxDBt0eyPvwRfkplT7xfGyIUz5DUabCvG" Archived-At: Subject: Re: [arch-d] Call for Feedback on the new proposed structure for Technical Programs and Administrative Support Groups 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, 12 Nov 2020 19:58:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RxDBt0eyPvwRfkplT7xfGyIUz5DUabCvG Content-Type: multipart/mixed; boundary="M2PEbtmBYdw45lPgOUXbdfvoxlBahmF65" --M2PEbtmBYdw45lPgOUXbdfvoxlBahmF65 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/12/20 8:47 AM, Mirja Kuehlewind wrote:> The IAB has been working on refactoring its programs. You can find > the proposed description of the new structure and procedures on > Github [1]. The aim of this effort is to increase transparency, > visibility, and openness of the architectural work done by the IAB. Out of curiosity, is this in response to a problem? Melinda --=20 Software longa, hardware brevis PGP key fingerprint 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F --M2PEbtmBYdw45lPgOUXbdfvoxlBahmF65-- --RxDBt0eyPvwRfkplT7xfGyIUz5DUabCvG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl+tk9MACgkQ37iRcpp2 24/sgRAAw2l14VC2h15KaGIHdxJ3GRcjmjcvyMZqHvyLw9ojlh9HDYEg67mwVcLv /K1KPVx5jp9DcAP8suqD+o7kA+7VhCfZcoiAy5uIwDsPpjZscQXCnEINnAhTvnrP RdaeUvQhz+dLQmmGR7QUFXFTiOg9lXBtogH55X3tKl2vCynNeaTucJgHmsTGPi6S eUmm0ea6ZBshP/saKQrDt8vPZSZ8uUXy4cMKAR4tHnhhVY0JrKV/kBE3Axm4SN3Y VVN9PiMnkp+dNl0RlBlgtibPwrvzR6yjefCu+ZLajlZG8Ns9hYt4v5hsYTZK3NEa Gj37K46Gj4SzCoy/LgkTzmeTwS+no3w+Kl3FdNAGgYt+6OamDi/DFPnTSGZvIGuK H5UqgsF9x/dLCds1vgD4MV5TdotLwbjCyjyf6VNpaATSeRwxBn2wasTNLMMFbvCx IOGRgY9GVPWjpkyE7/fZmVY7R2fj7LnMqcyIx8on+03gkhgvwI8JxlLvpDI8Ki0f Vkds8IvYPpkRzar0LtSM1nk2j2FtNRtg4yGLHMJgc3SK/JSB5UxSHYAsOw7bHLWK EhJmKn7V9NXFKjT3KPVahMnHJaep4X9nmX82rwnucwfTTy1V0EavZx4wXwUjU5p0 4JHfbWa6WCywR++3C9qPVThuukR/9c04Mwdxue9a3uuxUg29hVY= =5YXO -----END PGP SIGNATURE----- --RxDBt0eyPvwRfkplT7xfGyIUz5DUabCvG-- From nobody Thu Nov 12 12:29: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 7240F3A0639 for ; Thu, 12 Nov 2020 12:29: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=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 YxRCDoFhz4C3 for ; Thu, 12 Nov 2020 12:29:11 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 A69DC3A0769 for ; Thu, 12 Nov 2020 12:29:11 -0800 (PST) Received: from p200300dee707b600141061c179aad33d.dip0.t-ipconnect.de ([2003:de:e707:b600:1410:61c1:79aa:d33d]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kdJDR-0002La-1W; Thu, 12 Nov 2020 21:29:09 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: <5a803090-c188-088c-507d-4ff1f2ab78f9@nomountain.net> Date: Thu, 12 Nov 2020 21:29:07 +0100 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6F24DB57-639D-473A-8FB6-CA4776F38BE4@kuehlewind.net> References: <3036D6C9-A1F4-4035-B039-0C9E75DE55C4@kuehlewind.net> <5a803090-c188-088c-507d-4ff1f2ab78f9@nomountain.net> To: Melinda Shore X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1605212951;4452b375; X-HE-SMSGID: 1kdJDR-0002La-1W Archived-At: Subject: Re: [arch-d] Call for Feedback on the new proposed structure for Technical Programs and Administrative Support Groups 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, 12 Nov 2020 20:29:13 -0000 Hi Melinda, I should probably have said that there is a description on the IAB = webpage about programs (https://www.iab.org/activities/programs/) which = however is rather out-dated compared to what we do in programs these = days. So the goal is more transparency and openness in the program = itself but also in the way we maintain them. There has been no concrete = event that this is a response to, if that was the question, but I think = you know that the IAB has been discussing this for a while already. Mirja > On 12. Nov 2020, at 20:57, Melinda Shore = wrote: >=20 > On 11/12/20 8:47 AM, Mirja Kuehlewind wrote:> The IAB has been working > on refactoring its programs. You can find >> the proposed description of the new structure and procedures on >> Github [1]. The aim of this effort is to increase transparency, >> visibility, and openness of the architectural work done by the IAB. >=20 > Out of curiosity, is this in response to a problem? >=20 > Melinda >=20 > --=20 > Software longa, hardware brevis >=20 > PGP key fingerprint 4F68 2D93 2A17 96F8 20F2 > 34C0 DFB8 9172 9A76 DB8F >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Thu Nov 12 12:33: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 2283F3A07C3 for ; Thu, 12 Nov 2020 12:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Gtf3djF9762P for ; Thu, 12 Nov 2020 12:33:09 -0800 (PST) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 15A643A0062 for ; Thu, 12 Nov 2020 12:33:08 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id i186so6590495ybc.11 for ; Thu, 12 Nov 2020 12:33:08 -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=Fpmp5mN4hHUNeOvemHbbaCsGMbC1z6zLL0LrbWmzSRE=; b=pCU7YUmEKhY29dNdQbIUd4qiecjzF5dYqM6qKxgkNGBTO6n6R3E7b/wP2J6o1Cg532 ylxGhiKSd6ybu3nKkq7+0Yb7Wt1fpKOgdk52DWsOmn/CsPDaBYTvybG5tFIHg+J/V5CG UuWfDPReHpUuaBGaQT53G3vbjTPZteLU3wUYLAKWMOXLfVJkva9tFu1W/7FbsOoAfezw xjrjEdsut35GfwOE80dwwC5ovHBTceee58lmq6YS7Y27FV63iHF92ZPH0jDcKS5ngE/V yDzC/3RbWAo8yrh8ZKwMdM8T3EiDAfvoXM6kAUljHxB4R3RTMiiNA/MEeTBnRjqGeuqD nbWQ== 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=Fpmp5mN4hHUNeOvemHbbaCsGMbC1z6zLL0LrbWmzSRE=; b=F/2SBHbVryhDScLNkF9PFRLljHGPeX5MTVowrlk1N1DvvTDmQiI++TeJ5oYUOj6nEY 0KLE4NrXxNzAcqL+rNZ9MOYR6dXAhn/VxWiJoQQu1xNZYB5f5FIR40RF+c8KTF3l7SdU XN7VlT+yl+V1Y+7/Z5GEf0XtdTpZvnsQPbUEKHJxhCzxIvhPeDs/XhlxAcRY2o7TSbxZ KJWKyvlEXTA96vOGMI5S6BBEC2kHdIkWPEfKg3V6RNnGhlRFSuaj52lEHLzp70sF3A09 R9hnp3rCQMng1utrgYebGmj1ggfxabgBZCE0PT5ZIvNQ5+jK/d6c7Y7x96Jg41jDiQIK a8Yw== X-Gm-Message-State: AOAM5325kM9RVTmHrMLL45L7nYxqpHKPKWGZiAYlLanoag9O6HFtjfYO EgAN32JG8YF9bkXGcL4ILZWaLYSj0wpvuYIYlXg= X-Google-Smtp-Source: ABdhPJwOaaI6ilifmovn8ciY7xRBiPSk5xSvGtxiE0Zwq62qjRt9U+Kazr4dJWWL+8sPJD1D2UHLlCahvukFK1VtoqU= X-Received: by 2002:a25:bd7:: with SMTP id 206mr1973585ybl.84.1605213188097; Thu, 12 Nov 2020 12:33:08 -0800 (PST) MIME-Version: 1.0 References: <3036D6C9-A1F4-4035-B039-0C9E75DE55C4@kuehlewind.net> In-Reply-To: <3036D6C9-A1F4-4035-B039-0C9E75DE55C4@kuehlewind.net> From: Spencer Dawkins at IETF Date: Thu, 12 Nov 2020 14:32:42 -0600 Message-ID: To: Mirja Kuehlewind Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000dd89ef05b3eed1c0" Archived-At: Subject: Re: [arch-d] Call for Feedback on the new proposed structure for Technical Programs and Administrative Support Groups 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, 12 Nov 2020 20:33:11 -0000 --000000000000dd89ef05b3eed1c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Mirja, and the IAB, On Thu, Nov 12, 2020 at 11:47 AM Mirja Kuehlewind wrote: > Hi all, > > The IAB has been working on refactoring its programs. You can find the > proposed description of the new structure and procedures on Github [1]. T= he > aim of this effort is to increase transparency, visibility, and openness = of > the architectural work done by the IAB. > > In analysing the current IAB programs, the IAB identified two kinds of > programs which are quite different in their needs and goals. Therefore, t= he > new structure proposes to separate today=E2=80=99s IAB programs into Tech= nical > Programs and Administrative Support Groups. > > Technical Programs are more short-lived activities (even though this migh= t > be longer than one IAB cycle) and focus on specific technical or > architectural issues that require both input from experts as well as > community discussion. Current Technical Programs are model-t and EDM. > > Administrative Support Groups are long-term activities that help the IAB > to fulfil their oversight or administrative responsibilities. Based on th= e > nature of their task these groups usually consist of a small, dedicated s= et > of experts that may have a need to handle matters confidentially. > Administrative Support Groups are the current technical plenary program, > the IANA program, and the liaison program. Please note that the IAB is al= so > in the progress of reviewing these activities. > This roughly makes sense to me, but I would suggest finding another term beyond "Administrative Support", which seems to collide fabulously with the use of the word "Administrative" all over the IETF. I think it's accurate to say that these are "Oversight Groups", each tied closely to an IAB responsibility in https://tools.ietf.org/html/rfc2850#section-2. I'm not wedded to "Oversight", but please don't use "Administrative", because we'll spend the next decade or two explaining the difference between these programs and stuff in the IETF. I'm not sure why the IAB is talking about "Groups" for these instead of "Programs", which is (I think) an understood-as-IAB term, but I'm assuming there's a reason, such as the management procedures are different. If that's not true, "Oversight Programs" would be an improvement. I know you'll Do The Right Thing, of course. Best, Spencer > RSOC could also be considered as an Administrative Support Group; however= , > given the on-going process in the future RFC editor model program, the IA= B > will not implement any changes or actions on RSOC until this process has > concluded. > > Further, the future RFC editor model program is not considered in this ne= w > structure. The IAB is not intending to implement any changes or intervene > in any way with the work of the program. > > We believe that this new structure will better support the IAB=E2=80=99s = needs and > hopefully clarify procedures and expectation. Further, we hope that this > will also help to increase the exchange with the community! > > Please provide feedback on this mailing list, on GitHub by raising an > issue, or directly to the IAB . > > Mirja K=C3=BChlewind > IAB chair > > [1] > https://github.com/intarchboard/IAB-programs/blob/master/IAB-programs.md > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000dd89ef05b3eed1c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Mirja, and the IAB,=C2=A0

On Thu, Nov = 12, 2020 at 11:47 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
Hi all,

The IAB has been working on refactoring its programs. You can find the prop= osed description of the new structure and procedures on Github [1]. The aim= of this effort is to increase transparency, visibility, and openness of th= e architectural work done by the IAB.

In analysing the current IAB programs, the IAB identified two kinds of prog= rams which are quite different in their needs and goals. Therefore, the new= structure proposes to separate today=E2=80=99s IAB programs into Technical= Programs and Administrative Support Groups.

Technical Programs are more short-lived activities (even though this might = be longer than one IAB cycle) and focus on specific technical or architectu= ral issues that require both input from experts as well as community discus= sion. Current Technical Programs are model-t and EDM.

Administrative Support Groups are long-term activities that help the IAB to= fulfil their oversight or administrative responsibilities. Based on the na= ture of their task these groups usually consist of a small, dedicated set o= f experts that may have a need to handle matters confidentially. Administra= tive Support Groups are the current technical plenary program, the IANA pro= gram, and the liaison program. Please note that the IAB is also in the prog= ress of reviewing these activities.

Th= is roughly makes sense to me, but I would suggest finding another term beyo= nd "Administrative Support", which seems to collide fabulously wi= th the use of the word "Administrative" all over the IETF.=C2=A0<= /div>

I think it's accurate to say that these are &q= uot;Oversight Groups", each tied closely to an IAB responsibility in= =C2=A0https://too= ls.ietf.org/html/rfc2850#section-2.

I'm no= t wedded to "Oversight", but please don't use "Administr= ative", because we'll spend the next decade or two explaining the = difference between these programs and stuff in the IETF.=C2=A0
I'm not sure why the IAB is talking about "Groups&quo= t; for these instead of "Programs", which is (I think) an underst= ood-as-IAB term, but I'm assuming there's a reason, such as the man= agement procedures are different. If that's not true, "Oversight P= rograms" would be an improvement.=C2=A0

I kno= w you'll Do The Right Thing, of course.

Best,<= /div>

Spencer
=C2=A0
RSOC could also be considered as an Administr= ative Support Group; however, given the on-going process in the future RFC = editor model program, the IAB will not implement any changes or actions on = RSOC until this process has concluded.

Further, the future RFC editor model program is not considered in this new = structure. The IAB is not intending to implement any changes or intervene i= n any way with the work of the program.

We believe that this new structure will better support the IAB=E2=80=99s ne= eds and hopefully clarify procedures and expectation. Further, we hope that= this will also help to increase the exchange with the community!

Please provide feedback on this mailing list, on GitHub by raising an issue= , or directly to the IAB <iab@iab.org>.

Mirja K=C3=BChlewind
IAB chair

[1] https://github.com/intar= chboard/IAB-programs/blob/master/IAB-programs.md


_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000dd89ef05b3eed1c0-- From nobody Thu Nov 12 12:43: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 EFA5F3A07F9 for ; Thu, 12 Nov 2020 12:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ZdnU2Q8XvsMU for ; Thu, 12 Nov 2020 12:43:43 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 A14EB3A07DE for ; Thu, 12 Nov 2020 12:43:43 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id 2so6600874ybc.12 for ; Thu, 12 Nov 2020 12:43:43 -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=eNoiLSu5AtlRQCNg7a9/wj6RF8Epd+zz18JC7D7eWl4=; b=Vx5GDm9nv70GchLy3W0ENn4HtS3ce0JWXqkK9qSZNtj6NNS6By+WLtHnrqRlGzgLW1 7fddtR1sPFFNdjgk92jDG6x4lq360nGO9jIlqTXLNv8AZ4v08ZLhkUEBO6XjT6gEeQg4 nAlfWuJh+ifkeGF/KBSqc/SNpwPWfZdw4rqjDe38j+ncqQY6qJk9QA4+DtqXLyogpW2i +jyf6Q+6Z596w/apQMdJM8wxwM3q1Vl5+jkKBKbHnin4YleSybEWMw7n70Sf0d8FnHpX uvWzCcIvUMKekMrmq3PwtKJpE5rbNvyRF18F1wAp0TG4gtXDC+xHzSPNgFmfi+dEFucd ZRGA== 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=eNoiLSu5AtlRQCNg7a9/wj6RF8Epd+zz18JC7D7eWl4=; b=WYy8g3ZXqejZxHtO/8SQs0h+h0q+u9kdeEWI8u/xhv6TIY9IcJoU/Z5dswSuYlUr0P o6JVpx8wnGO3jJOwSj0opDSGBxI64NtKGcBxk1pvwNUO4xcH30zBvrVKy5wrUuqulxCK li5A9b976BQSLN8vc4ltAzL16Y7pi5eRh5W41cgzZ+CZ8hWGOc/5Pn5vmFJVExaMNZG5 0/9a3/0XQXwJZmE1HRNhlQk/LtHnL5Nk1WC7YCHPj7hSiKXD/fLcMtpanKd31JCfMHYU wUNnFr9D8Sks2IDu7AbKLdOHolk2P0QRUMEHNPO4S2UoNFHeRkH/c79VJcolaV4U6IM3 Cv5w== X-Gm-Message-State: AOAM532gDu8uRGyExJxah6WgI0ZMSnmaFzBNpV4Kp7MvqWbppbzZcN8W AcXTDK+AOAGp/N/xXD1iXPNa6dNQgbkuiLpd9bQ= X-Google-Smtp-Source: ABdhPJzIRd7UVad+BQ1GB3awJurXAiUNYd70+rPi71qk8O97SgpMeaYkA2dm5vnxgBowHKVzC20q+rr4wlA24pKFF68= X-Received: by 2002:a25:884:: with SMTP id 126mr1429462ybi.154.1605213822904; Thu, 12 Nov 2020 12:43:42 -0800 (PST) MIME-Version: 1.0 References: <3036D6C9-A1F4-4035-B039-0C9E75DE55C4@kuehlewind.net> <5a803090-c188-088c-507d-4ff1f2ab78f9@nomountain.net> <6F24DB57-639D-473A-8FB6-CA4776F38BE4@kuehlewind.net> In-Reply-To: <6F24DB57-639D-473A-8FB6-CA4776F38BE4@kuehlewind.net> From: Spencer Dawkins at IETF Date: Thu, 12 Nov 2020 14:43:16 -0600 Message-ID: To: Mirja Kuehlewind Cc: Melinda Shore , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000b40e4205b3eef7eb" Archived-At: Subject: Re: [arch-d] Call for Feedback on the new proposed structure for Technical Programs and Administrative Support Groups 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, 12 Nov 2020 20:43:46 -0000 --000000000000b40e4205b3eef7eb Content-Type: text/plain; charset="UTF-8" FWIW, On Thu, Nov 12, 2020 at 2:29 PM Mirja Kuehlewind wrote: > Hi Melinda, > > I should probably have said that there is a description on the IAB webpage > about programs (https://www.iab.org/activities/programs/) which however > is rather out-dated compared to what we do in programs these days. So the > goal is more transparency and openness in the program itself but also in > the way we maintain them. There has been no concrete event that this is a > response to, if that was the question, but I think you know that the IAB > has been discussing this for a while already. > I started my first reply in this thread by saying "This roughly makes sense to me ...", but since Mirja replied, I should probably have said why. I think these groups really are different - to mention one type of difference, the programs were originally set up to involve more people than just the current IAB (which was the way the IAB discharged its chartered responsibilities in 2010, when I joined), and one of the things I THINK I'm seeing is that the technical programs seem to be continuing that movement, to the point of open membership without approval by IAB vote, while at least some of the Administrative/Oversight Groups/Programs appropriately have closed membership (I'm thinking of the Liaison Oversight program and its predecessor programs during the TMPLS/MPLS-TP wars, or the IANA program during the spinoff of IANA from US DoC contracting). I don't think that's the only difference, but I don't know what current IAB thinking is about other differences. So, I was guessing that the IAB was thinking of distinctions like that, which I think are appropriate, between two kinds of programs, so that each kind of program better understands its expectations. I hope that's helpful (but Do The Right Thing, of course!). Best, Spencer --000000000000b40e4205b3eef7eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW,=C2=A0

On Thu, Nov 12, 2020 at 2:29 P= M Mirja Kuehlewind <ietf@kuehlewi= nd.net> wrote:
Hi Melinda,

I should probably have said that there is a description on the IAB webpage = about programs (https://www.iab.org/activities/programs/= ) which however is rather out-dated compared to what we do in programs thes= e days. So the goal is more transparency and openness in the program itself= but also in the way we maintain them. There has been no concrete event tha= t this is a response to, if that was the question, but I think you know tha= t the IAB has been discussing this for a while already.

I started my first reply in this thread by saying "Th= is roughly makes sense to me ...", but=C2=A0since Mirja replied, I sho= uld probably have said why.

I think these groups r= eally are different - to mention one type of difference, the programs were = originally set up to involve more people than just the current IAB (which w= as the way the IAB discharged its chartered responsibilities in 2010, when = I joined), and one of the things I THINK I'm seeing is that the technic= al programs seem to be continuing that movement, to the point of open membe= rship without approval by IAB vote, while at least some of the Administrati= ve/Oversight Groups/Programs appropriately have closed membership (I'm = thinking of the Liaison Oversight program and its predecessor programs duri= ng the TMPLS/MPLS-TP wars, or the IANA program during the spinoff of IANA f= rom US DoC contracting).=C2=A0

I don't think t= hat's the only difference, but I don't know what current IAB thinki= ng is about other differences.=C2=A0

So, I was gue= ssing that the IAB was thinking of distinctions like that, which I think ar= e appropriate, between two kinds of programs, so that each kind of program = better understands its expectations.

I hope that&#= 39;s helpful (but Do The Right Thing, of course!).

Best,

Spencer
--000000000000b40e4205b3eef7eb-- From nobody Thu Nov 12 13:02: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 15C1D3A08BD for ; Thu, 12 Nov 2020 13:02: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXS6pZ3suHEn for ; Thu, 12 Nov 2020 13:02:33 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 E3AA83A0879 for ; Thu, 12 Nov 2020 13:02:33 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id a18so5691565pfl.3 for ; Thu, 12 Nov 2020 13:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bCk/jlEzLjfQE+etR26zO4+RfwKcdsfJtb5IIv8ntmo=; b=kYXgd10WIUhspFaxJ0iWbmdt56ciymj4s/9xBbzTuP8D2g7JTuO+ncu2omh1l/PusI TBVHoPZyGU35Zvp8MGSpjZaYPqTVbSJF7abIpQNxPU92TcQEmXfUSp8s/ZchkzXEP+U4 5YVVApz4oSoTONVPrD+V7h4vMIyjQxXX9v2UWMnORrPO0ic2txd51fWOGqQyvGQoFeD3 JsPGrTM+ZLhinm85D9/poC99h/ZOu9gRWe6TEfSf2v0sb6y/tvsOXjfvYQDvPhM507qE avCI+a6NgFHrnigq26+GBMt25Sp4hxE2aAzpFv78hBgmKhIhGwNnDds5LiwaPxePj085 TItw== 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=bCk/jlEzLjfQE+etR26zO4+RfwKcdsfJtb5IIv8ntmo=; b=Sj6Fr2qlFj4S3+nwW4QNBD/lLRsYtUo6vRbMrExW4W22Q+QpbCFD9k+g010tKhbgMl +X9IRhahVCx3sWGNxpB6dawkqzaC24ML2sNrxnHA0+yRTkNC7APtFjTH1bhz/4gBVGt8 Z8ekco6LUwwW1ZDPyRz5p29Ae0PyN9GJa2JhBb311gkUbOR0biGaMiArrAFiwoxkU6BE DhsqZg4jm5RJGtj79D3ug3r6FAOaEXelMPERUK7si4ab/2AGvdJeiUKXYSY1lBXttLtF GEt2qGdoZGz2Tcba1jkC0rQyaSExN0m864YYUZ5j+wkfmobbcczEURjXwJ7+BUFaAJfn d2zg== X-Gm-Message-State: AOAM531YzWjTer+76ZmAH1N7FpzEPZg18d0WZehTC+LqsfnTWP7ldfBl nFvXPkgbk1D0QsZRFumDzbv3y/2YtDi1 X-Google-Smtp-Source: ABdhPJxQeR1VrRoOsuIHBA+J7UuzSOmHiPqmMiYwtuhukZijQBG0Wus6T6qHbvkfnB7SJrO3EbwUSw== X-Received: by 2002:a17:90a:a505:: with SMTP id a5mr1076517pjq.76.1605214952945; Thu, 12 Nov 2020 13:02:32 -0800 (PST) Received: from aspen.local (63-140-65-5.dynamic.lte.acsalaska.net. [63.140.65.5]) by smtp.gmail.com with ESMTPSA id gc17sm7687892pjb.47.2020.11.12.13.02.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Nov 2020 13:02:32 -0800 (PST) To: Spencer Dawkins at IETF , Mirja Kuehlewind Cc: architecture-discuss@ietf.org References: <3036D6C9-A1F4-4035-B039-0C9E75DE55C4@kuehlewind.net> <5a803090-c188-088c-507d-4ff1f2ab78f9@nomountain.net> <6F24DB57-639D-473A-8FB6-CA4776F38BE4@kuehlewind.net> From: Melinda Shore Message-ID: <4d3213d2-50f9-0788-1bda-09b11b46e495@nomountain.net> Date: Thu, 12 Nov 2020 12:02:29 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Call for Feedback on the new proposed structure for Technical Programs and Administrative Support Groups 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, 12 Nov 2020 21:02:35 -0000 On 11/12/20 11:43 AM, Spencer Dawkins at IETF wrote: > So, I was guessing that the IAB was thinking of distinctions like that, > which I think are appropriate, between two kinds of programs, so that > each kind of program better understands its expectations. I think the only place I saw any confusion about that during my tenure was around RFC Editor oversight/what-have-you, including but not limited to the RSOC. I'm not really seeing a problem here that needs solving. I do think that this discussion will inevitably lead to a discussion of the function and value of the IAB, which I do think might be worth having if it were possible to have that discussion in a civil manner. So, I think the Law of Unintended Consequences is going to dominate here and given the lack of an actual problem (I could be convinced otherwise but so far there's no problem in evidence) I'm not clear on the value of this exercise. Melinda -- Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis From nobody Thu Nov 12 19:00: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 684F13A13BD for ; Thu, 12 Nov 2020 19:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 cidk4YxDggkz for ; Thu, 12 Nov 2020 19:00:18 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59933A13B9 for ; Thu, 12 Nov 2020 19:00:17 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id j205so11692217lfj.6 for ; Thu, 12 Nov 2020 19:00:17 -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=bhAucbgI6uToxc/Mwc/6rJQQrhgCByfWXrKCWMfBBMk=; b=KPDI9uugoPeB4G+927vgcvxENhfpwm7FkRViqBGN1acOPhc+whw5uLK1dwMA4JawzP D8zJDmVHnbTaFe7/9PCcogHqobHb19wQIb8hjqUww41n8nttDeWo7yvJetCW8XJmzdbl UWFaRcD3RMGIxQFS1JWsht+/xz16jdwNkGR7G0mb6ZNVlbJ8kXqA0OQPRLNeVnzGSaKH d58eP1I4rhjfTHKYKrUme6x1+bTxpzWHFxkeL1ERrvJnIvAUUM0h8prCpB9C9fZDOhn0 6ppTTbuLng/gkm+h70RSu+uBqzZIJfJE/Wch2NE2QiSkhk1cqsXOYwK2Mpa22WQUc7Ug AHjA== 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=bhAucbgI6uToxc/Mwc/6rJQQrhgCByfWXrKCWMfBBMk=; b=hy6UYHe6rdS57XDmP2qVz5eyXGeWW0Eko+C0EhtqoMTasxBtD0BHiG8FgWS4l0Gr7w 2unPYK9dw1rZC4o5Am8P1jEZm0QjeTYFx2PGuFNoksB1T96Tvw0XzOYw/mDZoS6Q9m0P LtD23A4N96NTYFEKeADQIOy88hpQaUoscUuVL/AthZWT3yTCukB6KEfoesznMtzwPE6E AXXvcblPCpQX0+lCdd+ztySNoz2D5e5ZRXx1XcCCGLWHDQNPEIY5k6jExtGmEsD4eok3 cgzKftYa0fUJEiiIhijxvzqlFl+3ZYgPaRI9UwNlGmrRS+pLrBVjN1+CvZysixpj2AOq OZ+g== X-Gm-Message-State: AOAM532K7UNUE/llXi5A5EZf3ZYnRdz5/L2u0pHnLAJNk4b8Wjsau8dC 3Lb7+eu7vqRg6UQa334ka/mwg6J3wUKLtRadbUdnaQdt/ScsdQ== X-Google-Smtp-Source: ABdhPJyrRjT5eC3kO8HtsiI5oF4oNjm4F/A93YRfJLxiUXqD0ivVKP1OFrfDhMNGLVPeJbYA1PSk5EZPHa3IGWG8OIM= X-Received: by 2002:a19:4b0a:: with SMTP id y10mr11334lfa.570.1605236415346; Thu, 12 Nov 2020 19:00:15 -0800 (PST) MIME-Version: 1.0 From: Watson Ladd Date: Thu, 12 Nov 2020 19:00:04 -0800 Message-ID: To: architecture-discuss@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [arch-d] Comments on draft-lazanski-consolidation 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, 13 Nov 2020 03:00:19 -0000 Dear all, As someone who works on a team that's implemented all three of the protocols explicitly listed, it's a bit awkward for me to comment on the draft. But comment I will. The brief summary is that I think this draft suffers from trying to do too much, and if it was split up into section 5 and the rest it would be much more convincing and productive. Let me note that aws-us-east-1 having a bad day shouldn't be a news item. That alone is evidence that there is consolidation in the provision and location of computer services. But that doesn't really have a lot to do with protocol changes, and there aren't many examples of protocols changing in response to consolidation in the draft. I'm not sure what to make of section 4.2. It discusses the end to end principle, then says the availability of storage and computation changes that. NFS has existed for a long time, that doesn't mean the Internet provides storage. It means servers on the Internet provide storage. ISPs have always consolidated traffic, at least at the metropolitan level. They bring it to IXs or their transit links. 5G isn't changing that. The end to end principle is a principle of network design, and it isn't the only way to design networks: circuit switching and store-and-forward networks didn't do it, in part due to technical limitations. What is the edge to edge principle that this draft refers to? There have always been computers on the Internet, providing services to people. Anyone who has ssh'd into a cluster to run their codes is using data processing over the Internet. That these services might be anycasted or spread over multiple sites is not new. It doesn't make the network intelligent in the way the end-to-end principle argues against. All of this change doesn't involve new protocols. And then the draft discusses ECH, DoH, Privacy Pass as protocols that could lead to further consolidation. DoH has been discussed considerably in a variety of fora: I'll simply note that you can pick your resolver with DNS over UDP as well, and it's not really a protocol level issue how it was deployed, which the draft acknowledges. "Centralized" resolvers like 8.8.8.8 existed before DoH. ECH is I think probably the draft's strongest argument. Any sort of anonymity service benefits from having more usage, so them that has, gets. This is why e.g. Tor is prefered over less popular solutions. It's worth considering these incentives but I think that there is, and always has been, a variety of shared hosting options. There are some very real technical difficulties here, and I think all of us would welcome well thought out proposals. But doing nothing about SNI leakage is not an option. Privacy pass I think has been misinterpreted in this draft.. The multiple server case is really not central, it's a possible deployment model. The deployment that currently exists and many of the ideas that have been tossed around are of the single server model: the verifier only trusts a single server to hand out the token that is then used, akin to the usher taking a ticket at a movie theater. Different deployments use different servers, and there isn't a privacy issue. The draft is not saying there should be four servers worldwide. In conclusion I think this draft needs to be split up and each part further developed and clarified to be a good basis for further discussion. Sincerely, Watson -- Astra mortemque praestare gradatim From nobody Thu Nov 12 21:15: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 6D51D3A13F8 for ; Thu, 12 Nov 2020 21:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URI_DOTEDU=1.964] 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 eurVRtX6zDLI for ; Thu, 12 Nov 2020 21:15:17 -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 D55F53A13D0 for ; Thu, 12 Nov 2020 21:15:16 -0800 (PST) Received: from xse206.mail2web.com ([66.113.196.206] helo=xse.mail2web.com) by mx169.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kdRQK-000sRo-Pn for architecture-discuss@ietf.org; Fri, 13 Nov 2020 06:15:12 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4CXRVQ5kY1zBs8 for ; Thu, 12 Nov 2020 21:14:54 -0800 (PST) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kdRQE-0005Tn-MW for architecture-discuss@ietf.org; Thu, 12 Nov 2020 21:14:54 -0800 Received: (qmail 721 invoked from network); 13 Nov 2020 05:22:09 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.90]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Nov 2020 05:22:09 -0000 To: Watson Ladd , architecture-discuss@ietf.org References: From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <2ac94238-6b6d-ed04-f4f0-b8dcea496288@huitema.net> Date: Thu, 12 Nov 2020 21:14:57 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.206 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.206/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.206/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0cThwnZT+ODcFyeCwCHoUjupSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX7TmcuUvjRN+0J6Ac4ZemBWVO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PutP0Dzal8myJ8vVhoWnSKP9Tn5/AwQYA8p32I/LmTkdq8pnvZ XWSe7jV34Pxn0vH1Lz/y+awqhw7CmTPsWtYsCV/oEQh3zFZ7AJOfdc5NLopVCPmS+MVojfDUugvn Zl+jhHQOLtWk4clq0P6Ltvr/5Zl+BJt+8hYKwgejR0Z9YPn97p3CKmEi95YYeXPNWMiahaC2TJpF rGrq1WX76kTmg5w7R2/M+XaT5BLifEp8KpWu41J1t4cteGI4vH6PuMQp0kaOEXLuWd+6zLg4wp8u XxPcpGyeyPXKNTABBN67jV7JvFCbAD7w3FUirQwmJIqD2OUMeHyTpNN0eXybX/w7/3ZCM0u5uBlK VwmNWN494pUPBFtmg5GCGtjOaQC74kK2uZ9agFNFUxUZLPnr1LybeLQspoubd/Ea7HJk6sEwzYfL KUAGCjo0ibbuluTUoptOJ3Sw6H7d4EM0mJJ2ptqe0QtIz5SxsZxNzFkRa796RwWszYy73JZxs5Uw vGYJEd5WiFqrwMYgR7iLksuXwgJRJAY7oJjCTpsxJStfPIpup0dQAlTt7ce/LtGxuyH9kwlU4PtO b0y7gJ0A+SI1rGECao0wRpEZY7BrMzhNrDLnNRY580lwoSlpP4rXG4nCbCD3f3rei+cQaPCcHayj qxy2IX6m+UeFXprlCOm3BAEbJtA3uj2mTuvyU6BMseLZnOTpY5D0qT1wFY5dqDK/GtcZtMH11BTI 0x9g8g/IuZDuW2ZWBb39uS1TjWG2Inx+Ts2QsCIA/8Q3oXmtPTqZ8ErqG2a6xhMTEe3k2wYzBgyi N4o4YSZ+zLr/zR15dKPvvN8D X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [arch-d] Comments on draft-lazanski-consolidation 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, 13 Nov 2020 05:15:18 -0000 On 11/12/2020 7:00 PM, Watson Ladd wrote: > ECH is I think probably the draft's strongest argument. Any sort of > anonymity service benefits from having more usage, so them that has, > gets. This is why e.g. Tor is prefered over less popular solutions. > It's worth considering these incentives but I think that there is, and > always has been, a variety of shared hosting options. There are some > very real technical difficulties here, and I think all of us would > welcome well thought out proposals. But doing nothing about SNI > leakage is not an option. Watson's point is confirmed by market analysis. There is significant competition in the CDN market -- the ascension of Fastly from 'small startup" to "significant player" shows that. In fact, there is also competition in the "cloud hosting" market -- AWS and Azure are big, but there is a variety of other players, from Google Cloud to IBM, Oracle, Linode, Digital Ocean and many others. I did an analysis of that here: https://huitema.wordpress.com/2020/08/09/can-internet-services-hide-in-cr= owds/, but there is better data available here: https://www3.cs.stonybrook.edu/~mikepo/papers/esni.asiaccs20.pdf. As for ECH, the analysis shows that most of these "top million" sites are running on dedicated IP addresses, even when serviced by VPNs. Yes, ECH requires "shared address" hosting to work, but no, there is no evidence that big services are leveraging shared address provisioning to grab market share. -- Christian Huitema From nobody Fri Nov 13 00:14: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 74DCB3A1629 for ; Fri, 13 Nov 2020 00:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.589 X-Spam-Level: X-Spam-Status: No, score=-9.589 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, T_SPF_TEMPERROR=0.01, 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 yKGpHzyfhqD1 for ; Fri, 13 Nov 2020 00:14:11 -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 317073A1607 for ; Fri, 13 Nov 2020 00:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13886; q=dns/txt; s=iport; t=1605255251; x=1606464851; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=HJgU9mlQcZjXwq/+hAoPP89WXY4yNggw2vjpKH//sdA=; b=F3owwuo5K0SsXBCfGucKYYOCboymBO3doC2icZv73YVCtdsCAf3cfjDB Ym06gB4qgEXmcGeWB/IQi65M2S6HH9SOKWY9/NfIjwhy8JGVFBQGioMH7 qYVgdJxZbFDBwYaYIv6GfWvE/wFvyA2Ei1IsgRSnrV81K2XEmKFDtbznX c=; X-IPAS-Result: =?us-ascii?q?A0ATBABlP65f/xbLJq1iHQEBAQEJARIBBQUBgg+DcwEyL?= =?us-ascii?q?oQ9iQWIHooWiX6GMYFoCwEBAQ0BAS8EAQGESgKCHCY4EwIDAQEBAwIDAQEBA?= =?us-ascii?q?QUBAQECAQYEcYVthXIBAQEBAgEjVgULCxgqAgIhNgYTFQWDDIJWAw4grxt2g?= =?us-ascii?q?TKFV4JRDYIkgTiNMSqCAIERJxyCTz6CG4FpEQcBAQqDLTOCLASQOQspBaZoV?= =?us-ascii?q?IJ3gxqPTYMbhRMDH6F5oT2PBINkAgQGBQIVgWsjgVczGggbFWUBgj4+EhkNV?= =?us-ascii?q?o1QjkNAAzA4AgYBCQEBAwmMAgEngh4BAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.77,475,1596499200"; d="scan'208,217"; a="31026263" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Nov 2020 08:14:07 +0000 Received: from ams3-vpn-dhcp5496.cisco.com (ams3-vpn-dhcp5496.cisco.com [10.61.85.119]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AD8E6Mu027268 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Nov 2020 08:14:06 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_64DF5B79-8A71-4F86-8B78-9B9C728323E7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 13 Nov 2020 09:14:04 +0100 In-Reply-To: Cc: architecture-discuss@ietf.org To: Watson Ladd References: X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.85.119, ams3-vpn-dhcp5496.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [arch-d] Comments on draft-lazanski-consolidation 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, 13 Nov 2020 08:14:20 -0000 --Apple-Mail=_64DF5B79-8A71-4F86-8B78-9B9C728323E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Watson, > On 13 Nov 2020, at 04:00, Watson Ladd wrote: >=20 > Dear all, >=20 > As someone who works on a team that's implemented all three of the > protocols explicitly listed, it's a bit awkward for me to comment on > the draft. But comment I will. >=20 > The brief summary is that I think this draft suffers from trying to do > too much, and if it was split up into section 5 and the rest it would > be much more convincing and productive. >=20 > Let me note that aws-us-east-1 having a bad day shouldn't be a news > item. That alone is evidence that there is consolidation in the > provision and location of computer services. Yes. > But that doesn't really > have a lot to do with protocol changes, and there aren't many examples > of protocols changing in response to consolidation in the draft. I might put this differently. There are natural tendencies to = consolidation in any market, regardless of protocols, simply because of = economies of scale. But our protocols support that economic structure, = and that is deeply ingrained in our culture, to the point where I often = quote Mike O=E2=80=99Dell, a former IETF area director and an Internet = pioneer: =E2=80=9CThe only real problem is scaling.=E2=80=9D Load = balancing is an absolute requirement for scale, and so SNI came to be. = So we addressed that to scale, and that enabled market consolidation, = because without it CDNs could not offer secure services. =20 The same design can be seen in our mail systems. The MX record provides = for all manner of scaling. And for consolidation. Gmail, the system = you use, could hardly function without it. The same with short-lived = TTLs. There are other examples to me that seem to me to have created = consolidation due to lack of scale. For instance, NAT and private = addressing limited services to be delivered from the home, and once in = place, SPs built entire business models around that assumption. Some of = this might change over time with IPv6, but the status quo provides for a = lot of inertia. Dynamic addresses build on this. Without DHCP, it would not be scalable = for SPs to rotate addresses, thereby eliminating unwanted service = offerings. And then there are services that spot that, and correct for = it. Whole markets built out around this need for scale that a protocol = delivered. In each of these cases, the market pressure was there for work, our = tradition and processes of rough consensus and running code enabled the = work, and people showed up with code. >=20 > not sure what to make of section 4.2. It discusses the end to end > principle, then says the availability of storage and computation > changes that. NFS has existed for a long time, that doesn't mean the > Internet provides storage. It means servers on the Internet provide > storage. ISPs have always consolidated traffic, at least at the > metropolitan level. They bring it to IXs or their transit links. 5G > isn't changing that. The end to end principle is a principle of > network design, and it isn't the only way to design networks: circuit > switching and store-and-forward networks didn't do it, in part due to > technical limitations. What is the edge to edge principle that this > draft refers to? >=20 > There have always been computers on the Internet, providing services > to people. Anyone who has ssh'd into a cluster to run their codes is > using data processing over the Internet. That these services might be > anycasted or spread over multiple sites is not new. It doesn't make > the network intelligent in the way the end-to-end principle argues > against. NFS being a massive pain to handle, with all sorts of history with poor = performance on WANs, kernel hangs, and all the PTSD that brought to = administrators. Probably we should leave that example on the cutting = room floor. =20 On the other hand, SSH is more interesting. SSH has no key management = system to speak of, which is why attacking key servers led to a = fundamental failure. This is particularly ironic, given how it was = billed initially as a web of trust. You see no formal consolidation = there, but nevertheless there was a fail. Conversely and perhaps worth = study, you don=E2=80=99t see quite that same sort of failure with X.509 = certs, even though there is consolidation in the browser market. There = are huge numbers of CAs in browser stores. What would happen if those = policies got too restrictive? What are the economic incentives in play? >=20 > All of this change doesn't involve new protocols. >=20 > And then the draft discusses ECH, DoH, Privacy Pass as protocols that > could lead to further consolidation. DoH has been discussed > considerably in a variety of fora: I'll simply note that you can pick > your resolver with DNS over UDP as well, and it's not really a > protocol level issue how it was deployed, which the draft > acknowledges. "Centralized" resolvers like 8.8.8.8 existed before DoH. Users choosing DNS servers is a rarity. The only real question is who = else chooses. Is it the service provider, the home router vendor, or = the browser? By creating DoH, browsers have challenged the other two. = We ought not deny that reality. However, I also don=E2=80=99t think we = should replay good/bad here. To me, the draft needs to also look at malware and how consolidation = helps/hurts. I think it=E2=80=99s also probably worth while to look at = the recent O365 downtime, how two-sided markets can hurt scale and = stability, what what standards=E2=80=99 role are to prevent that risk. Eliot= --Apple-Mail=_64DF5B79-8A71-4F86-8B78-9B9C728323E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Watson,


On 13 Nov 2020, at 04:00, Watson Ladd <watsonbladd@gmail.com> wrote:

Dear = all,

As someone who works on a team that's = implemented all three of the
protocols explicitly listed, = it's a bit awkward for me to comment on
the draft. But = comment I will.

The brief summary is that I = think this draft suffers from trying to do
too much, and = if it was split up into section 5 and the rest it would
be = much more convincing and productive.

Let me = note that aws-us-east-1 having a bad day shouldn't be a news
item. That alone is evidence that there is consolidation in = the
provision and location of computer services. =

Yes.

But that doesn't really
have a lot to do with = protocol changes, and there aren't many examples
of = protocols changing in response to consolidation in the draft.

I = might put this differently.  There are natural tendencies to = consolidation in any market, regardless of = protocols, simply because of economies of scale.  But our protocols = support that economic structure, and that is deeply ingrained in our = culture, to the point where I often quote Mike O=E2=80=99Dell, a former = IETF area director and an Internet pioneer: =E2=80=9CThe only real = problem is scaling.=E2=80=9D  Load balancing is an absolute = requirement for scale, and so SNI came to be.  So we addressed that = to scale, and that enabled market consolidation, because without it CDNs = could not offer secure services.  

The same design can be seen in our mail systems. =  The MX record provides for all manner of scaling.  And for = consolidation.  Gmail, the system you use, could hardly function = without it.  The same with short-lived TTLs.

There are other examples to me that seem to me to = have created consolidation due to lack of scale. For instance, NAT and = private addressing limited services to be delivered from the home, and = once in place, SPs built entire business models around that assumption. =  Some of this might change over time with IPv6, but the status quo = provides for a lot of inertia.

Dynamic= addresses build on this.  Without DHCP, it would not be scalable = for SPs to rotate addresses, thereby eliminating unwanted service = offerings.  And then there are services that spot that, and correct = for it.  Whole markets built out around this need for scale that a = protocol delivered.

In each of these = cases, the market pressure was there for work, our tradition and = processes of rough consensus and running code enabled the work, and = people showed up with code.


 not sure what to make of section 4.2. It discusses the = end to end
principle, then says the availability of = storage and computation
changes that. NFS has existed for = a long time, that doesn't mean the
Internet provides = storage. It means servers on the Internet provide
storage. = ISPs have always consolidated traffic, at least at the
metropolitan level. They bring it to IXs or their transit = links. 5G
isn't changing that. The end to end principle is = a principle of
network design, and it isn't the only way = to design networks: circuit
switching and = store-and-forward networks didn't do it, in part due to
technical limitations. What is the edge to edge principle = that this
draft refers to?

There have always been computers on the Internet, providing = services
to people. Anyone who has ssh'd into a cluster to = run their codes is
using data processing over the = Internet. That these services might be
anycasted or spread = over multiple sites is not new. It doesn't make
the = network intelligent in the way the end-to-end principle argues
against.

NFS being a massive pain to handle, with all sorts of = history with poor performance on WANs, kernel hangs, and all the PTSD = that brought to administrators.  Probably we should leave that = example on the cutting room floor.  

On the other hand, SSH is more interesting. =  SSH has no key management system to speak of, which is why = attacking key servers led to a fundamental failure.  This is = particularly ironic, given how it was billed initially as a web of = trust.  You see no formal consolidation there, but nevertheless = there was a fail.  Conversely and perhaps worth study, you don=E2=80=99t see quite that same sort of failure = with X.509 certs, even though there is consolidation in the browser market.  There = are huge numbers of CAs in browser stores.  What would happen if = those policies got too restrictive?  What are the economic = incentives in play?


All of this = change doesn't involve new protocols.

And = then the draft discusses ECH, DoH, Privacy Pass as protocols that
could lead to further consolidation. DoH has been = discussed
considerably in a variety of fora: I'll simply = note that you can pick
your resolver with DNS over UDP as = well, and it's not really a
protocol level issue how it = was deployed, which the draft
acknowledges. "Centralized" = resolvers like 8.8.8.8 existed before DoH.

Users = choosing DNS servers is a rarity.  The only real question is who = else chooses.  Is it the service provider, the home router vendor, = or the browser?  By creating DoH, browsers have challenged the = other two.  We ought not deny that reality.  However, I also = don=E2=80=99t think we should replay good/bad here.

To me, the draft needs to also look at malware and = how consolidation helps/hurts.  I think it=E2=80=99s also probably = worth while to look at the recent O365 downtime, how two-sided markets = can hurt scale and stability, what what standards=E2=80=99 role are to = prevent that risk.

Eliot
= --Apple-Mail=_64DF5B79-8A71-4F86-8B78-9B9C728323E7-- From nobody Sun Nov 15 06:13:40 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 3BA8D3A12BE; Sun, 15 Nov 2020 06:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.276 X-Spam-Level: X-Spam-Status: No, score=0.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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 b-g6K-ZpQwcv; Sun, 15 Nov 2020 06:13:30 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id D45CF3A12BB; Sun, 15 Nov 2020 06:13:21 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.132.182]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 0AFED866024917 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2020 06:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1605449600; x=1605536000; i=@elandsys.com; bh=Dh6YOFBlhY0/dUZhf9J7sU8g5n1UpkEyenZVkbRk4Jk=; h=Date:To:From:Subject:In-Reply-To:References; b=xwqm1Sax76Nvoh7lIwJ7/+HUmXP+aG51J+3tAXQhT30ERWtvyTLcXeELluYh4WVMD +NHbfn4FC/yeZ08D3w73Y/0mr9rNW+Oj7/p+ovPR1EimPn/DZlW0pj0eZKHtmPF4fT 9N4SPJyhd3ff4sdE8tSiPG0oHjV6vh3FCr2xJDCQ= Message-Id: <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 15 Nov 2020 06:12:05 -0800 To: IAB Chair , architecture-discuss@iab.org From: S Moonesamy In-Reply-To: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@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] IAB report to the community for IETF-109 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, 15 Nov 2020 14:13:38 -0000 Dear Internet Architecture Board, At 10:34 AM 13-11-2020, IAB Chair wrote: >IAB Programs >=97=97 >=94 >The IAB has been working on refactoring its=20 >programs. In analysing the current IAB programs,=20 >the IAB identified two kinds of programs which=20 >are quite different in their needs and goals.=20 >Therefore, the new structure proposes to=20 >separate today's IAB programs into Technical=20 >Programs and Administrative Support Groups. The=20 >aim of this effort is to increase transparency,=20 >visibility, and openness of the architectural=20 >work done by the IAB. A request for feedback=20 >about this reorganization has been sent to the=20 >architecture-discuss@iab.org list, see The report for the announcement is for July. Is this a mistake? The Administrative Support Group is akin to a=20 group of 10 persons providing assistance to a=20 committee comprising the 13 persons. That is=20 different to the (IETF) directorates. Using the=20 IANA as an example, and based on what was=20 reported, there wasn't anything significant from=20 March to July. I don't remember seeing any=20 discussion of an appointment this year. What=20 does the IAB require assistance with? It is commendable that IAB/IAB programs might=20 wish to fix dysfunctions within areas of IETF=20 activity by doing the work. However, the role of=20 the "Architecture" in "IAB" is for long range=20 planning and coordination. The intent of Section=20 2.1 (RFC2850) is that the IAB is not the group=20 responsible for doing the actual work or else=20 that would not be labelled as "oversight". The concept of "program" creates opaque=20 accountability. Has the IAB considered that? I did not find anything in the report pertaining=20 to the IAB representing the interests of the=20 IETF. Is there an explanation for that omission? Regards, S. Moonesamy=20 From nobody Sun Nov 15 12:30: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 7563C3A0A87; Sun, 15 Nov 2020 12:30: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, SPF_HELO_NONE=0.001, SPF_NONE=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 d_X9gAxFUH1d; Sun, 15 Nov 2020 12:29:59 -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 B58203A0AB1; Sun, 15 Nov 2020 12:29:58 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1keOeq-000Mjg-KO; Sun, 15 Nov 2020 15:29:56 -0500 Date: Sun, 15 Nov 2020 15:29:50 -0500 From: John C Klensin To: S Moonesamy , IAB Chair , architecture-discuss@iab.org Message-ID: <891AEA3010444F9099444E76@PSB> In-Reply-To: <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.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: [arch-d] Program issues (was: Re: IAB report to the community for IETF-109) 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, 15 Nov 2020 20:30:00 -0000 Hi. I trust you figured out by now that the notice of the report contained the wrong link, presumably through the use of a template that was not updated. These things happen although why no one on the IAB spotted it might be an interesting question. The correct link, posted by Ole a couple of days ago, is https://www.ietf.org/proceedings/109/slides/slides-109-ietf-sessa-iab-report-to-the-community-for-ietf-109-00 However, one additional comment, prompted by your note, below... --On Sunday, November 15, 2020 06:12 -0800 S Moonesamy wrote: > The concept of "program" creates opaque accountability. Has > the IAB considered that? I have the dubious distinction of having written the first proposal for what evolved into the Program model. That proposal was far more radical than there was any chance of the community accepting and probably just a bad idea, but both it, and the version the IAB adopted and put into use around 2011, were intended to respond to one key problem. The problem was that, as the issues facing the Internet became more diverse and many of the participants in the IETF became more specialized in their skills and interests, the IAB could decide some effort was important and start work on it but then, as membership rotated, discover that it no longer had the expertise to effectively pursue that topic. That had happened in the past; it was not just a hypothetical problem. Asking the Nomcom to select people for expertise on one particular subject didn't work well either -- there were a few cases in which someone was selected on that basis who didn't want, or wasn't able, to contribute to the IAB's other work. So the idea was that, if the IAB felt that some topic was important to pursue but didn't have the expertise to do so internally, it could find relevant (and expert) people in the community, pass the responsibility on to them, treat them as if they were (non-voting) part of the IAB when that was important, and arrange for reporting as needed. It was not a requirement that the IAB have more involvement than general oversight; if several IAB members were actively interested in the topic and considered themselves either expert or willing to learn, there was no real need for a Program (even if the model might prove useful organizationally). By contrast, if IAB members became part of a particular Program, the assumption was that they would have no status except based on their expertise, i.e., that IAB members would be no "more equal" than anyone else. Finally, because the idea was shaped around Programs doing technical/ architectural work, accountability didn't change: the IAB should be judged on the basis of its technical and architectural work; especially good(or bad) work should be brought to the attention of the Nomcom; and the ultimate evaluation of quality would be adoption of ideas and topics by the IETF or the broader community. Just as with workshops, a report that was generally ignored and had no impact should be taken as reflecting badly on the whole IAB with the Nomcom having the unenviable job of figuring out who to blame. Implicitly, if a Program failed, the necessary assumption would be that either the IAB had not found the right people or had not defined the topic appropriately. In either case, I think there was an assumption that the community was owed a more detailed explanation than "shutting that one down" [1]. Because the RSOC had (or was perceived as having) administrative and management responsibilities rather than technical ones, it was never a good match for the Program model (at least as originally conceived). The accountability problems there were, IMO, just one issue (or symptom) of the mismatch. After almost ten years, the Program model has evolved significantly from the original conception. If that evolution has taken us to the point where accountability is a large issue --or to where they Program needs "refactoring"-- I wish the IAB would address the question of whether, while it seemed like a good idea at the time, it just didn't work out and the whole idea should be dropped rather than assuming that surrounding it with more process and rules would improve things. john [1] Same observation about workshops that never lead to reports, even if the report is only an explanation of why no conclusion or recommendations are possible. From nobody Sun Nov 15 13:10: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 887BE3A0D81; Sun, 15 Nov 2020 13:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 CYuo1PCg3axI; Sun, 15 Nov 2020 13:10:25 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 9A4343A0D7C; Sun, 15 Nov 2020 13:10:25 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id 34so7627607pgp.10; Sun, 15 Nov 2020 13:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+PbddO9TxUvks10jf/ckQOgUGVbrJNIv/ddqaSr0uqw=; b=i5R873QfXO+eyvk9pRcrSDDIJhOEdfDaHjsMbxxGZEO5MtthNKGp4B9Dv1K5rJFtto gd4++SF3LMzJa/b/6k2d94xIWTbh4RvjaVzdIIPogHKS/Trz/SOXAZcCOGL3L7fB5nMJ RpTHY2D8bMEfYr8hmycVeOoT7PwUv1szqLxrKOqXF/WWslb0I07qS+nO1c3XEmHBtZXO H8/kMNcAY/iRkhZo2M2A7+6ryCHzKGoUP/zCF+FBFpdH0+qUpwdVtFep4XhO2AZgx9Zo G1Dp0dL75+S7rJqT4vf3BfSzKgXUkLwXMDNDlQqCimmQL/BfjSroF+heoUzkGBFKcmy3 r7aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+PbddO9TxUvks10jf/ckQOgUGVbrJNIv/ddqaSr0uqw=; b=PCD4j24rEepewd3a1HCzh0EwQ91Tf+olDE/TyJGrPwoDf+1X6APVX05XfrHDOiH9X/ 6i0KkXaah2HDBBDnH6Pz5BbE393wAe9HPZXUQp9keGSOJjG2NIvNteL4W+3rshnCRNVG fVZZKLw1WDRw89Xpefo6HdmVlSeg0eovjkOJoFQ+TRwR56vJa9kG5aaVG6yiuYI4NCrs T/HpZwG+fR70vyXB8oyL6y+DGWG/B/+0tjjkayVS5Nq7L5Uwi8pc7qeyu7Osl7i5pZw7 eQy+MuAsImfkrlE9JxRR5HLWg8gMvc/edvGXQt4cI0MA46UshpE35IUl0qguqkcenNFC vQAQ== X-Gm-Message-State: AOAM530dMtMjfkv9uOJwSZ3Gf8CkUT8865XfZgP24hkaj1LV3R5H92j3 FL7o/K87DjtoefHesytkztcQ+QQ01Q2BjA== X-Google-Smtp-Source: ABdhPJxl+fWSTgKv7HLmSYwPVfq5wr3E1onPkz+p18yZqmz8AZhNCC/pO4cDMT0lvwJb7EpcC5cWHw== X-Received: by 2002:a63:3041:: with SMTP id w62mr10614813pgw.166.1605474623371; Sun, 15 Nov 2020 13:10:23 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id t128sm16200413pfb.111.2020.11.15.13.10.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2020 13:10:22 -0800 (PST) To: John C Klensin , S Moonesamy , IAB Chair , architecture-discuss@iab.org References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> From: Brian E Carpenter Message-ID: <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com> Date: Mon, 16 Nov 2020 10:10: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: <891AEA3010444F9099444E76@PSB> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Program issues 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, 15 Nov 2020 21:10:28 -0000 fwiw, I think that the separation of technical programs from administrative tasks is a great step forward, and overcomes the slight discomfort I've always had about the IAB program concept. I think we can regard an IAB technical program as rather like an IAB workshop that goes on for several years, with the same properties: it's invitational, it has no authority, and it is supposed to report back to the community with some interesting information and suggestions. As John says, it also has the virtue of surviving changes in IAB membership. I don't think it changes accountability at all. The IAB remains accountable for its formal decisions, statements and publications. As for admin tasks, I would always prefer that the IAB minimises that part of its efforts. Regards Brian Carpenter On 16-Nov-20 09:29, John C Klensin wrote: > Hi. > I trust you figured out by now that the notice of the report > contained the wrong link, presumably through the use of a > template that was not updated. These things happen although why > no one on the IAB spotted it might be an interesting question. > The correct link, posted by Ole a couple of days ago, is > > https://www.ietf.org/proceedings/109/slides/slides-109-ietf-sessa-iab-report-to-the-community-for-ietf-109-00 > > However, one additional comment, prompted by your note, below... > > --On Sunday, November 15, 2020 06:12 -0800 S Moonesamy > wrote: > >> The concept of "program" creates opaque accountability. Has >> the IAB considered that? > > I have the dubious distinction of having written the first > proposal for what evolved into the Program model. That proposal > was far more radical than there was any chance of the community > accepting and probably just a bad idea, but both it, and the > version the IAB adopted and put into use around 2011, were > intended to respond to one key problem. The problem was that, > as the issues facing the Internet became more diverse and many > of the participants in the IETF became more specialized in their > skills and interests, the IAB could decide some effort was > important and start work on it but then, as membership rotated, > discover that it no longer had the expertise to effectively > pursue that topic. That had happened in the past; it was not > just a hypothetical problem. Asking the Nomcom to select people > for expertise on one particular subject didn't work well either > -- there were a few cases in which someone was selected on that > basis who didn't want, or wasn't able, to contribute to the > IAB's other work. > > So the idea was that, if the IAB felt that some topic was > important to pursue but didn't have the expertise to do so > internally, it could find relevant (and expert) people in the > community, pass the responsibility on to them, treat them as if > they were (non-voting) part of the IAB when that was important, > and arrange for reporting as needed. It was not a requirement > that the IAB have more involvement than general oversight; if > several IAB members were actively interested in the topic and > considered themselves either expert or willing to learn, there > was no real need for a Program (even if the model might prove > useful organizationally). By contrast, if IAB members became > part of a particular Program, the assumption was that they would > have no status except based on their expertise, i.e., that IAB > members would be no "more equal" than anyone else. > > Finally, because the idea was shaped around Programs doing > technical/ architectural work, accountability didn't change: the > IAB should be judged on the basis of its technical and > architectural work; especially good(or bad) work should be > brought to the attention of the Nomcom; and the ultimate > evaluation of quality would be adoption of ideas and topics by > the IETF or the broader community. Just as with workshops, a > report that was generally ignored and had no impact should be > taken as reflecting badly on the whole IAB with the Nomcom > having the unenviable job of figuring out who to blame. > Implicitly, if a Program failed, the necessary assumption would > be that either the IAB had not found the right people or had not > defined the topic appropriately. In either case, I think there > was an assumption that the community was owed a more detailed > explanation than "shutting that one down" [1]. > > Because the RSOC had (or was perceived as having) administrative > and management responsibilities rather than technical ones, it > was never a good match for the Program model (at least as > originally conceived). The accountability problems there were, > IMO, just one issue (or symptom) of the mismatch. > > After almost ten years, the Program model has evolved > significantly from the original conception. If that evolution > has taken us to the point where accountability is a large issue > --or to where they Program needs "refactoring"-- I wish the IAB > would address the question of whether, while it seemed like a > good idea at the time, it just didn't work out and the whole > idea should be dropped rather than assuming that surrounding it > with more process and rules would improve things. > > john > > [1] Same observation about workshops that never lead to reports, > even if the report is only an explanation of why no conclusion > or recommendations are possible. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Sun Nov 15 14: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 0C1AB3A0E96; Sun, 15 Nov 2020 14:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ZsKoyO2-HtUW; Sun, 15 Nov 2020 14:06:10 -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 20D033A0E94; Sun, 15 Nov 2020 14:06:10 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id i17so16840000ljd.3; Sun, 15 Nov 2020 14:06:09 -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=H5Z7p8RbBSv6vN/AMJ5MIwlEwlpuyTK/721W6/3wMew=; b=VRNqyidJbY0q5dYaPcRgqPGeCWwN8aC39nCGFYPgu8QA2hEjOJMyO326OKjhhjxfe4 TT8TqiiP8Z83XzeytfsuLAiMZYccGb+8XMhQIQ4Z3RygkJ4AmXdzjb5OTP1uMIp8ijPM 3Gk9OTzSQT1P+1fkWvW0dKqlykey2NESPbNIhqq1x0czaTd1ZhJ8MoClwYu1VMIpIVGj KaVs1UMYePSIEVniuSKAKf6kzJH6ZyE8pQ0HU6eKmoUR5zPXmU42KpuFcfmGEPZsvgog D6+RTflNOqGmWsZgrJOKr+FIKc0Bbzkbi74VW0ztFMRhVzqxlhy/dnSruZIbqRNUEVBe N6Vw== 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=H5Z7p8RbBSv6vN/AMJ5MIwlEwlpuyTK/721W6/3wMew=; b=AA8p2VMQqWltP/5/1k+9wrnZq/qt4xFxqnXo2hPGxJjeQLt1eBEkP+zG3bNdYcs9iU G9FNt9PskIg434IoJ2cJGcRfcI6GU+7+klZiYO9zx62UEGHGyRoLRtSPlWUc4fQ73exH QAKPrMZsr6P+7M839b2JRtV+ZYWMlWXgHpkevuV6roayaXYV2T7+xG4z2Mvu5m25ZRkW FOcOsPN3Cvhi/HGEwJtjfnNlI8Tz2ucKabTSJN43DiUAQ2usm1QIlCuRFCmEFwm0BxwV Uki+W5Sr+KC+Yl1TuBnPUzEF4RZnELpJSNAqqaSwPNYkgCN9NRc3ZBVjXuYnuGjBXC3b M7nA== X-Gm-Message-State: AOAM530NmQx/+l+dSDfCcZQxqSwgkilgZYiUfVhcPVhPmruKsv1cYPPl k78GcKyL/cQ0whyoIwX6gmb8fZpBXlgslxf59GY= X-Google-Smtp-Source: ABdhPJzMX+SHKR+AdSle+Lv7VC7+IdHxLnQLhNqvsGKtq0N0VEx1xvc29b2jN/mFlwk5dat+b4MeHgpxdFF0bof9ngQ= X-Received: by 2002:a2e:b70d:: with SMTP id j13mr5395430ljo.240.1605477967904; Sun, 15 Nov 2020 14:06:07 -0800 (PST) MIME-Version: 1.0 References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com> In-Reply-To: <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com> From: Bernard Aboba Date: Sun, 15 Nov 2020 14:05:58 -0800 Message-ID: To: Brian E Carpenter Cc: John C Klensin , S Moonesamy , IAB Chair , architecture-discuss@iab.org Content-Type: multipart/alternative; boundary="000000000000f8c30305b42c77af" Archived-At: Subject: Re: [arch-d] Program issues 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, 15 Nov 2020 22:06:13 -0000 --000000000000f8c30305b42c77af Content-Type: text/plain; charset="UTF-8" Brian said: "As for admin tasks, I would always prefer that the IAB minimises that part of its efforts." [BA] In practice, the administrative programs have not worked well. The RSOC is perhaps the most prominent example, but by no means the only one. IMHO, the problem is not with the Program Model, but with the IAB itself. With technical programs, post-Kobe there are checks and balances, so that the IAB merely has the "power of the pulpit" - the ability to attempt to convince the IETF community to move in a particular direction. But with administrative programs, those checks and balances are often not present. This is because in some areas (such as RSOC and IANA), the IAB is to represent interests beyond those of the IETF. While that is good in theory, those non-IETF interests are not well defined, nor do they in practice have the ability to provide a check on IAB actions. Even if a way could be found to represent those interests within an IAB program (for example through appointment of non-IAB members), only IAB members have voting rights. Given these inherent problems, I would agree that the IAB needs to minimize that part of its efforts. The best way to ensure that this happens is for the IAB's administrative programs to be examined one by one, with an eye to removing them from the IAB's charter. On Sun, Nov 15, 2020 at 1:10 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > fwiw, I think that the separation of technical programs from > administrative tasks is a great step forward, and overcomes > the slight discomfort I've always had about the IAB program > concept. > > I think we can regard an IAB technical program as rather like > an IAB workshop that goes on for several years, with the same > properties: it's invitational, it has no authority, and it > is supposed to report back to the community with some > interesting information and suggestions. As John says, it > also has the virtue of surviving changes in IAB membership. > > I don't think it changes accountability at all. The IAB > remains accountable for its formal decisions, statements > and publications. > > As for admin tasks, I would always prefer that the IAB minimises > that part of its efforts. > > Regards > Brian Carpenter > > On 16-Nov-20 09:29, John C Klensin wrote: > > Hi. > > I trust you figured out by now that the notice of the report > > contained the wrong link, presumably through the use of a > > template that was not updated. These things happen although why > > no one on the IAB spotted it might be an interesting question. > > The correct link, posted by Ole a couple of days ago, is > > > > > https://www.ietf.org/proceedings/109/slides/slides-109-ietf-sessa-iab-report-to-the-community-for-ietf-109-00 > > > > However, one additional comment, prompted by your note, below... > > > > --On Sunday, November 15, 2020 06:12 -0800 S Moonesamy > > wrote: > > > >> The concept of "program" creates opaque accountability. Has > >> the IAB considered that? > > > > I have the dubious distinction of having written the first > > proposal for what evolved into the Program model. That proposal > > was far more radical than there was any chance of the community > > accepting and probably just a bad idea, but both it, and the > > version the IAB adopted and put into use around 2011, were > > intended to respond to one key problem. The problem was that, > > as the issues facing the Internet became more diverse and many > > of the participants in the IETF became more specialized in their > > skills and interests, the IAB could decide some effort was > > important and start work on it but then, as membership rotated, > > discover that it no longer had the expertise to effectively > > pursue that topic. That had happened in the past; it was not > > just a hypothetical problem. Asking the Nomcom to select people > > for expertise on one particular subject didn't work well either > > -- there were a few cases in which someone was selected on that > > basis who didn't want, or wasn't able, to contribute to the > > IAB's other work. > > > > So the idea was that, if the IAB felt that some topic was > > important to pursue but didn't have the expertise to do so > > internally, it could find relevant (and expert) people in the > > community, pass the responsibility on to them, treat them as if > > they were (non-voting) part of the IAB when that was important, > > and arrange for reporting as needed. It was not a requirement > > that the IAB have more involvement than general oversight; if > > several IAB members were actively interested in the topic and > > considered themselves either expert or willing to learn, there > > was no real need for a Program (even if the model might prove > > useful organizationally). By contrast, if IAB members became > > part of a particular Program, the assumption was that they would > > have no status except based on their expertise, i.e., that IAB > > members would be no "more equal" than anyone else. > > > > Finally, because the idea was shaped around Programs doing > > technical/ architectural work, accountability didn't change: the > > IAB should be judged on the basis of its technical and > > architectural work; especially good(or bad) work should be > > brought to the attention of the Nomcom; and the ultimate > > evaluation of quality would be adoption of ideas and topics by > > the IETF or the broader community. Just as with workshops, a > > report that was generally ignored and had no impact should be > > taken as reflecting badly on the whole IAB with the Nomcom > > having the unenviable job of figuring out who to blame. > > Implicitly, if a Program failed, the necessary assumption would > > be that either the IAB had not found the right people or had not > > defined the topic appropriately. In either case, I think there > > was an assumption that the community was owed a more detailed > > explanation than "shutting that one down" [1]. > > > > Because the RSOC had (or was perceived as having) administrative > > and management responsibilities rather than technical ones, it > > was never a good match for the Program model (at least as > > originally conceived). The accountability problems there were, > > IMO, just one issue (or symptom) of the mismatch. > > > > After almost ten years, the Program model has evolved > > significantly from the original conception. If that evolution > > has taken us to the point where accountability is a large issue > > --or to where they Program needs "refactoring"-- I wish the IAB > > would address the question of whether, while it seemed like a > > good idea at the time, it just didn't work out and the whole > > idea should be dropped rather than assuming that surrounding it > > with more process and rules would improve things. > > > > john > > > > [1] Same observation about workshops that never lead to reports, > > even if the report is only an explanation of why no conclusion > > or recommendations are possible. > > > > _______________________________________________ > > 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 > --000000000000f8c30305b42c77af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian said:=C2=A0

"As for admin ta= sks, I would always prefer that the IAB minimises that part of its efforts.= "

[BA] In practice, the administrative progra= ms have not worked well. The RSOC is perhaps the most prominent example, bu= t by no means the only one.

IMHO, the problem is n= ot with the Program Model, but with the IAB itself. With technical programs= , post-Kobe there are checks and balances, so that the IAB merely has the &= quot;power of the pulpit" - the ability to attempt to convince the IET= F community to move in a particular direction.

But= with administrative programs, those checks and balances are often not pres= ent.=C2=A0 This is because in some areas (such as RSOC and IANA), the IAB i= s to represent=C2=A0interests beyond those of the IETF.=C2=A0 While that is= good in theory, those non-IETF interests are not well defined, nor do they= in practice have the ability to provide a check on IAB actions. Even if a = way could be found to represent those interests within an IAB program (for = example through appointment of non-IAB members), only IAB members have voti= ng rights.=C2=A0

Given these inherent problems, I = would agree that the IAB needs to minimize that part of its efforts.=C2=A0 = The best way to ensure that this happens is for the IAB's administrativ= e programs to be examined one by one, with an eye to removing them from the= IAB's charter.

On Sun, Nov 15, 2020 at 1:10 PM Brian E Carpenter = <brian.e.carpenter@gmail.= com> wrote:
fwiw, I think that the separation of technical programs from
administrative tasks is a great step forward, and overcomes
the slight discomfort I've always had about the IAB program
concept.

I think we can regard an IAB technical program as rather like
an IAB workshop that goes on for several years, with the same
properties: it's invitational, it has no authority, and it
is supposed to report back to the community with some
interesting information and suggestions. As John says, it
also has the virtue of surviving changes in IAB membership.

I don't think it changes accountability at all. The IAB
remains accountable for its formal decisions, statements
and publications.

As for admin tasks, I would always prefer that the IAB minimises
that part of its efforts.

Regards
=C2=A0 =C2=A0Brian Carpenter

On 16-Nov-20 09:29, John C Klensin wrote:
> Hi.
> I trust you figured out by now that the notice of the report
> contained the wrong link, presumably through the use of a
> template that was not updated.=C2=A0 These things happen although why<= br> > no one on the IAB spotted it might be an interesting question.
> The correct link, posted by Ole a couple of days ago, is
>
> https://www.ietf.org/proceedings/109/slides/slides-109-ietf-s= essa-iab-report-to-the-community-for-ietf-109-00
>
> However, one additional comment, prompted by your note, below...
>
> --On Sunday, November 15, 2020 06:12 -0800 S Moonesamy
> <sm+iet= f@elandsys.com> wrote:
>
>> The concept of "program" creates opaque accountability.= =C2=A0 Has
>> the IAB considered that?
>
> I have the dubious distinction of having written the first
> proposal for what evolved into the Program model.=C2=A0 That proposal<= br> > was far more radical than there was any chance of the community
> accepting and probably just a bad idea, but both it, and the
> version the IAB adopted and put into use around 2011, were
> intended to respond to one key problem.=C2=A0 The problem was that, > as the issues facing the Internet became more diverse and many
> of the participants in the IETF became more specialized in their
> skills and interests, the IAB could decide some effort was
> important and start work on it but then, as membership rotated,
> discover that it no longer had the expertise to effectively
> pursue that topic.=C2=A0 That had happened in the past; it was not
> just a hypothetical problem.=C2=A0 Asking the Nomcom to select people<= br> > for expertise on one particular subject didn't work well either > -- there were a few cases in which someone was selected on that
> basis who didn't want, or wasn't able, to contribute to the > IAB's other work.
>
> So the idea was that, if the IAB felt that some topic was
> important to pursue but didn't have the expertise to do so
> internally, it could find relevant (and expert) people in the
> community, pass the responsibility on to them, treat them as if
> they were (non-voting) part of the IAB when that was important,
> and arrange for reporting as needed.=C2=A0 It was not a requirement > that the IAB have more involvement than general oversight; if
> several IAB members were actively interested in the topic and
> considered themselves either expert or willing to learn, there
> was no real need for a Program (even if the model might prove
> useful organizationally).=C2=A0 By contrast, if IAB members became
> part of a particular Program, the assumption was that they would
> have no status except based on their expertise, i.e., that IAB
> members would be no "more equal" than anyone else.
>
> Finally, because the idea was shaped around Programs doing
> technical/ architectural work, accountability didn't change: the > IAB should be judged on the basis of its technical and
> architectural work; especially good(or bad) work should be
> brought to the attention of the Nomcom; and the ultimate
> evaluation of quality would be adoption of ideas and topics by
> the IETF or the broader community.=C2=A0 =C2=A0Just as with workshops,= a
> report that was generally ignored and had no impact should be
> taken as reflecting badly on the whole IAB with the Nomcom
> having the unenviable job of figuring out who to blame.
> Implicitly, if a Program failed, the necessary assumption would
> be that either the IAB had not found the right people or had not
> defined the topic appropriately.=C2=A0 In either case, I think there > was an assumption that the community was owed a more detailed
> explanation than "shutting that one down" [1].
>
> Because the RSOC had (or was perceived as having) administrative
> and management responsibilities rather than technical ones, it
> was never a good match for the Program model (at least as
> originally conceived).=C2=A0 The accountability problems there were, > IMO, just one issue (or symptom) of the mismatch.
>
> After almost ten years, the Program model has evolved
> significantly from the original conception.=C2=A0 If that evolution > has taken us to the point where accountability is a large issue
> --or to where they Program needs "refactoring"-- I wish the = IAB
> would address the question of whether, while it seemed like a
> good idea at the time, it just didn't work out and the whole
> idea should be dropped rather than assuming that surrounding it
> with more process and rules would improve things.
>
>=C2=A0 =C2=A0 =C2=A0john
>
> [1] Same observation about workshops that never lead to reports,
> even if the report is only an explanation of why no conclusion
> or recommendations are possible.
>
> _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss
>

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000f8c30305b42c77af-- From nobody Sun Nov 15 14:30: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 A29153A0F0B; Sun, 15 Nov 2020 14:30:39 -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, 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 aTyMEnHPj9-w; Sun, 15 Nov 2020 14:30:38 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 01EA63A0F09; Sun, 15 Nov 2020 14:30:37 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.171.113]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 0AFMUL4X024973 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2020 14:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1605479434; x=1605565834; i=@elandsys.com; bh=zP48vYjjPfdrOKg+ptTCi8Z7W6LkiVWHeKia9JHtGSs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vVUdp+YDMm7vkPSRMT826x7hohD1NB8ykFj3GL5hAK2gwuKSgmJ1Y7AJds4mAjask zB4UFz4A7jU2jz2+48u1YjllR6UYERMIHPjkRutqtEcRa8kfA8ST2Ip5h+2E0RWKEy NTALQ5sAwPniykCWNh2Ias34x99WkMc4n6TAKd/0= Message-Id: <6.2.5.6.2.20201115134439.0aed3670@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 15 Nov 2020 14:29:10 -0800 To: John C Klensin , architecture-discuss@iab.org From: S Moonesamy Cc: IAB Chair , Brian E Carpenter , Bernard Aboba In-Reply-To: <891AEA3010444F9099444E76@PSB> References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Program issues (was: Re: IAB report to the community for IETF-109) 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, 15 Nov 2020 22:30:40 -0000 Hi John, At 12:29 PM 15-11-2020, John C Klensin wrote: >I trust you figured out by now that the notice of the report >contained the wrong link, presumably through the use of a >template that was not updated. These things happen although why >no one on the IAB spotted it might be an interesting question. Thanks for sharing the correct link. The two appointments which the IAB intends to make is actually for a Board of Trustees instead of a Board of Directors. >However, one additional comment, prompted by your note, below... Thanks for filling me in on the history. I interpreted "program" slightly differently. >After almost ten years, the Program model has evolved >significantly from the original conception. If that evolution >has taken us to the point where accountability is a large issue >--or to where they Program needs "refactoring"-- I wish the IAB >would address the question of whether, while it seemed like a >good idea at the time, it just didn't work out and the whole >idea should be dropped rather than assuming that surrounding it >with more process and rules would improve things. Let's assume that the Program model fulfilled its objective over a decade ago. It could do with some rethinking. I agree with Brian on minimizing admin tasks. It is, in my opinion, not unusual for some Programs to fail. It is useful to understand why instead of shutting them done without any explanation. As a response to Bernard's comment about the "power of the pulpit", I'll pick an idea from John, i.e. "the ultimate evaluation of quality would be adoption of ideas and topics by the IETF or the broader community. Representation of interests (re. Bernard's email) tends to be complex. I doubt that it would be doable through a Program. Regards, S. Moonesamy From nobody Sun Nov 15 14:36: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 E950A3A103A; Sun, 15 Nov 2020 14:36:32 -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=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 IvpIJxPvpIIS; Sun, 15 Nov 2020 14:36: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 11B9F3A0FEC; Sun, 15 Nov 2020 14:36:29 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1keQdG-000NkI-H7; Sun, 15 Nov 2020 17:36:26 -0500 Date: Sun, 15 Nov 2020 17:36:20 -0500 From: John C Klensin To: Brian E Carpenter , S Moonesamy , IAB Chair , architecture-discuss@iab.org Message-ID: <4122D6135972E5300169F327@PSB> In-Reply-To: <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com> References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> <0a73975a-eea8-a356-aec4-6fe04a4f3816@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] Program issues 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, 15 Nov 2020 22:36:40 -0000 Brian, Certainly if what the separation really means is to eliminate the bundling of [technical] Programs with administrative and oversight functions, I'd consider it a good idea... and much more consistent with what Olaf, myself, and the general consensus of the IAB a decade ago thought we were doing. My concern was that the IAB might be taking another step in the direction of substituting more internal structure, specific definitions, and categories for getting substantive work done (and, yes, for accountability). If this is really "hey, some of this stuff that we identified as "Programs" really doesn't match the original intent and is creating confusion, so we are going to stop calling them that", why doesn't the IAB just do it? To take the longest-lived one as an example, the IAB didn't need to consult the community or make a big deal out of starting to call its liaison oversight responsibilities (which existed long before programs existed) a "Program" and doesn't need to make a big deal out of ceasing to use that terminology. The problem there, as I see it, is that the IAB is feeling much less responsible and (coming back to Subramanian's question/point) accountable for liaison relationships than I believe was intended when RFC 2850 was written in 2000 (and indeed, although less specific, in RFCs 1358 and 1601 much earlier). If calling those liaison responsibilities a "Program" helped cause that change then, IMO, the terminology change was a bad idea because I think the IAB is responsible for consulting the community when it is going to drop a responsibility. But, again, the terminology isn't really the problem, the actions are. Granted that I'm getting a bit paranoid about such things but, when I read that proposal, I saw, not a simple adjustment of terminology but a further step in which the IAB becomes less a single (and jointly accountable) body and, instead, more like the IESG where different members are assigned primary responsibility for different topic areas and keep that responsibility for long periods of time. Unlike the IESG, where the necessity to have consensus about Last Calls and documents force some cross-checking of each other's work, that could easily turn the IAB into a collection of fiefdoms, a decision on which the community should clearly be consulted. And, while the above was written before Bernard's note arrived, I (perhaps obviously) agree with his analysis and the conclusion that it is probably time to start examining the IAB's administrative and oversight responsibilities to determine whether they are necessary at all. If they are necessary, whether the IAB is the right place to house them if they are and how they can be carried out in a way that is most effective and transparent and accountable to the community. john john --On Monday, November 16, 2020 10:10 +1300 Brian E Carpenter wrote: > fwiw, I think that the separation of technical programs from > administrative tasks is a great step forward, and overcomes > the slight discomfort I've always had about the IAB program > concept. > > I think we can regard an IAB technical program as rather like > an IAB workshop that goes on for several years, with the same > properties: it's invitational, it has no authority, and it > is supposed to report back to the community with some > interesting information and suggestions. As John says, it > also has the virtue of surviving changes in IAB membership. > > I don't think it changes accountability at all. The IAB > remains accountable for its formal decisions, statements > and publications. > > As for admin tasks, I would always prefer that the IAB > minimises that part of its efforts. > > Regards > Brian Carpenter > > On 16-Nov-20 09:29, John C Klensin wrote: >> Hi. >> I trust you figured out by now that the notice of the report >> contained the wrong link, presumably through the use of a >> template that was not updated. These things happen although >> why no one on the IAB spotted it might be an interesting >> question. The correct link, posted by Ole a couple of days >> ago, is >> >> https://www.ietf.org/proceedings/109/slides/slides-109-ietf-s >> essa-iab-report-to-the-community-for-ietf-109-00 >> >> However, one additional comment, prompted by your note, >> below... >> >> --On Sunday, November 15, 2020 06:12 -0800 S Moonesamy >> wrote: >> >>> The concept of "program" creates opaque accountability. Has >>> the IAB considered that? >> >> I have the dubious distinction of having written the first >> proposal for what evolved into the Program model. That >> proposal was far more radical than there was any chance of >> the community accepting and probably just a bad idea, but >> both it, and the version the IAB adopted and put into use >> around 2011, were intended to respond to one key problem. >> The problem was that, as the issues facing the Internet >> became more diverse and many of the participants in the IETF >> became more specialized in their skills and interests, the >> IAB could decide some effort was important and start work on >> it but then, as membership rotated, discover that it no >> longer had the expertise to effectively pursue that topic. >> That had happened in the past; it was not just a hypothetical >> problem. Asking the Nomcom to select people for expertise on >> one particular subject didn't work well either -- there were >> a few cases in which someone was selected on that basis who >> didn't want, or wasn't able, to contribute to the IAB's other >> work. >> >> So the idea was that, if the IAB felt that some topic was >> important to pursue but didn't have the expertise to do so >> internally, it could find relevant (and expert) people in the >> community, pass the responsibility on to them, treat them as >> if they were (non-voting) part of the IAB when that was >> important, and arrange for reporting as needed. It was not a >> requirement that the IAB have more involvement than general >> oversight; if several IAB members were actively interested in >> the topic and considered themselves either expert or willing >> to learn, there was no real need for a Program (even if the >> model might prove useful organizationally). By contrast, if >> IAB members became part of a particular Program, the >> assumption was that they would have no status except based on >> their expertise, i.e., that IAB members would be no "more >> equal" than anyone else. >> >> Finally, because the idea was shaped around Programs doing >> technical/ architectural work, accountability didn't change: >> the IAB should be judged on the basis of its technical and >> architectural work; especially good(or bad) work should be >> brought to the attention of the Nomcom; and the ultimate >> evaluation of quality would be adoption of ideas and topics by >> the IETF or the broader community. Just as with workshops, a >> report that was generally ignored and had no impact should be >> taken as reflecting badly on the whole IAB with the Nomcom >> having the unenviable job of figuring out who to blame. >> Implicitly, if a Program failed, the necessary assumption >> would be that either the IAB had not found the right people >> or had not defined the topic appropriately. In either case, >> I think there was an assumption that the community was owed a >> more detailed explanation than "shutting that one down" [1]. >> >> Because the RSOC had (or was perceived as having) >> administrative and management responsibilities rather than >> technical ones, it was never a good match for the Program >> model (at least as originally conceived). The accountability >> problems there were, IMO, just one issue (or symptom) of the >> mismatch. >> >> After almost ten years, the Program model has evolved >> significantly from the original conception. If that evolution >> has taken us to the point where accountability is a large >> issue --or to where they Program needs "refactoring"-- I wish >> the IAB would address the question of whether, while it >> seemed like a good idea at the time, it just didn't work out >> and the whole idea should be dropped rather than assuming >> that surrounding it with more process and rules would improve >> things. >> >> john >> >> [1] Same observation about workshops that never lead to >> reports, even if the report is only an explanation of why no >> conclusion or recommendations are possible. >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> From nobody Sun Nov 15 14:42: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 932483A0FB5; Sun, 15 Nov 2020 14:42:38 -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, NICE_REPLY_A=-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 (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 9xDDpTaWH20F; Sun, 15 Nov 2020 14:42:37 -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 68B823A0FB3; Sun, 15 Nov 2020 14:42:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4A2FCBE3E; Sun, 15 Nov 2020 22:42:34 +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 ttJ9MRZ44nTN; Sun, 15 Nov 2020 22:42:32 +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 78A22BE4C; Sun, 15 Nov 2020 22:42:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1605480152; bh=l71qEQRmbN7IYXn1uHjF1aCqSZrtZTfpLhnf2CpSMU4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Rx8BFWudIZV+qJg1MRbeIGYPlttIn5Gh4D3Brwqch7BkrYhRU87Q/r6P8cF38TqsL ZvafrwpaFP/KloMP9WA11eyFRlgF1zvSbZI6jLSkx33WvOUetLJdvfKHomTzgLGD2G StSHGJ3IeVYpPypy7WcrexuCg7wvINMev80wB/V4= To: John C Klensin , Brian E Carpenter , S Moonesamy , IAB Chair , architecture-discuss@iab.org References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com> <4122D6135972E5300169F327@PSB> From: Stephen Farrell Message-ID: <73a73ef6-f838-ba89-625e-4da48fa81553@cs.tcd.ie> Date: Sun, 15 Nov 2020 22:42:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: <4122D6135972E5300169F327@PSB> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8EGO61VY9gIZktCWX5Tna8EIc7zrQ671t" Archived-At: Subject: Re: [arch-d] Program issues 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, 15 Nov 2020 22:42:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8EGO61VY9gIZktCWX5Tna8EIc7zrQ671t Content-Type: multipart/mixed; boundary="ySNaEnLwkqXx14HKvr1wiOBT9vgQqsxtv"; protected-headers="v1" From: Stephen Farrell To: John C Klensin , Brian E Carpenter , S Moonesamy , IAB Chair , architecture-discuss@iab.org Message-ID: <73a73ef6-f838-ba89-625e-4da48fa81553@cs.tcd.ie> Subject: Re: [arch-d] Program issues References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com> <4122D6135972E5300169F327@PSB> In-Reply-To: <4122D6135972E5300169F327@PSB> --ySNaEnLwkqXx14HKvr1wiOBT9vgQqsxtv Content-Type: multipart/mixed; boundary="------------42FA06E506175185DE7E1320" Content-Language: en-US This is a multi-part message in MIME format. --------------42FA06E506175185DE7E1320 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 15/11/2020 22:36, John C Klensin wrote: > Granted that I'm getting a bit paranoid about such things but, > when I read that proposal, I saw, not a simple adjustment of > terminology but a further step in which the IAB becomes less a > single (and jointly accountable) body and, instead, more like > the IESG where different members are assigned primary > responsibility for different topic areas and keep that > responsibility for long periods of time. I never thought of that and nobody discussed that and I don't believe that's at all in-play myself, so yep in that case I think paranoia is not warranted. Cheers, S. --------------42FA06E506175185DE7E1320 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------42FA06E506175185DE7E1320-- --ySNaEnLwkqXx14HKvr1wiOBT9vgQqsxtv-- --8EGO61VY9gIZktCWX5Tna8EIc7zrQ671t Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl+xrtcFAwAAAAAACgkQWrL68XsXK+ps uQ//Ug905McpxcOJ2XjI29YVIuhXvvQFNWsBy3GSeBO99BCiu+yuEtEp4bQ2zf74WWTiwQQlX4q9 M4oY64ok8HjjkGOmsg9kHHS/3ExLyHI2k/BxZPE00C5HCvJTlugiy08h7cmCZpgG+kYRwn/UfDp3 W94y1H+ySJ2xf9q8glU0njdm3V/jrmxQTlcY8gNCFXIklQ74KpUaqu63T/j5E2dLAFRimoLbkpQ4 tgMM/InkM/n9GijATDrBFl4Z7i4LvpXQbDZbiqeqXqgUnEKWt3BVwsqvcnNMruNRv+rZDhaF12MR zUjR8B4Vs679uP6XQFus/h6R+lMpv8/zvWUysEcfvkdj31f0EJPJ+ZlK99VKk1DVEYfTE9mYE9Of c8anHSpIR9USZ8zu2pXDNQdclGK96i2s2RTgpImyzaJFQXJZ/7e82sjxjCp9bIs2tDCkW2BqAjQO KwhDrYCDYPoluEKQGxIcR6ETQgLmYoJ7Gxt6RLlWeRfX433+bpMOhZhzlhM91WeSVIlzipD4wtgK O5uxD4EKwBI2S+dqry6BGvZcKb1xlN24zTNxh9ZPLKUATn9rGnrRf1fjc44/t1CnGnxf1qyWGorX vibmHx4zP2XiwS3jRgfgeBguDaPFc250RQc3AftFGRQh5lXFBEBVz7YJ5xUm+4JbVNcvvV+x0CS1 7Ss= =0cbH -----END PGP SIGNATURE----- --8EGO61VY9gIZktCWX5Tna8EIc7zrQ671t-- From nobody Sun Nov 15 14:44: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 243203A1090 for ; Sun, 15 Nov 2020 14:44:20 -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, 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 ZTKEFAN6rf4O for ; Sun, 15 Nov 2020 14:44:18 -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 B7FD73A1065 for ; Sun, 15 Nov 2020 14:44:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B5773BE4C; Sun, 15 Nov 2020 22:44:11 +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 0FdI6WYHYTrd; Sun, 15 Nov 2020 22:44:10 +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 004B7BE3E; Sun, 15 Nov 2020 22:44:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1605480250; bh=M15Zo0Nq13Si6/WdVjPagTtLzfZaaCeQwr7OmQwt4Ms=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=QAHP6hErr+9UYklWu07jmonHb0/pn2d/dyTMtBf1Lt3sdf4SafKE7TA5A5A+MsVY1 nFLP53fj3lQFVmXY+Pb5/upEfDttr/byaoI6yF2QV9GUCS/sJInk+PaW7i9KCbarRK oXVq2rtXQg+rZgVbjL4BmVW4O8wFyUBuLLq876Ls= To: Bernard Aboba Cc: architecture-discuss@iab.org References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com> From: Stephen Farrell Message-ID: <4ffc9a4a-2d1a-af69-997b-6c668d0b9176@cs.tcd.ie> Date: Sun, 15 Nov 2020 22:44:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x2ScyUvuLXlSXwmMOn8J9yh2c5tbESayO" Archived-At: Subject: [arch-d] Reducing IAB admin things (was: Re: Program issues) 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, 15 Nov 2020 22:44:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x2ScyUvuLXlSXwmMOn8J9yh2c5tbESayO Content-Type: multipart/mixed; boundary="bLiin11D0bB7jgdCk5FkTGFmuJW5FW0Cz"; protected-headers="v1" From: Stephen Farrell To: Bernard Aboba Cc: architecture-discuss@iab.org Message-ID: <4ffc9a4a-2d1a-af69-997b-6c668d0b9176@cs.tcd.ie> Subject: Reducing IAB admin things (was: Re: [arch-d] Program issues) References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com> In-Reply-To: --bLiin11D0bB7jgdCk5FkTGFmuJW5FW0Cz Content-Type: multipart/mixed; boundary="------------4ADE4EE6FCA7342E6C4778E9" Content-Language: en-US This is a multi-part message in MIME format. --------------4ADE4EE6FCA7342E6C4778E9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 15/11/2020 22:05, Bernard Aboba wrote: > Given these inherent problems, I would agree that the IAB needs to mini= mize > that part of its efforts. The best way to ensure that this happens is = for > the IAB's administrative programs to be examined one by one, with an ey= e to > removing them from the IAB's charter. I think that's a credible proposition to explore. Be v. interested were it to be raised at the plenary and/or discussed more on some list. (I guess arch-d - even the name of which seems ironic for this topic;-) Two inputs to that: - In my last 2 years on the IAB and in interacting with IAB folks whilst on the IESG and otherwise, I have many times heard people bemoaning that the A in IAB was more for Admin than Architecture. I honestly can't think of a time when any IAB member wanted more of that. (But if they did, I'd probably have assumed they were joking and forgotten:-) So some of this could well be pushing at a very open door. - The hard part may be to find someone else to do stuff and to get agreement on that. The IESG already do too much. Some of these things do involve other bodies (e.g. other SDOs) where explaining change to 'em might be tricky. And lastly, and most tricky: it might take way more effort to agree a new setup than to just muck along with the current one, and that effort mightn't be worth the gain. (*) I'm not sure about that TBH and it may vary from topic to topic, but it'd be worth considering costs/benefits before trying to make too much change maybe. Cheers, S. (*) As one example, the IAB being the IETF's "department of foreign affairs" for liaisons has never made sense to me personally, but almost all the liaison oversight stuff the IAB does takes almost no time as the real action is handled by ADs or WG chairs or by volunteers who happen to be active in both bodies. And for some foreign bodies, explaining to them that we're changing our end of that bureaucracy may require a pile of unrewarding work. So that may well be one better left as-is rather than risk creating a new can of openable worms maybe;-) --------------4ADE4EE6FCA7342E6C4778E9 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------4ADE4EE6FCA7342E6C4778E9-- --bLiin11D0bB7jgdCk5FkTGFmuJW5FW0Cz-- --x2ScyUvuLXlSXwmMOn8J9yh2c5tbESayO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl+xrzkFAwAAAAAACgkQWrL68XsXK+pg Vg//UkkFweiKTLZitsM6dVLzf36RFjFdKkLqRnk8Wg5163U2eQ+MO+2MRkEfPtrVqKkbC2/sXcFs ogzVK35YctaLUY6LPWO5h3z8ZH83VFIINMlFxdItrPo4kiVWTy5xbGb5kXKP9bd0rvneuajybY8E hYugWbtzzOv7dfrbNK0AuHbfpco8gX7fkefjmKFWpKya/SUP7vkuAw+2++uil8q5lfah+XaYZTAQ FH/u1JM1ReXraFGcWpLRg607gPAWwUOOV7bt8NAZ2Ze/pVRM/+3uwbVYtSd25kU2G9o32/PfuAyN zS+easkZj0fajIqsrE89kjyXr5RffAQ/iCW1PfVe9fX/ZlEj0q45FccSWnwd3yVnM8cSxvoaIMw/ A2e/M03JPHEwrMOPvxXaoAW3PYIXJwcr8WjfL3gLfJH4KtfZ7WMcad2IJ/7mimodxEl/lYr0C4fx u+F2x+lSWc+NQPrs37/iDzc2el4Fwhre5aKjbKeeAGwGk4cgSX57onguEEY2Wlo/hSxnHtR4NbSq Vp3Mtc450gE1IUB3dO+FHxBShYhL37VgRmKorSn29ollvMcGSrVhCR7LsJv54J8JTw0CF5L8kJ42 buwF5Z1Qf4LgS4dszQ8wV6qib7umgXC7GnaYzb/T6FJOsJgIV72qcN8oCtI5VWEsWuNZlqUzyGWW abc= =uo0N -----END PGP SIGNATURE----- --x2ScyUvuLXlSXwmMOn8J9yh2c5tbESayO-- From nobody Sun Nov 15 14:47: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 09E833A0FCD for ; Sun, 15 Nov 2020 14:47: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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 (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 If16KKR9FV7X for ; Sun, 15 Nov 2020 14:47:51 -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 AD4F63A0FC9 for ; Sun, 15 Nov 2020 14:47:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D0F07BE4C; Sun, 15 Nov 2020 22:47:48 +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 sOA2uzkYXxtU; Sun, 15 Nov 2020 22:47:46 +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 8F8B9BE3E; Sun, 15 Nov 2020 22:47:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1605480466; bh=O5iulOpfSbCidJR/QFo43ZMGFbjtVafG4DT0/bs/fPo=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=cv6OQ3oIVzqpesyEW5pHZ3cJDQXksOX7z8lQATd3ImBcBoltANAFuifCPtdcWO4r/ AmSubMdAHHCIU57iONPKhHfwuKJY9ZYUI68Ny6Vc9FejGR3nFuaI4rZ4H5z1LwcrT/ IZzt/Bh7cNDC/BxJ5jL1Tom+wB5r6OxB/mZT9Ry0= From: Stephen Farrell To: Bernard Aboba Cc: architecture-discuss@iab.org References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com> <4ffc9a4a-2d1a-af69-997b-6c668d0b9176@cs.tcd.ie> Message-ID: <11dded4f-bd7d-05b3-473c-633d6625900d@cs.tcd.ie> Date: Sun, 15 Nov 2020 22:47:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: <4ffc9a4a-2d1a-af69-997b-6c668d0b9176@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8dHIHFqugqjjrPQs7WiXqgIgeOPmS048N" Archived-At: Subject: Re: [arch-d] Reducing IAB admin things (was: Re: Program issues) 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, 15 Nov 2020 22:47:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8dHIHFqugqjjrPQs7WiXqgIgeOPmS048N Content-Type: multipart/mixed; boundary="GhU3LSF33j8whzwbnhu3iEQu5w4B1Rk0J"; protected-headers="v1" From: Stephen Farrell To: Bernard Aboba Cc: architecture-discuss@iab.org Message-ID: <11dded4f-bd7d-05b3-473c-633d6625900d@cs.tcd.ie> Subject: Re: Reducing IAB admin things (was: Re: [arch-d] Program issues) References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com> <4ffc9a4a-2d1a-af69-997b-6c668d0b9176@cs.tcd.ie> In-Reply-To: <4ffc9a4a-2d1a-af69-997b-6c668d0b9176@cs.tcd.ie> --GhU3LSF33j8whzwbnhu3iEQu5w4B1Rk0J Content-Type: multipart/mixed; boundary="------------2AF0D27430737AA51CC06396" Content-Language: en-US This is a multi-part message in MIME format. --------------2AF0D27430737AA51CC06396 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Sorry, I should've said there: that concept of "reducing IAB admin things" wasn't discussed by the IAB before Mirja sent out that note. That mail was just me trying to see if people thought it worth looking into. IOW, there's not a big secret plan anywhere here, just a few bits of tidying up, improving etc in the refactoring programmes stuff. But if that shows the way to do something better as we go, then that'd be good I guess. Cheers, S. On 15/11/2020 22:44, Stephen Farrell wrote: >=20 > Hiya, >=20 > On 15/11/2020 22:05, Bernard Aboba wrote: >> Given these inherent problems, I would agree that the IAB needs to=20 >> minimize >> that part of its efforts.=C2=A0 The best way to ensure that this happe= ns is=20 >> for >> the IAB's administrative programs to be examined one by one, with an=20 >> eye to >> removing them from the IAB's charter. >=20 > I think that's a credible proposition to explore. Be v. > interested were it to be raised at the plenary and/or > discussed more on some list. (I guess arch-d - even the > name of which seems ironic for this topic;-) >=20 > Two inputs to that: >=20 > - In my last 2 years on the IAB and in interacting with > IAB folks whilst on the IESG and otherwise, I have many > times heard people bemoaning that the A in IAB was more > for Admin than Architecture. I honestly can't think of a > time when any IAB member wanted more of that. (But if > they did, I'd probably have assumed they were joking and > forgotten:-) So some of this could well be pushing at a > very open door. >=20 > - The hard part may be to find someone else to do stuff > and to get agreement on that. The IESG already do too much. > Some of these things do involve other bodies (e.g. other > SDOs) where explaining change to 'em might be tricky. And > lastly, and most tricky: it might take way more effort to > agree a new setup than to just muck along with the current > one, and that effort mightn't be worth the gain. (*) I'm not > sure about that TBH and it may vary from topic to topic, > but it'd be worth considering costs/benefits before trying > to make too much change maybe. >=20 > Cheers, > S. >=20 > (*) As one example, the IAB being the IETF's "department > of foreign affairs" for liaisons has never made sense to > me personally, but almost all the liaison oversight stuff > the IAB does takes almost no time as the real action is > handled by ADs or WG chairs or by volunteers who happen to > be active in both bodies. And for some foreign bodies, > explaining to them that we're changing our end of that > bureaucracy may require a pile of unrewarding work. So that > may well be one better left as-is rather than risk creating > a new can of openable worms maybe;-) >=20 >=20 >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 --------------2AF0D27430737AA51CC06396 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------2AF0D27430737AA51CC06396-- --GhU3LSF33j8whzwbnhu3iEQu5w4B1Rk0J-- --8dHIHFqugqjjrPQs7WiXqgIgeOPmS048N Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl+xsBEFAwAAAAAACgkQWrL68XsXK+oZ FBAAo5WpyZYLsR0I3TDhZWiXyR2hAOELFUfBZ4XKGsl28F004x6ZPm8vCNDTiwLhoXreCplFhM2J b3+0IF7yKOjqtTwKJY4awS+j/4iLkgBN+RVzkffr4is8rGp+V/Gg4lSPTbQpiOjAZQ2OZWPjfRZy rLOURoCCsmPn8XNurFCc9Huen/R40uRAzFyGYGgh4um2LltUD8HftwTsejMvLTQXEtD/ggT1oY3K iZnFgomolzcQBDmrd2ZZXIWTGJEhXy7HlFUlGdql3dclJsAnN7ERqictKp8Sk+/mNegEOmSuILx3 vwtrbvBRMTjmdJ78dVvcR8SO4CCM6nmwurd2CeV9r4s463sSXiFYrIx5d1DL6GCZsC8K6RNUiUkq XMYzQxyD+c5/XJoxhmx1O1xX11d0a1scrmqUF9DnyBnzCiWBz5zy0mO5v/dK97n9AD8ZnmjfFfKp jaOs3HSQSAIbOEqWEYmLWM/w7Y2TqdmkNnpuquHkRlD9B51jHsDvBYHQW6Th7dm2XNcpre5rTbJ2 Yz5oupUfOt/vlbfO//iVfTAAWYj7ooH1VsidNnRDL297o1EEH2DvpIrL17ox7PT5Du61VCGlNzXy fny9n6CnbgEwJUHUWj8J/Bj1rwLrHulP9H4gSpSa0V17FAwsynxu6aV/xtGk+vB7I59I+TE7C4pP 4DU= =RtN3 -----END PGP SIGNATURE----- --8dHIHFqugqjjrPQs7WiXqgIgeOPmS048N-- From nobody Sun Nov 15 14: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 121E83A0FEC; Sun, 15 Nov 2020 14:49:30 -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=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 Xpy-Yyko174z; Sun, 15 Nov 2020 14:49:29 -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 5549D3A103E; Sun, 15 Nov 2020 14:49:27 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1keQpj-000Np7-Lb; Sun, 15 Nov 2020 17:49:19 -0500 Date: Sun, 15 Nov 2020 17:49:13 -0500 From: John C Klensin To: Stephen Farrell , Brian E Carpenter , S Moonesamy , IAB Chair cc: architecture-discuss@iab.org Message-ID: <59C0583170CE2C33E27D67F7@PSB> In-Reply-To: <73a73ef6-f838-ba89-625e-4da48fa81553@cs.tcd.ie> References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com> <4122D6135972E5300169F327@PSB> <73a73ef6-f838-ba89-625e-4da48fa81553@cs.tcd.ie> 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] Program issues 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, 15 Nov 2020 22:49:30 -0000 Good. I always appreciate one less thing to worry about. At the same time, I was worried more about slippery slopes than specific intentions at present, so I'm unlikely to completely stop worrying. john --On Sunday, November 15, 2020 22:42 +0000 Stephen Farrell wrote: > > Hiya, > > On 15/11/2020 22:36, John C Klensin wrote: >> Granted that I'm getting a bit paranoid about such things but, >> when I read that proposal, I saw, not a simple adjustment of >> terminology but a further step in which the IAB becomes less a >> single (and jointly accountable) body and, instead, more like >> the IESG where different members are assigned primary >> responsibility for different topic areas and keep that >> responsibility for long periods of time. > > I never thought of that and nobody discussed that and I don't > believe that's at all in-play myself, so yep in that case I > think paranoia is not warranted. > > Cheers, > S. From nobody Sun Nov 15 22:16: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 736433A13E3; Sun, 15 Nov 2020 22:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.074 X-Spam-Level: X-Spam-Status: No, score=0.074 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwfpzVyIT2H4; Sun, 15 Nov 2020 22:16:23 -0800 (PST) Received: from [IPv6:2003:de:e707:b600:9908:c4b2:85c3:7c10] (p200300dee707b6009908c4b285c37c10.dip0.t-ipconnect.de [IPv6:2003:de:e707:b600:9908:c4b2:85c3:7c10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 078B53A13E0; Sun, 15 Nov 2020 22:16:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: IAB Chair In-Reply-To: <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> Date: Mon, 16 Nov 2020 07:16:20 +0100 Cc: IAB IAB , architecture-discuss@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [arch-d] IAB report to the community for IETF-109 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, 16 Nov 2020 06:16:26 -0000 Dear S. Moonesamy, Please see replies to your questions below. > On 15. Nov 2020, at 15:12, S Moonesamy wrote: >=20 > Dear Internet Architecture Board, > At 10:34 AM 13-11-2020, IAB Chair wrote: >> IAB Programs >> =C2=97=C2=97 >> =C2=94 >> The IAB has been working on refactoring its programs. In analysing = the current IAB programs, the IAB identified two kinds of programs which = are quite different in their needs and goals. Therefore, the new = structure proposes to separate today's IAB programs into Technical = Programs and Administrative Support Groups. The aim of this effort is to = increase transparency, visibility, and openness of the architectural = work done by the IAB. A request for feedback about this reorganization = has been sent to the architecture-discuss@iab.org list, see >=20 > The report for the announcement is for July. Is this a mistake? Sorry for the confusion again and also my late response. I believe that = has been clarified in the mean time. >=20 > The Administrative Support Group is akin to a group of 10 persons = providing assistance to a committee comprising the 13 persons. That is = different to the (IETF) directorates. Using the IANA as an example, and = based on what was reported, there wasn't anything significant from March = to July. I don't remember seeing any discussion of an appointment this = year. What does the IAB require assistance with? As you can see in the current report there was also not any mentioning = of these groups. This is because these groups are often/usually rather = low activity, at least without specific events that needs reporting, and = mainly provide specific expertise to the IAB when needed. However, we = receive certain reports, also from IANA, on a regular basis which can be = found in the minutes of the respective next IAB call. >=20 > It is commendable that IAB/IAB programs might wish to fix dysfunctions = within areas of IETF activity by doing the work. However, the role of = the "Architecture" in "IAB" is for long range planning and coordination. = The intent of Section 2.1 (RFC2850) is that the IAB is not the group = responsible for doing the actual work or else that would not be labelled = as "oversight". Responsibilities as described in section 2.1 are addressed, among other = things like e.g. workshops as also mention in that section, by Technical = Programs. As such the intention of Technical program is to=20 "make sure that [...] issues are brought to the attention of the group(s) that are in a position to address them=E2=80=9D=20 as also described in that section. And that's also what we described in the text provided about Technical = Programs: "The primary goal of a Technical Program should be to raise awareness of = an issue or question relating to the Internet architecture, or to = consider whether there is a question to be answered in a particular = area. Technical Programs help the IAB to frame questions. They do not directly = work to develop protocols, requirements, or use cases for new protocols, = systems, or frameworks. If a Technical Program concludes that = engineering or standards are required, a BoF should be considered to = transition the work to the IETF.=E2=80=9D >=20 > The concept of "program" creates opaque accountability. Has the IAB = considered that? There has been already some discussion about this point. However, part = of the restructuring is also to clarify these things. I think this = discussion applies rather to Administrative Support Groups and as I = noted in my mail to the architecture-discuss@iab.org list: "Administrative Support Groups are the current technical plenary = program, the IANA program, and the liaison program. Please note that the = IAB is also in the progress of reviewing these activities.=E2=80=9D >=20 > I did not find anything in the report pertaining to the IAB = representing the interests of the IETF. Is there an explanation for = that omission? I'm not sure what you would be expecting on this point as the report is = summarising activities since the last IETF meeting. Mirja >=20 > Regards, > S. Moonesamy=20 From nobody Thu Nov 19 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 607013A106D for ; Thu, 19 Nov 2020 11:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 1mb_lka1iKWO for ; Thu, 19 Nov 2020 11:25:56 -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 A071D3A1060 for ; Thu, 19 Nov 2020 11:25:56 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id y24so874511otk.3 for ; Thu, 19 Nov 2020 11:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=6tt1CI2tMSajU/Qvco62aFkYq3eHkd0gzJA1K7y2Yhc=; b=WEhbUP5QgT0yaktgR5axsRS/i14fDwmO5/vzG6ltfoIoKOTGa8Zu2qJBoWyKNQ5Hu/ 1wkCWb647mKpceuL6pHxY74OQb1Jgqa6UAY15bq7+IPS73T8ACZ3rUd0Mgnne6Sxc6Ef HnQPoBF0UH8AAdFY52NMOU8P5YztjugxqQeLm9+y/pcDx8ql1bnQwRAy6Jjv2EtmoYiJ lxN47let9DCkhKds1fl2YQ21YL8IQf5ajbVWIVQ3ide/uLbFNjdpA7AzFoHOMvJ2crfH m2ohrpnar0luCWTTS124mKNwc7TFNo3tS0fyhzSg/hS9gJfk3DkaZ7ZeorGpBZfIUfxj /hxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=6tt1CI2tMSajU/Qvco62aFkYq3eHkd0gzJA1K7y2Yhc=; b=mVmdKt2uAmU2VUk/w70LLLLF4lXEU2sacLtyGEG69PbU8LW1Eqytpibrnnh4YDiyA8 JgyVZUFTD0M0ZBs6fpxuj6SVZ16ubmzbh+41YnXHy0rArDDxXIBKUABymjerclFRJ5gD XyqSQDUALKDBqIADaldENK0OSQzIt8k5EO3Pgu9Be06sluwUHrH5KHxJ2aZsijpQmwe3 P1Wim1Kpr6J6qNxOsw/w2uY79LHs/qvnCEi6ZI4D0KMiHPpYapXIl8O4JUVFF8aL2veK AIE/pytf8BrWlGeXyk+zTYTfot45bQN1FhqRedofskSOhDPz2dCInvcls7Q6sxPN/01O 5SoQ== X-Gm-Message-State: AOAM533AgRehLfN4augNGPb5BSR+mmv2ItHovbU3dLskOU+2204D8pGL s97EPz4ch49SWT2ZoZesZcJ27ULE5ljDyg== X-Google-Smtp-Source: ABdhPJzXKZV60HrqzeKgSBFwVS2+rGhn0+bZ0Hf+HEiE/I6yRCIWYIQzjwdM4j5Fv9aJxwJCB7HnAQ== X-Received: by 2002:a9d:27e8:: with SMTP id c95mr11359979otb.262.1605813954105; Thu, 19 Nov 2020 11:25:54 -0800 (PST) Received: from ?IPv6:2602:304:78e4:12b9:144c:b2d5:f0a1:867b? ([2602:304:78e4:12b9:144c:b2d5:f0a1:867b]) by smtp.gmail.com with ESMTPSA id q132sm380942oia.46.2020.11.19.11.25.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Nov 2020 11:25:52 -0800 (PST) To: architecture-discuss@ietf.org From: Hesham ElBakoury Message-ID: Date: Thu, 19 Nov 2020 11:25:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C3D9C3A4B9C851D17ED928BB" Content-Language: en-US Archived-At: Subject: [arch-d] Announcing the first FlexNGIA Workshop - Call for Papers 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, 19 Nov 2020 19:26:02 -0000 This is a multi-part message in MIME format. --------------C3D9C3A4B9C851D17ED928BB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit *CALL FOR PAPERS* 1st IFIP/IEEE International workshop on                    Fully-Flexible Internet Architectures and Protocols                         for the Next-Generation Internet (FlexNGIA 2021                      in collocation with IFIP/IEEE International Symposium on                            Integrated Network Management (IM2021) 17-21 May 2021 // Bordeaux, France *https://www.FlexNGIA.net/workshop* --------------------------------------------------------------------------------------- The rise of edge, cloud and in-network computing and the proliferation  of  Artificial Intelligence (AI) solutions in networking  are  promoting the development of innovative applications like virtual/augmented reality, tele-presence, autonomous systems, remotely controlled robotics and tactile applications, promising  to  revolutionize health-care, transportation, industry, agriculture, society and culture. To deploy such applications and  to  comply  with their  requirements,  there is a need for new Internet paradigms including  a  Tactile Internet  that  combines  ultra  low latency with extremely high availability, reliability  and  security.  This  has  been  the  focus  of both   ITU and IETF/IRTF related initiatives for the past few years. Today’s   Internet falls   short  when  it  comes  to providing such requirements due to Several design  and implementation  limitations. To overcome these  it is essential to rethink the current Internet  and  devise  new   architectures  and   protocols  by efficiently harnessing recent technological  advances   in   terms   of virtualization, Network softwarization, NFV/SDN, and Data plane programmability, even when  they  break the tenets of the current Internet. This vision is embodied in the FlexNGIA Architecture (https://www.flexngia.net)that has the  potential  to enable  novel  network  services  and  management  schemes adapted to the requirements of future Internet applications. ================== Topics of Interest ================== The topics addressed in this workshop include, but are not limited to:    - Analysis of  the characteristics and requirements of future network applications.    - Gap analysis highlighting the limitations of the traditional Internet architecture      and  protocols  and their inability to cater to future applications’ requirements.    - Design  and evaluation   of   new   architectural  paradigms  and communication      protocols as well as network  management schemes  based on AI/ML and  distributed      decision making.    - Use-cases  and specific  applications   and   potential   mechanisms, protocols      and  schemes  to ensure  the  performance  and  reliability  required  by future      applications including the move to Industry 5.0 and 6G networks.    - Solutions  to further develop the FlexNGIA towards a full-fledged architecture by      addressing key research challenges including service function chaining, functional      decomposition, alternative  Network/Transport protocols,  resource management,      signaling,  design of  high-performance  virtual  network functions and services,      high-precision monitoring,  measurements  and  in-network  telemetry, pricing and      economics, Security and privacy. *More  challenges  are available at https://www.flexngia.net/research-challenges* ======================= Submission Instructions ======================= Authors are invited  to submit original contributions. Submitted manuscripts should use IEEE 2-column  conference style  and  are  limited  to 6 pages (including references). The submission link will be available soon at https://www.flexngia.net/workshop =============== Important Dates =============== - Paper submission deadline: January 8, 2021[e][f][g] - Paper acceptance notification: February 18, 2021 - Camera-ready version due: March 5, 2021 ==================== Organizing Committee ==================== *General co-chairs* ----------------- Marie-José Montpetit, Concordia University, Canada Latif Ladid, IPv6 Forum/University of Luxembourg, Luxembourg Rui L. Aguiar, University of Aveiro, Portugal *TPC co-chairs* ------------- Nadjib AitSaadi, Paris-Saclay University, France Noura Limam, University of Waterloo, Canada Lisandro Zambenedetti Granville, UFRGS, Brazil ==================================================================== *For more information, please check https://www.flexngia.net/workshop* -- Please check www.FlexNGIA.net for more information about the FlexNGIA project --- --------------C3D9C3A4B9C851D17ED928BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


                                    CALL FOR PAPERS

 

                        1st IFIP/IEEE International workshop on

                   Fully-Flexible Internet Architectures and Protocols

                        for the Next-Generation Internet (FlexNGIA 2021

                     in collocation with IFIP/IEEE International Symposium on

                           Integrated Network Management (IM2021)

                              17-21 May 2021 // Bordeaux, France

                          

                           https://www.FlexNGIA.net/workshop

                                  

---------------------------------------------------------------------------------------

The rise of edge, cloud  and in-network computing and the proliferation  of  Artificial

Intelligence (AI) solutions in networking  are  promoting the development of innovative

applications like virtual/augmented reality, tele-presence, autonomous systems, remotely

controlled robotics and tactile applications, promising  to  revolutionize health-care,

transportation, industry, agriculture, society and culture. To deploy such applications

and  to  comply  with  their  requirements,  there is a need for new Internet paradigms

including  a  Tactile  Internet  that  combines  ultra  low latency with extremely high

availability,  reliability  and  security.  This  has  been  the  focus  of  both   ITU

and IETF/IRTF related initiatives for the past few years.

Today’s   Internet   falls   short  when  it  comes  to providing such requirements due

to Several design  and  implementation  limitations. To overcome these  it is essential

to rethink the current  Internet  and  devise  new   architectures  and   protocols  by

efficiently harnessing recent technological  advances   in   terms   of virtualization,

Network softwarization, NFV/SDN, and Data plane programmability, even when  they  break

the tenets of the current Internet.

This vision is embodied in the FlexNGIA Architecture (https://www.flexngia.net)that has

the  potential  to  enable  novel  network  services  and  management  schemes  adapted

to the requirements of future Internet applications.

==================

Topics of Interest

==================

The topics addressed in this workshop include, but are not limited to:

   - Analysis of  the  characteristics and requirements of future network applications.

   - Gap analysis highlighting the limitations of the traditional Internet architecture

     and  protocols  and their inability to cater to future applications’ requirements.

   - Design  and  evaluation   of   new   architectural  paradigms  and   communication

     protocols as well as  network  management schemes  based on AI/ML and  distributed

     decision making.

   - Use-cases  and  specific  applications   and   potential   mechanisms,   protocols

     and  schemes  to  ensure  the  performance  and  reliability  required  by  future  

     applications including the move to Industry 5.0 and 6G networks.

   - Solutions  to  further develop the FlexNGIA towards a full-fledged architecture by

     addressing key research challenges including service function chaining, functional   

     decomposition,   alternative  Network/Transport protocols,  resource   management,

     signaling,  design  of  high-performance  virtual  network functions and services,

     high-precision  monitoring,  measurements  and  in-network  telemetry, pricing and

     economics, Security and privacy. 

More  challenges  are available at https://www.flexngia.net/research-challenges

=======================

Submission Instructions

=======================

Authors are invited  to submit original contributions. Submitted manuscripts should use

IEEE 2-column  conference  style  and  are  limited  to 6 pages (including references).

The submission link will be available soon at https://www.flexngia.net/workshop

===============

Important Dates

===============

- Paper submission deadline: January 8, 2021[e][f][g]

- Paper acceptance notification: February 18, 2021

- Camera-ready version due: March 5, 2021

====================

Organizing Committee

====================

General co-chairs

-----------------

Marie-José Montpetit, Concordia University, Canada

Latif Ladid, IPv6 Forum/University of Luxembourg, Luxembourg

Rui L. Aguiar, University of Aveiro, Portugal


TPC co-chairs

-------------

Nadjib AitSaadi, Paris-Saclay University, France

Noura Limam, University of Waterloo, Canada

Lisandro Zambenedetti Granville, UFRGS, Brazil

====================================================================

For more information, please check https://www.flexngia.net/workshop

--
Please check www.FlexNGIA.net for more information about the FlexNGIA project
--- --------------C3D9C3A4B9C851D17ED928BB--