From nobody Fri May 21 15:53:29 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752773A096F for ; Fri, 21 May 2021 15:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nMhSiSbfjiWd for ; Fri, 21 May 2021 15:53:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E683A0969 for ; Fri, 21 May 2021 15:53:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 81AC738D0D for ; Fri, 21 May 2021 19:02:53 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BIku1WwXIENX for ; Fri, 21 May 2021 19:02:53 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EBE5538D05 for ; Fri, 21 May 2021 19:02:52 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9387475B for ; Fri, 21 May 2021 18:53:16 -0400 (EDT) From: Michael Richardson To: gendispatch@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Gendispatch] towards a new series of non-standard documents X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 22:53:27 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am watching the IETF110 GENDISPATCH recording. I watched bits of it in conflict with another WG back in March. I am responding to Klensin's "rant" about 2028. As Keith and others said, RFCs aren't a great place to put some of this. We've had many WGs say that really, they want a working document, and we now have a small trend towards designating certain revisions of IDs as "Implementation Documents" We've had many rants, including Warren's latest, that Internet Drafts are n= ot RFCs, and that not all RFCs are standards. So maybe it is really on us to remove many of the things from our series that aren't even intended to ever be standards. [I will stand mute on topic of ISE, and I suggest you do too, as I think th= at once we figure out what we should be doing, the topic of what to do with ISE will become much easier to decide.] I think it's time to create a new series of documents, which are slightly more official than Internet Drafts (i.e. they represent some kind of consen= sus), but which are not immutable like RFCs. It should be physically possible to patch them easily via git pull request = to the official XML, but the approval of that pull request is probably an IESG action. In many ways, for protocols, these would be the "Proposed Standard" of (very?) old. But, let's not start with that. Instead, lets start that for non-protocol documents (including specifically process documents, but also use cases and requirements documents), this wou= ld be the final resting place. They would have versions. "IETF2028.02", etc. A reason that replacing 2028 is so hard, is because we would feel we have to get it completely, and perfectly right, and the reason we have to get it right is because it's so hard. Recursive logic, yes. We often go on about how stuff should be in web pages, and that's true, but we don't know how to effectively get consensus on a series of hyperlinked concepts. (Wikipedia works at best poorly) At the same time, we don't want to do an IETF LC on a CSS fix. The web site can easily normatively quote this new series, maybe even by XPATH or some magic reference. =2D-=20 Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmCoOdwACgkQgItw+93Q 3WX16Af+P4GKT22LmhvMij9g1OogInCZZGoJ+Bu3/HWU/WI6YtyFlzkxzpLjp6pD SqrlQu3elg1OWIfS86yiyxFNU6geSKfiaxcajBFqXGPVk8OIy3L/esvk09NwsLcb 19AxfyRlZ+LgGVQhOp9PvQUpBrZz28UsM6IgpQK+dIuPXMuG0/0D379sG0qVuZVs Zc1zsRXGzVg7jMfntftTk7YgQ74vhdbq/mFgpUVVqXEqRA7tIHMdXusO06bsX/A6 bYW3/70lvJ723bp3n4uqH+aSsXV9lEgCCNByDwW5rXNdYiMsvQUYma/V6fp7NHIJ ZEqKFLhBlL+hBznGKHmzHe70m8BJdw== =2oDF -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat May 22 16:00:45 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A213A226C for ; Sat, 22 May 2021 16:00:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iyLF9ruO-NU for ; Sat, 22 May 2021 16:00:38 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 844043A226B for ; Sat, 22 May 2021 16:00:38 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 14MMruxs013232; Sat, 22 May 2021 19:00:38 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 38pv5q1257-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 May 2021 19:00:37 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 14MN0Z1Q017016; Sat, 22 May 2021 19:00:36 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 14MN0XVL016229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 22 May 2021 19:00:33 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 110C640145A4; Sat, 22 May 2021 23:00:33 +0000 (GMT) Received: from GAALPA1MSGEX1BA.ITServices.sbc.com (unknown [135.50.89.102]) by zlp30483.vci.att.com (Service) with ESMTP id CBA2340145A3; Sat, 22 May 2021 23:00:32 +0000 (GMT) Received: from GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) by GAALPA1MSGEX1BA.ITServices.sbc.com (135.50.89.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Sat, 22 May 2021 18:59:46 -0400 Received: from GAALPA1MSGETA02.tmg.ad.att.com (144.160.249.124) by GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4 via Frontend Transport; Sat, 22 May 2021 18:59:46 -0400 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.177) by edgeal2.exch.att.com (144.160.249.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Sat, 22 May 2021 18:59:46 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mfoSUytVLQOmGR8nR6RqYl62ihApG9b1Zn8gxWZHKfrFZXn1bB8D67JrSWaMWqZ36ZRJ+GJcYYC/6JyfeqsFKasDywJnjgaS01p/VAk3slEIFyeiEQaNxXLxk2X3hhJxvkLkBs7jiCnxRFQb26YCxNBopvoFjXrp30nNtayjUQ15eJIj6/LuPGMDUxXJ9zPklpX9dnZvL3JBGQVqzn2Nd4PEtBS/exhJZR8f/CWUmVm6hSxMxu98O1ZsWIC+BnOPNqKa7qmv9AdOJ+WLUMFJZfjogJpsmxLmWVuEIYaGNrHCDtucb68WyqpCvVvFHs5YmdWHOyyJPBFSJU0FkCblWA== 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=/i7K2guIywWtcVPZJqHnGFrS+hmMdeO8pgIKxoWXGT4=; b=f/SlNGeb8hEK4zgKRjMcXadWYTKWuGBFW/abXW8UkHCRJvLcMlzkqH3CJ3Reth3Erv9dxMFd8i/hjrmkTXS3H+fr7Dst37PakvjlaDpmTGO5BNpvRD03D+9olIrqKfcdj16jntuvUDuAUXdU/dqZqIZW70YOu4IARytteV4BLkW7uP0uDsewzOwAi9lhaJgx0R5tZP6bOtboaizZ3s8aqBrA3Qxnx0m56oL8/1RoOsG5QcVG670twsj0lp1kvH/VGhIO+fBNQeKqHAfvRDZvqB3FYLG4FHYlaty5Fd+RlEv2CYLdhPTKNpvF3m9EjbwBA7adbXojWNFEnNRpzSk08Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/i7K2guIywWtcVPZJqHnGFrS+hmMdeO8pgIKxoWXGT4=; b=hri2myNak62+Ofzt9622wKr8XNrMUSHqtq1DOpEo2pE/tl9gsDHYWPUF94e05b60sjasWn6oo5RLHyMfafYOSitNRWKkN8TbaGxM4gPWFeacLddprteBg10sPpix0AefN0/91ItDgt1W3DiqI5XavhPAvriY3ZswUuLO5k6Yom8= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM5PR02MB2844.namprd02.prod.outlook.com (2603:10b6:3:109::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Sat, 22 May 2021 22:59:45 +0000 Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d09:83cc:18fe:ab1d]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d09:83cc:18fe:ab1d%9]) with mapi id 15.20.4150.027; Sat, 22 May 2021 22:59:45 +0000 From: "STARK, BARBARA H" To: "'Michael Richardson'" , "'gendispatch@ietf.org'" Thread-Topic: [Gendispatch] towards a new series of non-standard documents Thread-Index: AQHXTpQxo3nrzfM07kmTZjAYBMa7jqrwHXqA Date: Sat, 22 May 2021 22:59:45 +0000 Message-ID: References: <2446.1621637596@localhost> In-Reply-To: <2446.1621637596@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=att.com; x-originating-ip: [45.18.123.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 80d910af-65f6-4a95-5428-08d91d754b10 x-ms-traffictypediagnostic: DM5PR02MB2844: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3OM0qlWAfQpvgSB/BSgEFNzViJlmAbxOxnRvI0zFGO2JTjSL1XgtO7hbV2BsEq6c36VZHuMyELgI9RoRuhqETt8FhDCaCVLa3nTEkWZCOzNgzdm5Mil1qsUYVcvseMilaOCY8nTgqnXzQ9H7ZYxge2s14/gYEISa8asCG4rl2Dnm2m5U/rcNm1gTMeELKOALkoHFt5+4q91XeONgx3rCy4lRxSA6a5S4mkVz/24MeFPbbOcvuVZzFfhrEjvLGIJBkBxHijKTyKdialcVLxay6jyLe5R929YvQY2DGiBuu1BZLcDNex4qX5Zq3kJcJu/txSFhvC8kBWsE3QHPlRD7AkHFA9ICl9UqYqSF2R49hMJUTJsfUGA7hnhYxWHdQ/2tXSA4CAnB3cDeo2sDxG6FKadhVTwkrMKumsXeKFMBfyfBMcS6Sxavi3OcTU+U4rxzjZAXkbZTDHPCr4HNuAj71Y48UOWyg75TyynTEZylmr6zi0TSNpQlqrMuClEr15A6kmV34KTU08CMeJizRmT571XUei0MYBoKvHzv4NWUThl5Vk452xJFdekC6KMp8771D0esuU+lwvYULRbHj655kUMEtF5b0hAwECyD8ZGTOCxCADFRZmDUjxGvpbXjcKrDn7+2DWBS5pf8k40ngWS77A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(346002)(366004)(396003)(136003)(7696005)(8936002)(71200400001)(26005)(2906002)(76116006)(55016002)(9686003)(6506007)(33656002)(38100700002)(122000001)(478600001)(82202003)(66446008)(110136005)(316002)(5660300002)(64756008)(66574015)(186003)(66556008)(86362001)(83380400001)(66946007)(8676002)(66476007)(52536014)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?35KkIdj8h7HnfKvp4ahRCcpafnXurZdxOhi14jvl8Cneda6i5iXq2KyHA7Me?= =?us-ascii?Q?LodwIwxhZvHMrEPeuK60+ydVsvOOWeBEkPoqfs8ZSkwRkc86R7d19TRqfWiQ?= =?us-ascii?Q?aDrCZ+gnWP49ns//+ZdaXUQL76rWnK4NkhzbZ0022jjZsZIno7mlRPBEBDzb?= =?us-ascii?Q?N0AZyMqdiBYOrm6+7wZcg1qQAuJv9LZJcHIbKcfyvAIq2+degj+8d2K00klI?= =?us-ascii?Q?GNgwgp7VpS3AsyRpODI+DQbTI9OoDrzSfs6gkn59L1GPa5IRS/IPeKtRzpu8?= =?us-ascii?Q?jnHl9eU/VsFuzctfiLU7tWpwK1S+C0509+qk6RCOl2llrfXdswdPY9n0SKXe?= =?us-ascii?Q?BVjAyZhGXY5aKId1ywBMo+fb43bPEQWwbjj5cfAdjHJ06pDyxW4FyLi5J8jx?= =?us-ascii?Q?T0bxsS+A70w0DKWtM3Pv3RCsBUGxPJYGSMPCKvz4UoIAVqs5yBiyLy6EQQqD?= =?us-ascii?Q?JDK+p7Z0SNfMOSNDq9XBq8Cb26AgASY2yPVpUGrpUfToX7sYS2INVfQQVm26?= =?us-ascii?Q?nYsPYvdYNOc1pvyxpkVt4aERB9tiN9MXb5aU9rB7BFBnwNZT49uEtktuIw+L?= =?us-ascii?Q?KagcEXG58wU+jZp/5m1Z3I7Um5hdumef4QI1EyfyFM1aJ5gNqRH62Bo0BUGa?= =?us-ascii?Q?nrUtl1zq70/6NHJmX3H81ygdIZpb62hlRMoHaxbqL7jraNMhnIK0kXb+P67I?= =?us-ascii?Q?xCOsBzTAXjpMJSHc6zEaYVFCc+XPC9eewaXd8wQ8qo+vS9n2g1ff910NUo09?= =?us-ascii?Q?SPKcQfvbNpX4vdyvN6k5JU0+s41EvvtA9GR1vfvvnnhE6QTrLqgwwL65tTek?= =?us-ascii?Q?0mdhPDmugVDbhgCLWY6CIGlotsWg4Wvz2t1f4lTLBqRfJovTfu3NRwkHk4Eg?= =?us-ascii?Q?8yshbksZLTfRcYjwB2oRPwdKoW4dvMvhwUiZucSvLGOuzCTiDfK1DwFyy7t+?= =?us-ascii?Q?DTPbkRRYiy66l0kxcEO/DGZ+F13XN0Jp3ZhW9aaqRFg8at9sDeiMcD01rYyg?= =?us-ascii?Q?dzNOrU5H89N/2bQDuwPhvUDyOpjgrokF12HqWa7LqrU7KdaWKXDlsqN1dkPa?= =?us-ascii?Q?AeC5SWJVupCelKG8ZGg2xJ1dzs8EMa31UvDlWy8Dpqt9UavuJ05SmEI1tl7J?= =?us-ascii?Q?1aRZYgCRrbF0VNUdFn+RssF23mgi9SWUrbXuKSnSHW4ZcHHy0u2Bqlcdha+H?= =?us-ascii?Q?e8tGhCOqRAV4eYV1prA4qfFhiRBmYHBz6/sIkJTYB23SsYMoq5dg3j0BoVZj?= =?us-ascii?Q?G5j2oKDSnjavdH5RisFXLaXAjAHtRRBbAdNmsaATC1kfykwOK47/M365L1im?= =?us-ascii?Q?s7I=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80d910af-65f6-4a95-5428-08d91d754b10 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2021 22:59:45.6430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xfbG+Z2adP6i5LQUwRPoF5STepKWL6MNJwKW170bmTqeQen4xxUKbFd/H/0xWTeN X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR02MB2844 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 216339022FCEC09890FC0CF21E71E79266A67846CD31663477B02DF0B984C5A82 X-Proofpoint-GUID: oja721XVb2jQp41aRaTNmZy7n5M7IGyD X-Proofpoint-ORIG-GUID: oja721XVb2jQp41aRaTNmZy7n5M7IGyD X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-22_08:2021-05-20, 2021-05-22 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 mlxscore=0 spamscore=0 mlxlogscore=961 phishscore=0 impostorscore=0 clxscore=1011 bulkscore=0 adultscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105220169 Archived-At: Subject: Re: [Gendispatch] towards a new series of non-standard documents X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 23:00:43 -0000 > I am watching the IETF110 GENDISPATCH recording. > I watched bits of it in conflict with another WG back in March. > I am responding to Klensin's "rant" about 2028. >=20 > As Keith and others said, RFCs aren't a great place to put some of this. > We've had many WGs say that really, they want a working document, and we > now > have a small trend towards designating certain revisions of IDs as > "Implementation Documents" >=20 > We've had many rants, including Warren's latest, that Internet Drafts are= not > RFCs, and that not all RFCs are standards. So maybe it is really on us = to > remove many of the things from our series that aren't even intended to ev= er > be standards. > [I will stand mute on topic of ISE, and I suggest you do too, as I think = that > once we figure out what we should be doing, the topic of what to do with = ISE > will become much easier to decide.] >=20 > I think it's time to create a new series of documents, which are slightly > more official than Internet Drafts (i.e. they represent some kind of cons= ensus), > but which are not immutable like RFCs. > It should be physically possible to patch them easily via git pull reques= t to > the official XML, but the approval of that pull request is probably an IE= SG > action. > > In many ways, for protocols, these would be the "Proposed Standard" of > (very?) old. But, let's not start with that. > Instead, lets start that for non-protocol documents (including specifical= ly > process documents, but also use cases and requirements documents), this w= ould > be the final resting place. They would have versions. "IETF2028.02", et= c. +1. Being able to keep an RFC number the same when providing an updated spe= c would be awesome. And being able to provide timely updates (< 1 year) would be a dream. I'd l= ove to see this idea gain traction. Barbara > A reason that replacing 2028 is so hard, is because we would feel we have= to > gut [sic I think: s/get/gut] it completely, and perfectly right, and the = reason we have to get it > right is because it's so hard. Recursive logic, yes. >=20 > We often go on about how stuff should be in web pages, and that's true, = but > we don't know how to effectively get consensus on a series of hyperlinked > concepts. (Wikipedia works at best poorly) > At the same time, we don't want to do an IETF LC on a CSS fix. > The web site can easily normatively quote this new series, maybe even by > XPATH or some magic reference. From nobody Sat May 22 16:10:22 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BA23A22AE for ; Sat, 22 May 2021 16:10:20 -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, FREEMAIL_FROM=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 k4heCqWHzgki for ; Sat, 22 May 2021 16:10:15 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 A489E3A22AD for ; Sat, 22 May 2021 16:10:15 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id p7so20868935wru.10 for ; Sat, 22 May 2021 16:10:15 -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=3NdEYEICR/GxrwQcr685t8FBYRUnbOp3q5Nt2iK0f/0=; b=h+mYkV+fUnDFzRVv7d1Cp2J3a+lNRzIcPPTspnAU6NoweSAnkJw73D4+7YBJIu/06C bO0aiYqP3HqL4poGVxVUs+l2+qi49GJoisw+no55W6SR9wxaPKUlDrzYeD0IAT1zf/Gu GzHGAb0zmlWxABEJmL/jvdaxTTAZPFfkfyl+Y9rRpsf6E/+xse7Sqi+pCPA9Wkav7jUA hzeX3N7jd4xkYk63owDMLIcH80nARC3gAySH9ok9NHVwr4dKUWWfgxF9h0O0mcuSqbyp oHvaKM+ispQwW6tjYdiV90Glhtd4KARCeBWXYFKFUVyqNC96eWB3vFbSBK8lLgwQ0pXx EYDA== 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=3NdEYEICR/GxrwQcr685t8FBYRUnbOp3q5Nt2iK0f/0=; b=iOAtW7IXXDHe8sPJf0BbcQk0iTY6P3xQ76hUS3lmzfhySjCh+yfU3y5EONpQogjlqE Mqb7m53jW9GatoMFFe4dJlF0AOmrxGnWrvo6SRmSI092FZNzdK8ZgLnI6KQezM2by2Yf g+9Jf9V/9NDviuGUTTXYbTvcCJ+s7laCENCUQ3fc1atdF/Xp7HMsoARxsHhk35GuAuBi C+TToVSbj8GTshqI5AgFAerMfJeGXeQXhTvcZQ9rl4LCkTEeTIAzhIT8SrSQ34/F2B2t EzQ8asMgVZSy9y0svTVokrsLDfCgreXOahJYlM58azdz7k8ZPKXwTYA7+kQ+7+ld38UH 5i0g== X-Gm-Message-State: AOAM533mLTxd3LD5yLnu4s85ZkFzkIjKtg5ppr0Rlx2ewOFLss78MW0y yvCUOp9TXENiFwckhM5I4Sk= X-Google-Smtp-Source: ABdhPJzGsJDsIni7hpRAPN7mgUzsjbdGziYaAL+bTt5obzfP/y5OzVCKyVFL8BvqD8sXvNivn9ZeKA== X-Received: by 2002:a05:6000:1ac7:: with SMTP id i7mr16058334wry.380.1621725013739; Sat, 22 May 2021 16:10:13 -0700 (PDT) Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id z18sm6934336wro.33.2021.05.22.16.10.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 May 2021 16:10:13 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1177AB08-94C5-49B3-8678-14AB42CAF0C2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Date: Sat, 22 May 2021 16:10:08 -0700 In-Reply-To: Cc: Bob Hinden , Michael Richardson , "gendispatch@ietf.org" To: "STARK, BARBARA H" References: <2446.1621637596@localhost> X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [Gendispatch] towards a new series of non-standard documents X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 23:10:20 -0000 --Apple-Mail=_1177AB08-94C5-49B3-8678-14AB42CAF0C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Barbara, > On May 22, 2021, at 3:59 PM, STARK, BARBARA H wrote: >=20 >> I am watching the IETF110 GENDISPATCH recording. >> I watched bits of it in conflict with another WG back in March. >> I am responding to Klensin's "rant" about 2028. >>=20 >> As Keith and others said, RFCs aren't a great place to put some of = this. >> We've had many WGs say that really, they want a working document, and = we >> now >> have a small trend towards designating certain revisions of IDs as >> "Implementation Documents" >>=20 >> We've had many rants, including Warren's latest, that Internet Drafts = are not >> RFCs, and that not all RFCs are standards. So maybe it is really on = us to >> remove many of the things from our series that aren't even intended = to ever >> be standards. >> [I will stand mute on topic of ISE, and I suggest you do too, as I = think that >> once we figure out what we should be doing, the topic of what to do = with ISE >> will become much easier to decide.] >>=20 >> I think it's time to create a new series of documents, which are = slightly >> more official than Internet Drafts (i.e. they represent some kind of = consensus), >> but which are not immutable like RFCs. >> It should be physically possible to patch them easily via git pull = request to >> the official XML, but the approval of that pull request is probably = an IESG >> action. >>=20 >> In many ways, for protocols, these would be the "Proposed Standard" = of >> (very?) old. But, let's not start with that. >> Instead, lets start that for non-protocol documents (including = specifically >> process documents, but also use cases and requirements documents), = this would >> be the final resting place. They would have versions. = "IETF2028.02", etc. >=20 > +1. Being able to keep an RFC number the same when providing an = updated spec would be awesome. > And being able to provide timely updates (< 1 year) would be a dream. = I'd love to see this idea gain traction. I have mixed feeling, but as I understand what Michael is proposing, it = would not be an RFC, hence no RFC number. Bob > Barbara >=20 >> A reason that replacing 2028 is so hard, is because we would feel we = have to >> gut [sic I think: s/get/gut] it completely, and perfectly right, and = the reason we have to get it >> right is because it's so hard. Recursive logic, yes. >>=20 >> We often go on about how stuff should be in web pages, and that's = true, but >> we don't know how to effectively get consensus on a series of = hyperlinked >> concepts. (Wikipedia works at best poorly) >> At the same time, we don't want to do an IETF LC on a CSS fix. >> The web site can easily normatively quote this new series, maybe even = by >> XPATH or some magic reference. >=20 > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch --Apple-Mail=_1177AB08-94C5-49B3-8678-14AB42CAF0C2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmCpj1AACgkQrut0EXfn u6gseQf7ByZ5yw4UKcP3GNg11a7z+TwoLg8+RhEk8iSiqVJ7eodybiS8zPkVUClN ivA3gdjLRuB8AzGykIETtNCBSLIvpsSHkQ55sz3+Uc56YTJdWptaErNpyanXJVF8 221fWOvNON90OkVnfZaDlGyN0ovibUadC/Sme4uUIzPxCD9SmCvIKCkIuZj2877L ge9zclpQ/9RDJM3PRsiGpNKOXDYCUH1X3XfJJ5KSg5ODXNw9xzZ1mqtlEaodSJrB rM7cpbdTtvxQ3pY2PTvRdGuOXukepe3FQ+9jqvSMiPxMrE0AWC5MXjOuZ9bRdJ/i CYR7xR5cwUltqcc7wV7SmsIQwTqs2Q== =QZVd -----END PGP SIGNATURE----- --Apple-Mail=_1177AB08-94C5-49B3-8678-14AB42CAF0C2-- From nobody Sat May 22 16:14:33 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D093A22CD for ; Sat, 22 May 2021 16:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ki9ZQ5AytJ55 for ; Sat, 22 May 2021 16:14:26 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 D20033A22CC for ; Sat, 22 May 2021 16:14:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4FnfSL2h86z6GBd6; Sat, 22 May 2021 16:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1621725266; bh=yt/9yaLPYwBlubIkgTOr/b4DVEPcypaflQGu+HzCbtQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZHzVlK19fs8gYePOGB0D6672RyIZbhJJm6fp+SbcM7G8+3a2R7NeRc/NMBhLxjqei Tljh0f2LdFMx/jBV8AHzfox/CHAeitgFC5+UkBFKOIdFwFRTjXAOFXtK8xCe5WAEP4 qYKeZaD7gnP88A2I3g9Knbw2vTqCnMqVbC5JhMp0= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4FnfSK4Zmfz6G9gj; Sat, 22 May 2021 16:14:25 -0700 (PDT) To: "STARK, BARBARA H" , 'Michael Richardson' , "'gendispatch@ietf.org'" References: <2446.1621637596@localhost> From: "Joel M. Halpern" Message-ID: <6b66a58a-065e-51b4-7a64-e93c131195aa@joelhalpern.com> Date: Sat, 22 May 2021 19:14:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] towards a new series of non-standard documents X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 23:14:31 -0000 On Michael's proposal, I don't object, but I do not see much value in having a series of process documents that are not processed by the RFC Editor. We would still need some sort of development process that leads to an IETF rough consensus and an IESG review. So the benefit does not seem positive. With regard to protocols, I do not want the number staying the same when the content changes. (I dont care if the change is X->X.1->X.2 or X->Y->Z). It is important that if a customer says to be that they want RFC X, I at least have a stable understanding of that. (There is still the issue of exactly which features from something like the SRv6 Network Programming RFC the customer actually wants. But being unclear about the base protocol behavior would be much more problematic. Just because the IETF knows that the customer should want TLS 1.3 and not TLS 1.2 does not mean that is what the customer wants.) Yours, Joel On 5/22/2021 6:59 PM, STARK, BARBARA H wrote: >> I am watching the IETF110 GENDISPATCH recording. >> I watched bits of it in conflict with another WG back in March. >> I am responding to Klensin's "rant" about 2028. >> >> As Keith and others said, RFCs aren't a great place to put some of this. >> We've had many WGs say that really, they want a working document, and we >> now >> have a small trend towards designating certain revisions of IDs as >> "Implementation Documents" >> >> We've had many rants, including Warren's latest, that Internet Drafts are not >> RFCs, and that not all RFCs are standards. So maybe it is really on us to >> remove many of the things from our series that aren't even intended to ever >> be standards. >> [I will stand mute on topic of ISE, and I suggest you do too, as I think that >> once we figure out what we should be doing, the topic of what to do with ISE >> will become much easier to decide.] >> >> I think it's time to create a new series of documents, which are slightly >> more official than Internet Drafts (i.e. they represent some kind of consensus), >> but which are not immutable like RFCs. >> It should be physically possible to patch them easily via git pull request to >> the official XML, but the approval of that pull request is probably an IESG >> action. >> >> In many ways, for protocols, these would be the "Proposed Standard" of >> (very?) old. But, let's not start with that. >> Instead, lets start that for non-protocol documents (including specifically >> process documents, but also use cases and requirements documents), this would >> be the final resting place. They would have versions. "IETF2028.02", etc. > > +1. Being able to keep an RFC number the same when providing an updated spec would be awesome. > And being able to provide timely updates (< 1 year) would be a dream. I'd love to see this idea gain traction. > Barbara > >> A reason that replacing 2028 is so hard, is because we would feel we have to >> gut [sic I think: s/get/gut] it completely, and perfectly right, and the reason we have to get it >> right is because it's so hard. Recursive logic, yes. >> >> We often go on about how stuff should be in web pages, and that's true, but >> we don't know how to effectively get consensus on a series of hyperlinked >> concepts. (Wikipedia works at best poorly) >> At the same time, we don't want to do an IETF LC on a CSS fix. >> The web site can easily normatively quote this new series, maybe even by >> XPATH or some magic reference. > From nobody Sat May 22 16:15:31 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B052B3A22D0 for ; Sat, 22 May 2021 16:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8kB-o5U2kw0 for ; Sat, 22 May 2021 16:15:25 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 EF24E3A22CF for ; Sat, 22 May 2021 16:15:24 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id n10so23967421ion.8 for ; Sat, 22 May 2021 16:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JtpcCYy+XQ/v2BCa8h5K6zJeiYsMuQyBwYyB2iJTfAw=; b=PIPA1vV7ITDqd4Jrgqwie2+q7lvLLmOOQ6BhPVDgx7BkHxUA6Gq7gsgyO4EROhmOHX We6T2OMaodHnwsDv0axXL7FlR98H7mXAkopi8mY2kTFlYXExWeY8p+Mid+zwwXvmBQEK 7d7fb70s1HWpwdZu673OYO455jS/qaI9h3pWU+GoQ3P1ypzZ25iZ2Gw0lBqghsfwqVjr AnWtWE7rTdbsRrsEy9UFe7cLe59rr3zkU7hRTqtTj5vNhdlefBjD+Pkuo5BXs+bLLQXK k/ez1wSFEV0cftcWNWykVjG2eKG5hW9TBlXxURhetsa3QhJ1GCtLxL++RqjwdMDCwu4U kSXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JtpcCYy+XQ/v2BCa8h5K6zJeiYsMuQyBwYyB2iJTfAw=; b=WJas5OBjGEqMmJN1qjm4tLt+WyfT7uNrPa2suL1M/Z1yNl8tsH7rc1x1ILrPcQsCVC vy90MAVFc/szySUT3bXOtlE5piEHV74U2LhLkNlbPO34cxhjUQs95MRlUKqqzg7nLkOY TihnK3d7iAeBkiCCuE8rhHRMar/pCwQGam78w1NqrIftjSHuiOMxHEXGuZDGtriiTFnM NazQayX0jG8YQZTscUSDvYzzJPkq/whqB33HThjU1+bXfBZnAhuCDYrrei32vtbXJTCl 8rih4o3jzSfcjhb9FzbH3ITV6/U9b1/Lx6Ar5sWxPzQL85unEsZztanfuYcarZ8fEvXs AhdQ== X-Gm-Message-State: AOAM532JEQEoZWy19qWpkzlc3ajMUsphkaTHEWaS3KmQ7dhICbsM8SqO L4x8dgg4tYU0tVQSxlEGvBrW8jfxeGFFSnrabAXRuA== X-Google-Smtp-Source: ABdhPJwLFNSdowHr1mGGuEEPynBNCxOXtrEY77w6Ge3TGoQ1vZIFFCbSiza9Qn7j2YGMsAEblILvJgNj4fDT4+PZeVQ= X-Received: by 2002:a6b:5c18:: with SMTP id z24mr6309323ioh.127.1621725323600; Sat, 22 May 2021 16:15:23 -0700 (PDT) MIME-Version: 1.0 References: <2446.1621637596@localhost> In-Reply-To: From: Eric Rescorla Date: Sat, 22 May 2021 16:14:45 -0700 Message-ID: To: Bob Hinden Cc: "STARK, BARBARA H" , Michael Richardson , "gendispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d63e2c05c2f3598c" Archived-At: Subject: Re: [Gendispatch] towards a new series of non-standard documents X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 23:15:30 -0000 --000000000000d63e2c05c2f3598c Content-Type: text/plain; charset="UTF-8" If I may make a suggestion, perhaps we should defer the question of whether this series should have RFC numbers per se. Rather, it might be more useful to ask whether a series of the type Michael is suggesting would be useful, with the properties that: - It has a unique identifier that refers to the current state of the document - There is a way of some kind to refer to specific versions of the document - There is some way to update the document "in place" that is lighter weight than what it takes to publish an RFC. If people think it's not, then it doesn't matter if it has an RFC #. If people think the answer is "yes" (spoiler alert, this is my view) then we could try to work out what would make sense with the understanding that we could address the "is it an RFC" question later. -Ekr On Sat, May 22, 2021 at 4:10 PM Bob Hinden wrote: > Barbara, > > > On May 22, 2021, at 3:59 PM, STARK, BARBARA H wrote: > > > >> I am watching the IETF110 GENDISPATCH recording. > >> I watched bits of it in conflict with another WG back in March. > >> I am responding to Klensin's "rant" about 2028. > >> > >> As Keith and others said, RFCs aren't a great place to put some of this. > >> We've had many WGs say that really, they want a working document, and we > >> now > >> have a small trend towards designating certain revisions of IDs as > >> "Implementation Documents" > >> > >> We've had many rants, including Warren's latest, that Internet Drafts > are not > >> RFCs, and that not all RFCs are standards. So maybe it is really on > us to > >> remove many of the things from our series that aren't even intended to > ever > >> be standards. > >> [I will stand mute on topic of ISE, and I suggest you do too, as I > think that > >> once we figure out what we should be doing, the topic of what to do > with ISE > >> will become much easier to decide.] > >> > >> I think it's time to create a new series of documents, which are > slightly > >> more official than Internet Drafts (i.e. they represent some kind of > consensus), > >> but which are not immutable like RFCs. > >> It should be physically possible to patch them easily via git pull > request to > >> the official XML, but the approval of that pull request is probably an > IESG > >> action. > >> > >> In many ways, for protocols, these would be the "Proposed Standard" of > >> (very?) old. But, let's not start with that. > >> Instead, lets start that for non-protocol documents (including > specifically > >> process documents, but also use cases and requirements documents), this > would > >> be the final resting place. They would have versions. "IETF2028.02", > etc. > > > > +1. Being able to keep an RFC number the same when providing an updated > spec would be awesome. > > And being able to provide timely updates (< 1 year) would be a dream. > I'd love to see this idea gain traction. > > I have mixed feeling, but as I understand what Michael is proposing, it > would not be an RFC, hence no RFC number. > > Bob > > > > Barbara > > > >> A reason that replacing 2028 is so hard, is because we would feel we > have to > >> gut [sic I think: s/get/gut] it completely, and perfectly right, and > the reason we have to get it > >> right is because it's so hard. Recursive logic, yes. > >> > >> We often go on about how stuff should be in web pages, and that's > true, but > >> we don't know how to effectively get consensus on a series of > hyperlinked > >> concepts. (Wikipedia works at best poorly) > >> At the same time, we don't want to do an IETF LC on a CSS fix. > >> The web site can easily normatively quote this new series, maybe even by > >> XPATH or some magic reference. > > > > -- > > Gendispatch mailing list > > Gendispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/gendispatch > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --000000000000d63e2c05c2f3598c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I may make a suggestion, perhaps we should defer t= he question of whether this series should have RFC numbers per se.

Rather, it might be more useful to ask whether a series of= the type Michael is suggesting would be useful, with the properties that:<= /div>

- It has a unique identifier that refers to the cu= rrent state of the document
- There is a way of some kind to refe= r to specific versions of the document
- There is some way to= update the document "in place" that is lighter weight than what = it takes to publish an RFC.

If people think it'= ;s not, then it doesn't matter if it has an RFC #. If people think the = answer is "yes" (spoiler alert,
this is my view) then w= e could try to work out what would make sense with the understanding that w= e could
address the "is it an RFC" question later.
<= /div>

