From nobody Fri Jul 9 15:50:34 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5993A0995 for ; Fri, 9 Jul 2021 15:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.594 X-Spam-Level: X-Spam-Status: No, score=-9.594 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=APuFH6Yj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pnzWYAQ5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXXVwqdDPA9J for ; Fri, 9 Jul 2021 15:50:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE903A093B for ; Fri, 9 Jul 2021 15:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7543; q=dns/txt; s=iport; t=1625871022; x=1627080622; h=from:to:subject:date:message-id:references:mime-version; bh=AA/A61lwDnKd8NlShf/arwaOPRl6MPQhrFYxcZhVomw=; b=APuFH6YjX9cM6boBdwq1bygopJzBcxCDjFkeMDCe4P9J0MG6NcDJVw07 7QDStsIrBdlgzvHzc2Hz8GBhaVZxebbxK0T6RpkPB7I8J4RemgFlqSQJt MTMBqicQ6j5VbOkk9f8xoiI/hg2wcwYc52xrpfbLFkyhgivJNHtl0OQmX A=; IronPort-PHdr: =?us-ascii?q?A9a23=3A19u9rh+msBSqaf9uWDvoyV9kXcBvk7T9NEgS8?= =?us-ascii?q?JV0w75Nc6H2+ZPkMQSf4Ph2l1bGUM3d7O4MkOvZta3sGAliqZaMuXwPatpAA?= =?us-ascii?q?hkCj8hFngUqRsmfBh6zIPvjdSdvGsNEWRds9G26Nk4AHsH4ahXSr3S+4CRUF?= =?us-ascii?q?A/4MF9+J//+HcjZiMHkv90=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A+MvNrahvQ7aSEUg0o4uq/6kRdHBQX1B13D?= =?us-ascii?q?Abv31ZSRFFG/FwyPrOoB1L73HJYWgqN03IwerwRZVoMkmsiaKdgLNhcotKOT?= =?us-ascii?q?OHhILGFvAb0WKP+UyEJ8SczJ8S6U4DSdkENDSYNzET5qyWjHjaYrQdKZu8gd?= =?us-ascii?q?qVbIzlvhBQpHRRGthdBnBCe2Cm+yNNNW17LKt8MKDZyttMpjKmd3hSRN+8HG?= =?us-ascii?q?M5U+/KoMCOvI76YDYdbiRXqTWmvHeN0vrXAhKY1hARX3dk2rE561XIlAT/++?= =?us-ascii?q?GKr+y78BnBzGXehq4m2OcJi+EzR/BkuPJlbwkEuTzYILiJnIfy+wzdldvfqm?= =?us-ascii?q?rCVuO85SvIcf4Dsk85NVvF3icFkzOQrgrGrUWSkWNxRRDY0JbErPVQMbsbuW?= =?us-ascii?q?sRSGqo12Mw+N57y65FxGSfqt5eCg7Bhj3045zSWwhtjVfcmwtorQaC50YvIL?= =?us-ascii?q?f2RYUh5LD3xnklWKvo3RiKnLwPAa1rFoXR9fxWeVSVYzTQuXRu2sWlWjA2Eg?= =?us-ascii?q?2dSkYPt8SJ23wO9UoJgncw1YgahDMN5Zg9Q55L66DNNblpjqhHSosTYbhmDO?= =?us-ascii?q?kMTMOrAijGQA7KMmiVPVP7fZt3cU4la6SHlondwdvaNKDg4KFC6qgpYWkowl?= =?us-ascii?q?LaIXieevFm9Kc7hyzwfA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRCQBE0ehg/5BdJa1QCh4BAQsSDEC?= =?us-ascii?q?BTguBU1EHd1o3MYgQA4U5iFYDlSiFAIEugSUDVAsBAQENAQE1DAQBAYRTAoJ?= =?us-ascii?q?4AiU2Bw4CBAEBARIBAQUBAQECAQYEcROFaAEMhkUBBhIuAQE1Aw8CARkDAQI?= =?us-ascii?q?oBzIUBwIIAgQTIoJPAYF+VwMvAQ6bFwGBOgKKH3iBNIEBggcBAQYEBIFJQUa?= =?us-ascii?q?CYBiCMgMGgTqCe4QMgmiDeyccgg2BPByCYj6CYgEBAQEBgTBNDQmDF4IuglK?= =?us-ascii?q?BCiYEOAsOAhSgAjefDwqDJIotlAMFJqZKlgCMLpNiUwGEHAIEAgQFAg4BAQa?= =?us-ascii?q?BYwspgVlwFRpLAYI+PhIZDo4fg3CFFIVKcwI2AgYKAQEDCYtrAQE?= X-IronPort-AV: E=Sophos;i="5.84,228,1620691200"; d="scan'208,217";a="893626842" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jul 2021 22:50:20 +0000 Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 169MoLO1023034 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Fri, 9 Jul 2021 22:50:21 GMT Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 9 Jul 2021 17:50:20 -0500 Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 9 Jul 2021 18:50:19 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 9 Jul 2021 18:50:19 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nMfHgDmgq9wEm7BX01TWec5iynCxGMO4uUlhyljQ1eCpYcIMm7Mp0Y5dmC29+YznoGtoKU5uUOilrJ+h7zNQE73Oc+cTYPj11lO+PPTuPvl331d4ZEpdLv0HMf07BoswNegVxuVJbRl80BnHKvnsSoy0JK5STp+0pAfhRpzZ8mity1RyAfiVO0QZAwh2S18okTqzMqvLhkkEN7v4xX3Z7x1rtJEBmB+vBiSvXvCkqfBBYbKiwnh5SFTkF0MctKxqDvu33uJ3q1cnBXnkCDbiHVx18b1dXHh/OcOnrPuNUkgEVrgYK5UelL9D7wpNzqiy7AaZzVfOeLyb5NTWrweaPA== 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=lyjEnVGizTQJR+Cw+dn3+N47NDZw7g+48n8kogfupy0=; b=hnD7sZCZWQ7ZlUbEsw7t4Bauy5up+bC/nAwTEd43ArPs0A2dvey/eIutoLO/Mct7OSpKCWfQU6/EtavBLlNZNYc91S+diyDYHfjMDchkwN28Kd8bIcYhbLL4IapLHqYek2EGo8Ouwbek4SZM6OIuXjPUlDugRsz1iYDG7AeLA1DjZnjdidFwQqC55XEbwECJsy24p9cHXEnBr2O3RfTo7uIDI2kyW5IFTFo4G/qCEDPK6Vtg67oBmzlnxbjQYUM3jvP3+u4gvfR+PUIfJMXn9ZK1MtIDCkwLQD/SsZjJkk0KoGlaOmkVcmAr+AmpeX5+8tMPRcwW8pGuGBJ6+40jdA== 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=lyjEnVGizTQJR+Cw+dn3+N47NDZw7g+48n8kogfupy0=; b=pnzWYAQ5cOfi2bUENEAoJBLNHG+XvGIIL944jwVfZkE1kT+oKtwUbZFWhaNeBXBjAfjujJfINYsxvr7ZsP8uLwvlZExs9bciA4eOsEUzARc69R6yoP84MLGbcO59USGEUMDGvcLq1CMXluUQN8qEkvhuHYLUDsK8N08qoebwK0o= Received: from SJ0PR11MB5053.namprd11.prod.outlook.com (2603:10b6:a03:2af::17) by BYAPR11MB2680.namprd11.prod.outlook.com (2603:10b6:a02:c9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.21; Fri, 9 Jul 2021 22:50:18 +0000 Received: from SJ0PR11MB5053.namprd11.prod.outlook.com ([fe80::dcb8:9b1d:cae2:468f]) by SJ0PR11MB5053.namprd11.prod.outlook.com ([fe80::dcb8:9b1d:cae2:468f%9]) with mapi id 15.20.4308.023; Fri, 9 Jul 2021 22:50:18 +0000 From: "Charles Eckel (eckelcu)" To: "edm@iab.org" Thread-Topic: New Version Notification for draft-eckel-edm-find-code-00.txt Thread-Index: AQHXdQ8OlW/G2jZrrEmXs/l1LB2ktg== Date: Fri, 9 Jul 2021 22:50:18 +0000 Message-ID: <5C77D292-692A-481E-B3F1-77C40130173F@cisco.com> References: <162586849638.22752.11317942246363134121@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.100.0.2.22) authentication-results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 834eec9a-9975-49f5-240f-08d9432becdd x-ms-traffictypediagnostic: BYAPR11MB2680: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0uBmNDPpH7KUCryx1oVD1PAr3gupy7Uu2MnNFxlPol5IHIF5TpQfFPDDL+NAFJf69q4OhuaEhDm2GgPlTuc/hhK7fgQgmBfR5406lOEJuSdQS/Lys7sZdGZh4dY/ipVbn1SJa7eE1rSB2z3kP9m9uhnTdDJPOMXXRdYay3zuhrz7Pe3J5tf16Zo5bTVGOcenMoTGxoqtdkmXEdbGeJ+5Jm28KIYrxIDTfhwAku45UPHkRCpzk1gMPrXAR3e4aONpRAw3tHGuEijop/+B3Oo/JFdcgdhlZ337JDWktEcPijZ5EWkYBrLBpLR0axmZuh6YTQaVB8KBejWgwpO9MZGEPitBly6D3yCELdO4ocPJXRXOYB7+dQsRGxTXDCvP06xzh1JNoPnVope2i86V6mSEo/ntr//pw0H++hpu17KrQcfmFpacbtzeDQPTRnwLbILIZz2ghF0TkM6X9VvIsKV7UI+sa7xuNtvWBNcQS3zdHjjtnvmLyoXfFjuSzslPQsC5BwGrrE1HuaSntmdUfQaz4t9j+b/mEt6HlA/zbCGeXB6DuBkakkUOJBySVKryjtW4keaNQxwVsn5qrAeMfO/viFpDvBsKtDcvdbDf92nO3lpTd2nez1LbTvx4dzDLsqb1vBEMmPq27jXe9RJGcNpMtM6SPKnoXfHoB7djnb4xkUSOtn+LQVNQCAtcHshVuawsE9DYayfcoV57lsAx3wu1/vtTVbUnNwd9K6KlI24MM32mnUyKWZiinShVVH3mF+ca+7CQes+LAQRq2GCHLhPP+oaI1W7T6jg/lHOx0oC8sOuWdQwSUzZ3SMGvIOaa2XIqDaumCE7ukjL7lQRAjbua/A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB5053.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(346002)(376002)(136003)(396003)(2616005)(21615005)(6506007)(122000001)(8936002)(6512007)(6916009)(15650500001)(186003)(6486002)(8676002)(316002)(166002)(2906002)(33656002)(38100700002)(36756003)(86362001)(66476007)(64756008)(66556008)(5660300002)(66446008)(76116006)(966005)(66946007)(478600001)(66574015)(83380400001)(71200400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?wirXUUdGAook3m40WLbLiH29ApYex6Aou+qVQ+piE3Ksjga1gfMacdTO7aDA?= =?us-ascii?Q?4Auvi6cfeqrHnT5XgGxEQ0OrHK4Mjl0slDG8uYbJ3A3tpPR9kNYkEreT+0Pv?= =?us-ascii?Q?6egUR9apECqH28LXnkOqCanDzGj9GtLuh+XUpY56vfUtu8N4ArzUz2H0pI7Y?= =?us-ascii?Q?g9sBk2mONMBarIzmewORIlahTy6BCmc0WkFhrbtP7Uh7GmT8z8Anuc40xhHR?= =?us-ascii?Q?MUuWRSFwphcmBzh7TouKN+2OomBbkIa6zrmOw1dO3bP1ahwFGAcK94unWj8O?= =?us-ascii?Q?GbDxYY0jQ6vQYIzIoZ1XhARefNBy1Bk5EGBmKbXaeK5cHpMleOTJpYXyvP9W?= =?us-ascii?Q?5VAaMilqUfD1qo41wMSOqTu/VAZs3/lCrNQArFPmKGww56clGxBzvHY/85rn?= =?us-ascii?Q?Q2l8kU30dP1K1RqWPTu10fbIpI2C1wFE32GsxI26lNS+R/Px/1Ssty0yHi8w?= =?us-ascii?Q?SXYoR2h7Iw6HguRAtBXpL6bPxBLiSyl9Md9anTbV2UQ30cisdlszGHxEULNb?= =?us-ascii?Q?cd/g7v6XsAl1aYzJ/ZTmZSYhDHckDZEL7NPmvr9fRSwR8rin/OaV5rFeEg7v?= =?us-ascii?Q?WQZaf6cdRnuKqa5FdY5Q59+EE/WD+ImOEjni4iZG1ohFQcXvoZ8GyPtlimDQ?= =?us-ascii?Q?9uaz4pvNJ57JoPQ9vljfvNkzFyhigLQV3kbOwaghifv7S27Lar3mzLCBaRH9?= =?us-ascii?Q?CJ2+Wg6O2rGvlqPDJaMkd/69B/OHPB5WjQpNi7S7bfsj3c+vsEijemot77Vp?= =?us-ascii?Q?Q+KBUaYU2u60+cJPD2CAHE7pHnKQexZUn6TTpaIS/GBs1Zd1OF9rw9qUNYc6?= =?us-ascii?Q?SYEly/hRQvQDmZjSQNToKw9Srbfdxs1oLE6SP7U3m/fASRUGVATUZVXFIlO0?= =?us-ascii?Q?DzaUaEhWLvKmi7QPc5D3Zb2hDvPjjB4rgd5zPIg7q5eu3HYwpVmsYutzEHEQ?= =?us-ascii?Q?ftNPCSuAlsqp/rfO6p+qPgkkTdy2aho6cn0xXznAWnzj1/jkcEfDPvstAn0Q?= =?us-ascii?Q?58sSyREzX0AoXP747nVGm15dhfJadm5H10czx+zZ7YjNHaFKLDXJcvSlG8oq?= =?us-ascii?Q?UQaQuzGJCm+W9zIIAm61XHhwmH930Cv6Pplv1pTpA4imlpvdFbL3yB6123kG?= =?us-ascii?Q?PmAddHoiueocoWzQm0LTugZzZyrX3+JVk9eFCYIITjpYmGugwP3vKiCrlZ3b?= =?us-ascii?Q?MoIxRmkk7WdUH62VRAlH/n596hJsX3A5rRPR66YVR1mpEvsP0JiAZM2BXEEG?= =?us-ascii?Q?LgSE9jfxDG9kiEIwPaDTbhrGOdxA+9FMfu+hiT/7480+8OdRRyRKALXbUqs7?= =?us-ascii?Q?gr3L6WXlbFHgHt2xIScv2obP0/e2OcRnaohiSWsKcbuz018Udffhukl64EWV?= =?us-ascii?Q?ToLOfwR5b8ktIHUjHplB5c6D3NnviWXYNsrHlePRRU2x3Dzt6Q=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_5C77D292692A481EB3F177C40130173Fciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5053.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 834eec9a-9975-49f5-240f-08d9432becdd X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 22:50:18.5449 (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: IK0x+kqs22PRj7WbFIPRGjbu85n1nep27EsDmEGwaHt8i4kIr0mkZNC9KFm0cKfg7tck3ncaZn7ovQTW9RMYyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2680 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: [Edm] Fwd: New Version Notification for draft-eckel-edm-find-code-00.txt X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 22:50:32 -0000 --_000_5C77D292692A481EB3F177C40130173Fciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, We had some good discussions near the end of last year about making it easi= er to find code related to drafts and RFCs. I posted this draft in an attem= pt to revive that discussion and hopefully make progress toward improving t= he current situation. Comments, suggestions, pull requests welcome. Cheers, Charles Begin forwarded message: From: > Subject: New Version Notification for draft-eckel-edm-find-code-00.txt Date: July 9, 2021 at 3:08:16 PM PDT To: Charles Eckel > A new version of I-D, draft-eckel-edm-find-code-00.txt has been successfully submitted by Charles Eckel and posted to the IETF repository. Name: draft-eckel-edm-find-code Revision: 00 Title: Find Code Related to an Internet-Draft or RFC Document date: 2021-07-09 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-eckel-edm-find-code-0= 0.txt Status: https://datatracker.ietf.org/doc/draft-eckel-edm-find-code/ Html: https://www.ietf.org/archive/id/draft-eckel-edm-find-code-0= 0.html Htmlized: https://datatracker.ietf.org/doc/html/draft-eckel-edm-find-= code Abstract: Code related to existing IETF standards and ongoing standardization efforts may exist and be publicly accessible in many places. This document provides a set of practices to make it easier to identify and to find such code. The IETF Secretariat --_000_5C77D292692A481EB3F177C40130173Fciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6F9E1E2C4FA775489827FA0B7092ADD2@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi All,

We had some good discussions near the end of last year abou= t making it easier to find code related to drafts and RFCs. I posted this d= raft in an attempt to revive that discussion and hopefully make progress to= ward improving the current situation.
Comments, suggestions, pull requests welcome. 

Cheers,
Charles 

Begin forwarded message:

From: <internet-drafts@ietf.org>
Subject: New Version Notification = for draft-eckel-edm-find-code-00.txt
Date: July 9, 2021 at 3:08:16 PM PDT
To: Charles Eckel <eckelcu@cisco.com>


A new version of I-D, draft-eckel-edm-find-code-00.txt
has been successfully submitted by Charles Eckel and posted to the
IETF repository.

Name: draft-eckel-edm-= find-code
Revision: 0= 0
Title: Find Code Relat= ed to an Internet-Draft or RFC
Document date: 2021-07-09
Group: Individual Subm= ission
Pages: 8
URL:            https://www.ietf.org/archive/id/draft-eckel-edm-find-code-00.txt
Status:         https://dat= atracker.ietf.org/doc/draft-eckel-edm-find-code/
Html:           https://www.ietf.org/archive/id/draft-eckel-edm-find-code-00.html
Htmlized:       https://datatrack= er.ietf.org/doc/html/draft-eckel-edm-find-code


Abstract:
  Code related to existing IETF standards and ongoing standardiza= tion
  efforts may exist and be publicly accessible in many places. &n= bsp;This
  document provides a set of practices to make it easier to ident= ify
  and to find such code.




The IETF Secretariat