-Ekr


On Sat, May 22, 2021 at 4= :10 PM Bob Hinden <bob.hinden@gm= ail.com> wrote:
Barbara,

> On May 22, 2021, at 3:59 PM, STARK, BARBARA H <bs7652@att.com> wrote:
>
>> I am watching the IETF110 GENDISPATCH recording.
>> I watched bits of it in conflict with another WG back in March. >> I am responding to Klensin's "rant" about 2028.
>>
>> As Keith and others said, RFCs aren't a great place to put som= e of this.
>> We've had many WGs say that really, they want a working docume= nt, and we
>> now
>> have a small trend towards designating certain revisions of IDs as=
>> "Implementation Documents"
>>
>> We've had many rants, including Warren's latest, that Inte= rnet Drafts are not
>> RFCs, and that not all RFCs are standards.=C2=A0 =C2=A0So maybe it= is really on us to
>> remove many of the things from our series that aren't even int= ended to ever
>> be standards.
>> [I will stand mute on topic of ISE, and I suggest you do too, as I= think that
>> once we figure out what we should be doing, the topic of what to d= o with ISE
>> will become much easier to decide.]
>>
>> I think it's time to create a new series of documents, which a= re slightly
>> more official than Internet Drafts (i.e. they represent some kind = of consensus),
>> but which are not immutable like RFCs.
>> It should be physically possible to patch them easily via git pull= request to
>> the official XML, but the approval of that pull request is probabl= y an IESG
>> action.
>>
>> In many ways, for protocols, these would be the "Proposed Sta= ndard" of
>> (very?) old.=C2=A0 But, let's not start with that.
>> Instead, lets start that for non-protocol documents (including spe= cifically
>> process documents, but also use cases and requirements documents),= this would
>> be the final resting place.=C2=A0 They would have versions.=C2=A0 = "IETF2028.02", etc.
>
> +1. Being able to keep an RFC number the same when providing an update= d spec would be awesome.
> And being able to provide timely updates (< 1 year) would be a drea= m. I'd love to see this idea gain traction.

I have mixed feeling, but as I understand what Michael is proposing, it wou= ld not be an RFC, hence no RFC number.

Bob


> Barbara
>
>> A reason that replacing 2028 is so hard, is because we would feel = we have to
>> gut [sic I think: s/get/gut] it completely, and perfectly right, a= nd the reason we have to get it
>> right is because it's so hard.=C2=A0 Recursive logic, yes.
>>
>> We often go on about how stuff should be in web pages,=C2=A0 and t= hat's true, but
>> we don't know how to effectively get consensus on a series of = hyperlinked
>> concepts.=C2=A0 (Wikipedia works at best poorly)
>> At the same time, we don't want to do an IETF LC on a CSS fix.=
>> The web site can easily normatively quote this new series, maybe e= ven by
>> XPATH or some magic reference.
>
> --
> Gendispatch mailing list
> Gendispatch@= ietf.org
> https://www.ietf.org/mailman/listinfo/gendispa= tch

--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--000000000000d63e2c05c2f3598c-- From nobody Sat May 22 16:23:59 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA0C3A231A for ; Sat, 22 May 2021 16:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBvv9iNHCJgL for ; Sat, 22 May 2021 16:23:53 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 5D73C3A2319 for ; Sat, 22 May 2021 16:23:53 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id t11so23907322iol.9 for ; Sat, 22 May 2021 16:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8N4lgAiAIN/pp3w7XHRUoKpjSQmxZuJ+hg5NimpQAVg=; b=0aWN3Qzq1CImXSSvoEqJ3qT6ieJdJnVE+dq9YSOmu2nevFm8m6pkggYN/cLH2/bqjB K2+k9NQdx5apdECTTV79QYkmpQBFKj+T0GoN9hGXYp6zXeJ80UyJp1jRJPVYi6ocbPqL d339DoGIIM8huVXym7WAOAtbSroO+zXa0Hoi6NzJnfbxpcbrfpDDl961gpOhDODKhYwJ QCJvOKnOc2H6q2Yc7lTHExOL7bhRxVLAuod1hv66vxLycU5IgjnfU0u/sY4rNd3xn+D4 5SGhtbk7RWNgtIqqzeqsP8MZL6VVTQZ6Z42487jAQUxtrBqHJPH5t3Ss4XkBD3QlL97J FLNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8N4lgAiAIN/pp3w7XHRUoKpjSQmxZuJ+hg5NimpQAVg=; b=BvXy4BQJ4ZzxV+R+gEgyASohmXUnYsIaRfSEZEkhntyzgVdchEFNtZ+jEGtxSbNFi/ YrGJbB+xdi0nuLN+fOramEeC8XvYH1YvjtOF9MXuEmJAeuvAdrcDIgVBNd/D2G9NlMjH m4Gik88oHzQAyIQRtTQE28w14CZ5M6MRLVsRzo8GziPI2rSs5xOnnZnslDycCxsi7s7C vcJ1DVYrj7p7H7mlzunBXswZHShGvCtxPuEoBKFwKBl3cCA5OrzBj8o4u9Tp4BnouiZW ICHt+Q0VS/ykpbAZgyrxnnID91Lf0T+1YMobWl+LsSNT+eoty1XkyRHniQKGdI4fxln8 Y6sA== X-Gm-Message-State: AOAM530URxpfGhJhxclalfLe4nYv7TRJtKJfuRmBK9XkQmzZ12sL02x4 fe7mN3r4ajO5UT1n7YlCOgHUdjJfr6WTOwQesziRKw== X-Google-Smtp-Source: ABdhPJz1Rb5u42/Pd97lCFQMl5jVhQIHpkjOnRZnOoOjMoYx51ojXju8lr5D6NUGLRgEzTcq5DeX1afkp3n51RDmR8c= X-Received: by 2002:a6b:5c18:: with SMTP id z24mr6333540ioh.127.1621725831979; Sat, 22 May 2021 16:23:51 -0700 (PDT) MIME-Version: 1.0 References: <2446.1621637596@localhost> <6b66a58a-065e-51b4-7a64-e93c131195aa@joelhalpern.com> In-Reply-To: <6b66a58a-065e-51b4-7a64-e93c131195aa@joelhalpern.com> From: Eric Rescorla Date: Sat, 22 May 2021 16:23:16 -0700 Message-ID: To: "Joel M. Halpern" Cc: "STARK, BARBARA H" , Michael Richardson , "gendispatch@ietf.org" Content-Type: multipart/alternative; boundary="00000000000023717105c2f37810" Archived-At: Subject: Re: [Gendispatch] towards a new series of non-standard documents X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 23:23:58 -0000 --00000000000023717105c2f37810 Content-Type: text/plain; charset="UTF-8" On Sat, May 22, 2021 at 4:14 PM Joel M. Halpern wrote: > On Michael's proposal, I don't object, but I do not see much value in > having a series of process documents that are not processed by the RFC > Editor. We would still need some sort of development process that leads > to an IETF rough consensus and an IESG review. So the benefit does not > seem positive. > > With regard to protocols, I do not want the number staying the same when > the content changes. (I dont care if the change is X->X.1->X.2 or > X->Y->Z). It is important that if a customer says to be that they want > RFC X, I at least have a stable understanding of that. (There is still > the issue of exactly which features from something like the SRv6 Network > Programming RFC the customer actually wants. But being unclear about > the base protocol behavior would be much more problematic. Just because > the IETF knows that the customer should want TLS 1.3 and not TLS 1.2 > does not mean that is what the customer wants.) > Hi Joel, I agree with you that it's probably inadvisable to have a set of labels so coarse that, for instance, "IP" at one time pointed to RFC 791 and now it points to RFC 8200. Perhaps a more interesting question is not TLS 1.3 versus TLS 1.2 but rather TLS 1.3 versus whatever we end up calling https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8446bis-01, which is sort of an erratta rollup. It advertises itself [0] as: TLS 1.3 was originally specified in [RFC8446]. This document is solely an editorial update. It contains updated text in areas which were found to be unclear as well as other editorial improvements. In addition, it removes the use of the term "master" as applied to secrets in favor of the term "main" or shorter names where no term was neccessary. I think we *do* want people who are interested in "TLS 1.3" to go to this new document. Do you disagree? If so, perhaps we can draw some policy that distinguishes the inadvisable "IP" case above from this one? WRT to naming and X->X.1 -> X.2, what I've usually had in my head is that: X would always point to the latest version X.1, X.2, etc. would point to specific versions. -Ekr Yours, > Joel > > On 5/22/2021 6:59 PM, STARK, BARBARA H wrote: > >> I am watching the IETF110 GENDISPATCH recording. > >> I watched bits of it in conflict with another WG back in March. > >> I am responding to Klensin's "rant" about 2028. > >> > >> As Keith and others said, RFCs aren't a great place to put some of this. > >> We've had many WGs say that really, they want a working document, and we > >> now > >> have a small trend towards designating certain revisions of IDs as > >> "Implementation Documents" > >> > >> We've had many rants, including Warren's latest, that Internet Drafts > are not > >> RFCs, and that not all RFCs are standards. So maybe it is really on > us to > >> remove many of the things from our series that aren't even intended to > ever > >> be standards. > >> [I will stand mute on topic of ISE, and I suggest you do too, as I > think that > >> once we figure out what we should be doing, the topic of what to do > with ISE > >> will become much easier to decide.] > >> > >> I think it's time to create a new series of documents, which are > slightly > >> more official than Internet Drafts (i.e. they represent some kind of > consensus), > >> but which are not immutable like RFCs. > >> It should be physically possible to patch them easily via git pull > request to > >> the official XML, but the approval of that pull request is probably an > IESG > >> action. > >> > >> In many ways, for protocols, these would be the "Proposed Standard" of > >> (very?) old. But, let's not start with that. > >> Instead, lets start that for non-protocol documents (including > specifically > >> process documents, but also use cases and requirements documents), this > would > >> be the final resting place. They would have versions. "IETF2028.02", > etc. > > > > +1. Being able to keep an RFC number the same when providing an updated > spec would be awesome. > > And being able to provide timely updates (< 1 year) would be a dream. > I'd love to see this idea gain traction. > > Barbara > > > >> A reason that replacing 2028 is so hard, is because we would feel we > have to > >> gut [sic I think: s/get/gut] it completely, and perfectly right, and > the reason we have to get it > >> right is because it's so hard. Recursive logic, yes. > >> > >> We often go on about how stuff should be in web pages, and that's > true, but > >> we don't know how to effectively get consensus on a series of > hyperlinked > >> concepts. (Wikipedia works at best poorly) > >> At the same time, we don't want to do an IETF LC on a CSS fix. > >> The web site can easily normatively quote this new series, maybe even by > >> XPATH or some magic reference. > > > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --00000000000023717105c2f37810 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, May 22, 2021 at 4:14 PM Joel = M. Halpern <jmh@joelhalpern.com> wrote:
On= Michael's proposal, I don't object, but I do not see much value in=
having a series of process documents that are not processed by the RFC
Editor.=C2=A0 We would still need some sort of development process that lea= ds
to an IETF rough consensus and an IESG review.=C2=A0 So the benefit does no= t
seem positive.