--_000_5C77D292692A481EB3F177C40130173Fciscocom_-- From nobody Mon Jul 12 09:04:29 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C94F3A20D9; Mon, 12 Jul 2021 09:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=apple.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 7ybifO1UTeLG; Mon, 12 Jul 2021 09:04:15 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp15.apple.com (rn-mailsvcp-ppex-lapp15.rno.apple.com [17.179.253.34]) (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 AD8BE3A2093; Mon, 12 Jul 2021 09:03:32 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp15.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp15.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 16CFuqBn021326; Mon, 12 Jul 2021 09:03:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=02ZuYbwhA2XJgwiMMxbMGzKEnZnbV/K9QbbJ+c0I3ss=; b=inWwTRv0pnLApSpehflQd4ZPJcb+nlxML4/jEzrVpgJFa/tkpplBDHw2qxE8bmadCste 3ikXUV3k7Iz4QhGzawGfiykxI5+kSMbMEzH0oGPTzosGzNsCjx8ZCBPJUWJN2pmqGh/c VnqHBDssfiqgwPskW3UVCRLJsi5tGwL+TK1brtiBo+HjnqAzkbmwKWjQKdMCoIKM0uZj k7ry9jSztBg6gYBpEVFWmGroU1A4kVARux0WUBQnH35TXFhU2lqK1ZFprkUjYnrAmBuU LxjMr5myjrnHkHFY21yU2v8eTKnR3R9qaXXEPRK2l3QwJGjzB+e5Oz7TiMdDOHlrCjQ2 xw== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp15.rno.apple.com with ESMTP id 39q94b5rma-11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Jul 2021 09:03:31 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QW500FBW39V6MH0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 12 Jul 2021 09:03:31 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QW50100034HJY00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 12 Jul 2021 09:03:31 -0700 (PDT) X-Va-A: X-Va-T-CD: 3094999fc392673f544a7f909d8a31a1 X-Va-E-CD: 235d74d6202314d9e0f65613e916048f X-Va-R-CD: ace8ba1b213359ab72cf39b4c1ef3aa8 X-Va-CD: 0 X-Va-ID: 883df2c9-0067-4882-a5df-333c5da594bc X-V-A: X-V-T-CD: 3094999fc392673f544a7f909d8a31a1 X-V-E-CD: 235d74d6202314d9e0f65613e916048f X-V-R-CD: ace8ba1b213359ab72cf39b4c1ef3aa8 X-V-CD: 0 X-V-ID: a52f69f0-51e7-4ead-b8f3-1e15a9266fc5 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-12_09:2021-07-12, 2021-07-12 signatures=0 Received: from smtpclient.apple (unknown [17.11.53.224]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QW500IF539VST00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 12 Jul 2021 09:03:31 -0700 (PDT) From: Tommy Pauly Message-id: <0B8621DE-3E9B-4422-AB7F-C91849739BB4@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_5FBE7C06-6598-42F5-8FF1-6F88AAA0C3E6" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3681.0.2.1.2\)) Date: Mon, 12 Jul 2021 09:03:30 -0700 In-reply-to: <5C77D292-692A-481E-B3F1-77C40130173F@cisco.com> Cc: "edm@iab.org" To: "Charles Eckel (eckelcu)" References: <162586849638.22752.11317942246363134121@ietfa.amsl.com> <5C77D292-692A-481E-B3F1-77C40130173F@cisco.com> X-Mailer: Apple Mail (2.3681.0.2.1.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-12_09:2021-07-12, 2021-07-12 signatures=0 Archived-At: Subject: Re: [Edm] New Version Notification for draft-eckel-edm-find-code-00.txt X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 16:04:27 -0000 --Apple-Mail=_5FBE7C06-6598-42F5-8FF1-6F88AAA0C3E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Charles, Thanks for writing this up! Would you be able to talk about this at an = upcoming call? Best, Tommy > On Jul 9, 2021, at 3:50 PM, Charles Eckel (eckelcu) = wrote: >=20 > Hi All, >=20 > We had some good discussions near the end of last year about making it = easier to find code related to drafts and RFCs. I posted this draft in = an attempt to revive that discussion and hopefully make progress toward = improving the current situation. > Comments, suggestions, pull requests welcome.=20 >=20 > Cheers, > Charles=20 >=20 >> Begin forwarded message: >>=20 >> From: > >> Subject: New Version Notification for = draft-eckel-edm-find-code-00.txt >> Date: July 9, 2021 at 3:08:16 PM PDT >> To: Charles Eckel > >>=20 >>=20 >> A new version of I-D, draft-eckel-edm-find-code-00.txt >> has been successfully submitted by Charles Eckel and posted to the >> IETF repository. >>=20 >> Name: draft-eckel-edm-find-code >> Revision: 00 >> Title: Find Code Related to an Internet-Draft or RFC >> Document date: 2021-07-09 >> Group: Individual Submission >> Pages: 8 >> URL: = https://www.ietf.org/archive/id/draft-eckel-edm-find-code-00.txt = >> Status: = https://datatracker.ietf.org/doc/draft-eckel-edm-find-code/ = >> Html: = https://www.ietf.org/archive/id/draft-eckel-edm-find-code-00.html = >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-eckel-edm-find-code = >>=20 >>=20 >> Abstract: >> Code related to existing IETF standards and ongoing standardization >> efforts may exist and be publicly accessible in many places. This >> document provides a set of practices to make it easier to identify >> and to find such code. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >=20 > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm --Apple-Mail=_5FBE7C06-6598-42F5-8FF1-6F88AAA0C3E6 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Charles,

Thanks for writing this up! Would you be able to talk about this at an upcoming call?

Best,
Tommy

On Jul 9, 2021, at 3:50 PM, Charles Eckel (eckelcu) <eckelcu=40cisco.com@dmarc.ietf.org> wrote:

Hi All,

We had some good discussions near the end of last year about making it easier to find code related to drafts and RFCs. I posted this draft in an attempt to revive that discussion and hopefully make progress toward improving the current situation.
Comments, suggestions, pull requests welcome. 

Cheers,
Charles 

Begin forwarded message:

Subject: New Version Notification for draft-eckel-edm-find-code-00.txt
Date: July 9, 2021 at 3:08:16 PM PDT
To: Charles Eckel <eckelcu@cisco.com>


A new version of I-D, draft-eckel-edm-find-code-00.txt
has been successfully submitted by Charles Eckel and posted to the
IETF repository.

Name: draft-eckel-edm-find-code
Revision: 00
Title: Find Code Related to an Internet-Draft or RFC
Document date: 2021-07-09
Group: Individual Submission
Pages: 8
URL:            https://www.ietf.org/archive/id/draft-eckel-edm-find-code-00.txt
Status:         https://datatracker.ietf.org/doc/draft-eckel-edm-find-code/
Html:           https://www.ietf.org/archive/id/draft-eckel-edm-find-code-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-eckel-edm-find-code


Abstract:
  Code related to existing IETF standards and ongoing standardization
  efforts may exist and be publicly accessible in many places.  This
  document provides a set of practices to make it easier to identify
  and to find such code.




The IETF Secretariat



--
Edm mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm

--Apple-Mail=_5FBE7C06-6598-42F5-8FF1-6F88AAA0C3E6-- From nobody Wed Jul 14 07:20:11 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1003A1A1F for ; Wed, 14 Jul 2021 07:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=apple.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 QdKQSqSKVnl3 for ; Wed, 14 Jul 2021 07:20:04 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.rno.apple.com [17.179.253.49]) (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 1AE583A1A1D for ; Wed, 14 Jul 2021 07:20:03 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 16EECj0c026760 for ; Wed, 14 Jul 2021 07:20:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=7b149rjNTum6WlE5tjZH4fKay4r7eMxuK0kILieIxwQ=; b=k2adtnPxwWyEUU8KrabX84LNmZAH+qbL7/NqRUbLdtpXVgOwKUK4DB5sb3qcENRQH/Fj qwx9UBcqnzF36f8dSMFeJO2a+/6IRD4YIe3fGWUVYt0UMymfgRjiAPb73mQVIkVKHBAy cEJbZ1utKa4o2pUhx5LvjTgQ+pqleIoUXhNgkbuGXYgU9FE7nYiyI1Qat6FKwc6puRY1 ekcV4ZT7jEN2QNG3+hBlxpKjRjIFRUbzKLq/j2ZsqKQa6cWCxMXUXa+Rqj7jSuEisYR1 95fHo4hVS3947M8QQzbn/TR9pegMRcIdriFhbX13bbku0kUhRJeKaqHIyqt7WyJ7weIF kA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 39q9utfgtb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 14 Jul 2021 07:20:03 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QW800XHMNTFVWB0@rn-mailsvcp-mta-lapp04.rno.apple.com> for edm@iab.org; Wed, 14 Jul 2021 07:20:03 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QW800D00NR4IB00@rn-mailsvcp-mmp-lapp03.rno.apple.com> for edm@iab.org; Wed, 14 Jul 2021 07:20:03 -0700 (PDT) X-Va-A: X-Va-T-CD: 1af8597529a643bc4f908cf463616f6c X-Va-E-CD: df11914010713406303a1f5444902650 X-Va-R-CD: 0cb3ef7d81061cd214ddb42bf5e08f34 X-Va-CD: 0 X-Va-ID: 8f54ee12-edee-4bb0-868c-5ea80a67873c X-V-A: X-V-T-CD: 1af8597529a643bc4f908cf463616f6c X-V-E-CD: df11914010713406303a1f5444902650 X-V-R-CD: 0cb3ef7d81061cd214ddb42bf5e08f34 X-V-CD: 0 X-V-ID: 217fb9d0-bebf-4f36-91a8-ba98e1c6eb55 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-14_07:2021-07-14, 2021-07-14 signatures=0 Received: from smtpclient.apple (unknown [17.234.86.153]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QW80057SNTEAM00@rn-mailsvcp-mmp-lapp03.rno.apple.com> for edm@iab.org; Wed, 14 Jul 2021 07:20:02 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_4CBB94F6-EE4D-4F8D-B413-6ED01D03655B" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3681.0.2.1.2\)) Date: Wed, 14 Jul 2021 07:20:02 -0700 References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> To: edm@iab.org In-reply-to: <162626887655.14379.5438309391409890693@ietfa.amsl.com> Message-id: <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> X-Mailer: Apple Mail (2.3681.0.2.1.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-14_07:2021-07-14, 2021-07-14 signatures=0 Archived-At: Subject: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 14:20:10 -0000 --Apple-Mail=_4CBB94F6-EE4D-4F8D-B413-6ED01D03655B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello EDM, We=E2=80=99ve posted a new version of the use-it-or-lose-it draft, which = has been discussed in several of our past calls. The IAB would like to get this document progressed to be published as an = RFC between IETF 111 and IETF 112. Please take a look at the current = version, and provide your reviews either here by email, or on the GitHub = (https://github.com/intarchboard/draft-use-it-or-lose-it/issues = ). Best, Tommy > On Jul 14, 2021, at 6:21 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-iab-use-it-or-lose-it-01.txt > has been successfully submitted by Cindy Morgan and posted to the > IETF repository. >=20 > Name: draft-iab-use-it-or-lose-it > Revision: 01 > Title: Long-term Viability of Protocol Extension = Mechanisms > Document date: 2021-07-14 > Group: iab > Pages: 19 > URL: = https://www.ietf.org/archive/id/draft-iab-use-it-or-lose-it-01.txt > Status: = https://datatracker.ietf.org/doc/draft-iab-use-it-or-lose-it/ > Html: = https://www.ietf.org/archive/id/draft-iab-use-it-or-lose-it-01.html > Htmlized: = https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-iab-use-it-or-lose-it-01 >=20 > Abstract: > The ability to change protocols depends on exercising the extension > and version negotiation mechanisms that support change. Protocols > that don't use these mechanisms can find it difficult and costly to > deploy changes. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_4CBB94F6-EE4D-4F8D-B413-6ED01D03655B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= EDM,

We=E2=80=99ve = posted a new version of the use-it-or-lose-it draft, which has been = discussed in several of our past calls.

The IAB would like to get this document = progressed to be published as an RFC between IETF 111 and IETF 112. = Please take a look at the current version, and provide your reviews = either here by email, or on the GitHub (https://github.com/intarchboard/draft-use-it-or-lose-it/issues<= /a>).

Best,
Tommy

On Jul = 14, 2021, at 6:21 AM, internet-drafts@ietf.org wrote:


A new version of I-D, draft-iab-use-it-or-lose-it-01.txt
has been successfully submitted by Cindy Morgan and posted to = the
IETF repository.

Name: = draft-iab-use-it-or-lose-it
Revision: 01
Title:= = Long-term Viability of Protocol Extension Mechanisms
Document date: 2021-07-14
Group:= = iab
Pages: 19
URL: =            https://www.ietf.org/archive/id/draft-iab-use-it-or-lose-it-01.= txt
Status: =         https://datatracker.ietf.org/doc/draft-iab-use-it-or-lose-it/
Html: =           https://www.ietf.org/archive/id/draft-iab-use-it-or-lose-it-01.= html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-= it
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-iab-use-it-or-lose-it= -01

Abstract:
=   The ability to change protocols depends on exercising the = extension
  and version negotiation mechanisms = that support change.  Protocols
  that = don't use these mechanisms can find it difficult and costly to
  deploy changes.




The IETF Secretariat



= --Apple-Mail=_4CBB94F6-EE4D-4F8D-B413-6ED01D03655B-- From nobody Wed Jul 14 16:53:35 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F823A0E3E for ; Wed, 14 Jul 2021 16:53:33 -0700 (PDT) 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 VTlcvPd_k62Q for ; Wed, 14 Jul 2021 16:53:29 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 8C0A13A0E3B for ; Wed, 14 Jul 2021 16:53:29 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id o201so3474408pfd.1 for ; Wed, 14 Jul 2021 16:53:29 -0700 (PDT) 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=1XUFfPXVR1321o/UONIZQSwVqKR9M+nVwLOGXHMGMA4=; b=JcUizDneRk38Sj2pOAlPWPl/CtrgO9Xxv2JhEMi4R51VQZkwUNhjvPZUZQNdQrZ4tK 18+w724Zb6LBkcVClVgZdlpfS/y/WsjxFmKkaJTG3NGXjoM1b0ev7zqwBT1o3aCwG2gE lgp3Ml/hV5TPoECN2aukLHIoRR9vXEaye8cFjdNqYPNVejF5Brc15FCN/4n8xLTS7J9t jZwktiEeTfV0dNyzWZbeyHIKViIVEJXvAqhN7ip5TA1FCkO9ZOtNqjUY5kR3cvc39Ky9 8TeQPiGiJAJRNYaTuQD+GWN7YQSpG9Blp+GuepT3rcFlwpyj5a2awwoSfCJu6/CCMcVa yNpw== 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=1XUFfPXVR1321o/UONIZQSwVqKR9M+nVwLOGXHMGMA4=; b=opqALaeWoJCBRK7iCPcDshA79lJu0/lIQ6LsZeXRKCqzvG2DoMg1RYcOj3jPKSegvM QZ5PcTGkBX/jLj+dcVw/TeKZDcyQiDUOibLUEWAkrmDVR8cJrbjmsLMIgM3tc8Q2a6dU 5+fDu7aVNtgPONjD57fdzcXhiO59AXCiVJeu1ZqDuyKKDY8TJwtqqT8PrkwEEwcsh2Gy Xx6ZIVCHKhBZ7fuNjMrK7Zre6w8Jh6CVb0fzoHxvoS8WlJdXSe8302womPvm47rEKxfm iQ/GVzTeryVenYMUpTPrdvysoxeZtgFVZnUktfrZ3MqLLKNld4WNpM0/tLog0S2RFGN4 Xh1w== X-Gm-Message-State: AOAM531LCvmf7KGDSGbU7VL2hndIk3MrmENupmC3p2MgpccraYXReLlI y5zO8/RiktgvO9X3vPuUZmLERYzM9YYMjuzvXEJlw3t7+uA= X-Google-Smtp-Source: ABdhPJzHreowaqEFATEfEdtDoUFENEQJXAPsDSuT5o5cxl4bBcWOwjbNGLgzZEkRC3CchQ6lDtKWVCdW7bKiEf5vOYs= X-Received: by 2002:a05:6a00:bd6:b029:329:9432:9660 with SMTP id x22-20020a056a000bd6b029032994329660mr587385pfu.22.1626306807317; Wed, 14 Jul 2021 16:53:27 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Wed, 14 Jul 2021 16:53:16 -0700 Message-ID: To: Electronic Dance Music Content-Type: multipart/alternative; boundary="0000000000008bc90b05c71e0f8f" Archived-At: Subject: [Edm] Scheduling our next EDM call, week after IETF 111 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 23:53:34 -0000 --0000000000008bc90b05c71e0f8f Content-Type: text/plain; charset="UTF-8" Hi EDM enthusiasts, We'd like to schedule an EDM meeting for the first week of August, which is the week right after IETF 111. The meeting will be virtual (expect a video conference link in a followup email). We plan on discussing - draft-iab-use-it-or-lose-it - draft-eckel-edm-find-code - how coordination between implementations can help with EDM If you're interested in joining, please send your availability in this Doodle: https://doodle.com/poll/4qizgadaxnsg22bs If you have other agenda items you'd like to discuss, please reply here. Thanks, David & Tommy --0000000000008bc90b05c71e0f8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi EDM enthusiasts,

We'd like to sc= hedule an EDM meeting for the first week of August, which is the week right= after IETF 111. The meeting will be virtual (expect a video conference lin= k in a followup=C2=A0email).

We plan on discussing=
- how coordination between implementati= ons=C2=A0can help with EDM

If you're intereste= d in joining, please send your availability in this Doodle:

If you have other agenda ite= ms you'd like to discuss, please reply here.

T= hanks,
David & Tommy
--0000000000008bc90b05c71e0f8f-- From nobody Thu Jul 15 08:47:16 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006CA3A0F02 for ; Thu, 15 Jul 2021 08:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1] 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 PJD69YO_P0L0 for ; Thu, 15 Jul 2021 08:47:00 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A4A3A0EBF for ; Thu, 15 Jul 2021 08:46:59 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 30ADE54804C; Thu, 15 Jul 2021 17:46:49 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2852D4E7A54; Thu, 15 Jul 2021 17:46:49 +0200 (CEST) Date: Thu, 15 Jul 2021 17:46:49 +0200 From: Toerless Eckert To: Tommy Pauly Cc: edm@iab.org Message-ID: <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 15:47:14 -0000 Thanks for the work Tommy Some high level comment before inlining my more detailled feedback. The document discusses several great examples, but it then inlines the discussion and proposed conclusions from them. It would help a lot if the document was structured such that examples/discussion are separated from structural restatement of problems and guidelines. For the structural part: I think it would be good to write that the problems an solutions likely fall all into three high level categories: a) p2p protocol extension considerations. b) 3 or more party protocol extension considerations (including middleboxes as supported parties). c) 2 or more party protocol considerations plus undesirable middleboxes. Separating b) and c) is IMHO most important, For example, the example of the IP version codepoint not "working" when it was needed is argued by you as a bad extension point, where in my opinion, it is an unavoidable result from c) and the fact that you can-not, want-not fight against them (enryption). My proof point of course is that the very same problem would happen to the ethernet protocol field (which you cite as th solution), if/when some middlebox would do the same to it. Aka: judgements can not easily assume that all problems have the sam constraints/problems. Jut because it maybe possible to build better extension points for one type of problems doesn't mean the same can be done for other problems. And just because that means that other extension points will continue to be more problematic doesn't meant they can or should be avoided. The other high-level suggestion is that at least in my opinion there is more that could be written about reasons. IMHO: The deeper the extension point is within a protocol, and the more complex the protocols starte machienry reaction to unsupported extensions hs to be in the state machinery, the more difficult it is to make sure it will work correctly when needed. Of course, the most easy case is when you have extensible data structures signalled and some parts can just be ignored, but that is not always the semantic required. > --- > title: "Long-term Viability of Protocol Extension Mechanisms" > abbrev: Use It Or Lose It > docname: draft-iab-use-it-or-lose-it-latest > category: info > ipr: trust200902 > > stand_alone: yes > pi: [toc, sortrefs, symrefs, docmapping] > > author: > - > ins: M. Thomson > name: Martin Thomson > org: Mozilla > email: mt@lowentropy.net > - > ins: T. Pauly > name: Tommy Pauly > org: Apple > email: tpauly@apple.com > > normative: > > > informative: > HASH: > title: "Deploying a New Hash Algorithm" > author: > - > ins: S. Bellovin > name: Steven M. Bellovin > - > ins: E. Rescorla > name: Eric M. Rescorla > date: 2006 > target: "https://www.cs.columbia.edu/~smb/papers/new-hash.pdf" > seriesinfo: "Proceedings of NDSS '06" > > SNI: > title: "Accepting that other SNI name types will never work" > author: > - > ins: A. Langley > name: Adam Langley > date: 2016-03-03 > target: "https://mailarchive.ietf.org/arch/msg/tls/1t79gzNItZd71DwwoaqcQQ_4Yxc" > > INTOLERANCE: > title: "Re: [TLS] Thoughts on Version Intolerance" > author: > - > ins: H. Kario > name: Hubert Kario > date: 2016-07-20 > target: "https://mailarchive.ietf.org/arch/msg/tls/bOJ2JQc3HjAHFFWCiNTIb0JuMZc" > > RIPE-99: > title: "RIPE NCC and Duke University BGP Experiment" > author: > - > ins: E. Romijn > name: Erik Romijn > date: 2010-08-27 > target: https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment/ > > DNSFLAGDAY: > title: "DNS Flag Day 2019" > date: 2019-05 > target: https://dnsflagday.net/2019/ > > HTTP11: I-D.ietf-httpbis-messaging > > > > --- abstract > > The ability to change protocols depends on exercising the extension and version > negotiation mechanisms that support change. Protocols that don't use these > mechanisms can find it difficult and costly to deploy changes. qualify what "use" means - specifications of extensions, implementations of such extensions, active deployments of such extensions. rephrase second part of sentence to introduce the "loose it" part of the documents catch phrase. > --- middle > > # Introduction > > A successful protocol {{?SUCCESS=RFC5218}} needs to change in ways that allow it > to continue to fulfill the needs of its users. New use cases, conditions and > constraints on the deployment of a protocol can render a protocol that does not > change obsolete. [mayor] Your text is overall very assertive, which i think will just challenge everybody with free cycles to comment to find examples of when the claimed is not true. "may need to change", "may render" might aleviate this concern. more fundamentally, this paragraph would only be true if the "New" stuff would completely replace the old stuff, and that is most likely the least common condition. There is "New" stuff, but there more likely is also the "Old" stuff (use-cases, conditions, constrints, deployments). In this more likely case, the protocol will not become obsolete, but it may lead to a multitute of slightly similar protocols for different use-cases. Wort yet, it might lead to often unresolavlbe problems of how to run these multiple protocols in parallel when a deployment would require this. > Usage patterns and requirements for a protocol shift over time. In response, More inclusive: s/shift/evolve/ > implementations might adjust usage patterns within the constraints of the > protocol, the protocol could be extended, or a replacement protocol might be > developed. Experience with Internet-scale protocol deployment shows that each > option comes with different costs. {{?TRANSITIONS=RFC8170}} examines the > problem of protocol evolution more broadly. > > This document examines the specific conditions that determine whether protocol > maintainers have the ability to design and deploy new or modified protocols. Would it be appropriate to say he document attempts to provide guidance ? If it does, sayin so would be useful. The way its written right now it sounds more like an analysis from an uninterested bystander which i don't think it intends to be. If the document intends to guve guidance, consider whether BCP might be a better goal than inf. > {{implementations}} highlights some historical examples of difficulties in > transitions to new protocol features. {{use-it}} argues that ossified protocols > are more difficult to update and successful protocols make frequent use of new > extensions and code-points. {{use}} and {{other}} outline several strategies > that might aid in ensuring that protocol changes remain possible over time. > > The experience that informs this document is predominantly at "higher" layers of > the network stack, in protocols that operate at very large scale and > Internet-scale applications. It is possible that these conclusions are less > applicable to protocol deployments that have less scale and diversity, or > operate under different constraints. > > > # Imperfect Implementations Limit Protocol Evolution {#implementations} > > It can be extremely difficult to deploy a change to a protocol if there are > bugs in implementations with which the new deployment needs to interoperate. > Bugs in how new codepoints or extensions are handled often mean that endpoints > will react poorly to the use of extension mechanisms. This can manifest > as abrupt termination of sessions, errors, crashes, or disappearances of > endpoints and timeouts. I have often seen he term "forward compatibility" be used to characterize this problem. Feel free to use the term. I also think that "bugs in how ... handled" is blaming only one side (coders), and i can think of at least one equl if not worse community: spec writers. handling of extension points i easily underspecified and may actually be a challenging part of the specification to write bulletproof. > Interoperability with other implementations is usually highly valued, so > deploying mechanisms that trigger adverse reactions can be untenable. How about all those security protocols that simply silently stop when anything unexpected or undesirable happens, under the rule that any additional information/diagnostics would help attackers. In my experience with security systems (across different implementations), that has been the biggest challenge. > Where > interoperability is a competitive advantage, this is true even if the negative > reactions happen infrequently or only under relatively rare conditions. In the prior pargraph you ue "adverse reaction", here you use "negative reaction". Would suggest you pick one term and maybe also explain it a bit. Right now i can only think of puking protocol implementations reading those terms. Which is fun, but something more practical would be more useful for the text. For example explicit diagnostics of a identifyable and traceable error condition to the user instead of to the user unexplainable misbehavior of the system ? > Deploying a change to a protocol could require implementations fix a > substantial proportion of the bugs that the change exposes. This can > involve a difficult process that includes identifying the cause of > these errors, finding the responsible implementation(s), coordinating a > bug fix and release plan, contacting users and/or the operator of affected > services, and waiting for the fix to be deployed. I fear that this explanation does not well explain the root problem to the reader not familiar with the problem already. And even i am guessing if what i think the problem is also what you think. If it is, then maybe a text like mine here would help: Assume a protocol is deployed by a large user community utilizing different implementations. Some subset of users (group A) should/want to get a new protocol feature and are happy for their systems to be updated to get it. And this feature works fine amongst group A members. But when they now communicate with non group A members (lets call this group B, which may be a much larger number than group A), not only is there no new benefit of the new feature, but instead the new feature cases interoperability problems whose cause is not the new feature itself, but bugs or bad specification of he implemenations used by group B. Now, how do you even persuade group B to be interested in getting that problem fixed given that their only benefit is to re-establish the old status-quo of being able to communicate with group A. And in many cases, those implementations can not even be upgraded because their vendor went out of busines. > Given the effort involved in fixing problems, the existence of these sorts of or often impossibility > bugs can outright prevent the deployment of some types of protocol changes, > especially for protocols involving multiple parties or that are considered > critical infrastructure (e.g., IP, BGP, DNS, or TLS). It could even be > necessary to come up with a new protocol design that uses a different method to > achieve the same result. > > The set of interoperable features in a protocol is often the subset of its > features that have some value to those implementing and deploying the protocol. > It is not always the case that future extensibility is in that set. Unfortunately, IETF has stopped writing RFCs like RFC1025. Test-suites, Protocol Implemenation Compliance Specifications or whatever you want to call them. Every time i raise the point i hear just answers that sound like 'we've given up' / 'not our job'. > ## Good Protocol Design is Not Itself Sufficient {#not-good-enough} > > It is often argued that the careful design of a protocol extension point or > version negotiation capability is critical to the freedom that it ultimately > offers. > > RFC 6709 {{?EXTENSIBILITY=RFC6709}} contains a great deal of well-considered > advice on designing for extension. It includes the following advice: > > > This means that, to be useful, a protocol version-negotiation mechanism > should be simple enough that it can reasonably be assumed that all the > implementers of the first protocol version at least managed to implement the > version-negotiation mechanism correctly. > > This has proven to be insufficient in practice. Many protocols have evidence of > imperfect implementation of critical mechanisms of this sort. Mechanisms that > aren't used are the ones that fail most often. The same paragraph from RFC > 6709 acknowledges the existence of this problem, but does not offer any remedy: > > > The nature of protocol version-negotiation mechanisms is that, by definition, > they don't get widespread real-world testing until *after* the base protocol > has been deployed for a while, and its deficiencies have become evident. See above. IMHO you should to mention stuff pike RFC1025, test-suites, PICS as the methods used in other industries (just not IETF) for this. > Indeed, basic interoperability is considered critical early in the deployment of > a protocol. A desire to deploy can result in an engineering practice that > values simplicity, which could result in deferring implementation of version > negotiation and extension mechanisms. This leads to these mechanisms being > particularly affected by this problem. There is one big joker card you can and should pull here: Security. Whatever causes interop problems on extension points is likely also some form of attack vector that in a non insignificant subset of cases could also be exploited, even by third parties. test-suites that include all such , even illegal protocol options re in scurity circles well understood to be crucial for system protection/assessment. > ## Disuse Can Hide Problems {#disuse} > > There are many examples of extension points in protocols that have been either > completely unused, or their use was so infrequent that they could no longer be > relied upon to function correctly. > > > ### TLS > > Transport Layer Security (TLS) {{?TLS12=RFC5246}} provides examples of where a > design that is objectively sound fails when incorrectly implemented. TLS > provides examples of failures in protocol version negotiation and extensibility. Do you think a better, more explanatory spec could have help to reduce the amont of incorrect implementations ? Of course, not in hindishgt (although that would still be good for a -bis), but when writing the original RFC. Aka: if you agree with me that better specs can lead to fewer bugs1 i would appreciate anything you can write about that. > > Version negotiation in TLS 1.2 and earlier uses the "Highest mutually supported > version (HMSV)" scheme exactly as it is described in {{?EXTENSIBILITY}}. > However, clients are unable to advertise a new version without causing a > non-trivial proportions of sessions to fail due to bugs in server and middlebox > implementations. Ok, lets forget middleboxes for a moment. For those server implementations that you claim have bugs: Does each instance of such a "bug" have one or more clearly identifyable MUST statements or otherwise clearly identified REQUIRED element(s) of the spec ? If not, hen it is not an implemntation bug but a spec shortcoming. > Intolerance to new TLS versions is so severe {{INTOLERANCE}} that TLS 1.3 > {{?TLS13=RFC8446}} has abandoned HMSV version negotiation for a new mechanism. please ad reference to TLS 1.3 section describing that new mechanism. > > The server name indication (SNI) {{?TLS-EXT=RFC6066}} in TLS is another > excellent example of the failure of a well-designed extensibility point. SNI > uses the same technique for extension that is used with considerable success in > other parts of the TLS protocol. The original design of SNI includes the > ability to include multiple names of different types. > > What is telling in this case is that SNI was defined with just one type of name: ^^^^^^^^^^^^^^^^^ > a domain name. No other type has ever been standardized, though several have > been proposed. Not sure what the term means to imply. I uess a text like this: When you define an extension point that should support multiple alternative options, experience has shown that it is less likely to be implemented at all or without bugs if only one such option within the protocols base spec or in time before the firsst round of protocol implementations is finished. > Despite an otherwise exemplary design, SNI is so inconsistently ^^^^^^^^^^^^^^ > implemented that any hope for using the extension point it defines has been > abandoned {{SNI}}. do you mean rarely ? If its really inconsistent, then it would be ineresting to see a short description as to how the difference in implementations does/do cause problems. > Even where extension points have multiple valid values, if the set of permitted > values does not change over time, there is still a risk that new values are not > tolerated by existing implementations. If the set of values for a particular > field remains fixed over a long period, some implementations might not correctly > handle a new value when it is introduced. For example, implementations of TLS > broke when new values of the signature_algorithms extension were introduced. > > > ### DNS > > Ossified DNS code bases and systems resulted in fears that new Resource Record > Codes (RRCodes) would take years of software propagation before new RRCodes > could be used. This was not fear but proven experience. "Ossified..systems" is maybe unclear. Ossified deployments might be an easy textual fix, but it would be great to further elaborate on the fact that its not about the software itself, but primarily about the operationally federated international nature of the deployment why it took so long. In these type of systems, extensibility can reasonably only be used agile if it does not require code upgrades but at most configuration upgrade in as few as possible places. That was what RFC3597 enabled. Here i would take the opposite stance from above and ask this is reverted from "fear" to actual "experience". But its again not only the ode bassis, but in this case also the operational processes of deployments. "just because a new version of the code basis exists for 10 years doesn't mean we want to deploy it". > The result for a long time was heavily overloaded use of the TXT > record, such as in the Sender Policy Framework {{?SPF=RFC7208}}. It wasn't > until after the standard mechanism for dealing with new RRCodes > {{?RRTYPE=RFC3597}} was considered widely deployed that new RRCodes can be > safely created and used. > > > ### SNMP > > As a counter example, the first version of the Simple Network Management > Protocol (SNMP) {{?SNMPv1=RFC1157}} defines that unparseable or unauthenticated > messages are simply discarded without response: > > > It then verifies the version number of the SNMP message. If there is a > mismatch, it discards the datagram and performs no further actions. > > When SNMP versions 2, 2c and 3 came along, older agents did exactly what the > protocol specifies. Deployment of new versions was likely successful because > the handling of newer versions was both clear and simple. I am just imagining replacing SNMP with IP (v4/v6) and wonder if the same conclusion would make sense. I just don't think its a "counter" example, because the goals of the previous example of course where those of extensions, whereas here we're really talking about completely incompatible protocols that are just multiplexed on a version instead of a protocol number. Aka: whats the message of this section ? Creating different, completely incompatible protocols is the easiest protocol evolution ? I guess thats what people might have thought when they decided on IPv6, but 20 years laer we have >= 24 IPv4/IPv6 interop mechanisms: https://en.wikipedia.org/wiki/IPv6_transition_mechanism Aka: try to formulate some more useful conclusions out of the example. > ### HTTP > > HTTP has a number of very effective extension points in addition to the > aforementioned header fields. It also has some examples of extension points > that are so rarely used that it is possible that they are not at all usable. > > Extension points in HTTP that might be unwise to use include the extension point > on each chunk in the chunked transfer coding {{Section 7.1 of HTTP11}}, the > ability to use transfer codings other than the chunked coding, and the range > unit in a range request {{Section 14 of HTTP}}. > > > ### IPv4 > > Codepoints that are reserved for future use can be especially problematic. > Reserving codepoints without attributing semantics to their use can result in > diverse or conflicting semantics being attributed without any hope of > interoperability. An example of this is the "class E" address space in IPv4 > {{?RFC0988}}, which was reserved without assigning any semantics. Adress prefixes are not called code-points AFAIK, reads at least weird to me. IMHO it is not about not attributing semantic to extension points but underspecifying what to do. Here is how i would suggest to rewrite this paragraph: [RFC-editor node: Yes, we want to keep the obsoleted by RFC1112 reference RFC0988 because we want to have an earliest time of spec reference] Extension points that are reserved for future use can become problematic when their behavior is underspecified. {{?RFC0988}} introduced the IP Multicast semantic for the "class E" adress space in IPv4, which was previously reserved in {{?RFC900}} and not mentioned in {{?RFC791}}, resulting in the underspecified use of class E addresses for the IP unicast semantic. A more future proof version of RFC791 today should use normative language prohibiting forwarding of packets by its rules whn they have source an/or destination addresses from a reserved prefix. [ A bit off-topic: I was actually deploying IP multicast in 1989 on the Internet but i am not aware of this actually having been a real problem, so the example is somewhat theoretical to me. Maybe somene else remembers differently. However, we did have a real significant problem as late as 2005 (if i remember the timeline correctly), and that was that illegal packets with a unicast destination address and a class E source address could be sent to some router adress, which would turn this around into for example an ICMP port unreachable reply sent back to the source address, which resulted in some really bad DoS attacks when you knew an IP multicast address with many receivers active. So, now i am trying to figure out if/how that problem could have been stopped through better specs, but: RFC1112 is FULL of sentences highlighting that class E addresses in the source address field are illegal AND NOT IP multicast. Of course, the problem happened because of modular software in routers: The HOST stack in routers had not been updated to IP multicast (and/or implementers where lazy), and it was the host stack creating the ICMP port unreachable. So, actually, i am finally trying to get rfc1112 -bis'ed https://datatracker.ietf.org/doc/draft-eckert-pim-rfc1112bis/ And my best thinking right now is that we might want to make that rfc1112bis be also an update to rfc791 (and rfc8200) with exactly the type of above refinement that packets with an IP multicast source address are illegal and must be discarded. Even if the host stack does otherwise not implement IP multicast (because the forwarding module may). ] > For protocols that can use negotiation to attribute semantics to codepoints, it > is possible that unused codepoints can be reclaimed for active use, though this > requires that the negotiation include all protocol participants. For something > as fundamental as addressing, negotiation is difficult or even impossible, as > all nodes on the network path plus potential alternative paths would need to be > involved. All your Internet communication is likely running primarily across multiple MPLS/IP networks, and the semantic of the mayority of MPLS label is solely based on eventual consistency control plane protocols (IGPs/BGP). Arguably, IP unicast routing is not too different but the amount of different semantics is smaller than in MPLS (except when using SRv6 which has even more different adress semantics). Aka: expect for thss paragraph to be questioned by anybody who like me thinks about the reality of the Internet. If you have a very specific example you know is broken, lets start from that and maybe expand into some better generic conclusion. How about: 3 party systems are more difficult than 2-party system. more than 3 party systems are terrible difficult. > ## Multi-Party Interactions and Middleboxes {#middleboxes} > > Even the most superficially simple protocols can often involve more actors than > is immediately apparent. A two-party protocol has two ends, but even at the > endpoints of an interaction, protocol elements can be passed on to other > entities in ways that can affect protocol operation. > > One of the key challenges in deploying new features is ensuring compatibility > with all actors that could be involved in the protocol. If i think about my above multicast example, the problem is as you said across multiple actors (forwarder, host stack), but also across multiple protocols IP/IP-multicast, ICMP. So maybe s/in the protocol/in the complete, likely multi-protocol communications/ > Protocols deployed without active measures against intermediation will tend to > become intermediated over time, as network operators deploy middleboxes to > perform some function on traffic {{?PATH-SIGNALS=RFC8588}}. Is that the right RFC number: 8588 ? > In particular, one > of the consequences of an unencrypted protocol is that any element on path can > interact with the protocol. The problem is a bit that you do not provide a definition of "interact with the protocol". In its generality, the sentence ignores mentioning that authentication removes everything i would call "interact with the protcol", aka: modify protocol elements. Additional encrypion is only necessary to protection against interactions with the packet, such as filtering or protocol aware routing. Suggest: In particular, one consequences is that any element on path can interact with any unauthenticated protocol element. Furthermore, for protection against protocol aware packet processing such as filtering, encryption is required. > For example, HTTP was specifically designed with > intermediation in mind, transparent proxies {{?HTTP=I-D.ietf-httpbis-semantics}} > are not only possible but sometimes advantageous, despite some significant > downsides. Consequently, transparent proxies for cleartext HTTP are commonplace. If there is some reference for the downsides, that would be lovely. > The DNS protocol was designed with intermediation in mind through its use of > caching recursive resolvers {{?DNS=RFC1034}}. What was less anticipated was the > forced spoofing of DNS records by many middle-boxes such as those that inject > authentication or pay-wall mechanisms as an authentication and authorization > check, which are now prevalent in hotels, coffee shops and business networks. > > Middleboxes are also protocol participants, to the degree that they are able > to observe and act in ways that affect the protocol. The degree to which a > middlebox participates varies from the basic functions that a router performs > to full participation. For example, a SIP back-to-back user agent (B2BUA) > {{?B2BUA=RFC7092}} can be very deeply involved in the SIP protocol. Alas, i have not read up on the IEF curriculum about middleboxes, but i would suspect the term is primarily used for elements that are neither considered in the design of the protocol, nor operating at a higher layer than the protocol. I think a SIP b2b UA is either of the two (considered as part of the design or operating at a higher layer), so maybe another example for a more clearly middlebox function might be beter. The best (positive) examples of course are TCP accelerators via transparent TCP proxies, which AFAIK are still commonplace in many, especially lowr WAN-speed edge routers. Alas, this is all non-IEF standards based. We had some IRTF? BOF where researchers wanted to start spec'ing something of this out recently. Maybe the best reference for middleboxes and even specs for them are NAT middleboxs because NAT was clearly not part of the design and still is considered by many in the IETF to be the enemy https://datatracker.ietf.org/wg/behave/documents/ > This phenomenon appears at all layers of the protocol stack, even when > protocols are not designed with middlebox participation in mind. "even" ? Isn't this "primarily" > TCP's > {{?TCP=RFC0793}} extension points have been rendered difficult to use, largely > due to middlebox interactions, as experience with Multipath TCP > {{?MPTCP=RFC6824}} and Fast Open {{?TFO=RFC7413}} has shown. suggest rephrase: as documented for Multipath TCP in {{?MPTCP=RFC6824}} and for TCP Fast Open in {{?TFO=RFC7413}}. aka: original sentence makes it sounds references are just pointers to the functions but not the middlebox impact onto them. > IP's version field > was rendered useless when encapsulated over Ethernet, requring a new ethertype > with IPv6 {{?RFC2464}}, due in part to layer 2 devices making > version-independent assumptions about the structure of the IPv4 header. The > announcements of new optional transitive attributes in BGP caused significant > routing instability {{RIPE-99}}. > > By increasing the number of different actors involved in any single protocol > exchange, the number of potential implementation bugs that a deployment needs to > contend with also increases. s/potential/likely/ ? s/bugs/bugs and missing features/ s/deployments need to content/implementers need to waste time building workarounds for/ > In particular, incompatible changes to a protocol > that might be negotiated between endpoints in ignorance of the presence of a > middlebox can result in a middlebox interfering in negative and > unexpected ways. > > Unfortunately, middleboxes can considerably increase the difficulty of > deploying new versions or other changes to a protocol. I think it is somewhat difficult to ignore the elephant in the room, which is that a lot of middleboxes do perform security functions, and that there is a significant market demand for those and the counter meaures against middle boxes can make those self-defending protocols undeplyable and/or may ultimately create more negative problems at even higher layers. Aka: would be good to have some section tackling this. > # Retaining Viable Protocol Evolution Mechanisms {#use-it} > > The design of a protocol for extensibility and eventual replacement > {{?EXTENSIBILITY}} does not guarantee the ability to exercise those options. > The set of features that enable future evolution need to be interoperable in the > first implementations and deployments of the protocol. Implementations of s/interoperable/validated for interoperability/ > mechanisms that support evolution is necessary to ensure that they remain > available for new uses, and history has shown this occurs almost exclusively > through active mechanism use. > > The conditions for retaining the ability to evolve a design is most clearly > evident in the protocols that are known to have viable version negotiation or > extension points. The definition of mechanisms alone is insufficient; it's the > assured implementation through active use of those mechanisms that determines > the existence of freedom. Protocols that routinely add new extensions and code ^^^^^^^ something more specific maybe ? agile protocol evolution ? Or else specify what you mean with "freedom". Wihout qualifiers i always think freedom means this: https://www.youtube.com/watch?v=CdKVX45wYeQ > points rarely have trouble adding additional ones, especially when the handling > of new versions or extension is well defined. Maybe also the observation, that the extensions that crete least problems are those that only extend the data model, but not the state machinery of protocols. Thats how i would decribe the hundreds of DHCP options that where easily added for example or all of Yang models or the like. > ## Examples of Active Use {#ex-active} > > For example, header fields in email {{?SMTP=RFC5322}}, HTTP {{?HTTP}} > and SIP {{?SIP=RFC3261}} all derive from the same basic design, which amounts to > a list name/value pairs. There is no evidence of significant barriers to > deploying header fields with new names and semantics in email and HTTP as > clients and servers can ignore headers they do not understand or need. The > widespread deployment of SIP B2BUAs means that new SIP header fields do not > reliably reach peers, however, which doesn't necessarily cause interoperability > issues but rather causes feature deployment issues due to the lack of > option passing {{middleboxes}}. I would suggest to separate the SIP discussion from SMTP/HTTP and highlight for both of them the core aspect: SMTP/HTTP default behavior for extensions is "ignore when unknown". This is the best case for agile development/deployment. In SIP because of B2BUA, the default behavior is "filter/block" and i was involved when we tried to work around this in products for nex extensions we needed, and it really has lead to much less adoption of extensions. So i think the way how you describe the SIP example in your current paragraph is somewhat misleading: IMHO, active Use is necessary, but not sufficient. You do need actually working deployment models in the face of normal disturbances (middlebox such as B2BUA). > As another example, the attribute-value pairs (AVPs) in Diameter > {{?DIAMETER=RFC6733}} are fundamental to the design of the protocol. Any use of > Diameter requires exercising the ability to add new AVPs. This is routinely > done without fear that the new feature might not be successfully deployed. Data-models point i made above. I do remember DHCP functions requring new state machineries. Those of course are harder to deploy, ensure interop. > These examples show extension points that are heavily used are also being > relatively unaffected by deployment issues preventing addition of new values > for new use cases. > > These examples also confirm the case that good design does not guarantee > success. On the contrary, success is often despite shortcomings in the design. > For instance, the shortcomings of HTTP header fields are significant enough that > there are ongoing efforts to improve the syntax > {{?HTTP-HEADERS=RFC8941}}. > > Only by using a protocol's extension capabilities does it ensure the > availability of that capability. Protocols that fail to use a mechanism, or a > protocol that only rarely uses a mechanism, may suffer an inability to rely on > that mechanism. So i guess "use" actually is two stage, and thats not clear from the text. You need to use extensions in spec, but you also need to use them in deployments to not loose them. Maybe you can rephrase/refine accordingly. > > ## Dependency is Better {#need-it} > > The best way to guarantee that a protocol mechanism is used is to make the ^^^^ easiest > handling of it critical to an endpoint participating in that protocol. I am thinking primarily of error handling options. Only few deployment can afford regular error insertion to harden implementations. Something is not "best" if its not feasible in key problem areas. But it is easiest. > This means that implementations must rely on both the existence of extension > mechanisms and their continued, repeated expansion over time. > > For example, the message format in SMTP relies on header fields for most of its > functions, including the most basic delivery functions. A deployment of SMTP > cannot avoid including an implementation of header field handling. In addition > to this, the regularity with which new header fields are defined and used > ensures that deployments frequently encounter header fields that it does not yet > (and may never) understand. An SMTP implementation therefore needs to be able > to both process header fields that it understands and ignore those that it does > not. Its easy to attempt establising a generic principle from the most easy instance (ignoring of data model leaves). Try to come up with the most complex instance of need-it extensibility and document that. Otherwise maybe refine that the need-it can easily only be applied to a subset of extension cases. > In this way, implementing the extensibility mechanism is not merely mandated by > the specification, it is crucial to the functioning of a protocol deployment. > Should an implementation fail to correctly implement the mechanism, that failure > would quickly become apparent. > > Caution is advised to avoid assuming that building a dependency on an extension > mechanism is sufficient to ensure availability of that mechanism in the long > term. If the set of possible uses is narrowly constrained and deployments do > not change over time, implementations might not see new variations or assume a > narrower interpretation of what is possible. Those implementations might still > exhibit errors when presented with new variations. The corollary of this correct analsysis though is NOT to not have hese type of extension points because depending on protocol its the only way to do things. Instead, IMHO the corllary is that if an extension point is not sufficienly well enough exercisable through actual deployment use, hen it is even more important to code path analysis through testing. In routers where this problem is widespread, this is exactly whats being done through code coverage analsysis and explicitly a lot of negative testing for extension code points. Of course, third-party testing would always be better, see also examples such as the OpenSSH secrutiy issues. > ## Restoring Active Use > > With enough effort, active use can be used to restore capabililities. > > EDNS {{?EDNS=RFC6891}} was defined to provide extensibility in DNS. Intolerance > of the extension in DNS servers resulted in a fallback method being widely > deployed (see {{Section 6.2.2 of EDNS}}), This fallback resulted in EDNS being > disabled for affected servers. Over time, greater support for EDNS and > increased reliance on it for different features motivated a flag day > {{DNSFLAGDAY}} where the workaround was removed. > > The EDNS example shows that effort can be used to restore capabilities. This is > in part because EDNS was actively used with most resolvers and servers. It was > therefore possible to force a change to ensure that extension capabilities would > always be available. However, this required an enormous coordination effort. A > small number of incompatible servers and the names they serve also become > inaccessible to most clients. > > > # Active Use {#use} > > As discussed in {{use-it}}, the most effective defense against ossification of > protocol extension points is active use. > > Implementations are most likely to be tolerant of new values if they depend on > being able to frequently use new values. Failing that, implementations that > routinely see new values are more likely to correctly handle new values. More > frequent changes will improve the likelihood that incorrect handling or > intolerance is discovered and rectified. The longer an intolerant > implementation is deployed, the more difficult it is to correct. > > What constitutes "active use" can depend greatly on the environment in which a > protocol is deployed. The frequency of changes necessary to safeguard some > mechanisms might be slow enough to attract ossification in another protocol > deployment, while being excessive in others. > > > ## Version Negotiation > > As noted in {{not-good-enough}}, protocols that provide version negotiation > mechanisms might not be able to test that feature until a new version is > deployed. One relatively successful design approach has been to use the > protocol selection mechanisms built into a lower-layer protocol to select the > protocol. This could allow a version negotiation mechanism to benefit from > active use of the extension point by other protocols. > > For instance, all published versions of IP contain a version number as the four > high bits of the first header byte. However, version selection using this > field proved to be unsuccessful. Ultimately, successful deployment of IPv6 > over Ethernet {{?RFC2464}} required a different EtherType from IPv4. This > change took advantage of the already-diverse usage of EtherType. last paragraph sounds familiar from earlier in the doc. > Other examples of this style of design include Application-Layer Protocol > Negotiation ({{?ALPN=RFC7301}}) and HTTP content negotiation ({{Section 12 of > HTTP}}). > > This technique relies on the codepoint being usable. For instance, the IP > protocol number is known to be unreliable and therefore not suitable > {{?NEW-PROTOCOLS=DOI.10.1016/j.comnet.2020.107211}}. > > > ## Falsifying Active Use {#grease} > > "Grease" was originally defined for TLS {{?GREASE=RFC8701}}, but has been > adopted by other protocols, such as QUIC {{?QUIC=RFC9000}}. Grease identifies > lack of use as an issue (protocol mechanisms "rusting" shut) and proposes > reserving values for extensions that have no semantic value attached. > > The design in {{?GREASE}} is aimed at the style of negotiation most used in TLS, > where one endpoint offers a set of options and the other chooses the one that it > most prefers from those that it supports. An endpoint that uses grease randomly > offers options - usually just one - from a set of reserved values. These values > are guaranteed to never be assigned real meaning, so its peer will never have > cause to genuinely select one of these values. Nice, but if code points are reserved for never to be used in rality, they would also be followed with specialized state machinery in implementations, resulting in the fact that the state machinery for other, real future code points may not be exercised. > More generally, greasing is used to refer to any attempt to exercise extension > points without changing endpoint behavior, other than to encourage participants > to tolerate new or varying values of protocol elements. > > The principle that grease operates on is that an implementation that is > regularly exposed to unknown values is less likely to be intolerant of new > values when they appear. This depends largely on the assumption that the > difficulty of implementing the extension mechanism correctly is as easy or > easier than implementing code to identify and filter out reserved values. > Reserving random or unevenly distributed values for this purpose is thought to > further discourage special treatment. > > Without reserved greasing codepoints, an implementation can use code points from > spaces used for private or experimental use if such a range exists. In addition > to the risk of triggering participation in an unwanted experiment, this can be > less effective. Incorrect implementations might still be able to identify these > code points and ignore them. > > In addition to advertising bogus capabilities, an endpoint might also > selectively disable non-critical protocol elements to test the ability of peers > to handle the absence of certain capabilities. > > This style of defensive design is limited because it is only superficial. As > greasing only mimics active use of an extension point, it only exercises a small > part of the mechanisms that support extensibility. More critically, it does not > easily translate to all forms of extension points. For instance, HMSV > negotiation cannot be greased in this fashion. Other techniques might be > necessary for protocols that don't rely on the particular style of exchange that > is predominant in TLS. > > Grease is deployed with the intent of quickly revealing errors in implementing > the mechanisms it safeguards. Though it has been effective at revealing > problems in some cases with TLS, the efficacy of greasing isn't proven more > generally. Where implementations are able to tolerate a non-zero error rate in > their operation, greasing offers a potential option for safeguarding future > extensibility. However, this relies on there being a sufficient proportion of > participants that are willing to invest the effort and tolerate the risk of > interoperability failures. > > > # Complementary Techniques {#other} > > The protections to protocol evolution that come from [active use](#use) can be > improved through the use of other defensive techniques. The techniques listed > here might not prevent ossification on their own, but can make active use more > effective. > > > ## Cryptography > > Cryptography can be used to reduce the number of middlebox entities that can > participate in a protocol or limit the extent of participation. Using TLS or > other cryptographic tools can therefore reduce the number of entities that can > influence whether new features are usable. > > {{?PATH-SIGNALS=RFC8588}} recommends the use of encryption and integrity > protection to limit participation. For example, encryption is used by the QUIC > protocol {{?QUIC=RFC9000}} to limit the information that is available to > middleboxes and integrity protection prevents modification. As mentioned above, add authentication in before cryptography as another option and discuss differences. These complemenary techniques should be listed/assigned to my initial c), aka: unintended middleboxes. > ## Fewer Extension Points > > A successful protocol will include many potential types of extension. Designing > multiple types of extension mechanism, each suited to a specific purpose, might > leave some extension points less heavily used than others. > > Disuse of a specialized extension point might render it unusable. In contrast, > having a smaller number of extension points with wide applicability could > improve the use of those extension points. Use of a shared extension point for > any purpose can protect rarer or more specialized uses. > > Both extensions and core protocol elements use the same extension points in > protocols like HTTP {{?HTTP}} and DIAMETER {{?DIAMETER}}; see {{ex-active}}. Whats missing from techniques are thing like: a) Diagnostics for extension point failures. Ability to distinguish extension point failure between a), b), c), aka: designing an extension point so that it wold be clear if/who it fails. b) Upfront Extension point Profile signaling. Reduces depth of state machinery at which extension point failure occurs, and allows to proacively avoid probing an extension point. > ### Invariants > > Documenting aspects of the protocol that cannot or will not change as > extensions or new versions are added can be a useful exercise. Understanding > what aspects of a protocol are invariant can help guide the process of > identifying those parts of the protocol that might change. Example ? > As a means of protecting extensibility, a declaration of protocol invariants is > useful only to the extent that protocol participants are willing to allow new > uses for the protocol. Like with greasing, protocol participants could still > purposefully block the deployment of new features. A protocol that declares > protocol invariants relies on implementations understanding and respecting those > invariants. Examples ? This seems to leak also into security, e..: desire/need for middleboxes to constrain protocols to a predefined functionality. > Protocol invariants need to be clearly and concisely documented. Including > examples of aspects of the protocol that are not invariant, such as the > appendix of {{?QUIC-INVARIANTS=RFC8999}}, can be used to > clarify intent. > > > ## Effective Feedback > > While not a direct means of protecting extensibility mechanisms, feedback > systems can be important to discovering problems. > > Visibility of errors is critical to the success of techniques like grease (see > {{grease}}). The grease design is most effective if a deployment has a means of > detecting and reporting errors. Ignoring errors could allow problems to become > entrenched. > > Feedback on errors is more important during the development and early deployment > of a change. It might also be helpful to disable automatic error recovery > methods during development. I don't aagree on he "early deployment". It equally valuable whenever new deployments happen. Just think about all the middlebox issues that reopened in >= transport protocols years after initial deployments when IPv4 was amnded with IPv6. Or hen new classes of middleboxes appeared (Intrusion Detection Systems). > Automated feedback systems are important for automated systems, or where error > recovery is also automated. For instance, connection failures with HTTP > alternative services {{?ALT-SVC=RFC7838}} are not permitted to affect the > outcome of transactions. An automated feedback system for capturing failures in > alternative services is therefore necessary for failures to be detected. > > How errors are gathered and reported will depend greatly on the nature of the > protocol deployment and the entity that receives the report. For instance, end > users, developers, and network operations each have different requirements for > how error reports are created, managed, and acted upon. > > Automated delivery of error reports can be critical for rectifying deployment > errors as early as possible, such as seen in {{?DMARC=RFC7489}} and > {{?SMTP-TLS-Reporting=RFC8460}}. Local on the system: circular, space limited automatic logging of all events coupled with auomatic comression/reduction by severity level. Especially making it intelligent: around the time points of severe errors you do maintain also the less severe errors. Alas, i have not found good implementations of this. More easily: good management plane models for monitoring. E.g.: Yang models for protocols where there are counters for all possible error conditions. With yang push and other yang event models you can trigger/trace errors. > # Security Considerations > > Many of the problems identified in this document are not the result of > deliberate actions by an adversary, but more the result of mistakes, decisions > made without sufficient context, or simple neglect. Problems therefore not the > result of opposition by an adversary. In response, the recommended measures > generally assume that other protocol participants will not take deliberate > action to prevent protocol evolution. But equally many problems occur from middleboxes that want to be friendly, but don't work. Even more so from middleboxes needing to do a do a different job. Most often security. > The use of cryptographic techniques to exclude potential participants is the > only strong measure that the document recommends. In this security considerations it is IMHO most important to explicitly highlight the option of authentication without encryption. It prohibits messin with the procols, but it allows whats negatively is called perpass/monitoring, and a required security function - followed potentially by mandaory filtering/breaking of inappropriat protocol flows. > However, authorized protocol > peers are most often responsible for the identified problems, which can mean > that cryptography is insufficient to exclude them. Again, authenticated, but unencrypted. Firewalls need to keep bad stuff out, and good stuff in. SO they need to look at stuff and accordingly filter. > The ability to design, implement, and deploy new protocol mechanisms can be > critical to security. In particular, it is important to be able to replace Please say that these new mechanisms will require new extension point values. > cryptographic algorithms over time {{?AGILITY=RFC7696}}. For example, > preparing for replacement of weak hash algorithms was made more difficult > through misuse {{HASH}}. > > > # IANA Considerations > > This document makes no request of IANA. Actually there is IMHO an IANA related issue: We do not have the tooling for automated updating of code-point values. Whereas we have YAND and a lot of other formal models, if you want to especially build diagnostic systems, there is no automated way to suck in current IANA registry information becuase he only authoritative representation are "read-by-human-only" web paes. Aka: We should have formal language model authoritative IANA registry description. In additionl to the information we have now in IANA registries, such a formal model representation could/should alow for every code-point to have formal langauge "protocol informatin", aka: formal code that could be sucked in by protocol toolchains to automatically extend code. Cheers Toerless > --- back > > # Acknowledgments > {:numbered="false"} > > Wes Hardaker, Mirja Kühlewind, Mark Nottingham, and Brian Trammell made > significant contributions to this document. On Wed, Jul 14, 2021 at 07:20:02AM -0700, Tommy Pauly wrote: > Hello EDM, > > We’ve posted a new version of the use-it-or-lose-it draft, which has been discussed in several of our past calls. > > The IAB would like to get this document progressed to be published as an RFC between IETF 111 and IETF 112. Please take a look at the current version, and provide your reviews either here by email, or on the GitHub (https://github.com/intarchboard/draft-use-it-or-lose-it/issues ). > > Best, > Tommy > > > On Jul 14, 2021, at 6:21 AM, internet-drafts@ietf.org wrote: > > > > > > A new version of I-D, draft-iab-use-it-or-lose-it-01.txt > > has been successfully submitted by Cindy Morgan and posted to the > > IETF repository. > > > > Name: draft-iab-use-it-or-lose-it > > Revision: 01 > > Title: Long-term Viability of Protocol Extension Mechanisms > > Document date: 2021-07-14 > > Group: iab > > Pages: 19 > > URL: https://www.ietf.org/archive/id/draft-iab-use-it-or-lose-it-01.txt > > Status: https://datatracker.ietf.org/doc/draft-iab-use-it-or-lose-it/ > > Html: https://www.ietf.org/archive/id/draft-iab-use-it-or-lose-it-01.html > > Htmlized: https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it > > Diff: https://www.ietf.org/rfcdiff?url2=draft-iab-use-it-or-lose-it-01 > > > > Abstract: > > The ability to change protocols depends on exercising the extension > > and version negotiation mechanisms that support change. Protocols > > that don't use these mechanisms can find it difficult and costly to > > deploy changes. > > > > > > > > > > The IETF Secretariat > > > > > > -- > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm -- --- tte@cs.fau.de From nobody Thu Jul 15 11:25:14 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E903A00DB for ; Thu, 15 Jul 2021 11:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 4wHWX5n-dKqJ for ; Thu, 15 Jul 2021 11:25:06 -0700 (PDT) Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (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 D04FF3A00E5 for ; Thu, 15 Jul 2021 11:25:05 -0700 (PDT) Received: from sushi.unix-ag.uni-kl.de (sushi.unix-ag.uni-kl.de [IPv6:2001:638:208:ef34:0:ff:fe00:65]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 16FIOwLe090161 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 20:24:58 +0200 Received: from sushi.unix-ag.uni-kl.de (ip6-localhost [IPv6:::1]) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 16FIOvA6012022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Jul 2021 20:24:57 +0200 Received: (from auerswal@localhost) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Submit) id 16FIOuw6012016; Thu, 15 Jul 2021 20:24:56 +0200 Date: Thu, 15 Jul 2021 20:24:56 +0200 From: Erik Auerswald To: Tommy Pauly Cc: edm@iab.org Message-ID: <20210715182456.GA11424@unix-ag.uni-kl.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> Author: Erik Auerswald User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 18:25:13 -0000 Hi Tommy, thanks for working on this nice draft. I have sent a few small typing mistake fixes as a GitHub pull request (https://github.com/intarchboard/draft-use-it-or-lose-it/pull/50). Additionally, I think that two text passages could be improved a bit. 1. The last paragraph of section 2.1 seems to suggest that "simplicity" is not a good engineering practice. I think it intends to say that stopping at the "minimum viable product" tends to fall short on, in this case, extensibility. Thus I would suggest one of the following text changes, or something similar: OLD: A desire to deploy can result in an engineering practice that values simplicity, which could result in deferring implementation of version negotiation and extension mechanisms. NEW (version 1): A desire to deploy can result in a "minimum viable product" engineering practice, which could result in deferring implementation of version negotiation and extension mechanisms. NEW (version 2): A desire to deploy can result in an engineering practice that initially concentrates on a reduced feature set, which could result in deferring implementation of version negotiation and extension mechanisms. 2. In the second to last paragraph of section 3.1, the first sentence seems to me to possibly contain a logic mistake: "These examples also confirm the case that good design does not guarantee success." As far as I understand it, the examples from section 3.1 show that extension mechanisms can work even if they are not based on good design. The examples of the preceding section 2, specifically section 2.2.1, show that good design of extension mechnisms does not suffice for well working extensibility. Thus I would suggest a text change similar to the following: OLD: These examples also confirm the case that good design does not guarantee success. NEW: These examples also show that good design is not required for success. Thanks, Erik On Wed, Jul 14, 2021 at 04:20:02PM +0200, Tommy Pauly wrote: > Hello EDM, > > We’ve posted a new version of the use-it-or-lose-it draft, which > has been discussed in several of our past calls. > > The IAB would like to get this document progressed to be published as an > RFC between IETF 111 and IETF 112. Please take a look at the current > version, and provide your reviews either here by email, or on the > GitHub (https://github.com/intarchboard/draft-use-it-or-lose-it/issues > ). > > Best, > Tommy > > > On Jul 14, 2021, at 6:21 AM, internet-drafts@ietf.org wrote: > > > > > > A new version of I-D, draft-iab-use-it-or-lose-it-01.txt > > has been successfully submitted by Cindy Morgan and posted to the > > IETF repository. > > > > Name: draft-iab-use-it-or-lose-it > > Revision: 01 > > Title: Long-term Viability of Protocol Extension Mechanisms > > Document date: 2021-07-14 > > Group: iab > > Pages: 19 > > URL: https://www.ietf.org/archive/id/draft-iab-use-it-or-lose-it-01.txt > > Status: https://datatracker.ietf.org/doc/draft-iab-use-it-or-lose-it/ > > Html: https://www.ietf.org/archive/id/draft-iab-use-it-or-lose-it-01.html > > Htmlized: https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it > > Diff: https://www.ietf.org/rfcdiff?url2=draft-iab-use-it-or-lose-it-01 > > > > Abstract: > > The ability to change protocols depends on exercising the extension > > and version negotiation mechanisms that support change. Protocols > > that don't use these mechanisms can find it difficult and costly to > > deploy changes. > > > > > > > > > > The IETF Secretariat > > > > From nobody Fri Jul 16 00:14:42 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB983A2A59 for ; Fri, 16 Jul 2021 00:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 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_DNSWL_LOW=-0.7, 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=WQHubF4h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JtFoZUEd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fEBH_TNudnW for ; Fri, 16 Jul 2021 00:14:35 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39D43A2A58 for ; Fri, 16 Jul 2021 00:14:35 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 4028B5C01C0 for ; Fri, 16 Jul 2021 03:14:32 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Fri, 16 Jul 2021 03:14:32 -0400 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=fm2; bh=Gm17O49CjsmOHjedgeh+VlzIMM38bpX iCa2GoivTb5k=; b=WQHubF4h+/h6tzkEtzPCRkkFi6UDQHvaO5rJXvC3xQE1Sbz v+65ZPMMzVCHiCIhdLfkunW8NzLzBuFmx7fue4WKRVjZP1M3xpf1FLkC3AuGSimP 0RurwQ/2pC2CWcAFLCr0x0Au4ltBQkkNgaO0RZWOiObDF2oCjhwVJ0h2tQvJJso3 30i8oDppUQTMP+Ibe/Eeq7aFEcooTJDHgW+lv925ulb98ZCnbATCfOQ7o4YdqE6z d3Lm5aW+3kfok14XEVJJozjVTed0A5IfD74efEId+Sc3o/hVZAIlqyWYQP25BTL1 de6vZPoetwklCRE0XqwF5e3wkZo67Otx/WbQWGA== 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=fm3; bh=Gm17O4 9CjsmOHjedgeh+VlzIMM38bpXiCa2GoivTb5k=; b=JtFoZUEdPU/bmdnc8Mq2Xf 1nNhzclEU4odQtkIWOQTGYyV11oYrPqAsVB153KSFHarhZ0oz/agw8tfNT2Zh04I 9rxei5YxbiQlb8BWgK9qMBb3x+OR1/p3o7aAxI4DxlZNcAFTLYMroAaII6TFNYBY P9SaXt/Ci3yKyxDMm/JPfGyybLDLNWHhrJPf4GUz5ldsrVaiHa+eR2ZTc4Fhh8vZ GL3V1iUEJQxkgF//OT9GHJo+RVSmq07DRNdmGlKkEKSq0uOixfBCEDBPBXxsMUry NVRInrssSMqGD7JmS6Q5Lwqe0HeezFonHNTIEpPO7E+HGgxKVFD/jm3i+556bgtA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepvdehvdehjeffheeivdelleelgeehhfeutdelveeuieeiveevffeh teeuleeivdeunecuffhomhgrihhnpehgihhthhhusgdrihhonecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidr nhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CC9493C0D09; Fri, 16 Jul 2021 03:14:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b Mime-Version: 1.0 Message-Id: <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> In-Reply-To: <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> Date: Fri, 16 Jul 2021 17:14:10 +1000 From: "Martin Thomson" To: edm@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 07:14:41 -0000 Hi Toerless, Thanks for the review. It's going to take me a little while to just read your email. If there are specific items that you think need to be drawn out in particular, I would encourage you to open issues or new threads on just those. It will be easy to lose things with an email this long. I'm just going to reply to your meta-level comments here. I might try to turn the rest of this into issues on the repository. On Fri, Jul 16, 2021, at 01:46, Toerless Eckert wrote: > I think it would be good to write that the problems an solutions likely > fall all into three high level categories: > > a) p2p protocol extension considerations. > b) 3 or more party protocol extension considerations > (including middleboxes as supported parties). > c) 2 or more party protocol considerations plus undesirable middleboxes. > > Separating b) and c) is IMHO most important, I disagree. The draft does acknowledge the fact that difficulty scales poorly as more protocol participants are involved, but this is not the focus of the draft at all. The text exists to acknowledge that as a problem, but the core thesis is not that these are different but that they are _fundamentally_ the same. The number of participants just scales the problem (often very quickly out of reach). Your category (c) is almost out of scope. The text on limiting unwanted participation is very narrowly focused here. It only exists because it was necessary to point out that unprotected protocols can have more participants than expected and that - once the problem is identified - the most obvious solution seemed worth noting (not that it is always a *practical* solution, of course). See also https://martinthomson.github.io/tmi/draft-thomson-tmi.html > The other high-level suggestion is that at least in my opinion > there is more that could be written about reasons. > > IMHO: The deeper the extension point is within a protocol, and the > more complex the protocols starte machienry reaction to > unsupported extensions hs to be in the state machinery, > the more difficult it is to make sure it will work correctly > when needed. Of course, the most easy case is when you have > extensible data structures signalled and some parts can > just be ignored, but that is not always the semantic required. I think that this is just a matter of degree. Whether an extension point is hard to reach hasn't seemed to affect its availability in the cases we've gathered thus far. It's whether people have been motivated to seek it and actively use it that has mattered. It's not like the IP version field is hard to find or complicated. And - not in the draft - arguably some of the extension points in SDP are harder to reach than others, but the hard ones (a=extmap) are often more reliable than the easy ones (RTP/SAVPF). From nobody Fri Jul 16 01:06:52 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3C73A2BD9 for ; Fri, 16 Jul 2021 01:06:50 -0700 (PDT) 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=JJbpWj/5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=j0ZECpzC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnmIUQ1bcN4m for ; Fri, 16 Jul 2021 01:06:45 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A753A2BD4 for ; Fri, 16 Jul 2021 01:06:40 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 659C35C00F9 for ; Fri, 16 Jul 2021 04:06:39 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Fri, 16 Jul 2021 04:06:39 -0400 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=fm2; bh=OTaWYPSNWA7S7ZunXehOG+KIDPJznVg cC8vDf+MjcZU=; b=JJbpWj/5mEjPT8yf8O4gK1MMJWTmPSRcJe214r3oodi59ae gVwcouwEbk5VHjRNR5gAIZkXilfw8PbMTb3A9IdWiojrxxK3n6AdpWYS/PEmKSES 67CJ/13lavZhfvwNO5PSQqm8MJtd5QsKanA/sKE0nEKuZA4RHAErKzxN7g1LolZ3 CD5fUEXjnlxj0zjWyxFowSKavUeIwDvNcqiAZ4EImxpB/dDLrIYhtC7soIZJS1/0 okmxMX8dWDyG543cynqdAL0Tjjrp7x+/UR2KuEZ7P9ZbFrTdT3z2aHRoCxclfDe2 oObtw1baEhOI8EdaEXChjD4j5tYq4Iky1igDflA== 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=fm3; bh=OTaWYP SNWA7S7ZunXehOG+KIDPJznVgcC8vDf+MjcZU=; b=j0ZECpzCdtqIXKz+dZSh0S mvZL+FpqJN64fI8dg5mZfq95Pm8aALCwOUGfZ9inwJwyEC+Itt+La3Kf5ck143ee LJ7GKTA3nmEKiYHemqsZMjPDjhOnGvNP1GR/OiRSofQsibrsySuyFeJsdwb3AK2n ZqRGxmJbiUedXK2JGDd4uWPAULbhgpLJCusVo4bY0spSS1wFSr/kjKIkt9ChGX4A L/jxYp/bt6UWPWvBEbcpJF5cUB2tVJ3asQo3vkbnb9ahYRsNRP+ShdKtbyND9EWh m8wZviCN8DdHvya2+wh8hc3VOKu7yZhZIV1r3MXH8TZQguOjMp+LtgnEeAGTYR7A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvgdduvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhephfekvdekjeejlefgteefudetveefhfdujeefheegffdvgfduudeg vdejhffhheehnecuffhomhgrihhnpehgihhthhhusgdrihhopdhirggsrdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohif vghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DF8BC3C0D09; Fri, 16 Jul 2021 04:06:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b Mime-Version: 1.0 Message-Id: In-Reply-To: <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> Date: Fri, 16 Jul 2021 18:06:17 +1000 From: "Martin Thomson" To: edm@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 08:06:51 -0000 Replying to myself. Very bad form. Sorry. Hi again Toerless, I started reading through your feedback and I found some of it really helpful. I've made a bunch of edits in response. If you are willing to review the following pull request, that would be great. Here's a link: I won't do a blow-by-blow response. I'm afraid that I don't have that much time. Just one note. Throughout you mention authentication where the draft uses the word "cryptography". My understanding of cryptography is that it encompasses a broad discipline that includes encryption and integrity protection and authentication and a bunch of related things. Are you perhaps reading that word with the narrow meaning of "encryption"? Cheers, Martin On Fri, Jul 16, 2021, at 17:14, Martin Thomson wrote: > Hi Toerless, > > Thanks for the review. > > It's going to take me a little while to just read your email. If there > are specific items that you think need to be drawn out in particular, I > would encourage you to open issues or new threads on just those. It > will be easy to lose things with an email this long. > > I'm just going to reply to your meta-level comments here. I might try > to turn the rest of this into issues on the repository. > > On Fri, Jul 16, 2021, at 01:46, Toerless Eckert wrote: > > I think it would be good to write that the problems an solutions likely > > fall all into three high level categories: > > > > a) p2p protocol extension considerations. > > b) 3 or more party protocol extension considerations > > (including middleboxes as supported parties). > > c) 2 or more party protocol considerations plus undesirable middleboxes. > > > > Separating b) and c) is IMHO most important, > > I disagree. The draft does acknowledge the fact that difficulty scales > poorly as more protocol participants are involved, but this is not the > focus of the draft at all. The text exists to acknowledge that as a > problem, but the core thesis is not that these are different but that > they are _fundamentally_ the same. The number of participants just > scales the problem (often very quickly out of reach). > > Your category (c) is almost out of scope. The text on limiting > unwanted participation is very narrowly focused here. It only exists > because it was necessary to point out that unprotected protocols can > have more participants than expected and that - once the problem is > identified - the most obvious solution seemed worth noting (not that it > is always a *practical* solution, of course). > > See also https://martinthomson.github.io/tmi/draft-thomson-tmi.html > > > The other high-level suggestion is that at least in my opinion > > there is more that could be written about reasons. > > > > IMHO: The deeper the extension point is within a protocol, and the > > more complex the protocols starte machienry reaction to > > unsupported extensions hs to be in the state machinery, > > the more difficult it is to make sure it will work correctly > > when needed. Of course, the most easy case is when you have > > extensible data structures signalled and some parts can > > just be ignored, but that is not always the semantic required. > > I think that this is just a matter of degree. Whether an extension > point is hard to reach hasn't seemed to affect its availability in the > cases we've gathered thus far. It's whether people have been motivated > to seek it and actively use it that has mattered. It's not like the IP > version field is hard to find or complicated. And - not in the draft - > arguably some of the extension points in SDP are harder to reach than > others, but the hard ones (a=extmap) are often more reliable than the > easy ones (RTP/SAVPF). > > -- > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm > From nobody Fri Jul 16 14:00:16 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D563A0935 for ; Fri, 16 Jul 2021 14:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 SQz5QvXr2Hfp for ; Fri, 16 Jul 2021 14:00:09 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 006503A0931 for ; Fri, 16 Jul 2021 14:00:08 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 16GKwuKR031283; Fri, 16 Jul 2021 14:00:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=cFXl99ieNFwONGxl1BrKbglnXloviYCiCRCeSWC0TIY=; b=wVDDabbhHCxfmVdYEs6wvFlB1f3pPzzHhZ0Ln29oe9o4lsDR717zfSvhJu6NbGgAJbqk 2YZZrl6WtJqsSS8bB/Xsr4laAHgB9IPh0KuWeq3O5YjejyRHoreptzw0Qws6GFlBSEGv rMA8hqb1BXGiXErkHLzgPIIyc535cnBhssgCJh1tNp7LW6iDHBoqucyhsmLPs8RtZUlx gOdwtbhLui8xQpMT2HqrBEx3vSGf1dKp3FI0aUCqdq2Vz49lTxs0R1HjWrijDDrnBYVL 5RjSRCaIeuRNDZqSdNgSXyJN9tx+oZVgWgFAHdrTgRYOTVOwGren2N8CUdboH4EywfOh 4g== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 39tw4kawwj-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 16 Jul 2021 14:00:07 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QWC00GYUVO7HB00@rn-mailsvcp-mta-lapp03.rno.apple.com>; Fri, 16 Jul 2021 14:00:07 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QWC00100VNZYQ00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 16 Jul 2021 14:00:07 -0700 (PDT) X-Va-A: X-Va-T-CD: 01a37c4388be431533d60b3d58eeb299 X-Va-E-CD: 281407869ecdec76a85876a3d339dae7 X-Va-R-CD: cf71d9921d64adffaab788a1272d86eb X-Va-CD: 0 X-Va-ID: a45519d8-ffac-4db6-b4a7-a9316560c91f X-V-A: X-V-T-CD: 01a37c4388be431533d60b3d58eeb299 X-V-E-CD: 281407869ecdec76a85876a3d339dae7 X-V-R-CD: cf71d9921d64adffaab788a1272d86eb X-V-CD: 0 X-V-ID: 1fc326f9-336a-4f51-845c-302455fbcede X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-16_09:2021-07-16, 2021-07-16 signatures=0 Received: from smtpclient.apple (unknown [17.234.15.120]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QWC006J9VNPRX00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 16 Jul 2021 13:59:50 -0700 (PDT) From: Tommy Pauly Message-id: <6C0580F7-2D96-4FAE-AD63-1CD7F195FBB1@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_DF6FADC1-7383-477C-ABB3-222A485A45E6" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.6\)) Date: Fri, 16 Jul 2021 13:59:49 -0700 In-reply-to: Cc: edm@iab.org To: Martin Thomson References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> X-Mailer: Apple Mail (2.3654.80.0.2.6) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-16_10:2021-07-16, 2021-07-16 signatures=0 Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 21:00:14 -0000 --Apple-Mail=_DF6FADC1-7383-477C-ABB3-222A485A45E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 16, 2021, at 1:06 AM, Martin Thomson wrote: >=20 > Replying to myself. Very bad form. Sorry. >=20 > Hi again Toerless, >=20 > I started reading through your feedback and I found some of it really = helpful. I've made a bunch of edits in response. If you are willing to = review the following pull request, that would be great. >=20 > Here's a link:=20 Since I don=E2=80=99t see the link in my email, here it is: https://github.com/intarchboard/draft-use-it-or-lose-it/pull/52/files = >=20 > I won't do a blow-by-blow response. I'm afraid that I don't have that = much time. >=20 > Just one note. Throughout you mention authentication where the draft = uses the word "cryptography". My understanding of cryptography is that = it encompasses a broad discipline that includes encryption and integrity = protection and authentication and a bunch of related things. Are you = perhaps reading that word with the narrow meaning of "encryption"? >=20 > Cheers, > Martin >=20 > On Fri, Jul 16, 2021, at 17:14, Martin Thomson wrote: >> Hi Toerless, >>=20 >> Thanks for the review. >>=20 >> It's going to take me a little while to just read your email. If = there=20 >> are specific items that you think need to be drawn out in particular, = I=20 >> would encourage you to open issues or new threads on just those. It=20= >> will be easy to lose things with an email this long. >>=20 >> I'm just going to reply to your meta-level comments here. I might = try=20 >> to turn the rest of this into issues on the repository. >>=20 >> On Fri, Jul 16, 2021, at 01:46, Toerless Eckert wrote: >>> I think it would be good to write that the problems an solutions = likely >>> fall all into three high level categories: >>>=20 >>> a) p2p protocol extension considerations. >>> b) 3 or more party protocol extension considerations >>> (including middleboxes as supported parties). >>> c) 2 or more party protocol considerations plus undesirable = middleboxes. >>>=20 >>> Separating b) and c) is IMHO most important,=20 >>=20 >> I disagree. The draft does acknowledge the fact that difficulty = scales=20 >> poorly as more protocol participants are involved, but this is not = the=20 >> focus of the draft at all. The text exists to acknowledge that as a=20= >> problem, but the core thesis is not that these are different but that=20= >> they are _fundamentally_ the same. The number of participants just=20= >> scales the problem (often very quickly out of reach). >>=20 >> Your category (c) is almost out of scope. The text on limiting=20 >> unwanted participation is very narrowly focused here. It only exists=20= >> because it was necessary to point out that unprotected protocols can=20= >> have more participants than expected and that - once the problem is=20= >> identified - the most obvious solution seemed worth noting (not that = it=20 >> is always a *practical* solution, of course). >>=20 >> See also https://martinthomson.github.io/tmi/draft-thomson-tmi.html >>=20 >>> The other high-level suggestion is that at least in my opinion >>> there is more that could be written about reasons. >>>=20 >>> IMHO: The deeper the extension point is within a protocol, and the >>> more complex the protocols starte machienry reaction to >>> unsupported extensions hs to be in the state machinery, >>> the more difficult it is to make sure it will work correctly >>> when needed. Of course, the most easy case is when you have >>> extensible data structures signalled and some parts can >>> just be ignored, but that is not always the semantic required. >>=20 >> I think that this is just a matter of degree. Whether an extension=20= >> point is hard to reach hasn't seemed to affect its availability in = the=20 >> cases we've gathered thus far. It's whether people have been = motivated=20 >> to seek it and actively use it that has mattered. It's not like the = IP=20 >> version field is hard to find or complicated. And - not in the draft = -=20 >> arguably some of the extension points in SDP are harder to reach than=20= >> others, but the hard ones (a=3Dextmap) are often more reliable than = the=20 >> easy ones (RTP/SAVPF). >>=20 >> --=20 >> Edm mailing list >> Edm@iab.org >> https://www.iab.org/mailman/listinfo/edm >>=20 >=20 > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm --Apple-Mail=_DF6FADC1-7383-477C-ABB3-222A485A45E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 16, 2021, at 1:06 AM, Martin Thomson <mt@lowentropy.net> = wrote:

Replying to myself.  Very bad form.  Sorry.

Hi again Toerless,

I started reading through your feedback and I found some of = it really helpful.  I've made a bunch of edits in response. =  If you are willing to review the following pull request, that = would be great.

Here's a link:

Since I = don=E2=80=99t see the link in my email, here it is:



I won't do a = blow-by-blow response.  I'm afraid that I don't have that much = time.

Just one note.  Throughout you = mention authentication where the draft uses the word "cryptography". =  My understanding of cryptography is that it encompasses a broad = discipline that includes encryption and integrity protection and = authentication and a bunch of related things.  Are you perhaps = reading that word with the narrow meaning of "encryption"?

Cheers,
Martin

On Fri, Jul 16, 2021, at 17:14, Martin Thomson wrote:
Hi Toerless,

Thanks for the review.

It's going to take me a little while to just read your email. =  If there
are specific items that you think need to = be drawn out in particular, I
would encourage you to open = issues or new threads on just those.  It
will be = easy to lose things with an email this long.

I'm just going to reply to your meta-level comments here. =  I might try
to turn the rest of this into issues on = the repository.

On Fri, Jul 16, 2021, at = 01:46, Toerless Eckert wrote:
I think it would be good to write that the problems an = solutions likely
fall all into three high level = categories:

a) p2p protocol extension = considerations.
b) 3 or more party protocol extension = considerations
  (including middleboxes as = supported parties).
c) 2 or more party protocol = considerations plus undesirable middleboxes.

Separating b) and c) is IMHO most important,

I disagree.  The draft does = acknowledge the fact that difficulty scales
poorly as = more protocol participants are involved, but this is not the
focus of the draft at all.  The text exists to = acknowledge that as a
problem, but the core thesis is not = that these are different but that
they are = _fundamentally_ the same.  The number of participants just
scales the problem (often very quickly out of reach).

Your category (c) is almost out of scope. =  The text on limiting
unwanted participation is very = narrowly focused here.  It only exists
because it = was necessary to point out that unprotected protocols can
have more participants than expected and that - once the = problem is
identified - the most obvious solution seemed = worth noting (not that it
is always a *practical* = solution, of course).

See also https://martinthomson.github.io/tmi/draft-thomson-tmi.html<= br class=3D"">
The = other high-level suggestion is that at least in my opinion
there is more that could be written about reasons.

IMHO: The deeper the extension point is within = a protocol, and the
more complex the protocols starte = machienry reaction to
unsupported extensions hs to be in = the state machinery,
the more difficult it is to make sure = it will work correctly
when needed. Of course, the most = easy case is when you have
extensible data structures = signalled and some parts can
just be ignored, but that is = not always the semantic required.