With regard to protocols, I do not want the number staying the same when the content changes.=C2=A0 (I dont care if the change is X->X.1->X.2 = or
X->Y->Z).=C2=A0 It is important that if a customer says to be that th= ey want
RFC X, I at least have a stable understanding of that.=C2=A0 (There is stil= l
the issue of exactly which features from something like the SRv6 Network Programming RFC the customer actually wants.=C2=A0 But being unclear about =
the base protocol behavior would be much more problematic.=C2=A0 Just becau= se
the IETF knows that the customer should want TLS 1.3 and not TLS 1.2
does not mean that is what the customer wants.)

Hi Joel,

I agree with you that it's p= robably inadvisable to have a set of labels so coarse
that, for i= nstance, "IP" at one time pointed to RFC 791 and now it points
to RFC 8200.

Perhaps a more interesti= ng question is not TLS 1.3 versus TLS 1.2 but rather
which is sort of an erratta rollup= . It advertises itself [0] as:

=C2=A0=C2=A0 TLS 1.= 3 was originally specified in [RFC8446].=C2=A0 This document is
=C2=A0 = =C2=A0solely an editorial update.=C2=A0 It contains updated text in areas w= hich
=C2=A0 =C2=A0were found to be unclear as well as other editorial im= provements.=C2=A0 In
=C2=A0 =C2=A0addition, it removes the use of the te= rm "master" as applied to
=C2=A0 =C2=A0secrets in favor of the= term "main" or shorter names where no term
=C2=A0 =C2=A0was n= eccessary.

I think we *do* want people who are int= erested in "TLS 1.3" to go to this new document.
Do you= disagree? If so, perhaps we can draw some policy that distinguishes the
inadvisable "IP" case above from this one?

=

WRT to naming and X->X.1 -> X.2, what I'= ;ve usually had in my head is that:

X would always= point to the latest version
X.1, X.2, etc. would point to specif= ic versions.

-Ekr



Yours,
Joel

On 5/22/2021 6:59 PM, STARK, BARBARA H wrote:
>> I am watching the IETF110 GENDISPATCH recording.
>> I watched bits of it in conflict with another WG back in March. >> I am responding to Klensin's "rant" about 2028.
>>
>> As Keith and others said, RFCs aren't a great place to put som= e of this.
>> We've had many WGs say that really, they want a working docume= nt, and we
>> now
>> have a small trend towards designating certain revisions of IDs as=
>> "Implementation Documents"
>>
>> We've had many rants, including Warren's latest, that Inte= rnet Drafts are not
>> RFCs, and that not all RFCs are standards.=C2=A0 =C2=A0So maybe it= is really on us to
>> remove many of the things from our series that aren't even int= ended to ever
>> be standards.
>> [I will stand mute on topic of ISE, and I suggest you do too, as I= think that
>> once we figure out what we should be doing, the topic of what to d= o with ISE
>> will become much easier to decide.]
>>
>> I think it's time to create a new series of documents, which a= re slightly
>> more official than Internet Drafts (i.e. they represent some kind = of consensus),
>> but which are not immutable like RFCs.
>> It should be physically possible to patch them easily via git pull= request to
>> the official XML, but the approval of that pull request is probabl= y an IESG
>> action.
>>
>> In many ways, for protocols, these would be the "Proposed Sta= ndard" of
>> (very?) old.=C2=A0 But, let's not start with that.
>> Instead, lets start that for non-protocol documents (including spe= cifically
>> process documents, but also use cases and requirements documents),= this would
>> be the final resting place.=C2=A0 They would have versions.=C2=A0 = "IETF2028.02", etc.
>
> +1. Being able to keep an RFC number the same when providing an update= d spec would be awesome.
> And being able to provide timely updates (< 1 year) would be a drea= m. I'd love to see this idea gain traction.
> Barbara
>
>> A reason that replacing 2028 is so hard, is because we would feel = we have to
>> gut [sic I think: s/get/gut] it completely, and perfectly right, a= nd the reason we have to get it
>> right is because it's so hard.=C2=A0 Recursive logic, yes.
>>
>> We often go on about how stuff should be in web pages,=C2=A0 and t= hat's true, but
>> we don't know how to effectively get consensus on a series of = hyperlinked
>> concepts.=C2=A0 (Wikipedia works at best poorly)
>> At the same time, we don't want to do an IETF LC on a CSS fix.=
>> The web site can easily normatively quote this new series, maybe e= ven by
>> XPATH or some magic reference.
>