I think that this is just a matter of degree.  Whether = an extension
point is hard to reach hasn't seemed to = affect its availability in the
cases we've gathered thus = far.  It's whether people have been motivated
to = seek it and actively use it that has mattered.  It's not like the = IP
version field is hard to find or complicated. =  And - not in the draft -
arguably some of the = extension points in SDP are harder to reach than
others, = but the hard ones (a=3Dextmap) are often more reliable than the
easy ones (RTP/SAVPF).

--
Edm mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm


--
Edm mailing = list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm

= --Apple-Mail=_DF6FADC1-7383-477C-ABB3-222A485A45E6-- From nobody Fri Jul 16 15:37:14 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54403A0E4A for ; Fri, 16 Jul 2021 15:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-XGuulTaJ_s for ; Fri, 16 Jul 2021 15:37:08 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBD43A0E48 for ; Fri, 16 Jul 2021 15:37:08 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B5FF2548015; Sat, 17 Jul 2021 00:37:02 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id ADCFF4E7A73; Sat, 17 Jul 2021 00:37:02 +0200 (CEST) Date: Sat, 17 Jul 2021 00:37:02 +0200 From: Toerless Eckert To: Martin Thomson Cc: edm@iab.org Message-ID: <20210716223702.GQ24216@faui48e.informatik.uni-erlangen.de> References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 22:37:13 -0000 On Fri, Jul 16, 2021 at 05:14:10PM +1000, Martin Thomson wrote: > > I think it would be good to write that the problems an solutions likely > > fall all into three high level categories: > > > > a) p2p protocol extension considerations. > > b) 3 or more party protocol extension considerations > > (including middleboxes as supported parties). > > c) 2 or more party protocol considerations plus undesirable middleboxes. > > > > Separating b) and c) is IMHO most important, > > I disagree. The draft does acknowledge the fact that difficulty scales poorly as more protocol participants are involved, but this is not the focus of the draft at all. Something not being in focus is fine. I was just trying to find ways to better structure the problem space because right now its a difficult read by sequentially discussing interesting examples but then concluding recipes which just be best applicable to a subset of the problem space without acknowledging that. For this particular structure suggestion it just seemed to me as if you start with a), then acknowledge that http is b) because of its explicit support for proxies, but then the mayor discussions are all about c), where its 2 parties plus undesirable middleboxes. > The text exists to acknowledge that as a problem, but the core thesis is not that these are different but that they are _fundamentally_ the same. The number of participants just scales the problem (often very quickly out of reach). > > Your category (c) is almost out of scope. The text on limiting unwanted participation is very narrowly focused here. It only exists because it was necessary to point out that unprotected protocols can have more participants than expected and that - once the problem is identified - the most obvious solution seemed worth noting (not that it is always a *practical* solution, of course). So put all the text about undesirable middleboxes into a separate section, including the conclusions about encrypted protocols, because i don't think the document has arguments about encryption applicable to b). > > IMHO: The deeper the extension point is within a protocol, and the > > more complex the protocols starte machienry reaction to > > unsupported extensions hs to be in the state machinery, > > the more difficult it is to make sure it will work correctly > > when needed. Of course, the most easy case is when you have > > extensible data structures signalled and some parts can > > just be ignored, but that is not always the semantic required. > > I think that this is just a matter of degree. Whether an extension point is hard to reach hasn't seemed to affect its availability in the cases we've gathered thus far. It's whether people have been motivated to seek it and actively use it that has mattered. It's not like the IP version field is hard to find or complicated. And - not in the draft - arguably some of the extension points in SDP are harder to reach than others, but the hard ones (a=extmap) are often more reliable than the easy ones (RTP/SAVPF). I think you are contradicting yourself. Yes, the IP version field is indeed maybe the most easily reached extension point across the examples given. And IMHO we do not need to invent New IP Versions regularily just to keep the extension point greased (although i think there are other good reasons to do so, but thats a different discussion, happy to point you to a draft of mine for that too if there is interest ;-). The example problem with the IP version extension point was one of c) - unplanned middleboxes. You say those are almost out of scope. And i do agree that high level i can concentrate on a), b) and take c) out of scope by authentication and/or encryption. And then indeed my argument for the deeper the extesion point the more difficult holds true. c) of course messes up completely any predictions about what extension point does and does not work well. I would need to hear more details about your SDP example to comment. The more fundamental reason for this proposed characterization of some metric for difficulty of extension points (depth inside state machinery) is of course experience from testing suites and code coverage measurements. The deeper the extension point in the state machinery, the more code in the suite you need to get it covered. Cheers Toerless > -- > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm From nobody Fri Jul 16 16:17:44 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8324C3A0983 for ; Fri, 16 Jul 2021 16:17:43 -0700 (PDT) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2hVAlxd5LQi for ; Fri, 16 Jul 2021 16:17:38 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBEE3A097F for ; Fri, 16 Jul 2021 16:17:38 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7C06C548056; Sat, 17 Jul 2021 01:17:31 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 755604E7A74; Sat, 17 Jul 2021 01:17:31 +0200 (CEST) Date: Sat, 17 Jul 2021 01:17:31 +0200 From: Toerless Eckert To: Martin Thomson Cc: edm@iab.org Message-ID: <20210716231731.GR24216@faui48e.informatik.uni-erlangen.de> References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 23:17:44 -0000 On Fri, Jul 16, 2021 at 06:06:17PM +1000, Martin Thomson wrote: > Just one note. Throughout you mention authentication where the draft uses the word "cryptography". My understanding of cryptography is that it encompasses a broad discipline that includes encryption and integrity protection and authentication and a bunch of related things. Are you perhaps reading that word with the narrow meaning of "encryption"? https://en.wikipedia.org/wiki/Cryptography "More generally, cryptography is about constructing and analyzing protocols that prevent third parties or the public from reading private messages" So yes, i would very much appreciate if authentication without encryption is explicitly mentioned as an option to limited arbitrary interaction with a protocol: "In particular, one of the consequences of an unencrypted protocol is that any element on path can interact with the protocol." I don't think anyone would consider that a protocol with authentication but without encryption is covered by that sentence. Likewise: "Cryptography can be used to reduce the number of middlebox entities that can participate in a protocol or limit the extent of participation. Using TLS or other cryptographic tools can therefore reduce the number of entities that can influence whether new features are usable." With TLS-1.3 having removed null encryption, that text too is leading toward only considering encryption. Cheers Toerless > Cheers, > Martin > > On Fri, Jul 16, 2021, at 17:14, Martin Thomson wrote: > > Hi Toerless, > > > > Thanks for the review. > > > > It's going to take me a little while to just read your email. If there > > are specific items that you think need to be drawn out in particular, I > > would encourage you to open issues or new threads on just those. It > > will be easy to lose things with an email this long. > > > > I'm just going to reply to your meta-level comments here. I might try > > to turn the rest of this into issues on the repository. > > > > On Fri, Jul 16, 2021, at 01:46, Toerless Eckert wrote: > > > I think it would be good to write that the problems an solutions likely > > > fall all into three high level categories: > > > > > > a) p2p protocol extension considerations. > > > b) 3 or more party protocol extension considerations > > > (including middleboxes as supported parties). > > > c) 2 or more party protocol considerations plus undesirable middleboxes. > > > > > > Separating b) and c) is IMHO most important, > > > > I disagree. The draft does acknowledge the fact that difficulty scales > > poorly as more protocol participants are involved, but this is not the > > focus of the draft at all. The text exists to acknowledge that as a > > problem, but the core thesis is not that these are different but that > > they are _fundamentally_ the same. The number of participants just > > scales the problem (often very quickly out of reach). > > > > Your category (c) is almost out of scope. The text on limiting > > unwanted participation is very narrowly focused here. It only exists > > because it was necessary to point out that unprotected protocols can > > have more participants than expected and that - once the problem is > > identified - the most obvious solution seemed worth noting (not that it > > is always a *practical* solution, of course). > > > > See also https://martinthomson.github.io/tmi/draft-thomson-tmi.html > > > > > The other high-level suggestion is that at least in my opinion > > > there is more that could be written about reasons. > > > > > > IMHO: The deeper the extension point is within a protocol, and the > > > more complex the protocols starte machienry reaction to > > > unsupported extensions hs to be in the state machinery, > > > the more difficult it is to make sure it will work correctly > > > when needed. Of course, the most easy case is when you have > > > extensible data structures signalled and some parts can > > > just be ignored, but that is not always the semantic required. > > > > I think that this is just a matter of degree. Whether an extension > > point is hard to reach hasn't seemed to affect its availability in the > > cases we've gathered thus far. It's whether people have been motivated > > to seek it and actively use it that has mattered. It's not like the IP > > version field is hard to find or complicated. And - not in the draft - > > arguably some of the extension points in SDP are harder to reach than > > others, but the hard ones (a=extmap) are often more reliable than the > > easy ones (RTP/SAVPF). > > > > -- > > Edm mailing list > > Edm@iab.org > > https://www.iab.org/mailman/listinfo/edm > > > > -- > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm -- --- tte@cs.fau.de From nobody Sun Jul 18 17:04:02 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35B53A1673 for ; Sun, 18 Jul 2021 17:04:00 -0700 (PDT) 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=F5FDeSqX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cZuza1G3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWGFKknrotgJ for ; Sun, 18 Jul 2021 17:03:54 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A413A1674 for ; Sun, 18 Jul 2021 17:03:54 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 253C55C0056; Sun, 18 Jul 2021 20:03:50 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Sun, 18 Jul 2021 20:03:50 -0400 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 :cc:subject:content-type; s=fm2; bh=uSAZBNn5A21zi4f6frcx+50825If ZexwIAWRDcKaY4E=; b=F5FDeSqXTdmgc1wlUZEw4sEJi5kA0EiPn4HRfkzcF75+ y1sH9tc28afqhfrxRn70vsOjN2cKYW9uRcLzPJPqhCX5a2+COwMCEJqICJBnKawa E0iJmnk5lMeRMClZBH+nWdRpmzgFNI9KfLV1QWkwlw6O2QKornIhuM1h4HUP38D/ NdtRgyWVQxNjABwaPwItJhCa7QHiNLl902PymgewGx8gIJU4DkmENAbDwGIjrOi0 yn/qWccHm0q5te4wYWv97FN+jYxhBMbAa1TlPRdpPdC6DyzAf4idHaWoOP2I/0u2 YpsI66HGWukPaQjCvd0Fz02Jcs0sBG1d2DTYOoKh7w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=uSAZBN n5A21zi4f6frcx+50825IfZexwIAWRDcKaY4E=; b=cZuza1G3/yNE8Hcirq3vuD NixndY3hboDQH/UmQpAg5b1UIX6phEHviyN1p6rJgNzu+AZRYw8vtS2CoEJ49ARQ JUZIhlUjg4P+aCbWrVEweJuwlMnG7XofQsgA2V6TxguC4+UNZH/Y+YLwyo3Abirq tze2CU1xRlO01WljMAly91h1NKUn0IyJ00gmM8zwhqz0yAt9c/sywkgjnbUzurkF /hJvBralREr6RkDWkf3qKc92tLhira+5+BnFubDnbelL8NKU7Cc/vUdl1Qqv7rtS 1wUe0Yfq0BDS/7Tnq734H2k8TiWVZEodzYNbFbGoS1qmxvgO2F7wE09GuZJnYQ0A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdelgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepffelhfdufffhfefggfelje duvedtgfeutdffiedttefgveefveffffekuefggfevnecuffhomhgrihhnpehgihhthhhu sgdrtghomhdpfihikhhiphgvughirgdrohhrghdpfihikhhtihhonhgrrhihrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehl ohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 666BE3C0E65; Sun, 18 Jul 2021 20:03:49 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b Mime-Version: 1.0 Message-Id: <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com> In-Reply-To: <20210716231731.GR24216@faui48e.informatik.uni-erlangen.de> References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> <20210716231731.GR24216@faui48e.informatik.uni-erlangen.de> Date: Mon, 19 Jul 2021 10:03:30 +1000 From: "Martin Thomson" To: "Toerless Eckert" Cc: edm@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 00:04:01 -0000 On Sat, Jul 17, 2021, at 08:37, Toerless Eckert wrote: > So put all the text about undesirable middleboxes into a separate section, > including the conclusions about encrypted protocols, because i don't > think the document has arguments about encryption applicable to b). I just reviewed the document and while there is mention of the multi-participant problem in a few places, the only substantive pieces are a dedicated section on the subject (which I think is worthwhile) and a separate section that mentions cryptography as a means of controlling participation. I think that it is OK as it is. > I think you are contradicting yourself. > > Yes, the IP version field is indeed maybe the most easily reached > extension point across the examples given. And IMHO we do not > need to invent New IP Versions regularily just to keep the > extension point greased (although i think there are other good > reasons to do so, but thats a different discussion, happy to > point you to a draft of mine for that too if there is interest ;-). > > The example problem with the IP version extension point was > one of c) - unplanned middleboxes. Routers are not unexpected protocol participants in IP. What was unexpected there was that routers were forwarding v6 packets without understanding any of their contents. Maybe this is a problem with approaching it from the perspective of the number of participants. The key point is that other participants might not allow extension, regardless of how many participants there are. The corollary is that more participants increases the chances that extension is blocked by a participant. The supporting observation is that sometimes there are more participants than you might have expected. I think that's a clean argument construction. The unexpected participation observation doesn't really apply to the IP version example as you have to expect that every router on path needs to participate. The >>2 corollary applies in full though. > The more fundamental reason for this proposed characterization > of some metric for difficulty of extension points (depth inside > state machinery) is of course experience from testing suites and code > coverage measurements. The deeper the extension point in the state > machinery, the more code in the suite you need to get it covered. I don't think that necessarily holds. When we built QUIC, one of the most difficult pieces of code to build is the transport parameters. It's right at the end of a long sequence of things that you need to get right with a bunch of interactions between encryption levels, transport stuff, TLS internals, and 0-RTT interactions. It's about as deep in the state machine as I have ever experienced in building protocols. QUIC transport parameters are nonetheless pretty completely reliable as a means of extending the protocol. Maybe it's just because it is early days, but my belief is that it is the fact that we already have lots of uses of extensions that rely on them: https://github.com/quicwg/base-drafts/wiki/Temporary-IANA-Registry#quic-transport-parameters On Sat, Jul 17, 2021, at 09:17, Toerless Eckert wrote: > On Fri, Jul 16, 2021 at 06:06:17PM +1000, Martin Thomson wrote: > > Just one note. Throughout you mention authentication where the draft uses the word "cryptography". My understanding of cryptography is that it encompasses a broad discipline that includes encryption and integrity protection and authentication and a bunch of related things. Are you perhaps reading that word with the narrow meaning of "encryption"? > > https://en.wikipedia.org/wiki/Cryptography > "More generally, cryptography is about constructing and analyzing protocols > that prevent third parties or the public from reading private messages" https://en.wiktionary.org/wiki/cryptography is a better match with my understanding: > The discipline concerned with communication security (eg, confidentiality of messages, integrity of messages, sender authentication, non-repudiation of messages, and many other related issues), [...] From nobody Sun Jul 18 18:54:27 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3EE3A1B8D for ; Sun, 18 Jul 2021 18:54:25 -0700 (PDT) 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 ZvrdZNIexrGE for ; Sun, 18 Jul 2021 18:54:20 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 9C8D03A1B89 for ; Sun, 18 Jul 2021 18:54:20 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id b2so4217034plx.1 for ; Sun, 18 Jul 2021 18:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kzlTL91SsyiA1+TjRyHkvXQfZlyGnwNKK76b7mOBpFg=; b=UjKTQVlzxcuqulGJH8uy3jozlao/aJEqJPbzKX7/lZS9Ka3SYO6LqlPA6lErMOiaSZ Imoq3wrSd8gOzKLuuNgBjN6oznAtU/fbx8PC0AcMOsmrD/KVcwi2VPs5TZMI56fbAcHh Qwja3HrYpJN1AiAmgLHZXa1cgJRQu+7unPpbEaKilHX5zptcu4pqpdkRCedJ+gueXBIU C9NHql2WvBBcgGlxRd2AaGh8z4TIwwR9gMkg+mi0mdNBy/+lQYdSfjfIRF4XBxKeJt06 dJvQYL0MmPa3ULOWz9z/XCHx1y3BaDOsO2D1XgItVGWN6eSOVWIaxRZEw2fp0DrB9+Ma lrBA== 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=kzlTL91SsyiA1+TjRyHkvXQfZlyGnwNKK76b7mOBpFg=; b=NJYlMfBSUnw44fWbMMtKa/Czo31x9bXtkJ0BmB6qUeMu4Un1SfbVFuE0K+14OsmVW6 NdM7FfDxU2JIeQYB5elHGgko/Gwm7zAfLfJjAEVMD+LTAjt244HVuotbQ8fqF4tem2sc Vi1tvR91D5FRgi4V7tLcNlz535ZLwdDJNWjNNgVauMAeBwGfdbd4xlG65/2gjjGSvhnL QcB+GfWToXma1SY+j5tO9yoghMnGWWIV5mbBkfRzQE1Fy8/Y5nWDq967wYrinhu/kcM7 VCXB6WEXTqEliny5dEL404QxjgLtQaynPmENotYwg8RjEYttmRmlU7BXpza3C26sL2cZ EUlA== X-Gm-Message-State: AOAM530WzhP6OvZe5/uCi55dTuUJmcrdk3XmwO+iDQz8nAhBSrH87HvE qlbJPCrfOlwP8amLgmXpAm273+BI6VH4jA== X-Google-Smtp-Source: ABdhPJy6Lnaii/yyDFBS0I62lapi58fAuKhYQ2HnIejqamW+D7F3mW5fTrgaCC3Ia2vwF0zXzU5AbA== X-Received: by 2002:a17:90a:3e02:: with SMTP id j2mr7076703pjc.81.1626659658094; Sun, 18 Jul 2021 18:54:18 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id r29sm17849157pfq.102.2021.07.18.18.54.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Jul 2021 18:54:17 -0700 (PDT) To: Martin Thomson , Toerless Eckert Cc: edm@iab.org References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> <20210716231731.GR24216@faui48e.informatik.uni-erlangen.de> <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com> From: Brian E Carpenter Message-ID: <9a5eec9d-90ae-ffd3-fc83-00e3800d7f9c@gmail.com> Date: Mon, 19 Jul 2021 13:54:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 01:54:26 -0000 Martin, > The unexpected participation observation doesn't really apply to the IP version example as you have to expect that every router on path needs to participate. Not really. That's what Router Alert is all about. I'm saying it is much of a success, but it recognized from the start that not all routers are equal. The ineffectiveness of both RFC2113 and RFC2711 illustrates that there is fundamentally no difference between IPv4 Options and IPv6 Extension Headers in this respect. The network is equally ossified and opaque to new ones in both cases. Here is some of the recent debris from this problem: draft-eastlake-6man-hide-options-00 draft-peng-v6ops-hbh-04 draft-herbert-6man-eh-limits-00 draft-ietf-v6ops-ipv6-ehs-packet-drops-08 draft-ietf-opsec-ipv6-eh-filtering-08 draft-hinden-6man-hbh-processing-01 Regards Brian On 19-Jul-21 12:03, Martin Thomson wrote: > > > On Sat, Jul 17, 2021, at 08:37, Toerless Eckert wrote: >> So put all the text about undesirable middleboxes into a separate section, >> including the conclusions about encrypted protocols, because i don't >> think the document has arguments about encryption applicable to b). > > I just reviewed the document and while there is mention of the multi-participant problem in a few places, the only substantive pieces are a dedicated section on the subject (which I think is worthwhile) and a separate section that mentions cryptography as a means of controlling participation. I think that it is OK as it is. > >> I think you are contradicting yourself. >> >> Yes, the IP version field is indeed maybe the most easily reached >> extension point across the examples given. And IMHO we do not >> need to invent New IP Versions regularily just to keep the >> extension point greased (although i think there are other good >> reasons to do so, but thats a different discussion, happy to >> point you to a draft of mine for that too if there is interest ;-). >> >> The example problem with the IP version extension point was >> one of c) - unplanned middleboxes. > > Routers are not unexpected protocol participants in IP. What was unexpected there was that routers were forwarding v6 packets without understanding any of their contents. > > Maybe this is a problem with approaching it from the perspective of the number of participants. The key point is that other participants might not allow extension, regardless of how many participants there are. The corollary is that more participants increases the chances that extension is blocked by a participant. The supporting observation is that sometimes there are more participants than you might have expected. > > I think that's a clean argument construction. > > The unexpected participation observation doesn't really apply to the IP version example as you have to expect that every router on path needs to participate. The >>2 corollary applies in full though. > >> The more fundamental reason for this proposed characterization >> of some metric for difficulty of extension points (depth inside >> state machinery) is of course experience from testing suites and code >> coverage measurements. The deeper the extension point in the state >> machinery, the more code in the suite you need to get it covered. > > I don't think that necessarily holds. When we built QUIC, one of the most difficult pieces of code to build is the transport parameters. It's right at the end of a long sequence of things that you need to get right with a bunch of interactions between encryption levels, transport stuff, TLS internals, and 0-RTT interactions. It's about as deep in the state machine as I have ever experienced in building protocols. > > QUIC transport parameters are nonetheless pretty completely reliable as a means of extending the protocol. Maybe it's just because it is early days, but my belief is that it is the fact that we already have lots of uses of extensions that rely on them: https://github.com/quicwg/base-drafts/wiki/Temporary-IANA-Registry#quic-transport-parameters > > On Sat, Jul 17, 2021, at 09:17, Toerless Eckert wrote: >> On Fri, Jul 16, 2021 at 06:06:17PM +1000, Martin Thomson wrote: >>> Just one note. Throughout you mention authentication where the draft uses the word "cryptography". My understanding of cryptography is that it encompasses a broad discipline that includes encryption and integrity protection and authentication and a bunch of related things. Are you perhaps reading that word with the narrow meaning of "encryption"? >> >> https://en.wikipedia.org/wiki/Cryptography >> "More generally, cryptography is about constructing and analyzing protocols >> that prevent third parties or the public from reading private messages" > > https://en.wiktionary.org/wiki/cryptography is a better match with my understanding: > >> The discipline concerned with communication security (eg, confidentiality of messages, integrity of messages, sender authentication, non-repudiation of messages, and many other related issues), [...] > From nobody Sun Jul 18 19:25:32 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976BD3A1CAE for ; Sun, 18 Jul 2021 19:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 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, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, 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=f9BTPf4r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pefrqDev Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ_AH6bVKi4W for ; Sun, 18 Jul 2021 19:25:22 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765CA3A1CAC for ; Sun, 18 Jul 2021 19:25:22 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C22A85C004B; Sun, 18 Jul 2021 22:25:18 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Sun, 18 Jul 2021 22:25:18 -0400 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 :cc:subject:content-type; s=fm2; bh=M1XqbxXn5S42s6pKH7to9wQDi+ln VVwCfcj3YMNFcFE=; b=f9BTPf4rcTPvw/fq41H98nT33VRu63TW7eKX0OCxms6z B4OHRP3MV+0sGZuxe0eWuUBk+UarfRNb4pf4OkoFUGP9Pl7HqfC7seutVBwEMWsX oeve6spvPEO9FTOGi11SwSpsnbOVwuEFSxbP4+m4ScNVGZjwe7l3DfsJK5hZaLa5 Ywrx/sZooIr6kp1TSc7QtJYPa6NAHCNR5oOt3JfKZfww0CrzJ5C3goNmQpvMEqd7 xLAwQwu/xCWWD1fsEEhMnLVyVpN+fqifA5be1FstdpKp762jmpxGrKHmKIfhwS37 F80rsszIFIg/B6JwDBsQd68ltAUHPgIYJS/RFKvrRQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=M1Xqbx Xn5S42s6pKH7to9wQDi+lnVVwCfcj3YMNFcFE=; b=pefrqDevYML8neavu9exFG NuROpO3GmH7UwfWxFBq79C6y5IyL6vzl7MbNNNAw+SVh03lxHXKaOA3O3pCuAV04 hU8ZAHzUj6Js/VrPZCY7svcZIHwicS64o06NHqUSspoa6bNuXUVv8/G6pAmiL0FJ Cj6SbfRDCnDbqs8GavzEdNqMIS1Sq08u/uMKpFgBaRJ9KCYBeihevDV9Hglhof7m qPA0QYU8gBnP3kSaRfBRjKnCGOnxWSuQqnBbdOYY5u9e/A2V1ohDuG9qqt3CMU34 KyPFI1RtflsZ5FUNR+5m1HUwHQPY4F+gBQOlOnC4c76RnGs6W4kqD2akZSnewDlg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdelgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpeekteeuieektdekleefkeevhfekffevvdevgfekgfeluefgvdejjeeg ffeigedtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B2E053C0E68; Sun, 18 Jul 2021 22:25:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b Mime-Version: 1.0 Message-Id: <5d0baa69-8634-49de-bed3-cc8467c5e34f@www.fastmail.com> In-Reply-To: <9a5eec9d-90ae-ffd3-fc83-00e3800d7f9c@gmail.com> References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> <20210716231731.GR24216@faui48e.informatik.uni-erlangen.de> <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com> <9a5eec9d-90ae-ffd3-fc83-00e3800d7f9c@gmail.com> Date: Mon, 19 Jul 2021 12:24:57 +1000 From: "Martin Thomson" To: "Brian E Carpenter" , "Toerless Eckert" Cc: edm@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 02:25:31 -0000 On Mon, Jul 19, 2021, at 11:54, Brian E Carpenter wrote: > > The unexpected participation observation doesn't really apply to the IP version example as you have to expect that every router on path needs to participate. > > Not really. That's what Router Alert is all about. I'm saying it is > much of a success, but it recognized from the start that not all > routers are equal. > > The ineffectiveness of both RFC2113 and RFC2711 illustrates that there > is fundamentally no difference between IPv4 Options and IPv6 Extension > Headers in this respect. The network is equally ossified and opaque to > new ones in both cases. Oh, the options/header extension mess is multi-dimensional. I didn't get the impression that misuse at the root of the problem, though your first reference implies that it might be. I'm not following that work closely to say that it is the only problem here or even if it is the main problem. Do you think that it is worth talking about here? A one paragraph contribution that talked about the Router Alert Option/EH might help. if only to highlight how this is not always caused by bugs, but it can be interaction with policies that participants might choose to implement (that look like bugs). To some extent, that's consistent with the SIP intermediation story, which is dominated by policy. From nobody Mon Jul 19 10:37:49 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6D73A142F for ; Mon, 19 Jul 2021 10:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9QKzCzkujv7 for ; Mon, 19 Jul 2021 10:37:43 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D337A3A14A3 for ; Mon, 19 Jul 2021 10:37:42 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EA5A9548049; Mon, 19 Jul 2021 19:37:35 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id E2A5E4E7AB6; Mon, 19 Jul 2021 19:37:35 +0200 (CEST) Date: Mon, 19 Jul 2021 19:37:35 +0200 From: Toerless Eckert To: Martin Thomson Cc: edm@iab.org Message-ID: <20210719173735.GC24216@faui48e.informatik.uni-erlangen.de> References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> <20210716231731.GR24216@faui48e.informatik.uni-erlangen.de> <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 17:37:48 -0000 On Mon, Jul 19, 2021 at 10:03:30AM +1000, Martin Thomson wrote: > > > On Sat, Jul 17, 2021, at 08:37, Toerless Eckert wrote: > > So put all the text about undesirable middleboxes into a separate section, > > including the conclusions about encrypted protocols, because i don't > > think the document has arguments about encryption applicable to b). > > I just reviewed the document and while there is mention of the multi-participant problem in a few places, the only substantive pieces are a dedicated section on the subject (which I think is worthwhile) and a separate section that mentions cryptography as a means of controlling participation. I think that it is OK as it is. I stand by my suggestion for better structurin by categorization of cases, such as with unplanned middleboxes. > > The example problem with the IP version extension point was > > one of c) - unplanned middleboxes. > > Routers are not unexpected protocol participants in IP. What was unexpected there was that routers were forwarding v6 packets without understanding any of their contents. "IP's version field was rendered useless when encapsulated over Ethernet, requring a new ethertype with IPv6 [RFC2462], due in part to layer 2 devices making version-independent assumptions about the structure of the IPv4 header." Aka: yes, routers are not unplanned middleboxes, but in -04 you wrote about layer 2 devices, not routers. Btw: A pointer or more elaboration about that incident would be nice, because i do not remember this type of incident with L2 devices. > Maybe this is a problem with approaching it from the perspective of the number of participants. The key point is that other participants might not allow extension, regardless of how many participants there are. The corollary is that more participants increases the chances that extension is blocked by a participant. The supporting observation is that sometimes there are more participants than you might have expected. Indeed. And "participant" again has multiple aspects: - how many participants are allowed in a protocol communication - how many implementations are there - how many versions of implemenations are there - how many different operators deploy a subset of the participants In IP for example, the upper bound of participants in a communications is arguably 255 (TTL expiry of a packet), but the total number of implementations * versions * operators is much much larger. And this doesn't take into account unplanned participants. > I think that's a clean argument construction. Right. And my explanation above was trying to show a worst-case example of why the number of participants alone isn't even an upper bound for the complexity of the problem when you have a popular, widely implemented/deployed protocol. > The unexpected participation observation doesn't really apply to the IP version example as you have to expect that every router on path needs to participate. The >>2 corollary applies in full though. > > > The more fundamental reason for this proposed characterization > > of some metric for difficulty of extension points (depth inside > > state machinery) is of course experience from testing suites and code > > coverage measurements. The deeper the extension point in the state > > machinery, the more code in the suite you need to get it covered. > > I don't think that necessarily holds. When we built QUIC, one of the most difficult pieces of code to build is the transport parameters. It's right at the end of a long sequence of things that you need to get right with a bunch of interactions between encryption levels, transport stuff, TLS internals, and 0-RTT interactions. It's about as deep in the state machine as I have ever experienced in building protocols. Can't well comment as i do not know QUIC, but if there was something like a decision tree over the extension poins with probabiliies on reaching any leaf based on practical experience with deployments, then i wold not be surprised if many leafs have a 0% probability to be reached in todays actual deployments, and those leafs of course are the mayor concerns if/when they would get used in the future. Cheers Toerless > QUIC transport parameters are nonetheless pretty completely reliable as a means of extending the protocol. Maybe it's just because it is early days, but my belief is that it is the fact that we already have lots of uses of extensions that rely on them: https://github.com/quicwg/base-drafts/wiki/Temporary-IANA-Registry#quic-transport-parameters > > On Sat, Jul 17, 2021, at 09:17, Toerless Eckert wrote: > > On Fri, Jul 16, 2021 at 06:06:17PM +1000, Martin Thomson wrote: > > > Just one note. Throughout you mention authentication where the draft uses the word "cryptography". My understanding of cryptography is that it encompasses a broad discipline that includes encryption and integrity protection and authentication and a bunch of related things. Are you perhaps reading that word with the narrow meaning of "encryption"? > > > > https://en.wikipedia.org/wiki/Cryptography > > "More generally, cryptography is about constructing and analyzing protocols > > that prevent third parties or the public from reading private messages" > > https://en.wiktionary.org/wiki/cryptography is a better match with my understanding: > > > The discipline concerned with communication security (eg, confidentiality of messages, integrity of messages, sender authentication, non-repudiation of messages, and many other related issues), [...] -- --- tte@cs.fau.de From nobody Mon Jul 19 10:43:25 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256C03A1691 for ; Mon, 19 Jul 2021 10:43:24 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA8hQeElGz8t for ; Mon, 19 Jul 2021 10:43:19 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BBC3A1688 for ; Mon, 19 Jul 2021 10:43:09 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id k4so23031236wrc.8 for ; Mon, 19 Jul 2021 10:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FI/3s3+m4o0z7QUez95JArNvkLTOOcO3KXYhunwhUSw=; b=qypuK912Qg8PTMKlTbm67lTx7mAflRFOcnlTuYRVR8V4SZ0hyY3nLqtxfyKRhpdUb8 YDaK7kdo62yWIvmWLzco/I4vy2CGJduKchFxWz9cMZ5zFEKSn0fyxHoA2l9v0oyJDEAJ PpQjEJchF7GgXk8ufnPxuwFa4DTtYO7FgPD+5XN5ZMg5E6LRcH7V7BvlESO5nYUwZT9J 7WXCpfoDw0qtcwTiUbDuSd6VDwhQyApOlNI749NP2OfjPGkRpNU+9WZiw9TiqXi1rReW y2K+RurgnjCuFi3tW7LvN5YaQl3zq6FrAMGw/RT5TMa8jC9cbrXQ7AyGwMerTGaOmVL0 Rx/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FI/3s3+m4o0z7QUez95JArNvkLTOOcO3KXYhunwhUSw=; b=fXD6kM6lYC+74RAvxg4p4OGppoDUo8aPtakOsDxmhqrBADJ7VCb0xv7zHlpzcWC5up Y0a5pfdUs9NFmiO8ZWFI60RDdEqnyAQQzIMx0WdvrsiIjoFyGWHrm7GOKnem/tbbWu6y gveK4lkm4RxJ+pdi+42V+VGU040t1hywDzLTS7/uB3mxjS8F9fhrnSx0bIeV3r6DrxhF osfGl/Y2+4bB0YBdLyMayv+vgHlLZAlrSrqy+re8b1XXQr/v0uivRSLWXKvTyJU18BRc mwtoNqxMJJQPTb0u+YGsEITyBgi6D8QdNZeq9w0OAN9cd9MdyBc3Tvnnx8FrVP2rQrOR 9aqQ== X-Gm-Message-State: AOAM531J1Hc8sFm9dY71xa2P/tThd+q6XYCa6o9XQ6oBjJZx673CDUyL X8B3X68JPyQDo+ynN/6nan0= X-Google-Smtp-Source: ABdhPJyBS+6mAf7rRdQntO1mYb7nAyzy/8x8Pr1SdfkhZDiBN9m8kcaQC1GxGHI15DRAQrexHgjLDA== X-Received: by 2002:adf:c849:: with SMTP id e9mr31352126wrh.348.1626716586254; Mon, 19 Jul 2021 10:43:06 -0700 (PDT) Received: from [192.168.8.200] ([148.252.128.226]) by smtp.gmail.com with ESMTPSA id d24sm117279wmb.42.2021.07.19.10.43.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jul 2021 10:43:05 -0700 (PDT) From: Stewart Bryant Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_82DC4574-8D72-44DD-9904-EEB06DD8E24D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Mon, 19 Jul 2021 18:42:57 +0100 In-Reply-To: <20210719173735.GC24216@faui48e.informatik.uni-erlangen.de> Cc: Stewart Bryant , Martin Thomson , edm@iab.org To: Toerless Eckert References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> <20210716231731.GR24216@faui48e.informatik.uni-erlangen.de> <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com> <20210719173735.GC24216@faui48e.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 17:43:24 -0000 --Apple-Mail=_82DC4574-8D72-44DD-9904-EEB06DD8E24D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 Jul 2021, at 18:37, Toerless Eckert wrote: >=20 > "IP's version field was > rendered useless when encapsulated over Ethernet, requring a new > ethertype with IPv6 [RFC2462], due in part to layer 2 devices making > version-independent assumptions about the structure of the IPv4 > header.=E2=80=9D If vendors with a large footprint ignore standards all bets are off. The same applies to open source but there is even less pressure for them = to abide by the standards. - Stewart --Apple-Mail=_82DC4574-8D72-44DD-9904-EEB06DD8E24D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 19 Jul 2021, at 18:37, Toerless Eckert <tte@cs.fau.de> = wrote:

 "IP's = version field was
  rendered useless when encapsulated over Ethernet, = requring a new
  ethertype with IPv6 [RFC2462], due in part to = layer 2 devices making
  version-independent assumptions about the = structure of the IPv4
  header.=E2=80=9D