--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--00000000000023717105c2f37810-- From nobody Sat May 22 17:51:53 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37A93A2653 for ; Sat, 22 May 2021 17:51:51 -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 hvXFMT5SU_AM for ; Sat, 22 May 2021 17:51:47 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 DCDC83A2652 for ; Sat, 22 May 2021 17:51:46 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id o21so24073793iow.13 for ; Sat, 22 May 2021 17:51:46 -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 :cc; bh=MW+Whzxnk2PQKa774SL9CTo2GlGdpkHtILMg8USIm6M=; b=q/azqDFaMjwct34poQPSbdg7BCsB44Pl9twjeXsH+nLOMj8WHmM9actN9LwIMw+Usq UoqTmY8Z1neQ6G7lf/Dj9MTImLeHWNLsNDXqRrZ/XOBTKtIPw7nuvOJPCruUuudWY52n aBRUYxo88Wm69NlQWfFyywhq3q3MthH+vTSputEyqDl6D1kBA6dWiMB2Je0AghOT0khc jLICV5AYKBry+mb7Ub/1wvbT2XeRssKYy85WsP8+7YVNLdqzMc7xtjKfK4KOC06qZf28 70gObO6WjKer0pkFQmnCw5Fmnvt+m2tqaBWUfQAUNWIf6rcpf2cT/mFwPoJtTWKL8ywP gUmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MW+Whzxnk2PQKa774SL9CTo2GlGdpkHtILMg8USIm6M=; b=nGC7OjTa2aoDyab/mp+Ns1+XUA3Uc/lXkgJKdBoFdbX/o5tU0UrSsVs0ky1Gdhf3SU hJ4Snq+TtoYm+KWbUusUb+PUI/20Ynh6VfJdFZz3apzuM0cN9pmw6yM6cd61d3s/9mBT IDq96h/MIySKQ9gP4lCw2C02X1Jm1pPMVD6WIU9Tgaa8qUzfPvHM7hcHOQIrt+y3Mo1s Am99n3FsT0Tm8GuWnyRqeZJrslBtmmgzJVAhWnVDQjTmPUfl8cG2YQex9LIf+q64Wn5o 3GkvzN1FtA2sVdWEYLCyufYBWqFhnWBfw8UFQfqCJhX3lr4LN2WFkKGU0aCa0hJyNdqf qUFQ== X-Gm-Message-State: AOAM530LIvmwGcUUiNw2+j0KC+cR9VQjax4+Zm8Mq1sXc7AV9fCm9McX KEGDquIzUs5guEEH/lvNlfpScC9Rcz9TOtEkyzM= X-Google-Smtp-Source: ABdhPJyCJPHskEKxkrA1fqscZ2tc541169a8OkI4ZpMW+lblOGea2mbrdaRZ5/tBaQrbh4VZbgVS9aw4gl491bACtjM= X-Received: by 2002:a5d:8a0a:: with SMTP id w10mr7522901iod.188.1621731105154; Sat, 22 May 2021 17:51:45 -0700 (PDT) MIME-Version: 1.0 References: <2446.1621637596@localhost> <6b66a58a-065e-51b4-7a64-e93c131195aa@joelhalpern.com> In-Reply-To: From: Rob Sayre Date: Sat, 22 May 2021 17:51:34 -0700 Message-ID: To: Eric Rescorla Cc: "Joel M. Halpern" , Michael Richardson , "gendispatch@ietf.org" , "STARK, BARBARA H" Content-Type: multipart/alternative; boundary="00000000000071a96105c2f4b290" Archived-At: Subject: Re: [Gendispatch] towards a new series of non-standard documents X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 00:51:52 -0000 --00000000000071a96105c2f4b290 Content-Type: text/plain; charset="UTF-8" On Sat, May 22, 2021 at 4:24 PM Eric Rescorla wrote: > > > On Sat, May 22, 2021 at 4:14 PM Joel M. Halpern > wrote: > >> On Michael's proposal, I don't object, but I do not see much value in >> having a series of process documents that are not processed by the RFC >> Editor. We would still need some sort of development process that leads >> to an IETF rough consensus and an IESG review. So the benefit does not >> seem positive. >> >> With regard to protocols, I do not want the number staying the same when >> the content changes. (I dont care if the change is X->X.1->X.2 or >> X->Y->Z). It is important that if a customer says to be that they want >> RFC X, I at least have a stable understanding of that. (There is still >> the issue of exactly which features from something like the SRv6 Network >> Programming RFC the customer actually wants. But being unclear about >> the base protocol behavior would be much more problematic. Just because >> the IETF knows that the customer should want TLS 1.3 and not TLS 1.2 >> does not mean that is what the customer wants.) >> > > Hi Joel, > > I agree with you that it's probably inadvisable to have a set of labels so > coarse > that, for instance, "IP" at one time pointed to RFC 791 and now it points > to RFC 8200. > > Perhaps a more interesting question is not TLS 1.3 versus TLS 1.2 but > rather > TLS 1.3 versus whatever we end up calling > https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8446bis-01, > which is sort of an erratta rollup. [...] > > I think we *do* want people who are interested in "TLS 1.3" to go to this > new document. > Do you disagree? If so, perhaps we can draw some policy that distinguishes > the > inadvisable "IP" case above from this one? > Agree that RFC 8200 was a bit aspirational for 2017, but I've also found that a lot of traffic is running on IPv6 as I've tested various TLS 1.3 extensions this year. So, you can't really read RFC 791 and have an up-to-date understanding (although it will often work...). Perhaps it would help to maintain web pages that show evolutions of various technologies (like IP, TLS, etc). For example, it's difficult to understand TLS 1.3 without knowledge of at least a few earlier TLS versions. This would mean maintaining more meaningful records of updates/obsoletes relations, after giving new standards some time for adoption. thanks, Rob --00000000000071a96105c2f4b290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, May 22, 2021 at 4:24 PM Eric Resc= orla <ekr@rtfm.com> wrote:


On Sat, May 22, 2021 at 4:14 PM Joel M. Halpern <jmh@joelhalpern.com> wro= te:
On Michael's proposal, I don't object= , but I do not see much value in
having a series of process documents that are not processed by the RFC
Editor.=C2=A0 We would still need some sort of development process that lea= ds
to an IETF rough consensus and an IESG review.=C2=A0 So the benefit does no= t
seem positive.

With regard to protocols, I do not want the number staying the same when the content changes.=C2=A0 (I dont care if the change is X->X.1->X.2 = or
X->Y->Z).=C2=A0 It is important that if a customer says to be that th= ey want
RFC X, I at least have a stable understanding of that.=C2=A0 (There is stil= l
the issue of exactly which features from something like the SRv6 Network Programming RFC the customer actually wants.=C2=A0 But being unclear about =
the base protocol behavior would be much more problematic.=C2=A0 Just becau= se
the IETF knows that the customer should want TLS 1.3 and not TLS 1.2
does not mean that is what the customer wants.)

Hi Joel,

I agree with you that it's p= robably inadvisable to have a set of labels so coarse
that, for i= nstance, "IP" at one time pointed to RFC 791 and now it points
to RFC 8200.

Perhaps a more interesti= ng question is not TLS 1.3 versus TLS 1.2 but rather
which is sort of= an erratta rollup. [...]

I think we *do* want peo= ple who are interested in "TLS 1.3" to go to this new document.
Do you disagree? If so, perhaps we can draw some policy that disti= nguishes the
inadvisable "IP" case above from this one?=

Agree that RFC 8200 was = a bit aspirational for=C2=A02017, but I've also found that a lot of tra= ffic is running on IPv6 as I've tested various TLS 1.3 extensions this= =C2=A0year. So, you can't really read RFC 791 and have an up-to-date un= derstanding (although it will often work...).

Perh= aps it would help to maintain web pages that show evolutions of various tec= hnologies (like IP, TLS, etc). For example, it's difficult to understan= d TLS 1.3 without knowledge of at least a few earlier TLS versions.

This would mean maintaining more meaningful records of up= dates/obsoletes relations, after giving new standards some time for adoptio= n.

thanks,
Rob

--00000000000071a96105c2f4b290-- From nobody Sat May 22 21:01:01 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C6F3A2BAF for ; Sat, 22 May 2021 21:01:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2REoDSTrbTp for ; Sat, 22 May 2021 21:00:58 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB3E3A2BA9 for ; Sat, 22 May 2021 21:00:58 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id p39so1694747pfw.8 for ; Sat, 22 May 2021 21:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5nGpqRSvR7obn0qsvc48CK93ka4uk1zm37TXhVN8KFk=; b=rn8lXmuLRzHiYtMJnkYAuwmMPNELaReV/8RmP4+z6Pxe6lxZZ9yHUYWCVrUqmuPiAk v4CzuFf/9zx5bq80jQrmeldXGTSQT6BdNWRxBYuJGzzzEpQn+0Up8QdWpLB3f1/68syd NCgNVxmlLtZLROVXWRD138wvwVlO7t02nZOXp8W6H++SFa/7xdvba2GWCCbQGG/P7NMN 26hpHsyufedE/SVu5FMYIuQ6uwwV6NGUNecAVgi7eX0LCKD2ncmEx1WzbcIRUAwBZO90 VuS9G/uN8dJ/QEdGUQ+Pm/hpROKv08G3pIyI20j84DkwFulP8AVmonFBtPnBncG9pTGW BAtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5nGpqRSvR7obn0qsvc48CK93ka4uk1zm37TXhVN8KFk=; b=r3kTj2S5GbvgQH2iTf0w3zHt2tKe5YP/xl3rdVVPtgAmSYPjPnWVmwxjWZIWVpKHxn j1fIpBICbNkGsF8wHW4H/szfUg7wGdlr7MgxRoVm9+rm+FJmp5aqP0GdxuRr6tZ1Nyvn EalGKAp0PmJU5kC8/yQ/BViv2U2kZaLy6jFe8rh3qPeXdpCNdy6IS1pMg2Sq23a8w6Ni ynHOGLs4KEg6MT1ckoktYe8eO6iMSF5O0Ug5C8ChBQdVn/TMWxTLQeD4NoxynxuHY8oe Y4XIPLOY01spBwNqEcKfUQGfQ3zS6jMKhHnpC5+0MJiudeYlEsffcY8ttOz2bZG1hUFD t3NA== X-Gm-Message-State: AOAM531FQo4UmtPVx2/rBmUyx5rj0+vV8xt9pSXDST+aHSOo5CD4cPSs Hqm3FNKJpGdQ/a7Qf81OAvGbGKCQg9T1zw== X-Google-Smtp-Source: ABdhPJwchrb5LODWMzDycNGpwsZIjfAipRCUImXuGIFA+1K47jDoD6iqFebUz4kWrqJsj9ExPZj0UA== X-Received: by 2002:a62:ab14:0:b029:2db:b3d9:1709 with SMTP id p20-20020a62ab140000b02902dbb3d91709mr17689402pff.80.1621742456604; Sat, 22 May 2021 21:00:56 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id v24sm7444827pfn.101.2021.05.22.21.00.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 May 2021 21:00:56 -0700 (PDT) To: gendispatch@ietf.org References: <2446.1621637596@localhost> <6b66a58a-065e-51b4-7a64-e93c131195aa@joelhalpern.com> From: Brian E Carpenter Message-ID: <13b46373-7c69-4d16-caf6-a167cdf715af@gmail.com> Date: Sun, 23 May 2021 16:00:52 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] towards a new series of non-standard documents X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 04:01:00 -0000 On 23-May-21 12:51, Rob Sayre wrote: =2E.. > Agree that RFC 8200 was a bit aspirational for=C2=A02017, but I've also=20 found that a lot of traffic is running on IPv6 as I've tested various TLS=20 1.3 extensions this=C2=A0year. So, you can't really read RFC 791 and have=20 an up-to-date understanding (although it will often work...). >=20 > Perhaps it would help to maintain web pages that show evolutions of var= ious technologies (like IP, TLS, etc). For example, it's difficult to und= erstand TLS 1.3 without knowledge of at least a few earlier TLS versions.= >=20 > This would mean maintaining more meaningful records of updates/obsolete= s relations, after giving new standards some time for adoption. Whether it's a web page or a more traditional type of document, the probl= em for this has always been the large effort needed to (a) create and (b)=20 maintain such resources. Look at the "IPv6 Node Requirements" series for example. It *needs* updat= ing every few months as new IPv6 RFCs and operational experiences accumul= ate. It actually gets updated every 6 years on average, and is currently = 2 years out of date. Look at "Requirements for IP Version 4 Routers". Never been completely up= dated since 1995. (Two small updates in 1999 and 2012.) No doubt there are both better and worse examples, but can we figure out = how we would find and fund the sustained effort to do such work? If we ca= n solve that, I think the questions of format and document numbering woul= d be easy to decide. Brian From nobody Mon May 24 13:40:09 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92F3A041B for ; Mon, 24 May 2021 13:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 B3NpeyG5soOA for ; Mon, 24 May 2021 13:40:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239693A041D for ; Mon, 24 May 2021 13:40:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A929B38A6C for ; Mon, 24 May 2021 16:49:46 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fce3vyUriYCA for ; Mon, 24 May 2021 16:49:45 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D133738A6B for ; Mon, 24 May 2021 16:49:45 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A0D5A83A for ; Mon, 24 May 2021 16:39:58 -0400 (EDT) From: Michael Richardson To: gendispatch@ietf.org In-Reply-To: References: <2446.1621637596@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Gendispatch] towards a new series of non-standard documents X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 20:40:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Let me combine answers to a number of comments. Let me also say that none of these suggestions are new. NEWTRK and others flattened the grass on these trails long ago. I think that this could be an RFC3933 (BCP93) process experiment, although it suggests "1 year", and I think that we'd need about 3-4 months = to get the DT changes made, and we'd need to let it run for about three years, and we'd have to decide for each document, what to do in the case that the experiment failed. My gut instinct is that there are about three weeks of DT work that needs t= o be done, and then 2-3 days of tweaking every 3-4 months. I think that we could probably get RFC2028 respun (maybe into 2-3 cross-referencing documents) into such a new series in a matter of a few months. The first respun would be less than perfect, but incrementally better than what we had. Some of the win would be that the holder of the p= en wouldn't be facing a three year effort to get it across a distant finish li= ne. STARK, BARBARA H wrote: >> In many ways, for protocols, these would be the "Proposed Standard" = of >> (very?) old. But, let's not start with that. Instead, lets start >> that for non-protocol documents (including specifically process >> documents, but also use cases and requirements documents), this would >> be the final resting place. They would have versions. "IETF2028.02= ", >> etc. > +1. Being able to keep an RFC number the same when providing an updat= ed > spec would be awesome. And being able to provide timely updates (< 1 > year) would be a dream. I'd love to see this idea gain traction. Well, I don't propose for them to be RFCnumbers, but a new series. I think it would be reasonable for this new series to be able to pidgin against RFCnumbers though, but not replacing them. Joel M. Halpern wrote: > On Michael's proposal, I don't object, but I do not see much value in > having a series of process documents that are not processed by the RFC > Editor. We would still need some sort of development process that > leads to an IETF rough consensus and an IESG review. So the benefit > does not seem positive. I would would this series to involve the RFC-editor/RPC. It would still represent IETF rough consensus and go through an IESG review. We would need to establish referencing rules. Clearly it could make normative references to RFCs (and other external enti= ties). This series of documents would *certainly* be able to make normative references to other such documents in the same WG, possibly always referring to the latest such document. To me, this obvious situation would be that our current clusters would then become visible in the WG. I think that this would let us realize that we have clusters that might be too "atomic" (like the webrtc) cluster, and permit the WG(s) to split or refactor documents to allow incremental movement to RFC. Whether we allow normative references to other WGs would, I think, be an AD perogative choice, probably in consultation with all the WG chairs. Or some simpler rules. The goal here is conscious awareness. > With regard to protocols, I do not want the number staying the same > when the content changes. (I dont care if the change is X->X.1->X.2 = or > X->Y->Z). It is important that if a customer says to be that they wa= nt > RFC X, I at least have a stable understanding of that. I wouldn't start with protocols for the reason that I think that we have to get some experience. That might mean that this new series of documents wou= ldn't be able to create new IANA registries. Updating existing ones would depend upon the rules for that registry, and these documents would count as IETF Actions, etc. so in most cases that wouldn't be a serious problem. But, getting this exactly right needs a bit of finess, and so I'd want to do these document last, or maybe never. Again, think about this series as being a step between "living documents" in the form of wiki or web pages (which never seem to actually be very live), and written in stone documents like RFCs. Eric Rescorla wrote: > Perhaps a more interesting question is not TLS 1.3 versus TLS 1.2 but > rather TLS 1.3 versus whatever we end up calling > https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8446bis-01, > which is sort of an erratta rollup. It advertises itself [0] as: > TLS 1.3 was originally specified in [RFC8446]. This document is > solely an editorial update. It contains updated text in areas which > were found to be unclear as well as other editorial improvements. In > addition, it removes the use of the term "master" as applied to secre= ts > in favor of the term "main" or shorter names where no term was > neccessary. > I think we *do* want people who are interested in "TLS 1.3" to go to > this new document. Do you disagree? If so, perhaps we can draw some > policy that distinguishes the inadvisable "IP" case above from this > one? > WRT to naming and X->X.1 -> X.2, what I've usually had in my head is > that: > X would always point to the latest version X.1, X.2, etc. would point > to specific versions. I think that "STD" has all the properties here that you want, but the probl= em is that getting to STD remains very difficult, and the industry does not recognize it. Again, I recognize your needs here, and I have them too. But, I want to start with lower hanging fruit. Eric Rescorla wrote: > If I may make a suggestion, perhaps we should defer the question of > whether this series should have RFC numbers per se. No, they would not have RFC number. I suggest "IETFxxxx" or some such moniker. We can bikeshed that later. Would we call RFC8446bis, "IETF8446.02" or not, is another question. Maybe IETF.TLS.8446.02. or non-numbers. > Rather, it might be more useful to ask whether a series of the type > Michael is suggesting would be useful, with the properties that: > - It has a unique identifier that refers to the current state of the > document > - There is a way of some kind to refer to specific versions of > the document > - There is some way to update the document "in place" that > is lighter weight than what it takes to publish an RFC. Yes, these are properties that I'm suggesting. > If people think it's not, then it doesn't matter if it has an RFC #. = If > people think the answer is "yes" (spoiler alert, this is my view) then > we could try to work out what would make sense with the understanding > that we could address the "is it an RFC" question later. "NYARxxxx" =3D=3D=3D Not Yet An RFC My primary aim is to remove our process documents from being so hard to upd= ate. While I think that we want the mechanics of updating them could be as trivi= al to update as a git pull request (against "gitoris.ietf.org" or some such), approval of the pull request would be an IESG action representing IETF consensus. (with subsequent edits from an RPC review...) I think that our other not-to-be-published as Informational RFCs: architectural stuff, use cases, perhaps cryptographic vectors, should go he= re too. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmCsDx4ACgkQgItw+93Q 3WUxnAf/dV74fBOEMeme8AcDbFnOK0xuz+DRDmOghgMEk2I3EWxLeF1o5fsnj0Ix A+lAO3s1L4cIdTQfeGgK4587bq5WaJ/D6GD/NPJSv5BNKEXR2OWXBE4DGNa96QCt vTaPKbXA0gGnTN3jb8auXnteQbCZpxUFK6bBYiNN1mUaR9A1oqpJImr8j1h1Zlts QSA8sr1hiKXUSGHLz4YdFgdIOOn9hhZk0wR6HEgw9JWRA2si0T++9s8+DC0/gZ5Z GZcQHks7BMyFcyWWWMfFL39awBoEBEbJHz8XTbFeLWuVn9zc9H6YE/TOjtPWCBr0 ursrXyVenfNm3jexCVjjTgf0stWFFA== =4BYG -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 27 05:04:55 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60DE3A1AC9 for ; Thu, 27 May 2021 05:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCnXc9bQGx3R for ; Thu, 27 May 2021 05:04:49 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100100.outbound.protection.outlook.com [40.107.10.100]) (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 CBD7C3A1AC8 for ; Thu, 27 May 2021 05:04:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cUEvSWsBc1fmUp2MeL2A4WPwjR4xnBR/oNbq70RtMp0rw5U3doZMCrVju/c28ONNyaVJL50A+fAP8kSt2xkJW3ZscNtKvkaNbPGEHg/0GCgmOOgQOySROKKck1OhgddSNMQL6dAx4/yU9apYhnbKcE5/jEzCqV50x6UXgVxbp2IjECNvlHZjm+5wDylMjUqtaoB/7+hc5WMCiY9siSNL2TXVWdTPq9zG1VzUAqGTIqTaADZwhjOSLrxDLvDQPjYuffjhC139AnKA6ElyM4zQYfbeYtvY4DLDs7bV0bTDLBjCN5ewXk0e2WtNs9a31P0F20R/4Bb7FRSVoCeO8D9S4Q== 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=4w8HYmOGXIk6LEHBvt/eEOF1EffFDe+wKmzipIZd94Y=; b=EtrCvLzawGo8AVYHgYSwUCMYRJrlakpW2Utzcpt6RVY4R5iSXh8qAUwG/kqtKdq8Sm2Lei1Mc8vEUw1jbxUWNo6Lfk5aHs04v3LAiwV3mNsSdCMOOn9qk0EpMo+yLyYUkDJZeMih6aTfarS8EuB9+73J6Ko4cBNxRO3XKj5Vsyz1FWf35wl74ejebtZyX5yJ0rG2D4FVXzZzm0N/LebnUY1CXvYPICKli+/5HCcYBjbX1FaHuf1d00ztMP6N/xJIrDrkMdVShws4RquhLZqCjtrVAhm56nFbCKd7Ll/4pPLSaT/LlFiuJITw7eW9JtbrPQvzHUIPNEK6I8WZPIGJiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4w8HYmOGXIk6LEHBvt/eEOF1EffFDe+wKmzipIZd94Y=; b=vaHCDBOhOt+hYQ/8c0kpBayWB+uqKJxfmgxG1q3w4eNxBEJRI6Kk7zkFbD9wPk+enTzUHdH0wTr5H2vyT1fZT8ms+uX5S8azH/BIl+wNutPhB/XqPGRiORJ8W4PcqEHsaTYtApM5JZNdvc3b3qsPU7uTaBHoujga9XTkwucqrWrTfCpuIuxzsY+ivkquGSwhce9iJbO+x7F+lEq0NbYBWsZ+0SAGYPhFB0ePuU4CXl+reZ6YBBj7b8OK9LzuACWKd7B7mgntDu3f+h2oocMgkgP5nv6M/0TNu9X7FOnbwoR9p5zIQG8Xh+8odAvZUIYElXz7ZqDDHKBd2JojS62MgA== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LO2P123MB4475.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a2::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.21; Thu, 27 May 2021 12:04:46 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::d1dd:5a6f:a08e:6b23]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::d1dd:5a6f:a08e:6b23%7]) with mapi id 15.20.4173.022; Thu, 27 May 2021 12:04:46 +0000 From: Kirsty P To: GENDISPATCH List Thread-Topic: NomCom 2021-2022 Call for Volunteers Thread-Index: AQHXUu5B/ltEdJkgtUS/Yd4jg6WTIQ== Date: Thu, 27 May 2021 12:04:45 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-originating-ip: [51.132.68.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 97ed6bf0-426c-4735-ef7d-08d921079eab x-ms-traffictypediagnostic: LO2P123MB4475: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: o16QMeUANqmm8TliiPv9Gy7CRVwXvF2OY432xtadNxukbfxT2ie8WRq6lRu2fOKx5NKKVDg8BafPsBgz3U/KEMOI50Oxyj7JKjCp3iSkIE2vFzONwLlZvm6y3Ta6MChePXZMZHfQJOF+9JlB9xisu0X8zRUA2XLxhwDcZl6zgJnjFL5N8tl7io5x0SIah5m0XDn0kZel8/mqGNl5hnII+MQD7aKRh80YBivNKC/mKYjgjKWGlnIfssPQRjWXJk1wrINyeogtqPjsKpAcqPXJmhp1JCRrQO6aTLtSpINYz0ZtnIthzpo8x26qbv/ZtZ3z0pdEGvzKnclDWPJVoAPUFIQ78QzAdzUft5pRmLWhjAX7FEm8VpvM3YvgCELJUlnHpwQBnrAHgjl9Jiv41iWASy6830eA1ck1dxxN6J69Q7qhpreHz/zFpJ8jABA6WpXX44UvtibtWrruOP9nelziE9XAOH9EQ6rqR+bLewrMieQkqt+i9AxRMWaGx94G2rhYEBFy5nVBvxpDe99p0KAyxflIlkBEJOt1XmV73rPqBsj+1IFJpZqn3WUZN0CurbgH7XeyoSsdh4FKu0LJl8lIS+ozupleSW63fVSrK6EbzSsZ3ZO0hzOoxw3h24cvQhomwc5AOl2LqjNFviwSLlNJwZBxuiPzd0sX/CAvVfBn07BBNKqQLxfSrU9e21g8FYat3r00/hlreAo7fhy8mf5o3kCA/Lt0IM270cXKbXcO73w= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(136003)(396003)(39850400004)(366004)(6916009)(478600001)(122000001)(4744005)(316002)(33656002)(186003)(38100700002)(5660300002)(71200400001)(26005)(2906002)(9686003)(966005)(8676002)(19627405001)(6506007)(7696005)(55016002)(8936002)(66476007)(66946007)(86362001)(64756008)(66446008)(52536014)(76116006)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?OaTFHw+Xk/ZTVEoq8bM6oxRRoiepa1C2sKU4pnrHb55MIjDX0qszhPf4yQ?= =?iso-8859-1?Q?KzMh9zdne5i04AxpUuiC9S0DloQkkphrDj4k1xgD2NHrCwkXO/HkUzpcN0?= =?iso-8859-1?Q?4zCAErsQqsetyfGGJ27jtCwIbArQhl7/jeNJJsKp8qbDArrUsMKnTc3BHt?= =?iso-8859-1?Q?uxrMywmugyPrKY3uGG/+y+h9jNQ0CQzp2LNz3owmjL/M1Y22mJD543A3a5?= =?iso-8859-1?Q?bmUuav9ZGK0ucI8G6sNK8kSsbx2yZahVdHM5IoRA6XH2t7Ia3npt5EAtQk?= =?iso-8859-1?Q?6xJzi0FvGxbgRCVx27SGPAEcoxBf8vT3qTK1rS3NSPNFlVKN67YK/4HHSJ?= =?iso-8859-1?Q?P1SH3c3IZe+4n+6aCXiDP6VSiM2sX6g2NC3XDT67WA1EzeM0G3AVgmF9JG?= =?iso-8859-1?Q?TAfdhf0bT4nx8w8uXFOsewLB6ccZkEsC0eMN3+Y6RP0ycA+mn6NPwROimO?= =?iso-8859-1?Q?hEnaGNxTQwFcuhAiJfMlXOdEqsF5/9DwfUqyTzu2spAH3kJ2Qi4e12l/OS?= =?iso-8859-1?Q?2SAUn9O9PNxoJug6iQ4IYQxdumVmzAkKSL/a3e3q7C8yu0QD+HImHPnyNF?= =?iso-8859-1?Q?n6PUTTKILwoUJuASAjT5mGdMbJfKt6VMYn5YM7ZE+2yv/ubPZz8yA1eNno?= =?iso-8859-1?Q?2175oute11mZHvpYpbdQzc2dqw/V52gTzscyuQllIkpqTJpCVjMOlzeehH?= =?iso-8859-1?Q?D5Qs9VorWq4H25fpUPU7AOn49nIUQBrg8eTN1LDQ6e1QATWeKwrnZGaeAf?= =?iso-8859-1?Q?gTX6LCg3fPUPbM3ujYSeRHI1ab+4fVVnA7CeWqTK9sh/Dxpr92sQDQAdQ+?= =?iso-8859-1?Q?gUx8+UzI/jPXezjihx4fl17Efw203UOIThcY4AhHzH4V0Kg4gL/cWUVtQe?= =?iso-8859-1?Q?x70vkqW/tjVsKkyW8oYw5vivAEZLA43/naoPd3DA0h82d+4OWxw7560XoS?= =?iso-8859-1?Q?zTBWQr3teAw+Pk17mvt+HToARCSlQO7Wch7ORZrtCf321f9BpnURlw3fyq?= =?iso-8859-1?Q?uSZ+SOK3AFyDqGoNewUyJiMkvU+KMbCWWoez8WcdtXton1P/8DrcbbN4Hv?= =?iso-8859-1?Q?ipjnpA3f8zxn/AdVgnsLS3ceMCTXL8Z2anipk4uF6bM+e6WVquIbzHSmfu?= =?iso-8859-1?Q?LzJ9WpXEHbO6103KR1NZcdK4H1dALQQrS7lNtW+6AXkA/jFUuRA2Be2Gp1?= =?iso-8859-1?Q?1DOmdiTQi0grlfcuZS7GRG7tXECPBqFW+OeYwpaSqm9Zv/yrqWttuTj2pi?= =?iso-8859-1?Q?4Ms/V4dHZC10asksukMo1xvdswLPOc/pjn5xWSgH6rKykfgPan7KjoRdQz?= =?iso-8859-1?Q?y/RLIyDQtBTWakSfmKtuS+WY5GlXjSbqxH+Mb9KaZfaWhCLWk3Y6GoJ6xE?= =?iso-8859-1?Q?QS2cQ5A0yt?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB35993AE59DF052A2DDF0842FD7239LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 97ed6bf0-426c-4735-ef7d-08d921079eab X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2021 12:04:45.9434 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jVI1GpVx/p1nE9Lc5cRjt4/swmsroFgiF7DoFa1aDELHb9PALse2CuhmTdG8RyxE57HpBlewWbsSUi9Y3MAhTw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB4475 Archived-At: Subject: [Gendispatch] NomCom 2021-2022 Call for Volunteers X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2021 12:04:54 -0000 --_000_LO2P123MB35993AE59DF052A2DDF0842FD7239LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As members of the IETF community, you might be interested in the NomCom cal= l for volunteers, which is open now. Volunteering for the NomCom is a great= way to contribute to the IETF. All details are available at: https://mailarchive.ietf.org/arch/msg/ietf-an= nounce/T_WVH96pH-5QVTRqd0yTT1TaPaU/ Kirsty This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB35993AE59DF052A2DDF0842FD7239LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As members of the IETF community, you might be interested in the NomCom cal= l for volunteers, which is open now. Volunteering for the NomCom is a = great way to contribute to the IETF.