If vendors with a large footprint = ignore standards all bets are off.

The same applies to open source but = there is even less pressure for them to abide by the = standards.

- = Stewart


= --Apple-Mail=_82DC4574-8D72-44DD-9904-EEB06DD8E24D-- From nobody Mon Jul 19 12:31:55 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE393A3CB2 for ; Mon, 19 Jul 2021 12:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 dHKzAG1Q5fQP for ; Mon, 19 Jul 2021 12:31:49 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D323A3CB3 for ; Mon, 19 Jul 2021 12:31:49 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B08C7548056; Mon, 19 Jul 2021 21:31:42 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id A3C774E7AB8; Mon, 19 Jul 2021 21:31:42 +0200 (CEST) Date: Mon, 19 Jul 2021 21:31:42 +0200 From: Toerless Eckert To: Stewart Bryant Cc: Martin Thomson , edm@iab.org Message-ID: <20210719193142.GH24216@faui48e.informatik.uni-erlangen.de> References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> <20210716231731.GR24216@faui48e.informatik.uni-erlangen.de> <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com> <20210719173735.GC24216@faui48e.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 19:31:54 -0000 On Mon, Jul 19, 2021 at 06:42:57PM +0100, Stewart Bryant wrote: > > > > On 19 Jul 2021, at 18:37, Toerless Eckert wrote: > > > > "IP's version field was > > rendered useless when encapsulated over Ethernet, requring a new > > ethertype with IPv6 [RFC2462], due in part to layer 2 devices making > > version-independent assumptions about the structure of the IPv4 > > header.” > If vendors with a large footprint ignore standards all bets are off. > The same applies to open source but there is even less pressure for them to abide by the standards. I think the problem is less "ignoring standards" but implementation bugs by developers implementation fix and release latency and deployment latency of operators. That is all business as usual and overwhelming, so i am not sure one would need to talk about obnoxious behavior, like knowingly "ignoring" stuff. Cheers toerless From nobody Mon Jul 19 14:03:37 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD453A0978 for ; Mon, 19 Jul 2021 14:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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] 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 ZNG48_kuXLVv for ; Mon, 19 Jul 2021 14:03:31 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684F33A0976 for ; Mon, 19 Jul 2021 14:03:31 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id 21so17707954pfp.3 for ; Mon, 19 Jul 2021 14:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lizWgVSHzJAqjnUht1xZjjbamne68AC+6qQdNdehqkw=; b=XdAj37tjmgyZFv2q7377ZBvKyPV/OQQlQRKcm9E2b8OOhjiYkE9TVtHblaJ/4s4paa DR4jgxeDheHVP5y4Ol940zINNdbAwF61HFhOk+xgWfuEe+3vucgJudMDsTuYFTnQdJs9 ZWkovd/cv3ViQYgUKuEzUugbeDlTMneJUvYAVjoot8R/F5LTFrQBVsXn9N2IYIC/o/qm hnOW0+xmsvYzl2I63bau/S9zSkFDmNx0ybEwuq0kyQFHHUCn7eKcvLvA0EhkH2wGNMBS aAAw1ZU/KVt+9h5DYTGKR57Dr8MDCcr+UIpoSsWt8IuhhI6jHfl5ubRLliUdy+qjfZix x7nA== 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=lizWgVSHzJAqjnUht1xZjjbamne68AC+6qQdNdehqkw=; b=YHTTd/UvKZITEtBhsz5p1/OnmE7c/C+tCT5LPG6pdotPNlrwGM9j/2TLArmly1DalI eXLaupZd3eOXLCytlUCyppUgh6+YKUTXvBoxxHnUItIh93ghR4XW2LNSg+FT9em8Nf3v ybQbjryQlbKNLhYCU41CalUAc45IBNwOQBBAQFilo/J0GpVq+RLt/hY/mNgFDcmXJZsP H9Oyz6BS0roIqdu5z7QKA8A4d7WvIb5w+qKtQM6+pnJl2QCAyxHdA6CSy8UcZViKpq0p iQiZcu+VLLdfhYPB5SzYIYWjxDbampNqSgfO2ASbsLKAhrnL3o2rZ4BlnWc1L8yGEzk5 DWhQ== X-Gm-Message-State: AOAM531p3cmNj6kkZVQp+xYenII1YAHEIr4P3QDJbceSFfRw0j3SLZL7 NRItWoIUvKNNJZLA9G10weKB8q+Y5OKnlQ== X-Google-Smtp-Source: ABdhPJwn/xNPeZ3j5lejndVdQZgJ0jVyU8rFkLXXIHb76tD761yeppIVJBZvJm8a7AuJPchxG089vQ== X-Received: by 2002:a63:1d47:: with SMTP id d7mr15639169pgm.44.1626728609881; Mon, 19 Jul 2021 14:03:29 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id j6sm17581746pji.23.2021.07.19.14.03.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jul 2021 14:03:29 -0700 (PDT) To: Martin Thomson , Toerless Eckert Cc: edm@iab.org References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> <20210716231731.GR24216@faui48e.informatik.uni-erlangen.de> <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com> <9a5eec9d-90ae-ffd3-fc83-00e3800d7f9c@gmail.com> <5d0baa69-8634-49de-bed3-cc8467c5e34f@www.fastmail.com> From: Brian E Carpenter Message-ID: <28895b98-f412-e3bb-810f-c6aabb718619@gmail.com> Date: Tue, 20 Jul 2021 09:03:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <5d0baa69-8634-49de-bed3-cc8467c5e34f@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 21:03:36 -0000 On 19-Jul-21 14:24, Martin Thomson wrote: > On Mon, Jul 19, 2021, at 11:54, Brian E Carpenter wrote: >>> The unexpected participation observation doesn't really apply to the IP version example as you have to expect that every router on path needs to participate. >> >> Not really. That's what Router Alert is all about. I'm saying it is >> much of a success, but it recognized from the start that not all >> routers are equal. >> >> The ineffectiveness of both RFC2113 and RFC2711 illustrates that there >> is fundamentally no difference between IPv4 Options and IPv6 Extension >> Headers in this respect. The network is equally ossified and opaque to >> new ones in both cases. > > Oh, the options/header extension mess is multi-dimensional. I didn't get the impression that misuse at the root of the problem, I don't think so. There is a 3-way tussle here between the realities of line-speed routing hardware, a tendency by protocol designers to assume that routers are general-purpose computers with lots of time to analyse packet headers, and the desire of firewall vendors to block anything suspicious, including anything new. By way of anecdote, when my student a few years ago deployed the SHIM6 header extensions between the University of Auckland and a site in Ireland, we had to circumvent firewall rules at both sites in order to do so; traversing the wide-area Internet was no problem at all. But "greasing" those site firewalls simply isn't a meaningful concept; they *exist* to prevent unknown stuff getting through. The generic issue is that any mechanism that requires an intermediate system to analyse a transport header (or, worse, a payload) at line speed is stymied by unexpected IPv6 extension headers. You can't say "don't do that" when doing so is a requirement, as it is for firewalls and server load balancing to name but two cases. (We tried to fix this problem for server load balancing with RFC7098, but I'm not sure we succeeded.) > though your first reference implies that it might be. I'm not following that work closely to say that it is the only problem here or even if it is the main problem. > > Do you think that it is worth talking about here? A one paragraph contribution that talked about the Router Alert Option/EH might help. if only to highlight how this is not always caused by bugs, but it can be interaction with policies that participants might choose to implement (that look like bugs). To some extent, that's consistent with the SIP intermediation story, which is dominated by policy. I certainly think the point is worth mentioning, if only as a case where greasing probably won't help. Brian From nobody Mon Jul 19 14:16:49 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76133A0A16 for ; Mon, 19 Jul 2021 14:16:46 -0700 (PDT) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMR0Eb8JfIRY for ; Mon, 19 Jul 2021 14:16:42 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287873A0A0D for ; Mon, 19 Jul 2021 14:16:42 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 644B8548056; Mon, 19 Jul 2021 23:16:35 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5725B4E7ABA; Mon, 19 Jul 2021 23:16:35 +0200 (CEST) Date: Mon, 19 Jul 2021 23:16:35 +0200 From: Toerless Eckert To: Martin Thomson Cc: Brian E Carpenter , edm@iab.org Message-ID: <20210719211635.GL24216@faui48e.informatik.uni-erlangen.de> References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> <20210716231731.GR24216@faui48e.informatik.uni-erlangen.de> <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com> <9a5eec9d-90ae-ffd3-fc83-00e3800d7f9c@gmail.com> <5d0baa69-8634-49de-bed3-cc8467c5e34f@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d0baa69-8634-49de-bed3-cc8467c5e34f@www.fastmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 21:16:47 -0000 Sorry, but you folks triggered my "router alert" button, so i have to give you my favourite pitch about it, given how i experienced serious deployment problems for big customers. Twice (not two customers, but for two protocols for many customers ;-) Protocol designs based on router alert (RSVP, PGM) where KILLED because of relying on router alert: Badly implemented router alert. Badly implemented router alerts are IMHO the result of bad router alert IETF specs. Bad router alert specs IMHO are the result of IETF dogma that only the externally visible behavior is worth to specify for a protocol, internal behavior does not impact interoperability. Aka: specs do not say what they IMHO MUST say to get working features (like router alert). Problem is: internal behavior often has subtle externally observable impact, even if just performance differences . And that is what killed router alert in deployments. I.e: routers where punting to slow-path ALL router-alert packets, even though the router alert has a field indicating which protocol it is for. Deployments for RSVP, PGM got killed not because of slow-path processing of RSVP, PGM router-alert on those routers explicitly configured to support this. But on the transit routers in between, that punted RSVP, PGM router-alert even though they didn't have any slow-path need nor code for RSVP or PGM router alert. So they where even killed from those router alert packets in performance. IMHO this could be perfectly well avoided to be standards compliant behavior by writing much harder standards. Especially including MUST text that requires specific performance behavior. Especially performance requirements when you DO NOT support a particular extension !!! Aka: if you receive a router-alert packet for a protocol you do not support and/or have not enabled, you MUST forward that packet at 95% or higher performance as if the packet did not have the router alert. Feel free to call me a hopeless optimist ;-)) Cheers Toerless Btw: I am leaving out the even older source-routing example to take down the Internet. Same issue, different punt reason... On Mon, Jul 19, 2021 at 12:24:57PM +1000, Martin Thomson wrote: > On Mon, Jul 19, 2021, at 11:54, Brian E Carpenter wrote: > > > The unexpected participation observation doesn't really apply to the IP version example as you have to expect that every router on path needs to participate. > > > > Not really. That's what Router Alert is all about. I'm saying it is > > much of a success, but it recognized from the start that not all > > routers are equal. > > > > The ineffectiveness of both RFC2113 and RFC2711 illustrates that there > > is fundamentally no difference between IPv4 Options and IPv6 Extension > > Headers in this respect. The network is equally ossified and opaque to > > new ones in both cases. > > Oh, the options/header extension mess is multi-dimensional. I didn't get the impression that misuse at the root of the problem, though your first reference implies that it might be. I'm not following that work closely to say that it is the only problem here or even if it is the main problem. > > Do you think that it is worth talking about here? A one paragraph contribution that talked about the Router Alert Option/EH might help. if only to highlight how this is not always caused by bugs, but it can be interaction with policies that participants might choose to implement (that look like bugs). To some extent, that's consistent with the SIP intermediation story, which is dominated by policy. -- --- tte@cs.fau.de From nobody Fri Jul 23 16:10:42 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAD53A20D2 for ; Fri, 23 Jul 2021 16:10:40 -0700 (PDT) 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 4vmgmqNAd_Da for ; Fri, 23 Jul 2021 16:10:35 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7141C3A20D0 for ; Fri, 23 Jul 2021 16:10:35 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id g23-20020a17090a5797b02901765d605e14so5692362pji.5 for ; Fri, 23 Jul 2021 16:10:35 -0700 (PDT) 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; bh=cdekeMWbJC0KLvqWP6gCu18Ydl+XPlQWwdifJoLD6n8=; b=BUkreRr6kvkBIcek/VqJMcMLihp5AOWzrWw4agRRshKYRifXbSJT2C4F4jmdV+y216 py+2zRpZ0irsg7EOoMtHEh+VVxGrlJM1XyVl1CgMgEaH0sIIBZvURQoOYZEoe5j7b+8E NzUuzugrf+lV8aeCzgg64/6r0AN5lcxKynR8Kp5RngYFQ13wes1ZuW3dHa7Vvl7VnP5k vBvTb2xGLDVKNBem/FMEoDP9mCW+EhwfbiJ6jaBpvBeBvFIA0lEO7UcVDBEW5JS41Fet OqM9zXSg+VNJtCT/MZOjaStoaiwu/ILZTwopyqgfW3uMWUPZQlT42OzQBzvOhfdLPhft s00w== 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; bh=cdekeMWbJC0KLvqWP6gCu18Ydl+XPlQWwdifJoLD6n8=; b=DRIxDjztkOVl9rXA4Z59f1Mac/O+V1msR4BwqxgZCOygsINi5yqkY65ifJMC5pQL/k 4G/48OG7q9Epy6mCB53QcLm7do03WpWNWop2+R+s7/1HaD2sIP/DfjerqVlTOI1MXHGm Lsc2yEhcQYtf7JOGmf+yyiNIAAtMBR3ySTb7lUoJulI1Z2v0tl6gI51T3WfpQRO0LzOV vFswDlZBirIw9DO8pGHBLJJAb+V+qQgUI6LlkTqZC3ZxRrrPONOOiGGSAgHUqQpAVvBA g76VMUKwxASF6IA/w3dlDONKKYki0V5at9/IbX7Vi0u9A9+AOJXQ8OaAVyFxPqQe0zd4 nzqA== X-Gm-Message-State: AOAM531Un9TXnpBYMtgLNFLCD12GgGEVD4aryTFwlqy8sOcCkTuPLjSN 5dQ29bbR0rC9ZbgbyMZG3hrddm87KFNxtBkAzXEfDoVJnfA= X-Google-Smtp-Source: ABdhPJwGc7H36mScfZma9nTM1D851ZO6lLnw1IxrLOHmrXa+GG6nzathWIH34LFEoaMQtTWJVisgAEcyXh/4gqDfDnE= X-Received: by 2002:a05:6a00:bd6:b029:329:9432:9660 with SMTP id x22-20020a056a000bd6b029032994329660mr6559624pfu.22.1627081833694; Fri, 23 Jul 2021 16:10:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Fri, 23 Jul 2021 16:10:22 -0700 Message-ID: To: Electronic Dance Music Content-Type: multipart/alternative; boundary="000000000000b7c76e05c7d282d8" Archived-At: Subject: Re: [Edm] Scheduling our next EDM call, week after IETF 111 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 23:10:40 -0000 --000000000000b7c76e05c7d282d8 Content-Type: text/plain; charset="UTF-8" Hi, Based on the results, we're scheduling this on Wednesday August 4, 2021 at 21:00-22:00 UTC. This maps to: - San Francisco: Wednesday 4 @ 2-3pm - New York: Wednesday 4 @ 5-6pm - Paris: Wednesday 4 @ 11pm-midnight - Sydney: Thursday 5 @ 7-8am Here's a link with more time zones: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210804T14&p1=224&ah=1 We'll send out video conferencing details closer to the meeting. See you then! David & Tommy On Wed, Jul 14, 2021 at 4:53 PM David Schinazi wrote: > Hi EDM enthusiasts, > > We'd like to schedule an EDM meeting for the first week of August, which > is the week right after IETF 111. The meeting will be virtual (expect a > video conference link in a followup email). > > We plan on discussing > - draft-iab-use-it-or-lose-it > > - draft-eckel-edm-find-code > > - how coordination between implementations can help with EDM > > If you're interested in joining, please send your availability in this > Doodle: > https://doodle.com/poll/4qizgadaxnsg22bs > > If you have other agenda items you'd like to discuss, please reply here. > > Thanks, > David & Tommy > --000000000000b7c76e05c7d282d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Based on the results, we're sch= eduling this on Wednesday August 4, 2021 at 21:00-22:00 UTC. This maps to:<= /div>
- San Francisco: Wednesday 4 @=C2=A02-3pm
- New York: W= ednesday 4=C2=A0@ 5-6pm
- Paris: Wednesday 4 @ 11pm-midnight
- Sydney: Thursday 5 @=C2=A07-8am

Here's= a link with more time zones:

We'll send out vide= o conferencing details closer to the meeting.

See = you then!
David & Tommy

On Wed, Jul 14, 2021 at 4:53 PM = David Schinazi <dschinazi.ie= tf@gmail.com> wrote:
Hi EDM enthusiasts,

We'= d like to schedule an EDM meeting for the first week of August, which is th= e week right after IETF 111. The meeting will be virtual (expect a video co= nference link in a followup=C2=A0email).

We plan o= n discussing
-=C2=A0draft-eckel-edm-find-code
- how coordination between implementations=C2=A0can help with EDM<= /div>

If you're interested in joining, please send y= our availability in this Doodle:

If you have other agenda items you= 9;d like to discuss, please reply here.

Thanks,
David & Tommy
--000000000000b7c76e05c7d282d8-- From nobody Fri Jul 23 17:26:05 2021 Return-Path: X-Original-To: edm@iab.org Delivered-To: edm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD19C3A2315; Fri, 23 Jul 2021 17:26:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF-Announce" Cc: edm@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162708636267.8988.7208701272560033676@ietfa.amsl.com> Date: Fri, 23 Jul 2021 17:26:02 -0700 Archived-At: Subject: [Edm] Evolvability, Deployability, & Maintainability (edm) PROGRAM Virtual Meeting: 2021-08-04 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2021 00:26:03 -0000 The Evolvability, Deployability, & Maintainability (edm) Program will hold a virtual interim meeting on 2021-08-04 from 14:00 to 15:00 America/Los_Angeles (21:00 to 22:00 UTC). Agenda: We plan on discussing - draft-iab-use-it-or-lose-it - draft-eckel-edm-find-code - how coordination between implementations can help with EDM Information about remote participation: https://meet.google.com/ikf-hhrm-kqi