All details are available at: https://mailarchive.ietf.org/arch/msg/ie= tf-announce/T_WVH96pH-5QVTRqd0yTT1TaPaU/ 

Kirsty



This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB35993AE59DF052A2DDF0842FD7239LO2P123MB3599GBRP_-- From nobody Thu May 27 08:05:42 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74ECE3A11F4 for ; Thu, 27 May 2021 08:05:41 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESc_eOPmx7jY for ; Thu, 27 May 2021 08:05:37 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF723A11F3 for ; Thu, 27 May 2021 08:05:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4FrWN05M5wz1nwQ2; Thu, 27 May 2021 08:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1622127936; bh=WnlSGqkY34qxV68zMYXmwjTOgmiR9SoHIBh8iIVqkUM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZPlOJoX28HRzjQfYzfoW4pnCXyb4IzavyFapGWj1qXdQVMAeLrgfzOAqqX/rTerLh 0HNZJd8tZFZ8MXYVKdwO4i9+FvuUQVL5Tdh2znlujQVITTJVu+yD2iYfcyW0spFc4R PyoUEWrAWiDot6zcV1kIpspDqtObPRKUB3OsSZi4= X-Quarantine-ID: <3IKKmNZgd9qD> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4FrWN01hhpz1ns7c; Thu, 27 May 2021 08:05:36 -0700 (PDT) To: Michael Richardson , "gendispatch@ietf.org" References: <2446.1621637596@localhost> <22418.1621888798@localhost> <17130.1621975830@localhost> <01845418-2468-92e6-3515-d461b066af46@joelhalpern.com> <30749.1622127653@dooku> From: "Joel M. Halpern" Message-ID: <708f9a1f-3a53-ae2b-30b3-776badccb4f8@joelhalpern.com> Date: Thu, 27 May 2021 11:05:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <30749.1622127653@dooku> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] towards a new series of non-standard documents X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2021 15:05:42 -0000 Michael and I have been chatting about his proposal. I am trying to understand the benefit, as from where I sit the hard part of process changes is getting sufficient (even if rough) agreement. Michael suggests (if I understand him) that making the change process easier may make it easier for folks to accept less than perfect results (which we need.) Conversely, if it is not seen as making it enough easier, I have trouble seeing how this cuts the perpetual process discussion logjams (we bifurcate on most of them.) I believe that Michael and I agree that a related problem is that there is no way to actually work on these things, whatever the publication means. Last message from Michael to me below for additional context with Michael's permission. Yours, Joel On 5/27/2021 11:00 AM, Michael Richardson wrote: > > Joel M. Halpern wrote: > > At the moment, we do not even have a process that can sensibly work on > > process changes. The only way gendispatch can dispatch your request is > > as AD sponsored. > > Well, I haven't gotten to the point of writing a document that could be > dispatched :-) > > > Whcih seems wrong to me. I understand why IETF > > chairs do not want a standing IETF process WG. But without a place to > > work on these things, and thus to figure out what the rough community > > consensus actually is, I do not see a path forward. > > I think that maybe this is maybe one of the huge bugs. > > > PS: I have a process item I am working int he background that will need > > rough community consensus (in my view, the particular thing I am trying > > to fix should not be done by edict from the LLC or IESG.) I am more > > worried about what process we will use to determine rough consensus > > than I am about getting it through the RPC. > > So I'm picking on process documents because I think that: > a) we have immediate need > b) we have great group anxiety about getting all the words *exactly* correct. > (I point to nomcom changes in 2020, mtgvenue, shmoo documents) > c) it removes discussion about IANA actions, and external SDO references. > > It doesn't alleviate the need for having a WG to do work, and probably even a > charter. Actually, I'd like to use charter documents as examples of these > new types of documents. > > {feel free to reply publically} >