From nobody Fri Jul 2 15:06:12 2021 Return-Path: X-Original-To: rfced-future@iab.org Delivered-To: rfced-future@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8EB3A0AB1; Fri, 2 Jul 2021 15:02:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: The IAB , rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162526337903.26814.16071108195958052713@ietfa.amsl.com> Date: Fri, 02 Jul 2021 15:02:59 -0700 Archived-At: Subject: [Rfced-future] rfcefdp - Requested sessions have been scheduled for IETF 111 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 22:03:10 -0000 Dear Eliot Lear, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rfcefdp Session 1 (1:00 requested) Thursday, 29 July 2021, Session II 1330-1430 Room Name: Room 3 size: 503 --------------------------------------------- rfcefdp Session 2 (1:00 requested) Thursday, 29 July 2021, Session III 1500-1600 Room Name: Room 3 size: 503 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/111/sessions/rfcefdp.ics Request Information: --------------------------------------------------------- Working Group Name: RFC Editor Future Development Area Name: Internet Architecture Board Session Requester: Eliot Lear Number of Sessions: 2 Length of Session(s): 1 Hour, 1 Hour Number of Attendees: 60 Conflicts to Avoid: People who must be present: Brian Rosen Eliot Lear Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jul 4 19:24:49 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A3C3A172F for ; Sun, 4 Jul 2021 19:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=MI8CqdI/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JePYVHJC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDOPNQdSYrn2 for ; Sun, 4 Jul 2021 19:24:40 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A540E3A1729 for ; Sun, 4 Jul 2021 19:24:40 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id E4C8D5C00AC for ; Sun, 4 Jul 2021 22:24:38 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Sun, 04 Jul 2021 22:24:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=nhABOX2ONaJOl4TjPlf7GbihI1w8uAf 3v7ivFx83MqU=; b=MI8CqdI/PNifCeE59Cw6IMXbts8VdgETHCBuOpOoqZKLQq/ a7H6/Zwntueiw30m9wHtsz9C1wq97qPFnvyV/DIqf9bia0bp3we+3kziFw3deKJR al4FeXR1ALiRAk78A5NJg0tC5DN3x10M90Myoc6kFQOYV3uR1TwjSYHyEcluzI1S m2NXP1GygwKsXi0SawWQQVQMYQ3Xd00eCKOekNId0ARDxa6GenaJ/1a35oIIlnaG duF5StFiS9jtQWQOSzYGC77rjiMctxHfB9JcUP7lzmybsJVus+Gp+xoWmVykkSSL soNoMGd/cbDoIfZLmxasGq/KQGX7ClalK+LAgfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=nhABOX 2ONaJOl4TjPlf7GbihI1w8uAf3v7ivFx83MqU=; b=JePYVHJCAULIYrRILamJ5f 28SRGk/vjhEzYySEHlY91H96/O8NOfdZBxceIDJe5owmiE57Zj98ETpEVsZzcnBa WSJbn7Fu5Nc099N55NlPDesJ82Ol6tc0gO+NIixeoUaiHPv9U/KiymL6JiLWRSVv tzru2a0QLX25Tv5NrDGeUDgnsPXqgxW2vxN6KNrQHTIx/9GNCL7J/wdN9Q7LKELV UDrmt9gRgjFxPlLmpm311M2137/rROX24MFqOJWn/55IFMzl8WBCdL2GRU0iMrz0 5HlFbT3aLEiGV35rd8tJqre4mkP8QCND0STRI+eVGL7tyQq20SrA5opQ4kRJEpoA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeejfedgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8122D3C0060; Sun, 4 Jul 2021 22:24:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578 Mime-Version: 1.0 Message-Id: <3ab5daad-5036-484e-bb76-0adb73f6cc31@www.fastmail.com> In-Reply-To: <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> References: <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> Date: Mon, 05 Jul 2021 12:24:18 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 02:24:47 -0000 On Thu, Jul 1, 2021, at 02:15, Michael StJohns wrote: > On 6/30/2021 2:18 AM, Eliot Lear wrote: > > The RSWG establishes policy, with input from the community, the RSAB, > > and the RSEA. > > s/establishes/proposes/ please. I respectfully disagree. The goal of this process is to seat the authority in the community, which means RSWG establishes policy. The purpose of the RSAB being only to ensure that the outcome is not unreasonable. I find the "with input from the community" a bit odd in Eliot's phrasing. The goal is to - to the extent possible - have RSWG == community, with the usual caveat that it is more like RSWG \self-selected-subset-of community. From nobody Sun Jul 4 21:31:17 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688A03A1176 for ; Sun, 4 Jul 2021 21:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=itaoyama.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 XuuNmQp04F5u for ; Sun, 4 Jul 2021 21:31:13 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410113.outbound.protection.outlook.com [40.107.141.113]) (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 D22F23A117D for ; Sun, 4 Jul 2021 21:31:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GvNtn9Ot67Tb+6USJyVSk8ch7aY3T0xUKKgf6Ff4y+PbW8haG2oSSsRlgyKFIxEyfv89Z9QVzqgS8tybSNuolqnT9MPgNx4zPRY964Wrm9Fw+hjjqfSGjFFcS/N7UScU1vVJx4pzTsViaov/EE/gO2tl0ovVEfORhyZvJTH5lpWhRBtapsoSTNh5L+E4zteSchQHiWmCsTnAz8HucKA+QF90As09VBqJH+iil9LwHWQm7O2rw7M+z/9EihaGYOzyNk4ddwKWfKdpxOkAh7BdDRMqOUyiDBZak3wTPWVmnpMK2xKzm878neUPfQLzvSMl3C2p8zKMovvzY2F9Eosj4A== 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=5oK02XQMu+Uwc/cE0a36mOfSMLRzL5fWiS1SqBR/ehw=; b=OsascN8BBkD5iqtbAAB+wMNzbFAPf9SGreceUhmnorN3XyNUN8zdKqOxbEWsmKaSbs0BuxXzS3mzxAH+7kT9N6gSAutCZ98xuWiB20OAlQjAGdEVBqj6xvgk3r2c5yiYGMKT13Z/JJrXMIknjzhzPVwks1mzI6+T6BUTf2oR5JXaxZF82mqMI5Pk1TkdEOGEBjUI3ndjB3N2LPFXkq8aC6VbEkZdX+tZnKgUbqq0LVb/LcPub3n1CZddeeO11fAvNNNRhxZApxEJYvmpJdl5RkP1Kn9BRuPvbZlKfGtEHtSiXNye0OjxUYj5iWwif2mEcwM4PCcw1J2NQ92bhDoXwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5oK02XQMu+Uwc/cE0a36mOfSMLRzL5fWiS1SqBR/ehw=; b=GkKlEDOZg5dbIWSlauk1+zpmP6nA/yFB8eBpcrRuk1gCfAYhCXfsuD2XdLr7jTSrQza+oxnV6hHII0vnZFh8TkCV/KhOv+fXXQ0xuNUbXpm1wIqZhN1I1sfR7f1zdMDj4zDrOLMuOokbj4OkiaIELToZKUB3phU7rNR/JspbVkI= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYAPR01MB6089.jpnprd01.prod.outlook.com (2603:1096:402:39::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.23; Mon, 5 Jul 2021 04:31:09 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b%6]) with mapi id 15.20.4287.033; Mon, 5 Jul 2021 04:31:09 +0000 To: Brian E Carpenter , Eliot Lear , Jay Daley , Michael StJohns Cc: rfced-future@iab.org References: <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> Date: Mon, 5 Jul 2021 13:31:04 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.39] X-ClientProxiedBy: TY2PR01CA0018.jpnprd01.prod.outlook.com (2603:1096:404:a::30) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [133.2.210.39] (133.2.210.39) by TY2PR01CA0018.jpnprd01.prod.outlook.com (2603:1096:404:a::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.22 via Frontend Transport; Mon, 5 Jul 2021 04:31:06 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2efa4f4f-6206-452b-a21a-08d93f6db4d2 X-MS-TrafficTypeDiagnostic: TYAPR01MB6089: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1l58WSadNZ5lKoFV0FwbI2Y8O9iOPCBS78gpCDeVq0zpvpb3fv8psA/e0em3W0CakGW3yMRsc2zc1Lf793A5a6bKLUlzjT2F2jU+R1+Un5N8q9mdvCa+raXYsFnMl0TJ5Yrt0ic+jxkHN/P2+UZ8FqfSlVXucwfT52uN5xOhpN0EMQQkX4sed4mnPJblpm2ss4ePiiXVm94HhBr0vHv7v8Z8uhAeVq46bd9aXZiP20Xtxqy3sjH+VuIjEk56Lc2XPq9bcM87zIbRQuw0bpzt0NwS4bOoq010dZIf6ogzoWApJmUT3mg4LbPHIeEdTb9JbtqC67v3+54yeDCl+yZAfqfLfhrUG6tzHS43cXe9PqD31msmG1Ej/Cguf+HX4k3+ryzbXmH44+NZbGe1ZiPUR+5K9gWWBcsUtHUQGvVwf0D4+XttVfk5XinA1zcI95I/gNvRQrLWEm2irRaxIf3hrngtJB9jB07jS1a5YpVVgt+soYz9w75r6qBCq79zRTzYblx7BbxEJkXB7m+alQg/ighSCdg9TeIjjS3naNJO1QVQkT9p01U49Vcifk4eTTLRwE+C1KPIe96D12YSqnG6rMBhGlaD+7eyRQaVDDjGp7Nc+NgKfzAx/KbuAvMgN+C/9P2/ptPZRREqHtd9l9VcbtYmWKZOkXyyBblrgWGEOGbjbObqvs9vJIadkdPrgTncGRwyM5AEirSbh7DFmk1BUDNsGLa8v5dCBc7MYFB9ev9W9tCM2hB1RE48JzWo5AGe0vIbEvFJhzpjI4Dx1cwMzR7+5b2F9Dq3G3CbtzPiCtw= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(376002)(39850400004)(366004)(136003)(52116002)(4326008)(186003)(31686004)(38100700002)(8676002)(66476007)(6706004)(66556008)(66946007)(36916002)(8936002)(38350700002)(5660300002)(956004)(786003)(53546011)(110136005)(86362001)(478600001)(6486002)(316002)(16526019)(26005)(2616005)(2906002)(16576012)(31696002)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TTJ5Ny9JZkQvR05wRXZGNmQwRzdQYnJ2dlF1a21GQnpqU0lJNDQvRTN0ZVFY?= =?utf-8?B?Mm9ITGcva0c3ZFZCR0VXRFRKZnVvRUszUXRxS1V0N2VLYkkzSnJseUVCWGRM?= =?utf-8?B?ZUFqZkZVMGwyYTNLNjE3VUdvMGF3bGVKNmwwZjQraG9pOS9hSkFoYlNsKzZr?= =?utf-8?B?elhJVU5vSTJ4NU1aVzZqTVoxM0JVQ2o2YkxUUmRmVDVtNkNFWlNNK0dQZjVT?= =?utf-8?B?QVFhU25kKzQvOWx1c0VGWUV5Rlk2NlF0dGRZandxWXl6aWtSc2FaV0RoNStk?= =?utf-8?B?S3dkMGgxUGI5RU0rc2NGTVBtdUFaN1FRTWgvMmM4S2VkTGI0UTk1VmQvRWZL?= =?utf-8?B?YWU0d2FnTUZRS0lQSEVSNXBicDVYcVNrN0V4eHdwSHZYWjVoOSt4anZKQkg2?= =?utf-8?B?RlJ0cnMrcFpWUE52SGswQm9QNU5qL1BuRC8vZC8wZm9ybGorN1BsSHhSbzFo?= =?utf-8?B?YWJQMFp3cEI4SDZtRjl6WTQvUHIwNXRaK1U3Qk5wMVJ2dElDaWhJbnEwNXlU?= =?utf-8?B?Rk5KenA1RXltQ1poSEFSR3hBYTUwVUtISDhhQ0FTS0xSMFNzODM1V1QwS0N1?= =?utf-8?B?ZE1FQldXbU5aajNiSG5xdERXdW9XMHE1TS9JNml2OGJNUlYrbXRZaUhRUE1s?= =?utf-8?B?NU1lZE55RTc0MHVvMW1Kd2crNE9VWWwrL1FJdFFSMFBRRHo1ZC9MWFRuMTBn?= =?utf-8?B?dU1uUXdqZGd5WWliTUJYalAzRWNPQVlGamxpbmNLTVlTWExyMWVadlcvejcr?= =?utf-8?B?U3VxTUsyQ0lSUjF3VzJRV0FocW12ckM4ZXM2NC85ekFqWkRHblYrVXJZMDJu?= =?utf-8?B?UmY1OE5zNDFNRVllSUl0Q0dvNmRCMmVLaXRuQ203a0ZIOSsySHlMc3hhWWdR?= =?utf-8?B?TENCamgvc0lqM3BpSGRVZDZJWC9NSkpjSmMrMWpldzJSbmhDSzhFOVgwa2c3?= =?utf-8?B?Nnowa2V5NjRSZmwwcnZMbWhEVCtnSjJQcU1nL21TbXppM3plMHV0aXVocWZX?= =?utf-8?B?eGdhOTh5Q2JDZ0xBdmdaYmVaUEZUZWFidXhSY1Y2My9rWlNLVE9Nb0hVWlpa?= =?utf-8?B?WnkzVmlmVVFYRE8zZWNZdmd4cE9FbGVXNlhRc0RKV2U3eGJsQ0ZOR1d5TnR3?= =?utf-8?B?YTNEd1g3U1VjOXR5OWhubm1EZm1JZlc5MC9zTzNTdklnNnhxVklaYUxTSnJU?= =?utf-8?B?amdoME0zVGxCMDJMY1lFa1hpL1Q1Zm5pS2tucUtvOE54L1JCNWx5K0w1R3JS?= =?utf-8?B?V1BGWGN4S1VjdXNITlVGTDM2UktBQi80d1ZRK09hRVVsckgzcEVORjJmdDMw?= =?utf-8?B?ZmdWVERycDJBOE9LUTF4YlhqZGhoU25EZDdReEJUOXREZENVTFBUNm1jOVl6?= =?utf-8?B?Uks1MWtzdWZkZ3NLdjcvaTUyWWpsaGY4OHA2TVlsZTF6UXhhSmhCN05Eblh1?= =?utf-8?B?OG9VaHB5cElnaWN4RXlpUkJHMmNrOTNRbTBMRlFkQjJtMjdBWk45dE9JS1VP?= =?utf-8?B?OEoxajRXT0ZKbU9lVEpHVDROVkVzSmVFb2Fid3E4NHZnWWNoZEtHcXBMVXE5?= =?utf-8?B?NTZYK1d0QU5LQTluNmdPTU91NktNTU1GeVBkV0lsaDJhQmpxNXBwSENFSXdG?= =?utf-8?B?LzBhNU81aVVMR1dJODhXcHA0SklMUmNFM1lNanlQbndsWURPQVZ0S010V2gz?= =?utf-8?B?eitvRGdYQTYzUlhod2ptcVNFRVJjQ3F5QktaSTBKZVh2NkRpRG5QSnRPL2cx?= =?utf-8?Q?H+phgktivqrUzWzHjhzLtqFYviVds4xKM5CmmKn?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 2efa4f4f-6206-452b-a21a-08d93f6db4d2 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jul 2021 04:31:09.4046 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: CTUxJL8ItCrjXubGfPRYi09ZCFhnm+2xBZYOLeJs75UluJGHZ0bWMIGpD1lvV7D44O2amspuw14nW/wADcWIvg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB6089 Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 04:31:16 -0000 On 2021-07-01 05:57, Brian E Carpenter wrote: > On 01-Jul-21 07:40, Eliot Lear wrote: >> >> Here's the model, slightly tweaked, but the goal is not to wordsmith this model, but rather to explain the relationships with the RPC in particular (e.g., the first two bullets are really just there for completeness; we've covered that ground).  I don't think this text goes into the draft.  We need something that is a bit more elaborated.  But if > people are comfortable with the general approach, then we have a good starting point to develop appropriate text. >> >>> * The RSWG establishes policy, with input from the community, the RSAB, and the RSEA. >>> * The RSAB considers those proposals and approves or returns as appropriate. >>> * The RPC periodically reports to the RSAB on how it is implementing > that policy. >>> * The RSEA provides expertise to the RPC and RSAB on how to implement the policy on an ongoing and operational basis, perhaps raising issues along the way for both the RSAB and community to consider. > > Yes, I think that position's the RSEA's role nicely (and to my mind, fixes the name as RSA because the RSEA is clearly *not* in authority). I'm somewhat worried here. While I agree with Martin Thomson (see separate mail) that it's the RSWG that establishes policy, I think it's important to mention that the RS[EA...] not only provides expertise on how to implement policy, but also on potential new policies, including proposing new policies by themselves. "perhaps raising issues" may have been written to include that, but in my view, it's quite weak. Regards,   Martin. > Brian > >>> >>> If issues arise with particular policies, the RPC still brings them to > the RSAB who interprets the policy, and provides interim guidance to the RPC, informing the RSWG of those interpretations. >>> >> Are there people who are generally uncomfortable with the overall approach?  Please discuss. >> >> Eliot >> From nobody Sun Jul 4 21:52:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF993A1357 for ; Sun, 4 Jul 2021 21:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GztCpCk1N__x for ; Sun, 4 Jul 2021 21:52:12 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F033A135A for ; Sun, 4 Jul 2021 21:52:12 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id i184so2677690pfc.12 for ; Sun, 04 Jul 2021 21:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VVKr0H95nrhH7ddDcVj9nVgnDTyc9rZjwTg52HS58Wg=; b=rv0mZWKHM9/Pwe/G3ViFWTkL16EjVUXTNLNjS/3FbRpjzBZXog4lqBfWaYleTrSgI6 fKB4AaIfnXn3oVv2Y5ptmQ60fHqShbDbmihZuZQuiglwxRrGegq9ekvoEk3aPrqRdiFp 08lSIWIAsyoD/5rj0kCCJjZFrTAf7ioPW/F7SUaxuIkzJBsLWGeep2Ij8+KmEat9Tt2q IeV1m0kvdhAoFnO1MI00rCHqE6+NzK490kr8x+sTjmypOml/IODOtp6n8d155dB7J03y TTBLfh+pwKHkd9H3W282TMZ4l4hZc76YVfO20lCX/vt5xWro3GPwtuDodvjfOmPsDBa4 yKUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VVKr0H95nrhH7ddDcVj9nVgnDTyc9rZjwTg52HS58Wg=; b=V4U9o3/jBD68BmyoHci+I2ZZQSGiHw/U1iaM+fsjjivGf4Ssh2MOwfBvqb1T1FPa6y KotNRxky8dFTmjhHt7FMiz+K7LgkSBSxOoQRR4qp2jxkmDSiHLG4jgNvVsSq3gkDVCl/ 3vI2vG5rgu/x30E11AjyKLdAT6qWvLnjE0V3HDSRU6S5Rx3BF9lUzBkgfN4PjTLERO3O dwbEg/rYioYn8ZTRBo8XiADawAq95nySzMmnWvdRTbJV2SPcdCQ93RGQ3M5taeyQ1t5Y qZ/MVYA19PnhjyXZgZOl/RqgsRkGGHJEX6W/SC510tCIySqi1q9Kl8zcScqnbtkRewSH PQVQ== X-Gm-Message-State: AOAM530aKfKtD1JoxlQMNS+nsEZknUi5E91Q0YmWNiUrNPeGLasxI6rB pv8FcagqY7YGljIYID/UZjlLxtBIvr48hA== X-Google-Smtp-Source: ABdhPJyvvMih5nrX/ZAg7q8qDNdEmSl8ijBTcHC+wfC3ifgG6TIrBv3ivNIBOm1PWNPi9O0VMVJjDQ== X-Received: by 2002:a63:d709:: with SMTP id d9mr13912304pgg.337.1625460730852; Sun, 04 Jul 2021 21:52:10 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id 125sm11146596pfg.52.2021.07.04.21.52.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Jul 2021 21:52:10 -0700 (PDT) To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Eliot Lear , Jay Daley , Michael StJohns Cc: rfced-future@iab.org References: <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> From: Brian E Carpenter Message-ID: <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> Date: Mon, 5 Jul 2021 16:52:05 +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: <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 04:52:17 -0000 On 05-Jul-21 16:31, Martin J. D=C3=BCrst wrote: >=20 >=20 > On 2021-07-01 05:57, Brian E Carpenter wrote: >> On 01-Jul-21 07:40, Eliot Lear wrote: >>> >>> Here's the model, slightly tweaked, but the goal is not to wordsmith = this model, but rather to explain the relationships with the RPC in parti= cular (e.g., the first two bullets are really just there for completeness= ; we've covered that ground).=C2=A0 I don't think this text goes into the=20 draft.=C2=A0 We need something that is a bit more elaborated.=C2=A0 But i= f >> people are comfortable with the general approach, then we have a good = starting point to develop appropriate text. >>> >>>> * The RSWG establishes policy, with input from the community, the=20 RSAB, and the RSEA. >>>> * The RSAB considers those proposals and approves or returns as a= ppropriate. >>>> * The RPC periodically reports to the RSAB on how it is implement= ing >> that policy. >>>> * The RSEA provides expertise to the RPC and RSAB on how to imple= ment the policy on an ongoing and operational basis, perhaps raising issu= es along the way for both the RSAB and community to consider. >> >> Yes, I think that position's the RSEA's role nicely (and to my mind, f= ixes the name as RSA because the RSEA is clearly *not* in authority). >=20 > I'm somewhat worried here. While I agree with Martin Thomson (see=20 > separate mail) that it's the RSWG that establishes policy, I think it's=20 > important to mention that the RS[EA...] not only provides expertise on = > how to implement policy, but also on potential new policies, including = > proposing new policies by themselves. "perhaps raising issues" may have=20 > been written to include that, but in my view, it's quite weak. That text isn't the primary part of the RSEA's job description, though. I thought it was OK in the context of this part of the draft. Brian >=20 > Regards, =C2=A0 Martin. >=20 >=20 >> Brian >> >>>> >>>> If issues arise with particular policies, the RPC still brings them = to >> the RSAB who interprets the policy, and provides interim guidance to t= he RPC, informing the RSWG of those interpretations. >>>> >>> Are there people who are generally uncomfortable with the overall app= roach?=C2=A0 Please discuss. >>> >>> Eliot >>> From nobody Mon Jul 5 02:37:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CD23A0CDC for ; Mon, 5 Jul 2021 02:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 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.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlpXSnNGKr1D for ; Mon, 5 Jul 2021 02:37:36 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 579AC3A0CD8 for ; Mon, 5 Jul 2021 02:37:36 -0700 (PDT) Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:dcea:c17:6f09:3eb8]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1659bUBJ063614 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 5 Jul 2021 11:37:31 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625477853; bh=ev/vFV40kqundX+u+9av2gv3P9eniL/17WYbvItYoMw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Ww/JpTQtAEMqlHsPjLXbvTewi3wfsbWVZBT+cAb2bspgYAIU8XeWhHDwcHH+ZBHdi lnlhPyf1FVCwbm670GlNnNTaM5YD8wlwH3m7awnhaLbeOtDdnOr+l7iR883Lz/Royu Y8oOCD/NDZSSMpKTBLmXyqnDXFKfhCVxGyrHumZ4= To: Martin Thomson , rfced-future@iab.org References: <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <3ab5daad-5036-484e-bb76-0adb73f6cc31@www.fastmail.com> From: Eliot Lear Message-ID: Date: Mon, 5 Jul 2021 11:37:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <3ab5daad-5036-484e-bb76-0adb73f6cc31@www.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WvINS4cYuheJdtHbWfEwx25OaQHrfy8BF" Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 09:37:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WvINS4cYuheJdtHbWfEwx25OaQHrfy8BF Content-Type: multipart/mixed; boundary="SCuxzeid5NHEZl92BTiwAZrg5VWUk18XY"; protected-headers="v1" From: Eliot Lear To: Martin Thomson , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 References: <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> <3ab5daad-5036-484e-bb76-0adb73f6cc31@www.fastmail.com> In-Reply-To: <3ab5daad-5036-484e-bb76-0adb73f6cc31@www.fastmail.com> --SCuxzeid5NHEZl92BTiwAZrg5VWUk18XY Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 05.07.21 04:24, Martin Thomson wrote: > On Thu, Jul 1, 2021, at 02:15, Michael StJohns wrote: >> On 6/30/2021 2:18 AM, Eliot Lear wrote: >>> The RSWG establishes policy, with input from the community, the RSAB,= >>> and the RSEA. >> s/establishes/proposes/ please. > I respectfully disagree. The goal of this process is to seat the autho= rity in the community, which means RSWG establishes policy. The purpose = of the RSAB being only to ensure that the outcome is not unreasonable. Again, we're not relitigating the roles here.=C2=A0 This is just a matter= of=20 establishing the relationships relating to RPC.=C2=A0 Don't worry about w= ord=20 smithing at this point.=C2=A0 I didn't intend that text to go into the dr= aft=20 verbatim, but to be the basis of our understanding of those=20 relationships so that text could be written. > > I find the "with input from the community" a bit odd in Eliot's phrasin= g. The goal is to - to the extent possible - have RSWG =3D=3D community,= with the usual caveat that it is more like RSWG \self-selected-subset-of= community. Actually so did I, in retrospect, for the precise reasons you state. Eliot --SCuxzeid5NHEZl92BTiwAZrg5VWUk18XY-- --WvINS4cYuheJdtHbWfEwx25OaQHrfy8BF Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDi0toFAwAAAAAACgkQh7ZrRtnSejMB KAf8CPfIGcnrRd2/o2rRpu+F4sVkszfUSVyAWBHL27Y9sCF4ENk10h/zL8yAoeGAS23Zw3MZxwG0 h2B/VQUUphS1nJ22fF+1wHYm0DCsaB4jajGdVm3h2kyYiXQvefZ2gO8Lv5hwfuwz+YbsF3nf26Mo K8VOoLCAxU2HAFMDX7Y1hpD71Gw74sOPqDKpVRoMYh/v3AbHoBRklJ2CFoRrqRgJjkivjLnZNFFb pktELHsrliOK21HynncTJohQUVR7M4fAZQESUzaj8bfkQDoLhUnE4Vf/MvutCBfvTzyrVxDVRCpc XaZIVkK5ow4mrJ4ZpOneylje6NpIL0ysivlLKDkH5A== =PTUy -----END PGP SIGNATURE----- --WvINS4cYuheJdtHbWfEwx25OaQHrfy8BF-- From nobody Mon Jul 5 09:23:20 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7113A1D48 for ; Mon, 5 Jul 2021 09:23:18 -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 v0wywaZKsb5j for ; Mon, 5 Jul 2021 09:23:13 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F9F3A1D47 for ; Mon, 5 Jul 2021 09:23:13 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id b5so17766045ilc.12 for ; Mon, 05 Jul 2021 09:23:13 -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=DpLPxJrngLd9Kdee6LGIDHOLRBfNYBimyb5pS6oNCMo=; b=Q3OD2joj75UGILik0s847Sh5uOb1SDPGYVn34hzTHTigFfUDYyJZ0WJr3LOPndGJvb PhF1FaPmPoIZ9q6Ki+hZL0z8tFKqdIAgviqG1Drbc/L6iIcOtUs9H5dmahJ7q82zEuao P1i8/p+jv+iMp9J85fgzy6fXmmFHrSermryf8Fwfw8hJ2o4+HsNSCx4Cb9cAV2cvWGNK 0INEi2opWmlR5Y8UB++QuAhwelRJXG6V9dJMZoEv2imqPMxW3WedlQukiYYsBdzQnyfQ 1TtEODbgcNdURB8ZlOkxSfzaI9anvESKHfxeRJZWxeoIIKmLWCnFHplnn3sE+V/Uc1LB Aadw== 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=DpLPxJrngLd9Kdee6LGIDHOLRBfNYBimyb5pS6oNCMo=; b=enx+heaa7ynE+WVYE2COpcHcAUBg9JUhHXzlaPJMwdlZt1G6IGN+XNmnKVPu7bM8+3 zpakz3XABjBPtUpCDE+8ukhybpPHusoZL4f3IyZI2y/5Hbmr6rT0Xzxn7ZQnt4Pff2x3 lsQmvcS8W0hilhlDFS45u48uudtiUcFkH1oNyX2BGKei6EyzxiTcQFzJ+ZFgQPvoxNBB 6gf26zvafSO7pbnp3OgkMUHb9Enrn1hcd2CSvD1g7ZwnGFtpBw0yIHGV78iEq+PnF2lg oWpzg/HjNHjK2KsKyWHMLVw1kKGnFXOs85kgIQCL4E0IAwys9tahltxQnlcmp0AOL81a fkCg== X-Gm-Message-State: AOAM5339x4yhPq5/xiT0twK3GWyZVNnh7b+FP9U7SEJRkxB+/hX38LJU AlRBeX4UhuTMTM8BYEF6O56VPqDb2CLzIkj/Xw4XJg== X-Google-Smtp-Source: ABdhPJzlf0IpZT6aqK0q33rMQXxYFTgFbypmi2hLnp3G1v2l7b9Gd0h+N0cSwDEaPuFHqNZPOxQKnXcjg4q5YDYgyMM= X-Received: by 2002:a05:6e02:219c:: with SMTP id j28mr11164937ila.56.1625502192668; Mon, 05 Jul 2021 09:23:12 -0700 (PDT) MIME-Version: 1.0 References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk> <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch> In-Reply-To: <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch> From: Eric Rescorla Date: Mon, 5 Jul 2021 09:22:36 -0700 Message-ID: To: Eliot Lear Cc: Brian E Carpenter , Adrian Farrel , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000c6b92605c662b894" Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 16:23:19 -0000 --000000000000c6b92605c662b894 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 28, 2021 at 10:42 PM Eliot Lear wrote: > Ok. Then the text as it stands is as follows: > > Decisions of the RSWG can only be appealed on grounds of failure to > follow the correct process. Appeals should be made within 30 days of > any action, or in the case of failure to act, of notice having been > given to the RSWG. The RSAB will then decide if the process was > followed and will direct RSWG chairs as to what procedural actions are > required. > > Any concerns? Please respond by the 6th. > Yes. I don't think "direct" is appropriate. The RSWG is not subordinate to the RSAB, so the RSAB should not be "directing" them. The more I think about this, the more I am concerned about the structure with appeals going to the RSAB. It seems to me that at a high level, there are two ways in which you could have an appeal: - A document comes to the RSAB which did not follow the process - Something else happens (e.g., the RSWG doesn't advance a document despite consensus). In the first case, the document is in front of the RSAB and we could simply empower them to reject it. In the second case, however, I don't believe the RSAB should be able to direct the WG to adopt/advance a document, but this text verges on this. What I would propose here is to dispense with appeals instead all the RSAB to reject documents for process violations. If WG members feel that the chairs are handling things badly in other ways, they can approach the bodies which appointed those chairs and ask for their removal, as indicated in S 3.1.1. This also gives us a handy answer to issue #72. -Ekr Eliot > On 29.06.21 00:47, Brian E Carpenter wrote: > > On 28-Jun-21 23:31, Adrian Farrel wrote: > > Yeah, I can live with that. > > Ditto. > > > Failure to act is always a tricksy one. I think you have it covered. > > Yes. Let us not forget that the first ever formal appeal in the IETF > was an appeal against IESG inaction. > > Brian > > > A > > -----Original Message----- > From: Eliot Lear > Sent: 28 June 2021 08:33 > To: adrian@olddog.co.uk; rfced-future@iab.org > Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) > > Hi Adrian, > > On 22.06.21 17:10, Adrian Farrel wrote: > > I completely agree with the sentiment, but I think the wording may have issues. > > What the proposal does is say what can be done "if there are concerns about the process followed by the RSWG." It does not say (but I think it is meant to imply) that the content of the decisions cannot be appealed. > > The "should" is also slightly ambiguous. > And "any action" presumably means the action being appealed. > > I would... > > Decisions of the RSWG can only be appealed on grounds of failure to follow the correct process. Such an appeal must be made to the RSAB within 30 days of the action being appealed. The RSAB will then decide whether the process was followed correctly. > > One of the cases we were trying to cover was inaction of the chairs, > such as their refusal either to call a question or declare [lack of] > consensus. Thus the wording as you saw it. This leads to an > interesting question: when does the 30 day clock start? Also, I think > the intent was to provide direction to the chairs in the case of an > appeal being upheld. > > With all of this in mind, I propose a bit of a merge: > > > Decisions of the RSWG can only be appealed on grounds of failure to > follow the correct process. Appeals should be made within 30 days of > any action, or in the case of failure to act, of notice having been > given to the RSWG. The RSAB will then decide if the process was > followed and will direct RSWG chairs as to what procedural actions are > required. > > Does this make sense? > > Eliot > > > Cheers, > Adrian > > -----Original Message----- > From: Rfced-future On Behalf Of Eliot Lear > Sent: 22 June 2021 15:38 > To: rfced-future@iab.org > Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) > > The following text was proposed to address appeals of the RSWG: > > > Appeals of RSWG decisions can be made to the RSAB if there are > concerns about the process followed by the RSWG. Appeals should be > made within 30 days of any action. The RSAB then decides if the > process has been followed. > > Please raise concerns by 6 July if you have any. > > Eliot > > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000c6b92605c662b894 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 28, 2021 at 10:42 PM Elio= t Lear <lear@lear.ch> wrote:
<= /div>
=20 =20 =20

Ok.=C2=A0 Then the text as it stands is as follows:

Decisions of the RSWG can only be appealed on grounds of failure=
 to=20
follow the correct process. Appeals should be made within 30 days of=20
any action, or in the case of failure to act, of notice having been=20
given to the RSWG. The RSAB will then decide if the process was=20
followed and will direct RSWG chairs as to what procedural actions are=20
required.

Any concerns?=C2=A0 Please respond by the 6th.


Yes. I don't think "direct" is appro= priate. The RSWG is not subordinate to the RSAB, so the RSAB should not be = "directing" them.

The more I think about= this, the more I am concerned about the structure with appeals going to th= e RSAB.

It seems to me that at a high level, there= are two ways in which you could have an appeal:

-= A document comes to the RSAB which did not follow the process
- = Something else happens (e.g., the RSWG doesn't advance a document despi= te consensus).

In the first case, the document is = in front of the RSAB and we could simply empower them to reject it. In the = second case, however, I don't believe the RSAB should be able to direct= the WG to adopt/advance a document, but this text verges on this.

What I would propose here is to dispense with appeals inst= ead all the RSAB to reject documents for process violations. If WG members = feel that the chairs are handling things badly in other ways, they can appr= oach the bodies which appointed those chairs and ask for their removal, as = indicated in S 3.1.1. This also gives us a handy answer to issue #72.

-Ekr

Eliot

On 29.06.21 00:47, Brian E Carpenter wrote:
On 28-Jun-21 23:31, Adrian Farrel wrote:

Yeah, I can live with that.

Ditto.


Failure to act is always a tricksy one. I think you have it co=
vered.

Yes. Let us not forget that the first ever formal appeal in the =
IETF
was an appeal against IESG inaction.

   Brian


A

-----Original Message-----
From: Eliot Lear <lear=
@lear.ch>=20
Sent: 28 June 2021 08:33
To: adrian@olddog.=
co.uk; rfced-=
future@iab.org
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)

Hi Adrian,

On 22.06.21 17:10, Adrian Farrel wrote:

I completely agree with the sentiment, but I think the wordi=
ng may have issues.

What the proposal does is say what can be done "if there are concerns =
about the process followed by the RSWG." It does not say (but I think =
it is meant to imply) that the content of the decisions cannot be appealed.

The "should" is also slightly ambiguous.
And "any action" presumably means the action being appealed.

I would...

Decisions of the RSWG can only be appealed on grounds of failure to follow =
the correct process. Such an appeal must be made to the RSAB within 30 days=
 of the action being appealed. The RSAB will then decide whether the proces=
s was followed correctly.

One of the cases we were trying to cover was inaction of the c=
hairs,=20
such as their refusal either to call a question or declare [lack of]=20
consensus.  Thus the wording as you saw it.  This leads to an=20
interesting question: when does the 30 day clock start? Also,  I think=20
the intent was to provide direction to the chairs in the case of an=20
appeal being upheld.

With all of this in mind, I propose a bit of a merge:


Decisions of the RSWG can only be appealed on grounds of fai=
lure to=20
follow the correct process. Appeals should be made within 30 days of=20
any action, or in the case of failure to act, of notice having been=20
given to the RSWG. The RSAB will then decide if the process was=20
followed and will direct RSWG chairs as to what procedural actions are=20
required.

Does this make sense?

Eliot


Cheers,
Adrian

-----Original Message-----
From: Rfced-future <rfced-future-bounces@iab.org> On Behalf Of Eliot Lea=
r
Sent: 22 June 2021 15:38
To: rfced-future@=
iab.org
Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)

The following text was proposed to address appeals of the RSWG:


Appeals of RSWG decisions can be made to the RSAB if there=
 are
concerns about the process followed by the RSWG. Appeals should be
made within 30 days of any action. The RSAB then decides if the
process has been followed.

Please raise concerns by 6 July if you have any.

Eliot





      

      

    

  


-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future




--000000000000c6b92605c662b894--


From nobody Mon Jul  5 22:47:40 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2033E3A11FC for ; Mon,  5 Jul 2021 22:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B5Lbu76nyv7 for ; Mon,  5 Jul 2021 22:47:34 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 0E0463A11FD for ; Mon,  5 Jul 2021 22:47:32 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1002::5c6] ([IPv6:2001:420:c0c0:1002:0:0:0:5c6]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1665lS1B078824 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 6 Jul 2021 07:47:29 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625550449; bh=8QxvVrJCYqRAEkL5hD16TA6Dhxa5vC4WPXeMCOyCVV8=; h=Subject:From:To:References:Date:In-Reply-To:From; b=kQFND3CA9MXURPw0cTp/CwTRQRwehnuTb9EzhcyI8/iL5jTt4xhQvFS+iNLnZJKSc +RK6iBRlARucKsbbtNfxIPo/E0fMoxlNRGDkVWLGeXyQrU95RdVFbuVF1r4Smlv9AP GHQiaGKOkdjr02GFfy2+FefqFUvWSUY+xpqSvBFQ=
From: Eliot Lear 
To: rfced-future@iab.org
References: 
Message-ID: <8dfe7f27-4892-9b5b-e6e9-7aa8d99bb9e4@lear.ch>
Date: Tue, 6 Jul 2021 07:47:27 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OLHfm7jPYOKTnOgiP73xOXHQM3tOmF3Zu"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 14: selection of chairs
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Jul 2021 05:47:39 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--OLHfm7jPYOKTnOgiP73xOXHQM3tOmF3Zu
Content-Type: multipart/mixed; boundary="4w90dzC5avHQ66bcMlJkBW77P428iG0Ac";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Message-ID: <8dfe7f27-4892-9b5b-e6e9-7aa8d99bb9e4@lear.ch>
Subject: Re: Consensus check: Issue 14: selection of chairs
References: 
In-Reply-To: 

--4w90dzC5avHQ66bcMlJkBW77P428iG0Ac
Content-Type: multipart/alternative;
 boundary="------------20D52F6701AB28EA000E44E5"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------20D52F6701AB28EA000E44E5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Consensus call completed.=C2=A0 Peter should make the tweak about stagger=
ed=20
terms.

On 22.06.21 16:32, Eliot Lear wrote:
>
> Peter has added text into -01 for this in Sections 3.1.1 and 3.1.2.=C2=A0=
=20
> There are three remaining issues:
>
> 1.=C2=A0 Adrian's point about staggered terms.=C2=A0 Peter will address=
 this=20
> editorially.
>
> 2. Chair removal.=C2=A0 A separate issue 72 has been opened for this.
>
> 3. Possible term limits for the RSAB.=C2=A0 A separate issue 71 has bee=
n=20
> opened for this.
>
> If you have any *other* concerns about the text in the draft, please=20
> say so by 6 July 2021.
>
>

--------------20D52F6701AB28EA000E44E5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Consensus call completed.=C2=A0 Peter should make the tweak about
      staggered terms.

    

    
On 22.06.21 16:32, Eliot Lear wrote:
    

    

      
      
Peter has added text into -01 for this in Sections 3.1.1 and
        3.1.2.=C2=A0 There are three remaining issues:

      
1.=C2=A0 Adrian's point about staggered terms.=C2=A0 Peter will =
address
        this editorially.

      
2. Chair removal.=C2=A0 A separate issue 72 has been opened for
        this.

      
3. Possible term limits for the RSAB.=C2=A0 A separate issue 71 =
has
        been opened for this.

      
If you have any other concerns about the text in the
        draft, please say so by 6 July 2021.

      

      

      

    

  


--------------20D52F6701AB28EA000E44E5--

--4w90dzC5avHQ66bcMlJkBW77P428iG0Ac--

--OLHfm7jPYOKTnOgiP73xOXHQM3tOmF3Zu
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDj7m8FAwAAAAAACgkQh7ZrRtnSejM2
vwgAsPdnorry8WGULU+rHcRw8S4zrMZE+BoixJUjMhRn5NsnoJDtYgMfTaR91HISKihRotaKH6ab
O1eF97V3DAFpKfrVaGtGvqg4nCABaJ4nX5wquw0PBOdecgmfwJ8wZxdDJTOjy+aEPOoitDa3HxpO
iFt/f621DeosdaFOJC316pLeZKhK5wTkQtcl08AiUVnRAhauyXmsNjFPkMdP/P6zp2cOkFl0PEwH
lN+omOv/CU8aVuzzGYineqN0c0haICGWK8VjXpHorrPL9JkGWSZF5idUu06F+Z1StFHso2MnwsSO
nwbUvNJxnkhMUaZcnTGIyMjLRyxJtbgYq2X7mzDZGQ==
=iyek
-----END PGP SIGNATURE-----

--OLHfm7jPYOKTnOgiP73xOXHQM3tOmF3Zu--


From nobody Mon Jul  5 22:47:51 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94613A1200 for ; Mon,  5 Jul 2021 22:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leREMHWcdC6l for ; Mon,  5 Jul 2021 22:47:49 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 2FF783A11FE for ; Mon,  5 Jul 2021 22:47:48 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1002::5c6] ([IPv6:2001:420:c0c0:1002:0:0:0:5c6]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1665lkvX078831 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 6 Jul 2021 07:47:46 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625550466; bh=LTHCwklBwkx2jyoLAiWGuvXhSRXodDrwryuFQOS6j/k=; h=Subject:From:To:References:Date:In-Reply-To:From; b=uIitEUwg0ycYhOyBRhAbgezbbfApjSiiF5d5xn5TVoDAE+YGpKDk1nmfTpmbzjFTl naI2ID0S5Mn214Gdy8s0js/gCcz8vBhXFugPvejCh05376MvY+u4APTPyL36v27Jm6 j3TAhm/chPfLxc0o09wv1ABJ8VqsiYCqkENufrWc=
From: Eliot Lear 
To: rfced-future@iab.org
References: 
Message-ID: 
Date: Tue, 6 Jul 2021 07:47:45 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8il9fnBVI0Kq9Vq8BKCJZJ9lxsk3jY4xe"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Close Issue 11: Is there a figurehead
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Jul 2021 05:47:51 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--8il9fnBVI0Kq9Vq8BKCJZJ9lxsk3jY4xe
Content-Type: multipart/mixed; boundary="6JMmEeZz4GWuorcjDNMeasL29hzdvCc4k";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Message-ID: 
Subject: Re: Consensus check: Close Issue 11: Is there a figurehead
References: 
In-Reply-To: 

--6JMmEeZz4GWuorcjDNMeasL29hzdvCc4k
Content-Type: multipart/alternative;
 boundary="------------ED17EEFDCCA93FF42A4834E6"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------ED17EEFDCCA93FF42A4834E6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

This issue will be closed.

On 22.06.21 16:22, Eliot Lear wrote:
> This is more a placeholder issue about whether we have an RSE/A.=20
> Propose to close.=C2=A0 We think we're beyond this point.=C2=A0 Please =
comment=20
> by 6 July if you disagree.
>
>
>

--------------ED17EEFDCCA93FF42A4834E6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
This issue will be closed.

    

    
On 22.06.21 16:22, Eliot Lear wrote:
    

    
This is
      more a placeholder issue about whether we have an RSE/A. Propose
      to close.=C2=A0 We think we're beyond this point.=C2=A0 Please comm=
ent by 6
      July if you disagree.
      

      

      

      

      

    

  


--------------ED17EEFDCCA93FF42A4834E6--

--6JMmEeZz4GWuorcjDNMeasL29hzdvCc4k--

--8il9fnBVI0Kq9Vq8BKCJZJ9lxsk3jY4xe
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDj7oEFAwAAAAAACgkQh7ZrRtnSejNT
pwf6AhHRXylbKvlegvufaPGR9xO7sbKniloAlNr7Bbw8i1ECwFtd7GLQEM0DaQ2ejJrZLA8ah45Z
glpeTRL/DUzcPUnT6/HF/jlWt4Pn4YffhWVfoJ4xCTny9sX8UbvabMTy2Jhc7AMsRm+4wKexgWgi
WO3Jfz+83BpjfhIF8nko8k3tqd6VU96htglOBEw7vA3cHjjV2lA3/4Ao2jDWKwLI3HSoXSq2rdve
+O9esn/GlQhzuZutx+HcKTCSXQcGmWUS+OkoThJu8ftYwVEA2VxDxhsPCtT/Fq6xzr8pjSmJcpLa
i8ZtNmI3ASPlhl3I7bTjFgHZuB5ugElbC+hq5Xu/Bg==
=LGcG
-----END PGP SIGNATURE-----

--8il9fnBVI0Kq9Vq8BKCJZJ9lxsk3jY4xe--


From nobody Mon Jul  5 22:49:11 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D25F3A120D for ; Mon,  5 Jul 2021 22:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTyNGvscbYxT for ; Mon,  5 Jul 2021 22:49:04 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 4D70E3A120A for ; Mon,  5 Jul 2021 22:49:04 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1002::5c6] ([IPv6:2001:420:c0c0:1002:0:0:0:5c6]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1665n2tj078859 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 6 Jul 2021 07:49:02 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625550542; bh=CykF9/HYmbRdtgn2QIDpK1CsjjZUKuEMjgy9nbtLAOY=; h=Subject:From:To:References:Date:In-Reply-To:From; b=K/pLnOonbhBixoEhDkzIo68SD2EaFwUqT4ErmrfDomNvtMt34ns6WmrJIxzFVuOxj pwlvw2jeGyFEYAJ7TZYrcSz7ShLZoyHNIfaxd7Y0QEA80FE8yHBdpvL2WGn6dpSp0I 8cLWr2LaQrl3nBVhOcZzn01CWl1ISfrCb05vHV3E=
From: Eliot Lear 
To: rfced-future@iab.org
References:  
Message-ID: <40a55031-1681-a2a6-d2e3-34057eeed919@lear.ch>
Date: Tue, 6 Jul 2021 07:49:01 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="USTh7DpMEZCEkO5uO6Ui0z61XSbtqiVkk"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Close Issue 11: Is there a figurehead
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Jul 2021 05:49:09 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--USTh7DpMEZCEkO5uO6Ui0z61XSbtqiVkk
Content-Type: multipart/mixed; boundary="fA9JNTcxKcIft38xBiMpjfDg5u93iQA9v";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Message-ID: <40a55031-1681-a2a6-d2e3-34057eeed919@lear.ch>
Subject: Re: Consensus check: Close Issue 11: Is there a figurehead
References: 
 
In-Reply-To: 

--fA9JNTcxKcIft38xBiMpjfDg5u93iQA9v
Content-Type: multipart/alternative;
 boundary="------------84B00C64B03A774B48A288AF"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------84B00C64B03A774B48A288AF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Just noticed that I jumped the gun by one day.=C2=A0 Please respond to th=
is=20
note if you have concerns.

On 06.07.21 07:47, Eliot Lear wrote:
>
> This issue will be closed.
>
> On 22.06.21 16:22, Eliot Lear wrote:
>> This is more a placeholder issue about whether we have an RSE/A.=20
>> Propose to close.=C2=A0 We think we're beyond this point.=C2=A0 Please=
 comment=20
>> by 6 July if you disagree.
>>
>>
>>
>

--------------84B00C64B03A774B48A288AF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Just noticed that I jumped the gun by one day.=C2=A0 Please respon=
d to
      this note if you have concerns.

    

    
On 06.07.21 07:47, Eliot Lear wrote:
    

    

      
      
This issue will be closed.

      

      
On 22.06.21 16:22, Eliot Lear wrote:=


      

      
This is=

        more a placeholder issue about whether we have an RSE/A. Propose
        to close.=C2=A0 We think we're beyond this point.=C2=A0 Please co=
mment by
        6 July if you disagree. 

        

        

        

        

      

      

      

    

  


--------------84B00C64B03A774B48A288AF--

--fA9JNTcxKcIft38xBiMpjfDg5u93iQA9v--

--USTh7DpMEZCEkO5uO6Ui0z61XSbtqiVkk
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDj7s0FAwAAAAAACgkQh7ZrRtnSejND
Iwf9ET0bJcP0te6BfsQYnGD75CCIlB9tlOSzIakFvlfOy2yvr4oCDmFoeieeFQYCOQIcSfpzd1PL
6YA6XBEeyGOZ5P6CerSS+prJynqDcgz5Ywr92P0MKCSMS67caANlb/oq1GWXgjAhZ9VMh4vt9yCb
y/OmOAseoZje03lp1kQQ0XXQr+KO831typvz9YOG53pIS5ERXEasXg2Tl0gmtW3XzPAt1+l2crLk
qJEV50HvLuDmOa2cMbDB9AGtNqEoNrwa15lnOFeNoHuNtLY2SLTkrGVx6f3bhbaZw5keasvgyL+h
/o6vDxKE2x5UYDpwejibzDxREBwyC1pVlKqyfUS4VQ==
=71O+
-----END PGP SIGNATURE-----

--USTh7DpMEZCEkO5uO6Ui0z61XSbtqiVkk--


From nobody Mon Jul  5 23:12:18 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28BB3A1417 for ; Mon,  5 Jul 2021 23:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.426
X-Spam-Level: 
X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUPzAao_D6Yv for ; Mon,  5 Jul 2021 23:12:10 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 309863A1413 for ; Mon,  5 Jul 2021 23:12:09 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1002::5c6] ([IPv6:2001:420:c0c0:1002:0:0:0:5c6]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1666C66D079140 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 6 Jul 2021 08:12:06 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625551927; bh=iD11ko8jXe2D99PQgpWnNpjj1FE1/TmkexvZFYIgk/w=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=Zb3StMzkmBFgwH31l2dWRiEzoJLwGXw4z5++ORRCEPrsZ8LCfiPg/ixpD0kef1ki9 YxOj3qKxEtQ6kjIdq8v/eiNN5Vq+b64sxhehq2K/KWmMWpWFkx9xn+suOFAT27hj5D rLkrOJCREaInQx96pRJrnqmZqRv+ZdiXed3QFUc8=
To: Eric Rescorla 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch> 
From: Eliot Lear 
Message-ID: 
Date: Tue, 6 Jul 2021 08:12:05 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d49SjBMYaYb2KqQg1lBz1JkvwmnKPqbWJ"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Jul 2021 06:12:16 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--d49SjBMYaYb2KqQg1lBz1JkvwmnKPqbWJ
Content-Type: multipart/mixed; boundary="Huy6jSDiFsnFFtCa7r3fqenu6ZXRw5Qo7";
 protected-headers="v1"
From: Eliot Lear 
To: Eric Rescorla 
Cc: rfced-future@iab.org
Message-ID: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch>
 <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk>
 <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch>
 <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>
 
 <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>
 
In-Reply-To: 

--Huy6jSDiFsnFFtCa7r3fqenu6ZXRw5Qo7
Content-Type: multipart/alternative;
 boundary="------------FF29D406E1066BB31ED98B7D"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------FF29D406E1066BB31ED98B7D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Eric,

Thanks for your comments.=C2=A0 We are, I think, to the point on this iss=
ue=20
where it would be good to have a renewed sense on where people stand.=C2=A0=
 I=20
have two questions:

  * Assuming you are in the rough and that there would be an appeals
    process, would changing the word =E2=80=9Cdirect=E2=80=9D to =E2=80=9C=
advise=E2=80=9D address your
    concerns, and would other people find that acceptable?
  * Do people agree with EKR that an appeal process is not required?

As a reminder, we had a proposal earlier that did NOT have an appeals=20
process.=C2=A0 It seems to me that at its core, as a matter of practicali=
ty,=20
the issue here is whether chairs can be effectively managed from their=20
constituent bodies or whether the RSAB might abuse its authority on=20
appeal.=C2=A0 My suggestion to the group is in the form of general advice=
:=20
absent strong opinions either way, less process is better ;-)

Given your comment, I propose to let this issue remain open for another=20
two weeks, so that we can properly resolve this matter.

Eliot

On 05.07.21 18:22, Eric Rescorla wrote:
>
>
> On Mon, Jun 28, 2021 at 10:42 PM Eliot Lear  > wrote:
>
>     Ok.=C2=A0 Then the text as it stands is as follows:
>
>         Decisions of the RSWG can only be appealed on grounds of failur=
e to
>         follow the correct process. Appeals should be made within 30 da=
ys of
>         any action, or in the case of failure to act, of notice having =
been
>         given to the RSWG. The RSAB will then decide if the process was=

>         followed and will direct RSWG chairs as to what procedural acti=
ons are
>         required.
>
>     Any concerns?=C2=A0 Please respond by the 6th.
>
>
> Yes. I don't think "direct" is appropriate. The RSWG is not=20
> subordinate to the RSAB, so the RSAB should not be "directing" them.
>
> The more I think about this, the more I am concerned about the=20
> structure with appeals going to the RSAB.
>
> It seems to me that at a high level, there are two ways in which you=20
> could have an appeal:
>
> - A document comes to the RSAB which did not follow the process
> - Something else happens (e.g., the RSWG doesn't advance a document=20
> despite consensus).
>
> In the first case, the document is in front of the RSAB and we could=20
> simply empower them to reject it. In the second case, however, I don't =

> believe the RSAB should be able to direct the WG to adopt/advance a=20
> document, but this text verges on this.
>
> What I would propose here is to dispense with appeals instead all the=20
> RSAB to reject documents for process violations. If WG members feel=20
> that the chairs are handling things badly in other ways, they can=20
> approach the bodies which appointed those chairs and ask for their=20
> removal, as indicated in S 3.1.1. This also gives us a handy answer to =

> issue #72.
>
> -Ekr
>
>     Eliot
>
>     On 29.06.21 00:47, Brian E Carpenter wrote:
>>     On 28-Jun-21 23:31, Adrian Farrel wrote:
>>>     Yeah, I can live with that.
>>     Ditto.
>>
>>>     Failure to act is always a tricksy one. I think you have it cover=
ed.
>>     Yes. Let us not forget that the first ever formal appeal in the IE=
TF
>>     was an appeal against IESG inaction.
>>
>>         Brian
>>
>>>     A
>>>
>>>     -----Original Message-----
>>>     From: Eliot Lear   =20
>>>     Sent: 28 June 2021 08:33
>>>     To:adrian@olddog.co.uk  ;rfced-future=
@iab.org  
>>>     Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (R=
SWG)
>>>
>>>     Hi Adrian,
>>>
>>>     On 22.06.21 17:10, Adrian Farrel wrote:
>>>>     I completely agree with the sentiment, but I think the wording m=
ay have issues.
>>>>
>>>>     What the proposal does is say what can be done "if there are con=
cerns about the process followed by the RSWG." It does not say (but I thi=
nk it is meant to imply) that the content of the decisions cannot be appe=
aled.
>>>>
>>>>     The "should" is also slightly ambiguous.
>>>>     And "any action" presumably means the action being appealed.
>>>>
>>>>     I would...
>>>>
>>>>     Decisions of the RSWG can only be appealed on grounds of failure=
 to follow the correct process. Such an appeal must be made to the RSAB w=
ithin 30 days of the action being appealed. The RSAB will then decide whe=
ther the process was followed correctly.
>>>     One of the cases we were trying to cover was inaction of the chai=
rs,
>>>     such as their refusal either to call a question or declare [lack =
of]
>>>     consensus.  Thus the wording as you saw it.  This leads to an
>>>     interesting question: when does the 30 day clock start? Also,  I =
think
>>>     the intent was to provide direction to the chairs in the case of =
an
>>>     appeal being upheld.
>>>
>>>     With all of this in mind, I propose a bit of a merge:
>>>
>>>>     Decisions of the RSWG can only be appealed on grounds of failure=
 to
>>>>     follow the correct process. Appeals should be made within 30 day=
s of
>>>>     any action, or in the case of failure to act, of notice having b=
een
>>>>     given to the RSWG. The RSAB will then decide if the process was
>>>>     followed and will direct RSWG chairs as to what procedural actio=
ns are
>>>>     required.
>>>     Does this make sense?
>>>
>>>     Eliot
>>>
>>>>     Cheers,
>>>>     Adrian
>>>>
>>>>     -----Original Message-----
>>>>     From: Rfced-future    On Behalf Of Eliot Lear
>>>>     Sent: 22 June 2021 15:38
>>>>     To:rfced-future@iab.org  
>>>>     Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG=
)
>>>>
>>>>     The following text was proposed to address appeals of the RSWG:
>>>>
>>>>>     Appeals of RSWG decisions can be made to the RSAB if there are
>>>>>     concerns about the process followed by the RSWG. Appeals should=
 be
>>>>>     made within 30 days of any action. The RSAB then decides if the=

>>>>>     process has been followed.
>>>>     Please raise concerns by 6 July if you have any.
>>>>
>>>>     Eliot
>>>>
>>>>
>>>>
>     --=20
>     Rfced-future mailing list
>     Rfced-future@iab.org 
>     https://www.iab.org/mailman/listinfo/rfced-future
>     
>
>

--------------FF29D406E1066BB31ED98B7D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Eric,

    
Thanks for your comments.=C2=A0 We are, I think, to the point on t=
his
      issue where it would be good to have a renewed sense on where
      people stand.=C2=A0 I have two questions:

    

    
    
      
  • Assuming you are in the rough and that there would be an
        appeals process, would changing the word =E2=80=9Cdirect=E2=80=9D=
 to =E2=80=9Cadvise=E2=80=9D
        address your concerns, and would other people find that
        acceptable?
    • 
      
  • Do people agree with EKR that an appeal process is not
        required?=C2=A0 
    
      
    • 
    

    
As a reminder, we had a proposal earlier that did NOT have an
      appeals process.=C2=A0 It seems to me that at its core, as a matter=
 of
      practicality, the issue here is whether chairs can be effectively
      managed from their constituent bodies or whether the RSAB might
      abuse its authority on appeal.=C2=A0 My suggestion to the group is =
in
      the form of general advice: absent strong opinions either way,
      less process is better ;-)

    

    
Given your comment, I propose to let this issue remain open for
      another two weeks, so that we can properly resolve this matter.
=

    

    
Eliot

    

    
On 05.07.21 18:22, Eric Rescorla wrote=
:

    

    

      
      

        


        

        

        

          
On Mon, Jun 28, 2021 at
            10:42 PM Eliot Lear <lear@lear.ch> wrote:

          

          

            

              
Ok.=C2=A0 Then the text as it stands is as follows:

              

                
Decisions of the RSWG can only be appealed on ground=
s of failure to=20
follow the correct process. Appeals should be made within 30 days of=20
any action, or in the case of failure to act, of notice having been=20
given to the RSWG. The RSAB will then decide if the process was=20
followed and will direct RSWG chairs as to what procedural actions are=20
required.

              

              
Any concerns?=C2=A0 Please respond by the 6th.

              

            

          

          


          

          
Yes. I don't think "direct" is appropriate. The RSWG is
            not subordinate to the RSAB, so the RSAB should not be
            "directing" them.

          


          

          
The more I think about this, the more I am concerned
            about the structure with appeals going to the RSAB.

          


          

          
It seems to me that at a high level, there are two ways
            in which you could have an appeal:

          


          

          
- A document comes to the RSAB which did not follow the
            process

          
- Something else happens (e.g., the RSWG doesn't advance
            a document despite consensus).

          


          

          
In the first case, the document is in front of the RSAB
            and we could simply empower them to reject it. In the second
            case, however, I don't believe the RSAB should be able to
            direct the WG to adopt/advance a document, but this text
            verges on this.

          


          

          
What I would propose here is to dispense with appeals
            instead all the RSAB to reject documents for process
            violations. If WG members feel that the chairs are handling
            things badly in other ways, they can approach the bodies
            which appointed those chairs and ask for their removal, as
            indicated in S 3.1.1. This also gives us a handy answer to
            issue #72.

          

          


          

          
-Ekr

          


          

          

            

              
 

              
Eliot

              

              
On 29.06.21 00:47, Brian E Carpenter wrote:

              

              

                
On 28-Jun-21 23:31, Adrian Farrel wrote:


                

                  
Yeah, I can live with that.


                

                
Ditto.



                

                  
Failure to act is always a tricksy one. I think yo=
u have it covered.


                

                
Yes. Let us not forget that the first ever formal ap=
peal in the IETF
was an appeal against IESG inaction.

   Brian



                

                  
A

-----Original Message-----
From: Eliot Lear <lear@lear.ch>=20
Sent: 28 June 2021 08:33
To: adrian@olddog.co.uk; rfced-future@iab.org
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)

Hi Adrian,

On 22.06.21 17:10, Adrian Farrel wrote:


                  

                    
I completely agree with the sentiment, but I thi=
nk the wording may have issues.

What the proposal does is say what can be done "if there are concerns abo=
ut the process followed by the RSWG." It does not say (but I think it is =
meant to imply) that the content of the decisions cannot be appealed.

The "should" is also slightly ambiguous.
And "any action" presumably means the action being appealed.

I would...

Decisions of the RSWG can only be appealed on grounds of failure to follo=
w the correct process. Such an appeal must be made to the RSAB within 30 =
days of the action being appealed. The RSAB will then decide whether the =
process was followed correctly.


                  

                  
One of the cases we were trying to cover was inact=
ion of the chairs,=20
such as their refusal either to call a question or declare [lack of]=20
consensus.  Thus the wording as you saw it.  This leads to an=20
interesting question: when does the 30 day clock start? Also,  I think=20
the intent was to provide direction to the chairs in the case of an=20
appeal being upheld.

With all of this in mind, I propose a bit of a merge:



                  

                    
Decisions of the RSWG can only be appealed on gr=
ounds of failure to=20
follow the correct process. Appeals should be made within 30 days of=20
any action, or in the case of failure to act, of notice having been=20
given to the RSWG. The RSAB will then decide if the process was=20
followed and will direct RSWG chairs as to what procedural actions are=20
required.


                  

                  
Does this make sense?

Eliot



                  

                    
Cheers,
Adrian

-----Original Message-----
From: Rfced-future <rfced-future-bounces@iab.org>=
 On Behalf Of Eliot Lear
Sent: 22 June 2021 15:38
To: rfced-future@iab.org
Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)

The following text was proposed to address appeals of the RSWG:



                    

                      
Appeals of RSWG decisions can be made to the R=
SAB if there are
concerns about the process followed by the RSWG. Appeals should be
made within 30 days of any action. The RSAB then decides if the
process has been followed.


                    

                    
Please raise concerns by 6 July if you have any.=


Eliot





                  

                

              

            

            -- 

            Rfced-future mailing list

            Rfced-future@iab.org

            https://www.iab.org/mailman/listinfo/rfced-future

          

        

      

      

      

    

  


--------------FF29D406E1066BB31ED98B7D--

--Huy6jSDiFsnFFtCa7r3fqenu6ZXRw5Qo7--

--d49SjBMYaYb2KqQg1lBz1JkvwmnKPqbWJ
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDj9DUFAwAAAAAACgkQh7ZrRtnSejOg
9Af/bqFP8NPmkYFF6bzQx2mSDloXNk4NPlPQJfBpHFqYUqbq//LwbMAHWZoHKCwM6DGyVbrPY4co
4jdSN9k9bHO7hS27xUSw8BEE+jV6f6swk94pJZ3D57z+AAUx6UCvjV1KACCKYpipUDRfXeI4Tpf+
0F1UMbroG/2wud135YitF9aVKkzdt8dSwyTrLf1vv5JQRfyk+YyidblpoZnK1tdCiheM6X0ta/9g
bdGm3iA3r5AUwwAh2RKIV7hyRIqOOq5rGs2Q2/5QCsrjhTBCisOhmkAAyHX5+6ws80GLvozpvouH
g7Nl64y+jilOpXjRrFhaU/WuRYIjdvi5sd1As5+bqQ==
=8WAd
-----END PGP SIGNATURE-----

--d49SjBMYaYb2KqQg1lBz1JkvwmnKPqbWJ--


From nobody Tue Jul  6 06:46:04 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39453A288A for ; Tue,  6 Jul 2021 06:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 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.338, 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 zW9uqWZTRCl6 for ; Tue,  6 Jul 2021 06:45:58 -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 0AB103A2889 for ; Tue,  6 Jul 2021 06:45:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GK3jd3VDHz1nsXf; Tue,  6 Jul 2021 06:45:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1625579157; bh=b0lk/RHZnm91M7LFD1q8kJEsnhtA9OETShRNLAx59lQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=eghdlYICbYfHgL2sSviQFzJilhwB3gajMjXRaXP0oHT4YwYdMBKYtmj0JN6tsGkrB Fq7oAJbHbbeDAgQ87XEX7EL0slHHOIaenpxwBn1eGrqcQmCyfmy8H3W5WwAbzzz0bo N6lI/D2P4pxE4gptPyl46Fc9rfrB6D685W1qrVP4=
X-Quarantine-ID: 
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)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GK3jc687lz1nsQK; Tue,  6 Jul 2021 06:45:56 -0700 (PDT)
To: Eliot Lear , Eric Rescorla 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>  
From: "Joel M. Halpern" 
Message-ID: <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>
Date: Tue, 6 Jul 2021 09:45:55 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Jul 2021 13:46:03 -0000

Having listened to several rounds of discussion, I think there does need 
to be a way to appeal chair inaction.  Any such appeal will be 
difficult.  As it should be.  But if the chairs are pushing their view 
over the rough consensus of the RSWG, that needs to be remedied.  And as 
a practical matter, going back to the appointing bodies is going to be 
even mroe difficult, since most members of the appointing bodies are 
probably leaving the RSWG / RSAB work to those they have delegated.  So 
I think that appeal needs to go to the RSAB.

And if the appeal goes to the RSAB for inaction, then the RSAB needs to 
be able to do more than advise.  Because if the appeal takes place, and 
the RSAB agrees with the appeal, and the RSWG chairs ignore that, then 
it needs to be really clear that the chair or chairs need to be 
replaced.  There may be wording to say that short of "direct", but 
"advise" is not strong enough.

Yours,
Joel

On 7/6/2021 2:12 AM, Eliot Lear wrote:
> Eric,
> 
> Thanks for your comments.  We are, I think, to the point on this issue 
> where it would be good to have a renewed sense on where people stand.  I 
> have two questions:
> 
>   * Assuming you are in the rough and that there would be an appeals
>     process, would changing the word “direct” to “advise” address your
>     concerns, and would other people find that acceptable?
>   * Do people agree with EKR that an appeal process is not required?
> 
> As a reminder, we had a proposal earlier that did NOT have an appeals 
> process.  It seems to me that at its core, as a matter of practicality, 
> the issue here is whether chairs can be effectively managed from their 
> constituent bodies or whether the RSAB might abuse its authority on 
> appeal.  My suggestion to the group is in the form of general advice: 
> absent strong opinions either way, less process is better ;-)
> 
> Given your comment, I propose to let this issue remain open for another 
> two weeks, so that we can properly resolve this matter.
> 
> Eliot
> 
> On 05.07.21 18:22, Eric Rescorla wrote:
>>
>>
>> On Mon, Jun 28, 2021 at 10:42 PM Eliot Lear > > wrote:
>>
>>     Ok.  Then the text as it stands is as follows:
>>
>>         Decisions of the RSWG can only be appealed on grounds of failure to
>>         follow the correct process. Appeals should be made within 30 days of
>>         any action, or in the case of failure to act, of notice having been
>>         given to the RSWG. The RSAB will then decide if the process was
>>         followed and will direct RSWG chairs as to what procedural actions are
>>         required.
>>
>>     Any concerns?  Please respond by the 6th.
>>
>>
>> Yes. I don't think "direct" is appropriate. The RSWG is not 
>> subordinate to the RSAB, so the RSAB should not be "directing" them.
>>
>> The more I think about this, the more I am concerned about the 
>> structure with appeals going to the RSAB.
>>
>> It seems to me that at a high level, there are two ways in which you 
>> could have an appeal:
>>
>> - A document comes to the RSAB which did not follow the process
>> - Something else happens (e.g., the RSWG doesn't advance a document 
>> despite consensus).
>>
>> In the first case, the document is in front of the RSAB and we could 
>> simply empower them to reject it. In the second case, however, I don't 
>> believe the RSAB should be able to direct the WG to adopt/advance a 
>> document, but this text verges on this.
>>
>> What I would propose here is to dispense with appeals instead all the 
>> RSAB to reject documents for process violations. If WG members feel 
>> that the chairs are handling things badly in other ways, they can 
>> approach the bodies which appointed those chairs and ask for their 
>> removal, as indicated in S 3.1.1. This also gives us a handy answer to 
>> issue #72.
>>
>> -Ekr
>>
>>     Eliot
>>
>>     On 29.06.21 00:47, Brian E Carpenter wrote:
>>>     On 28-Jun-21 23:31, Adrian Farrel wrote:
>>>>     Yeah, I can live with that.
>>>     Ditto.
>>>
>>>>     Failure to act is always a tricksy one. I think you have it covered.
>>>     Yes. Let us not forget that the first ever formal appeal in the IETF
>>>     was an appeal against IESG inaction.
>>>
>>>         Brian
>>>
>>>>     A
>>>>
>>>>     -----Original Message-----
>>>>     From: Eliot Lear    
>>>>     Sent: 28 June 2021 08:33
>>>>     To:adrian@olddog.co.uk  ;rfced-future@iab.org  
>>>>     Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
>>>>
>>>>     Hi Adrian,
>>>>
>>>>     On 22.06.21 17:10, Adrian Farrel wrote:
>>>>>     I completely agree with the sentiment, but I think the wording may have issues.
>>>>>
>>>>>     What the proposal does is say what can be done "if there are concerns about the process followed by the RSWG." It does not say (but I think it is meant to imply) that the content of the decisions cannot be appealed.
>>>>>
>>>>>     The "should" is also slightly ambiguous.
>>>>>     And "any action" presumably means the action being appealed.
>>>>>
>>>>>     I would...
>>>>>
>>>>>     Decisions of the RSWG can only be appealed on grounds of failure to follow the correct process. Such an appeal must be made to the RSAB within 30 days of the action being appealed. The RSAB will then decide whether the process was followed correctly.
>>>>     One of the cases we were trying to cover was inaction of the chairs,
>>>>     such as their refusal either to call a question or declare [lack of]
>>>>     consensus.  Thus the wording as you saw it.  This leads to an
>>>>     interesting question: when does the 30 day clock start? Also,  I think
>>>>     the intent was to provide direction to the chairs in the case of an
>>>>     appeal being upheld.
>>>>
>>>>     With all of this in mind, I propose a bit of a merge:
>>>>
>>>>>     Decisions of the RSWG can only be appealed on grounds of failure to
>>>>>     follow the correct process. Appeals should be made within 30 days of
>>>>>     any action, or in the case of failure to act, of notice having been
>>>>>     given to the RSWG. The RSAB will then decide if the process was
>>>>>     followed and will direct RSWG chairs as to what procedural actions are
>>>>>     required.
>>>>     Does this make sense?
>>>>
>>>>     Eliot
>>>>
>>>>>     Cheers,
>>>>>     Adrian
>>>>>
>>>>>     -----Original Message-----
>>>>>     From: Rfced-future    On Behalf Of Eliot Lear
>>>>>     Sent: 22 June 2021 15:38
>>>>>     To:rfced-future@iab.org  
>>>>>     Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
>>>>>
>>>>>     The following text was proposed to address appeals of the RSWG:
>>>>>
>>>>>>     Appeals of RSWG decisions can be made to the RSAB if there are
>>>>>>     concerns about the process followed by the RSWG. Appeals should be
>>>>>>     made within 30 days of any action. The RSAB then decides if the
>>>>>>     process has been followed.
>>>>>     Please raise concerns by 6 July if you have any.
>>>>>
>>>>>     Eliot
>>>>>
>>>>>
>>>>>
>>     -- 
>>     Rfced-future mailing list
>>     Rfced-future@iab.org 
>>     https://www.iab.org/mailman/listinfo/rfced-future
>>     
>>
>>
> 


From nobody Tue Jul  6 11:41:34 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276833A3120 for ; Tue,  6 Jul 2021 11:41:32 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbGuQeFe0dKM for ; Tue,  6 Jul 2021 11:41:27 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8053A3129 for ; Tue,  6 Jul 2021 11:41:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 905A9300BC1 for ; Tue,  6 Jul 2021 14:41:26 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HxjZce3vBCpe for ; Tue,  6 Jul 2021 14:41:19 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 5D80A300AE9; Tue,  6 Jul 2021 14:41:19 -0400 (EDT)
From: Russ Housley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_BFCCD580-E264-4C56-91E9-E70FB7773801"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Tue, 6 Jul 2021 14:41:18 -0400
In-Reply-To: 
Cc: rfced-future@iab.org
To: Eliot Lear 
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>  
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Jul 2021 18:41:32 -0000

--Apple-Mail=_BFCCD580-E264-4C56-91E9-E70FB7773801
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Eliot:

I think an appeals process is needed.  As Adrian pointed out, if a =
concern is raised in the RSWG, but the chairs take no action, then some =
form of appeal is needed.  However, I observe that the 30 day =
requirement in the proposed paragraph is not really a good fit for =
failure-to-do-anything appeals.

Russ


> On Jul 6, 2021, at 2:12 AM, Eliot Lear  wrote:
>=20
> Eric,
> Thanks for your comments.  We are, I think, to the point on this issue =
where it would be good to have a renewed sense on where people stand.  I =
have two questions:
>=20
> Assuming you are in the rough and that there would be an appeals =
process, would changing the word =E2=80=9Cdirect=E2=80=9D to =
=E2=80=9Cadvise=E2=80=9D address your concerns, and would other people =
find that acceptable?
> Do people agree with EKR that an appeal process is not required? =20
> As a reminder, we had a proposal earlier that did NOT have an appeals =
process.  It seems to me that at its core, as a matter of practicality, =
the issue here is whether chairs can be effectively managed from their =
constituent bodies or whether the RSAB might abuse its authority on =
appeal.  My suggestion to the group is in the form of general advice: =
absent strong opinions either way, less process is better ;-)
>=20
> Given your comment, I propose to let this issue remain open for =
another two weeks, so that we can properly resolve this matter.
>=20
> Eliot
>=20
> On 05.07.21 18:22, Eric Rescorla wrote:
>>=20
>>=20
>> On Mon, Jun 28, 2021 at 10:42 PM Eliot Lear > wrote:
>> Ok.  Then the text as it stands is as follows:
>>=20
>> Decisions of the RSWG can only be appealed on grounds of failure to=20=

>> follow the correct process. Appeals should be made within 30 days of=20=

>> any action, or in the case of failure to act, of notice having been=20=

>> given to the RSWG. The RSAB will then decide if the process was=20
>> followed and will direct RSWG chairs as to what procedural actions =
are=20
>> required.
>> Any concerns?  Please respond by the 6th.
>>=20
>>=20
>> Yes. I don't think "direct" is appropriate. The RSWG is not =
subordinate to the RSAB, so the RSAB should not be "directing" them.
>>=20
>> The more I think about this, the more I am concerned about the =
structure with appeals going to the RSAB.
>>=20
>> It seems to me that at a high level, there are two ways in which you =
could have an appeal:
>>=20
>> - A document comes to the RSAB which did not follow the process
>> - Something else happens (e.g., the RSWG doesn't advance a document =
despite consensus).
>>=20
>> In the first case, the document is in front of the RSAB and we could =
simply empower them to reject it. In the second case, however, I don't =
believe the RSAB should be able to direct the WG to adopt/advance a =
document, but this text verges on this.
>>=20
>> What I would propose here is to dispense with appeals instead all the =
RSAB to reject documents for process violations. If WG members feel that =
the chairs are handling things badly in other ways, they can approach =
the bodies which appointed those chairs and ask for their removal, as =
indicated in S 3.1.1. This also gives us a handy answer to issue #72.
>>=20
>> -Ekr
>>=20
>>=20
>> Eliot
>>=20
>> On 29.06.21 00:47, Brian E Carpenter wrote:
>>> On 28-Jun-21 23:31, Adrian Farrel wrote:
>>>> Yeah, I can live with that.
>>> Ditto.
>>>=20
>>>> Failure to act is always a tricksy one. I think you have it =
covered.
>>> Yes. Let us not forget that the first ever formal appeal in the IETF
>>> was an appeal against IESG inaction.
>>>=20
>>>    Brian
>>>=20
>>>> A
>>>>=20
>>>> -----Original Message-----
>>>> From: Eliot Lear  =20
>>>> Sent: 28 June 2021 08:33
>>>> To: adrian@olddog.co.uk ; =
rfced-future@iab.org 
>>>> Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals =
(RSWG)
>>>>=20
>>>> Hi Adrian,
>>>>=20
>>>> On 22.06.21 17:10, Adrian Farrel wrote:
>>>>> I completely agree with the sentiment, but I think the wording may =
have issues.
>>>>>=20
>>>>> What the proposal does is say what can be done "if there are =
concerns about the process followed by the RSWG." It does not say (but I =
think it is meant to imply) that the content of the decisions cannot be =
appealed.
>>>>>=20
>>>>> The "should" is also slightly ambiguous.
>>>>> And "any action" presumably means the action being appealed.
>>>>>=20
>>>>> I would...
>>>>>=20
>>>>> Decisions of the RSWG can only be appealed on grounds of failure =
to follow the correct process. Such an appeal must be made to the RSAB =
within 30 days of the action being appealed. The RSAB will then decide =
whether the process was followed correctly.
>>>> One of the cases we were trying to cover was inaction of the =
chairs,=20
>>>> such as their refusal either to call a question or declare [lack =
of]=20
>>>> consensus.  Thus the wording as you saw it.  This leads to an=20
>>>> interesting question: when does the 30 day clock start? Also,  I =
think=20
>>>> the intent was to provide direction to the chairs in the case of an=20=

>>>> appeal being upheld.
>>>>=20
>>>> With all of this in mind, I propose a bit of a merge:
>>>>=20
>>>>> Decisions of the RSWG can only be appealed on grounds of failure =
to=20
>>>>> follow the correct process. Appeals should be made within 30 days =
of=20
>>>>> any action, or in the case of failure to act, of notice having =
been=20
>>>>> given to the RSWG. The RSAB will then decide if the process was=20
>>>>> followed and will direct RSWG chairs as to what procedural actions =
are=20
>>>>> required.
>>>> Does this make sense?
>>>>=20
>>>> Eliot
>>>>=20
>>>>> Cheers,
>>>>> Adrian
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: Rfced-future  =
 On Behalf Of Eliot Lear
>>>>> Sent: 22 June 2021 15:38
>>>>> To: rfced-future@iab.org 
>>>>> Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
>>>>>=20
>>>>> The following text was proposed to address appeals of the RSWG:
>>>>>=20
>>>>>> Appeals of RSWG decisions can be made to the RSAB if there are
>>>>>> concerns about the process followed by the RSWG. Appeals should =
be
>>>>>> made within 30 days of any action. The RSAB then decides if the
>>>>>> process has been followed.
>>>>> Please raise concerns by 6 July if you have any.
>>>>>=20
>>>>> Eliot
>>>>>=20
>>>>>=20
>>>>>=20
>> --=20
>> Rfced-future mailing list
>> Rfced-future@iab.org 
>> https://www.iab.org/mailman/listinfo/rfced-future =

>>=20
>=20


--Apple-Mail=_BFCCD580-E264-4C56-91E9-E70FB7773801
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Eliot:

I =
think an appeals process is needed.  As Adrian pointed out, if a =
concern is raised in the RSWG, but the chairs take no action, then some =
form of appeal is needed.  However, I observe that the 30 day =
requirement in the proposed paragraph is not really a good fit for =
failure-to-do-anything appeals.

Russ


On Jul =
6, 2021, at 2:12 AM, Eliot Lear <lear@lear.ch> wrote:

Eric,
Thanks for =
your comments.  We are, I think, to the point on this
      issue where it would be good to have a renewed sense on where
      people stand.  I have two questions:

    

    
    
      
  • Assuming you are in the rough and that there would =
be an
        appeals process, would changing the word =E2=80=9Cdirect=E2=80=9D =
to =E2=80=9Cadvise=E2=80=9D
        address your concerns, and would other people find that
        acceptable?
    • 
      
  • Do people agree with EKR that an appeal process is =
not
        required?  
    
      
    • 
    
As a reminder, we had a proposal earlier that did =
NOT have an
      appeals process.  It seems to me that at its core, as a =
matter of
      practicality, the issue here is whether chairs can be effectively
      managed from their constituent bodies or whether the RSAB might
      abuse its authority on appeal.  My suggestion to the group is =
in
      the form of general advice: absent strong opinions either way,
      less process is better ;-)

    
Given your comment, I propose to let this issue =
remain open for
      another two weeks, so that we can properly resolve this matter.

    
Eliot

    

    
On 05.07.21 18:22, Eric Rescorla =
wrote:

    

    

      
      

        


        

        

        

          
On Mon, Jun 28, 2021 at
            10:42 PM Eliot Lear <lear@lear.ch> wrote:

          

          

            
Ok.  Then the text as it =
stands is as follows:

              

                
Decisions of the RSWG can only be =
appealed on grounds of failure to=20
follow the correct process. Appeals should be made within 30 days of=20
any action, or in the case of failure to act, of notice having been=20
given to the RSWG. The RSAB will then decide if the process was=20
followed and will direct RSWG chairs as to what procedural actions are=20=

required.

              
Any concerns?  Please =
respond by the 6th.

              

            

          

          


          

          
Yes. I don't think "direct" is appropriate. =
The RSWG is
            not subordinate to the RSAB, so the RSAB should not be
            "directing" them.

          


          

          
The more I think about this, the more I am =
concerned
            about the structure with appeals going to the RSAB.

          


          

          
It seems to me that at a high level, there are =
two ways
            in which you could have an appeal:

          


          

          
- A document comes to the RSAB which did not =
follow the
            process

          
- Something else happens (e.g., the RSWG =
doesn't advance
            a document despite consensus).

          


          

          
In the first case, the document is in front of =
the RSAB
            and we could simply empower them to reject it. In the second
            case, however, I don't believe the RSAB should be able to
            direct the WG to adopt/advance a document, but this text
            verges on this.

          


          

          
What I would propose here is to dispense with =
appeals
            instead all the RSAB to reject documents for process
            violations. If WG members feel that the chairs are handling
            things badly in other ways, they can approach the bodies
            which appointed those chairs and ask for their removal, as
            indicated in S 3.1.1. This also gives us a handy answer to
            issue #72.

          

          


          

          
-Ekr

          


          

          

            
 
Eliot

              

              
On 29.06.21 00:47, Brian E Carpenter =
wrote:

              

              

                
On 28-Jun-21 23:31, Adrian Farrel wrote:


                

                  
Yeah, I can live with that.


                

                
Ditto.



                

                  
Failure to act is always a tricksy =
one. I think you have it covered.


                

                
Yes. Let us not forget that the first =
ever formal appeal in the IETF
was an appeal against IESG inaction.

   Brian



                

                  
A

-----Original Message-----
From: Eliot Lear <lear@lear.ch>=20
Sent: 28 June 2021 08:33
To: adrian@olddog.co.uk; rfced-future@iab.org
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)

Hi Adrian,

On 22.06.21 17:10, Adrian Farrel wrote:


                  

                    
I completely agree with the =
sentiment, but I think the wording may have issues.

What the proposal does is say what can be done "if there are concerns =
about the process followed by the RSWG." It does not say (but I think it =
is meant to imply) that the content of the decisions cannot be appealed.

The "should" is also slightly ambiguous.
And "any action" presumably means the action being appealed.

I would...

Decisions of the RSWG can only be appealed on grounds of failure to =
follow the correct process. Such an appeal must be made to the RSAB =
within 30 days of the action being appealed. The RSAB will then decide =
whether the process was followed correctly.


                  

                  
One of the cases we were trying to =
cover was inaction of the chairs,=20
such as their refusal either to call a question or declare [lack of]=20
consensus.  Thus the wording as you saw it.  This leads to an=20
interesting question: when does the 30 day clock start? Also,  I think=20=

the intent was to provide direction to the chairs in the case of an=20
appeal being upheld.

With all of this in mind, I propose a bit of a merge:



                  

                    
Decisions of the RSWG can only be =
appealed on grounds of failure to=20
follow the correct process. Appeals should be made within 30 days of=20
any action, or in the case of failure to act, of notice having been=20
given to the RSWG. The RSAB will then decide if the process was=20
followed and will direct RSWG chairs as to what procedural actions are=20=

required.


                  

                  
Does this make sense?

Eliot



                  

                    
Cheers,
Adrian

-----Original Message-----
From: Rfced-future <rfced-future-bounces@iab.org> On Behalf Of Eliot =
Lear
Sent: 22 June 2021 15:38
To: rfced-future@iab.org
Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)

The following text was proposed to address appeals of the RSWG:



                    

                      
Appeals of RSWG decisions can be =
made to the RSAB if there are
concerns about the process followed by the RSWG. Appeals should be
made within 30 days of any action. The RSAB then decides if the
process has been followed.


                    

                    
Please raise concerns by 6 July if =
you have any.

Eliot





                  

                

              

            

            -- 

            Rfced-future mailing list

            Rfced-future@iab.org

            https://www.iab.org/mailman/listinfo/rfced-future

          

        

      

      

      

    

  





=

--Apple-Mail=_BFCCD580-E264-4C56-91E9-E70FB7773801--


From nobody Tue Jul  6 15:39:21 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00ADE3A18F7 for ; Tue,  6 Jul 2021 15:39:18 -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 RRT_RTM8gGjA for ; Tue,  6 Jul 2021 15:39:12 -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 154973A18F5 for ; Tue,  6 Jul 2021 15:39:12 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id l5so608738iok.7 for ; Tue, 06 Jul 2021 15:39:12 -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=7TSs6xZwuCxaVSnp4IWA3Et/bqMJH3bmzPKTpPMtqLw=; b=uUdLKKDHOArQ6VfWJT5FntNq/p0cbkDdaAEGR/JiFyyAN9P8ShpzkWRyVfdte8LpvG zhFPPLG51bQtnAIl3wguye49e3ggJib5fk6cK899imC4YwzvhC4MRs7K081Fq/kk8qeG FSMOw53DZLaUoWVR7NsUbrtDG/6EFh3HF+2/AcHeWj4g/hBqgUG95a+TBivoWO74O+dG nsbRlPU6zxWlbtwyfAA1CWcJ6DiC1Rb5cQCqCpAiEJks04MftlqKNl/zmM51OYgeawZA I8M3cdRnJgH/0hHFHOQXw4eegGT1QyWz3U68sPufP0GX3nMTEtjeXdGKVcK0m5VdGc7w zUcw==
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=7TSs6xZwuCxaVSnp4IWA3Et/bqMJH3bmzPKTpPMtqLw=; b=HLhFSsCCiU0FRZidYBts5FOE3s35dXtB1+759oHhWdPInPE4v1fiVoJNBJPjsn+APs otoeZaXFw6jBv+YPK6mvwWmzTvY9CErdeWeszx60ROYkQO0V4LoBNJJ5VEe9QV2URWLy uBpHYRAdnJmx1tlOAquPWGxNxMk7MDsx3qw+vIPZUrZWmnx8PnD4zecJAmdBP6DmVEkR 5cUXDklvkT954kJJU4T0Ab12z9fflzhk67qu3JuRIX2ZDRJuDS3JoxU85rNKDwJl2+RN S8Bpw91dn2vS8Hj5Auz8aZxlJAuEAN7vYY4lPBNIObxQRS80YLC53bJN7ftB9UQW1udB TASA==
X-Gm-Message-State: AOAM531moHXvr7TymDNHO2YNBaqjC1FlY7czyvAjksVBkyF9MaB/LzeO Txzwq8g5exXvdja/LKIwBLyWyF4rFfb1Bu/56nxMRA==
X-Google-Smtp-Source: ABdhPJykcGWY/3edEwDpjla68AP1ndz0R7i8q3BmqOrvBLHT8wgrkOg2ebbs9vXoAZflnOLyqo6sJ5kTSZAw/binoRA=
X-Received: by 2002:a02:9607:: with SMTP id c7mr11652007jai.87.1625611150604;  Tue, 06 Jul 2021 15:39:10 -0700 (PDT)
MIME-Version: 1.0
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>
In-Reply-To: <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>
From: Eric Rescorla 
Date: Tue, 6 Jul 2021 15:38:34 -0700
Message-ID: 
To: "Joel M. Halpern" 
Cc: Eliot Lear , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000002cd11305c67c1773"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Jul 2021 22:39:18 -0000

--0000000000002cd11305c67c1773
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

My concern with this, as indicated above, is that it seems to make the RSWG
subordinate to the RSAB. What stops the RSAB from
directing/instructing/etc. the RSWG to advance some document which clearly
does not have consensus.

If we need an escalation process for the chairs not advancing documents
which they ought to advance, ISTM that the right escalation path is to the
body that appointed those chairs. Joel, can you say more about why you
think they will be too busy to do that? Do you have other concerns besides
that?

-Ekr


On Tue, Jul 6, 2021 at 6:45 AM Joel M. Halpern  wrote:

> Having listened to several rounds of discussion, I think there does need
> to be a way to appeal chair inaction.  Any such appeal will be
> difficult.  As it should be.  But if the chairs are pushing their view
> over the rough consensus of the RSWG, that needs to be remedied.  And as
> a practical matter, going back to the appointing bodies is going to be
> even mroe difficult, since most members of the appointing bodies are
> probably leaving the RSWG / RSAB work to those they have delegated.  So
> I think that appeal needs to go to the RSAB.
>
> And if the appeal goes to the RSAB for inaction, then the RSAB needs to
> be able to do more than advise.  Because if the appeal takes place, and
> the RSAB agrees with the appeal, and the RSWG chairs ignore that, then
> it needs to be really clear that the chair or chairs need to be
> replaced.  There may be wording to say that short of "direct", but
> "advise" is not strong enough.
>
> Yours,
> Joel
>
> On 7/6/2021 2:12 AM, Eliot Lear wrote:
> > Eric,
> >
> > Thanks for your comments.  We are, I think, to the point on this issue
> > where it would be good to have a renewed sense on where people stand.  =
I
> > have two questions:
> >
> >   * Assuming you are in the rough and that there would be an appeals
> >     process, would changing the word =E2=80=9Cdirect=E2=80=9D to =E2=80=
=9Cadvise=E2=80=9D address your
> >     concerns, and would other people find that acceptable?
> >   * Do people agree with EKR that an appeal process is not required?
> >
> > As a reminder, we had a proposal earlier that did NOT have an appeals
> > process.  It seems to me that at its core, as a matter of practicality,
> > the issue here is whether chairs can be effectively managed from their
> > constituent bodies or whether the RSAB might abuse its authority on
> > appeal.  My suggestion to the group is in the form of general advice:
> > absent strong opinions either way, less process is better ;-)
> >
> > Given your comment, I propose to let this issue remain open for another
> > two weeks, so that we can properly resolve this matter.
> >
> > Eliot
> >
> > On 05.07.21 18:22, Eric Rescorla wrote:
> >>
> >>
> >> On Mon, Jun 28, 2021 at 10:42 PM Eliot Lear  >> > wrote:
> >>
> >>     Ok.  Then the text as it stands is as follows:
> >>
> >>         Decisions of the RSWG can only be appealed on grounds of
> failure to
> >>         follow the correct process. Appeals should be made within 30
> days of
> >>         any action, or in the case of failure to act, of notice having
> been
> >>         given to the RSWG. The RSAB will then decide if the process wa=
s
> >>         followed and will direct RSWG chairs as to what procedural
> actions are
> >>         required.
> >>
> >>     Any concerns?  Please respond by the 6th.
> >>
> >>
> >> Yes. I don't think "direct" is appropriate. The RSWG is not
> >> subordinate to the RSAB, so the RSAB should not be "directing" them.
> >>
> >> The more I think about this, the more I am concerned about the
> >> structure with appeals going to the RSAB.
> >>
> >> It seems to me that at a high level, there are two ways in which you
> >> could have an appeal:
> >>
> >> - A document comes to the RSAB which did not follow the process
> >> - Something else happens (e.g., the RSWG doesn't advance a document
> >> despite consensus).
> >>
> >> In the first case, the document is in front of the RSAB and we could
> >> simply empower them to reject it. In the second case, however, I don't
> >> believe the RSAB should be able to direct the WG to adopt/advance a
> >> document, but this text verges on this.
> >>
> >> What I would propose here is to dispense with appeals instead all the
> >> RSAB to reject documents for process violations. If WG members feel
> >> that the chairs are handling things badly in other ways, they can
> >> approach the bodies which appointed those chairs and ask for their
> >> removal, as indicated in S 3.1.1. This also gives us a handy answer to
> >> issue #72.
> >>
> >> -Ekr
> >>
> >>     Eliot
> >>
> >>     On 29.06.21 00:47, Brian E Carpenter wrote:
> >>>     On 28-Jun-21 23:31, Adrian Farrel wrote:
> >>>>     Yeah, I can live with that.
> >>>     Ditto.
> >>>
> >>>>     Failure to act is always a tricksy one. I think you have it
> covered.
> >>>     Yes. Let us not forget that the first ever formal appeal in the
> IETF
> >>>     was an appeal against IESG inaction.
> >>>
> >>>         Brian
> >>>
> >>>>     A
> >>>>
> >>>>     -----Original Message-----
> >>>>     From: Eliot Lear  
> >>>>     Sent: 28 June 2021 08:33
> >>>>     To:adrian@olddog.co.uk  ;
> rfced-future@iab.org  
> >>>>     Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals
> (RSWG)
> >>>>
> >>>>     Hi Adrian,
> >>>>
> >>>>     On 22.06.21 17:10, Adrian Farrel wrote:
> >>>>>     I completely agree with the sentiment, but I think the wording
> may have issues.
> >>>>>
> >>>>>     What the proposal does is say what can be done "if there are
> concerns about the process followed by the RSWG." It does not say (but I
> think it is meant to imply) that the content of the decisions cannot be
> appealed.
> >>>>>
> >>>>>     The "should" is also slightly ambiguous.
> >>>>>     And "any action" presumably means the action being appealed.
> >>>>>
> >>>>>     I would...
> >>>>>
> >>>>>     Decisions of the RSWG can only be appealed on grounds of failur=
e
> to follow the correct process. Such an appeal must be made to the RSAB
> within 30 days of the action being appealed. The RSAB will then decide
> whether the process was followed correctly.
> >>>>     One of the cases we were trying to cover was inaction of the
> chairs,
> >>>>     such as their refusal either to call a question or declare [lack
> of]
> >>>>     consensus.  Thus the wording as you saw it.  This leads to an
> >>>>     interesting question: when does the 30 day clock start? Also,  I
> think
> >>>>     the intent was to provide direction to the chairs in the case of
> an
> >>>>     appeal being upheld.
> >>>>
> >>>>     With all of this in mind, I propose a bit of a merge:
> >>>>
> >>>>>     Decisions of the RSWG can only be appealed on grounds of failur=
e
> to
> >>>>>     follow the correct process. Appeals should be made within 30
> days of
> >>>>>     any action, or in the case of failure to act, of notice having
> been
> >>>>>     given to the RSWG. The RSAB will then decide if the process was
> >>>>>     followed and will direct RSWG chairs as to what procedural
> actions are
> >>>>>     required.
> >>>>     Does this make sense?
> >>>>
> >>>>     Eliot
> >>>>
> >>>>>     Cheers,
> >>>>>     Adrian
> >>>>>
> >>>>>     -----Original Message-----
> >>>>>     From: Rfced-future   rfced-future-bounces@iab.org>  On Behalf Of Eliot Lear
> >>>>>     Sent: 22 June 2021 15:38
> >>>>>     To:rfced-future@iab.org  
> >>>>>     Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSW=
G)
> >>>>>
> >>>>>     The following text was proposed to address appeals of the RSWG:
> >>>>>
> >>>>>>     Appeals of RSWG decisions can be made to the RSAB if there are
> >>>>>>     concerns about the process followed by the RSWG. Appeals shoul=
d
> be
> >>>>>>     made within 30 days of any action. The RSAB then decides if th=
e
> >>>>>>     process has been followed.
> >>>>>     Please raise concerns by 6 July if you have any.
> >>>>>
> >>>>>     Eliot
> >>>>>
> >>>>>
> >>>>>
> >>     --
> >>     Rfced-future mailing list
> >>     Rfced-future@iab.org 
> >>     https://www.iab.org/mailman/listinfo/rfced-future
> >>     
> >>
> >>
> >
>

--0000000000002cd11305c67c1773
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


My concern with this, as indicated above, is that it =
seems to make the RSWG subordinate to the RSAB. What stops the RSAB from di=
recting/instructing/etc. the RSWG to advance some document which clearly do=
es not have consensus.

If we need an escalation pr=
ocess for the chairs not advancing documents which they ought to advance, I=
STM that the right escalation path is to the body that appointed those chai=
rs. Joel, can you say more about why you think they will be too busy to do =
that? Do you have other concerns besides that?

-Ekr


On Tue, Jul 6, 2021 at 6:45 AM Joel M. Halpern &l=
t;jmh@joelhalpern.com> wrote:=

Having listened=
 to several rounds of discussion, I think there does need 

to be a way to appeal chair inaction.=C2=A0 Any such appeal will be 

difficult.=C2=A0 As it should be.=C2=A0 But if the chairs are pushing their=
 view 

over the rough consensus of the RSWG, that needs to be remedied.=C2=A0 And =
as 

a practical matter, going back to the appointing bodies is going to be 

even mroe difficult, since most members of the appointing bodies are 

probably leaving the RSWG / RSAB work to those they have delegated.=C2=A0 S=
o 

I think that appeal needs to go to the RSAB.



And if the appeal goes to the RSAB for inaction, then the RSAB needs to 
be able to do more than advise.=C2=A0 Because if the appeal takes place, an=
d 

the RSAB agrees with the appeal, and the RSWG chairs ignore that, then 

it needs to be really clear that the chair or chairs need to be 

replaced.=C2=A0 There may be wording to say that short of "direct"=
;, but 

"advise" is not strong enough.



Yours,

Joel



On 7/6/2021 2:12 AM, Eliot Lear wrote:

> Eric,

> 

> Thanks for your comments.=C2=A0 We are, I think, to the point on this =
issue 

> where it would be good to have a renewed sense on where people stand.=
=C2=A0 I 

> have two questions:

> 

>=C2=A0 =C2=A0* Assuming you are in the rough and that there would be an=
 appeals

>=C2=A0 =C2=A0 =C2=A0process, would changing the word =E2=80=9Cdirect=E2=
=80=9D to =E2=80=9Cadvise=E2=80=9D address your

>=C2=A0 =C2=A0 =C2=A0concerns, and would other people find that acceptab=
le?

>=C2=A0 =C2=A0* Do people agree with EKR that an appeal process is not r=
equired?

> 

> As a reminder, we had a proposal earlier that did NOT have an appeals =


> process.=C2=A0 It seems to me that at its core, as a matter of practic=
ality, 

> the issue here is whether chairs can be effectively managed from their=
 

> constituent bodies or whether the RSAB might abuse its authority on 
> appeal.=C2=A0 My suggestion to the group is in the form of general adv=
ice: 

> absent strong opinions either way, less process is better ;-)

> 

> Given your comment, I propose to let this issue remain open for anothe=
r 

> two weeks, so that we can properly resolve this matter.

> 

> Eliot

> 

> On 05.07.21 18:22, Eric Rescorla wrote:

>>

>>

>> On Mon, Jun 28, 2021 at 10:42 PM Eliot Lear <lear@lear.ch 

>> <mailto:lear@=
lear.ch>> wrote:

>>

>>=C2=A0 =C2=A0 =C2=A0Ok.=C2=A0 Then the text as it stands is as foll=
ows:

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Decisions of the RSWG can only be=
 appealed on grounds of failure to

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0follow the correct process. Appea=
ls should be made within 30 days of

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any action, or in the case of fai=
lure to act, of notice having been

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0given to the RSWG. The RSAB will =
then decide if the process was

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0followed and will direct RSWG cha=
irs as to what procedural actions are

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0required.

>>

>>=C2=A0 =C2=A0 =C2=A0Any concerns?=C2=A0 Please respond by the 6th.<=
br>
>>

>>

>> Yes. I don't think "direct" is appropriate. The RSWG=
 is not 

>> subordinate to the RSAB, so the RSAB should not be "directing=
" them.

>>

>> The more I think about this, the more I am concerned about the 
>> structure with appeals going to the RSAB.

>>

>> It seems to me that at a high level, there are two ways in which y=
ou 

>> could have an appeal:

>>

>> - A document comes to the RSAB which did not follow the process
>> - Something else happens (e.g., the RSWG doesn't advance a doc=
ument 

>> despite consensus).

>>

>> In the first case, the document is in front of the RSAB and we cou=
ld 

>> simply empower them to reject it. In the second case, however, I d=
on't 

>> believe the RSAB should be able to direct the WG to adopt/advance =
a 

>> document, but this text verges on this.

>>

>> What I would propose here is to dispense with appeals instead all =
the 

>> RSAB to reject documents for process violations. If WG members fee=
l 

>> that the chairs are handling things badly in other ways, they can =


>> approach the bodies which appointed those chairs and ask for their=
 

>> removal, as indicated in S 3.1.1. This also gives us a handy answe=
r to 

>> issue #72.

>>

>> -Ekr

>>

>>=C2=A0 =C2=A0 =C2=A0Eliot

>>

>>=C2=A0 =C2=A0 =C2=A0On 29.06.21 00:47, Brian E Carpenter wrote:

>>>=C2=A0 =C2=A0 =C2=A0On 28-Jun-21 23:31, Adrian Farrel wrote:
>>>>=C2=A0 =C2=A0 =C2=A0Yeah, I can live with that.

>>>=C2=A0 =C2=A0 =C2=A0Ditto.

>>>

>>>>=C2=A0 =C2=A0 =C2=A0Failure to act is always a tricksy one.=
 I think you have it covered.

>>>=C2=A0 =C2=A0 =C2=A0Yes. Let us not forget that the first ever =
formal appeal in the IETF

>>>=C2=A0 =C2=A0 =C2=A0was an appeal against IESG inaction.

>>>

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brian

>>>

>>>>=C2=A0 =C2=A0 =C2=A0A

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0-----Original Message-----

>>>>=C2=A0 =C2=A0 =C2=A0From: Eliot Lear<lear@lear.ch>=C2=A0 <mailto:lear@lear.ch>=C2=A0 

>>>>=C2=A0 =C2=A0 =C2=A0Sent: 28 June 2021 08:33

>>>>=C2=A0 =C2=A0 =C2=A0To:adrian@olddog.co.uk=C2=A0 <mailto:adrian@olddog.co.uk&g=
t;;rfced-future@i=
ab.org=C2=A0 <mailto:rfced-future@iab.org>

>>>>=C2=A0 =C2=A0 =C2=A0Subject: Re: [Rfced-future] Consensus c=
heck: Issue 16: Appeals (RSWG)

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0Hi Adrian,

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0On 22.06.21 17:10, Adrian Farrel wrote:=


>>>>>=C2=A0 =C2=A0 =C2=A0I completely agree with the sentime=
nt, but I think the wording may have issues.

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0What the proposal does is say what =
can be done "if there are concerns about the process followed by the R=
SWG." It does not say (but I think it is meant to imply) that the cont=
ent of the decisions cannot be appealed.

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0The "should" is also slig=
htly ambiguous.

>>>>>=C2=A0 =C2=A0 =C2=A0And "any action" presumab=
ly means the action being appealed.

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0I would...

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0Decisions of the RSWG can only be a=
ppealed on grounds of failure to follow the correct process. Such an appeal=
 must be made to the RSAB within 30 days of the action being appealed. The =
RSAB will then decide whether the process was followed correctly.

>>>>=C2=A0 =C2=A0 =C2=A0One of the cases we were trying to cove=
r was inaction of the chairs,

>>>>=C2=A0 =C2=A0 =C2=A0such as their refusal either to call a =
question or declare [lack of]

>>>>=C2=A0 =C2=A0 =C2=A0consensus.=C2=A0 Thus the wording as yo=
u saw it.=C2=A0 This leads to an

>>>>=C2=A0 =C2=A0 =C2=A0interesting question: when does the 30 =
day clock start? Also,=C2=A0 I think

>>>>=C2=A0 =C2=A0 =C2=A0the intent was to provide direction to =
the chairs in the case of an

>>>>=C2=A0 =C2=A0 =C2=A0appeal being upheld.

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0With all of this in mind, I propose a b=
it of a merge:

>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0Decisions of the RSWG can only be a=
ppealed on grounds of failure to

>>>>>=C2=A0 =C2=A0 =C2=A0follow the correct process. Appeals=
 should be made within 30 days of

>>>>>=C2=A0 =C2=A0 =C2=A0any action, or in the case of failu=
re to act, of notice having been

>>>>>=C2=A0 =C2=A0 =C2=A0given to the RSWG. The RSAB will th=
en decide if the process was

>>>>>=C2=A0 =C2=A0 =C2=A0followed and will direct RSWG chair=
s as to what procedural actions are

>>>>>=C2=A0 =C2=A0 =C2=A0required.

>>>>=C2=A0 =C2=A0 =C2=A0Does this make sense?

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0Eliot

>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0Cheers,

>>>>>=C2=A0 =C2=A0 =C2=A0Adrian

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0-----Original Message-----

>>>>>=C2=A0 =C2=A0 =C2=A0From: Rfced-future<rfced-future-bounces@i=
ab.org>=C2=A0 <mailto:rfced-future-bounces@iab.org>=C2=A0 On Behalf=
 Of Eliot Lear

>>>>>=C2=A0 =C2=A0 =C2=A0Sent: 22 June 2021 15:38

>>>>>=C2=A0 =C2=A0 =C2=A0To:rfced-future@iab.org=C2=A0 <mailto:rfced-future@iab.or=
g>

>>>>>=C2=A0 =C2=A0 =C2=A0Subject: [Rfced-future] Consensus c=
heck: Issue 16: Appeals (RSWG)

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0The following text was proposed to =
address appeals of the RSWG:

>>>>>

>>>>>>=C2=A0 =C2=A0 =C2=A0Appeals of RSWG decisions can b=
e made to the RSAB if there are

>>>>>>=C2=A0 =C2=A0 =C2=A0concerns about the process foll=
owed by the RSWG. Appeals should be

>>>>>>=C2=A0 =C2=A0 =C2=A0made within 30 days of any acti=
on. The RSAB then decides if the

>>>>>>=C2=A0 =C2=A0 =C2=A0process has been followed.

>>>>>=C2=A0 =C2=A0 =C2=A0Please raise concerns by 6 July if =
you have any.

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0Eliot

>>>>>

>>>>>

>>>>>

>>=C2=A0 =C2=A0 =C2=A0-- 

>>=C2=A0 =C2=A0 =C2=A0Rfced-future mailing list

>>=C2=A0 =C2=A0 =C2=A0Rfced-future@iab.org <mailto:Rfced-future@iab.org>

>>=C2=A0 =C2=A0 =C2=A0https://www.iab.org/mai=
lman/listinfo/rfced-future

>>=C2=A0 =C2=A0 =C2=A0<https://www.iab.org=
/mailman/listinfo/rfced-future>

>>

>>

> 




--0000000000002cd11305c67c1773--


From nobody Tue Jul  6 15:49:08 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACF23A19F6 for ; Tue,  6 Jul 2021 15:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 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.338, 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 YOUonkkeuOhg for ; Tue,  6 Jul 2021 15:49:01 -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 CB04E3A19F3 for ; Tue,  6 Jul 2021 15:49:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GKHmF1xjGz1nw96; Tue,  6 Jul 2021 15:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1625611741; bh=IKlIDH3sMYlxiI463xi3ylzlipE01T7LsZUKLHzHMNY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gKKgXIp20EAFzI3+XjnGAp9O96zX10R0fV0x/+nEGcjPJn4Fjn6sBmtM+O+pJGvwy FBvRecjUdZpLfARdv566qe7D5BSYTiw6sq9PVdhpXYXeqAUuGr7QvxeKR1eTrjEcEz QiVpB3qLSItQ9X3LNTwli6ATcQ5bMw2bIjsoLtqI=
X-Quarantine-ID: 
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 4GKHmD25Wwz1nt05; Tue,  6 Jul 2021 15:49:00 -0700 (PDT)
To: Eric Rescorla 
Cc: Eliot Lear , rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com> 
From: "Joel M. Halpern" 
Message-ID: <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>
Date: Tue, 6 Jul 2021 18:48:58 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Jul 2021 22:49:07 -0000

Fair question.   My concern with appealeing the chairs to the appointing 
body is several-fold.

First, the appointing bodies ONLY recourse is to fire the chairs.  I 
would hope for an appeals process that had soem resolution short of that.

Second is the matter of involvement.  It is not just a matter of "too 
busy" although that is relevant.  The RSAB members will have been 
involved in the RSWG and will understand the context of the discussion. 
   The other members of the appointing bodies will likely not be paying 
attention.  Part of the problem with the previous setup was that the IAB 
didn't really pay attention to the RSE / RPC activiites.  And this makes 
their involvement even worse.

I would note that if the RSAB directs an action on the basis that RSWG 
process requires it (the only basis they can rule on such an appeal) and 
if they are just making up what they want, then one can appeal the RSAB 
decision on process grounds to whomever we say such process appeals go to.

Yours,
Joel

On 7/6/2021 6:38 PM, Eric Rescorla wrote:
> My concern with this, as indicated above, is that it seems to make the 
> RSWG subordinate to the RSAB. What stops the RSAB from 
> directing/instructing/etc. the RSWG to advance some document which 
> clearly does not have consensus.
> 
> If we need an escalation process for the chairs not advancing documents 
> which they ought to advance, ISTM that the right escalation path is to 
> the body that appointed those chairs. Joel, can you say more about why 
> you think they will be too busy to do that? Do you have other concerns 
> besides that?
> 
> -Ekr
> 
> 
> On Tue, Jul 6, 2021 at 6:45 AM Joel M. Halpern  > wrote:
> 
>     Having listened to several rounds of discussion, I think there does
>     need
>     to be a way to appeal chair inaction.  Any such appeal will be
>     difficult.  As it should be.  But if the chairs are pushing their view
>     over the rough consensus of the RSWG, that needs to be remedied. 
>     And as
>     a practical matter, going back to the appointing bodies is going to be
>     even mroe difficult, since most members of the appointing bodies are
>     probably leaving the RSWG / RSAB work to those they have delegated.  So
>     I think that appeal needs to go to the RSAB.
> 
>     And if the appeal goes to the RSAB for inaction, then the RSAB needs to
>     be able to do more than advise.  Because if the appeal takes place, and
>     the RSAB agrees with the appeal, and the RSWG chairs ignore that, then
>     it needs to be really clear that the chair or chairs need to be
>     replaced.  There may be wording to say that short of "direct", but
>     "advise" is not strong enough.
> 
>     Yours,
>     Joel
> 
>     On 7/6/2021 2:12 AM, Eliot Lear wrote:
>      > Eric,
>      >
>      > Thanks for your comments.  We are, I think, to the point on this
>     issue
>      > where it would be good to have a renewed sense on where people
>     stand.  I
>      > have two questions:
>      >
>      >   * Assuming you are in the rough and that there would be an appeals
>      >     process, would changing the word “direct” to “advise” address
>     your
>      >     concerns, and would other people find that acceptable?
>      >   * Do people agree with EKR that an appeal process is not required?
>      >
>      > As a reminder, we had a proposal earlier that did NOT have an
>     appeals
>      > process.  It seems to me that at its core, as a matter of
>     practicality,
>      > the issue here is whether chairs can be effectively managed from
>     their
>      > constituent bodies or whether the RSAB might abuse its authority on
>      > appeal.  My suggestion to the group is in the form of general
>     advice:
>      > absent strong opinions either way, less process is better ;-)
>      >
>      > Given your comment, I propose to let this issue remain open for
>     another
>      > two weeks, so that we can properly resolve this matter.
>      >
>      > Eliot
>      >
>      > On 05.07.21 18:22, Eric Rescorla wrote:
>      >>
>      >>
>      >> On Mon, Jun 28, 2021 at 10:42 PM Eliot Lear      
>      >> >> wrote:
>      >>
>      >>     Ok.  Then the text as it stands is as follows:
>      >>
>      >>         Decisions of the RSWG can only be appealed on grounds of
>     failure to
>      >>         follow the correct process. Appeals should be made
>     within 30 days of
>      >>         any action, or in the case of failure to act, of notice
>     having been
>      >>         given to the RSWG. The RSAB will then decide if the
>     process was
>      >>         followed and will direct RSWG chairs as to what
>     procedural actions are
>      >>         required.
>      >>
>      >>     Any concerns?  Please respond by the 6th.
>      >>
>      >>
>      >> Yes. I don't think "direct" is appropriate. The RSWG is not
>      >> subordinate to the RSAB, so the RSAB should not be "directing" them.
>      >>
>      >> The more I think about this, the more I am concerned about the
>      >> structure with appeals going to the RSAB.
>      >>
>      >> It seems to me that at a high level, there are two ways in which
>     you
>      >> could have an appeal:
>      >>
>      >> - A document comes to the RSAB which did not follow the process
>      >> - Something else happens (e.g., the RSWG doesn't advance a document
>      >> despite consensus).
>      >>
>      >> In the first case, the document is in front of the RSAB and we
>     could
>      >> simply empower them to reject it. In the second case, however, I
>     don't
>      >> believe the RSAB should be able to direct the WG to adopt/advance a
>      >> document, but this text verges on this.
>      >>
>      >> What I would propose here is to dispense with appeals instead
>     all the
>      >> RSAB to reject documents for process violations. If WG members feel
>      >> that the chairs are handling things badly in other ways, they can
>      >> approach the bodies which appointed those chairs and ask for their
>      >> removal, as indicated in S 3.1.1. This also gives us a handy
>     answer to
>      >> issue #72.
>      >>
>      >> -Ekr
>      >>
>      >>     Eliot
>      >>
>      >>     On 29.06.21 00:47, Brian E Carpenter wrote:
>      >>>     On 28-Jun-21 23:31, Adrian Farrel wrote:
>      >>>>     Yeah, I can live with that.
>      >>>     Ditto.
>      >>>
>      >>>>     Failure to act is always a tricksy one. I think you have
>     it covered.
>      >>>     Yes. Let us not forget that the first ever formal appeal in
>     the IETF
>      >>>     was an appeal against IESG inaction.
>      >>>
>      >>>         Brian
>      >>>
>      >>>>     A
>      >>>>
>      >>>>     -----Original Message-----
>      >>>>     From: Eliot Lear> 
>     >
>      >>>>     Sent: 28 June 2021 08:33
>      >>>> To:adrian@olddog.co.uk  
>          >;rfced-future@iab.org
>            >
>      >>>>     Subject: Re: [Rfced-future] Consensus check: Issue 16:
>     Appeals (RSWG)
>      >>>>
>      >>>>     Hi Adrian,
>      >>>>
>      >>>>     On 22.06.21 17:10, Adrian Farrel wrote:
>      >>>>>     I completely agree with the sentiment, but I think the
>     wording may have issues.
>      >>>>>
>      >>>>>     What the proposal does is say what can be done "if there
>     are concerns about the process followed by the RSWG." It does not
>     say (but I think it is meant to imply) that the content of the
>     decisions cannot be appealed.
>      >>>>>
>      >>>>>     The "should" is also slightly ambiguous.
>      >>>>>     And "any action" presumably means the action being appealed.
>      >>>>>
>      >>>>>     I would...
>      >>>>>
>      >>>>>     Decisions of the RSWG can only be appealed on grounds of
>     failure to follow the correct process. Such an appeal must be made
>     to the RSAB within 30 days of the action being appealed. The RSAB
>     will then decide whether the process was followed correctly.
>      >>>>     One of the cases we were trying to cover was inaction of
>     the chairs,
>      >>>>     such as their refusal either to call a question or declare
>     [lack of]
>      >>>>     consensus.  Thus the wording as you saw it.  This leads to an
>      >>>>     interesting question: when does the 30 day clock start?
>     Also,  I think
>      >>>>     the intent was to provide direction to the chairs in the
>     case of an
>      >>>>     appeal being upheld.
>      >>>>
>      >>>>     With all of this in mind, I propose a bit of a merge:
>      >>>>
>      >>>>>     Decisions of the RSWG can only be appealed on grounds of
>     failure to
>      >>>>>     follow the correct process. Appeals should be made within
>     30 days of
>      >>>>>     any action, or in the case of failure to act, of notice
>     having been
>      >>>>>     given to the RSWG. The RSAB will then decide if the
>     process was
>      >>>>>     followed and will direct RSWG chairs as to what
>     procedural actions are
>      >>>>>     required.
>      >>>>     Does this make sense?
>      >>>>
>      >>>>     Eliot
>      >>>>
>      >>>>>     Cheers,
>      >>>>>     Adrian
>      >>>>>
>      >>>>>     -----Original Message-----
>      >>>>>     From: Rfced-future     > 
>          >  On Behalf Of Eliot Lear
>      >>>>>     Sent: 22 June 2021 15:38
>      >>>>> To:rfced-future@iab.org  
>     >
>      >>>>>     Subject: [Rfced-future] Consensus check: Issue 16:
>     Appeals (RSWG)
>      >>>>>
>      >>>>>     The following text was proposed to address appeals of the
>     RSWG:
>      >>>>>
>      >>>>>>     Appeals of RSWG decisions can be made to the RSAB if
>     there are
>      >>>>>>     concerns about the process followed by the RSWG. Appeals
>     should be
>      >>>>>>     made within 30 days of any action. The RSAB then decides
>     if the
>      >>>>>>     process has been followed.
>      >>>>>     Please raise concerns by 6 July if you have any.
>      >>>>>
>      >>>>>     Eliot
>      >>>>>
>      >>>>>
>      >>>>>
>      >>     --
>      >>     Rfced-future mailing list
>      >> Rfced-future@iab.org 
>     >
>      >> https://www.iab.org/mailman/listinfo/rfced-future
>     
>      >>          >
>      >>
>      >>
>      >
> 


From nobody Tue Jul  6 16:58:29 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B753A0883 for ; Tue,  6 Jul 2021 16:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 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.338, 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=mozilla.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 d5dvx7DaIZsJ for ; Tue,  6 Jul 2021 16:58:26 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 09FCA3A0881 for ; Tue,  6 Jul 2021 16:58:25 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id h190so764461iof.12 for ; Tue, 06 Jul 2021 16:58:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=KZUHuZ36cJH+u0STplkDSlnX003mSrnvL90PRJlC4nk=; b=aXgUdidsYfFVIOBfGGkTYd9hoCJXFIgDcG94+0uxeOBmaU3kOIU507EU1a7/7tQujg gbmFcKYIoMusab+MRNVJEQrO4u0RY0az6sS/5FQ7SSK2q1naxbVidLDuBPuMu2VgkYyI EbAuodZNzUub3IvZnIpbGy2/8DO8R/SCDC91g=
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=KZUHuZ36cJH+u0STplkDSlnX003mSrnvL90PRJlC4nk=; b=lwTY96zwvFYTjkrFw3zKNanxsoXJ1eVU5x3sSCAoSXjkyoUZvCPxmHFp7FPWgmN7KL dVtYCUQqom3Pz7QOOwOofL1VQqhv0y/rHmdQvuvjui8YlREm7FGAx/rmxQkg1hwBUeUE 9P+ZLG0A/HpIaA/MrJ860o13oyd0wjqQthkuhXM1OyY/MZ9UUiCJuYNen3QG49ifO8k7 fiCStQvmstLgDpWRYymSzdKCq8APS02hBBHyZ77D/eZ3n5YXa1A43TzjBjPO/BqiWIDQ NX9LI5UYEVELdj1H3IxeTnGfDZKktHHRwlfie9ol1rUjZHbk04L6hyrYXwZLIT9y7r3Y k6Wg==
X-Gm-Message-State: AOAM530+TOto3hk5AoO66QvwcAzlilu16Z8JrlUIuf9hb/RVKNtJIZyc WUCayhmHerb86lcxwwTeaxp+uw==
X-Google-Smtp-Source: ABdhPJyRBxcIasQIop51xXVuRUq3nAtZF2oE0FIWp38mC54mmJ/oflabN3/HQkek73Ft4KocYmsNdg==
X-Received: by 2002:a6b:7b47:: with SMTP id m7mr17983970iop.193.1625615904502;  Tue, 06 Jul 2021 16:58:24 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id n13sm558153ilq.5.2021.07.06.16.58.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 16:58:24 -0700 (PDT)
To: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>
From: Peter Saint-Andre 
Message-ID: 
Date: Tue, 6 Jul 2021 17:58:22 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Jul 2021 23:58:29 -0000

On 7/6/21 4:48 PM, Joel M. Halpern wrote:
> Fair question.   My concern with appealeing the chairs to the appointing
> body is several-fold.
> 
> First, the appointing bodies ONLY recourse is to fire the chairs.  I
> would hope for an appeals process that had soem resolution short of that.

It's not clear to me that the only recourse is to fire the chairs. The
appointing bodies could certainly consult, advise, admonish, express
serious concerns, etc.

> Second is the matter of involvement.  It is not just a matter of "too
> busy" although that is relevant.  The RSAB members will have been
> involved in the RSWG and will understand the context of the discussion.

Given that the appointing bodies for the RSWG chairs each have a
representative on the RSAB, one hopes that those representatives will be
paying attention and can brief the rest of the body.

Peter


From nobody Tue Jul  6 17:17:21 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7821B3A10BF for ; Tue,  6 Jul 2021 17:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.136
X-Spam-Level: 
X-Spam-Status: No, score=-3.136 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.338, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 zJPOI-Nc4-Vs for ; Tue,  6 Jul 2021 17:17:16 -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 0C8E83A10B7 for ; Tue,  6 Jul 2021 17:17:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GKKk335cBz1nvkT; Tue,  6 Jul 2021 17:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1625617035; bh=Yf0sBwG/RXwzEhs0DKULhvo/Z3UAtKnpzeAzRImpRNw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=cNZ7nTtFaS8dOFSjrW3g1WrL3rBmhAIc1E4OdCbKZrVVwYCUBOcW70dQZl5ztJj8/ e+OOnA0HDuSEjKgyx7qgLUV2cZVZWy+FX4CvV+vP10npHoqXBwA/bs0JBty6caLCQR S0QPO2NnXABveEQaEF03oJqA5f93WZBoGI7xXvXY=
X-Quarantine-ID: 
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)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GKKk269Hvz1nsCk; Tue,  6 Jul 2021 17:17:14 -0700 (PDT)
To: Peter Saint-Andre , rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com> 
From: "Joel M. Halpern" 
Message-ID: 
Date: Tue, 6 Jul 2021 20:17:12 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 00:17:20 -0000

In line...
Yours,
Joel

On 7/6/2021 7:58 PM, Peter Saint-Andre wrote:
> On 7/6/21 4:48 PM, Joel M. Halpern wrote:
>> Fair question.   My concern with appealeing the chairs to the appointing
>> body is several-fold.
>>
>> First, the appointing bodies ONLY recourse is to fire the chairs.  I
>> would hope for an appeals process that had soem resolution short of that.
> 
> It's not clear to me that the only recourse is to fire the chairs. The
> appointing bodies could certainly consult, advise, admonish, express
> serious concerns, etc.
Hmmm.  Really?  The IESG or the IAB getting into giving advice and 
opinions on how the RSWG works seems to be an involvement we have been 
avoiding.  

> 
>> Second is the matter of involvement.  It is not just a matter of "too
>> busy" although that is relevant.  The RSAB members will have been
>> involved in the RSWG and will understand the context of the discussion.
> 
> Given that the appointing bodies for the RSWG chairs each have a
> representative on the RSAB, one hopes that those representatives will be
> paying attention and can brief the rest of the body.
Then we might as well take the appeal to the RSAB, if it is those 
members who are going to drive the conversation anyway.
> 
> Peter
> 


From nobody Tue Jul  6 21:19:14 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D093A0E28 for ; Tue,  6 Jul 2021 21:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 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.338, RCVD_IN_DNSWL_BLOCKED=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 U8sfkBWCZToy for ; Tue,  6 Jul 2021 21:19:08 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 8D04A3A0E1D for ; Tue,  6 Jul 2021 21:19:08 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id u19so354050plc.3 for ; Tue, 06 Jul 2021 21:19:08 -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=lr0+57/TX2dvyV94c87iv4wOFJSF48DgnFmqnjlyMNQ=; b=RtdyG48sCpjy+Lyu1eR+b489rJORggLja4QD8oCZv15uhAT7lUyK8j/bmH1Kv9Ebs7 xikziCOvGxkSfZDgR1et2KRZznOJNrP1nuFZgjgftCbZSfpUYY4tEWqWkLef4PTGybcA kW10ddq9PnAltY53Df72WhJuK+LlI5XCklMuQks0FzAGbPPm8PhnxEg/Ig+1hrPhJU7n RHXbaxid8y0qgpiGPFhLguug3slt8TUjmNdngUMRmsfxsps7oZ2iKzae03s/qJxwLanh 2joSQj4JTik4xDNU3AEU7BnzkZMU8yBvyi/g3dypL0Itmj3RHIqFr7vgl4f6bc/ch/sS 5+jg==
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=lr0+57/TX2dvyV94c87iv4wOFJSF48DgnFmqnjlyMNQ=; b=JuLmok5fol4A7a9GjDJkpSxIFbFr2sf8uCzk8cV7a/ldX924X9VbMuAfz299YGdKRn Q/HPG+i1nCk4uAabLAE9igGKyAK2CgeVDFy4TKH+HTZ1T1zG3/gDIUWRiIUfvkY1xh0b 5FOJnyoTiku9kUCVq1bFdbmWOvbL0v90GeeJVepxiLNxyoOUUT8yzJ9FjOSTF/7XtmGh bonQeTsocPVH3/bAVquHAglJL1yDcBYcMh/MiQxBvfBO7/5HjunlWSbQWdObcRJXJZNo C3G38mgWrX9C0t1co8uSCeSp1ZgKuDUdLYuVVnn8pw/Qq+oqXe6MUSJ/hUPXtUNibgzS w4Gg==
X-Gm-Message-State: AOAM530AJQQ5mJCtduzikeKR2E0X8c0npl0oOKYHwMx0+u5iTyd5XAmm E4QGZA1xDqiNrIMvc4dLh9Ghwzms99eo9w==
X-Google-Smtp-Source: ABdhPJwJpaYF9MAQJw40lwv5NmUTC0KhZDHbPCCdleBE5xGm41TIfhvsKkIFOQE3aOVzKU5il/kypw==
X-Received: by 2002:a17:90a:6848:: with SMTP id e8mr3882043pjm.224.1625631547193;  Tue, 06 Jul 2021 21:19:07 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id lb13sm4202291pjb.5.2021.07.06.21.19.05 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 21:19:06 -0700 (PDT)
To: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>  
From: Brian E Carpenter 
Message-ID: <1de70954-0b3a-8a36-c744-07abf0d88023@gmail.com>
Date: Wed, 7 Jul 2021 16:19:02 +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: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 04:19:14 -0000

On 06-Jul-21 18:12, Eliot Lear wrote:
> Eric,
>=20
> Thanks for your comments.=C2=A0 We are, I think, to the point on this i=
ssue where it would be good to have a renewed sense on where people stand=
=2E=C2=A0 I have two questions:
>=20
>   * Assuming you are in the rough and that there would be an appeals pr=
ocess, would changing the word =E2=80=9Cdirect=E2=80=9D to =E2=80=9Cadvis=
e=E2=80=9D address your concerns, and would other people find that accept=
able?

I think in practice it matters little, so it's OK for me.

>   * Do people agree with EKR that an appeal process is not required?

No. We need checks and balances.=20

    Brian

>=20
> As a reminder, we had a proposal earlier that did NOT have an appeals p=
rocess.=C2=A0 It seems to me that at its core, as a matter of practicalit=
y, the issue here is whether chairs can be effectively managed from their=20
constituent bodies or whether the RSAB might abuse its authority on appea=
l.=C2=A0 My suggestion to the group is in the form of general advice: abs=
ent strong opinions either way, less process is better ;-)
>=20
> Given your comment, I propose to let this issue remain open for another=20
two weeks, so that we can properly resolve this matter.
>=20
> Eliot
>=20
> On 05.07.21 18:22, Eric Rescorla wrote:
>>
>>
>> On Mon, Jun 28, 2021 at 10:42 PM Eliot Lear > wrote:
>>
>>     Ok.=C2=A0 Then the text as it stands is as follows:
>>
>>         Decisions of the RSWG can only be appealed on grounds of failu=
re to=20
>>         follow the correct process. Appeals should be made within 30 d=
ays of=20
>>         any action, or in the case of failure to act, of notice having=20
been=20
>>         given to the RSWG. The RSAB will then decide if the process wa=
s=20
>>         followed and will direct RSWG chairs as to what procedural act=
ions are=20
>>         required.
>>
>>     Any concerns?=C2=A0 Please respond by the 6th.
>>
>>
>> Yes. I don't think "direct" is appropriate. The RSWG is not subordinat=
e to the RSAB, so the RSAB should not be "directing" them.
>>
>> The more I think about this, the more I am concerned about the structu=
re with appeals going to the RSAB.
>>
>> It seems to me that at a high level, there are two ways in which you c=
ould have an appeal:
>>
>> - A document comes to the RSAB which did not follow the process
>> - Something else happens (e.g., the RSWG doesn't advance a document de=
spite consensus).
>>
>> In the first case, the document is in front of the RSAB and we could s=
imply empower them to reject it. In the second case, however, I don't bel=
ieve the RSAB should be able to direct the WG to adopt/advance a document=
, but this text verges on this.
>>
>> What I would propose here is to dispense with appeals instead all the =
RSAB to reject documents for process violations. If WG members feel that =
the chairs are handling things badly in other ways, they can approach the=20
bodies which appointed those chairs and ask for their removal, as indicat=
ed in S 3.1.1. This also gives us a handy answer to issue #72.
>>
>> -Ekr
>>
>>     Eliot
>>
>>     On 29.06.21 00:47, Brian E Carpenter wrote:
>>>     On 28-Jun-21 23:31, Adrian Farrel wrote:
>>>>     Yeah, I can live with that.
>>>     Ditto.
>>>
>>>>     Failure to act is always a tricksy one. I think you have it cove=
red.
>>>     Yes. Let us not forget that the first ever formal appeal in the I=
ETF
>>>     was an appeal against IESG inaction.
>>>
>>>        Brian
>>>
>>>>     A
>>>>
>>>>     -----Original Message-----
>>>>     From: Eliot Lear  =20
>>>>     Sent: 28 June 2021 08:33
>>>>     To: adrian@olddog.co.uk ; rfced-futu=
re@iab.org 
>>>>     Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (=
RSWG)
>>>>
>>>>     Hi Adrian,
>>>>
>>>>     On 22.06.21 17:10, Adrian Farrel wrote:
>>>>>     I completely agree with the sentiment, but I think the wording =
may have issues.
>>>>>
>>>>>     What the proposal does is say what can be done "if there are co=
ncerns about the process followed by the RSWG." It does not say (but I th=
ink it is meant to imply) that the content of the decisions cannot be app=
ealed.
>>>>>
>>>>>     The "should" is also slightly ambiguous.
>>>>>     And "any action" presumably means the action being appealed.
>>>>>
>>>>>     I would...
>>>>>
>>>>>     Decisions of the RSWG can only be appealed on grounds of failur=
e to follow the correct process. Such an appeal must be made to the RSAB =
within 30 days of the action being appealed. The RSAB will then decide wh=
ether the process was followed correctly.
>>>>     One of the cases we were trying to cover was inaction of the cha=
irs,=20
>>>>     such as their refusal either to call a question or declare [lack=20
of]=20
>>>>     consensus.  Thus the wording as you saw it.  This leads to an=20
>>>>     interesting question: when does the 30 day clock start? Also,  I=20
think=20
>>>>     the intent was to provide direction to the chairs in the case of=20
an=20
>>>>     appeal being upheld.
>>>>
>>>>     With all of this in mind, I propose a bit of a merge:
>>>>
>>>>>     Decisions of the RSWG can only be appealed on grounds of failur=
e to=20
>>>>>     follow the correct process. Appeals should be made within 30 da=
ys of=20
>>>>>     any action, or in the case of failure to act, of notice having =
been=20
>>>>>     given to the RSWG. The RSAB will then decide if the process was=20

>>>>>     followed and will direct RSWG chairs as to what procedural acti=
ons are=20
>>>>>     required.
>>>>     Does this make sense?
>>>>
>>>>     Eliot
>>>>
>>>>>     Cheers,
>>>>>     Adrian
>>>>>
>>>>>     -----Original Message-----
>>>>>     From: Rfced-future   On Behalf Of Eliot Lear
>>>>>     Sent: 22 June 2021 15:38
>>>>>     To: rfced-future@iab.org 
>>>>>     Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSW=
G)
>>>>>
>>>>>     The following text was proposed to address appeals of the RSWG:=

>>>>>
>>>>>>     Appeals of RSWG decisions can be made to the RSAB if there are=

>>>>>>     concerns about the process followed by the RSWG. Appeals shoul=
d be
>>>>>>     made within 30 days of any action. The RSAB then decides if th=
e
>>>>>>     process has been followed.
>>>>>     Please raise concerns by 6 July if you have any.
>>>>>
>>>>>     Eliot
>>>>>
>>>>>
>>>>>
>>     --=20
>>     Rfced-future mailing list
>>     Rfced-future@iab.org 
>>     https://www.iab.org/mailman/listinfo/rfced-future 
>>
>>
>=20


From nobody Tue Jul  6 21:24:31 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F603A1079 for ; Tue,  6 Jul 2021 21:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 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.338, 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 ziUMsI76KM-R for ; Tue,  6 Jul 2021 21:24:29 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 E99693A1081 for ; Tue,  6 Jul 2021 21:24:27 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id w15so913408pgk.13 for ; Tue, 06 Jul 2021 21:24:27 -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=QCaNbMEqPx+vt8oFSA9ph1AmBJ9zCtAgHMeQlQtx8wg=; b=PkykmWrmMvunJXKXhIszEiFa1D4iJFqCFx7A3jm+oyc1pKuGfrrTcA6FIX8T6UBR19 azC1mkQOl2pJ3p9Hw3fLg6QyH55xNZKCaKCyjJq66u6XNzFe1gnhjU+vVpQrcd2960dZ vnSHl108+LfkLmSJlfjwuAJH3ABuxqpMouhadYGFPDNQnz1xjAZsORG+OrHazba4LTXN vImd214pij7f6JdlC0MM5WtA7hS4XUCLeOS8HmLYv4uLkYj8oQ2kv16XHStH6xjemzpC FRmPXq9aQReMY0oJHUF/99IQM0H44PDmsNb9mYiYxO2rMsZ8n46bwOw1jIQhrTEZzngn VvwQ==
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=QCaNbMEqPx+vt8oFSA9ph1AmBJ9zCtAgHMeQlQtx8wg=; b=QqcJPhuP5Byr3qoVZ3/Flh3zTLVhYm/iZiSsBrFOjH1dS1BTc56ClrJCuNnp5pbBNy 8KfrFzQWDiWv0vF7JgkddumBXiFRipeGnUWgomE7GfebPtOjmOVKv3kfYA+teLLQGEDe B7aQLjeTf+UCR3+5lrOL8nIVCRtj8PTwPxB77EiKf8ZkA1BOMULAr5AoOwKbn9oQFzxT WgVaPfuJ/lZfPfgL5ztGIk4NTdL6nbEHwL0Hm6wiIY/hExaUAWjAynFOghxCuPYhxmih P5mJBkTzNOLg3RgB3PU90qMthhzSnp3ece2ENbY8408ThUpnIt9bQA45S/uwsiTV8DMJ BZAA==
X-Gm-Message-State: AOAM531OtSk/oBajOUS4lBFPngkd9JTZabjjncwYHsMfZsj5NQVUJrID K+Vqc/lK3AOu540qz3FbRQZ6iVeva65Cvg==
X-Google-Smtp-Source: ABdhPJzBpOiCF7nsCJi7HPy3Jfuy9ROty3eZNsO8quFKXuGtuYKqeZsEeW0PnOOvJHbBLQTX+WjZ5Q==
X-Received: by 2002:a63:b48:: with SMTP id a8mr12918612pgl.169.1625631866625;  Tue, 06 Jul 2021 21:24:26 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id o20sm20268303pgv.80.2021.07.06.21.24.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 21:24:25 -0700 (PDT)
To: "Joel M. Halpern" , Peter Saint-Andre , rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>  
From: Brian E Carpenter 
Message-ID: <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com>
Date: Wed, 7 Jul 2021 16:24:21 +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: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 04:24:31 -0000

On 07-Jul-21 12:17, Joel M. Halpern wrote:
> In line...
> Yours,
> Joel
>=20
> On 7/6/2021 7:58 PM, Peter Saint-Andre wrote:
>> On 7/6/21 4:48 PM, Joel M. Halpern wrote:
>>> Fair question.=C2=A0=C2=A0 My concern with appealeing the chairs to t=
he appointing
>>> body is several-fold.
>>>
>>> First, the appointing bodies ONLY recourse is to fire the chairs.=C2=A0=20
I
>>> would hope for an appeals process that had soem resolution short of t=
hat.
>>
>> It's not clear to me that the only recourse is to fire the chairs. The=

>> appointing bodies could certainly consult, advise, admonish, express
>> serious concerns, etc.
> Hmmm.  Really?  The IESG or the IAB getting into giving advice and=20

> opinions on how the RSWG works seems to be an involvement we have been =

> avoiding.  

True. But in any case, firing them is the ultimate sanction (just as a
recall in the IETF process is the ultimate sanction). As long as we have
firing as an option, "advise, admonish, express serious concerns" will
happen anyway, behind the scenes if not in public. I don't think we need
to write that down, because it would just happen if things went wrong.

   Brian

>=20
>>
>>> Second is the matter of involvement.=C2=A0 It is not just a matter of=20
"too
>>> busy" although that is relevant.=C2=A0 The RSAB members will have bee=
n
>>> involved in the RSWG and will understand the context of the discussio=
n.
>>
>> Given that the appointing bodies for the RSWG chairs each have a
>> representative on the RSAB, one hopes that those representatives will =
be
>> paying attention and can brief the rest of the body.
> Then we might as well take the appeal to the RSAB, if it is those =

> members who are going to drive the conversation anyway.
>>
>> Peter
>>
>=20


From nobody Tue Jul  6 21:59:27 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BE63A1399 for ; Tue,  6 Jul 2021 21:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level: 
X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 nDlI7dHAactL for ; Tue,  6 Jul 2021 21:59:20 -0700 (PDT)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 55B8F3A1391 for ; Tue,  6 Jul 2021 21:59:20 -0700 (PDT)
Received: by mail-qv1-xf2f.google.com with SMTP id g15so460269qvi.13 for ; Tue, 06 Jul 2021 21:59:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=JzAD2ddmDdbe6OF4tCjwuWD1HvwNY4ymTUqJts+7mFQ=; b=yxT4J/CHxEPsuau+ycLAloD0gvEQnO0W59gEHx4NYMGErgmG8CM35R3dGDVnWFiciy tsJsP6zt6efN8HUqVFXKgdU8LwMmV8AW2C6w4Kjl23o5TiM/H7SRv+/FiIkYI3q7zsN5 vpgBorgDnKO2VZ6dYYUQOsjoxCMw2Ra26QvqVa7p+iBct/N40Pihb4lbBhuX8X2c0dJX njtJWGd1AywT4KdyitcwNSag68Oa7fk8C7CV5ujur24on9lamLobkdwdCyAxl43i8U/l TW8GOFtAq985nPjF17Q8ov6W5hQcKnA7fMgdk5DC8CyVcMXZOkDXG18umRi2QbkK6YYq dZIQ==
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; bh=JzAD2ddmDdbe6OF4tCjwuWD1HvwNY4ymTUqJts+7mFQ=; b=IU5z9bidLR/GV9fZRD1Ln9udtgZ8COOP0kVg2dqizkVQGKwh4x9n1dmoBYMv9QIhKQ RVDxzMOTrJUB27N0K/F/dOvdT053VSEKGF5OWJi6XyJhTmJGYytSDIuxSM3pcp7hynWW 7YbDX5PfeVJb9rOJF/APnYPBr4bBqBaC6Fa+8dg1fmVBUUJxTgESYp/Zw0Er8KHDfxCf DN0+oCtQYE/uQziHwVoCoxhzbFCeCH483HQSafOekgDMsc7v7UIGkPPvphFr4LQC0Mke jzKr7fOgsTjXEge7Fu3QF3PEz+qbBM76uw+6lOyXWFCTcc/lx5inYCYYy7wEmxzM1yvh m1iA==
X-Gm-Message-State: AOAM531XnHndXIz0LDuUxogsZzOAznNVTG60shMYqu2s3OrXhg7lgH3E lThTUUs5IVRRnjSoy9DOa/lOdUBvgrifTsX+ce0=
X-Google-Smtp-Source: ABdhPJwLSIVAlZLtAST72Fm9Hzymo8ICtu1bQk4jZib3pHD6o4g7igbwkJwjXf9/71Ami5M9z8SJKg==
X-Received: by 2002:a0c:eb51:: with SMTP id c17mr15571867qvq.13.1625633957878;  Tue, 06 Jul 2021 21:59:17 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id a190sm7799745qkf.9.2021.07.06.21.59.16 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 21:59:17 -0700 (PDT)
To: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com>
From: Michael StJohns 
Message-ID: <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>
Date: Wed, 7 Jul 2021 00:59:16 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com>
Content-Type: multipart/alternative; boundary="------------DA350FC55EC51AE95A2A90E6"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 04:59:24 -0000

This is a multi-part message in MIME format.
--------------DA350FC55EC51AE95A2A90E6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 7/7/2021 12:24 AM, Brian E Carpenter wrote:
>> Hmmm.  Really?  The IESG or the IAB getting into giving advice and
>> opinions on how the RSWG works seems to be an involvement we have been
>> avoiding.  
> True. But in any case, firing them is the ultimate sanction (just as a
> recall in the IETF process is the ultimate sanction). As long as we have
> firing as an option, "advise, admonish, express serious concerns" will
> happen anyway, behind the scenes if not in public. I don't think we need
> to write that down, because it would just happen if things went wrong.
>
>     Brian
>

The question to which I keep returning:   To whom is the RSWG 
accountable too if not the RSAB?    It's certainly not accountable to 
the community, even though it's made up of various permutations (over 
time) of the members of the community.  About all the community could do 
with a broken WG is to rerun the process we're currently doing and 
restructure yet again.  That seems both like overkill and a bad model.

The WG chairs can be replaced, but there is no equivalent recourse for 
participants proposing and approving harmful proposals or for that 
matter sitting on their hands and not proposing and creating necessary 
documents.   And now it sounds like EKR et al (sorry to single you out, 
but yours is the most recent push against RSAB checks and balances) are 
looking for a model where the RSAB can only push back on processes and 
not bad documents or ideas. Or not even that with the proposal to 
eliminate appeals from RSWG actions.

I know who all of the RSAB members will be - not the individuals, but 
their chains of authority and responsibility stemming from their 
positions and from their organizations.  I'm less sure of the RSWG 
chairs.   The rest of the crowd has no agreed upon individual 
responsibilities, but gets ultimate authority?  This model seems to be 
moving to less and less of a good balance of authority and 
responsibility the further we go.

Later, Mike




--------------DA350FC55EC51AE95A2A90E6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 7/7/2021 12:24 AM, Brian E Carpenter
      wrote:

    

    

      

        
<jmh>Hmmm.  Really?  The IESG or the IAB getting into giving advice and 


      

      

        
opinions on how the RSWG works seems to be an involvement we have been 
avoiding.  </jmh>


      

      
True. But in any case, firing them is the ultimate sanction (just as a
recall in the IETF process is the ultimate sanction). As long as we have
firing as an option, "advise, admonish, express serious concerns" will
happen anyway, behind the scenes if not in public. I don't think we need
to write that down, because it would just happen if things went wrong.

   Brian



    

    


    

    
The question to which I keep returning:   To whom is the RSWG
      accountable too if not the RSAB?    It's certainly not accountable
      to the community, even though it's made up of various permutations
      (over time) of the members of the community.  About all the
      community could do with a broken WG is to rerun the process we're
      currently doing and restructure yet again.  That seems both like
      overkill and a bad model.

    

    
The WG chairs can be replaced, but there is no equivalent
      recourse for participants proposing and approving harmful
      proposals or for that matter sitting on their hands and not
      proposing and creating necessary documents.   And now it sounds
      like EKR et al (sorry to single you out, but yours is the most
      recent push against RSAB checks and balances) are looking for a
      model where the RSAB can only push back on processes and not bad
      documents or ideas. Or not even that with the proposal to
      eliminate appeals from RSWG actions.

    

    
I know who all of the RSAB members will be - not the individuals,
      but their chains of authority and responsibility stemming from
      their positions and from their organizations.  I'm less sure of
      the RSWG chairs.   The rest of the crowd has no agreed upon
      individual responsibilities, but gets ultimate authority?  This
      model seems to be moving to less and less of a good balance of
      authority and responsibility the further we go.

    
Later, Mike

    


    

    


    

  


--------------DA350FC55EC51AE95A2A90E6--


From nobody Wed Jul  7 00:24:31 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048603A1059 for ; Wed,  7 Jul 2021 00:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.239
X-Spam-Level: 
X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=itaoyama.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 I7IKPrW8vhen for ; Wed,  7 Jul 2021 00:24:25 -0700 (PDT)
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410105.outbound.protection.outlook.com [40.107.141.105]) (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 E40BE3A104F for ; Wed,  7 Jul 2021 00:24:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T5+YnuH0umrNF+xkykdyDoWoQw5MV/p1/giUOODSOStH3FEHtqhE2q6JD+T6iP1Fl0DqCQyfwskcqGppb28jShRjdD34eJ5NtosNzIh0u+6A5A1+RbrPmjjTz2XJIOSQa7kopA9vjUuOSVxaUnTMYpRT5+x73R5glA+jf0QQJ4PIlcuCF5yoLT1G52lGS3BZ6hFGtRdS/5QKs03+Xpv+XuX+Ku6ZV1+INJGpH4aTlfSX2zWPQdA2GuxAp5x3H6BByh7RnAkI2YPdhuX7jb4qJebXPPWQsXxiXtKgGn3e0VLQ6e6RpigDMDvCBRGelx5+8N9xzGPGdTmxCeKvra/hzA==
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=RsrBKUMLezF/mg6MV6t4o6TszenDAPNvt24m2jkuxFU=; b=KbVK3vdpSoBs4lopyg0bdaJ7DvtBKGdA6jyRB77tC/kMZleH82NdqW8QH59aC5yryMsAv5uJnic6JALLzHVpiNhtTg2If6jYu4jyLrpCoHss6bmzvSXfUwYNFTRlJC3zzBaL5nm59XQnLeddBkCRrYYeXLdStIY4wXZh/KzPHk69GhAxmd/Idk4HDvy0IxR7wG3XfOZlMnlurJAy8uOa9UE7dE8x2Y/6KkwgZJAZAx/0hLF6rkptepx0sugzlZkS/WubMMHH++yUh+TUtbogsrssATO4k+uxCamLR4qesR/w8WeTEuTzeAxeLNtEEQM9roNN/tixk6SVKZaSUkao2w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RsrBKUMLezF/mg6MV6t4o6TszenDAPNvt24m2jkuxFU=; b=vtqyAh6yzkowCt91EN42TswZhkbAhhrZUuxZFfOlERAx5mhH5/Nw/Zk6gvtuvX4Tkbar9Jh8pHp4fFoHMYq0gdalW/QtaVRYJnmOqVNi1m4+vRZlp+OmAGVTle7tQ2BqH1AHax+6WeCwyXhebze946NzVeNnVKdngXgk/Fo+Tq8=
Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp;
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYYPR01MB6894.jpnprd01.prod.outlook.com (2603:1096:400:d1::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.33; Wed, 7 Jul 2021 07:24:21 +0000
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b%6]) with mapi id 15.20.4287.033; Wed, 7 Jul 2021 07:24:21 +0000
To: Michael StJohns , rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>
From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: <598c725e-34f7-2314-f0d6-d8eb76266048@it.aoyama.ac.jp>
Date: Wed, 7 Jul 2021 16:24:19 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
In-Reply-To: <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: TYXPR01CA0051.jpnprd01.prod.outlook.com (2603:1096:403:a::21) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [133.2.210.39] (133.2.210.39) by TYXPR01CA0051.jpnprd01.prod.outlook.com (2603:1096:403:a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20 via Frontend Transport; Wed, 7 Jul 2021 07:24:21 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 51a27862-8c72-4e5f-b6f5-08d941183d38
X-MS-TrafficTypeDiagnostic: TYYPR01MB6894:
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: 7ElvH3STKv6boaKYhuP2RNIOXL1Ap2Cuiu1FnZUlYm/gJOLi60qfUdQZT8C+iAKqPXKctc0ADUr1ZdeIbW+zIHJrWbS9cuZ5EltKc01jVeDFI5H+7nj1yabMOAbhb3bsFMZArb4xg4cgvkUg00MQxwciI7PjYdAjbzi5x4wpY7zE694WE48gM4CFs8E/q9Ge6bIqvC9wSfL1hjxwDlYiLaV5oWP9oaEW8YLW0hGxQ4NntChWNTd6bVcaZjHiQj+WNLVloBVXvdSxRZe2H15cit/xkitjB9uodS7wPF6a7MoTBPqxPEagxRGdlGz0aV4XbuH+p/qs1auVac04KbCbrYHvsqckOD8yoSEXVQGS0NldOCVkm2l6JrC9R0S4WpuLuS30Qoswv3cLXB9tFFSYwXZQwCCrU2aCegvaFLYCFLIxsrcP8T9s6JLyiZmpkyeB4swko/NhTTQxE0TKODNUbGE/gfhLloDHCteG75c/9aG3kUJIIAh1DMvIVbPT/5JOpNaqq6An6V8f3ta/YBTox6uCAVOo39fLcQOxzx2Tf5pHvMHE9h+mwtUDDA8y+1ZbfAowSIQ04O8fve1WnbSjdI7R/QVHxKmamdtgn9Rncx61ZArZcnNLrwjS10xffOcAaHDfg3kk6sAAkWofS+XCubQVYvItXj0Ss7FhFFoexh/TIY5huyt0+ncx86m9wp887jU/NqSE+o1TzUWffyhAThY/YrQN5163BU2Ebdq3Zpim4ZJ7We50A5BBc9zQVCwQ6zE+P1q+gRnNcZZ7xI4oUCVXH85FrQBeS8oZySU/xjg=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE;  SFS:(396003)(346002)(39840400004)(376002)(136003)(366004)(6486002)(38100700002)(53546011)(36916002)(66946007)(2906002)(8936002)(956004)(31696002)(38350700002)(6706004)(31686004)(86362001)(52116002)(26005)(8676002)(478600001)(83380400001)(786003)(316002)(2616005)(5660300002)(186003)(16576012)(66476007)(66556008)(3940600001)(43740500002)(45980500001); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q3I0WmxYQ3V6UkhhM1ZITFhzZGorYnFkMU1raTZGQ0w5UWFsdm4zaFFCSHlx?= =?utf-8?B?QTZON2ZEbzVqQ2kxVlVoWHQ2cXR0Z051WHoybHF4R0Q5UnpZanQwVnJxdklP?= =?utf-8?B?ZHRvZ2k1SExVak0wQzRPTndtNlBpTUwvY09ldjl3MlN4L1A3OGtYR1VpOWtr?= =?utf-8?B?SlY1K3BGakVSV3hBMEljL3QzblZzYUVGN2c3R1BGdnBhU2lNcnY3SVBmcllJ?= =?utf-8?B?T2VEVE5Cdm1DNkRsMG5DWFZ3UHg5ektsWnlET0piN3dFOTUxT1htTlR3WXpy?= =?utf-8?B?MXZMZVh4UCtNMnpOaEVlZ3FaN3E2a3l2SDBpZnJUWERiZ0JkUzJiWk9wNzZw?= =?utf-8?B?OW9lWmFBTFFFcC9TZ0hoRlhGNktoRU4zSCtjWTFaaUtWS2t3WmJhbTJPMXow?= =?utf-8?B?cnJrWXBHc2xwZ1JpV0RkeDZkdFlBbUJhempjMHVWcDFXYU1XQnJxbjgzT0Fu?= =?utf-8?B?MEg1VjhKazRCVTErSHo3T2tRMkFLMnZXaWVrczg3ZnV1UlI0WmJQNkxCQ2Zk?= =?utf-8?B?cjY5U0YwMDBHMXJXUGxTcmhrc3dtTHNaNU1YUkwrT21xeEkvQ0cvb2NWSHUz?= =?utf-8?B?MHFncXIyL0pJbzlPKzQyRGEwT1JZcVUyQ1VvSFJLYmdIdUcxUVVGQ2ttbGhX?= =?utf-8?B?ZmpzVkEwaEFJUit5TVc5dC9mUmt3cGRhNlR5RUgzZlU0RVdhZklXV0U5eVVU?= =?utf-8?B?T1BHbXg1OEFKbzBYbHNVKzkvNnpFcGFLTTFxM1FiaS9qMXFmVlFqcVJlcmZN?= =?utf-8?B?SXBZQ0k4V2ZHdzRYeWdENVVtNlo2azFNRjY1ODlmaEFBTzJKVmtuY1dpaXJy?= =?utf-8?B?RDkyL0QxVzlJY1VxczVSOTBpWE1KdG81QXlEc0M1UEVvVTJMT3RERitSQzdB?= =?utf-8?B?c1RNbWc0Y283a0lpVFJTSmozOVNZNEdnQ0dCZE4rOXVtYkJPYUpFbWl0K3E2?= =?utf-8?B?b2xMbCtxbyt4WDRMZ0J3TklvYUtGTVBRUWNRUFJMbWJPRHFRRHZHK3ZhS0Za?= =?utf-8?B?dFlrektBN1d1czhsNG9sR2RUZGJZSVFoWlloZFFZeGxKNFBtS3BnbXV4bTB6?= =?utf-8?B?cWdPdGFTbHRpV3B0NW9NOGhmNUlPUWwvMU5XOE4xN1JvUW4wMkNMdmcyYjhU?= =?utf-8?B?NXFyYTVlM0E2UUttWFMraHNlTi8yMS9EeDZsL2RqeUdPK25wME5OYVlWTzJZ?= =?utf-8?B?QitOSmdveWVQRjRNWnF0NU1zbVMyV3JNZ2EwS1lTQ0NBZi9EZjdXaWdTWEtq?= =?utf-8?B?aVRLeG15Mm9WbndldWdIenRuRkF1eC8vb2tWdFlJYkU1K2dLMG1FczB0Q3Nw?= =?utf-8?B?UDVPUzVET3RlYy82YWE1QlhXdUMrc0NPbGZEWkJvV2dIWHBnTWg1RnhOMldw?= =?utf-8?B?RmF3ancxcUJBcENMbW9zcVJONGNqWlc1ZDM4aG1CNDhqS3RvOWlQSVRTRkl1?= =?utf-8?B?bUZVbXBUeTViTS9iMm8yQWxUNFRPaGUwVWdqTHMzd1VISW9ZdkVvUGl4N1pX?= =?utf-8?B?K0NLOTZ0ODBSTzdOMFRtVHo5YkNpSUsrQmFDRnp0UUhQRVJpbVIyRVlhaGEv?= =?utf-8?B?YlpwaW9PQTJTb0dXTUhlTmdrcEU5OXYrMGxIczQ5emJvZzhoMldnbEU2UFFZ?= =?utf-8?B?akFJWDc5ZFFjWTFLa2lWczhYTHNaWS84cFJEZDZPb1ErSmoxSk1xTHdYdU5S?= =?utf-8?B?N2pGcWliM2I3MkpsTVU0elZsY2llVEFlakdnVkVpNVd2Z1NGZUMzelU0QVJU?= =?utf-8?Q?sVH1i2cO9ZUUE9kzAIuorbh8uhWN++AcAQ++odK?=
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 51a27862-8c72-4e5f-b6f5-08d941183d38
X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2021 07:24:21.4591 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: yMG35w7yF11LUvQDAjZUJKaY8ihnGxC5TPwGRCNYlwZrc4+b2DWYoRvOzTMq6SzzVv0vE2vlk+RL9pkXKrKzlQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYPR01MB6894
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 07:24:30 -0000

On 2021-07-07 13:59, Michael StJohns wrote:

> The question to which I keep returning:   To whom is the RSWG 
> accountable too if not the RSAB?    It's certainly not accountable to 
> the community, even though it's made up of various permutations (over 
> time) of the members of the community.  About all the community could do 
> with a broken WG is to rerun the process we're currently doing and 
> restructure yet again.  That seems both like overkill and a bad model.

If the community realizes that the overall structure is broken, that's 
what would have to be done, but see below.


> The WG chairs can be replaced, but there is no equivalent recourse for 
> participants proposing and approving harmful proposals or for that 
> matter sitting on their hands and not proposing and creating necessary 
> documents.

Let's first look at people sitting on their hands. That happens with a 
lot of stuff in a lot of IETF WGs, too. It's solved either by realizing 
that the 'necessary' stuff may not be that necessary, or by others 
coming in and doing the work if it's important enough for them.

As for approving harmful proposals, something similar applies. If 
there's a small group of people trying to push something harmful 
through, it's just up to others to come in and say no. That also has 
worked in many IETF WGs (not in all, I guess, and in many cases without 
many people realizing it).

Regards,   Martin.


> And now it sounds like EKR et al (sorry to single you out, 
> but yours is the most recent push against RSAB checks and balances) are 
> looking for a model where the RSAB can only push back on processes and 
> not bad documents or ideas. Or not even that with the proposal to 
> eliminate appeals from RSWG actions.
> 
> I know who all of the RSAB members will be - not the individuals, but 
> their chains of authority and responsibility stemming from their 
> positions and from their organizations.  I'm less sure of the RSWG 
> chairs.   The rest of the crowd has no agreed upon individual 
> responsibilities, but gets ultimate authority?  This model seems to be 
> moving to less and less of a good balance of authority and 
> responsibility the further we go.
> 
> Later, Mike
> 


From nobody Wed Jul  7 09:58:36 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04353A1EFA for ; Wed,  7 Jul 2021 09:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1JPrf9u6Kvm for ; Wed,  7 Jul 2021 09:58:29 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 44FFA3A1EF5 for ; Wed,  7 Jul 2021 09:58:29 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1001::440] ([IPv6:2001:420:c0c0:1001:0:0:0:440]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 167GwP2L103144 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 7 Jul 2021 18:58:26 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625677106; bh=FIKWMInBF17SF5VKmjbk7SUZ3H+TfgOcv6E46R/yKP8=; h=Subject:From:To:References:Cc:Date:In-Reply-To:From; b=KDMhKnSuqC7YJ87IVXdkC8FAIa1BFgNJymEUCNLelNLXDppPO1ex9CUNk4S9b8lg1 swgHF6lwbQa0k14Wo7mTXQ75L0z8wehSfamkbf9Lp+XIBH5HylmLtlGC4NrgWgMBhQ 5VpL6QTK+K5xOthLR0paqAA1N0hbWlqbXRcNkT2A=
From: Eliot Lear 
To: rfced-future@iab.org
References: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch>
Cc: =?UTF-8?Q?Mirja_K=c3=bchlewind?= 
Message-ID: <385e1dad-aaad-6adc-f058-73e67d56cd1b@lear.ch>
Date: Wed, 7 Jul 2021 18:58:14 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CPKYaEPCmbayVzPBq1sRRDMgDZI41lhDn"
Archived-At: 
Subject: Re: [Rfced-future] Call for Adoption: draft-saintandre-rfced-model-01
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 16:58:35 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--CPKYaEPCmbayVzPBq1sRRDMgDZI41lhDn
Content-Type: multipart/mixed; boundary="eCTSagmDvOqIIDs9dtd4TiUaeWgA1y8ql";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Cc: =?UTF-8?Q?Mirja_K=c3=bchlewind?= 
Message-ID: <385e1dad-aaad-6adc-f058-73e67d56cd1b@lear.ch>
Subject: Re: Call for Adoption: draft-saintandre-rfced-model-01
References: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch>
In-Reply-To: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch>

--eCTSagmDvOqIIDs9dtd4TiUaeWgA1y8ql
Content-Type: multipart/alternative;
 boundary="------------46D08115718EA9FC6DBA3456"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------46D08115718EA9FC6DBA3456
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi everyone,

Thank you for your emails.=C2=A0 There were no objections to adopting thi=
s as=20
a WG draft.=C2=A0 The chairs will ask Peter to post and Mirja to approve =

draft-iab-rfcefdp-rfced-model-00.

Eliot

On 22.06.21 18:02, Eliot Lear wrote:
>
> Dear Colleagues,
>
> As discussed in the May interim, we are now issuing a Call for=20
> Adoption of draft-saintandre-rfced-model-01 as the draft this group=20
> will use as intended output. =C2=A0We hope that this call is a mere=20
> formality. =C2=A0Our procedures for content going into that draft and=20
> issues raised do not change. =C2=A0The purpose of adoption is to make c=
lear=20
> our group=E2=80=99s ownership of its content and intent to pursue that =
work as=20
> WG output, with the very generous and kind help of Peter.
>
> Please raise any concerns by 6 July 2021.
>
> Eliot
>
>

--------------46D08115718EA9FC6DBA3456
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi everyone,

    
Thank you for your emails.=C2=A0 There were no objections to adopt=
ing
      this as a WG draft.=C2=A0 The chairs will ask Peter to post and Mir=
ja
      to approve draft-iab-rfcefdp-rfced-model-00.

    
Eliot

    

    
On 22.06.21 18:02, Eliot Lear wrote:
    

    

      
      
Dear Colleagues,

        

        As discussed in the
          May interim, we are now issuing a Call for Adoption of
          draft-saintandre-rfced-model-01 as the draft this group will
          use as intended output. =C2=A0We hope that this call is a mere
          formality. =C2=A0Our procedures for content going into that dra=
ft
          and issues raised do not change. =C2=A0The purpose of adoption =
is
          to make clear our group=E2=80=99s ownership of its content and =
intent
          to pursue that work as WG output, with the very generous and
          kind help of Peter.

        

        Please raise any
          concerns by 6 July 2021.

      
Eliot

        

      

      

    

  


--------------46D08115718EA9FC6DBA3456--

--eCTSagmDvOqIIDs9dtd4TiUaeWgA1y8ql--

--CPKYaEPCmbayVzPBq1sRRDMgDZI41lhDn
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDl3SYFAwAAAAAACgkQh7ZrRtnSejN+
0AgA1DfwkZ5T/1TxWMITZXUD7vcjml2D+3G0WorOZTUMiDe4LuIalzfO6b+sGU4aZSNRdIyFysEX
Kfo3V7m9CinCZo3S2U1xSI7noGcYzGfSwpxuXflrJL1cZTvGLd9k++BH9hrZ1LaHhD9/oM1OXsrM
PuqzfbKPb+lHBiD18ZMmFCtUhgC2/ypJ0uTV17YwhlP7n3GqJsvpdGy+siiicoldAy0x52tuxkJO
IdwYhLxTJdYVVXyJGQByGSf4SU6dL0L4N1dTtP/712Tz7UoKgLrI7A2zjiYRe/A/Hdiy4V3uxXcf
X2xEy4wZ+UGXGp0RU9lifGgzdf+tAJHYhYbfUB5iYA==
=20xw
-----END PGP SIGNATURE-----

--CPKYaEPCmbayVzPBq1sRRDMgDZI41lhDn--


From nobody Wed Jul  7 10:02:06 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0003A1F17 for ; Wed,  7 Jul 2021 10:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WdLKLu6Iluv for ; Wed,  7 Jul 2021 10:01:59 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 29E853A1F15 for ; Wed,  7 Jul 2021 10:01:58 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1001::440] ([IPv6:2001:420:c0c0:1001:0:0:0:440]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 167H1tcl103195 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 7 Jul 2021 19:01:56 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625677316; bh=8QlSVxIbGjxm0tXyjBjhbfuAPj8ytmh4ZPx0ejT+//w=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=XuMF3yrgdGo151zavPcIGS1MZuk4xAswyKX79PPnAjJaMMd+pxbPPeE6gknZYErDH BsQbprXS7fbt4Gby03dN/yDZ637zjM21alht+xZaGkari0Pws4MVrmR4MhAwPcZtIT O3A5F4WGA+AHb8eBFiZ+uMfVy6arySRfTa73witk=
From: Eliot Lear 
To: rfced-future@iab.org
Cc: EKR 
References: <612bacba-0bdb-32bb-5369-19486742a111@lear.ch>
Message-ID: 
Date: Wed, 7 Jul 2021 19:01:54 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <612bacba-0bdb-32bb-5369-19486742a111@lear.ch>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2BbGYlWcX7X3V3Wtbujo8PqtGWVbMPV6y"
Archived-At: 
Subject: Re: [Rfced-future] Issue 68: we prohibited in person meetings and design teams
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 17:02:04 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2BbGYlWcX7X3V3Wtbujo8PqtGWVbMPV6y
Content-Type: multipart/mixed; boundary="ag3zKoC7iZ11aeUSkeUgJFrQgiDpb4N4p";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Cc: EKR 
Message-ID: 
Subject: Re: Issue 68: we prohibited in person meetings and design teams
References: <612bacba-0bdb-32bb-5369-19486742a111@lear.ch>
In-Reply-To: <612bacba-0bdb-32bb-5369-19486742a111@lear.ch>

--ag3zKoC7iZ11aeUSkeUgJFrQgiDpb4N4p
Content-Type: multipart/alternative;
 boundary="------------3155D869BD1794A0634F0C6E"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------3155D869BD1794A0634F0C6E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

I have not heard any objections to the following text.=C2=A0 Peter, pleas=
e=20
include in -01 of WG draft.

On 30.06.21 07:55, Eliot Lear wrote:
>
>> When the RSWG is formed, all discussions shall take place on an open=20
>> email discussion list or through in person meetings. Subsequently,=20
>> the RSWG may decide by rough consensus to use working methods(e.g.,=20
>> GitHub as specified in [RFC8874] or design teams) as long as they are =

>> consistent with [RFC2418].
>
> Eliot
>
>
>

--------------3155D869BD1794A0634F0C6E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
I have not heard any objections to the following text.=C2=A0 Peter=
,
      please include in -01 of WG draft.

    

    
On 30.06.21 07:55, Eliot Lear wrote:
    

    


      
When the RSWG is formed, all discussions
        shall take place on an open email discussion list or through in
        person meetings. Subsequently, the RSWG may decide by rough
        consensus to use working methods(e.g., GitHub as specified in
        [RFC8874] or design teams) as long as they are consistent with
        [RFC2418].
        

      

      

      Eliot
      

      

      

      

      

    

  


--------------3155D869BD1794A0634F0C6E--

--ag3zKoC7iZ11aeUSkeUgJFrQgiDpb4N4p--

--2BbGYlWcX7X3V3Wtbujo8PqtGWVbMPV6y
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDl3gIFAwAAAAAACgkQh7ZrRtnSejMw
0AgA0r3lpctBIl1lJvWz2Xbg+Z1SJPQdKQfIatoLZ06nbh6KykKKmhYcadKTDANf6cc05sXlygM1
Xhq1uVYlNpbKm7XuOgko5tFzT4f9eIf30GDkd1H8MB44Bvanq2Ojmxm9Bshm7oKItASQPtb/7uQT
af8vH6B7KK+xW6MiiYXUis/gerhwn4K4O9r3MwwCLbFhh/J7FE/wuJOJRe39sA7RA2e2y5nzhd5U
Ld5srhIy+EDYPRin0DW6q1LvX9qdl/jhvaJZIb5EfU1cw2jO03jgNoeLPlUAnQyVhAiRVObirhY6
VsJ/a7Fy4BQparanhYWNdJ6ANQfTOgxHVp80zFZrEQ==
=eyln
-----END PGP SIGNATURE-----

--2BbGYlWcX7X3V3Wtbujo8PqtGWVbMPV6y--


From nobody Wed Jul  7 10:07:01 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEC03A1F30 for ; Wed,  7 Jul 2021 10:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzpoejHOLdZb for ; Wed,  7 Jul 2021 10:06:55 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 6D91B3A1F2F for ; Wed,  7 Jul 2021 10:06:55 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1001::440] ([IPv6:2001:420:c0c0:1001:0:0:0:440]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 167H6qNu103222 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Wed, 7 Jul 2021 19:06:52 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625677612; bh=+pPJ8qacYCwaiVUR7bJmhEk5xgX/xBM6+45syiNsrSg=; h=Subject:From:To:References:Date:In-Reply-To:From; b=IV1uqSbWjZJJ7EOXGrwcRb52E2BIvYB9jFkuJ2tJs47zAFv2At4YYNLBkRQEbayx5 TlOv3KOYGKb5i/WgoOrXMZXOp8WaTP3WsKXEnX9OIi4ZI809t1m1KVALDLCS+TBwcS 8yBKy03nGYLTrY/r5aQ8kGXoOpdQoCEzPumcr2OI=
From: Eliot Lear 
To: rfced-future@iab.org
References: 
Message-ID: 
Date: Wed, 7 Jul 2021 19:06:51 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pWD4xdzOvD8jJm8tav38Htua5Dr4qibG6"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check- Issue 53: Do new streams necessarily imply new RSAB members?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 17:07:00 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--pWD4xdzOvD8jJm8tav38Htua5Dr4qibG6
Content-Type: multipart/mixed; boundary="XoyQ5TbhCzluccQZhKN2yoz3HRnkTORBN";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Message-ID: 
Subject: Re: Consensus check- Issue 53: Do new streams necessarily imply new
 RSAB members?
References: 
In-Reply-To: 

--XoyQ5TbhCzluccQZhKN2yoz3HRnkTORBN
Content-Type: multipart/alternative;
 boundary="------------E1083D8436A42C7B4C672E1E"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------E1083D8436A42C7B4C672E1E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

There were no comments on this after our meeting, so Peter should=20
include appropriate text in a draft sometime after -00.

On 22.06.21 16:54, Eliot Lear wrote:
>
> General agreement that this matter can be deferred into whatever RFC=20
> defines the stream.=C2=A0 If you have concerns about this approach, ple=
ase=20
> make them known by 6 July.
>
> Eliot
>
>
>

--------------E1083D8436A42C7B4C672E1E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
There were no comments on this after our meeting, so Peter should
      include appropriate text in a draft sometime after -00.

    

    
On 22.06.21 16:54, Eliot Lear wrote:
    

    

      

      General agreement that this matter can be deferred into whatever
      RFC defines the stream.=C2=A0 If you have concerns about this appro=
ach,
      please make them known by 6 July.
      

      

      Eliot
      

      

      

      

      

    

  


--------------E1083D8436A42C7B4C672E1E--

--XoyQ5TbhCzluccQZhKN2yoz3HRnkTORBN--

--pWD4xdzOvD8jJm8tav38Htua5Dr4qibG6
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDl3ysFAwAAAAAACgkQh7ZrRtnSejNc
+gf/TJtmk/N+Xz03HnESqmk2ByZq7eJq/ZT5QeNQVixCFxQ2eJtoFTkkbGZe4qBN1SbZnjLkScQt
qKTJA04VEG5J6+3gXjdTYm7hqeTx0RnrSWBmip/cZEZYtmwifARZWuWaKF0+Un45drRefKZDCyTO
bwdGSJPCLWcvz9M+xFQ4uANInSL5KLSuyZVLJh58+B6qgnF8Y6+Ow3RFWVcnhlUnfCx0iivF5I1m
TssOlkXJ7XwldK5UwIi+MvqNwHO9PFx4Wf9AHn6h+IasMYkLBRjViZYbN5CnkCl+K/oMFO+CtH9o
GRUe8UV/YpFsKaKmrShf27CqJ1j14VT0C3MfbSmh9A==
=8bTN
-----END PGP SIGNATURE-----

--pWD4xdzOvD8jJm8tav38Htua5Dr4qibG6--


From nobody Wed Jul  7 10:09:08 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7063A1F3F for ; Wed,  7 Jul 2021 10:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdCIyxZS_sic for ; Wed,  7 Jul 2021 10:09:02 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 2DA4B3A1F3E for ; Wed,  7 Jul 2021 10:09:01 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1001::440] ([IPv6:2001:420:c0c0:1001:0:0:0:440]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 167H8wuW103245 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 7 Jul 2021 19:08:58 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625677739; bh=LPgBZUr/FyG58kSkDZrvpXGpLIlPEaUvmBQ+4cpGXAg=; h=Subject:From:To:References:Date:In-Reply-To:From; b=om5mU5CA/1hNImKpK2eXP+G3Ele3GFaLkkRhf1bGkWcyRQ9qShGU1N3rQWnGEAnfH Q9D5Sxkx64qwhu7AudfeK/sg91oKFmFX4oWXUlW67Gj1lcn688WrddVSrQXi9SD6UY Cu9SFK2Sr4QsCbnwuAPwgQouWMhDFxlScgz9pBnc=
From: Eliot Lear 
To: Peter Saint-Andre , rfced-future@iab.org
References: <6ed31a83-d686-59c3-ebdf-e914a0167022@lear.ch> <0a6401d7677a$137b07a0$3a7116e0$@olddog.co.uk>  
Message-ID: 
Date: Wed, 7 Jul 2021 19:08:57 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8lXFoIGkd6E6bDiCCzxCZ6o371BHr9ktY"
Archived-At: 
Subject: Re: [Rfced-future] Consensus Check - Issue 20: Decider for hiring RSE/A
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 17:09:07 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--8lXFoIGkd6E6bDiCCzxCZ6o371BHr9ktY
Content-Type: multipart/mixed; boundary="BelbY3Vt4vuZP2iNlU5WnFbmHl9FA6lec";
 protected-headers="v1"
From: Eliot Lear 
To: Peter Saint-Andre , rfced-future@iab.org
Message-ID: 
Subject: Re: [Rfced-future] Consensus Check - Issue 20: Decider for hiring
 RSE/A
References: <6ed31a83-d686-59c3-ebdf-e914a0167022@lear.ch>
 <0a6401d7677a$137b07a0$3a7116e0$@olddog.co.uk>
 
 
In-Reply-To: 

--BelbY3Vt4vuZP2iNlU5WnFbmHl9FA6lec
Content-Type: multipart/alternative;
 boundary="------------E72E1AC798DCDBB2397665C2"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------E72E1AC798DCDBB2397665C2
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

I think rough consensus is that people prefer Option 1 below. However,=20
to confirm, we can leave this issue open just a little longer.

On 28.06.21 12:38, Eliot Lear wrote:
> Could people please share their views?
>
> On 25.06.21 21:00, Peter Saint-Andre wrote:
>> Proposed text #1 (high level)
>>
>> =C2=A0=C2=A0 The RSEA will be selected by a search committee formed by=
 the
>> =C2=A0=C2=A0 Executive Director of the IETF LLC, taking into account t=
he role
>> =C2=A0=C2=A0 definition [13] as well as other information that the com=
mittee
>> =C2=A0=C2=A0 deems necessary or helpful in making its decision.
>>
>> Proposed text #2 (detailed)
>>
>> =C2=A0=C2=A0 The RSEA will be selected by a search committee formed by=
 the
>> =C2=A0=C2=A0 Executive Director of the IETF LLC.=C2=A0 To the extent p=
ossible, the
>> =C2=A0=C2=A0 committee will follow best practices for an executive sea=
rch.=C2=A0 The
>> =C2=A0=C2=A0 committee should take into account the role definition [1=
3] as well
>> =C2=A0=C2=A0 as other information that the committee deems necessary o=
r helpful in
>> =C2=A0=C2=A0 making its decision, such as an organizational competency=
 model,
>> =C2=A0=C2=A0 consultations with relevant stakeholders (e.g., stream ma=
nagers),
>> =C2=A0=C2=A0 formal assessments, and structured interviews.
>
>

--------------E72E1AC798DCDBB2397665C2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
I think rough consensus is that people prefer Option 1 below.=C2=A0=

      However, to confirm, we can leave this issue open just a little
      longer.

    

    
On 28.06.21 12:38, Eliot Lear wrote:
    

    
Could
      people please share their views?
      

      

      On 25.06.21 21:00, Peter Saint-Andre wrote:
      

      
Proposed text #1 (high level)
        

        

        =C2=A0=C2=A0 The RSEA will be selected by a search committee form=
ed by the
        

        =C2=A0=C2=A0 Executive Director of the IETF LLC, taking into acco=
unt the
        role
        

        =C2=A0=C2=A0 definition [13] as well as other information that th=
e
        committee
        

        =C2=A0=C2=A0 deems necessary or helpful in making its decision.
        

        

        Proposed text #2 (detailed)
        

        

        =C2=A0=C2=A0 The RSEA will be selected by a search committee form=
ed by the
        

        =C2=A0=C2=A0 Executive Director of the IETF LLC.=C2=A0 To the ext=
ent possible,
        the
        

        =C2=A0=C2=A0 committee will follow best practices for an executiv=
e
        search.=C2=A0 The
        

        =C2=A0=C2=A0 committee should take into account the role definiti=
on [13]
        as well
        

        =C2=A0=C2=A0 as other information that the committee deems necess=
ary or
        helpful in
        

        =C2=A0=C2=A0 making its decision, such as an organizational compe=
tency
        model,
        

        =C2=A0=C2=A0 consultations with relevant stakeholders (e.g., stre=
am
        managers),
        

        =C2=A0=C2=A0 formal assessments, and structured interviews.
        

      

      

      

      

    

  


--------------E72E1AC798DCDBB2397665C2--

--BelbY3Vt4vuZP2iNlU5WnFbmHl9FA6lec--

--8lXFoIGkd6E6bDiCCzxCZ6o371BHr9ktY
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDl36kFAwAAAAAACgkQh7ZrRtnSejOU
QggAqqsoKqZNN/p+WCxE0SpOFQPLEj/mKmiAJYi6Xpc1EekbGahqp50UnZ1uEZCV7eAgC1Wcbi9e
7QdHu1Rboh667Gk8HGMVw3mZMWw4lJK2Tv5vWSPWDmjdLICgt7nsit/6iO/jD+Nl1JRWeGDjKDvM
xVNLSj1bXrz6jbvbIYDemYsz8WC/FyFNJ5SFVbIO6gGUjooA1JKdxzCiNi4dODfbdCLL5NwSBdx5
GID1/JBeInsdz5ZuU70bEQzhxzzOVh3dkLNJkNVZ4xvVJXMChnkban58HwJzKk+j8aKDTxoNDNbn
hZs1TaO6SwXxZOBC39CQHQmH2mT5oV0dn6tCx2mW1A==
=Kcg0
-----END PGP SIGNATURE-----

--8lXFoIGkd6E6bDiCCzxCZ6o371BHr9ktY--


From nobody Wed Jul  7 10:29:16 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED02C3A1FC0 for ; Wed,  7 Jul 2021 10:29:14 -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 lhW4Tgo5Mzfg for ; Wed,  7 Jul 2021 10:29:10 -0700 (PDT)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0253A1FC6 for ; Wed,  7 Jul 2021 10:29:10 -0700 (PDT)
Received: by mail-il1-x12e.google.com with SMTP id j12so3673260ils.5 for ; Wed, 07 Jul 2021 10:29:10 -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=Qlk7rVmgCuL7r/j5hYsNEqOJ6vS3i/ueOVLnSNjr9dQ=; b=ogCId7UVqXk5fBHOWO+TfWJWKdbhv5fu0swRxOK9O0UgH7y7fMWGcrbLeLhV8mS5c2 jqC3BxmPzKzskTJMuxYFzEqX6C86DBdjGjRt4wWREfTnG2axEdd9Hc3z0YmI68rjOVeM UjeGwDRnmOAZ+KScgbJxPc+egEOQblYymAn2JceRqiPEISwV7K3y1hl3HluqV5uHUykF WDQ/ggbdIzOmc7CtszwtjQ7QkD608w9dPtPWsYI2bbDomKagkr0bMhODQY/nh6PiKbU4 DYud3Xzy1g6rLC4i8MqJEWbD2zWQsFlrkWF1O/qZfGCYm6VsGbyjEaLDc7KrfWhjbw6d yCbw==
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=Qlk7rVmgCuL7r/j5hYsNEqOJ6vS3i/ueOVLnSNjr9dQ=; b=rJY6ormXLyTVkMA0vLdX0Q6J4ss2yNaLgTlj5OSOddWbQyC36v4VmrAipy1qph/qg2 KH38+Mdp855yrVc52HJhCeY1ZiaqlQmCREPvKExlXLkSaH7mUqUiw7Pgc9qzqin62gmo sf5ZwzpZzMDeAhNHhnBEjqYUrjMUBkV1O3XmOmau5TfMbUtnqg1GnD/0Fb+iLPmZOgSm 5rUKE00dh3+ygpwACMjUnNETzvVjxf6/+UHy6o6JivzLiEgoj65ejIwRwJrhwSOmGP97 fRduu0Aly6AtdgTnnhbbFOZQpUNh9dTXaZ1WMwFVBAoTtHCdX+hrwWdnxdWF1m6TmlJ2 /CnQ==
X-Gm-Message-State: AOAM5324mWPms7Mxd59BPbl4u81RioTPvua6ixITzsdzSBV2Ajm2HZBM q0P5xAjCRQzTBGNmFYdVZyO7EPhGiB3VuNm+PurGbg==
X-Google-Smtp-Source: ABdhPJySRl/FJi0jlUemAqCSQSS42YMRMpHuVl3bOTwQp1tdgPDkfO32+P6yXgXCJXWZKpVAV9KhLdopqUWj1MomHsU=
X-Received: by 2002:a92:9509:: with SMTP id y9mr19424475ilh.18.1625678948703;  Wed, 07 Jul 2021 10:29:08 -0700 (PDT)
MIME-Version: 1.0
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>
In-Reply-To: <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>
From: Eric Rescorla 
Date: Wed, 7 Jul 2021 10:28:32 -0700
Message-ID: 
To: Michael StJohns 
Cc: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="00000000000041b74305c68be0c7"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 17:29:15 -0000

--00000000000041b74305c68be0c7
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 6, 2021 at 9:59 PM Michael StJohns 
wrote:

> On 7/7/2021 12:24 AM, Brian E Carpenter wrote:
>
> Hmmm.  Really?  The IESG or the IAB getting into giving advice and
>
> opinions on how the RSWG works seems to be an involvement we have been
> avoiding.  
>
> True. But in any case, firing them is the ultimate sanction (just as a
> recall in the IETF process is the ultimate sanction). As long as we have
> firing as an option, "advise, admonish, express serious concerns" will
> happen anyway, behind the scenes if not in public. I don't think we need
> to write that down, because it would just happen if things went wrong.
>
>    Brian
>
>
>
> The question to which I keep returning:   To whom is the RSWG accountable
> too if not the RSAB?    It's certainly not accountable to the community,
> even though it's made up of various permutations (over time) of the members
> of the community.  About all the community could do with a broken WG is to
> rerun the process we're currently doing and restructure yet again.  That
> seems both like overkill and a bad model.
>
Well, I do think that it's *accountable* to the community but needs the
consent of the RSAB.

The WG chairs can be replaced, but there is no equivalent recourse for
> participants proposing and approving harmful proposals or for that matter
> sitting on their hands and not proposing and creating necessary
> documents.   And now it sounds like EKR et al (sorry to single you out, but
> yours is the most recent push against RSAB checks and balances) are looking
> for a model where the RSAB can only push back on processes and not bad
> documents or ideas. Or not even that with the proposal to eliminate appeals
> from RSWG actions.
>
I just want to clarify that I am not arguing that that the RSAB should not
be able to push back on bad documents or ideas. What I'm saying is that the
RSAB should not be able to force the WG to advance ideas it thinks are good
even if the RSWG does not.

-Ekr


I know who all of the RSAB members will be - not the individuals, but their
> chains of authority and responsibility stemming from their positions and
> from their organizations.  I'm less sure of the RSWG chairs.   The rest of
> the crowd has no agreed upon individual responsibilities, but gets ultimate
> authority?  This model seems to be moving to less and less of a good
> balance of authority and responsibility the further we go.
>
> Later, Mike
>
>
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--00000000000041b74305c68be0c7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Jul 6, 2021 at 9:59 PM Michae=
l StJohns <msj@nthpermutation.=
com> wrote:

 =20
   =20
 =20
  

    
On 7/7/2021 12:24 AM, Brian E Carpenter
      wrote:

    

    

      

        
<jmh>Hmmm.  Really?  The IESG or the IAB getting into gi=
ving advice and=20


      

      

        
opinions on how the RSWG works seems to be an involvement we h=
ave been=20
avoiding.  </jmh>


      

      
True. But in any case, firing them is the ultimate sanction (jus=
t as a
recall in the IETF process is the ultimate sanction). As long as we have
firing as an option, "advise, admonish, express serious concerns"=
 will
happen anyway, behind the scenes if not in public. I don't think we nee=
d
to write that down, because it would just happen if things went wrong.

   Brian



    

    


    

    
The question to which I keep returning:=C2=A0=C2=A0 To whom is the R=
SWG
      accountable too if not the RSAB?=C2=A0=C2=A0=C2=A0 It's certainly=
 not accountable
      to the community, even though it's made up of various permutation=
s
      (over time) of the members of the community.=C2=A0 About all the
      community could do with a broken WG is to rerun the process we're
      currently doing and restructure yet again.=C2=A0 That seems both like
      overkill and a bad model.
Well, I do t=
hink that it's *accountable* to the community but needs the consent of =
the RSAB.


    

    
The WG chairs can be replaced, but there is no equivalent
      recourse for participants proposing and approving harmful
      proposals or for that matter sitting on their hands and not
      proposing and creating necessary documents.=C2=A0=C2=A0 And now it so=
unds
      like EKR et al (sorry to single you out, but yours is the most
      recent push against RSAB checks and balances) are looking for a
      model where the RSAB can only push back on processes and not bad
      documents or ideas. Or not even that with the proposal to
      eliminate appeals from RSWG actions.
I=
 just want to clarify that I am not arguing that that the RSAB should not b=
e able to push back on bad documents or ideas. What I'm saying is that =
the RSAB should not be able to force the WG to advance ideas it thinks are =
good even if the RSWG does not.

-Ekr


    

    
I know who all of the RSAB members will be - not the individuals,
      but their chains of authority and responsibility stemming from
      their positions and from their organizations.=C2=A0 I'm less sure=
 of
      the RSWG chairs.=C2=A0=C2=A0 The rest of the crowd has no agreed upon
      individual responsibilities, but gets ultimate authority?=C2=A0 This
      model seems to be moving to less and less of a good balance of
      authority and responsibility the further we go.

    
Later, Mike

    


    

    


    

  


-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future




--00000000000041b74305c68be0c7--


From nobody Wed Jul  7 10:51:34 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CE83A207D for ; Wed,  7 Jul 2021 10:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 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.338, 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=mozilla.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 RGp5L6gr9D8n for ; Wed,  7 Jul 2021 10:51:27 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 5CD0F3A2075 for ; Wed,  7 Jul 2021 10:50:39 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id a6so4746577ioe.0 for ; Wed, 07 Jul 2021 10:50:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QD3GLYXLo/KTvw+Hct/hNronbLAGrLKvOENjsdaNAT0=; b=SbT195VPf9hg52oyKQCgRsbq8HyCtdbsVbS+khSDzbhI8JoVNneqRrQ9o8ufNuWHE2 Tfx758cRDHWP/C4t9igy1gblkrPxefSMkhkVL3MMX3BkGoP2nfqgzjlyQ1wXc6VRQ0Fu JOqakriIlTEI1RSRnCxQe6m8HAhrg9vB20hq8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QD3GLYXLo/KTvw+Hct/hNronbLAGrLKvOENjsdaNAT0=; b=PGEPOwZ+3/3seav2443ilwU7ONhFjAu3R6j6X3uGDvpObpeVAiPG45n/1IXr+stEMU ZlZh0NYohmez7v//HH98JUom/QmZ9pBpu9NR5V1PyvRjFi/IwVb98mo4Dj+WNH2y/5rK AG2lOgpIXg7vQpKYeEmalEizBPihKk3NDJYgt3QEbC6LPXeYHrPasChTOnDmXMVNdAl5 0F3NJCeSa7SIz2s5GxWKfbbSTKfArBLssqOlL7sbRSCSjpjlC/mk/I7qeYt8RXa3j3eB W7mWAUWqCGTstXZJNgMtoz13OeFOKE574wIxrumwn6EtUBe5XOrMwNnD+oQm80fQOxW6 ZpvQ==
X-Gm-Message-State: AOAM531Q4wyXoHD6t8iL2BjuhRCSsjut18rO2VBuzJ/VLvVPvBdoupUF QSLnrQwi8YRpkvC18UBG3HAwDQ==
X-Google-Smtp-Source: ABdhPJzz7hGAHukjkrkRw1r7sq1kvq7Tf9nxH06Qo1UmDDEThKD5BLcHRbTF1NiavJPYSPYbHCwFJg==
X-Received: by 2002:a05:6602:17ce:: with SMTP id z14mr245958iox.73.1625680237828;  Wed, 07 Jul 2021 10:50:37 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id v10sm7861836ilq.71.2021.07.07.10.50.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 10:50:36 -0700 (PDT)
To: Eliot Lear , rfced-future@iab.org
Cc: =?UTF-8?Q?Mirja_K=c3=bchlewind?= 
References: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> <385e1dad-aaad-6adc-f058-73e67d56cd1b@lear.ch>
From: Peter Saint-Andre 
Message-ID: <6107ce3b-4bec-e30c-c594-9098314e3b81@mozilla.com>
Date: Wed, 7 Jul 2021 11:50:35 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <385e1dad-aaad-6adc-f058-73e67d56cd1b@lear.ch>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Call for Adoption: draft-saintandre-rfced-model-01
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 17:51:33 -0000

ACK. I will endeavor to publish an updated I-D this week.

On 7/7/21 10:58 AM, Eliot Lear wrote:
> Hi everyone,
> 
> Thank you for your emails.  There were no objections to adopting this as
> a WG draft.  The chairs will ask Peter to post and Mirja to approve
> draft-iab-rfcefdp-rfced-model-00.
> 
> Eliot
> 
> On 22.06.21 18:02, Eliot Lear wrote:
>>
>> Dear Colleagues,
>>
>> As discussed in the May interim, we are now issuing a Call for
>> Adoption of draft-saintandre-rfced-model-01 as the draft this group
>> will use as intended output.  We hope that this call is a mere
>> formality.  Our procedures for content going into that draft and
>> issues raised do not change.  The purpose of adoption is to make clear
>> our group’s ownership of its content and intent to pursue that work as
>> WG output, with the very generous and kind help of Peter.
>>
>> Please raise any concerns by 6 July 2021.
>>
>> Eliot
>>
>>
> 


From nobody Wed Jul  7 11:34:16 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDA63A23DB for ; Wed,  7 Jul 2021 11:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 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.338, 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 mKhI349ij2KQ for ; Wed,  7 Jul 2021 11:34:09 -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 0BBDC3A23E5 for ; Wed,  7 Jul 2021 11:34:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GKp3h1Ytbz1nsSx; Wed,  7 Jul 2021 11:34:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1625682848; bh=By/5jd5t056e397Mo/Zuuwc3WUt+v8pevjhhEkb9vdE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AMbiK51sX89C5hriJlMFgQT/JP2ocXA7LxWYeJ7gOu6tcQElJK3+QKbe+qBq02tVs bmdmw13pgab2sflh0UaOwFum49jlmx2ZvmFGtcMeDUzWMxsPTnnT/oHC2sc9xCngvr U1p1mxBCIxnfu8ghdJJR+lqAM+aAx2iXSkbQ2wrk=
X-Quarantine-ID: 
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 4GKp3g4Ptfz1nt5Q; Wed,  7 Jul 2021 11:34:06 -0700 (PDT)
To: Eric Rescorla 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com> 
From: "Joel M. Halpern" 
Message-ID: <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>
Date: Wed, 7 Jul 2021 14:34:06 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 18:34:15 -0000

I think I am missing something in your reasoning EKR.

We are discussing the case where the RSWG chairs are not advancing 
something in the presence of a claimed rough consensus in support of 
that thing.

And you are objecting to the RSAB being able to "force the WG to advance 
ideas it thinks are good even if the RSWG does not."

if there is rough consensus for the idea, then the RSWG thinks the idea 
is good, even if the chairs do not.  I believe the chairs should lose 
that fight.

The other alternative is that there is not rough consensus for the idea, 
but the RSAB claims there is.  That would seem to be subject to the 
already agreed rules for appealing RSAB actions.  Because in that 
situation the RSAB would not be following the process.

Why is that not sufficient?

Yours,
Joel

On 7/7/2021 1:28 PM, Eric Rescorla wrote:
> 
> 
> On Tue, Jul 6, 2021 at 9:59 PM Michael StJohns  > wrote:
> 
>     On 7/7/2021 12:24 AM, Brian E Carpenter wrote:
>>>     Hmmm.  Really?  The IESG or the IAB getting into giving advice and
>>>     opinions on how the RSWG works seems to be an involvement we have been
>>>     avoiding.  
>>     True. But in any case, firing them is the ultimate sanction (just as a
>>     recall in the IETF process is the ultimate sanction). As long as we have
>>     firing as an option, "advise, admonish, express serious concerns" will
>>     happen anyway, behind the scenes if not in public. I don't think we need
>>     to write that down, because it would just happen if things went wrong.
>>
>>         Brian
>>
> 
>     The question to which I keep returning:   To whom is the RSWG
>     accountable too if not the RSAB?    It's certainly not accountable
>     to the community, even though it's made up of various permutations
>     (over time) of the members of the community.  About all the
>     community could do with a broken WG is to rerun the process we're
>     currently doing and restructure yet again.  That seems both like
>     overkill and a bad model.
> 
> Well, I do think that it's *accountable* to the community but needs the 
> consent of the RSAB.
> 
>     The WG chairs can be replaced, but there is no equivalent recourse
>     for participants proposing and approving harmful proposals or for
>     that matter sitting on their hands and not proposing and creating
>     necessary documents.   And now it sounds like EKR et al (sorry to
>     single you out, but yours is the most recent push against RSAB
>     checks and balances) are looking for a model where the RSAB can only
>     push back on processes and not bad documents or ideas. Or not even
>     that with the proposal to eliminate appeals from RSWG actions.
> 
> I just want to clarify that I am not arguing that that the RSAB should 
> not be able to push back on bad documents or ideas. What I'm saying is 
> that the RSAB should not be able to force the WG to advance ideas it 
> thinks are good even if the RSWG does not.
> 
> -Ekr
> 
> 
>     I know who all of the RSAB members will be - not the individuals,
>     but their chains of authority and responsibility stemming from their
>     positions and from their organizations.  I'm less sure of the RSWG
>     chairs.   The rest of the crowd has no agreed upon individual
>     responsibilities, but gets ultimate authority?  This model seems to
>     be moving to less and less of a good balance of authority and
>     responsibility the further we go.
> 
>     Later, Mike
> 
> 
> 
>     -- 
>     Rfced-future mailing list
>     Rfced-future@iab.org 
>     https://www.iab.org/mailman/listinfo/rfced-future
>     
> 
> 


From nobody Wed Jul  7 12:24:07 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42ADB3A256E for ; Wed,  7 Jul 2021 12:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.428
X-Spam-Level: 
X-Spam-Status: No, score=-2.428 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.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErotBC4UKdSM for ; Wed,  7 Jul 2021 12:24:00 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 A10A73A256B for ; Wed,  7 Jul 2021 12:24:00 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1001::440] ([IPv6:2001:420:c0c0:1001:0:0:0:440]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 167JNu6d104516 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 7 Jul 2021 21:23:57 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625685837; bh=j/zpTsUQe7+F5js+qxVjJdsMf92lvBg4RmL+YOUBhtQ=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=DJblRt4f4/U+bYpSsdrGBeePtuRN7v85GcskBy07kpLyg3grWFuyJPH+LKHkzUgXi kt91SRxASGxXrQ3ZZ+q32u7KQiWzYG4Of9nSxknnR/2fVKNJHwKa8gGVzSvHipsJzP 5ANUJ+oVEXnaXmIGt6y1UkVZVEY+PLuc5F4F8CFU=
To: "Joel M. Halpern" , Eric Rescorla 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>
From: Eliot Lear 
Message-ID: <42dbd74a-6a8f-7b1b-9b25-427c6d786a37@lear.ch>
Date: Wed, 7 Jul 2021 21:23:54 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I3pzZkEKPEn8I9ZbpFLawlzUD0ZVETq7F"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 19:24:07 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--I3pzZkEKPEn8I9ZbpFLawlzUD0ZVETq7F
Content-Type: multipart/mixed; boundary="9np1kG2cMz6Rpu8G3XyLIO02B9k4vWU3C";
 protected-headers="v1"
From: Eliot Lear 
To: "Joel M. Halpern" , Eric Rescorla 
Cc: rfced-future@iab.org
Message-ID: <42dbd74a-6a8f-7b1b-9b25-427c6d786a37@lear.ch>
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch>
 <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk>
 <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch>
 <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>
 
 <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>
 
 
 <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>
 
 <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>
 
 
 <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com>
 <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>
 
 <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>
In-Reply-To: <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>

--9np1kG2cMz6Rpu8G3XyLIO02B9k4vWU3C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

If I may, Joel:

On 07.07.21 20:34, Joel M. Halpern wrote:
> I think I am missing something in your reasoning EKR.
>
> We are discussing the case where the RSWG chairs are not advancing=20
> something in the presence of a claimed rough consensus in support of=20
> that thing.
>
> And you are objecting to the RSAB being able to "force the WG to=20
> advance ideas it thinks are good even if the RSWG does not."
>
> if there is rough consensus for the idea, then the RSWG thinks the=20
> idea is good, even if the chairs do not.=C2=A0 I believe the chairs sho=
uld=20
> lose that fight.

Perhaps=C2=A0 EKR is worried about the case where people who serve on the=
=20
RSAB make a proposal and then appeal to the RSAB to force the chairs to=20
call consensus or to even declare consensus, and the the RSAB upholds=20
the appeal.=C2=A0 This is similar to how people were concerned about the =
IAB=20
imposing themselves on the IESG. Perhaps the group would want to=20
consider some analog to the language used in 2119 to avoid excessive=20
RSAB influence.

Eliot




--9np1kG2cMz6Rpu8G3XyLIO02B9k4vWU3C--

--I3pzZkEKPEn8I9ZbpFLawlzUD0ZVETq7F
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDl/0oFAwAAAAAACgkQh7ZrRtnSejNL
fwgAzhwBam57tu1hyFizB1L+S2P7HpZdJ+KgUu1zGSZde/dPwC4n9PrWmMoebNuGBK1vK3GEYQSZ
8QARTbi/P8A+lVQnN7249exajwQnndqqhn66vBvUsA25q4bt41K6lSHL39hY47xQ23hYzrqwZMyC
AdgK/7o2xY8BYCNzv1RqeAV7MkrFKGGiYselqX6a0H4BbtQb1GH+G3DTn30weslW26LOZN2T4inh
kJOcKP+s7lsa5RUFIHO6+Q2R+u3DTNjF3Ifa5Ftr2pV5ncIPIBOhw+lqj6RzKBrljPSD990JWXzb
MxlJt1X25soiOAVqKg+EbYmxBBYXas+RH/iotDO70w==
=mPYo
-----END PGP SIGNATURE-----

--I3pzZkEKPEn8I9ZbpFLawlzUD0ZVETq7F--


From nobody Wed Jul  7 13:25:48 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36203A0ED5 for ; Wed,  7 Jul 2021 13:25:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qWFL86owNluo for ; Wed,  7 Jul 2021 13:25:41 -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 DBDE73A0EC3 for ; Wed,  7 Jul 2021 13:25:40 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id a6so5350285ioe.0 for ; Wed, 07 Jul 2021 13:25:40 -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=ReHER98PvSe81ecDhCIZdG4j9tuyoY1rtNuDR81bpP8=; b=Ukm3koxL2O1mvIWw0LivH3h2ZJLhof4CMzpXxVZC4khadhkwNvAVb7Wt9sel0KoXEr IU8xju4DqtigrgZAB2u3f5bx4q2fZ9bVhJMhrSQ9Tu9omf9IDShHP1yyiXu6r0Xt9h13 1aAG1EaG0srJoptpLzMCBbcw+3gjqMLzDAvT+1Wi3/zJEPROOaMSmvsyNdDP3MzeGuX5 EtVxe9awuArdhzX1mY+naXCgJ5w/P3GijC9wDWtu/zEML/fFJtmFE2Jy5lksfHLn/zrO m+5w5MM6Z+54b+BBptepmeDalhwyvgSzr955aB95VH5Puhilxv0akoHmib6PJI2qdXAY bqmg==
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=ReHER98PvSe81ecDhCIZdG4j9tuyoY1rtNuDR81bpP8=; b=Rt+dpB7NTeqNtgaKxT6dqcwl11hxACfdfeSeecvzAybE/EiY0Fd/hwpb+rbdrz2tiS fNOs0lHDeqpXbEOT0Ppz5tHr/FpgwUp1hoJ6ltLuPozXd5wpMODTWC2eHfsJLl0MzlcB tK5CWLf3UiSQA6VrO1a0V/blNuQmhO6CcVDgtQe2x2yDirtdwOFapmITAwpzU5IdQM3Q 0Yih2pGxFnP8E3KRF+s76VrP9Qn2EWxQ/VQ+Wk/HsTcevK7+B5XsrAc52bPaKjfY+U/i dE1j3Dyh/NNmJCSkrO56liA3o4a4bAeWQKr+4a3t0BknNIZPFdALanb+GOosdW0IPWyJ +hEg==
X-Gm-Message-State: AOAM531OADZ6Tl4eiVzxg9ZZsvq1unU289VqKHs4y8qLhgIVrSGufGDN iNM7fziIp2qQ9mIeporSFkQjs1gl6p+ZcjAnxymKiw==
X-Google-Smtp-Source: ABdhPJwEYdjyxJyhREd6MEDTQHWmy9rPGvpH9qVjbrIYAyNyx1Y7vGBSR9fEZz4UFHI9Y7zsa/7Q3QsJguGmAwqra/s=
X-Received: by 2002:a6b:f914:: with SMTP id j20mr20678318iog.127.1625689538916;  Wed, 07 Jul 2021 13:25:38 -0700 (PDT)
MIME-Version: 1.0
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com> <42dbd74a-6a8f-7b1b-9b25-427c6d786a37@lear.ch>
In-Reply-To: <42dbd74a-6a8f-7b1b-9b25-427c6d786a37@lear.ch>
From: Eric Rescorla 
Date: Wed, 7 Jul 2021 13:25:02 -0700
Message-ID: 
To: Eliot Lear 
Cc: "Joel M. Halpern" , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000007b8cd105c68e57bc"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 20:25:46 -0000

--0000000000007b8cd105c68e57bc
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 7, 2021 at 12:24 PM Eliot Lear  wrote:

> If I may, Joel:
>
> On 07.07.21 20:34, Joel M. Halpern wrote:
> > I think I am missing something in your reasoning EKR.
> >
> > We are discussing the case where the RSWG chairs are not advancing
> > something in the presence of a claimed rough consensus in support of
> > that thing.
> >
> > And you are objecting to the RSAB being able to "force the WG to
> > advance ideas it thinks are good even if the RSWG does not."
> >
> > if there is rough consensus for the idea, then the RSWG thinks the
> > idea is good, even if the chairs do not.  I believe the chairs should
> > lose that fight.
>
> Perhaps  EKR is worried about the case where people who serve on the
> RSAB make a proposal and then appeal to the RSAB to force the chairs to
> call consensus or to even declare consensus, and the the RSAB upholds
> the appeal.


Yes, more or less.


  This is similar to how people were concerned about the IAB
> imposing themselves on the IESG. Perhaps the group would want to
> consider some analog to the language used in 2119 to avoid excessive
> RSAB influence.
>

That might work.

-Ekr

Eliot
>
>
>
>

--0000000000007b8cd105c68e57bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Jul 7, 2021 at 12:24 PM Eliot=
 Lear <lear@lear.ch> wrote:
If I may, Joel:



On 07.07.21 20:34, Joel M. Halpern wrote:

> I think I am missing something in your reasoning EKR.

>

> We are discussing the case where the RSWG chairs are not advancing 
> something in the presence of a claimed rough consensus in support of <=
br>
> that thing.

>

> And you are objecting to the RSAB being able to "force the WG to =


> advance ideas it thinks are good even if the RSWG does not."

>

> if there is rough consensus for the idea, then the RSWG thinks the 
> idea is good, even if the chairs do not.=C2=A0 I believe the chairs sh=
ould 

> lose that fight.



Perhaps=C2=A0 EKR is worried about the case where people who serve on the <=
br>
RSAB make a proposal and then appeal to the RSAB to force the chairs to 
call consensus or to even declare consensus, and the the RSAB upholds 

the appeal.

Yes, more or less.
 
=
=C2=A0 This is similar to how people were concerned about the IAB 

imposing themselves on the IESG. Perhaps the group would want to 

consider some analog to the language used in 2119 to avoid excessive 

RSAB influence.

That might work.
<=
div>
-Ekr


Eliot










--0000000000007b8cd105c68e57bc--


From nobody Wed Jul  7 13:29:56 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA33A0FC9 for ; Wed,  7 Jul 2021 13:29:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 stqP9AHEU6Iy for ; Wed,  7 Jul 2021 13:29:49 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 886333A26BB for ; Wed,  7 Jul 2021 13:29:25 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id y8so5264851iop.13 for ; Wed, 07 Jul 2021 13:29:25 -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=4s6Ndip795ictqwCB5TBbHPLbEBWA9s4O4uXNnl64jk=; b=WcaOfegVsehlrUGNtJAzGaAk7laEJjU7t5z9vOaDtffwYQIN+lxUeDfrSQGKgevxBr Plv14l2+VRPsgEYxSmVCFC6Ty/mDgxALoYsHy/xF/Iu+Kww9UKOwPsF5AK/24Z3gTtXW qFL9NzuSckLolYNm/kWcBSNS3FGAb56Dsb40FWTH2hAkBpzbKi0YFhemjojkhbfkwKcW ywOSyKBiGcThZIzzVSSNG4UaGKHvWLxgmIsuhiZg+pemin9eRnakJ5EcP/15Dcw4L2+I oAqStTfVnHLbgigoGQb9Q6A9hvlZ2nypWyiRNsCsVlYh/HmyaqIB/eR+nbAySql06Nhb Hi0w==
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=4s6Ndip795ictqwCB5TBbHPLbEBWA9s4O4uXNnl64jk=; b=pA/0DnbLbYurwmAhsqQY9zPj5dgN0cy3u6xSzWF5tYB8dS5qRixWg26QgpozP9Ecrk fhsz5AonRQDAtXsM6SmKXuhk1qfr39s/Z2YuXn8+d/fEbOziXYk93hA/j52Ayk9/DF7I BhNu+YIOtbS2Y88s13FtSh4JXep/9lfLQWrjl60yvnGQHOiwQ9uJkH0/pOYf6mu/rYxM kFuNN2KU37TW6SJkHKB2ktiiLYfraxk/FTae9sFF1zQZGNmySmK4S7/AMUo0tBFGPZQc rWC1V5Cyn4t/jJDGssjo6iiLraR30VVJpuuFRKTkhppvfgfE20596YkNu1j35+oVMEQN WC8g==
X-Gm-Message-State: AOAM531+EVlQ7crcXTOERjoMM4QPDZ3ifiNpGDswBskZTpu9+fVl2Mw0 7KVR1BrBv3N2eLB9JaT8vZv1v3Old0Ovt4QWBQHnqw==
X-Google-Smtp-Source: ABdhPJw0fhUptC/WQH661DsqPSCJPNplUryZQbGoGn+VrH/dzHgUvxBl8QzzMMRb766QTpUSUH3FpBU6IdM8iVzcLRY=
X-Received: by 2002:a05:6638:4114:: with SMTP id ay20mr23315485jab.10.1625689764210;  Wed, 07 Jul 2021 13:29:24 -0700 (PDT)
MIME-Version: 1.0
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>
In-Reply-To: <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>
From: Eric Rescorla 
Date: Wed, 7 Jul 2021 13:28:48 -0700
Message-ID: 
To: "Joel M. Halpern" 
Cc: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000e93c4905c68e6439"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 20:29:55 -0000

--000000000000e93c4905c68e6439
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 7, 2021 at 11:34 AM Joel M. Halpern  wrote:

> I think I am missing something in your reasoning EKR.
>
> We are discussing the case where the RSWG chairs are not advancing
> something in the presence of a claimed rough consensus in support of
> that thing.
>
> And you are objecting to the RSAB being able to "force the WG to advance
> ideas it thinks are good even if the RSWG does not."
>
> if there is rough consensus for the idea, then the RSWG thinks the idea
> is good, even if the chairs do not.  I believe the chairs should lose
> that fight.


I'm generally fairly sympathetic to this position, though I would note that
in
the IETF the Chair's role seems a bit muddled here. See especially RFC 4858
S 3.1,
which I think implies that the chairs do have some substantive
responsibility for
document quality, not just procedural responsibilities.


The other alternative is that there is not rough consensus for the idea,
> but the RSAB claims there is.  That would seem to be subject to the
> already agreed rules for appealing RSAB actions.  Because in that
> situation the RSAB would not be following the process.
>

> Why is that not sufficient?
>

Well, it's actually not clear to me that this *would* violate the process,
but perhaps
all that's needed is some sharpening of the text, as Eliot suggests.

-Ekr



> Yours,
> Joel
>
> On 7/7/2021 1:28 PM, Eric Rescorla wrote:
> >
> >
> > On Tue, Jul 6, 2021 at 9:59 PM Michael StJohns  > > wrote:
> >
> >     On 7/7/2021 12:24 AM, Brian E Carpenter wrote:
> >>>     Hmmm.  Really?  The IESG or the IAB getting into giving
> advice and
> >>>     opinions on how the RSWG works seems to be an involvement we have
> been
> >>>     avoiding.  
> >>     True. But in any case, firing them is the ultimate sanction (just
> as a
> >>     recall in the IETF process is the ultimate sanction). As long as we
> have
> >>     firing as an option, "advise, admonish, express serious concerns"
> will
> >>     happen anyway, behind the scenes if not in public. I don't think we
> need
> >>     to write that down, because it would just happen if things went
> wrong.
> >>
> >>         Brian
> >>
> >
> >     The question to which I keep returning:   To whom is the RSWG
> >     accountable too if not the RSAB?    It's certainly not accountable
> >     to the community, even though it's made up of various permutations
> >     (over time) of the members of the community.  About all the
> >     community could do with a broken WG is to rerun the process we're
> >     currently doing and restructure yet again.  That seems both like
> >     overkill and a bad model.
> >
> > Well, I do think that it's *accountable* to the community but needs the
> > consent of the RSAB.
> >
> >     The WG chairs can be replaced, but there is no equivalent recourse
> >     for participants proposing and approving harmful proposals or for
> >     that matter sitting on their hands and not proposing and creating
> >     necessary documents.   And now it sounds like EKR et al (sorry to
> >     single you out, but yours is the most recent push against RSAB
> >     checks and balances) are looking for a model where the RSAB can only
> >     push back on processes and not bad documents or ideas. Or not even
> >     that with the proposal to eliminate appeals from RSWG actions.
> >
> > I just want to clarify that I am not arguing that that the RSAB should
> > not be able to push back on bad documents or ideas. What I'm saying is
> > that the RSAB should not be able to force the WG to advance ideas it
> > thinks are good even if the RSWG does not.
> >
> > -Ekr
> >
> >
> >     I know who all of the RSAB members will be - not the individuals,
> >     but their chains of authority and responsibility stemming from their
> >     positions and from their organizations.  I'm less sure of the RSWG
> >     chairs.   The rest of the crowd has no agreed upon individual
> >     responsibilities, but gets ultimate authority?  This model seems to
> >     be moving to less and less of a good balance of authority and
> >     responsibility the further we go.
> >
> >     Later, Mike
> >
> >
> >
> >     --
> >     Rfced-future mailing list
> >     Rfced-future@iab.org 
> >     https://www.iab.org/mailman/listinfo/rfced-future
> >     
> >
> >
>

--000000000000e93c4905c68e6439
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Jul 7, 2021 at 11:34 AM Joel =
M. Halpern <jmh@joelhalpern.com> wrote:
I =
think I am missing something in your reasoning EKR.



We are discussing the case where the RSWG chairs are not advancing 

something in the presence of a claimed rough consensus in support of 

that thing.



And you are objecting to the RSAB being able to "force the WG to advan=
ce 

ideas it thinks are good even if the RSWG does not."



if there is rough consensus for the idea, then the RSWG thinks the idea 
is good, even if the chairs do not.=C2=A0 I believe the chairs should lose =


that fight.

the IETF the =
Chair's role seems a bit muddled here. See especially RFC 4858 S 3.1,
which I think implies that the chairs do have some substantive res=
ponsibility for
document quality, not just procedural responsibil=
ities.

 

The other alternative is that there is not rough consensus for the idea, 
but the RSAB claims there is.=C2=A0 That would seem to be subject to the 
already agreed rules for appealing RSAB actions.=C2=A0 Because in that 

situation the RSAB would not be following the process.



Why is that not sufficient?

Well, it=
9;s actually not clear to me that this *would* violate the process, but per=
haps
all that's needed is some sharpening of the text, as Eli=
ot suggests.

-Ekr

=C2=A0<=
/div>

Yours,

Joel



On 7/7/2021 1:28 PM, Eric Rescorla wrote:

> 

> 

> On Tue, Jul 6, 2021 at 9:59 PM Michael StJohns <msj@nthpermutation.com 

> <mailto:msj@nthpermutation.com>> wrote:

> 

>=C2=A0 =C2=A0 =C2=A0On 7/7/2021 12:24 AM, Brian E Carpenter wrote:

>>>=C2=A0 =C2=A0 =C2=A0<jmh>Hmmm.=C2=A0 Really?=C2=A0 The IE=
SG or the IAB getting into giving advice and

>>>=C2=A0 =C2=A0 =C2=A0opinions on how the RSWG works seems to be =
an involvement we have been

>>>=C2=A0 =C2=A0 =C2=A0avoiding.=C2=A0 </jmh>

>>=C2=A0 =C2=A0 =C2=A0True. But in any case, firing them is the ultim=
ate sanction (just as a

>>=C2=A0 =C2=A0 =C2=A0recall in the IETF process is the ultimate sanc=
tion). As long as we have

>>=C2=A0 =C2=A0 =C2=A0firing as an option, "advise, admonish, ex=
press serious concerns" will

>>=C2=A0 =C2=A0 =C2=A0happen anyway, behind the scenes if not in publ=
ic. I don't think we need

>>=C2=A0 =C2=A0 =C2=A0to write that down, because it would just happe=
n if things went wrong.

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brian

>>

> 

>=C2=A0 =C2=A0 =C2=A0The question to which I keep returning:=C2=A0=C2=A0=
 To whom is the RSWG

>=C2=A0 =C2=A0 =C2=A0accountable too if not the RSAB?=C2=A0=C2=A0=C2=A0 =
It's certainly not accountable

>=C2=A0 =C2=A0 =C2=A0to the community, even though it's made up of v=
arious permutations

>=C2=A0 =C2=A0 =C2=A0(over time) of the members of the community.=C2=A0 =
About all the

>=C2=A0 =C2=A0 =C2=A0community could do with a broken WG is to rerun the=
 process we're

>=C2=A0 =C2=A0 =C2=A0currently doing and restructure yet again.=C2=A0 Th=
at seems both like

>=C2=A0 =C2=A0 =C2=A0overkill and a bad model.

> 

> Well, I do think that it's *accountable* to the community but need=
s the 

> consent of the RSAB.

> 

>=C2=A0 =C2=A0 =C2=A0The WG chairs can be replaced, but there is no equi=
valent recourse

>=C2=A0 =C2=A0 =C2=A0for participants proposing and approving harmful pr=
oposals or for

>=C2=A0 =C2=A0 =C2=A0that matter sitting on their hands and not proposin=
g and creating

>=C2=A0 =C2=A0 =C2=A0necessary documents.=C2=A0=C2=A0 And now it sounds =
like EKR et al (sorry to

>=C2=A0 =C2=A0 =C2=A0single you out, but yours is the most recent push a=
gainst RSAB

>=C2=A0 =C2=A0 =C2=A0checks and balances) are looking for a model where =
the RSAB can only

>=C2=A0 =C2=A0 =C2=A0push back on processes and not bad documents or ide=
as. Or not even

>=C2=A0 =C2=A0 =C2=A0that with the proposal to eliminate appeals from RS=
WG actions.

> 

> I just want to clarify that I am not arguing that that the RSAB should=
 

> not be able to push back on bad documents or ideas. What I'm sayin=
g is 

> that the RSAB should not be able to force the WG to advance ideas it <=
br>
> thinks are good even if the RSWG does not.

> 

> -Ekr

> 

> 

>=C2=A0 =C2=A0 =C2=A0I know who all of the RSAB members will be - not th=
e individuals,

>=C2=A0 =C2=A0 =C2=A0but their chains of authority and responsibility st=
emming from their

>=C2=A0 =C2=A0 =C2=A0positions and from their organizations.=C2=A0 I'=
;m less sure of the RSWG

>=C2=A0 =C2=A0 =C2=A0chairs.=C2=A0=C2=A0 The rest of the crowd has no ag=
reed upon individual

>=C2=A0 =C2=A0 =C2=A0responsibilities, but gets ultimate authority?=C2=
=A0 This model seems to

>=C2=A0 =C2=A0 =C2=A0be moving to less and less of a good balance of aut=
hority and

>=C2=A0 =C2=A0 =C2=A0responsibility the further we go.

> 

>=C2=A0 =C2=A0 =C2=A0Later, Mike

> 

> 

> 

>=C2=A0 =C2=A0 =C2=A0-- 

>=C2=A0 =C2=A0 =C2=A0Rfced-future mailing list

>=C2=A0 =C2=A0 =C2=A0Rfced-future@iab.org <mailto:Rfced-future@iab.org>

>=C2=A0 =C2=A0 =C2=A0https://www.iab.org/mailman=
/listinfo/rfced-future

>=C2=A0 =C2=A0 =C2=A0<https://www.iab.org/mai=
lman/listinfo/rfced-future>

> 

> 




--000000000000e93c4905c68e6439--


From nobody Wed Jul  7 14:35:25 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22BA3A0970 for ; Wed,  7 Jul 2021 14:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 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.338, RCVD_IN_DNSWL_BLOCKED=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 vqA_kqa2GExA for ; Wed,  7 Jul 2021 14:35:17 -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 577F83A0964 for ; Wed,  7 Jul 2021 14:35:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GKt4h33cQz6G9RY; Wed,  7 Jul 2021 14:35:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1625693716; bh=996E1PnyFwsZBKf/7t33S5MjhfVSmX+keenCwYWJHbE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=iojFmaLVfz6tCvXYNkXH3rtuc9rEeAiXW4RPuSqwXsknPAy1MV4XXPwLxwTU8Kmcy nJL34SrHHkMefSdjE/PWl0njhYYExj30rpzZPKq3HUF/lBgdK4FMRKt4wjaOJg1e52 W8JUDM/VC8LhmzbW4bFPb75ErGEXp4+B1E9RI7l0=
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 4GKt4g5zlKz6G9RN; Wed,  7 Jul 2021 14:35:15 -0700 (PDT)
To: Eric Rescorla 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com> 
From: "Joel M. Halpern" 
Message-ID: <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com>
Date: Wed, 7 Jul 2021 17:35:15 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 21:35:23 -0000

Do you think we need to include a sentence or two in the document saying 
that the chairs are required to follow the rough consensus of the 
working group?   And further that in process matters the RSAB is 
requried to respect the rough consensus of the working group?    If that 
will help get this issue unstuck, I am all for it.

Yours,
Joel

On 7/7/2021 4:28 PM, Eric Rescorla wrote:
> 
> 
> On Wed, Jul 7, 2021 at 11:34 AM Joel M. Halpern  > wrote:
> 
>     I think I am missing something in your reasoning EKR.
> 
>     We are discussing the case where the RSWG chairs are not advancing
>     something in the presence of a claimed rough consensus in support of
>     that thing.
> 
>     And you are objecting to the RSAB being able to "force the WG to
>     advance
>     ideas it thinks are good even if the RSWG does not."
> 
>     if there is rough consensus for the idea, then the RSWG thinks the idea
>     is good, even if the chairs do not.  I believe the chairs should lose
>     that fight.
> 
> 
> I'm generally fairly sympathetic to this position, though I would note 
> that in
> the IETF the Chair's role seems a bit muddled here. See especially RFC 
> 4858 S 3.1,
> which I think implies that the chairs do have some substantive 
> responsibility for
> document quality, not just procedural responsibilities.
> 
> 
>     The other alternative is that there is not rough consensus for the
>     idea,
>     but the RSAB claims there is.  That would seem to be subject to the
>     already agreed rules for appealing RSAB actions.  Because in that
>     situation the RSAB would not be following the process.
> 
> 
>     Why is that not sufficient?
> 
> 
> Well, it's actually not clear to me that this *would* violate the 
> process, but perhaps
> all that's needed is some sharpening of the text, as Eliot suggests.
> 
> -Ekr
> 
>     Yours,
>     Joel
> 
>     On 7/7/2021 1:28 PM, Eric Rescorla wrote:
>      >
>      >
>      > On Tue, Jul 6, 2021 at 9:59 PM Michael StJohns
>     
>      > >>
>     wrote:
>      >
>      >     On 7/7/2021 12:24 AM, Brian E Carpenter wrote:
>      >>>     Hmmm.  Really?  The IESG or the IAB getting into
>     giving advice and
>      >>>     opinions on how the RSWG works seems to be an involvement
>     we have been
>      >>>     avoiding.  
>      >>     True. But in any case, firing them is the ultimate sanction
>     (just as a
>      >>     recall in the IETF process is the ultimate sanction). As
>     long as we have
>      >>     firing as an option, "advise, admonish, express serious
>     concerns" will
>      >>     happen anyway, behind the scenes if not in public. I don't
>     think we need
>      >>     to write that down, because it would just happen if things
>     went wrong.
>      >>
>      >>         Brian
>      >>
>      >
>      >     The question to which I keep returning:   To whom is the RSWG
>      >     accountable too if not the RSAB?    It's certainly not
>     accountable
>      >     to the community, even though it's made up of various
>     permutations
>      >     (over time) of the members of the community.  About all the
>      >     community could do with a broken WG is to rerun the process we're
>      >     currently doing and restructure yet again.  That seems both like
>      >     overkill and a bad model.
>      >
>      > Well, I do think that it's *accountable* to the community but
>     needs the
>      > consent of the RSAB.
>      >
>      >     The WG chairs can be replaced, but there is no equivalent
>     recourse
>      >     for participants proposing and approving harmful proposals or for
>      >     that matter sitting on their hands and not proposing and creating
>      >     necessary documents.   And now it sounds like EKR et al (sorry to
>      >     single you out, but yours is the most recent push against RSAB
>      >     checks and balances) are looking for a model where the RSAB
>     can only
>      >     push back on processes and not bad documents or ideas. Or not
>     even
>      >     that with the proposal to eliminate appeals from RSWG actions.
>      >
>      > I just want to clarify that I am not arguing that that the RSAB
>     should
>      > not be able to push back on bad documents or ideas. What I'm
>     saying is
>      > that the RSAB should not be able to force the WG to advance ideas it
>      > thinks are good even if the RSWG does not.
>      >
>      > -Ekr
>      >
>      >
>      >     I know who all of the RSAB members will be - not the individuals,
>      >     but their chains of authority and responsibility stemming
>     from their
>      >     positions and from their organizations.  I'm less sure of the
>     RSWG
>      >     chairs.   The rest of the crowd has no agreed upon individual
>      >     responsibilities, but gets ultimate authority?  This model
>     seems to
>      >     be moving to less and less of a good balance of authority and
>      >     responsibility the further we go.
>      >
>      >     Later, Mike
>      >
>      >
>      >
>      >     --
>      >     Rfced-future mailing list
>      > Rfced-future@iab.org 
>     >
>      > https://www.iab.org/mailman/listinfo/rfced-future
>     
>      >          >
>      >
>      >
> 


From nobody Wed Jul  7 15:05:20 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9FF3A0DAE for ; Wed,  7 Jul 2021 15:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 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.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBmrduvL8aSO for ; Wed,  7 Jul 2021 15:05:11 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 128383A0D9C for ; Wed,  7 Jul 2021 15:05:10 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id d12so3758993pgd.9 for ; Wed, 07 Jul 2021 15:05:10 -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=3V5G+7697qFiunJ7lTj7q/UERF+M2/hcVusd3HcR464=; b=Z4o6VPBiDgbHZS4zuoS2ha+Uaw5/2lnJLu/3mu3biaQeDBbRG9cXH9zjHRVnJIoldm KppZyB71P46ZEA3jP7PXqKi1CtkZSs/0m0ggbzlqgx5HIUBMMdngIh3/EqjOKyEl1dOG gC8BGv5imo0l/oNr5m6LdAJQnCBkbZ5BkIvdOsMdeU+OHODJL1kWA57vkzdGLd/Z8c1/ 75deWY1b4g2grVcm1uI2/omVt/OTnyOglT3qXMPAYEUT778R6rENAntrK4pUFBjcl2+t okyX49TJDakvipVOaex0Pa5iDnFdTub4em3R4FJ1VexM0XhgdK7HhFLPhA30+cEq1e4j 0Wjw==
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=3V5G+7697qFiunJ7lTj7q/UERF+M2/hcVusd3HcR464=; b=jl0ud2D5l1n9xUljQrlk1dkh1rHrz5vm83wQlriEVU5vBwIbjVdUPCH12okfDiX+E1 10lKXQxDL/vrvEVbDsMQ5KeHSeN7OdaWMfp73re8bziGWs9KaJW+nRUFytiQReWltOJd TAJDSFWUeEvX46QXZZL3pHPs6eFR3ulWOPNI+3WzVN7aCxWP8TKP3FAMPuvpw85o8LVh oa/4Nw18lG/t4hW9PFpb0r3vF51LNPz1idPVZruF7Tn1IrID7oemNSTB3SLRzTLI5I0/ rAPjw4X+cl93Q19Nd5NZbLTw86IGxpfaCy/xADk2u+u2uS6Ah+57I3+ngqAdzwtpPdub /7Fw==
X-Gm-Message-State: AOAM531cBO4h5JraYt/7Hj/CTFn9GbYEAZCOZl/skm3hV9NbFpTHHBS2 vL7UyLgS/7gdKV1PKE5bb0yGN8aA+2BIDg==
X-Google-Smtp-Source: ABdhPJz2xh0MkXWLj1YyJ9W6z+MuB9t7+yyiJlCzYJl7kb0wWlq6fLV5krP7Zt0rqJJqwPemsqHabw==
X-Received: by 2002:a62:5807:0:b029:326:896:2737 with SMTP id m7-20020a6258070000b029032608962737mr5095976pfb.10.1625695509937;  Wed, 07 Jul 2021 15:05:09 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id q89sm7326838pjq.42.2021.07.07.15.05.08 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 15:05:09 -0700 (PDT)
To: rfced-future@iab.org
References: <612bacba-0bdb-32bb-5369-19486742a111@lear.ch> 
From: Brian E Carpenter 
Message-ID: 
Date: Thu, 8 Jul 2021 10:05:06 +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: [Rfced-future] Issue 68: we prohibited in person meetings and design teams
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 22:05:19 -0000

As long as "in person" includes "on line", so maybe some tiny wordsmithin=
g is needed.

Regards
   Brian Carpenter

On 08-Jul-21 05:01, Eliot Lear wrote:
> I have not heard any objections to the following text.=C2=A0 Peter, ple=
ase include in -01 of WG draft.
>=20
> On 30.06.21 07:55, Eliot Lear wrote:
>>
>>> When the RSWG is formed, all discussions shall take place on an open =
email discussion list or through in person meetings. Subsequently, the RS=
WG may decide by rough consensus to use working methods(e.g., GitHub as s=
pecified in [RFC8874] or design teams) as long as they are consistent wit=
h [RFC2418].
>>
>> Eliot
>>
>>
>>
>=20


From nobody Wed Jul  7 15:08:28 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D083A0DD2 for ; Wed,  7 Jul 2021 15:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 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.338, RCVD_IN_DNSWL_BLOCKED=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 nDEreaUvf3IF for ; Wed,  7 Jul 2021 15:08:22 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 8CC053A0DCE for ; Wed,  7 Jul 2021 15:08:22 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id p17so1327799plf.12 for ; Wed, 07 Jul 2021 15:08:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=D4hxSEVjLYLGw4ELns1cFS2x2r5HKyqogUm5uinUF/Q=; b=EOzZHgjbZFVLd89H9JCfaMcbDvJctp7ScqK9slh/7SzbynTS1YV2feLNelXsgTopxH M/Z8WIWkZEtHraMMsfBe8Vvlvfzr9jJpN4ZI1ELbuAXX+MF2auSECTFEkTxqg/6lcITU BsJMx1MwLWRvuuZDjmfsfArS0O8FxuetjMhl5inwJ63U+JiTVTs+OeJvxVQHE3ytEj+k YiO0kpVAhtpda4VWoWYwJIRMmDSsE86wFmPWyu0h+Y2lUS+S0fuH91p6erP9DRmekZDH sYTBLtZhR8vjjB9Bzj2PWYpXnn7J+IYYn1HRfIbk8jG1uphDFsL5ZTkMihuImLM9Hrh/ dHyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=D4hxSEVjLYLGw4ELns1cFS2x2r5HKyqogUm5uinUF/Q=; b=lRJHoiHw4UqeRXTDKtf8Kvd4i/ZJcmtY9xSekOzTqRePNrfkLO0isM/DWc2If3tpVp Zwa7KjKWfcAIL6wqI8YubPmkcRwkIp/mwLHphnTv3mOpyd2rZGEI5zijdPH7NDvm5mLc TVwb+Ap6Trpmfacf+yHGD0rrmW2AdBaL1PTpzdJwf5hfvEeUosbeqwpoX7iXWrAKEofx TBf9rmSVaB9UvmJhFuV7YK3CT9uvDZuwKMZAFEsFQH8CzlsW4Mo+sI9tjyEhQDtTpsI6 JMyEGle4TWPupvfuqCTEkyUPJRSClDM/DqFHvf8V73yWD9tQ3HgkLRfMG+wJuT2iBC/A kPSw==
X-Gm-Message-State: AOAM5336cjabbpxynOVtkLLhm604QC8CAhQwb1nYumwg+YpH+MeSqE2P taXX0i0sNJyLTCpnmuAjCia62gURlL5HqA==
X-Google-Smtp-Source: ABdhPJwLM4I41KtDTG4CUNTNTNnuKjyzxC0GlyYXy7W3n0MqoZZS6+UZCBg+SW/y9VOYOdWKJ1Kx1A==
X-Received: by 2002:a17:90b:238f:: with SMTP id mr15mr1207846pjb.57.1625695701375;  Wed, 07 Jul 2021 15:08:21 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id p3sm7659277pjt.0.2021.07.07.15.08.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 15:08:20 -0700 (PDT)
To: "Joel M. Halpern" , Eric Rescorla 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>  <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com>
From: Brian E Carpenter 
Message-ID: <29e09ae1-3892-57f4-fe8e-305eca08be04@gmail.com>
Date: Thu, 8 Jul 2021 10:08:17 +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: <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 22:08:27 -0000

On 08-Jul-21 09:35, Joel M. Halpern wrote:
> Do you think we need to include a sentence or two in the document sayin=
g=20
> that the chairs are required to follow the rough consensus of the=20
> working group?   And further that in process matters the RSAB is=20
> requried to respect the rough consensus of the working group?    If tha=
t=20
> will help get this issue unstuck, I am all for it.

That makes sense to me.

   Brian

>=20
> Yours,
> Joel
>=20
> On 7/7/2021 4:28 PM, Eric Rescorla wrote:
>>
>>
>> On Wed, Jul 7, 2021 at 11:34 AM Joel M. Halpern > > wrote:
>>
>>     I think I am missing something in your reasoning EKR.
>>
>>     We are discussing the case where the RSWG chairs are not advancing=

>>     something in the presence of a claimed rough consensus in support =
of
>>     that thing.
>>
>>     And you are objecting to the RSAB being able to "force the WG to
>>     advance
>>     ideas it thinks are good even if the RSWG does not."
>>
>>     if there is rough consensus for the idea, then the RSWG thinks the=20
idea
>>     is good, even if the chairs do not.=C2=A0 I believe the chairs sho=
uld lose
>>     that fight.
>>
>>
>> I'm generally fairly sympathetic to this position, though I would note=20

>> that in
>> the IETF the Chair's role seems a bit muddled here. See especially RFC=20

>> 4858 S 3.1,
>> which I think implies that the chairs do have some substantive=20
>> responsibility for
>> document quality, not just procedural responsibilities.
>>
>>
>>     The other alternative is that there is not rough consensus for the=

>>     idea,
>>     but the RSAB claims there is.=C2=A0 That would seem to be subject =
to the
>>     already agreed rules for appealing RSAB actions.=C2=A0 Because in =
that
>>     situation the RSAB would not be following the process.
>>
>>
>>     Why is that not sufficient?
>>
>>
>> Well, it's actually not clear to me that this *would* violate the=20
>> process, but perhaps
>> all that's needed is some sharpening of the text, as Eliot suggests.
>>
>> -Ekr
>>
>>     Yours,
>>     Joel
>>
>>     On 7/7/2021 1:28 PM, Eric Rescorla wrote:
>>      >
>>      >
>>      > On Tue, Jul 6, 2021 at 9:59 PM Michael StJohns
>>     
>>      > >=
>
>>     wrote:
>>      >
>>      >=C2=A0 =C2=A0 =C2=A0On 7/7/2021 12:24 AM, Brian E Carpenter wrot=
e:
>>      >>>=C2=A0 =C2=A0 =C2=A0Hmmm.=C2=A0 Really?=C2=A0 The IESG or=20
the IAB getting into
>>     giving advice and
>>      >>>=C2=A0 =C2=A0 =C2=A0opinions on how the RSWG works seems to be=20
an involvement
>>     we have been
>>      >>>=C2=A0 =C2=A0 =C2=A0avoiding.=C2=A0 
>>      >>=C2=A0 =C2=A0 =C2=A0True. But in any case, firing them is the u=
ltimate sanction
>>     (just as a
>>      >>=C2=A0 =C2=A0 =C2=A0recall in the IETF process is the ultimate =
sanction). As
>>     long as we have
>>      >>=C2=A0 =C2=A0 =C2=A0firing as an option, "advise, admonish, exp=
ress serious
>>     concerns" will
>>      >>=C2=A0 =C2=A0 =C2=A0happen anyway, behind the scenes if not in =
public. I don't
>>     think we need
>>      >>=C2=A0 =C2=A0 =C2=A0to write that down, because it would just h=
appen if things
>>     went wrong.
>>      >>
>>      >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brian
>>      >>
>>      >
>>      >=C2=A0 =C2=A0 =C2=A0The question to which I keep returning:=C2=A0=
=C2=A0 To whom is the RSWG
>>      >=C2=A0 =C2=A0 =C2=A0accountable too if not the RSAB?=C2=A0=C2=A0=
=C2=A0 It's certainly not
>>     accountable
>>      >=C2=A0 =C2=A0 =C2=A0to the community, even though it's made up o=
f various
>>     permutations
>>      >=C2=A0 =C2=A0 =C2=A0(over time) of the members of the community.=
=C2=A0 About all the
>>      >=C2=A0 =C2=A0 =C2=A0community could do with a broken WG is to re=
run the process we're
>>      >=C2=A0 =C2=A0 =C2=A0currently doing and restructure yet again.=C2=
=A0 That seems both like
>>      >=C2=A0 =C2=A0 =C2=A0overkill and a bad model.
>>      >
>>      > Well, I do think that it's *accountable* to the community but
>>     needs the
>>      > consent of the RSAB.
>>      >
>>      >=C2=A0 =C2=A0 =C2=A0The WG chairs can be replaced, but there is =
no equivalent
>>     recourse
>>      >=C2=A0 =C2=A0 =C2=A0for participants proposing and approving har=
mful proposals or for
>>      >=C2=A0 =C2=A0 =C2=A0that matter sitting on their hands and not p=
roposing and creating
>>      >=C2=A0 =C2=A0 =C2=A0necessary documents.=C2=A0=C2=A0 And now it =
sounds like EKR et al (sorry to
>>      >=C2=A0 =C2=A0 =C2=A0single you out, but yours is the most recent=20
push against RSAB
>>      >=C2=A0 =C2=A0 =C2=A0checks and balances) are looking for a model=20
where the RSAB
>>     can only
>>      >=C2=A0 =C2=A0 =C2=A0push back on processes and not bad documents=20
or ideas. Or not
>>     even
>>      >=C2=A0 =C2=A0 =C2=A0that with the proposal to eliminate appeals =
from RSWG actions.
>>      >
>>      > I just want to clarify that I am not arguing that that the RSAB=

>>     should
>>      > not be able to push back on bad documents or ideas. What I'm
>>     saying is
>>      > that the RSAB should not be able to force the WG to advance ide=
as it
>>      > thinks are good even if the RSWG does not.
>>      >
>>      > -Ekr
>>      >
>>      >
>>      >=C2=A0 =C2=A0 =C2=A0I know who all of the RSAB members will be -=20
not the individuals,
>>      >=C2=A0 =C2=A0 =C2=A0but their chains of authority and responsibi=
lity stemming
>>     from their
>>      >=C2=A0 =C2=A0 =C2=A0positions and from their organizations.=C2=A0=20
I'm less sure of the
>>     RSWG
>>      >=C2=A0 =C2=A0 =C2=A0chairs.=C2=A0=C2=A0 The rest of the crowd ha=
s no agreed upon individual
>>      >=C2=A0 =C2=A0 =C2=A0responsibilities, but gets ultimate authorit=
y?=C2=A0 This model
>>     seems to
>>      >=C2=A0 =C2=A0 =C2=A0be moving to less and less of a good balance=20
of authority and
>>      >=C2=A0 =C2=A0 =C2=A0responsibility the further we go.
>>      >
>>      >=C2=A0 =C2=A0 =C2=A0Later, Mike
>>      >
>>      >
>>      >
>>      >=C2=A0 =C2=A0 =C2=A0--
>>      >=C2=A0 =C2=A0 =C2=A0Rfced-future mailing list
>>      > Rfced-future@iab.org 
>>     >
>>      > https://www.iab.org/mailman/listinfo/rfced-future
>>     
>>      >=C2=A0 =C2=A0 =C2=A0>     >
>>      >
>>      >
>>
>=20


From nobody Wed Jul  7 16:30:46 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8474A3A1670 for ; Wed,  7 Jul 2021 16:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrM6zlg7Xctk for ; Wed,  7 Jul 2021 16:30:39 -0700 (PDT)
Received: from hans.rg.net (hans.rg.net [IPv6:2001:418:1::42]) by ietfa.amsl.com (Postfix) with ESMTP id F00D63A166E for ; Wed,  7 Jul 2021 16:30:35 -0700 (PDT)
Received: from smtpclient.apple ([IPv6:2601:1c0:cb00:5dd1:cdca:2e9e:95ac:1afb]) (authenticated bits=0) by hans.rg.net (8.16.1/8.16.1) with ESMTPSA id 167NUVQF042619 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Wed, 7 Jul 2021 23:30:31 GMT (envelope-from llynch@civil-tongue.net)
X-Authentication-Warning: hans.rg.net: Host [IPv6:2601:1c0:cb00:5dd1:cdca:2e9e:95ac:1afb] claimed to be smtpclient.apple
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Lucy Lynch 
In-Reply-To: <29e09ae1-3892-57f4-fe8e-305eca08be04@gmail.com>
Date: Wed, 7 Jul 2021 16:30:25 -0700
Cc: "Joel M. Halpern" , Eric Rescorla , rfced-future@iab.org
Message-Id: <7C658177-8283-49ED-9650-0B0E93995BE4@civil-tongue.net>
References: <29e09ae1-3892-57f4-fe8e-305eca08be04@gmail.com>
To: Brian E Carpenter 
X-Mailer: iPad Mail (18F72)
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 23:30:45 -0000

> On Jul 7, 2021, at 3:08 PM, Brian E Carpenter  wrote:
>=20
> =EF=BB=BFOn 08-Jul-21 09:35, Joel M. Halpern wrote:
>> Do you think we need to include a sentence or two in the document saying=20=

>> that the chairs are required to follow the rough consensus of the=20
>> working group?   And further that in process matters the RSAB is=20
>> requried to respect the rough consensus of the working group?    If that=20=

>> will help get this issue unstuck, I am all for it.
>=20
> That makes sense to me.
>=20

This may be a tiny corner case but=E2=80=A6 what if the participants of a do=
minate stream determine the participant(s) of a smaller stream to be in the r=
ough. What protects stream integrity?  =20

>   Brian
>=20
>>=20
>> Yours,
>> Joel
>>=20
>>> On 7/7/2021 4:28 PM, Eric Rescorla wrote:
>>>=20
>>>=20
>>> On Wed, Jul 7, 2021 at 11:34 AM Joel M. Halpern >> > wrote:
>>>=20
>>>    I think I am missing something in your reasoning EKR.
>>>=20
>>>    We are discussing the case where the RSWG chairs are not advancing
>>>    something in the presence of a claimed rough consensus in support of
>>>    that thing.
>>>=20
>>>    And you are objecting to the RSAB being able to "force the WG to
>>>    advance
>>>    ideas it thinks are good even if the RSWG does not."
>>>=20
>>>    if there is rough consensus for the idea, then the RSWG thinks the=20=

> idea
>>>    is good, even if the chairs do not.  I believe the chairs should lose=

>>>    that fight.
>>>=20
>>>=20
>>> I'm generally fairly sympathetic to this position, though I would note=20=

>=20
>>> that in
>>> the IETF the Chair's role seems a bit muddled here. See especially RFC=20=

>=20
>>> 4858 S 3.1,
>>> which I think implies that the chairs do have some substantive=20
>>> responsibility for
>>> document quality, not just procedural responsibilities.
>>>=20
>>>=20
>>>    The other alternative is that there is not rough consensus for the
>>>    idea,
>>>    but the RSAB claims there is.  That would seem to be subject to the
>>>    already agreed rules for appealing RSAB actions.  Because in that
>>>    situation the RSAB would not be following the process.
>>>=20
>>>=20
>>>    Why is that not sufficient?
>>>=20
>>>=20
>>> Well, it's actually not clear to me that this *would* violate the=20
>>> process, but perhaps
>>> all that's needed is some sharpening of the text, as Eliot suggests.
>>>=20
>>> -Ekr
>>>=20
>>>    Yours,
>>>    Joel
>>>=20
>>>    On 7/7/2021 1:28 PM, Eric Rescorla wrote:
>>>>=20
>>>>=20
>>>> On Tue, Jul 6, 2021 at 9:59 PM Michael StJohns
>>>    
>>>> >>
>>>    wrote:
>>>>=20
>>>>      On 7/7/2021 12:24 AM, Brian E Carpenter wrote:
>>>>>>      Hmmm.  Really?  The IESG or=20
> the IAB getting into
>>>    giving advice and
>>>>>>      opinions on how the RSWG works seems to be=20
> an involvement
>>>    we have been
>>>>>>      avoiding.  
>>>>>      True. But in any case, firing them is the ultimate sanction
>>>    (just as a
>>>>>      recall in the IETF process is the ultimate sanction). As
>>>    long as we have
>>>>>      firing as an option, "advise, admonish, express serious
>>>    concerns" will
>>>>>      happen anyway, behind the scenes if not in public. I don't
>>>    think we need
>>>>>      to write that down, because it would just happen if things
>>>    went wrong.
>>>>>=20
>>>>>          Brian
>>>>>=20
>>>>=20
>>>>      The question to which I keep returning:   To whom is the RSWG
>>>>      accountable too if not the RSAB?    It's certainly not
>>>    accountable
>>>>      to the community, even though it's made up of various
>>>    permutations
>>>>      (over time) of the members of the community.  About all the
>>>>      community could do with a broken WG is to rerun the process we're
>>>>      currently doing and restructure yet again.  That seems both like
>>>>      overkill and a bad model.
>>>>=20
>>>> Well, I do think that it's *accountable* to the community but
>>>    needs the
>>>> consent of the RSAB.
>>>>=20
>>>>      The WG chairs can be replaced, but there is no equivalent
>>>    recourse
>>>>      for participants proposing and approving harmful proposals or for
>>>>      that matter sitting on their hands and not proposing and creating
>>>>      necessary documents.   And now it sounds like EKR et al (sorry to
>>>>      single you out, but yours is the most recent=20
> push against RSAB
>>>>      checks and balances) are looking for a model=20
> where the RSAB
>>>    can only
>>>>      push back on processes and not bad documents=20
> or ideas. Or not
>>>    even
>>>>      that with the proposal to eliminate appeals from RSWG actions.
>>>>=20
>>>> I just want to clarify that I am not arguing that that the RSAB
>>>    should
>>>> not be able to push back on bad documents or ideas. What I'm
>>>    saying is
>>>> that the RSAB should not be able to force the WG to advance ideas it
>>>> thinks are good even if the RSWG does not.
>>>>=20
>>>> -Ekr
>>>>=20
>>>>=20
>>>>      I know who all of the RSAB members will be -=20
> not the individuals,
>>>>      but their chains of authority and responsibility stemming
>>>    from their
>>>>      positions and from their organizations. =20
> I'm less sure of the
>>>    RSWG
>>>>      chairs.   The rest of the crowd has no agreed upon individual
>>>>      responsibilities, but gets ultimate authority?  This model
>>>    seems to
>>>>      be moving to less and less of a good balance=20
> of authority and
>>>>      responsibility the further we go.
>>>>=20
>>>>      Later, Mike
>>>>=20
>>>>=20
>>>>=20
>>>>      --
>>>>      Rfced-future mailing list
>>>> Rfced-future@iab.org 
>>>    >
>>>> https://www.iab.org/mailman/listinfo/rfced-future
>>>    
>>>>      >>    >
>>>>=20
>>>>=20
>>>=20
>>=20
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>=20


From nobody Wed Jul  7 16:35:51 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E353E3A16D4 for ; Wed,  7 Jul 2021 16:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.136
X-Spam-Level: 
X-Spam-Status: No, score=-3.136 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.338, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nMXpplDepH5Z for ; Wed,  7 Jul 2021 16:35:45 -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 04BC33A16CD for ; Wed,  7 Jul 2021 16:35:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GKwlh2n9wz1nsR1; Wed,  7 Jul 2021 16:35:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1625700944; bh=zSfZTqHHPHAZ9csl0AxSQhoEEuVpCrIHngbgHkmt3qI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=S0BvQGjuJL2PxMbQDrI0MxDRVUUCCBjOwXcyn6dnfj6N2rMV2tTo1ANFpASo0gcE7 XnLu4bq8yr2vemOWZXWO3nH5vNEr3yYncGrJjQgPsUAo1OsbihTH0n1rgT6o8Ctoxi 2aJ/eHLQ3V/LgfCeC+QpJK+M0aTIauK0Ixeo84FY=
X-Quarantine-ID: 
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 4GKwlg4Y3fz1ns43; Wed,  7 Jul 2021 16:35:43 -0700 (PDT)
To: Lucy Lynch 
Cc: "Joel M. Halpern" , Eric Rescorla , rfced-future@iab.org
References: <29e09ae1-3892-57f4-fe8e-305eca08be04@gmail.com> <7C658177-8283-49ED-9650-0B0E93995BE4@civil-tongue.net>
From: "Joel M. Halpern" 
Message-ID: <2eeace98-6b08-db26-ce22-4e4baaf6dd20@joelhalpern.com>
Date: Wed, 7 Jul 2021 19:35:42 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <7C658177-8283-49ED-9650-0B0E93995BE4@civil-tongue.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Jul 2021 23:35:50 -0000

That is why I suggested the wording that the RSAB respects the RSWG 
rough consensus for procedural matters.  That still leaves the RSAB the 
right to raise the content objections taht we have agreed to.

At least, I hope I have split that hair properly.

Yours,
Joel

On 7/7/2021 7:30 PM, Lucy Lynch wrote:
> 
> 
>> On Jul 7, 2021, at 3:08 PM, Brian E Carpenter  wrote:
>>
>> On 08-Jul-21 09:35, Joel M. Halpern wrote:
>>> Do you think we need to include a sentence or two in the document saying
>>> that the chairs are required to follow the rough consensus of the
>>> working group?   And further that in process matters the RSAB is
>>> requried to respect the rough consensus of the working group?    If that
>>> will help get this issue unstuck, I am all for it.
>>
>> That makes sense to me.
>>
> 
> This may be a tiny corner case but… what if the participants of a dominate stream determine the participant(s) of a smaller stream to be in the rough. What protects stream integrity?
> 
>>    Brian
>>
>>>
>>> Yours,
>>> Joel
>>>
>>>> On 7/7/2021 4:28 PM, Eric Rescorla wrote:
>>>>
>>>>
>>>> On Wed, Jul 7, 2021 at 11:34 AM Joel M. Halpern >>> > wrote:
>>>>
>>>>     I think I am missing something in your reasoning EKR.
>>>>
>>>>     We are discussing the case where the RSWG chairs are not advancing
>>>>     something in the presence of a claimed rough consensus in support of
>>>>     that thing.
>>>>
>>>>     And you are objecting to the RSAB being able to "force the WG to
>>>>     advance
>>>>     ideas it thinks are good even if the RSWG does not."
>>>>
>>>>     if there is rough consensus for the idea, then the RSWG thinks the
>> idea
>>>>     is good, even if the chairs do not.  I believe the chairs should lose
>>>>     that fight.
>>>>
>>>>
>>>> I'm generally fairly sympathetic to this position, though I would note
>>
>>>> that in
>>>> the IETF the Chair's role seems a bit muddled here. See especially RFC
>>
>>>> 4858 S 3.1,
>>>> which I think implies that the chairs do have some substantive
>>>> responsibility for
>>>> document quality, not just procedural responsibilities.
>>>>
>>>>
>>>>     The other alternative is that there is not rough consensus for the
>>>>     idea,
>>>>     but the RSAB claims there is.  That would seem to be subject to the
>>>>     already agreed rules for appealing RSAB actions.  Because in that
>>>>     situation the RSAB would not be following the process.
>>>>
>>>>
>>>>     Why is that not sufficient?
>>>>
>>>>
>>>> Well, it's actually not clear to me that this *would* violate the
>>>> process, but perhaps
>>>> all that's needed is some sharpening of the text, as Eliot suggests.
>>>>
>>>> -Ekr
>>>>
>>>>     Yours,
>>>>     Joel
>>>>
>>>>     On 7/7/2021 1:28 PM, Eric Rescorla wrote:
>>>>>
>>>>>
>>>>> On Tue, Jul 6, 2021 at 9:59 PM Michael StJohns
>>>>     
>>>>> >>
>>>>     wrote:
>>>>>
>>>>>       On 7/7/2021 12:24 AM, Brian E Carpenter wrote:
>>>>>>>       Hmmm.  Really?  The IESG or
>> the IAB getting into
>>>>     giving advice and
>>>>>>>       opinions on how the RSWG works seems to be
>> an involvement
>>>>     we have been
>>>>>>>       avoiding.  
>>>>>>       True. But in any case, firing them is the ultimate sanction
>>>>     (just as a
>>>>>>       recall in the IETF process is the ultimate sanction). As
>>>>     long as we have
>>>>>>       firing as an option, "advise, admonish, express serious
>>>>     concerns" will
>>>>>>       happen anyway, behind the scenes if not in public. I don't
>>>>     think we need
>>>>>>       to write that down, because it would just happen if things
>>>>     went wrong.
>>>>>>
>>>>>>           Brian
>>>>>>
>>>>>
>>>>>       The question to which I keep returning:   To whom is the RSWG
>>>>>       accountable too if not the RSAB?    It's certainly not
>>>>     accountable
>>>>>       to the community, even though it's made up of various
>>>>     permutations
>>>>>       (over time) of the members of the community.  About all the
>>>>>       community could do with a broken WG is to rerun the process we're
>>>>>       currently doing and restructure yet again.  That seems both like
>>>>>       overkill and a bad model.
>>>>>
>>>>> Well, I do think that it's *accountable* to the community but
>>>>     needs the
>>>>> consent of the RSAB.
>>>>>
>>>>>       The WG chairs can be replaced, but there is no equivalent
>>>>     recourse
>>>>>       for participants proposing and approving harmful proposals or for
>>>>>       that matter sitting on their hands and not proposing and creating
>>>>>       necessary documents.   And now it sounds like EKR et al (sorry to
>>>>>       single you out, but yours is the most recent
>> push against RSAB
>>>>>       checks and balances) are looking for a model
>> where the RSAB
>>>>     can only
>>>>>       push back on processes and not bad documents
>> or ideas. Or not
>>>>     even
>>>>>       that with the proposal to eliminate appeals from RSWG actions.
>>>>>
>>>>> I just want to clarify that I am not arguing that that the RSAB
>>>>     should
>>>>> not be able to push back on bad documents or ideas. What I'm
>>>>     saying is
>>>>> that the RSAB should not be able to force the WG to advance ideas it
>>>>> thinks are good even if the RSWG does not.
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>       I know who all of the RSAB members will be -
>> not the individuals,
>>>>>       but their chains of authority and responsibility stemming
>>>>     from their
>>>>>       positions and from their organizations.
>> I'm less sure of the
>>>>     RSWG
>>>>>       chairs.   The rest of the crowd has no agreed upon individual
>>>>>       responsibilities, but gets ultimate authority?  This model
>>>>     seems to
>>>>>       be moving to less and less of a good balance
>> of authority and
>>>>>       responsibility the further we go.
>>>>>
>>>>>       Later, Mike
>>>>>
>>>>>
>>>>>
>>>>>       --
>>>>>       Rfced-future mailing list
>>>>> Rfced-future@iab.org 
>>>>     >
>>>>> https://www.iab.org/mailman/listinfo/rfced-future
>>>>     
>>>>>       >>>     >
>>>>>
>>>>>
>>>>
>>>
>>
>> -- 
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>>
> 


From nobody Wed Jul  7 18:18:04 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B232A3A1F43 for ; Wed,  7 Jul 2021 18:18:02 -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 vFWyXy1dooc3 for ; Wed,  7 Jul 2021 18:17:57 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 BB1363A1EC9 for ; Wed,  7 Jul 2021 18:17:57 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id k16so6119621ios.10 for ; Wed, 07 Jul 2021 18:17:57 -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=DcUWwaf1dpSIAkO7MBAidOvuHylSxhBTaPM/x8xiNbQ=; b=pDdDOMXk/mY5V3OTuZE3XGHcr6Kae1K4/GuxcBEPG7QMUxUrSqLMswz/v8YvJ/ellu 7PhsoJ8egiTJhkkJK4NnWI2Y1/EIFNQB/4HtBvDHIgiRWSnjcyNBQOr3PV28UQ2UhowK wFJYLNtsO3EmnbSVNw/+BlGaedG+e1PoO1tzGPzyANowikNit8kocgARRbzGwDPPM05e iCFCbZZt6rZgdQMrPmLpv/wuJRC2kAdVRcifak7vmYF1LOX7m0WtUoYZ6p1gz/GqUFZh vaayQ++4HFCFydxA5V9HZF6qiKFDTSuJ2m5xRGG8lmJjfx7WzyHaNZtG/EyMfrU5Cs+f qGuA==
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=DcUWwaf1dpSIAkO7MBAidOvuHylSxhBTaPM/x8xiNbQ=; b=VpRAas945RlTOYAXRm+dtsPhsXivld5JavVV9LhIgS4UKZkYrh/TixD+ojr95+yLEn dWarUe1M+MFN2TM2/a80lu6hBxtbzJ81fLgIKFJeMV9oA+gpjWc80jitct34zRPSUhGg omBRwGrL8mOSf6OcLMgNSLf9hSfGzEDchrL1bE6QYV+QfAPQAhZ/jYqjW3zFCabYpath VAfEamhfa3LRtAZYwOovd4idDwd7IfZy/CbGBAOyuxC74OMMZ0IQI1RzYicPH7E+TQQp WkeQ2FPZKTuQ9JVyPGZfPuzcFdyTRamyfiTf+jy2x8t7XpLXIo8+zH7uLla/e15Qv4bz Ohag==
X-Gm-Message-State: AOAM53319bNhDnsNNxfk1VPjzt3eKLHYvVzWxblbAYOSqTvHp+AnT49T PZoM1y5xsXzrUP5Z96UDvKtlmmjBxzZi3G+s4iZBqg==
X-Google-Smtp-Source: ABdhPJy5r3S+9O5eBqc4P5vR9zPtdSbtphvNUTq07nPJ4bMFrV7QFR86sgQHJuMz+uCYE6m2B87/drqECIyC2I+OguM=
X-Received: by 2002:a02:c859:: with SMTP id r25mr24296192jao.17.1625707076323;  Wed, 07 Jul 2021 18:17:56 -0700 (PDT)
MIME-Version: 1.0
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>  <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com>
In-Reply-To: <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com>
From: Eric Rescorla 
Date: Wed, 7 Jul 2021 18:17:20 -0700
Message-ID: 
To: "Joel M. Halpern" 
Cc: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000cb252405c6926c0b"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Jul 2021 01:18:03 -0000

--000000000000cb252405c6926c0b
Content-Type: text/plain; charset="UTF-8"

This seems like an OK resolution to me.

On Wed, Jul 7, 2021 at 2:35 PM Joel M. Halpern  wrote:

> Do you think we need to include a sentence or two in the document saying
> that the chairs are required to follow the rough consensus of the
> working group?   And further that in process matters the RSAB is
> requried to respect the rough consensus of the working group?    If that
> will help get this issue unstuck, I am all for it.
>
> Yours,
> Joel
>
> On 7/7/2021 4:28 PM, Eric Rescorla wrote:
> >
> >
> > On Wed, Jul 7, 2021 at 11:34 AM Joel M. Halpern  > > wrote:
> >
> >     I think I am missing something in your reasoning EKR.
> >
> >     We are discussing the case where the RSWG chairs are not advancing
> >     something in the presence of a claimed rough consensus in support of
> >     that thing.
> >
> >     And you are objecting to the RSAB being able to "force the WG to
> >     advance
> >     ideas it thinks are good even if the RSWG does not."
> >
> >     if there is rough consensus for the idea, then the RSWG thinks the
> idea
> >     is good, even if the chairs do not.  I believe the chairs should lose
> >     that fight.
> >
> >
> > I'm generally fairly sympathetic to this position, though I would note
> > that in
> > the IETF the Chair's role seems a bit muddled here. See especially RFC
> > 4858 S 3.1,
> > which I think implies that the chairs do have some substantive
> > responsibility for
> > document quality, not just procedural responsibilities.
> >
> >
> >     The other alternative is that there is not rough consensus for the
> >     idea,
> >     but the RSAB claims there is.  That would seem to be subject to the
> >     already agreed rules for appealing RSAB actions.  Because in that
> >     situation the RSAB would not be following the process.
> >
> >
> >     Why is that not sufficient?
> >
> >
> > Well, it's actually not clear to me that this *would* violate the
> > process, but perhaps
> > all that's needed is some sharpening of the text, as Eliot suggests.
> >
> > -Ekr
> >
> >     Yours,
> >     Joel
> >
> >     On 7/7/2021 1:28 PM, Eric Rescorla wrote:
> >      >
> >      >
> >      > On Tue, Jul 6, 2021 at 9:59 PM Michael StJohns
> >     
> >      > >>
> >     wrote:
> >      >
> >      >     On 7/7/2021 12:24 AM, Brian E Carpenter wrote:
> >      >>>     Hmmm.  Really?  The IESG or the IAB getting into
> >     giving advice and
> >      >>>     opinions on how the RSWG works seems to be an involvement
> >     we have been
> >      >>>     avoiding.  
> >      >>     True. But in any case, firing them is the ultimate sanction
> >     (just as a
> >      >>     recall in the IETF process is the ultimate sanction). As
> >     long as we have
> >      >>     firing as an option, "advise, admonish, express serious
> >     concerns" will
> >      >>     happen anyway, behind the scenes if not in public. I don't
> >     think we need
> >      >>     to write that down, because it would just happen if things
> >     went wrong.
> >      >>
> >      >>         Brian
> >      >>
> >      >
> >      >     The question to which I keep returning:   To whom is the RSWG
> >      >     accountable too if not the RSAB?    It's certainly not
> >     accountable
> >      >     to the community, even though it's made up of various
> >     permutations
> >      >     (over time) of the members of the community.  About all the
> >      >     community could do with a broken WG is to rerun the process
> we're
> >      >     currently doing and restructure yet again.  That seems both
> like
> >      >     overkill and a bad model.
> >      >
> >      > Well, I do think that it's *accountable* to the community but
> >     needs the
> >      > consent of the RSAB.
> >      >
> >      >     The WG chairs can be replaced, but there is no equivalent
> >     recourse
> >      >     for participants proposing and approving harmful proposals or
> for
> >      >     that matter sitting on their hands and not proposing and
> creating
> >      >     necessary documents.   And now it sounds like EKR et al
> (sorry to
> >      >     single you out, but yours is the most recent push against RSAB
> >      >     checks and balances) are looking for a model where the RSAB
> >     can only
> >      >     push back on processes and not bad documents or ideas. Or not
> >     even
> >      >     that with the proposal to eliminate appeals from RSWG actions.
> >      >
> >      > I just want to clarify that I am not arguing that that the RSAB
> >     should
> >      > not be able to push back on bad documents or ideas. What I'm
> >     saying is
> >      > that the RSAB should not be able to force the WG to advance ideas
> it
> >      > thinks are good even if the RSWG does not.
> >      >
> >      > -Ekr
> >      >
> >      >
> >      >     I know who all of the RSAB members will be - not the
> individuals,
> >      >     but their chains of authority and responsibility stemming
> >     from their
> >      >     positions and from their organizations.  I'm less sure of the
> >     RSWG
> >      >     chairs.   The rest of the crowd has no agreed upon individual
> >      >     responsibilities, but gets ultimate authority?  This model
> >     seems to
> >      >     be moving to less and less of a good balance of authority and
> >      >     responsibility the further we go.
> >      >
> >      >     Later, Mike
> >      >
> >      >
> >      >
> >      >     --
> >      >     Rfced-future mailing list
> >      > Rfced-future@iab.org 
> >     >
> >      > https://www.iab.org/mailman/listinfo/rfced-future
> >     
> >      >      >     >
> >      >
> >      >
> >
>

--000000000000cb252405c6926c0b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This seems like an OK resolution to me.

On Wed, Jul 7, =
2021 at 2:35 PM Joel M. Halpern <=
jmh@joelhalpern.com> wrote:
Do you think we need to include a sentence or two in the=
 document saying 

that the chairs are required to follow the rough consensus of the 

working group?=C2=A0 =C2=A0And further that in process matters the RSAB is =


requried to respect the rough consensus of the working group?=C2=A0 =C2=A0 =
If that 

will help get this issue unstuck, I am all for it.



Yours,

Joel



On 7/7/2021 4:28 PM, Eric Rescorla wrote:

> 

> 

> On Wed, Jul 7, 2021 at 11:34 AM Joel M. Halpern <jmh@joelhalpern.com 

> <mailto:jm=
h@joelhalpern.com>> wrote:

> 

>=C2=A0 =C2=A0 =C2=A0I think I am missing something in your reasoning EK=
R.

> 

>=C2=A0 =C2=A0 =C2=A0We are discussing the case where the RSWG chairs ar=
e not advancing

>=C2=A0 =C2=A0 =C2=A0something in the presence of a claimed rough consen=
sus in support of

>=C2=A0 =C2=A0 =C2=A0that thing.

> 

>=C2=A0 =C2=A0 =C2=A0And you are objecting to the RSAB being able to &qu=
ot;force the WG to

>=C2=A0 =C2=A0 =C2=A0advance

>=C2=A0 =C2=A0 =C2=A0ideas it thinks are good even if the RSWG does not.=
"

> 

>=C2=A0 =C2=A0 =C2=A0if there is rough consensus for the idea, then the =
RSWG thinks the idea

>=C2=A0 =C2=A0 =C2=A0is good, even if the chairs do not.=C2=A0 I believe=
 the chairs should lose

>=C2=A0 =C2=A0 =C2=A0that fight.

> 

> 

> I'm generally fairly sympathetic to this position, though I would =
note 

> that in

> the IETF the Chair's role seems a bit muddled here. See especially=
 RFC 

> 4858 S 3.1,

> which I think implies that the chairs do have some substantive 

> responsibility for

> document quality, not just procedural responsibilities.

> 

> 

>=C2=A0 =C2=A0 =C2=A0The other alternative is that there is not rough co=
nsensus for the

>=C2=A0 =C2=A0 =C2=A0idea,

>=C2=A0 =C2=A0 =C2=A0but the RSAB claims there is.=C2=A0 That would seem=
 to be subject to the

>=C2=A0 =C2=A0 =C2=A0already agreed rules for appealing RSAB actions.=C2=
=A0 Because in that

>=C2=A0 =C2=A0 =C2=A0situation the RSAB would not be following the proce=
ss.

> 

> 

>=C2=A0 =C2=A0 =C2=A0Why is that not sufficient?

> 

> 

> Well, it's actually not clear to me that this *would* violate the =


> process, but perhaps

> all that's needed is some sharpening of the text, as Eliot suggest=
s.

> 

> -Ekr

> 

>=C2=A0 =C2=A0 =C2=A0Yours,

>=C2=A0 =C2=A0 =C2=A0Joel

> 

>=C2=A0 =C2=A0 =C2=A0On 7/7/2021 1:28 PM, Eric Rescorla wrote:

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 > On Tue, Jul 6, 2021 at 9:59 PM Michael StJohn=
s

>=C2=A0 =C2=A0 =C2=A0<msj@nthpermutation.com <mailto:msj@nthpermutation.com>

>=C2=A0 =C2=A0 =C2=A0 > <mailto:msj@nthpermutation.com <mailto:msj@nthpermutation.com=
>>>

>=C2=A0 =C2=A0 =C2=A0wrote:

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 7/7/2021 12:24 AM, Bria=
n E Carpenter wrote:

>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0<jmh>Hmmm.=
=C2=A0 Really?=C2=A0 The IESG or the IAB getting into

>=C2=A0 =C2=A0 =C2=A0giving advice and

>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0opinions on how th=
e RSWG works seems to be an involvement

>=C2=A0 =C2=A0 =C2=A0we have been

>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0avoiding.=C2=A0 &l=
t;/jmh>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0True. But in any case,=
 firing them is the ultimate sanction

>=C2=A0 =C2=A0 =C2=A0(just as a

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0recall in the IETF pro=
cess is the ultimate sanction). As

>=C2=A0 =C2=A0 =C2=A0long as we have

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0firing as an option, &=
quot;advise, admonish, express serious

>=C2=A0 =C2=A0 =C2=A0concerns" will

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0happen anyway, behind =
the scenes if not in public. I don't

>=C2=A0 =C2=A0 =C2=A0think we need

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0to write that down, be=
cause it would just happen if things

>=C2=A0 =C2=A0 =C2=A0went wrong.

>=C2=A0 =C2=A0 =C2=A0 >>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brian
>=C2=A0 =C2=A0 =C2=A0 >>

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The question to which I ke=
ep returning:=C2=A0=C2=A0 To whom is the RSWG

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0accountable too if not the=
 RSAB?=C2=A0=C2=A0=C2=A0 It's certainly not

>=C2=A0 =C2=A0 =C2=A0accountable

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to the community, even tho=
ugh it's made up of various

>=C2=A0 =C2=A0 =C2=A0permutations

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0(over time) of the members=
 of the community.=C2=A0 About all the

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0community could do with a =
broken WG is to rerun the process we're

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0currently doing and restru=
cture yet again.=C2=A0 That seems both like

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0overkill and a bad model.<=
br>
>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 > Well, I do think that it's *accountable* =
to the community but

>=C2=A0 =C2=A0 =C2=A0needs the

>=C2=A0 =C2=A0 =C2=A0 > consent of the RSAB.

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The WG chairs can be repla=
ced, but there is no equivalent

>=C2=A0 =C2=A0 =C2=A0recourse

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0for participants proposing=
 and approving harmful proposals or for

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0that matter sitting on the=
ir hands and not proposing and creating

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0necessary documents.=C2=A0=
=C2=A0 And now it sounds like EKR et al (sorry to

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0single you out, but yours =
is the most recent push against RSAB

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0checks and balances) are l=
ooking for a model where the RSAB

>=C2=A0 =C2=A0 =C2=A0can only

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0push back on processes and=
 not bad documents or ideas. Or not

>=C2=A0 =C2=A0 =C2=A0even

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0that with the proposal to =
eliminate appeals from RSWG actions.

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 > I just want to clarify that I am not arguing =
that that the RSAB

>=C2=A0 =C2=A0 =C2=A0should

>=C2=A0 =C2=A0 =C2=A0 > not be able to push back on bad documents or =
ideas. What I'm

>=C2=A0 =C2=A0 =C2=A0saying is

>=C2=A0 =C2=A0 =C2=A0 > that the RSAB should not be able to force the=
 WG to advance ideas it

>=C2=A0 =C2=A0 =C2=A0 > thinks are good even if the RSWG does not.
>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 > -Ekr

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I know who all of the RSAB=
 members will be - not the individuals,

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0but their chains of author=
ity and responsibility stemming

>=C2=A0 =C2=A0 =C2=A0from their

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0positions and from their o=
rganizations.=C2=A0 I'm less sure of the

>=C2=A0 =C2=A0 =C2=A0RSWG

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0chairs.=C2=A0=C2=A0 The re=
st of the crowd has no agreed upon individual

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0responsibilities, but gets=
 ultimate authority?=C2=A0 This model

>=C2=A0 =C2=A0 =C2=A0seems to

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0be moving to less and less=
 of a good balance of authority and

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0responsibility the further=
 we go.

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Later, Mike

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0--

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Rfced-future mailing list<=
br>
>=C2=A0 =C2=A0 =C2=A0 > Rfced-future@iab.org <mailto:Rfced-future@iab.org>

>=C2=A0 =C2=A0 =C2=A0<mailto:Rfced-future@iab.org <mailto:Rfced-future@iab.org>>

>=C2=A0 =C2=A0 =C2=A0 > https://www.iab.org/m=
ailman/listinfo/rfced-future

>=C2=A0 =C2=A0 =C2=A0<https://www.iab.org/mai=
lman/listinfo/rfced-future>

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<https://www.iab.org/mailman/listinfo/rfced-future

>=C2=A0 =C2=A0 =C2=A0<https://www.iab.org/mai=
lman/listinfo/rfced-future>>

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >

> 




--000000000000cb252405c6926c0b--


From nobody Wed Jul  7 23:13:31 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684D33A13AC for ; Wed,  7 Jul 2021 23:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0dUyWtkVJ6U for ; Wed,  7 Jul 2021 23:13:23 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 6426D3A13AA for ; Wed,  7 Jul 2021 23:13:23 -0700 (PDT)
Received: from [IPv6:2a02:aa15:4101:2a80:6c39:6e3c:358a:bc63] ([IPv6:2a02:aa15:4101:2a80:6c39:6e3c:358a:bc63]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1686DJvR127986 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 8 Jul 2021 08:13:19 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625724800; bh=bePzpQOGZEE7jPp0GfooUNhZxfJl/6z7Dm06U8BSPbI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Oq6e4AhuBeywKux62SGeLIXKisKnjgdbrOtxFmSxxtv5BpuSnzVfpLKnB8j/tsoZb k878kNqssevyJFMtNRWAhLe03VrZJVwtA7cxw8yGOEmHG4IkoM0C4RIcssU6PGoSKr kfiompGkta8ni6Dj1cTRED8sj7X8bYsCRUgbW0MA=
To: Eric Rescorla , "Joel M. Halpern" 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>  <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com> 
From: Eliot Lear 
Message-ID: 
Date: Thu, 8 Jul 2021 08:13:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l9ioChhbv5RV4A6fgDx1Lh05wO6F3bGKY"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Jul 2021 06:13:29 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--l9ioChhbv5RV4A6fgDx1Lh05wO6F3bGKY
Content-Type: multipart/mixed; boundary="bwhi1t80rcidV7FzIwWeddbK2bPwd6inR";
 protected-headers="v1"
From: Eliot Lear 
To: Eric Rescorla , "Joel M. Halpern" 
Cc: rfced-future@iab.org
Message-ID: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch>
 <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk>
 <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch>
 <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>
 
 <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>
 
 
 <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>
 
 <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>
 
 
 <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com>
 <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>
 
 <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>
 
 <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com>
 
In-Reply-To: 

--bwhi1t80rcidV7FzIwWeddbK2bPwd6inR
Content-Type: multipart/alternative;
 boundary="------------5142EA0588EDA36A281E6FD6"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------5142EA0588EDA36A281E6FD6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: base64

V2UgcmVhbGx5IG5vdyBtdXN0IHJldHVybiB0byB0aGUgYXBwZWFscyBwcm9jZXNzIGZyb20g
dGhlIFJTQUIuIEknbSAKZ29pbmcgdG8gc3RhcnQgdGhhdCBkaXNjdXNzaW9uIGluIGEgZGlm
ZmVyZW50IHRocmVhZC4KCkVsaW90CgpPbiAwOC4wNy4yMSAwMzoxNywgRXJpYyBSZXNjb3Js
YSB3cm90ZToKPiBUaGlzIHNlZW1zIGxpa2UgYW4gT0sgcmVzb2x1dGlvbiB0byBtZS4KPgo+
IE9uIFdlZCwgSnVsIDcsIDIwMjEgYXQgMjozNSBQTSBKb2VsIE0uIEhhbHBlcm4gPGptaEBq
b2VsaGFscGVybi5jb20gCj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4gd3JvdGU6
Cj4KPiAgICAgRG8geW91IHRoaW5rIHdlIG5lZWQgdG8gaW5jbHVkZSBhIHNlbnRlbmNlIG9y
IHR3byBpbiB0aGUgZG9jdW1lbnQKPiAgICAgc2F5aW5nCj4gICAgIHRoYXQgdGhlIGNoYWly
cyBhcmUgcmVxdWlyZWQgdG8gZm9sbG93IHRoZSByb3VnaCBjb25zZW5zdXMgb2YgdGhlCj4g
ICAgIHdvcmtpbmcgZ3JvdXA/wqAgwqBBbmQgZnVydGhlciB0aGF0IGluIHByb2Nlc3MgbWF0
dGVycyB0aGUgUlNBQiBpcwo+ICAgICByZXF1cmllZCB0byByZXNwZWN0IHRoZSByb3VnaCBj
b25zZW5zdXMgb2YgdGhlIHdvcmtpbmcgZ3JvdXA/IMKgIElmCj4gICAgIHRoYXQKPiAgICAg
d2lsbCBoZWxwIGdldCB0aGlzIGlzc3VlIHVuc3R1Y2ssIEkgYW0gYWxsIGZvciBpdC4KPgo+
ICAgICBZb3VycywKPiAgICAgSm9lbAo+Cj4gICAgIE9uIDcvNy8yMDIxIDQ6MjggUE0sIEVy
aWMgUmVzY29ybGEgd3JvdGU6Cj4gICAgID4KPiAgICAgPgo+ICAgICA+IE9uIFdlZCwgSnVs
IDcsIDIwMjEgYXQgMTE6MzQgQU0gSm9lbCBNLiBIYWxwZXJuCj4gICAgIDxqbWhAam9lbGhh
bHBlcm4uY29tIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4KPiAgICAgPiA8bWFpbHRv
OmptaEBqb2VsaGFscGVybi5jb20gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4+IHdy
b3RlOgo+ICAgICA+Cj4gICAgID7CoCDCoCDCoEkgdGhpbmsgSSBhbSBtaXNzaW5nIHNvbWV0
aGluZyBpbiB5b3VyIHJlYXNvbmluZyBFS1IuCj4gICAgID4KPiAgICAgPsKgIMKgIMKgV2Ug
YXJlIGRpc2N1c3NpbmcgdGhlIGNhc2Ugd2hlcmUgdGhlIFJTV0cgY2hhaXJzIGFyZSBub3QK
PiAgICAgYWR2YW5jaW5nCj4gICAgID7CoCDCoCDCoHNvbWV0aGluZyBpbiB0aGUgcHJlc2Vu
Y2Ugb2YgYSBjbGFpbWVkIHJvdWdoIGNvbnNlbnN1cyBpbgo+ICAgICBzdXBwb3J0IG9mCj4g
ICAgID7CoCDCoCDCoHRoYXQgdGhpbmcuCj4gICAgID4KPiAgICAgPsKgIMKgIMKgQW5kIHlv
dSBhcmUgb2JqZWN0aW5nIHRvIHRoZSBSU0FCIGJlaW5nIGFibGUgdG8gImZvcmNlIHRoZSBX
RyB0bwo+ICAgICA+wqAgwqAgwqBhZHZhbmNlCj4gICAgID7CoCDCoCDCoGlkZWFzIGl0IHRo
aW5rcyBhcmUgZ29vZCBldmVuIGlmIHRoZSBSU1dHIGRvZXMgbm90LiIKPiAgICAgPgo+ICAg
ICA+wqAgwqAgwqBpZiB0aGVyZSBpcyByb3VnaCBjb25zZW5zdXMgZm9yIHRoZSBpZGVhLCB0
aGVuIHRoZSBSU1dHCj4gICAgIHRoaW5rcyB0aGUgaWRlYQo+ICAgICA+wqAgwqAgwqBpcyBn
b29kLCBldmVuIGlmIHRoZSBjaGFpcnMgZG8gbm90LsKgIEkgYmVsaWV2ZSB0aGUgY2hhaXJz
Cj4gICAgIHNob3VsZCBsb3NlCj4gICAgID7CoCDCoCDCoHRoYXQgZmlnaHQuCj4gICAgID4K
PiAgICAgPgo+ICAgICA+IEknbSBnZW5lcmFsbHkgZmFpcmx5IHN5bXBhdGhldGljIHRvIHRo
aXMgcG9zaXRpb24sIHRob3VnaCBJCj4gICAgIHdvdWxkIG5vdGUKPiAgICAgPiB0aGF0IGlu
Cj4gICAgID4gdGhlIElFVEYgdGhlIENoYWlyJ3Mgcm9sZSBzZWVtcyBhIGJpdCBtdWRkbGVk
IGhlcmUuIFNlZQo+ICAgICBlc3BlY2lhbGx5IFJGQwo+ICAgICA+IDQ4NTggUyAzLjEsCj4g
ICAgID4gd2hpY2ggSSB0aGluayBpbXBsaWVzIHRoYXQgdGhlIGNoYWlycyBkbyBoYXZlIHNv
bWUgc3Vic3RhbnRpdmUKPiAgICAgPiByZXNwb25zaWJpbGl0eSBmb3IKPiAgICAgPiBkb2N1
bWVudCBxdWFsaXR5LCBub3QganVzdCBwcm9jZWR1cmFsIHJlc3BvbnNpYmlsaXRpZXMuCj4g
ICAgID4KPiAgICAgPgo+ICAgICA+wqAgwqAgwqBUaGUgb3RoZXIgYWx0ZXJuYXRpdmUgaXMg
dGhhdCB0aGVyZSBpcyBub3Qgcm91Z2ggY29uc2Vuc3VzCj4gICAgIGZvciB0aGUKPiAgICAg
PsKgIMKgIMKgaWRlYSwKPiAgICAgPsKgIMKgIMKgYnV0IHRoZSBSU0FCIGNsYWltcyB0aGVy
ZSBpcy7CoCBUaGF0IHdvdWxkIHNlZW0gdG8gYmUgc3ViamVjdAo+ICAgICB0byB0aGUKPiAg
ICAgPsKgIMKgIMKgYWxyZWFkeSBhZ3JlZWQgcnVsZXMgZm9yIGFwcGVhbGluZyBSU0FCIGFj
dGlvbnMuIEJlY2F1c2UgaW4gdGhhdAo+ICAgICA+wqAgwqAgwqBzaXR1YXRpb24gdGhlIFJT
QUIgd291bGQgbm90IGJlIGZvbGxvd2luZyB0aGUgcHJvY2Vzcy4KPiAgICAgPgo+ICAgICA+
Cj4gICAgID7CoCDCoCDCoFdoeSBpcyB0aGF0IG5vdCBzdWZmaWNpZW50Pwo+ICAgICA+Cj4g
ICAgID4KPiAgICAgPiBXZWxsLCBpdCdzIGFjdHVhbGx5IG5vdCBjbGVhciB0byBtZSB0aGF0
IHRoaXMgKndvdWxkKiB2aW9sYXRlIHRoZQo+ICAgICA+IHByb2Nlc3MsIGJ1dCBwZXJoYXBz
Cj4gICAgID4gYWxsIHRoYXQncyBuZWVkZWQgaXMgc29tZSBzaGFycGVuaW5nIG9mIHRoZSB0
ZXh0LCBhcyBFbGlvdCBzdWdnZXN0cy4KPiAgICAgPgo+ICAgICA+IC1Fa3IKPiAgICAgPgo+
ICAgICA+wqAgwqAgwqBZb3VycywKPiAgICAgPsKgIMKgIMKgSm9lbAo+ICAgICA+Cj4gICAg
ID7CoCDCoCDCoE9uIDcvNy8yMDIxIDE6MjggUE0sIEVyaWMgUmVzY29ybGEgd3JvdGU6Cj4g
ICAgID7CoCDCoCDCoCA+Cj4gICAgID7CoCDCoCDCoCA+Cj4gICAgID7CoCDCoCDCoCA+IE9u
IFR1ZSwgSnVsIDYsIDIwMjEgYXQgOTo1OSBQTSBNaWNoYWVsIFN0Sm9obnMKPiAgICAgPsKg
IMKgIMKgPG1zakBudGhwZXJtdXRhdGlvbi5jb20gPG1haWx0bzptc2pAbnRocGVybXV0YXRp
b24uY29tPgo+ICAgICA8bWFpbHRvOm1zakBudGhwZXJtdXRhdGlvbi5jb20gPG1haWx0bzpt
c2pAbnRocGVybXV0YXRpb24uY29tPj4KPiAgICAgPsKgIMKgIMKgID4gPG1haWx0bzptc2pA
bnRocGVybXV0YXRpb24uY29tCj4gICAgIDxtYWlsdG86bXNqQG50aHBlcm11dGF0aW9uLmNv
bT4gPG1haWx0bzptc2pAbnRocGVybXV0YXRpb24uY29tCj4gICAgIDxtYWlsdG86bXNqQG50
aHBlcm11dGF0aW9uLmNvbT4+Pj4KPiAgICAgPsKgIMKgIMKgd3JvdGU6Cj4gICAgID7CoCDC
oCDCoCA+Cj4gICAgID7CoCDCoCDCoCA+wqAgwqAgwqBPbiA3LzcvMjAyMSAxMjoyNCBBTSwg
QnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6Cj4gICAgID7CoCDCoCDCoCA+Pj7CoCDCoCDCoDxq
bWg+SG1tbS7CoCBSZWFsbHk/wqAgVGhlIElFU0cgb3IgdGhlIElBQiBnZXR0aW5nIGludG8K
PiAgICAgPsKgIMKgIMKgZ2l2aW5nIGFkdmljZSBhbmQKPiAgICAgPsKgIMKgIMKgID4+PsKg
IMKgIMKgb3BpbmlvbnMgb24gaG93IHRoZSBSU1dHIHdvcmtzIHNlZW1zIHRvIGJlIGFuCj4g
ICAgIGludm9sdmVtZW50Cj4gICAgID7CoCDCoCDCoHdlIGhhdmUgYmVlbgo+ICAgICA+wqAg
wqAgwqAgPj4+wqAgwqAgwqBhdm9pZGluZy7CoCA8L2ptaD4KPiAgICAgPsKgIMKgIMKgID4+
wqAgwqAgwqBUcnVlLiBCdXQgaW4gYW55IGNhc2UsIGZpcmluZyB0aGVtIGlzIHRoZSB1bHRp
bWF0ZQo+ICAgICBzYW5jdGlvbgo+ICAgICA+wqAgwqAgwqAoanVzdCBhcyBhCj4gICAgID7C
oCDCoCDCoCA+PsKgIMKgIMKgcmVjYWxsIGluIHRoZSBJRVRGIHByb2Nlc3MgaXMgdGhlIHVs
dGltYXRlIHNhbmN0aW9uKS4gQXMKPiAgICAgPsKgIMKgIMKgbG9uZyBhcyB3ZSBoYXZlCj4g
ICAgID7CoCDCoCDCoCA+PsKgIMKgIMKgZmlyaW5nIGFzIGFuIG9wdGlvbiwgImFkdmlzZSwg
YWRtb25pc2gsIGV4cHJlc3Mgc2VyaW91cwo+ICAgICA+wqAgwqAgwqBjb25jZXJucyIgd2ls
bAo+ICAgICA+wqAgwqAgwqAgPj7CoCDCoCDCoGhhcHBlbiBhbnl3YXksIGJlaGluZCB0aGUg
c2NlbmVzIGlmIG5vdCBpbiBwdWJsaWMuIEkKPiAgICAgZG9uJ3QKPiAgICAgPsKgIMKgIMKg
dGhpbmsgd2UgbmVlZAo+ICAgICA+wqAgwqAgwqAgPj7CoCDCoCDCoHRvIHdyaXRlIHRoYXQg
ZG93biwgYmVjYXVzZSBpdCB3b3VsZCBqdXN0IGhhcHBlbiBpZgo+ICAgICB0aGluZ3MKPiAg
ICAgPsKgIMKgIMKgd2VudCB3cm9uZy4KPiAgICAgPsKgIMKgIMKgID4+Cj4gICAgID7CoCDC
oCDCoCA+PsKgIMKgIMKgIMKgIMKgQnJpYW4KPiAgICAgPsKgIMKgIMKgID4+Cj4gICAgID7C
oCDCoCDCoCA+Cj4gICAgID7CoCDCoCDCoCA+wqAgwqAgwqBUaGUgcXVlc3Rpb24gdG8gd2hp
Y2ggSSBrZWVwIHJldHVybmluZzogVG8gd2hvbSBpcwo+ICAgICB0aGUgUlNXRwo+ICAgICA+
wqAgwqAgwqAgPsKgIMKgIMKgYWNjb3VudGFibGUgdG9vIGlmIG5vdCB0aGUgUlNBQj/CoMKg
wqAgSXQncyBjZXJ0YWlubHkgbm90Cj4gICAgID7CoCDCoCDCoGFjY291bnRhYmxlCj4gICAg
ID7CoCDCoCDCoCA+wqAgwqAgwqB0byB0aGUgY29tbXVuaXR5LCBldmVuIHRob3VnaCBpdCdz
IG1hZGUgdXAgb2YgdmFyaW91cwo+ICAgICA+wqAgwqAgwqBwZXJtdXRhdGlvbnMKPiAgICAg
PsKgIMKgIMKgID7CoCDCoCDCoChvdmVyIHRpbWUpIG9mIHRoZSBtZW1iZXJzIG9mIHRoZSBj
b21tdW5pdHkuwqAgQWJvdXQKPiAgICAgYWxsIHRoZQo+ICAgICA+wqAgwqAgwqAgPsKgIMKg
IMKgY29tbXVuaXR5IGNvdWxkIGRvIHdpdGggYSBicm9rZW4gV0cgaXMgdG8gcmVydW4gdGhl
Cj4gICAgIHByb2Nlc3Mgd2UncmUKPiAgICAgPsKgIMKgIMKgID7CoCDCoCDCoGN1cnJlbnRs
eSBkb2luZyBhbmQgcmVzdHJ1Y3R1cmUgeWV0IGFnYWluLiBUaGF0IHNlZW1zCj4gICAgIGJv
dGggbGlrZQo+ICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgb3ZlcmtpbGwgYW5kIGEgYmFkIG1v
ZGVsLgo+ICAgICA+wqAgwqAgwqAgPgo+ICAgICA+wqAgwqAgwqAgPiBXZWxsLCBJIGRvIHRo
aW5rIHRoYXQgaXQncyAqYWNjb3VudGFibGUqIHRvIHRoZSBjb21tdW5pdHkgYnV0Cj4gICAg
ID7CoCDCoCDCoG5lZWRzIHRoZQo+ICAgICA+wqAgwqAgwqAgPiBjb25zZW50IG9mIHRoZSBS
U0FCLgo+ICAgICA+wqAgwqAgwqAgPgo+ICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgVGhlIFdH
IGNoYWlycyBjYW4gYmUgcmVwbGFjZWQsIGJ1dCB0aGVyZSBpcyBubyBlcXVpdmFsZW50Cj4g
ICAgID7CoCDCoCDCoHJlY291cnNlCj4gICAgID7CoCDCoCDCoCA+wqAgwqAgwqBmb3IgcGFy
dGljaXBhbnRzIHByb3Bvc2luZyBhbmQgYXBwcm92aW5nIGhhcm1mdWwKPiAgICAgcHJvcG9z
YWxzIG9yIGZvcgo+ICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgdGhhdCBtYXR0ZXIgc2l0dGlu
ZyBvbiB0aGVpciBoYW5kcyBhbmQgbm90IHByb3Bvc2luZwo+ICAgICBhbmQgY3JlYXRpbmcK
PiAgICAgPsKgIMKgIMKgID7CoCDCoCDCoG5lY2Vzc2FyeSBkb2N1bWVudHMuwqDCoCBBbmQg
bm93IGl0IHNvdW5kcyBsaWtlIEVLUiBldAo+ICAgICBhbCAoc29ycnkgdG8KPiAgICAgPsKg
IMKgIMKgID7CoCDCoCDCoHNpbmdsZSB5b3Ugb3V0LCBidXQgeW91cnMgaXMgdGhlIG1vc3Qg
cmVjZW50IHB1c2gKPiAgICAgYWdhaW5zdCBSU0FCCj4gICAgID7CoCDCoCDCoCA+wqAgwqAg
wqBjaGVja3MgYW5kIGJhbGFuY2VzKSBhcmUgbG9va2luZyBmb3IgYSBtb2RlbCB3aGVyZQo+
ICAgICB0aGUgUlNBQgo+ICAgICA+wqAgwqAgwqBjYW4gb25seQo+ICAgICA+wqAgwqAgwqAg
PsKgIMKgIMKgcHVzaCBiYWNrIG9uIHByb2Nlc3NlcyBhbmQgbm90IGJhZCBkb2N1bWVudHMg
b3IKPiAgICAgaWRlYXMuIE9yIG5vdAo+ICAgICA+wqAgwqAgwqBldmVuCj4gICAgID7CoCDC
oCDCoCA+wqAgwqAgwqB0aGF0IHdpdGggdGhlIHByb3Bvc2FsIHRvIGVsaW1pbmF0ZSBhcHBl
YWxzIGZyb20gUlNXRwo+ICAgICBhY3Rpb25zLgo+ICAgICA+wqAgwqAgwqAgPgo+ICAgICA+
wqAgwqAgwqAgPiBJIGp1c3Qgd2FudCB0byBjbGFyaWZ5IHRoYXQgSSBhbSBub3QgYXJndWlu
ZyB0aGF0IHRoYXQKPiAgICAgdGhlIFJTQUIKPiAgICAgPsKgIMKgIMKgc2hvdWxkCj4gICAg
ID7CoCDCoCDCoCA+IG5vdCBiZSBhYmxlIHRvIHB1c2ggYmFjayBvbiBiYWQgZG9jdW1lbnRz
IG9yIGlkZWFzLiBXaGF0IEknbQo+ICAgICA+wqAgwqAgwqBzYXlpbmcgaXMKPiAgICAgPsKg
IMKgIMKgID4gdGhhdCB0aGUgUlNBQiBzaG91bGQgbm90IGJlIGFibGUgdG8gZm9yY2UgdGhl
IFdHIHRvCj4gICAgIGFkdmFuY2UgaWRlYXMgaXQKPiAgICAgPsKgIMKgIMKgID4gdGhpbmtz
IGFyZSBnb29kIGV2ZW4gaWYgdGhlIFJTV0cgZG9lcyBub3QuCj4gICAgID7CoCDCoCDCoCA+
Cj4gICAgID7CoCDCoCDCoCA+IC1Fa3IKPiAgICAgPsKgIMKgIMKgID4KPiAgICAgPsKgIMKg
IMKgID4KPiAgICAgPsKgIMKgIMKgID7CoCDCoCDCoEkga25vdyB3aG8gYWxsIG9mIHRoZSBS
U0FCIG1lbWJlcnMgd2lsbCBiZSAtIG5vdCB0aGUKPiAgICAgaW5kaXZpZHVhbHMsCj4gICAg
ID7CoCDCoCDCoCA+wqAgwqAgwqBidXQgdGhlaXIgY2hhaW5zIG9mIGF1dGhvcml0eSBhbmQg
cmVzcG9uc2liaWxpdHkgc3RlbW1pbmcKPiAgICAgPsKgIMKgIMKgZnJvbSB0aGVpcgo+ICAg
ICA+wqAgwqAgwqAgPsKgIMKgIMKgcG9zaXRpb25zIGFuZCBmcm9tIHRoZWlyIG9yZ2FuaXph
dGlvbnMuIEknbSBsZXNzIHN1cmUKPiAgICAgb2YgdGhlCj4gICAgID7CoCDCoCDCoFJTV0cK
PiAgICAgPsKgIMKgIMKgID7CoCDCoCDCoGNoYWlycy7CoMKgIFRoZSByZXN0IG9mIHRoZSBj
cm93ZCBoYXMgbm8gYWdyZWVkIHVwb24KPiAgICAgaW5kaXZpZHVhbAo+ICAgICA+wqAgwqAg
wqAgPsKgIMKgIMKgcmVzcG9uc2liaWxpdGllcywgYnV0IGdldHMgdWx0aW1hdGUgYXV0aG9y
aXR5P8KgIFRoaXMKPiAgICAgbW9kZWwKPiAgICAgPsKgIMKgIMKgc2VlbXMgdG8KPiAgICAg
PsKgIMKgIMKgID7CoCDCoCDCoGJlIG1vdmluZyB0byBsZXNzIGFuZCBsZXNzIG9mIGEgZ29v
ZCBiYWxhbmNlIG9mCj4gICAgIGF1dGhvcml0eSBhbmQKPiAgICAgPsKgIMKgIMKgID7CoCDC
oCDCoHJlc3BvbnNpYmlsaXR5IHRoZSBmdXJ0aGVyIHdlIGdvLgo+ICAgICA+wqAgwqAgwqAg
Pgo+ICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgTGF0ZXIsIE1pa2UKPiAgICAgPsKgIMKgIMKg
ID4KPiAgICAgPsKgIMKgIMKgID4KPiAgICAgPsKgIMKgIMKgID4KPiAgICAgPsKgIMKgIMKg
ID7CoCDCoCDCoC0tCj4gICAgID7CoCDCoCDCoCA+wqAgwqAgwqBSZmNlZC1mdXR1cmUgbWFp
bGluZyBsaXN0Cj4gICAgID7CoCDCoCDCoCA+IFJmY2VkLWZ1dHVyZUBpYWIub3JnIDxtYWls
dG86UmZjZWQtZnV0dXJlQGlhYi5vcmc+Cj4gICAgIDxtYWlsdG86UmZjZWQtZnV0dXJlQGlh
Yi5vcmcgPG1haWx0bzpSZmNlZC1mdXR1cmVAaWFiLm9yZz4+Cj4gICAgID7CoCDCoCDCoDxt
YWlsdG86UmZjZWQtZnV0dXJlQGlhYi5vcmcgPG1haWx0bzpSZmNlZC1mdXR1cmVAaWFiLm9y
Zz4KPiAgICAgPG1haWx0bzpSZmNlZC1mdXR1cmVAaWFiLm9yZyA8bWFpbHRvOlJmY2VkLWZ1
dHVyZUBpYWIub3JnPj4+Cj4gICAgID7CoCDCoCDCoCA+IGh0dHBzOi8vd3d3LmlhYi5vcmcv
bWFpbG1hbi9saXN0aW5mby9yZmNlZC1mdXR1cmUKPiAgICAgPGh0dHBzOi8vd3d3LmlhYi5v
cmcvbWFpbG1hbi9saXN0aW5mby9yZmNlZC1mdXR1cmU+Cj4gICAgID7CoCDCoCDCoDxodHRw
czovL3d3dy5pYWIub3JnL21haWxtYW4vbGlzdGluZm8vcmZjZWQtZnV0dXJlCj4gICAgIDxo
dHRwczovL3d3dy5pYWIub3JnL21haWxtYW4vbGlzdGluZm8vcmZjZWQtZnV0dXJlPj4KPiAg
ICAgPsKgIMKgIMKgID7CoCDCoCDCoDxodHRwczovL3d3dy5pYWIub3JnL21haWxtYW4vbGlz
dGluZm8vcmZjZWQtZnV0dXJlCj4gICAgIDxodHRwczovL3d3dy5pYWIub3JnL21haWxtYW4v
bGlzdGluZm8vcmZjZWQtZnV0dXJlPgo+ICAgICA+wqAgwqAgwqA8aHR0cHM6Ly93d3cuaWFi
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JmY2VkLWZ1dHVyZQo+ICAgICA8aHR0cHM6Ly93d3cu
aWFiLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JmY2VkLWZ1dHVyZT4+Pgo+ICAgICA+wqAgwqAg
wqAgPgo+ICAgICA+wqAgwqAgwqAgPgo+ICAgICA+Cj4KPgo=
--------------5142EA0588EDA36A281E6FD6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
We really now must return to the appeals process from the RSAB.=C2=
=A0
      I'm going to start that discussion in a different thread.

    
Eliot

    

    
On 08.07.21 03:17, Eric Rescorla wrote=
:

    

    

      
      
This seems like an OK resolution to me.

      

      

      

        
On Wed, Jul 7, 2021 at 2:35=
 PM
          Joel M. Halpern <jmh@joelhalpern.com> wrote:
        

        
=
Do
          you think we need to include a sentence or two in the document
          saying 

          that the chairs are required to follow the rough consensus of
          the 

          working group?=C2=A0 =C2=A0And further that in process matters =
the RSAB
          is 

          requried to respect the rough consensus of the working group?=C2=
=A0
          =C2=A0 If that 

          will help get this issue unstuck, I am all for it.

          

          Yours,

          Joel

          

          On 7/7/2021 4:28 PM, Eric Rescorla wrote:

          > 

          > 

          > On Wed, Jul 7, 2021 at 11:34 AM Joel M. Halpern <jmh@joelhalpern.com 

          > <mailto:jmh@joelhalpern.co=
m>>
          wrote:

          > 

          >=C2=A0 =C2=A0 =C2=A0I think I am missing something in your =
reasoning EKR.

          > 

          >=C2=A0 =C2=A0 =C2=A0We are discussing the case where the RS=
WG chairs are
          not advancing

          >=C2=A0 =C2=A0 =C2=A0something in the presence of a claimed =
rough
          consensus in support of

          >=C2=A0 =C2=A0 =C2=A0that thing.

          > 

          >=C2=A0 =C2=A0 =C2=A0And you are objecting to the RSAB being=
 able to
          "force the WG to

          >=C2=A0 =C2=A0 =C2=A0advance

          >=C2=A0 =C2=A0 =C2=A0ideas it thinks are good even if the RS=
WG does not."

          > 

          >=C2=A0 =C2=A0 =C2=A0if there is rough consensus for the ide=
a, then the
          RSWG thinks the idea

          >=C2=A0 =C2=A0 =C2=A0is good, even if the chairs do not.=C2=A0=
 I believe the
          chairs should lose

          >=C2=A0 =C2=A0 =C2=A0that fight.

          > 

          > 

          > I'm generally fairly sympathetic to this position, though
          I would note 

          > that in

          > the IETF the Chair's role seems a bit muddled here. See
          especially RFC 

          > 4858 S 3.1,

          > which I think implies that the chairs do have some
          substantive 

          > responsibility for

          > document quality, not just procedural responsibilities.
          > 

          > 

          >=C2=A0 =C2=A0 =C2=A0The other alternative is that there is =
not rough
          consensus for the

          >=C2=A0 =C2=A0 =C2=A0idea,

          >=C2=A0 =C2=A0 =C2=A0but the RSAB claims there is.=C2=A0 Tha=
t would seem to be
          subject to the

          >=C2=A0 =C2=A0 =C2=A0already agreed rules for appealing RSAB=
 actions.=C2=A0
          Because in that

          >=C2=A0 =C2=A0 =C2=A0situation the RSAB would not be followi=
ng the
          process.

          > 

          > 

          >=C2=A0 =C2=A0 =C2=A0Why is that not sufficient?

          > 

          > 

          > Well, it's actually not clear to me that this *would*
          violate the 

          > process, but perhaps

          > all that's needed is some sharpening of the text, as
          Eliot suggests.

          > 

          > -Ekr

          > 

          >=C2=A0 =C2=A0 =C2=A0Yours,

          >=C2=A0 =C2=A0 =C2=A0Joel

          > 

          >=C2=A0 =C2=A0 =C2=A0On 7/7/2021 1:28 PM, Eric Rescorla wrot=
e:

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 > On Tue, Jul 6, 2021 at 9:59 PM Mi=
chael StJohns

          >=C2=A0 =C2=A0 =C2=A0<msj@nthpermutation=
=2Ecom
          <mailto:msj@nthpermutation=
=2Ecom>

          >=C2=A0 =C2=A0 =C2=A0 > <mailto:msj@nthpermutation.com
          <mailto:msj@nthpermutation=
=2Ecom>>>

          >=C2=A0 =C2=A0 =C2=A0wrote:

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 7/7/2021 12=
:24 AM, Brian E Carpenter
          wrote:

          >=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0<jm=
h>Hmmm.=C2=A0 Really?=C2=A0 The IESG
          or the IAB getting into

          >=C2=A0 =C2=A0 =C2=A0giving advice and

          >=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0opinio=
ns on how the RSWG works
          seems to be an involvement

          >=C2=A0 =C2=A0 =C2=A0we have been

          >=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0avoidi=
ng.=C2=A0 </jmh>

          >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0True. But =
in any case, firing them is
          the ultimate sanction

          >=C2=A0 =C2=A0 =C2=A0(just as a

          >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0recall in =
the IETF process is the
          ultimate sanction). As

          >=C2=A0 =C2=A0 =C2=A0long as we have

          >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0firing as =
an option, "advise, admonish,
          express serious

          >=C2=A0 =C2=A0 =C2=A0concerns" will

          >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0happen any=
way, behind the scenes if not
          in public. I don't

          >=C2=A0 =C2=A0 =C2=A0think we need

          >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0to write t=
hat down, because it would
          just happen if things

          >=C2=A0 =C2=A0 =C2=A0went wrong.

          >=C2=A0 =C2=A0 =C2=A0 >>

          >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Brian

          >=C2=A0 =C2=A0 =C2=A0 >>

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The question t=
o which I keep returning:=C2=A0=C2=A0
          To whom is the RSWG

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0accountable to=
o if not the RSAB?=C2=A0=C2=A0=C2=A0 It's
          certainly not

          >=C2=A0 =C2=A0 =C2=A0accountable

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to the communi=
ty, even though it's made up
          of various

          >=C2=A0 =C2=A0 =C2=A0permutations

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0(over time) of=
 the members of the
          community.=C2=A0 About all the

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0community coul=
d do with a broken WG is to
          rerun the process we're

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0currently doin=
g and restructure yet again.=C2=A0
          That seems both like

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0overkill and a=
 bad model.

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 > Well, I do think that it's *accou=
ntable* to the
          community but

          >=C2=A0 =C2=A0 =C2=A0needs the

          >=C2=A0 =C2=A0 =C2=A0 > consent of the RSAB.

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The WG chairs =
can be replaced, but there is
          no equivalent

          >=C2=A0 =C2=A0 =C2=A0recourse

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0for participan=
ts proposing and approving
          harmful proposals or for

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0that matter si=
tting on their hands and not
          proposing and creating

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0necessary docu=
ments.=C2=A0=C2=A0 And now it sounds
          like EKR et al (sorry to

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0single you out=
, but yours is the most
          recent push against RSAB

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0checks and bal=
ances) are looking for a
          model where the RSAB

          >=C2=A0 =C2=A0 =C2=A0can only

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0push back on p=
rocesses and not bad
          documents or ideas. Or not

          >=C2=A0 =C2=A0 =C2=A0even

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0that with the =
proposal to eliminate appeals
          from RSWG actions.

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 > I just want to clarify that I am =
not arguing
          that that the RSAB

          >=C2=A0 =C2=A0 =C2=A0should

          >=C2=A0 =C2=A0 =C2=A0 > not be able to push back on bad d=
ocuments or
          ideas. What I'm

          >=C2=A0 =C2=A0 =C2=A0saying is

          >=C2=A0 =C2=A0 =C2=A0 > that the RSAB should not be able =
to force the
          WG to advance ideas it

          >=C2=A0 =C2=A0 =C2=A0 > thinks are good even if the RSWG =
does not.

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 > -Ekr

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I know who all=
 of the RSAB members will be
          - not the individuals,

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0but their chai=
ns of authority and
          responsibility stemming

          >=C2=A0 =C2=A0 =C2=A0from their

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0positions and =
from their organizations.=C2=A0
          I'm less sure of the

          >=C2=A0 =C2=A0 =C2=A0RSWG

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0chairs.=C2=A0=C2=
=A0 The rest of the crowd has no
          agreed upon individual

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0responsibiliti=
es, but gets ultimate
          authority?=C2=A0 This model

          >=C2=A0 =C2=A0 =C2=A0seems to

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0be moving to l=
ess and less of a good
          balance of authority and

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0responsibility=
 the further we go.

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Later, Mike
          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0--

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Rfced-future m=
ailing list

          >=C2=A0 =C2=A0 =C2=A0 > Rfced-future@iab.o=
rg
          <mailto:Rfced-future@iab.o=
rg>

          >=C2=A0 =C2=A0 =C2=A0<mailto:Rfced-future@iab.o=
rg
          <mailto:Rfced-future@iab.o=
rg>>

          >=C2=A0 =C2=A0 =C2=A0 > https://www.iab.org/mailman/listinfo/rfced-future

          >=C2=A0 =C2=A0 =C2=A0<https://www.iab.org/mailman/listinfo/rfced-future>

          >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<https://www.iab.org/mailman/listinfo/rfced-future

          >=C2=A0 =C2=A0 =C2=A0<https://www.iab.org/mailman/listinfo/rfced-future>>

          >=C2=A0 =C2=A0 =C2=A0 >

          >=C2=A0 =C2=A0 =C2=A0 >

          > 

        

      

      

      

    

  


--------------5142EA0588EDA36A281E6FD6--

--bwhi1t80rcidV7FzIwWeddbK2bPwd6inR--

--l9ioChhbv5RV4A6fgDx1Lh05wO6F3bGKY
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDml34FAwAAAAAACgkQh7ZrRtnSejNb
owgAnlwP92AUvAGHkxohEDX36FNrAKamKYSOpo71WEJVs5vAQup7tKbfk5dtJnt9OVjmJClutxOh
NtHggrkUoUIGB3vPOh9g6Q5usnRpX0AQzihnLwHnGYjjgkBGQ6jjADzcjubwg+u4p8W1o0mbt4YE
Pa/A4ykDR09KHQLTw4d9tflqAzwNWxKFqju0VbcfbjvIwFUE7yLtGA6hOSn/GM8zlbIR170CFO5C
WKPlKWlLXPIF3CZ2uFLdfPkVxDxibLzqnnl+23q51w0nwa/3N2cnmMQu7JxpUyJxw8jyqTNlC5zB
Mpj/yWtGwuPJAqcVdnhugIR3eIg3QAZgSNJqPVczig==
=hXa/
-----END PGP SIGNATURE-----

--l9ioChhbv5RV4A6fgDx1Lh05wO6F3bGKY--


From nobody Wed Jul  7 23:25:41 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335A73A14C5 for ; Wed,  7 Jul 2021 23:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4IdFYi9MFn6 for ; Wed,  7 Jul 2021 23:25:13 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 14B6F3A14B2 for ; Wed,  7 Jul 2021 23:25:12 -0700 (PDT)
Received: from [IPv6:2a02:aa15:4101:2a80:6c39:6e3c:358a:bc63] ([IPv6:2a02:aa15:4101:2a80:6c39:6e3c:358a:bc63]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1686P97m128063 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 8 Jul 2021 08:25:10 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625725510; bh=w+XynOSzIrkaeDCiCEYi7fTCfucaBLV8hSnSh2XzaaQ=; h=To:From:Subject:Date:From; b=cxzrOXDi2SA6qAEfG/BauurpkIk24SxXj4sDmcjQHnDETWYvUuIY4Zdg4ZnpF/k2x IKUcYbaf9ZL6WA8qmuIYLpmACKw8eKfJQVY9ZjKAeBqz4EPjEfGXl025DphD077Kha a4sSuWnBKdpHTXOIkSOw4YlyBTMITeKNnYtDUgBE=
To: rfced-future@iab.org
From: Eliot Lear 
Message-ID: 
Date: Thu, 8 Jul 2021 08:25:09 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dI7xwOOO2FeUY6dYHnb1BnpVKPIOUtYPV"
Archived-At: 
Subject: [Rfced-future] Issue 36: Who to appeal RSAB decisions to?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Jul 2021 06:25:24 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--dI7xwOOO2FeUY6dYHnb1BnpVKPIOUtYPV
Content-Type: multipart/mixed; boundary="Q6NaGRjbuoUhM7fZI4tBYpvTB2n9gqglT";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Message-ID: 
Subject: Issue 36: Who to appeal RSAB decisions to?

--Q6NaGRjbuoUhM7fZI4tBYpvTB2n9gqglT
Content-Type: multipart/alternative;
 boundary="------------E9EF3D043FEA09B41703F16F"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------E9EF3D043FEA09B41703F16F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi everyone,

When last we left our heros on this issue, we had several different=20
ideas as to where RSAB decisions might be appealed to. There was=20
consensus on exactly one point: the ISOC BoT should *not* be the answer.

Before we answer the question, it is probably helpful to remind people=20
what sort of decisions could be appealed:

  * RSAB exceeds its authority.=C2=A0 It makes decisions that it is not
    entitled to make.
  * RSAB fails to follow procedure.=C2=A0 An example might be that it sim=
ply
    fails to move a document forward as set forth in the draft.
  * Any appeal sent to the RSAB.=C2=A0 In particular, if the RSAB argues =
that
    a consensus in the RSWG was present that wasn't or that consensus
    wasn't present when it was.

And then we need to think about remedies from the higher body. The=20
easiest one is that a decision is voided.

If this were the IAB, what would be the risks?

If this was some other body, who would that be and what would be the risk=
s?

Thoughts?

Eliot




--------------E9EF3D043FEA09B41703F16F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  

    
  
  
    
Hi everyone,

    
When last we left our heros on this issue, we had several
      different ideas as to where RSAB decisions might be appealed to.=C2=
=A0
      There was consensus on exactly one point: the ISOC BoT should no=
t
      be the answer.

    
Before we answer the question, it is probably helpful to remind
      people what sort of decisions could be appealed:

    
    
      
  • RSAB exceeds its authority.=C2=A0 It makes decisions that it is=
 not
        entitled to make.
    
      
    • 
      
  • RSAB fails to follow procedure.=C2=A0 An example might be that =
it
        simply fails to move a document forward as set forth in the
        draft.
    • 
      
  • Any appeal sent to the RSAB.=C2=A0 In particular, if the RSAB
        argues that a consensus in the RSWG was present that wasn't or
        that consensus wasn't present when it was.
    • 
    

    
And then we need to think about remedies from the higher body.=C2=A0=
=C2=A0
      The easiest one is that a decision is voided.

    
If this were the IAB, what would be the risks?

    
If this was some other body, who would that be and what would be
      the risks?

    
Thoughts?

    
Eliot

    

    


    

    


    

  


--------------E9EF3D043FEA09B41703F16F--

--Q6NaGRjbuoUhM7fZI4tBYpvTB2n9gqglT--

--dI7xwOOO2FeUY6dYHnb1BnpVKPIOUtYPV
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDmmkUFAwAAAAAACgkQh7ZrRtnSejOi
CwgAtQlqXMDCGy/8CCKdjKUvJxNbWl8tXjPZyfTS7vPdMceS5/xvTE57TgGY7vjpHOP4Vra1pg1w
67Fy4qv77c6Aa9gRdEK5c2VJV+Kk2lZw9zsyMVGRQ65ydCioTja0NV6iU/v6c1iCoRqoywYDms2/
pRFm8FAwEgnCRcDP9O/xFfsmVhfAJJTqWnV31SHtx33/OZGR72ZiHBeAmIOXYdr6psBSQilf9Y6/
T00xgsXH2Isw5n8dFH8RB2WaA8vwpvV3Fo18rkK3vcjUI8LxDx9J+Xa8G7+lemoI8K3Q08rXf8Fj
VEZjSUnBPzZxdRx4LkLnsb7F3qnY0Puy5Qq1F1/iiA==
=BetT
-----END PGP SIGNATURE-----

--dI7xwOOO2FeUY6dYHnb1BnpVKPIOUtYPV--


From nobody Thu Jul  8 14:46:37 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74DE3A0BFE for ; Thu,  8 Jul 2021 14:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 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.338, 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 8ZOBH6yhqRdF for ; Thu,  8 Jul 2021 14:46:30 -0700 (PDT)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C09F3A1FBC for ; Thu,  8 Jul 2021 14:46:30 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id h1-20020a17090a3d01b0290172d33bb8bcso7021867pjc.0 for ; Thu, 08 Jul 2021 14:46:30 -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=XtTR6d9M3tENICC8befEQOjKt8sLyxcbi2q1KPBZ9Po=; b=IwA9OGsGyHpWpSPz4DaZs3CgEUtPZkGHu06MDdDIb6VmXjN2G45fo0XFAogSo7YV0v Hsjhka0YNSFLQvFgjffSRAQColVpjG49W0A3g7Mz9pWPWxfpufQWpG03hB3KyC77R7mv XePfbem8DS2ImWd2S1iyv3yMO5agztjq77QJkuI92Dcb1QTod6B3/t164ujfSoEwj60E HqFmTLRP3x98G9JWf4ZvpEjYufgrqxqbZe7sLA0CGQ28LY4mYMZvkS2RHXuiQHQzRzPg sBW1AGER8IfqGxAQ3Wc5FLEnkskrqJIJq3/ez123Pk3z4o5GE24lMoVX+MmnOPU2KuiS KOAA==
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=XtTR6d9M3tENICC8befEQOjKt8sLyxcbi2q1KPBZ9Po=; b=SDB+zXptmxzF+q7DegYrDyZEtYtD5IzZXMj23Mf5UCQruAKJ7L71EC15EoiE3nj6O8 n6dNGuQM0s+xjSvXeCj7R080/pLOn02BieLNuTARbu67ngjn400JupndP44IPUyU98GU DV2o3Fh4mMhKWr+EqUpTRlYq1iAeh5KDA5sYMCP4hbLZL5+CQZgzrgfi0eqNJ8fc/0P1 wZ3PDOS7gjc/9Ih8DTp2zTmriDniF8MvBXTdvXYYi550f0zFCx/Sr7yoYWP97NdsgPAw TlWbno0vvvJ73kv6j2+N4pCA71vTX6FkN09WpW2HFaKpwIueT4O6zCF1o1KSmqIXQghN FJ/w==
X-Gm-Message-State: AOAM530UdXjXMFWdldqZn+Ly2HcfiVaA3sTAbNsZmQbUCXQ4gXS9Qjox KA4t6ziT/okUemWA25YlnRQZbXxpgKCJdA==
X-Google-Smtp-Source: ABdhPJz7iqIf2a7TOu6SbTfbqzCZYxI3qZkYhqt8IknN2RvqRInxioZ+EdPw3idtDYdxMuAk7dYeVQ==
X-Received: by 2002:a17:902:eb52:b029:129:bc24:ce5e with SMTP id i18-20020a170902eb52b0290129bc24ce5emr10926242pli.67.1625780789500;  Thu, 08 Jul 2021 14:46:29 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id gd16sm3379390pjb.9.2021.07.08.14.46.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jul 2021 14:46:28 -0700 (PDT)
To: Eliot Lear , rfced-future@iab.org
References: 
From: Brian E Carpenter 
Message-ID: 
Date: Fri, 9 Jul 2021 09:46:25 +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: [Rfced-future] Issue 36: Who to appeal RSAB decisions to?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Jul 2021 21:46:35 -0000

On 08-Jul-21 18:25, Eliot Lear wrote:
> Hi everyone,
>=20
> When last we left our heros on this issue, we had several different ide=
as as to where RSAB decisions might be appealed to.=C2=A0 There was conse=
nsus on exactly one point: the ISOC BoT should *not* be the answer.
>=20
> Before we answer the question, it is probably helpful to remind people =
what sort of decisions could be appealed:
>=20
>   * RSAB exceeds its authority.=C2=A0 It makes decisions that it is not=20
entitled to make.
>   * RSAB fails to follow procedure.=C2=A0 An example might be that it s=
imply fails to move a document forward as set forth in the draft.
>   * Any appeal sent to the RSAB.=C2=A0 In particular, if the RSAB argue=
s that a consensus in the RSWG was present that wasn't or that consensus =
wasn't present when it was.
>=20
> And then we need to think about remedies from the higher body.=C2=A0=C2=
=A0 The easiest one is that a decision is voided.

=2E.. and sent back for a do-over. I realise that has the potential for i=
nfinite loops, but we do *not* want to give power of decision to the high=
er body; just oversight of the process.

> If this were the IAB, what would be the risks?

IMHO, only the risk of infinite loops, if we limit the appeal body's powe=
r to process failure.

>=20
> If this was some other body, who would that be and what would be the ri=
sks?

I really don't see any plausible alternative.

   Brian
>=20
> Thoughts?
>=20
> Eliot
>=20
>=20
>=20
>=20


From nobody Thu Jul  8 15:09:03 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DCC3A2246 for ; Thu,  8 Jul 2021 15:09:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 dz4sPueEynAs for ; Thu,  8 Jul 2021 15:08:57 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 2B69B3A2245 for ; Thu,  8 Jul 2021 15:08:57 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id y8so10088763iop.13 for ; Thu, 08 Jul 2021 15:08:57 -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=HambvuAXlNIfRvCp/hKzMwdONW52aow5i1M+pFGXZ1I=; b=cI/VMPlxhgcQab5x0pbEomI0u8tdbICFHMTdsbrIi0yJnfnBJX04g791Pn8Xov9PmI nNYTb8ZDe/3K4jNOu7jEitFOt/V0sEtvn1q7Yab1o4vozccdQjkjUDdmhzBq/ntZxga9 j5RtoMq/GFjWvxte35v+n/32yxmJyKbydMzk8DL2KZLB2n+0uGUkdUNkjifw2oE00JdX LidMtgLzpYj2exyGgeE68v8ZrDYkRVhV9DQTcSOzETPL1jUvfnkPe7JnWVjvjFPIOdtO My6DrRaUX1OxT89QY1jklqAsGan4CX4k/SbKkn69rOIiCM/Sw+e5n9Jgjwf6TEzYx1I/ fEhg==
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=HambvuAXlNIfRvCp/hKzMwdONW52aow5i1M+pFGXZ1I=; b=HndfQyJu38PGDBn/OYA5zQxpg5yPL6Qrdo/Df6IlPUjWjPv3SduzODllizvGf8T5fj TO9zsY+w7djgmKPssAwzPn2QE86BOTHlknn07vKUf8/MK20CfdjNk50WTsw720s+o4pp O+3RddmHNIrAyIeWyZxsmFG0LS17swZ13gAvbhLeTGA34LA+wrcihyJg0IcxuwyZd81/ O90yNSVniPQxflpsTHg4go2q8zkTGc9erxPo7R3y7E/OojYrRq2rN2E3aI+4a5CKKTGx M47dtzOYJ9r4rk8NPSb7OBiiL9/HGx+vy2uOUEKLIao6gGVUsIsAACJ3OvETSsM6d+O9 wdFQ==
X-Gm-Message-State: AOAM530t1/kOZGsSlF/OFVHkn9sF3+8jIxevysjAQ/ias6O2JEO04P1a mW0m6IuOSbKNSds5kTkkQumD3T6XV00ccMNFwiPv5Q==
X-Google-Smtp-Source: ABdhPJzO++NLfy9px8sQC4+aHljhUgbWFRbtBquzbQuaor50n2prlIwfp9In4cBApYDYomPLo7Bki1yv1Wc6RqwQvxQ=
X-Received: by 2002:a6b:6205:: with SMTP id f5mr25680125iog.60.1625782135637;  Thu, 08 Jul 2021 15:08:55 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Eric Rescorla 
Date: Thu, 8 Jul 2021 15:08:19 -0700
Message-ID: 
To: Brian E Carpenter 
Cc: Eliot Lear , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000ad5dc605c6a3e672"
Archived-At: 
Subject: Re: [Rfced-future] Issue 36: Who to appeal RSAB decisions to?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Jul 2021 22:09:02 -0000

--000000000000ad5dc605c6a3e672
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 8, 2021 at 2:46 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 08-Jul-21 18:25, Eliot Lear wrote:
> > Hi everyone,
> >
> > When last we left our heros on this issue, we had several different
> ideas as to where RSAB decisions might be appealed to.  There was consensus
> on exactly one point: the ISOC BoT should *not* be the answer.
> >
> > Before we answer the question, it is probably helpful to remind people
> what sort of decisions could be appealed:
> >
> >   * RSAB exceeds its authority.  It makes decisions that it is not
> entitled to make.
> >   * RSAB fails to follow procedure.  An example might be that it simply
> fails to move a document forward as set forth in the draft.
> >   * Any appeal sent to the RSAB.  In particular, if the RSAB argues that
> a consensus in the RSWG was present that wasn't or that consensus wasn't
> present when it was.
> >
> > And then we need to think about remedies from the higher body.   The
> easiest one is that a decision is voided.
>
> ... and sent back for a do-over. I realise that has the potential for
> infinite loops, but we do *not* want to give power of decision to the
> higher body; just oversight of the process.
>
> > If this were the IAB, what would be the risks?
>
> IMHO, only the risk of infinite loops, if we limit the appeal body's power
> to process failure.
>
> >
> > If this was some other body, who would that be and what would be the
> risks?
>
> I really don't see any plausible alternative.
>
>    Brian
> >
>

I agree with Brian on all points.

-Ekr

> Thoughts?
> >
> > Eliot
> >
> >
> >
> >
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--000000000000ad5dc605c6a3e672
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Jul 8, 2021 at 2:46 PM Brian =
E Carpenter <brian.e.carp=
enter@gmail.com> wrote:
On 08-Jul-21 18:25, Eliot Lear wrote:

> Hi everyone,

> 

> When last we left our heros on this issue, we had several different id=
eas as to where RSAB decisions might be appealed to.=C2=A0 There was consen=
sus on exactly one point: the ISOC BoT should *not* be the answer.

> 

> Before we answer the question, it is probably helpful to remind people=
 what sort of decisions could be appealed:

> 

>=C2=A0 =C2=A0* RSAB exceeds its authority.=C2=A0 It makes decisions tha=
t it is not 

entitled to make.

>=C2=A0 =C2=A0* RSAB fails to follow procedure.=C2=A0 An example might b=
e that it simply fails to move a document forward as set forth in the draft=
.

>=C2=A0 =C2=A0* Any appeal sent to the RSAB.=C2=A0 In particular, if the=
 RSAB argues that a consensus in the RSWG was present that wasn't or th=
at consensus wasn't present when it was.

> 

> And then we need to think about remedies from the higher body.=C2=A0=
=C2=A0 The easiest one is that a decision is voided.



... and sent back for a do-over. I realise that has the potential for infin=
ite loops, but we do *not* want to give power of decision to the higher bod=
y; just oversight of the process.



> If this were the IAB, what would be the risks?



IMHO, only the risk of infinite loops, if we limit the appeal body's po=
wer to process failure.



> 

> If this was some other body, who would that be and what would be the r=
isks?



I really don't see any plausible alternative.



=C2=A0 =C2=A0Brian

> 

I agree with Brian on all points.=


-Ekr


> Thoughts?

> 

> Eliot

> 

> 

> 

> 



-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future




--000000000000ad5dc605c6a3e672--


From nobody Fri Jul  9 10:16:18 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB353A2843 for ; Fri,  9 Jul 2021 10:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 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.338, 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=mozilla.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 tVuClI3P9SBE for ; Fri,  9 Jul 2021 10:16:14 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 06DA13A2841 for ; Fri,  9 Jul 2021 10:16:13 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id k16so13174118ios.10 for ; Fri, 09 Jul 2021 10:16:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=SKbpscIl9ZbhcBuGmguepeRRJsQvG8JgB+qQ+q/ax60=; b=Hi7adacxo/W+f8nL1QxPavSlawG7AK6GmfqgUWS5R0T5ePLpA23T5xdyJ5Suu+r4Zm +JkFRcr0oEJ+3hj1cbLDR1XsDUxeEQkJmiRHWkwjFJ5/whqHrcauIVQdlNewqQ3XVTX9 iR6OtuVs78dNywWoFcT08AawP0vutqgDjEfmE=
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=SKbpscIl9ZbhcBuGmguepeRRJsQvG8JgB+qQ+q/ax60=; b=b7N+/UUp0jSrXw8QDWMr4LJcNZIf8AQledICqcV120Lv92r9g4kDJjP6O/KOuPhdUM jbT0eiEH/kt2fH426j2N4W8w82KMTUQAopzOpjDPwLMvUReThdmnrcdVvSe//+dasrcd WK7Q23kMV4Kw2eV5WS+UMQJkRUrn2CllPpx6j5R2dkVD78zW3OV3wJDXjifbrUKOD55j eCjV2Itl0NGfygbMa9dOd4X5Bwx7wbh6jpLK5QLqJcSi+02i1hPB7zFfNsVwAAg82QuU /ox4sZG7+8VMa/QTMyeqmg40p94wG450WXXcgG3zhgGp6ZUC99hRpZjIoap0fdcx4qio gV9g==
X-Gm-Message-State: AOAM5337qwLI9VzQLUg/bEIENWZg7Q1VC0JbXyO0ePiiME6gkW+cKqoD RRSAQry7OcJo9DpyZZ0lVXhAvQ==
X-Google-Smtp-Source: ABdhPJxPoZrtZJ/jst431CguwMZly6mFC/2rsacwS9rhDhJMpov2zbs0CxD1XIkqNllj2XEhT7ebRw==
X-Received: by 2002:a02:aa8b:: with SMTP id u11mr27326160jai.43.1625850972053;  Fri, 09 Jul 2021 10:16:12 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id q7sm3010676ilv.17.2021.07.09.10.16.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 10:16:11 -0700 (PDT)
To: Eliot Lear , rfced-future@iab.org
References:  
From: Peter Saint-Andre 
Message-ID: <073ebd0b-3975-2655-d478-a87a3f993bc0@mozilla.com>
Date: Fri, 9 Jul 2021 11:16:10 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus check- Issue 53: Do new streams necessarily imply new RSAB members?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Jul 2021 17:16:17 -0000

Proposed text:

Whenever a new stream is created {{RFC4844}}, the document that
creates the stream shall specify if a voting member representing
that stream shall also be added to the RSAB, along with any rules
and processes related to that representative (e.g., whether the
representative is member of the body responsible for the stream
or an appointed delegate thereof).

On 7/7/21 11:06 AM, Eliot Lear wrote:
> There were no comments on this after our meeting, so Peter should
> include appropriate text in a draft sometime after -00.
> 
> On 22.06.21 16:54, Eliot Lear wrote:
>>
>> General agreement that this matter can be deferred into whatever RFC
>> defines the stream.  If you have concerns about this approach, please
>> make them known by 6 July.
>>
>> Eliot
>>
>>
>>
> 


From nobody Fri Jul  9 10:41:34 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D373A28EF for ; Fri,  9 Jul 2021 10:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 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.338, 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=mozilla.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 eYA4g5ogww6o for ; Fri,  9 Jul 2021 10:41:31 -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 E73C23A2925 for ; Fri,  9 Jul 2021 10:41:30 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id z26so1776309ioz.11 for ; Fri, 09 Jul 2021 10:41:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=P7vObbyPD0zRsVJL2OGt7gtTcr7Cjbz+TbFBDiF7f6U=; b=YAN2ReKP1Ks4J8Cw2OguSezLB0CeZ9nCCjzY7Puf15j7iaitedntJjzEfdRHehHmRs KcOCgqvUHjteUBtNu6sZQmHo3rfZ5nejZexHolstd6EJhYwcqY5HiEbc53pR/k0S1eWd 1g0Y/LT28LJdPGvXsewONXiOh5qtRr7cISXys=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=P7vObbyPD0zRsVJL2OGt7gtTcr7Cjbz+TbFBDiF7f6U=; b=Xg1cZFFHFl8zTPPgYPcxC+Adw86Q1aoHn8wCoXSLhaE++PNiAvu2VWUEGHuhIDvacg TW1IRyD66iXVxKOqIDyCAQdW8jqz+tGBwvRA2ZFDhHjl2Wpls6ufMkeDFnbVB2A29lVy THt188gtgCMZkAAvUWWJHIOZB/a71eiQLv0PYPkmWXToLuPQhTneS3VXreMmedJzxAvI kyp2u0+yRqQk/F8rKMawYKcae0fnEFhMzKV8tfZ3Vz0zidYKVroCwx8DmQDThh9HHxDi GFzzYcYINPEz5MVo8azzDbMqS0MgqBt97Z38wEdq4D+s0V+mcyNf/Odnqut9MQ27lTPh DQrw==
X-Gm-Message-State: AOAM530kJ+2QW/HZyhOIppRDPafq33O2hjk63qg3IoxYTIlTsDQvCD1R eS0TQH/3LreEFAjIQHoih6py5ct2h9m3QA==
X-Google-Smtp-Source: ABdhPJzkAXQ7BIeJUk7quM9ZT9xXlK8naGRJlpvptbT0bG+sHLMfC5dxsz3gSi8L9b5kYXgrqYFE6g==
X-Received: by 2002:a02:c95a:: with SMTP id u26mr24782536jao.49.1625852489503;  Fri, 09 Jul 2021 10:41:29 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id e14sm3156141ilc.47.2021.07.09.10.41.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 10:41:28 -0700 (PDT)
To: adrian@olddog.co.uk, 'Eric Rescorla' , 'Eliot Lear' 
Cc: rfced-future@iab.org
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk>
From: Peter Saint-Andre 
Message-ID: <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com>
Date: Fri, 9 Jul 2021 11:41:27 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <128201d76cea$a9326c00$fb974400$@olddog.co.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Jul 2021 17:41:33 -0000

My apologies for the delayed response. I'm working in batch mode. :-)

Updated proposed text:

The IAB and IESG delegates must be selected by the Nominating
Committee {{RFC3777}} to their respective bodies (i.e., they
must not be liaison or ex-officio members). These delegates shall
serve for one-year renewable terms. If it becomes necessary to
replace such a delegate for any reason, then for the sake of continuity
the IAB or IESG should name a new delegate to complete the term.

Further comments below.

On 6/29/21 7:28 AM, Adrian Farrel wrote:
> I agree with Ekr about replacing for any reason.
> 
>  
> 
> I don’t oppose any of these delegation rules, I just find them odd.
> 
>  
> 
> The delegating body remains completely responsible for the actions of
> the delegate, so:
> 
>   * Why does it matter where the delegate is drawn from?

AIUI the idea is that IAB and IESG delegates need to be selected by the
Nominating Committee so that:

(1) they are not liaison or ex-officio members, which would be strange
(the IAB chair could be the IESG delegate!)

(2) normal recall processes can be applied if necessary

>   * Why set specific term limits in this document (surely that is up to
>     the delegating body)?

In practice I doubt that it makes much difference, but I suppose terms
could be 2 years instead of 1.

>   * Why can the IRTF chair and ISE also delegate?

Perhaps because then the "reporting" lines become unclear.

Peter


From nobody Fri Jul  9 11:21:27 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE863A2A34 for ; Fri,  9 Jul 2021 11:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 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.338, 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 (1024-bit key) header.d=mozilla.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 DohJshWbv1J7 for ; Fri,  9 Jul 2021 11:21:23 -0700 (PDT)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 272253A2A33 for ; Fri,  9 Jul 2021 11:21:23 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id g3so11305456ilj.7 for ; Fri, 09 Jul 2021 11:21:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=e41tJGn7gVLAQlPlwAMr7wKAfhf2uI5m+bE/ALcBp3M=; b=EydhT8bS/u82yC+6qhbMeFrFzA79D/PjLuiEqW07b7I8SShMmzaCR2yMe95Wt3KGY5 DUwX0ktLk1h8jQ1FN1oxyLZFhMQZm0z9LMUCVpulbLximejBubfbj2iDGPQsNCg9o9Ie vr3fpm4Kztp4Yfwes9ct0mkN+AZLSAZfMcnLE=
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=e41tJGn7gVLAQlPlwAMr7wKAfhf2uI5m+bE/ALcBp3M=; b=BjVfcrpqYhmfYaAMjilMBPrGbaa1vctSYesDzIC10NOEwj9e84HAUJDRw/DW0ux2GZ PevZVuiVtO7opWWiqnjFIDhLS4rI2lpXPj52mrpW5w/ai4vZjgVnYhC5u8Isie6VnSiS QOIAY4P2/6M7yxuiE2+YCec60GdMGmjIJEue9vaUHNL4NgLC80L5CIkzZGZXmzhhGHAI YGKJXgUoEXkNv/1uSEvcWVl9CX9EGwVQh5FBc/APAZKfgIUpyJUnESHsUrrVt6MluINx k+jrprnz/Ql+PgCiyYTYXIUCuoH5tiMukg5JPJLxJCXOrt7Ea1wFSeNN1uRX3M1kJNra cEwg==
X-Gm-Message-State: AOAM533RirqJcXSaSIj7Spt0LLxm4wZDak/eUUjLRq7E00YYbyWYAdB2 +G4sbKXXcheJnVd1WeKkT7Pwvg==
X-Google-Smtp-Source: ABdhPJwqeFbCOo0M4VfZM3o71V+tcdlvbZsGKQ7FBvg1tnxGJ9dKqjslOW0OzAOsvJhRym9+U0+UNw==
X-Received: by 2002:a92:6902:: with SMTP id e2mr28531592ilc.275.1625854881828;  Fri, 09 Jul 2021 11:21:21 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id u2sm3292422ilm.19.2021.07.09.11.21.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 11:21:21 -0700 (PDT)
To: Brian E Carpenter , rfced-future@iab.org
References: <612bacba-0bdb-32bb-5369-19486742a111@lear.ch>  
From: Peter Saint-Andre 
Message-ID: 
Date: Fri, 9 Jul 2021 12:21:19 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Issue 68: we prohibited in person meetings and design teams
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Jul 2021 18:21:26 -0000

Proposed text:

When the RSWG is formed, all discussions shall take place on an
open email discussion list. Subsequently, the RSWG may decide by rough
consensus to also use additional tooling (e.g., GitHub as specified in
{{RFC8874}}), forms of communication (e.g., in-person or online
meetings), and working methods (e.g., design teams) as long as they
are consistent with {{RFC2418}}.

On 7/7/21 4:05 PM, Brian E Carpenter wrote:
> As long as "in person" includes "on line", so maybe some tiny wordsmithing is needed.
> 
> Regards
>    Brian Carpenter
> 
> On 08-Jul-21 05:01, Eliot Lear wrote:
>> I have not heard any objections to the following text.  Peter, please include in -01 of WG draft.
>>
>> On 30.06.21 07:55, Eliot Lear wrote:
>>>
>>>> When the RSWG is formed, all discussions shall take place on an open email discussion list or through in person meetings. Subsequently, the RSWG may decide by rough consensus to use working methods(e.g., GitHub as specified in [RFC8874] or design teams) as long as they are consistent with [RFC2418].
>>>
>>> Eliot
>>>
>>>
>>>
>>
> 


From nobody Fri Jul  9 13:36:04 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329A33A2E4B for ; Fri,  9 Jul 2021 13:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 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.338, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 wqVb7oiFOEXk for ; Fri,  9 Jul 2021 13:35:48 -0700 (PDT)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 50B373A2E2B for ; Fri,  9 Jul 2021 13:35:48 -0700 (PDT)
Received: by mail-il1-x135.google.com with SMTP id a11so11732738ilf.2 for ; Fri, 09 Jul 2021 13:35:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Gvsi3h9pF5hK0KIkCXUf8GQkkkCd7p11rsnAhBGyoVo=; b=OmTWv4paUS04xTo7l4Gdf8BX/QfYNxM80dGnjXl6lP+qobHPDu6oIaCWnHvr1WdrXa ubdLSM64UdEbpwZ/WiTQE3WPeNjNihoAL05tZTxgszrRFpix9VoEBeLfC3iN/suGIr2b Gdxp8Vnh/nLaj8VgLYM2EfUhIPq/ARURcJqGw=
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=Gvsi3h9pF5hK0KIkCXUf8GQkkkCd7p11rsnAhBGyoVo=; b=FCcPjCgAHCa6qVr/9FTXPyl2bZ0dlPJ7y2eZdiPDx4qUN7e8VCc4eWZE3MReXaYxf1 8cMhP/BB0bsbS7zYfScYqeseDOXpy8JgRCI0hOTV1BcyMl+J1OjKvuVCDX8N9jWr8IJG Dd+tCJns4QqZUfrMSn9A3dt4+TNLv0s4ST8px4zb2T/vpHNoHLqaUNvQL6Po1ornOOme rlv2swCkJo/Aiixf5/BHuVGzddEOcRSlGFXwoLlpiT0NHWrOmMtP51ZSm7SAe1MQuHfH U+5H49kH1ulDd6BViCwj0FawNWq/SIuN7QEB4MQkr9m6TlWpHhNulvwFoc9QsWcKQMcV y3fg==
X-Gm-Message-State: AOAM531nbi2d/QpObxfQKtVgoF080QzHSG28V6QizJDj5/ghogpRUVw1 w1zxbDCWKt1uNIn0XAp9K35giA==
X-Google-Smtp-Source: ABdhPJzewP9/gH4ZvAqelRgXNsPVj8dETJUMx8qKxkBOBMu3cSRLRKQKJQTaXck2mJpZZsZ0pS0KSQ==
X-Received: by 2002:a05:6e02:80a:: with SMTP id u10mr27417334ilm.298.1625862946616;  Fri, 09 Jul 2021 13:35:46 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id w21sm3235397iol.52.2021.07.09.13.35.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 13:35:46 -0700 (PDT)
To: Jay Daley , "rfced-future@iab.org" 
References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> <25bbe57b-f2fb-b07a-c5e4-0027156f03a7@nthpermutation.com>  
From: Peter Saint-Andre 
Message-ID: 
Date: Fri, 9 Jul 2021 14:35:44 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Jul 2021 20:36:02 -0000

On 6/22/21 8:30 PM, Jay Daley wrote:
> 
> 
>> On 23/06/2021, at 2:19 PM, Martin Thomson > > wrote:
>>
>> On Wed, Jun 23, 2021, at 11:58, Michael StJohns wrote:
>>> Ultimately, legally and effectively, the timing and priority of any work
>>> by the RPC is an LLC/RPC decision.  Ditto for any hired/contracted for
>>> RSA/E (mutual agreement consistent with the contract/employment
>>> agreement).  So yes - the RSAB may say "deprioritize" vs RSWG
>>> "emphasize" at which point if there's disagreement, that's going to be
>>> an interesting contractual discussion between the LLC contract manager
>>> and the RPC based on input from both the RSAB and the RSWG.  That's just
>>> reality and I don't really thing we need to spend a lot of time on
>>> trying to change how those levers of power are manipulated.  If there's
>>> a massive failure later, AND someone has a better idea, AND it can be
>>> implemented through contractual language, THEN we can readdress this
>>> point.
>>
>> I wasn't suggesting that we needed to change the substance here, just
>> to change the emphasis on the text.  You'll note that I just reworded
>> Jay's text, not changed the bullet points.
>>
>>> Which also has me asking a question:  Should the LLC provide a liaison
>>> to the RSAB as mandatory requirement?
>>
>> Not mandatory, and I don't think we need formal encouragement for
>> everyone to be proactively consultative.  I'd rather stay silent (for
>> reasons similar to those you outline above).
> 
> I think there should be an LLC liaison as a non-voting member.  That’s
> what we have with RSOC and what I think is necessary for the LLC in it’s
> role of setting the performance targets for the RPC and negotiating the
> work plan budget/timetables.

Proposed text:

  To ensure the smooth functioning of the RFC Series, the RSAB may
  at its discretion include non-voting members, for instance liaisons
  from the IETF LLC or RPC.

Peter


From nobody Fri Jul  9 13:44:09 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEBC3A2E61 for ; Fri,  9 Jul 2021 13:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 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.338, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 A2PE5iJB_hwG for ; Fri,  9 Jul 2021 13:44:02 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 702B03A2E66 for ; Fri,  9 Jul 2021 13:44:02 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id z1so11779275ils.0 for ; Fri, 09 Jul 2021 13:44:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ZRk6PB7uUfa9ZTHkDjHxHxUBL3rZ3bhdejOojqqSgIU=; b=bqJbQxo3cIagDSpeDM4lxrz1ikCKrDroQU1CNRqY96zvN5iLQG4oY8wokWOD0rdyyx DzaSSwtVryXeUlMQENuTjL+AlBrA+JB3j3ESLLTi0v5kchRqsrPg3oJFumOo+Dk4TUZQ JzI5SECyFJ2ZBnKBd7Mj70FzKnCRhdHQe4qiw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZRk6PB7uUfa9ZTHkDjHxHxUBL3rZ3bhdejOojqqSgIU=; b=XGJ97CW9gYKioLoHUNpiYjKLU/Q/y5eTqC7VtfSJ7CfTSK/kmORU2G8obsAXdq9Hx2 iNg37MmWX2Pi9IefDyOreSa/jjj5I/u6lg3oxonoViC0TRwTYuWxXEeaW51nAFA8V+vF 6qaAkqgFC64KJlx2DUMyojbXNgLfuLPXDp2TKGR5nYo8U/r7RuxVzbnSfJWKeXIrAN5l Areh7OpAyXqBIxqwNyYADkhGekoRe2DO63gzT+7a3gXPTstlOZ1MWqy6+raZwPOTdVPS Y+0I8/fOkqx0uP7o8wTaVVHh1hhotFCGQ4KiI7eEmYVf2wCfiTIG5aWzm6EyOpQ+83Jv Wffw==
X-Gm-Message-State: AOAM532BR7dqGUXyg86xNksCnj/568Hs4t6PqeaTGDIy/ojYPsiJ8epk cgJyX44iI8AourWxsIBWUz6Sbvvc6jN6Wg==
X-Google-Smtp-Source: ABdhPJxP8jxiUZy/XNpgqhIrAw+RRTzsdFZgg2uFQXrGx3xgusggNVwtCA6+BKzP+JPbOt4lUpbI1A==
X-Received: by 2002:a05:6e02:1207:: with SMTP id a7mr9316854ilq.283.1625863440600;  Fri, 09 Jul 2021 13:44:00 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id q7sm3357550ioi.34.2021.07.09.13.43.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 13:44:00 -0700 (PDT)
From: Peter Saint-Andre 
To: Jay Daley , "rfced-future@iab.org" 
References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> <25bbe57b-f2fb-b07a-c5e4-0027156f03a7@nthpermutation.com>   
Message-ID: <503630f1-5c96-d666-3951-1ecd5dcce5ff@mozilla.com>
Date: Fri, 9 Jul 2021 14:43:58 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Jul 2021 20:44:08 -0000

On 7/9/21 2:35 PM, Peter Saint-Andre wrote:
> On 6/22/21 8:30 PM, Jay Daley wrote:
>>
>>
>>> On 23/06/2021, at 2:19 PM, Martin Thomson >> > wrote:
>>>
>>> On Wed, Jun 23, 2021, at 11:58, Michael StJohns wrote:
>>>> Ultimately, legally and effectively, the timing and priority of any work
>>>> by the RPC is an LLC/RPC decision.  Ditto for any hired/contracted for
>>>> RSA/E (mutual agreement consistent with the contract/employment
>>>> agreement).  So yes - the RSAB may say "deprioritize" vs RSWG
>>>> "emphasize" at which point if there's disagreement, that's going to be
>>>> an interesting contractual discussion between the LLC contract manager
>>>> and the RPC based on input from both the RSAB and the RSWG.  That's just
>>>> reality and I don't really thing we need to spend a lot of time on
>>>> trying to change how those levers of power are manipulated.  If there's
>>>> a massive failure later, AND someone has a better idea, AND it can be
>>>> implemented through contractual language, THEN we can readdress this
>>>> point.
>>>
>>> I wasn't suggesting that we needed to change the substance here, just
>>> to change the emphasis on the text.  You'll note that I just reworded
>>> Jay's text, not changed the bullet points.
>>>
>>>> Which also has me asking a question:  Should the LLC provide a liaison
>>>> to the RSAB as mandatory requirement?
>>>
>>> Not mandatory, and I don't think we need formal encouragement for
>>> everyone to be proactively consultative.  I'd rather stay silent (for
>>> reasons similar to those you outline above).
>>
>> I think there should be an LLC liaison as a non-voting member.  That’s
>> what we have with RSOC and what I think is necessary for the LLC in it’s
>> role of setting the performance targets for the RPC and negotiating the
>> work plan budget/timetables.
> 
> Proposed text:
> 
>   To ensure the smooth functioning of the RFC Series, the RSAB may
>   at its discretion include non-voting members, for instance liaisons
>   from the IETF LLC or RPC.

Or (option 2):

  To ensure the smooth functioning of the RFC Series, the RSAB shall
  include the IETF Executive Director as a non-voting member since
  the IETF LLC is ultimately responsible for the operation of the
  policy implementation function. The RSAB may at its discretion include
  additional non-voting members, for instance a liaison from the RPC.

Peter


From nobody Fri Jul  9 14:03:36 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8A53A2EE5 for ; Fri,  9 Jul 2021 14:03:28 -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, 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 (1024-bit key) header.d=mozilla.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 M00j295mtEkg for ; Fri,  9 Jul 2021 14:03:25 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 ACB7B3A2EE4 for ; Fri,  9 Jul 2021 14:03:25 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id h190so13932579iof.12 for ; Fri, 09 Jul 2021 14:03:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=dD5cNQ9POjWwB4gpb1toe0vapmk+9THLMpV9GpdgL/A=; b=B+UCFadTmouBtwswrXTLYiiC+5nSh2fyad7x79jSlQkHEJk7hWqn2WSIsCTzjUryB+ tSE/1wny9ZTOpnGw2dVy1Ewv11ohzWxb1mJ5fTLn+7uoRjjC/zdps53MqWFdXlFeJ9K8 YlefUbC+5NApc+huvlTVIU1QEN928Hnzzkamg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=dD5cNQ9POjWwB4gpb1toe0vapmk+9THLMpV9GpdgL/A=; b=Pz0WQWEGdK24sQ2EsLRhUdcVfxh6Zph/52/s+d9ccvIvpk/sCGQJZ9O3Fj6VnIBFdr In40eHGpU8YkpT+XQaDMPY0LhgttX7ScuG8mY+TZyoWFn8Tpk5QegBwfC8ASumfoH7gk vuEeyOPVckftdDRva32wmFV7u0zukeiZiuK385r2lvld0kK9t0Bn5bbjRN2tepZYnWmQ 3dSikNrsM1uuh+O3aZCIepnLftOudQTZQscxVrjbmYo2y3u2kiTBHx848CyBc8LxnOYY HulIvPvUHe059fCL4d0/7HVT3QaYXlHIrJbUbMtpD6nLv4PZ4MIqBcVhqmYgi8ebTg+M tZZw==
X-Gm-Message-State: AOAM533rxsA9mjtkfbfWM72qcxWxjrZL/ZAzyqOY/BrtS+RDYq5q1wtI FCRn5I5cwLvzv4kGu+4DzpUSAQ==
X-Google-Smtp-Source: ABdhPJyq+v0ktcRxkkmgyJmBzxHhy3da3Pq7SuzZnJc7lRWgPVuN73KPAcdKnV2v0225eeofgY9N5Q==
X-Received: by 2002:a02:7f47:: with SMTP id r68mr7784121jac.127.1625864604279;  Fri, 09 Jul 2021 14:03:24 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id e14sm3406339ilc.47.2021.07.09.14.03.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 14:03:23 -0700 (PDT)
To: "rfced-future@iab.org" 
From: Peter Saint-Andre 
Message-ID: 
Date: Fri, 9 Jul 2021 15:03:22 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Jul 2021 21:03:36 -0000

The role played by the technical publishing expert in version 3 of the
model is different enough from past roles that I suggest we should not
use the name "RFC Series Editor" but instead "RFC Series Advisor".

Peter


From nobody Fri Jul  9 14:21:56 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54573A2F6C for ; Fri,  9 Jul 2021 14:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 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.338, 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 (1024-bit key) header.d=mozilla.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 4beWesd1T8Il for ; Fri,  9 Jul 2021 14:21:51 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 B18AB3A2F6A for ; Fri,  9 Jul 2021 14:21:51 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id y6so10749561ilj.13 for ; Fri, 09 Jul 2021 14:21:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=67jYRqDHmuz+IEW0N1WRtsElhNltFe3MHzhsYzo1Mu4=; b=dr7VD7DYr5se5ME+C7Aep8WaFdGtgXetOEhRdajB8OXv4gSwmj0WcFKea4Bdt0grrO s2o6TDWikLUp7uOHdA8b9zMZYZmC7uAGG9piCWLMNR8ESukxIfd4DwD5qFbj2kWJd9hU ZsT4JP3FHZBLADdqwv96XpIrBXTlTpNI8gqwQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=67jYRqDHmuz+IEW0N1WRtsElhNltFe3MHzhsYzo1Mu4=; b=gMt4gonkhldf+eRDKZjWSnS4x2UxvWbFMzSO0uDb8g0eaoWzyQ1loZMuAm7WsHMrzf rmMd9Bi2F2SkBCFSAsxz/I16AoS9rCpNfxmGxbF/9YQa2PdFWpSCcp46oV2jGQQLAbr7 GbVygXYTNjqUv/8DRqInsV7IVaF4OTorcJgGx+7msucVoA327A1Ka4YHzvQ12dMf9UJd BaurIDXkZ8TVw70huSbqsqvy/EgswFG5zuvRToBu2f85eoKmNECf2t6uc9NnNsgqBdOv yZJ4F5ivemcS0Sre4+O7N3EYcncw6gPbHTxbIaJchT5gwM7Mw4RArz0wqvPN0q3Tk1ac +7yA==
X-Gm-Message-State: AOAM5339B1SMwnA8XOviULVH11yCbKtd+KbYGxpOkZNi+0o7wa9or58V Hq/R59fVjsYlRKBhXe3rsYOgLA==
X-Google-Smtp-Source: ABdhPJzUJueiqGK8I3VaQa9748BtQWx+AbE214d2AAW5p+StcBexGdPEP7lqkKohX0bvcERSdgrDpQ==
X-Received: by 2002:a92:d942:: with SMTP id l2mr28655275ilq.107.1625865710523;  Fri, 09 Jul 2021 14:21:50 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id c26sm3406658ioa.32.2021.07.09.14.21.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 14:21:50 -0700 (PDT)
To: Brian E Carpenter 
Cc: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>    <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com>
From: Peter Saint-Andre 
Message-ID: 
Date: Fri, 9 Jul 2021 15:21:48 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <3b86de0d-6823-c740-7928-4258a420d990@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Jul 2021 21:21:55 -0000

On 7/4/21 10:52 PM, Brian E Carpenter wrote:
> On 05-Jul-21 16:31, Martin J. Dürst wrote:
>>
>>
>> On 2021-07-01 05:57, Brian E Carpenter wrote:
>>> On 01-Jul-21 07:40, Eliot Lear wrote:
>>>>
>>>> Here's the model, slightly tweaked, but the goal is not to wordsmith this model, but rather to explain the relationships with the RPC in particular (e.g., the first two bullets are really just there for completeness; we've covered that ground).  I don't think this text goes into the 
> draft.  We need something that is a bit more elaborated.  But if
>>> people are comfortable with the general approach, then we have a good starting point to develop appropriate text.
>>>>
>>>>>    * The RSWG establishes policy, with input from the community, the 
> RSAB, and the RSEA.
>>>>>    * The RSAB considers those proposals and approves or returns as appropriate.
>>>>>    * The RPC periodically reports to the RSAB on how it is implementing
>>> that policy.
>>>>>    * The RSEA provides expertise to the RPC and RSAB on how to implement the policy on an ongoing and operational basis, perhaps raising issues along the way for both the RSAB and community to consider.
>>>
>>> Yes, I think that position's the RSEA's role nicely (and to my mind, fixes the name as RSA because the RSEA is clearly *not* in authority).
>>
>> I'm somewhat worried here. While I agree with Martin Thomson (see 
>> separate mail) that it's the RSWG that establishes policy, I think it's 
> 
>> important to mention that the RS[EA...] not only provides expertise on 
>> how to implement policy, but also on potential new policies, including 
>> proposing new policies by themselves. "perhaps raising issues" may have 
> 
>> been written to include that, but in my view, it's quite weak.
> 
> That text isn't the primary part of the RSEA's job description, though.
> I thought it was OK in the context of this part of the draft.

Additionally, anyone (including the RSEA) can propose policy changes in
the RSWG. But for the avoidance of doubt we could say:

* The RSEA provides expert advice to the RPC and RSAB on how to
  implement established policies on an ongoing and operational basis,
  which can include raising issues or initiating proposed policy changes
  within the RSWG.

Peter


From nobody Fri Jul  9 14:42:25 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900253A300D for ; Fri,  9 Jul 2021 14:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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=mozilla.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 V7FLFWo7l-8s for ; Fri,  9 Jul 2021 14:42:22 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 42AC23A300B for ; Fri,  9 Jul 2021 14:42:21 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id y8so13998763iop.13 for ; Fri, 09 Jul 2021 14:42:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=430JpPyNH6mZzKi3DWE1hafYSERAjgOxpvdiPc68Crk=; b=dovv6B0TgXemQcQjO0l5ZZZ7lLB8pUvOQT1Z4vegi9MOegUQoEcLrc6h1XWAekJHr/ mSC1a5llfMgb9cI2DUeG2RoiwQMXs8vGVB6VQeNejhRXN6MXMJztFU/2233cQfrRbWQ1 qyJRfSe3ezZeWgZHxox/zQGTYowQ5pVB5fmKQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=430JpPyNH6mZzKi3DWE1hafYSERAjgOxpvdiPc68Crk=; b=q8pdoh7VZPFGxo2LhTWA9HbJmZVHA/tPMnhO4Cr5VOFOtRWqXStswi7MaAwFs7Kele qQ7G4utpTrd3w3PekZLGSz5XzVR3oYfWLUJNz1t1dulQe45zvlJQUTdA2ZBJBoEQJho8 EpLmzlL63QO/OqXqWNlHKJbFypJnSaSu5d6iLwBL4DDcUJwll8p5WBE9fvj7x8yLXNBN x5kpFUaaGJB4bDWZtB8+oeE2UcryqyuxFUJ/KkiDifDPnOX1NQhvG10/98sq/oNZHC/L o03CC/6kETSvsFQxwethG1J6ro2HZwwT8zAiJp5zWbMVJGMgG3CjY+QoCWmuhxr4CKXd V9Ng==
X-Gm-Message-State: AOAM531Oc6EQdlHN9EFfCO8uKOHb5+BzaaHl1NU74tg5LcgEyy1ImW25 hHIhzEUKJWZ2cyadLKnIgSF76g==
X-Google-Smtp-Source: ABdhPJw8KdoLqN4CtqRiXFkDs4B6HzfcIaoBcl3EwN1DUnJ+W01OuYmDEzIFcFWjHuo/PtzZYt6B0A==
X-Received: by 2002:a05:6602:10e:: with SMTP id s14mr30628990iot.52.1625866939700;  Fri, 09 Jul 2021 14:42:19 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id r3sm3617418ilg.20.2021.07.09.14.42.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 14:42:19 -0700 (PDT)
To: "rfced-future@iab.org" 
From: Peter Saint-Andre 
Message-ID: <9ed55c70-a41c-9fa6-7bbd-4ab9b76eb030@mozilla.com>
Date: Fri, 9 Jul 2021 15:42:18 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Rfced-future] draft-iab-rfcefdp-rfced-model-00 (forthcoming)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Jul 2021 21:42:24 -0000

Hi all,

I've just submitted draft-iab-rfcefdp-rfced-model-00, which will appear
once Mirja approves of the submission.

Peter


From nobody Fri Jul  9 21:41:33 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622FC3A1B9F for ; Fri,  9 Jul 2021 21:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 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.338, 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 9DiXjQdNfvPS for ; Fri,  9 Jul 2021 21:41:29 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7F93A1B9B for ; Fri,  9 Jul 2021 21:41:29 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id k20so5020047pgg.7 for ; Fri, 09 Jul 2021 21:41:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=z4fsJXXLrcHp+iOVYhLsSAe3WqLCfC8ObhB5W/q2S8s=; b=dJDIae7cyzZJbhzbJUeEs0E5PlY05QMnjKugm4N5UUF7CjJqfFDNr4DFo0r+cRKiA0 8Uca2ahs0tghJqlI4IyHuYD+C98apEbEbzo90mXurHYuo5oJ6wQgiL1yk5EFKreq8uAw Gt+EgYQiWT1ZJHp6tOO1TvzTiP1fYRXd/osY0MCDRNbB0B4DsUmXMrikH2c+TrPow/hF y6gLAHAvUbZ0MLDPonQ88alI5SCMlrqSbYElhS66wutQLcyvQlZW6DEw/SdYD2kcjPXQ +obj6SIBhAbp2qczgCjGl6o1WVjVTeoSFW3zIkijfCdV4v+IAs+ACBa5i9JchwrSFHRi bkmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z4fsJXXLrcHp+iOVYhLsSAe3WqLCfC8ObhB5W/q2S8s=; b=rH0q3WNxT3+lLkL8JXhMYpD/YvWJ71vBH3aFsNzSOahk0zUKR6mZYaabhsdzpwI409 qr1tfMr7VxCamlJbDqQDr75FliuQ/cVPC6GANV/poF58a3/zybaiK6bIre/65w9KTqx2 2269xi5ftd5KdIgCmoVr7s1BI4yDl4XT65iiH+ZvuftTa2s9jpBg+68SNfYL14ta1NSd uhbbQL5rsVpQrqmZUQlLP4N39dZql5bXvhGua0zzOLbOzsB7UM7EAgk2p1kFsO+/xHXK f54UjwSUpQku1Xm+01mnBt/ow/qYUcO1rKXHboZC86lGlyqTpD0DMyYIqrySbn2Pr4cs uDSQ==
X-Gm-Message-State: AOAM533rJOAfZU21R8UfkDnMMmrj0VBdx7CaoxItm7oDs2fpyDQQGY7I xF0zriQm2/mfhveDeJn2H0pNJ7T5juZF2A==
X-Google-Smtp-Source: ABdhPJyAQADHH/zl+Xkkn4LSoZS7inprfIBs4zBQZUKQnVuDrXF0l4biRbd8cEYreoAyA8Yn6F1nSw==
X-Received: by 2002:a05:6a00:b91:b029:321:4219:3c52 with SMTP id g17-20020a056a000b91b029032142193c52mr28387738pfj.69.1625892088228;  Fri, 09 Jul 2021 21:41:28 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id m21sm3507403pfo.159.2021.07.09.21.41.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 21:41:27 -0700 (PDT)
To: Peter Saint-Andre , adrian@olddog.co.uk, 'Eric Rescorla' , 'Eliot Lear' 
Cc: rfced-future@iab.org
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com>
From: Brian E Carpenter 
Message-ID: <5168ae3f-654f-723e-0786-1f3be4765ac4@gmail.com>
Date: Sat, 10 Jul 2021 16:41:22 +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: <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Jul 2021 04:41:33 -0000

On 10-Jul-21 05:41, Peter Saint-Andre wrote:
> My apologies for the delayed response. I'm working in batch mode. :-)
>=20
> Updated proposed text:
>=20
> The IAB and IESG delegates must be selected by the Nominating

s/be/have been/  for clarity.

> Committee {{RFC3777}} to their respective bodies (i.e., they
> must not be liaison or ex-officio members). These delegates shall
> serve for one-year renewable terms. If it becomes necessary to
> replace such a delegate for any reason, then for the sake of continuity=

> the IAB or IESG should name a new delegate to complete the term.
>=20
> Further comments below.
>=20
> On 6/29/21 7:28 AM, Adrian Farrel wrote:
>> I agree with Ekr about replacing for any reason.
>>
>> =C2=A0
>>
>> I don=E2=80=99t oppose any of these delegation rules, I just find them=20
odd.
>>
>> =C2=A0
>>
>> The delegating body remains completely responsible for the actions of
>> the delegate, so:
>>
>>   * Why does it matter where the delegate is drawn from?
>=20
> AIUI the idea is that IAB and IESG delegates need to be selected by the=

> Nominating Committee so that:
>=20
> (1) they are not liaison or ex-officio members, which would be strange
> (the IAB chair could be the IESG delegate!)
>=20
> (2) normal recall processes can be applied if necessary
>=20
>>   * Why set specific term limits in this document (surely that is up t=
o
>>     the delegating body)?
>=20
> In practice I doubt that it makes much difference, but I suppose terms
> could be 2 years instead of 1.
>=20
>>   * Why can the IRTF chair and ISE also delegate?
>=20
> Perhaps because then the "reporting" lines become unclear.
>=20
> Peter
>=20


From nobody Fri Jul  9 21:42:10 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98FD3A1BA2 for ; Fri,  9 Jul 2021 21:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 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.338, 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 UKgVul3BL42L for ; Fri,  9 Jul 2021 21:42:03 -0700 (PDT)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0: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 A8F503A1BA0 for ; Fri,  9 Jul 2021 21:42:03 -0700 (PDT)
Received: by mail-pf1-x429.google.com with SMTP id a127so10643533pfa.10 for ; Fri, 09 Jul 2021 21:42:03 -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=swXXRRBNNrf6prlX5q+CL7rcs8Gfv9GAMyNlAIYR/9Q=; b=f7UwHRRk6MfDBVQJEAg11HknauxD06ojYYL6oWBAb0311uWidl9xNvdSTk/1e+1ew+ lfVP0sFpxWJgdDoqU1xmcXM5MYuntWvIolkRqIMv2rrz2p61QRdpefEqfoTHPBSFgMRL rCI4b2r5B2I10hj4UsEqji4Yzq2Ppr2XPofyMK8lG7LoL+qMhaktZdZcZ0Jk+MdlEdMD OHtDjQoTmkeV/A9lZeBwtbnX+9ULmHYlx3S3B60qn8cefmpa7+OYVwjixNVwyRofvrKq NMvaSqncws0/kNcTTM8OHjB32KXm/nq3gVqHsr12uMoRuKN0DA/3/1b2lhwsZDdfWrzB 44hg==
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=swXXRRBNNrf6prlX5q+CL7rcs8Gfv9GAMyNlAIYR/9Q=; b=CGl6rDsK9eizmHRDGmOdVofViI1av6rapNvnXPnbmdAmFDNyEoYO35ZnkZAqZHb67o sNm7o15IDkYm7VHgpP0bEnF5b8pDaInKC04uqlXou062CoXApvDjqiMiicsPGOL80u+x apczrlups4W+b9Lg3NY5MYt478ammdEOQIEv/Bf8dSmNQx4KjqmWrmECh+5VJ4LOFX/C yUVbMczCEcFfQRY6Wt+l67uVib/gFeOhWBKmagFvM0xZ5sYCgnvOOM1SyanQVdCYb/rG Ae2Lb/cVOXwG1r/iZ7OPek1XPV0f2wiO8NgoIW3FazR5Y3q4Y3wJaHfB6Kf6rMwWmYnB 3g5Q==
X-Gm-Message-State: AOAM532eUadYRTkk1r01Qn3jaHXWhZDiZ/ktE5ubT0zGufDPsFETTAUb iDXUv3E6x2TarDeZB8tf6KzbowimNOQR2g==
X-Google-Smtp-Source: ABdhPJxNXnt83BD2jGuWiqQw8Vh63cQ1k4hrkw9NOdkMWnVXTd7YlxXwPDuRG99hlfCgqI8MRf4mGA==
X-Received: by 2002:a63:4242:: with SMTP id p63mr22361778pga.185.1625892122369;  Fri, 09 Jul 2021 21:42:02 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id bk16sm1368914pjb.54.2021.07.09.21.42.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 21:42:01 -0700 (PDT)
To: Peter Saint-Andre , rfced-future@iab.org
References: <612bacba-0bdb-32bb-5369-19486742a111@lear.ch>   
From: Brian E Carpenter 
Message-ID: <530d3289-3698-bfee-c929-81e97c0b8e27@gmail.com>
Date: Sat, 10 Jul 2021 16:41:57 +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: [Rfced-future] Issue 68: we prohibited in person meetings and design teams
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Jul 2021 04:42:09 -0000

wfm, thanks.

Regards
   Brian Carpenter

On 10-Jul-21 06:21, Peter Saint-Andre wrote:
> Proposed text:
>=20
> When the RSWG is formed, all discussions shall take place on an
> open email discussion list. Subsequently, the RSWG may decide by rough
> consensus to also use additional tooling (e.g., GitHub as specified in
> {{RFC8874}}), forms of communication (e.g., in-person or online
> meetings), and working methods (e.g., design teams) as long as they
> are consistent with {{RFC2418}}.
>=20
> On 7/7/21 4:05 PM, Brian E Carpenter wrote:
>> As long as "in person" includes "on line", so maybe some tiny wordsmit=
hing is needed.
>>
>> Regards
>>    Brian Carpenter
>>
>> On 08-Jul-21 05:01, Eliot Lear wrote:
>>> I have not heard any objections to the following text.=C2=A0 Peter, p=
lease include in -01 of WG draft.
>>>
>>> On 30.06.21 07:55, Eliot Lear wrote:
>>>>
>>>>> When the RSWG is formed, all discussions shall take place on an ope=
n email discussion list or through in person meetings. Subsequently, the =
RSWG may decide by rough consensus to use working methods(e.g., GitHub as=20
specified in [RFC8874] or design teams) as long as they are consistent wi=
th [RFC2418].
>>>>
>>>> Eliot
>>>>
>>>>
>>>>
>>>
>>


From nobody Fri Jul  9 21:43:13 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EF03A1BA9 for ; Fri,  9 Jul 2021 21:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 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.338, 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 Ei9wZW2FA3RB for ; Fri,  9 Jul 2021 21:43:10 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 4358E3A1BA6 for ; Fri,  9 Jul 2021 21:43:10 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id d1so881766plg.0 for ; Fri, 09 Jul 2021 21:43:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=E/5ZNZfMj07jFnjegpkOT/zv9lPzEvK2WdWQr0fSCds=; b=b956Uha8RSuGX2cRC70CtOeNByBhlJTJ/VXUIxB7P2Z5G71kqseYLOz/0twIfbi/wG QZT4p7p6D6bHP/nP+BrQEaBAeftFIOSmppY/in5unN02tS41hwGFJw0ldsCZDU5zIh8+ ze7nEn6QU/IcknuCCuq+R6yM3krxlFTj3GG7wMFhLXuC2FTGHHNDqmBHpf61TTDSyV/w WHJXpKA4gvWYWk0J2PZzX3HDE2mYZnM8lWtBIjc+uBWB3mIzU8hRrlLGpRklkkLkflqH pRvqJ95Kq8zveM3zz71+guHZYZjcxwywFbYDU/EPzN/EN3bfZx+LltR6bQNknCD1zMv1 qx/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=E/5ZNZfMj07jFnjegpkOT/zv9lPzEvK2WdWQr0fSCds=; b=Aei1SGw3ggTVeo/VD02mDhgXdcUoDjRUTAp2ln3fbuqazDcV4wl1dWOcVYB2eCwvgG SpnOspLCvYsNJrRtqRBLmF7Z8fsMvHMIV4Rs4keseTdmilhVWQasGEvtB5NEP1rk0WYW g8mZskZAdVsIfzLnBCTYy/EH/aLZYtaujS/FyLou9f4qN/n/DKfvMVynDwZqzxKpUjV9 waRbpmsgOEjF2OzRyO2mDKo4I3/KcvCRx0hB5ssqFDNriSp8dj3BbPkxhzeHkiI3d/vR mvhEBy16hAWsuKzY+rgzBhFBXs4LVa08EWS50efsjaKMPa+MS8vTbQdsH7zhsN6fKGPl Ol1w==
X-Gm-Message-State: AOAM532m9zxNQU0CYZbI25vlazRQnp+78qfuAixyOE8Deq7ZrI2Hwfdw +t3UQQH5PdpkIfLuWKwfjJ8MhjDKBjK+qQ==
X-Google-Smtp-Source: ABdhPJzFGVeNP4YJuVIFGulJOBWqjJrhLHPGRiUGmnD2RwJDLFQHfWyu+tgzBc2j7xGYsZNcILKJyw==
X-Received: by 2002:a17:90a:86c6:: with SMTP id y6mr5578458pjv.16.1625892189168;  Fri, 09 Jul 2021 21:43:09 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id g18sm7944013pfi.199.2021.07.09.21.43.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 21:43:08 -0700 (PDT)
To: Peter Saint-Andre 
Cc: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>    <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com> 
From: Brian E Carpenter 
Message-ID: 
Date: Sat, 10 Jul 2021 16:43:04 +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: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Jul 2021 04:43:12 -0000

wfm

Regards
   Brian Carpenter

On 10-Jul-21 09:21, Peter Saint-Andre wrote:
> On 7/4/21 10:52 PM, Brian E Carpenter wrote:
>> On 05-Jul-21 16:31, Martin J. D=C3=BCrst wrote:
>>>
>>>
>>> On 2021-07-01 05:57, Brian E Carpenter wrote:
>>>> On 01-Jul-21 07:40, Eliot Lear wrote:
>>>>>
>>>>> Here's the model, slightly tweaked, but the goal is not to wordsmit=
h this model, but rather to explain the relationships with the RPC in par=
ticular (e.g., the first two bullets are really just there for completene=
ss; we've covered that ground).=C2=A0 I don't think this text goes into t=
he=20
>> draft.=C2=A0 We need something that is a bit more elaborated.=C2=A0 Bu=
t if
>>>> people are comfortable with the general approach, then we have a goo=
d starting point to develop appropriate text.
>>>>>
>>>>>>    * The RSWG establishes policy, with input from the community, t=
he=20
>> RSAB, and the RSEA.
>>>>>>    * The RSAB considers those proposals and approves or returns as=20
appropriate.
>>>>>>    * The RPC periodically reports to the RSAB on how it is impleme=
nting
>>>> that policy.
>>>>>>    * The RSEA provides expertise to the RPC and RSAB on how to imp=
lement the policy on an ongoing and operational basis, perhaps raising is=
sues along the way for both the RSAB and community to consider.
>>>>
>>>> Yes, I think that position's the RSEA's role nicely (and to my mind,=20
fixes the name as RSA because the RSEA is clearly *not* in authority).
>>>
>>> I'm somewhat worried here. While I agree with Martin Thomson (see=20
>>> separate mail) that it's the RSWG that establishes policy, I think it=
's=20
>>
>>> important to mention that the RS[EA...] not only provides expertise o=
n=20
>>> how to implement policy, but also on potential new policies, includin=
g=20
>>> proposing new policies by themselves. "perhaps raising issues" may ha=
ve=20
>>
>>> been written to include that, but in my view, it's quite weak.
>>
>> That text isn't the primary part of the RSEA's job description, though=
=2E
>> I thought it was OK in the context of this part of the draft.
>=20
> Additionally, anyone (including the RSEA) can propose policy changes in=

> the RSWG. But for the avoidance of doubt we could say:
>=20
> * The RSEA provides expert advice to the RPC and RSAB on how to
>   implement established policies on an ongoing and operational basis,
>   which can include raising issues or initiating proposed policy change=
s
>   within the RSWG.
>=20
> Peter
>=20


From nobody Fri Jul  9 21:44:49 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E0C3A1BBD for ; Fri,  9 Jul 2021 21:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 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.338, 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 JTRP0m3aXFX1 for ; Fri,  9 Jul 2021 21:44:43 -0700 (PDT)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 639023A1BB9 for ; Fri,  9 Jul 2021 21:44:43 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id v13so6084239ple.9 for ; Fri, 09 Jul 2021 21:44:43 -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=H/zB/V+7uR1GJOlMTWq5zjGE9uhan5zQj8C7QXwQIrc=; b=WFW1SKYbt990rqJgT14SQg7C3SvWy1Pglt0P8XV1sP37nF5ZSUzV1rAgWQvMH+9yqG rznlM1dHwgfoKz91IFw9mwxUelrFiQ9R58d9SmbqLQKMFhUS+9EO3yWTd1y9PUJka94J LpsDVmIYvN+KOCmXmaJ6Qevj2OKNGt+foOusPyPd4jtULxWLt+csQjR4UWow7qV+iJ9r htHpLR5SjgBrELvRbF1EK9UUIdGN0bYoUmb390BVM1WeJJ68dxQBXWM3stvYUGCvZTSb Qah8R9m4OVs9af/lUw4CZg98BuunpuUAbO3T06H/wIw2y0Xq1YtnVR7DzRKPI5wH38kY 2GkA==
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=H/zB/V+7uR1GJOlMTWq5zjGE9uhan5zQj8C7QXwQIrc=; b=ZmRcQ4pVLPY4iIUmgs8ykj66PYhG02/bkFr7cYrWtDj7JIQG3cxwk+eNaIyLo5ZA+Z ei8LnYQQrv6BFziafoOnKbIbv20Vc3zO360skBwVO3phqHVMeUZtEGrdKGVKj5VJZf9u hzA11fTcVcypiEt/5SdnW1bTp6KnVnZ3cCqSPpIcnKvIV415/LUoeNsg/mkaAiyoIe2e rkO7aklrj5YcucVoc/lRaaHiMEOt1UH4tpqUdJto47dbXIvOSU6I8lZkkZY+FgOdAfot 0VJWav4JUZbBahK21QiIsySgTz5Dz0aaEoeEvbRG5cOZeaIHpoqFMRMGfhq6VBOJAI5k yzuQ==
X-Gm-Message-State: AOAM533RJsanhhQVHktnYdJuynGEWqknsI2hVVZdH35H+zX/H3IWkNtQ /TF0aOGMLQYlfVQ57Cgcp85NujQQIuujsw==
X-Google-Smtp-Source: ABdhPJyJ3MNg/h4QTY4r9qE4dArpTVLgIykFkfx+qsYjAMqUyAp98r6rGV9gIEG37C2a3bHWGwMhtQ==
X-Received: by 2002:a17:902:968a:b029:11d:6448:1352 with SMTP id n10-20020a170902968ab029011d64481352mr33454032plp.59.1625892281124;  Fri, 09 Jul 2021 21:44:41 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id l12sm8029412pff.105.2021.07.09.21.44.39 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 21:44:40 -0700 (PDT)
To: rfced-future@iab.org
References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> <25bbe57b-f2fb-b07a-c5e4-0027156f03a7@nthpermutation.com>    <503630f1-5c96-d666-3951-1ecd5dcce5ff@mozilla.com>
From: Brian E Carpenter 
Message-ID: <6409f630-48ef-c6c4-b731-9e679adc049a@gmail.com>
Date: Sat, 10 Jul 2021 16:44:37 +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: <503630f1-5c96-d666-3951-1ecd5dcce5ff@mozilla.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Jul 2021 04:44:48 -0000

I thought the first proposal was necessary and sufficient.
(As a general rule, I think we should avoid narrow specification
when a broader one is sufficient.)

Regards
   Brian Carpenter

On 10-Jul-21 08:43, Peter Saint-Andre wrote:
> On 7/9/21 2:35 PM, Peter Saint-Andre wrote:
>> On 6/22/21 8:30 PM, Jay Daley wrote:
>>>
>>>
>>>> On 23/06/2021, at 2:19 PM, Martin Thomson >>> > wrote:
>>>>
>>>> On Wed, Jun 23, 2021, at 11:58, Michael StJohns wrote:
>>>>> Ultimately, legally and effectively, the timing and priority of any=20
work
>>>>> by the RPC is an LLC/RPC decision.=C2=A0 Ditto for any hired/contra=
cted for
>>>>> RSA/E (mutual agreement consistent with the contract/employment
>>>>> agreement).=C2=A0 So yes - the RSAB may say "deprioritize" vs RSWG
>>>>> "emphasize" at which point if there's disagreement, that's going to=20
be
>>>>> an interesting contractual discussion between the LLC contract mana=
ger
>>>>> and the RPC based on input from both the RSAB and the RSWG.=C2=A0 T=
hat's just
>>>>> reality and I don't really thing we need to spend a lot of time on
>>>>> trying to change how those levers of power are manipulated.=C2=A0 I=
f there's
>>>>> a massive failure later, AND someone has a better idea, AND it can =
be
>>>>> implemented through contractual language, THEN we can readdress thi=
s
>>>>> point.
>>>>
>>>> I wasn't suggesting that we needed to change the substance here, jus=
t
>>>> to change the emphasis on the text. =C2=A0You'll note that I just re=
worded
>>>> Jay's text, not changed the bullet points.
>>>>
>>>>> Which also has me asking a question:=C2=A0 Should the LLC provide a=20
liaison
>>>>> to the RSAB as mandatory requirement?
>>>>
>>>> Not mandatory, and I don't think we need formal encouragement for
>>>> everyone to be proactively consultative. =C2=A0I'd rather stay silen=
t (for
>>>> reasons similar to those you outline above).
>>>
>>> I think there should be an LLC liaison as a non-voting member. =C2=A0=
That=E2=80=99s
>>> what we have with RSOC and what I think is necessary for the LLC in i=
t=E2=80=99s
>>> role of setting the performance targets for the RPC and negotiating t=
he
>>> work plan budget/timetables.
>>
>> Proposed text:
>>
>>   To ensure the smooth functioning of the RFC Series, the RSAB may
>>   at its discretion include non-voting members, for instance liaisons
>>   from the IETF LLC or RPC.
>=20
> Or (option 2):
>=20
>   To ensure the smooth functioning of the RFC Series, the RSAB shall
>   include the IETF Executive Director as a non-voting member since
>   the IETF LLC is ultimately responsible for the operation of the
>   policy implementation function. The RSAB may at its discretion includ=
e
>   additional non-voting members, for instance a liaison from the RPC.
>=20
> Peter
>=20


From nobody Fri Jul  9 21:46:12 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB9C3A1BC4 for ; Fri,  9 Jul 2021 21:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 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.338, 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 rZx-8NyvbPUx for ; Fri,  9 Jul 2021 21:46:10 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523A13A1BC3 for ; Fri,  9 Jul 2021 21:46:10 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id 37so12039353pgq.0 for ; Fri, 09 Jul 2021 21:46:10 -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=+7UOUaQ/Gfz0906BDug1lzR97PRXlwiLLK71sIhJXX4=; b=FrKBq6GMflm+O+xTh2Gcb9L+d90av/FPl/6BWO4SO6WedCOviUZgNhV7ahG6BG15mj 4LaMRHqAFVLeZkGyjZCFjSbZ/Jw2VbyUXQCXpklz+vJOPbUMWcKmOiQ3Pe82dh0HyJqO 4EjP/6qlnAst9e9rX9P/ckhNxLxAT4QVSj3lXdNXUrVE2+GuwpHXmipKx4D3SNeIkhOo JJ0bB9b8iSo/e7BXKMgmHRUI7ZVquZPfcAQ93s5rXRWXpLfhOsM0ijdgBnsK5Dspzfyo 0pNY4WlAOmjMizrVNWfWty8XfB9EYxbRoIeH0rC98DPk/OiMErbfKqL0pMTRr7fJ0I6p oa8g==
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=+7UOUaQ/Gfz0906BDug1lzR97PRXlwiLLK71sIhJXX4=; b=S4NDzUB9364SGgeHeiqTA2sIYNa1EOuQFPF4bHMcbmsHp+Iy39zFCvwCqGmGDdRvd3 jSzA2EGD9u+XKyNWK0qTdWwGUNXi3j5yJazuPQXJICgjzn51pig8G7Ek+akCuOaiA5KC naav9pSjEqQLDnUh1Cnh1Dt1prr0NnC4ilC1k+M/t2qorMTz7wnEiwGlDkZb/RTVutzO Wn9MBKkpVHrNu8Sk80Tn3WRZbAMUvkzpEK3cFJy/1KWO8Xu45jz2RUd1d3MYmFxW8krN rB4wyPda56Nxv5j/i7P+uFTcLnKpCDcK8S1SSv8ep7YyIrGSp4Z8HshSrfRWxt+tPtDu MzeA==
X-Gm-Message-State: AOAM532W4VF9l6gcMDm9xczRkzMPxGNC/LwnXR2jUYXlM/H9B7bDwzE6 cA5rrdKRxRl08+vTD35LF51+ozciVyG9Ng==
X-Google-Smtp-Source: ABdhPJwBc8p0FGttd98lSTXAvDIx5BPT8yd43niPwPaFhIMXU8UWB84PmM8yQuC9pp8wbmfettY0TQ==
X-Received: by 2002:a05:6a00:24cf:b029:321:42f1:9f57 with SMTP id d15-20020a056a0024cfb029032142f19f57mr28158539pfv.77.1625892369328;  Fri, 09 Jul 2021 21:46:09 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id x24sm7752647pfu.209.2021.07.09.21.46.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 21:46:08 -0700 (PDT)
To: Peter Saint-Andre , "rfced-future@iab.org" 
References: 
From: Brian E Carpenter 
Message-ID: 
Date: Sat, 10 Jul 2021 16:46:05 +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: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Jul 2021 04:46:12 -0000

On 10-Jul-21 09:03, Peter Saint-Andre wrote:
> The role played by the technical publishing expert in version 3 of the
> model is different enough from past roles that I suggest we should not
> use the name "RFC Series Editor" but instead "RFC Series Advisor".

If I didn't say "+1", I would be contradicting myself ;-).

   Brian


From nobody Fri Jul  9 22:00:43 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CE03A1C75 for ; Fri,  9 Jul 2021 22:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 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.338, 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 h0BYegx5K35J for ; Fri,  9 Jul 2021 22:00:37 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 32F5F3A1C73 for ; Fri,  9 Jul 2021 22:00:37 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id f5so12029643pgv.3 for ; Fri, 09 Jul 2021 22:00:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yE5VpMO1EhUV+DAy1xPtcX0zbYOr/IQko7BlAqer5b8=; b=cyqKkp81MVlmbeGJwhi3ve7M0T8+5OrvwqURBx0RlJXqhgPqlPBwDVqUb8aQO/XJF2 FDuvKKj+wHOstwKNetp3a4K4xvU4lgdKMyFpsgKOlu6LPE6tKoqqvqn6+Uu5T01J7kEV vmy6N9tl5e53TuNImFedFBSPdTQcIMwR6rtLaczbI4Uhs+iKyfkA/WwqmLIhwvBxfgMJ q7VmxV0ixS8hBLNDfX1wkKrFZB/K4thBQ4X6oCVY6q8kmnRyaeY19OxI5+y5OyUfUe/C cX2y6Aa0o7ynk70H+OZ0pH/u34r0e8PsdTl6UGBTYT7DFQj3BmVlTREfcE0V7AzhlazS 1YtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yE5VpMO1EhUV+DAy1xPtcX0zbYOr/IQko7BlAqer5b8=; b=d5S/LQJn1tF/w8QUxashODseyR8kCmDh7aCplocyZr3YmBeBssvE1wkb7OaPNgcu2P B1x0lFReXiDXst2f6d7Z8FoUmPkW44HNbItNTismIykJ2mZTT2e7BrO2wZEK/cYKSaeJ E1WvKkXiJP3fa7RjlCSmzFNCXY4htkmPYOGq9nfpfNLiMYZ3YBasp+hkcLXPFlWJpU7t a4PZ/VaVCh0ZAsE+spol6Lj+4GyCyG6F93+VluzkQBTmsBx4ejiHGW0olZr0HIWCgxB5 Jt5gBGmNiZpGWnhTIa4bRHVAfZD2KQ+MM/UwuQy1Q4nckBR0cJUVfN3gbmvjpqr8cQte iBPg==
X-Gm-Message-State: AOAM530+rwPOlpYN+1Vg8KdWWI8ZwLfkvh9PrYBQa4Dyx5ke/D5Oe4NQ M7y5QT/ow5yGMMuqMFCykY/qC/jarRooOQ==
X-Google-Smtp-Source: ABdhPJzMWT8Lyx0LIJJtCQnsOc0YLCoe2ibgzNMCqBIIpSLHwRlHGKj4i4aBZt1jRZ1ibMaboVhzBA==
X-Received: by 2002:a63:3d08:: with SMTP id k8mr6717086pga.147.1625893236039;  Fri, 09 Jul 2021 22:00:36 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id j2sm8017571pfi.111.2021.07.09.22.00.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 22:00:35 -0700 (PDT)
To: John C Klensin , Eliot Lear 
Cc: rfced-future@iab.org
References:  <9CCFECFF41DD399EA4AB89BE@PSB>
From: Brian E Carpenter 
Message-ID: 
Date: Sat, 10 Jul 2021 17:00:31 +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: <9CCFECFF41DD399EA4AB89BE@PSB>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] A voice from the (perhaps lunatic) fringe (was: draft-saintandre-rfced-model-01.txt)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Jul 2021 05:00:42 -0000

Long ago I promised to comment on issues #1 and #2 below
(having commented on #3 immediately):

On 22-Jun-21 07:08, John C Klensin wrote:
>=20
>=20
> --On Monday, June 21, 2021 15:54 +0200 Eliot Lear 
> wrote:
>=20
>> Everyone,
>>
>> Please have a good look at Peter's and*your*latest work
>> before today's call. =C2=A0We've come a long way. =C2=A0Now we
>> still have a ways to go, but a fresh read of this draft will
>> help us keep moving.
>>
>> https://datatracker.ietf.org/doc/draft-saintandre-rfced-model/
>=20
> I'm quite sure that I'm far out in the rough part of "rough
> consensus" but. after studying Peter's latest draft (which I
> think is excellent given the discussions) and the on-list
> discussions of the last few weeks, I think we are, very
> fundamentally, headed in the wrong direction with significant
> philosophical problems in what we are proposing and doing.  I
> would be surprised if this note changes the minds of anyone
> reading it and would even be surprised if most of the group
> bothers to read it at all.  However, because I see dangers in
> the direction in which things are headed, I'm feeling a need to
> try to summarize a perspective and set of positions that have
> been raised before and largely ignored.  If I were right, most
> of the discussions of recent months are not analogous to
> rearranging the deck chairs on the Titanic; they are about
> forming committees to develop policy for such rearrangements,
> other committees to review and validate the work of the first
> committee, and mechanisms for reviewing that process.  Glug,
> glug,...
>=20
> Core issue #1: The function of the RFC Editor Function.   The
> RFC Series predates the IETF by many years.  Even though it
> became the primary venue for publishing IETF work and we have
> made adjustments along the line, neither RFC 5620 nor 6335/8728
> fundamentally changed that model.  However, from Jon and Joyce
> through at least most of Heather's tenure, decisions have been
> made informally and depending on the assumption that everyone
> involved is an adult with shared goals about good quality
> documents and a better Internet (and ARPANET before it).  It
> worked well almost all of the time; when it didn't, things got
> sorted out on, more or less, a Do The Right Thing principle.  We
> are now trying to make rules and structures to cover every
> possible case.

Are we really, though? This is certainly a point we need to
keep in mind when reviewing the proposal as a whole. Are we
defining anything that doesn't *need* to be defined in advance?
If so, delete it.

> That has rarely worked well, if only because it
> encourage little disagreements to turn into large, formal,
> decision-making processes.  In addition, the IETF part of the
> puzzle is changing.  RFCs may still be the formal publication of
> record, but far more, including documentation of rather
> fundamental policy decisions, is being done by blogs,
> statements, datatracker entries, etc.  That may be fine, but it
> may suggest that some clear redrawing of boundaries is important
> ... and this effort is not addressing those issues.

Indeed. But there's close to a continuum between a casual idea
mentioned on your favourite instant messaging tool through
wiki pages, pull requests, blogs, I-Ds, etc etc, up to formal
publication in an archived series. If we get to "living
standards" documents as hinted in #3 below, whether they fit
in the formal & archived category or not must be addressed.
=20
> Core issue #2: The question of expertise.  While Heather was the
> first person to be in charge of the Series who came out of a
> professional publications background, all of her predecessors
> understood what they didn't know and were good (some better than
> others, of course) at asking questions, understanding, learning,
> and thinking through the answers, and then making decisions
> using that advice and being willing to be accountable for it.
> The new approach is modeled on IETF WGs, but ignores a
> fundamental assumption built into the WG model: that a large
> majority of the participants in a WG will have significant
> expertise in the subject matter.  While I hope we are evolving
> better ways to deliver the message, when people have spoken up
> in WGs who have no ideas what they are talking about and are
> persistent about it, WGs usually have ways to deal with that
> behavior.   By contrast, most people who have participated
> actively in the IETF for any length of time have probably
> noticed that the issues that call forth the most passion and the
> longest threads on the IETF list and elsewhere are those about
> which people have little expertise but strong opinions of one
> type or another.  What I'm about to say may smack of elitism,
> putting me further into the rough, but I note that we do not
> think highly of, e.g., politicians trying to design network
> architectures and protocols.  If our goal is to create
> structures that turn the RFC Series into something the fraction
> of the IETF community who are willing and able to invest large
> amounts of time on these things want (perhaps at the expense of
> doing Internet technical work), then I think we are right on
> track.   But, noting that subset of the IETF community is almost
> certainly not representative of IETF participants generally much
> less the broader Internet community, that is a very significant
> change in objectives.  If we are going to do that, we should be
> explicit about it.  If we are not, the idea of open
> participation to anyone who wants to be involved and has the
> time, with no expectations about expertise falls into the "be
> careful what you wish for" category.

It's a fair warning, but it seems to me that the people here
(and that is not the 40k+ people covered by Jay's recent survey)
are convinced that we should reject kings, presidents and Editors.
So I think that means accepting the risk that a bunch of amateurs
will decide that they know best, whatever the expert says.

Something like =E2=80=9CDemocracy is the worst form of government,
except for all the others.=E2=80=9D

   Brian

>=20
> (3) Core issue #3: What is a standard and what is a stable
> document?  While, ideally, it should not be a required part of
> this discussion, it appears to me that there is an ongoing
> difference of opinion in the IETF was to whether standards (and
> perhaps IETF Stream documents in general) should be stable
> specifications that may periodically be revised or replaced but
> are otherwise threaded together with "updates" and "obsoletes"
> designations (possibly supplemented by organizing documents
> along the lines proposed by NEWTRK) or whether we want to move
> more toward living documents that are updated in place with each
> correction, changes of experience, or change in community
> opinion about one or more points.  If we are going to move more
> in the latter direction, it could have a profound effect on the
> RFC Series, either because IETF Standards and other normative
> specifications come out of the Series, dramatically changing the
> mix of documents, or because the system has to adjust to a
> completely different type of documents for which, e.g., the
> current production model might not be correct for at least a
> subset.  While a lighter-weight structure might have more
> ability to adapt to such changes, the current effort to specify
> details and create an elaborate discussion and approval process
> seems less likely to do so, especially if the RSWG/RSAB
> structure ends up not completely agreeing with, e.g., the IESG.
> The solution is presumably obvious: Convene another Program or
> WG to more or less start over.  Unfortunately, we are pushing
> toward two years of limited functionality since the actions that
> apparently convinced Heather that she didn't want more of
> whatever was going on.  I think that has been very damaging and
> that a repeat would be more so.  Others probably disagree but I
> would ask them whether, if we can go two or more years without
> an RSEA or any of the structure now proposed, should we be
> trying to see what we can learn from that and devise something
> much lighter weight on the basis of the experience?
>=20
> (4) Core issue #4: What got us here and are we fixing it?  The
> chain of events that led to this Program/Group could be seen
> either as an assertion of power by some bodies over the RSE (aka
> "the RSE is 'just' a contractor") or an asser5ion of authority
> by groups who lacked substantive expertise (see (2) above),
> neither with any transparency as far as the broader community
> was concerned.  It seems to me that the new model probably fixes
> the transparency problem, but does so partially by increasing
> the number of non-expert people and organizational structures
> with an ability to meddle and/or interfere with keeping a clear
> focus on consistent objectives.  Is that a solution?  For those
> who think it is, consider how you would feel if you took a
> network engineering job, discovered that you were managed by a
> committee or two, none of whose members understood your job or
> your areas of expertise, and whose objectives might shift over
> time (either because of changing membership or to convince
> themselves or others that they were being useful).
>=20
> I have a longer list, but it is probably better that I keep this
> rant (comparatively) short and get it out.
>=20
> Do I have alternate suggestions?  Yes, but they depend on
> changes in the decisions about the issues identified above even,
> or especially, when those decisions were made implicitly or
> because we started erecting structures without really addressing
> them in a way that made those decisions moot.
>=20
> Grumpily and from, probably, far out in the rough,
>    john
>=20
>=20


From nobody Sat Jul 10 11:03:42 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4413A1069 for ; Sat, 10 Jul 2021 11:03:39 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 EXGnpSv_ZsGn for ; Sat, 10 Jul 2021 11:03:35 -0700 (PDT)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 485A53A1067 for ; Sat, 10 Jul 2021 11:03:35 -0700 (PDT)
Received: by mail-oi1-x22d.google.com with SMTP id j65so10967084oih.5 for ; Sat, 10 Jul 2021 11:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:to; bh=jRTXhDtzeSya4MRdjlEOOZe4QmgkZWZG2zGr3FsoZQw=; b=IwMLK4spuVOivW2vj4aNNc99av3j/GCdfueDdKH6JnlZzlgtyheQNaUkgI06xCk5r3 QPpVLtcDjCNJREbZ3ZBbBzOhKmAGiHaPOsDMJOIEoHCqIta4PzGehDAoW+wjPcRitZPa 23ScUdMoc86psParctp+ph0A5HlhFia1eBtt0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:to; bh=jRTXhDtzeSya4MRdjlEOOZe4QmgkZWZG2zGr3FsoZQw=; b=n8A9NQoGnsgmIFzf25SOp8440budlUpEq0KZDz+mpnJykIsLUGXd+xBkckFNCpjovX 3UBFOG62dqW95XsWqGOJCpiZTSR7JWUfUcfnf2y4xoLK+MtrxTzqdUKg4WCn848We6rc Oxo5pax9/FMtHj3v2TqOsfqs5AYwC2DVV22YLkYrF6vZmrLSioX18L6yv4Rjj5dEOV2m xU1dn/I4A3ZT2MXb9dEh2PAh7wojO+PtoZJ83f83PGFBSbIdoiOVmI2/+g7ISBX5rIiX cKtqELJUL1iFxK5q88MhGI3ykCe72nUrSHwmtrqg5TNzhAfiECWa0xmtjaEpPBqbRynC ozmg==
X-Gm-Message-State: AOAM5310UWR6mv2bVBaFl53GwDLmy3XZ3+e+rlRE9YIaQEJnRyapZxn6 G+eA67mh4oe185b0KZCJOq59wA==
X-Google-Smtp-Source: ABdhPJz5gwnzvT9aQDMoeoyvcRMDhVr5C3ioNaT7iSDnVrFhkjQgaLSyOBx7B9V7Ixcpbj1ycHztfw==
X-Received: by 2002:a05:6808:101:: with SMTP id b1mr4268991oie.106.1625940213988;  Sat, 10 Jul 2021 11:03:33 -0700 (PDT)
Received: from [192.0.2.1] ([8.48.134.27]) by smtp.gmail.com with ESMTPSA id x130sm1976997oix.22.2021.07.10.11.03.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jul 2021 11:03:33 -0700 (PDT)
From: Peter Saint-Andre 
Content-Type: multipart/alternative; boundary=Apple-Mail-B71911FE-B8FA-479C-B4FF-7775C75F44CB
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Sat, 10 Jul 2021 12:03:32 -0600
Message-Id: 
References: 
To: rfced-future@iab.org
X-Mailer: iPhone Mail (16H50)
Archived-At: 
Subject: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Jul 2021 18:03:40 -0000

--Apple-Mail-B71911FE-B8FA-479C-B4FF-7775C75F44CB
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable


>=20
> Begin forwarded message:
>=20
>> From: internet-drafts@ietf.org
>> Date: July 10, 2021 at 1:58:09 AM MDT
>> To: "Peter Saint-Andre" 
>> Subject: New Version Notification for draft-iab-rfcefdp-rfced-model-00.tx=
t
>>=20
>>=20
>> A new version of I-D, draft-iab-rfcefdp-rfced-model-00.txt
>> has been successfully submitted by Peter Saint-Andre and posted to the
>> IETF repository.
>>=20
>> Name:        draft-iab-rfcefdp-rfced-model
>> Revision:    00
>> Title:        RFC Editor Model (Version 3)
>> Document date:    2021-07-09
>> Group:        iab
>> Pages:        20
>> URL:            https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-m=
odel-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-iab-rfcefdp-rfced-=
model/
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-r=
fced-model
>>=20
>>=20
>> Abstract:
>>   This document describes Version 3 of the RFC Editor model.  As
>>   specified here, the model divides the responsibilities for the RFC
>>   Series into two high-level functions: policy definition governing the
>>   Series as a whole, and policy implementation through publication of
>>   documents in the Series.  The policy definition function is the
>>   responsibility of the RFC Series Working Group (RSWG), which produces
>>   policy proposals that are subject to approval by the RFC Series
>>   Approval Board (RSAB).  The policy implementation function is
>>   primarily the responsibility of the RFC Production Center (RPC),
>>   under the ultimate authority of the IETF Administration Limited
>>   Liability Company (LLC).
>>=20
>>   This document reflects experience gained with version 1 of the RFC
>>   Editor Model as specified in RFC 5620 and with version 2 as specified
>>   in RFC 6635 and RFC 8728.
>>=20
>>   This document obsoletes RFC 8728.
>>=20
>>=20
>>=20
>>=20
>> The IETF Secretariat
>>=20
>>=20

--Apple-Mail-B71911FE-B8FA-479C-B4FF-7775C75F44CB
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



Begin forwarded message:

From: internet-drafts@ietf.org
Date: July 10, 2021 at 1:5=
8:09 AM MDT
To: "Peter Saint-Andre" <stpeter@jabber.org>
Subject: New Version Not=
ification for draft-iab-rfcefdp-rfced-model-00.txt


A new=
 version of I-D, draft-iab-rfcefdp-rfced-model-00.txt
has be=
en successfully submitted by Peter Saint-Andre and posted to the
<=
span>IETF repository.

Name:     &=
nbsp;  draft-iab-rfcefdp-rfced-model
Revision:   &=
nbsp;00
Title:        RFC Editor Model (=
Version 3)
Document date:    2021-07-09
=
Group:        iab
Pages:   &n=
bsp;    20
URL:      &nbs=
p;     https://www.ietf.org/archive/id/draft-i=
ab-rfcefdp-rfced-model-00.txt
Status:    =
     https://datatracker.ietf.org/doc/draft-iab-rfc=
efdp-rfced-model/
Htmlized:     &nbs=
p; https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-mo=
del


Abstract:   This document describes Version 3 of the RFC Editor mod=
el.  As
   specified here, the model divides t=
he responsibilities for the RFC
   Series into two=
 high-level functions: policy definition governing the
 &nbs=
p; Series as a whole, and policy implementation through publication of<=
/span>
   documents in the Series.  The policy defin=
ition function is the
   responsibility of the RFC=
 Series Working Group (RSWG), which produces
   po=
licy proposals that are subject to approval by the RFC Series
   Approval Board (RSAB).  The policy implementation functi=
on is
   primarily the responsibility of the RFC P=
roduction Center (RPC),
   under the ultimate auth=
ority of the IETF Administration Limited
   Liabil=
ity Company (LLC).

   This docume=
nt reflects experience gained with version 1 of the RFC
 &nb=
sp; Editor Model as specified in RFC 5620 and with version 2 as specifi=
ed
   in RFC 6635 and RFC 8728.

   This document obsoletes RFC 8728.




The IE=
TF Secretariat


=

--Apple-Mail-B71911FE-B8FA-479C-B4FF-7775C75F44CB--


From nobody Sun Jul 11 00:37:41 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8BA3A24E9 for ; Sun, 11 Jul 2021 00:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.19
X-Spam-Level: 
X-Spam-Status: No, score=-0.19 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV3E70LqDjZk for ; Sun, 11 Jul 2021 00:37:34 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 378D33A24E4 for ; Sun, 11 Jul 2021 00:37:33 -0700 (PDT)
Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:e5a1:8874:c101:7d37]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16B7bTv7173470 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 11 Jul 2021 09:37:30 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625989051; bh=DWE1mYlIRjlduV7fDwRSoLWbbZLocGZAIPsl64ZAkB4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=C538NlmWIFy8dM900RaumoBqZR8O/CsX5lsCCPa77IwzF35C7ETxnwZfXc0BSGejP rh7+Wn7zbEqGuNIa+Yf8XGJHjtBJoAjkRKjByk7nhVVyzI7BW/SEmAg5MwPXmgWvNO fgm13vP10Z04K1eRpsy6FMUfKJa8eK/IUKrKP9FM=
To: Peter Saint-Andre , rfced-future@iab.org
References:  
From: Eliot Lear 
Message-ID: <855b2143-dedb-a08d-ce5f-84a927ae44a1@lear.ch>
Date: Sun, 11 Jul 2021 09:37:27 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7OtE97EDlPun9p78FzsS3KQY80Z3fioKj"
Archived-At: 
Subject: Re: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-00.txt
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Jul 2021 07:37:39 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--7OtE97EDlPun9p78FzsS3KQY80Z3fioKj
Content-Type: multipart/mixed; boundary="vVdZcabzdYCKgIWmzl2Nf29kMVvMi1w0F";
 protected-headers="v1"
From: Eliot Lear 
To: Peter Saint-Andre , rfced-future@iab.org
Message-ID: <855b2143-dedb-a08d-ce5f-84a927ae44a1@lear.ch>
Subject: Re: [Rfced-future] Fwd: New Version Notification for
 draft-iab-rfcefdp-rfced-model-00.txt
References: 
 
In-Reply-To: 

--vVdZcabzdYCKgIWmzl2Nf29kMVvMi1w0F
Content-Type: multipart/alternative;
 boundary="------------A6779A3DDEC32AA452814D79"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------A6779A3DDEC32AA452814D79
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Thank you very much, Peter, for helping us reach this milestone.

Eliot

On 10.07.21 20:03, Peter Saint-Andre wrote:
>
>>
>> Begin forwarded message:
>>
>>> *From:* internet-drafts@ietf.org 
>>> *Date:* July 10, 2021 at 1:58:09 AM MDT
>>> *To:* "Peter Saint-Andre" >> >
>>> *Subject:* *New Version Notification for=20
>>> draft-iab-rfcefdp-rfced-model-00.txt*
>>>
>>>
>>> A new version of I-D, draft-iab-rfcefdp-rfced-model-00.txt
>>> has been successfully submitted by Peter Saint-Andre and posted to th=
e
>>> IETF repository.
>>>
>>> Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-iab-rfcefdp-rfced-model
>>> Revision: =C2=A0 =C2=A000
>>> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC Editor Model (Version 3)
>>> Document date: =C2=A0 =C2=A02021-07-09
>>> Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0iab
>>> Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A020
>>> URL:=20
>>> https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-model-00.txt =

>>> 
>>> Status:=20
>>> https://datatracker.ietf.org/doc/draft-iab-rfcefdp-rfced-model/=20
>>> 
>>> Htmlized:=20
>>> https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model=20
>>> =

>>>
>>>
>>> Abstract:
>>> =C2=A0=C2=A0This document describes Version 3 of the RFC Editor model=
=2E =C2=A0As
>>> =C2=A0=C2=A0specified here, the model divides the responsibilities fo=
r the RFC
>>> =C2=A0=C2=A0Series into two high-level functions: policy definition g=
overning the
>>> =C2=A0=C2=A0Series as a whole, and policy implementation through publ=
ication of
>>> =C2=A0=C2=A0documents in the Series. =C2=A0The policy definition func=
tion is the
>>> =C2=A0=C2=A0responsibility of the RFC Series Working Group (RSWG), wh=
ich produces
>>> =C2=A0=C2=A0policy proposals that are subject to approval by the RFC =
Series
>>> =C2=A0=C2=A0Approval Board (RSAB). =C2=A0The policy implementation fu=
nction is
>>> =C2=A0=C2=A0primarily the responsibility of the RFC Production Center=
 (RPC),
>>> =C2=A0=C2=A0under the ultimate authority of the IETF Administration L=
imited
>>> =C2=A0=C2=A0Liability Company (LLC).
>>>
>>> =C2=A0=C2=A0This document reflects experience gained with version 1 o=
f the RFC
>>> =C2=A0=C2=A0Editor Model as specified in RFC 5620 and with version 2 =
as specified
>>> =C2=A0=C2=A0in RFC 6635 and RFC 8728.
>>>
>>> =C2=A0=C2=A0This document obsoletes RFC 8728.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>>
>

--------------A6779A3DDEC32AA452814D79
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Thank you very much, Peter, for helping us reach this milestone.
    
Eliot

    

    
On 10.07.21 20:03, Peter Saint-Andre
      wrote:

    

    

      
      

      

        

          


            Begin forwarded message:

            

          

          

            
From: internet-drafts@ietf.org
=

              Date: July 10, 2021 at 1:58:09 AM MDT

              To: "Peter Saint-Andre" <stpeter@jabber.org>

              Subject: New Version Notification for
                draft-iab-rfcefdp-rfced-model-00.txt

              

            

          

          

            


              A new version of I-D,
                draft-iab-rfcefdp-rfced-model-00.txt

              has been successfully submitted by Peter Saint-Andre
                and posted to the

              IETF repository.

              

              Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-iab-rfcefdp-rf=
ced-model

              Revision: =C2=A0 =C2=A000

              Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC Editor Model (V=
ersion 3)

              Document date: =C2=A0 =C2=A02021-07-09

              Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0iab

              Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A020

              URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0https://www.ietf.org/archive/i=
d/draft-iab-rfcefdp-rfced-model-00.txt

              Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0https://datatracker.ietf.org/d=
oc/draft-iab-rfcefdp-rfced-model/

              Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/d=
oc/html/draft-iab-rfcefdp-rfced-model

              

              

              Abstract:

               =C2=A0=C2=A0This document describes Version 3 of the=
 RFC
                Editor model. =C2=A0As

               =C2=A0=C2=A0specified here, the model divides the
                responsibilities for the RFC

               =C2=A0=C2=A0Series into two high-level functions: po=
licy
                definition governing the

               =C2=A0=C2=A0Series as a whole, and policy implementa=
tion
                through publication of

               =C2=A0=C2=A0documents in the Series. =C2=A0The polic=
y definition
                function is the

               =C2=A0=C2=A0responsibility of the RFC Series Working=
 Group
                (RSWG), which produces

               =C2=A0=C2=A0policy proposals that are subject to app=
roval by
                the RFC Series

               =C2=A0=C2=A0Approval Board (RSAB). =C2=A0The policy =
implementation
                function is

               =C2=A0=C2=A0primarily the responsibility of the RFC
                Production Center (RPC),

               =C2=A0=C2=A0under the ultimate authority of the IETF=

                Administration Limited

               =C2=A0=C2=A0Liability Company (LLC).

              

               =C2=A0=C2=A0This document reflects experience gained=
 with
                version 1 of the RFC

               =C2=A0=C2=A0Editor Model as specified in RFC 5620 an=
d with
                version 2 as specified

               =C2=A0=C2=A0in RFC 6635 and RFC 8728.

              

               =C2=A0=C2=A0This document obsoletes RFC 8728.=


              

              

              

              

              The IETF Secretariat

              

              

            

          

        

      

      

      

    

  


--------------A6779A3DDEC32AA452814D79--

--vVdZcabzdYCKgIWmzl2Nf29kMVvMi1w0F--

--7OtE97EDlPun9p78FzsS3KQY80Z3fioKj
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDqn7cFAwAAAAAACgkQh7ZrRtnSejOB
ewgAw2QJ058r1v1rwqUbpJE27M/SNRAi+MrstAx5sAWo29z89ocmm9iO5ghCdK5s9PceiSy4ecWk
Jd6BAHS/pFlhZdmybcKwZJQY6XbPl6ouhU89v0Zf8lA7SmEf3EzWx5nOncXaPLwm7W4bU3p1ZnxU
TK88Id2+YYb/9NJenQLNumz+p/n62UzYfq1ZJXeQjy35BqagIOGzsjJx8hkb0IwY72FBNqiS6nIt
Ejsg23jyvGIlZlN1rANKhtXkVkRjieq0TyZKfg3ZSw+lW5AYW7mVmW0/irAkV0G5/7vSJ43Y9MZ/
0WEQXK6lWUuL0Cbu9M3jd+mCJPw5bT9B/+Z4TUm7hA==
=xlhG
-----END PGP SIGNATURE-----

--7OtE97EDlPun9p78FzsS3KQY80Z3fioKj--


From nobody Sun Jul 11 06:30:52 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15D73A132F for ; Sun, 11 Jul 2021 06:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.005
X-Spam-Level: 
X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1PktbueZDaj for ; Sun, 11 Jul 2021 06:30:47 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 A4FF63A132C for ; Sun, 11 Jul 2021 06:30:45 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16BDUgIj001558; Sun, 11 Jul 2021 14:30:42 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5D80F4604C; Sun, 11 Jul 2021 14:30:42 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 513BA4604A; Sun, 11 Jul 2021 14:30:42 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS; Sun, 11 Jul 2021 14:30:42 +0100 (BST)
Received: from LAPTOPK7AS653V ([195.166.134.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16BDUftK022052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 11 Jul 2021 14:30:41 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Peter Saint-Andre'" , "'Eric Rescorla'" , "'Eliot Lear'" 
Cc: 
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com>
In-Reply-To: <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com>
Date: Sun, 11 Jul 2021 14:30:41 +0100
Organization: Old Dog Consulting
Message-ID: <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJYLqiQ/XeTdq1mmedVrtykX7nyGwI9AqC2AbAelv8BWB++mKoSKA7Q
Content-Language: en-gb
X-Originating-IP: 195.166.134.8
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26274.007
X-TM-AS-Result: No--8.590-10.0-31-10
X-imss-scan-details: No--8.590-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26274.007
X-TMASE-Result: 10--8.590400-10.000000
X-TMASE-MatchedRID: rYpa/RC+czHkQwDXuLnCoXFPUrVDm6jtv8jdqvFOu+JSMKT1gdNFdn/W Du2EM8cZpz2zmd/LUEPZq7KnwCRxJrl7A3O5D6aXGUlF/M3Dxp/ic2JqBZEdqp20WOXA/NsCoCy y4pUARDe1CEyS0lv4cu2cyuFOC/C0JnnhbG2etMNRUg+O1TsbkhHlzzcojFNO8DnqkZbEZZierZ cAhZL2PppoFjCUvmU+Ah8W5oynYbfMb22XrRFMnNkHtQ1akR8vv+Qg1T/0LH4fza+IncS8fz11q DA2H+Xsoeiq4rYt7pLwpcCKD24C07VOJaplYKiP9uIPtqMvtZDLvfc3C6SWwoe/yi1B5QhCDSml bGhIRQHYd95zD4odNWti+8bXIBakuVw1xSf6tag1M1qoT3ENliGZtiDVlw6ezFD45Y9raeRpTXM 2NIspHFZJrjHNLwRqeb3f20kKgFI+D3J+ThgLRgI6gMblpHUxeQcbUqMm1kQY3xDPQbHgfvbpIT sbsw2ILdJtM173xww0swrGthudGnjWEqrIFFVBCbqZbMjTXcdNfoANulgf0YtkBWmEtb9tKrauX d3MZDUMFsa+1wyh/P3AViuv25B5tW0MbjIJObeHXB0sDcf4CS7cj8S0w+wboLg3Bli2QnJDDKa3 G4nrLQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Jul 2021 13:30:52 -0000

I *still* don't object to this, but (just so you know) you haven't =
convinced me this isn't odd.

When, in the course of my life in general, I delegate some task, I =
delegate to someone I think is capable of carrying the task. Yet I =
remain completely responsible for their performance. If they screw up in =
any way, then I am responsible: of course, I might remove them from =
their delegated role, but more importantly I should be held responsible =
for their actions and for the act of delegating to them.

I don't see, in view of this, why it is a requirement that the Head of =
the IETF Stream can only delegate to another AD.=20

Cheers,
Adrian

-----Original Message-----
From: Peter Saint-Andre =20
Sent: 09 July 2021 18:41
To: adrian@olddog.co.uk; 'Eric Rescorla' ; 'Eliot Lear' =

Cc: rfced-future@iab.org
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members

My apologies for the delayed response. I'm working in batch mode. :-)

Updated proposed text:

The IAB and IESG delegates must be selected by the Nominating
Committee {{RFC3777}} to their respective bodies (i.e., they
must not be liaison or ex-officio members). These delegates shall
serve for one-year renewable terms. If it becomes necessary to
replace such a delegate for any reason, then for the sake of continuity
the IAB or IESG should name a new delegate to complete the term.

Further comments below.

On 6/29/21 7:28 AM, Adrian Farrel wrote:
> I agree with Ekr about replacing for any reason.
>=20
> =20
>=20
> I don=E2=80=99t oppose any of these delegation rules, I just find them =
odd.
>=20
> =20
>=20
> The delegating body remains completely responsible for the actions of
> the delegate, so:
>=20
>   * Why does it matter where the delegate is drawn from?

AIUI the idea is that IAB and IESG delegates need to be selected by the
Nominating Committee so that:

(1) they are not liaison or ex-officio members, which would be strange
(the IAB chair could be the IESG delegate!)

(2) normal recall processes can be applied if necessary

>   * Why set specific term limits in this document (surely that is up =
to
>     the delegating body)?

In practice I doubt that it makes much difference, but I suppose terms
could be 2 years instead of 1.

>   * Why can the IRTF chair and ISE also delegate?

Perhaps because then the "reporting" lines become unclear.

Peter


From nobody Sun Jul 11 21:08:43 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743943A2D4F for ; Sun, 11 Jul 2021 21:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-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=itaoyama.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 yAl4v9iObtgd for ; Sun, 11 Jul 2021 21:08:35 -0700 (PDT)
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400109.outbound.protection.outlook.com [40.107.140.109]) (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 93E4B3A2D53 for ; Sun, 11 Jul 2021 21:08:35 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Afggq9b07dnBKyYSoFpJD653nScg7nTlepFHUL75gButh/O7Qf29SwiV/ZvabpvhefRxP233zPz4SSVqMuk7GsguwdJefzo4dp8OYznfxYFKmMVtYjlRsuC+dH6ry12T9MmxZSTEKLMOKSWFgskaIs/BK5gReaicx2VtvxKiGhHWtcfUTQDOIFR8p0EEboLy+VUJ9mVCGbWhdmIwhoCoJ4CFtPhhy75iY29wCbzlR1nryncjHz2do8RTedvZoscbZ5kWTwaTn/l+jcpyC92FqdpS5xR32gyczGiN+pvXAMHw/tnhQ8qq7JPe1vngF7wc2xwttdG0vXJDmsEFzw7s9Q==
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=ehes1WM1SBgp/pBwJsuhJb6vIG+RDAmsJWOSJlfNTGo=; b=fWcAPmF/2xG1Tii9Y30lLuN5z6IK76y6ksBi/Un3gw52+mAzwtntFA2rR2EQ7W0xOujm1Cc16yxs8oiAwm/IVI/HkqbT7glKhY4T0CadXknXm+cS8YRCllZBAhEmG1/3qMsXZzmaZTMbXMf9KOignleGGEmy2+8QM33UoZIjVNjo5t+KZhluIY2ECN9lvWVdteWFee8pmHoDy+7wUQNEozIIvZzf59R4n5zExJYU1flC07kK1Wr+rED2r6eiyjrGW6l68GLxWcO5OC8ovCik+6kYuoL8fKgTkxhnJMPJjNZg+uJJJX70A4E2kDrvtHjNJJVuhJ8b3bY8EFP0r6EiwQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ehes1WM1SBgp/pBwJsuhJb6vIG+RDAmsJWOSJlfNTGo=; b=KKkV3je+qhd/f46n4hx30Ksvl6M+qYhz0GZACs5HXzCii9BnN17JDZ3mGRR39zUnTHauW8whNkyvZUIDXbbXrSAq8JYHI+KbwkpZRPNmsE0XF1+qipLZ9jK3g+6pJRR2X8hU0GHaQS6WFIDDfS/iHV8OtotLFzr17dknE20b6UE=
Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp;
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYAPR01MB3150.jpnprd01.prod.outlook.com (2603:1096:404:8e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.21; Mon, 12 Jul 2021 04:08:32 +0000
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b%6]) with mapi id 15.20.4308.026; Mon, 12 Jul 2021 04:08:31 +0000
To: Brian E Carpenter , Peter Saint-Andre 
Cc: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>    <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com>  
From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: 
Date: Mon, 12 Jul 2021 13:08:30 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: TYAPR01CA0091.jpnprd01.prod.outlook.com (2603:1096:404:2c::31) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [133.2.210.39] (133.2.210.39) by TYAPR01CA0091.jpnprd01.prod.outlook.com (2603:1096:404:2c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20 via Frontend Transport; Mon, 12 Jul 2021 04:08:30 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 7b4b7116-59d6-4304-32eb-08d944eab596
X-MS-TrafficTypeDiagnostic: TYAPR01MB3150:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: cEMFVz8QTj/lLoM35lbLj5X6E6nQR7+JOnAHrE5fimqi/ESaktNZFW8RH3mQUDukQm4ZK8NjJGF/3BTQaPfT5MxJyNL4PkZmyd3G7S52hUulwV6f+kJMn2sCj/4b5TJ41Yae30Kr7uGwoupH6yrWm0bv1SK9Hcj20KrrCeGgWfSYNWXSl5ntrQgq6a6P+72pnzupMgPK0zo5maCS4w23RnjCmPKucHW/VgZSCr6zehfPzprKvOYoS2jRzC3hzv9LnAbuMPeNufRDXh5+MnKj1N+RQ2TKiFR1X3CYjNIPsW/22rQ4tYhjprJJqcUN4TOv0xj0T3R178VF2P0jRSbvV3SYKxLTaM7xfq5y7/BktnGHLzrYw3qh1UVSakCKtzkl1MpJpC/WeuiSREHIY15XH7y7svkXFhYaajsmi9aTWF8weVL3hpifJBBuJwUZb0AX1oBrLv4Ixr74Hfqp2FmwGtuwff33oSkyG4RZjjPuCb12pk1xPlOsmCVwHZRB1PjF5lAWWa5KlbmlC9F/9s/v7VWs7WVFMZE1CqIcEM+cJu1hvfALrohjImXnebHDqS4d0k1Z03byYxu1niARjMYocUChO8SFnyxMQBbg/HEJqkUY32TwwAjkrpNQAmd08IUrmb8ztPqKw2Cg5EcCQGpc4lp6XcwAF6cxx8vrat2059RmvRobtPkNiLP+vMIo+fBrhYBSoHWwGtx5ZUJJDD1ZhQAamk1/0vsLj4AtWqjsJtR5qqNqzIPMNS2lnIVKS32rnA7IzK6hmi63sufASloIu/kF17PwSq1l5UUdVjEblbg=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE;  SFS:(366004)(39840400004)(376002)(136003)(396003)(346002)(66574015)(31686004)(66476007)(2906002)(478600001)(38350700002)(66946007)(110136005)(31696002)(26005)(66556008)(186003)(86362001)(36916002)(5660300002)(52116002)(8676002)(53546011)(6706004)(786003)(316002)(6486002)(4326008)(8936002)(16576012)(2616005)(956004)(38100700002)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MjVNWjdRaDRkL3ZEZHVhdTExM3dnVFVpY0EzQlhsNU9ianpZbFNhbEZaRlN0?= =?utf-8?B?ZnhiSCtMRy9xQkxNaGxqQWsyR0Y1VnhHUnR1a2JFZVpaNFo0VGR4cjBtVHVh?= =?utf-8?B?QnQraWZoYVdnalRBU2x4MXFjZzQ4ZHVSSUt2VlFtU29hcFoxemVwbVBIbzEx?= =?utf-8?B?NmNrU0swRjJQdmQxQ1puaEp2aktKSkdaMllWWUtJZjI5Wk9PcnErUitmYnFz?= =?utf-8?B?M2lhLy9Ca0EvOFg1QzZuZmQranMrYzkrV2crUXNJSVUxVUlqZi9paEFVRE82?= =?utf-8?B?RWRkT2ZnRjFacUlxRndzbExKd3ZuNTdIL0FmeWhsUGNsUkZhNzFEMnVna0Nm?= =?utf-8?B?d3JqdVhKMG9sVkN5Y0VObS9TcERqeHByU2NLWTJmQUhoY1laMlYzSjU3SUEz?= =?utf-8?B?Mk15TEw4Yll0WXhGSys2SEVtM1RhU3ZsS1VJTGtpNkRIRTUzaE5xcGtHV1NT?= =?utf-8?B?eXdTcFQ0TFZ2L2daUi9oSElRc05LOTgxZEpoWFVtZEN2R1N0azNBZ0pGcUli?= =?utf-8?B?MUZuMU5oajI5Qm52UVQvcnVmQVJXUkZLTUtWbVJsdjJ0Tll5ZU1VeXlmcnRp?= =?utf-8?B?WXFWbVdXUktRdXU0SWtJWXJ4MGgxM2VnVlliNHE3dHJWUlEzbDkxQ3V6WTNT?= =?utf-8?B?Uk5WbWdDeVI4OUNkMEo4NCs1a3hEV3pxQzA4SThFZkJwK2hPNVhFbVpkalls?= =?utf-8?B?dUp5cnFnaGZuby9OYzhFRVFEV203YWRYc05RZVgwR3VaQVcvUzY4WlU2NEdH?= =?utf-8?B?cVczZFNQVUQ5OVQvOEZrU3RuZFdXa2k5RWo2SHV6RXBqR1ltY1NTb2xnMFVx?= =?utf-8?B?WE9OTUFsdFRVcC83SkZOeTFFQW1yY09kZWh3eXVFUnVURDY1QjZyL1U2NzJl?= =?utf-8?B?Z1I4Y3FHWHVQU05paTZxVjBDZ04rOTl0V3I0M1ZYUGNUb3h3Sm5Bdm5vcmEy?= =?utf-8?B?K2xZZkVPTG04MzF0VHVXZDNEYnROZ2pJUmVRdCszdGE5QXJIQzlZWU5ORjRD?= =?utf-8?B?QVhMQmRLZzdYbmlTK3Q4bnhtMFprUmxtQnUwT2hkTzhCa09tNFJKUitQNE4y?= =?utf-8?B?OE1HR2pZb1FtSFhIT1QzcTlvN011NEl3VU9zT1ZuVCtsRG5jL0E0TEpwY3Rt?= =?utf-8?B?d0dkVm5CK0tUOHIvNG5sMmt4LzFkSVhwSUpFRDhOQVdVTlBsSEtCZHpFNVFT?= =?utf-8?B?YS9xeGY2NXdWaTZVU3dRcEd3VDFWWXVmM1R4SmdVODNScjlYa1o5eksyNGMv?= =?utf-8?B?M05rOThSZHBLRGgzQkRPYXZsb1JocUNreSs2WVhXMElGV2dtUFZQNFVPejRs?= =?utf-8?B?dzVmelZiaWwzWkhBZ2M3WEhsN0dnTEY0Si9sNkhmc2pOdFdPS2pndzNKMWw3?= =?utf-8?B?dW9iV1A4bWpRekxKMlYxZ1hZSlRSQXlma1YvVmgwdTNSUCtSQTgzVnBqc3Js?= =?utf-8?B?Ni9sUGQ5WW9oL0NpdHN0VUlmcE1WdnkyOEF3UVpPQ3puUE5sUlZ4VEljbndW?= =?utf-8?B?OTJhT2xyK1NWb3E3Z1BDbFovRDIxcGxKL2diRVFSTDlFV3d3aFBuNW9Vdjdq?= =?utf-8?B?N3VYWjA3RUUwbjl1bEk1di9qK1RQdlFkSjdlRXJzenVnYytnTlpZSXhjeFlu?= =?utf-8?B?L0NzR3R5RXVLNyt5eDVHdEFPSUlicEhVcmRMSDhuUjBxNFZsaGZEWUdyQ3M4?= =?utf-8?B?a2owOGNHWXdJK0NySVNZVi9KeENjLy94LzJEREE4RlllM2VlWW00VDVPczUr?= =?utf-8?Q?zoA+2lugdeB37M6X8furbas7vH+mjf+5eaJqBtd?=
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b4b7116-59d6-4304-32eb-08d944eab596
X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2021 04:08:31.1332 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: CWlI0ojBNKJ5A1xltg7fKxBf37S98h2MhTxKB9Yfo4dBkpQ17n+tg94OTizBNYCWQLs28P05xBBe2hexLEqlbw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB3150
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jul 2021 04:08:41 -0000

Looks good to me, too.   Regards,   Martin.

On 2021-07-10 13:43, Brian E Carpenter wrote:
> wfm
> 
> Regards
>     Brian Carpenter
> 
> On 10-Jul-21 09:21, Peter Saint-Andre wrote:
>> On 7/4/21 10:52 PM, Brian E Carpenter wrote:
>>> On 05-Jul-21 16:31, Martin J. Dürst wrote:
>>>> I'm somewhat worried here. While I agree with Martin Thomson (see
>>>> separate mail) that it's the RSWG that establishes policy, I think it's
>>>
>>>> important to mention that the RS[EA...] not only provides expertise on
>>>> how to implement policy, but also on potential new policies, including
>>>> proposing new policies by themselves. "perhaps raising issues" may have
>>>
>>>> been written to include that, but in my view, it's quite weak.
>>>
>>> That text isn't the primary part of the RSEA's job description, though.
>>> I thought it was OK in the context of this part of the draft.
>>
>> Additionally, anyone (including the RSEA) can propose policy changes in
>> the RSWG. But for the avoidance of doubt we could say:
>>
>> * The RSEA provides expert advice to the RPC and RSAB on how to
>>    implement established policies on an ongoing and operational basis,
>>    which can include raising issues or initiating proposed policy changes
>>    within the RSWG.
>>
>> Peter
>>
> 


From nobody Mon Jul 12 02:47:13 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92823A08FC for ; Mon, 12 Jul 2021 02:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.189
X-Spam-Level: 
X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUqPfxD6xBqw for ; Mon, 12 Jul 2021 02:47:06 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 5B39D3A08FA for ; Mon, 12 Jul 2021 02:47:05 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1003::338] ([IPv6:2001:420:c0c0:1003:0:0:0:338]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16C9l2Kc195445 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 12 Jul 2021 11:47:03 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626083223; bh=ZXiwwF9kmFs5BP8sNRQkgy2yPnSkOT7jU2Tmrhydvpk=; h=To:From:Subject:Date:From; b=p23Jkt0gVh2bCebWoVcFzMH9sgxbJrwCgYexsJG/0icA6PIJ4qH5bplKarsROGDwA WFYmEhfH4OgN34Xcm1Lyf0gLk9kFlfJxNxUWU7jFLRrfVGxHnJQxuUK8Ln9ODopC7m ViuQSUlxhvb9XpsrToTtO7tVbOu3FTtpQupcBoTU=
To: rfced-future@iab.org
From: Eliot Lear 
Message-ID: <6125a073-3779-d32d-0252-28833a957d34@lear.ch>
Date: Mon, 12 Jul 2021 11:46:58 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xvAP33u8KvU7CobnASZfRLD1XExfYXttk"
Archived-At: 
Subject: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jul 2021 09:47:12 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--xvAP33u8KvU7CobnASZfRLD1XExfYXttk
Content-Type: multipart/mixed; boundary="dpZD8tTOhDYpZUwGWfdlm5R7zWikmkTdU";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Message-ID: <6125a073-3779-d32d-0252-28833a957d34@lear.ch>
Subject: Issue #73 Who is responsible for creating new streams?

--dpZD8tTOhDYpZUwGWfdlm5R7zWikmkTdU
Content-Type: multipart/alternative;
 boundary="------------6595DEA0DAE15DCDB410DF80"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------6595DEA0DAE15DCDB410DF80
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi there,

I opened this issue, and while it is related to who sits on the RSAB,=20
it's a little different.=C2=A0 The question is really this: what is the=20
process to create / delete editorial streams?=C2=A0 Does it go through th=
e=20
IETF process?=C2=A0 Does it go to the IAB?=C2=A0 Does it go through th RS=
WG/RSAB=20
process?

Peter asks this question: is it beyond the remit of *this* group to=20
decide that?=C2=A0 My gut says that this is not this group's decision but=
=20
perhaps an IAB decision or IETF decision or something in between.=C2=A0 T=
o=20
say otherwise would seem the tail wagging the dog.=C2=A0 Unless people=20
disagree with this logic, I'll close the issue.=C2=A0 Please comment by t=
he 26th.

This having been said, I do think this may be an issue for Brian's 2850=20
update doc, since the IAB has previously held authority to manage that=20
process.

Eliot


--------------6595DEA0DAE15DCDB410DF80
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  

    
  
  
    
Hi there,

    
I opened this issue, and while it is related to who sits on the
      RSAB, it's a little different.=C2=A0 The question is really this: w=
hat
      is the process to create / delete editorial streams?=C2=A0 Does it =
go
      through the IETF process?=C2=A0 Does it go to the IAB?=C2=A0 Does i=
t go
      through th RSWG/RSAB process?

    
Peter asks this question: is it beyond the remit of this
      group to decide that?=C2=A0 My gut says that this is not this group=
's
      decision but perhaps an IAB decision or IETF decision or something
      in between.=C2=A0 To say otherwise would seem the tail wagging the
      dog.=C2=A0 Unless people disagree with this logic, I'll close the
      issue.=C2=A0 Please comment by the 26th.

    
This having been said, I do think this may be an issue for
      Brian's 2850 update doc, since the IAB has previously held
      authority to manage that process.

    

    
Eliot

    

  


--------------6595DEA0DAE15DCDB410DF80--

--dpZD8tTOhDYpZUwGWfdlm5R7zWikmkTdU--

--xvAP33u8KvU7CobnASZfRLD1XExfYXttk
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDsD5IFAwAAAAAACgkQh7ZrRtnSejP1
8wf+MXp9lA8D0hURTpE+vHwVE/3C/Hlayv9Rk/XolObzGzlQP8Umid23oNc48tW4Ax1Z6U+9wAO1
LE07G9BQonCmXEVGmgMyh4yB7fYCUU7i1s0ftu9A8RtsrY8kfWMheXvIO88oWHCcOKr/nVDPiOGV
xJ9/Lr2/9BmNuUIW38bNhKitMiPJVOnmP+Hxd088gJI+4GLJQ/WIb9hm27D1zkWkm1RD9YYXhzKf
LrPfnRfZS5wgmDHou1IImFP3dBInv3CDiEN9vgopH3PXmBmY9svTIAumHEl1yg1b9zG3yLB1IZpm
eYOBtILhLzvsVOyOv/qTKlqqiCUdaukZL0m4EwCFIg==
=H26s
-----END PGP SIGNATURE-----

--xvAP33u8KvU7CobnASZfRLD1XExfYXttk--


From nobody Mon Jul 12 09:58:44 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7908F3A2234 for ; Mon, 12 Jul 2021 09:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQGm-skQDwYG for ; Mon, 12 Jul 2021 09:58:41 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 E4E063A222E for ; Mon, 12 Jul 2021 09:58:40 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id u8-20020a7bcb080000b02901e44e9caa2aso456809wmj.4 for ; Mon, 12 Jul 2021 09:58:40 -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=TcATUHpQhyMlbLCqmXi/y/XOS/TsR/0f+XnQFrFqktg=; b=UGfle74cQGnSKhNUnUNK7lH/M9J3vl02BkjKrSUFnn1mBf9yYQmZ5XNdgXAXvNexSq JYh2smHqNqmKfhKECK9AhacrNwWBZmywW9ayzHz2Ij905fPZlKe1GBJSgg7pbOYxablD CMx36WvjzSPoVcbfzIdzrYM7wPeQOMSlwrQB+XLRi532zQywZ3OeYhohG5PzZuOkrBYI aBK7rNr1mC4BYLoTBdmcPFT+lyoq4xZnZEnYxgwCtI05eiXsEYpYx1KgH4X40VyxKCf3 44twOEKWJiyKA5V1NKHQCVW8HF4eJ5bxoyiRgSI6W3fdPyD8UEH1b5r0ybVH5ZmmubtX 13kg==
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=TcATUHpQhyMlbLCqmXi/y/XOS/TsR/0f+XnQFrFqktg=; b=byA+hjgrSqOKosmHsVUeOFrWdo0JMtodLWJbkbPAVyTulA6Zp694wxHg76duVOj1kp QA5IZL2h1fX+NJaRnTG+K40l0Eg16ypssPhkEn1mqZoXA7/PtFnyVXtV5NJkJsK8b028 QD1POGAmllpSP6DKeDH+X4CL0OkmcT/czoNAUQW5ZSLJVuUuMtKohvRJAUFO0/JV8ENo K5xgTIuB58Q26uBqhuz/CM8a90Px509fq3DWeLsTBjLkaVrV6XSnP+naQdBWdWA/XRPR vTqZId1U4q+hyqiDaGwGpbzotkRHPe1YkgFVDy/oY0MSKF9eeBdtE5IKHv7soviQBKwO RueA==
X-Gm-Message-State: AOAM532I01L3dT+/HT6CDY6RJLCYCm9KB23n2M6FruS9emZJCUXrH0Qw FGiU66Y1Rydvs0PqqfO0534=
X-Google-Smtp-Source: ABdhPJy5jxO7jJ8tfRbM4nke09yEHtkniE/g1tMJ3i/9FuuSj3Eo4zMpmgDwnzz+OrIUGRkW/J8HEQ==
X-Received: by 2002:a05:600c:2189:: with SMTP id e9mr15223649wme.35.1626109117886;  Mon, 12 Jul 2021 09:58:37 -0700 (PDT)
Received: from [10.0.0.199] (c-73-223-183-113.hsd1.ca.comcast.net. [73.223.183.113]) by smtp.gmail.com with ESMTPSA id k5sm14072086wmk.11.2021.07.12.09.58.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jul 2021 09:58:37 -0700 (PDT)
From: Bob Hinden 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_B8A12A05-CC06-4250-8200-D4C84385E8D2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Mon, 12 Jul 2021 09:58:34 -0700
In-Reply-To: 
Cc: Bob Hinden , "rfced-future@iab.org" 
To: Peter Saint-Andre 
References: 
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jul 2021 16:58:43 -0000

--Apple-Mail=_B8A12A05-CC06-4250-8200-D4C84385E8D2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

> On Jul 9, 2021, at 2:03 PM, Peter Saint-Andre  =
wrote:
>=20
> The role played by the technical publishing expert in version 3 of the
> model is different enough from past roles that I suggest we should not
> use the name "RFC Series Editor" but instead "RFC Series Advisor=E2=80=9D=
.

I strongly disagree.

The RFC Editor role has changed multiple times in the past in many ways =
and we still call it the RFC Editor.

This includes:

Administrative support and direction changed from Defense Advanced =
Project Agency (DARPA), the Internet Society, IAOC, and currently the =
IETF LLC.

It has been performed by Jon Postel, Bob Braden, Joyce Reynolds, Glenn =
Kowack, Olaf Kolkman, and Heather Flanagan.

Actual editing has transitioned from an individual to a contracted =
company.

The scope and the context of this position has changed as the =
administration and the person doing the job changed.   It has great name =
recognition.   I don=E2=80=99t see any reason why what we are defining =
now can not be called the RFC Editor.   Changing it the =E2=80=9CRFC =
Series Advisor=E2=80=9D will cause considerable confusion in the larger =
community.

Bob



--Apple-Mail=_B8A12A05-CC06-4250-8200-D4C84385E8D2
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-----

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmDsdLoACgkQrut0EXfn
u6iYgAf+MBHzVUVsH0HJCaEpXAn5ZlB9wDGd/fPua39cZaQjJCj8SL8Dt6zp9H+E
DOGtDhRQwLS+Px5mqsS0hMD76uwBhPQw+XqLzkMb/yGCUmE1f8D6o+G2mPGeHC1N
eguE39EM8XNYTtTGRnzfQt4qe0uRX9/wpwaCp72VmRj1L1rcpUjHwKkm5ecRoddi
nj2GgGhTSl6SM5T3G1jjVFSNDZwkQkeutRUPrencxM+465zE/5cVjJBvElm8hKE1
zGOehaIff3GIpuKV+cVpX7PNvy6uhbSqN4Qhm/2/P+Sz5KzrqrW91M2oGYhSftdM
AiPYOF1eIsm5HHrw9rTBnTnKHs/X8A==
=z0PR
-----END PGP SIGNATURE-----

--Apple-Mail=_B8A12A05-CC06-4250-8200-D4C84385E8D2--


From nobody Mon Jul 12 10:20:13 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D643A2308 for ; Mon, 12 Jul 2021 10:20:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 a8a_SitANEwe for ; Mon, 12 Jul 2021 10:20:10 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36BF3A2307 for ; Mon, 12 Jul 2021 10:20:09 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id r125so11122678qkf.1 for ; Mon, 12 Jul 2021 10:20:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=I3muArErvcC+9FBxDbcgc2Epjt51tDEJfGasPoj0lyw=; b=n96OOGOaYlevow8kULA/A1vXzAhuCXbjgEraCnL/nDsuzO34gOIl5rCgi9wZ6Lg8P9 uxwOB/gzc5Hbp721sCkAN+2RZsNSj1dGlLOm2sG+wsTCszN6EQXa8rEb02pM/nnMCkBj nd1j2VCddRD3AqDrUimb6MM8/2VfFan4Yac2lQhXE375RgGKfOTgzmPAcWjvIfNAul8s WxmZmFc8925ZRj0dkdb7rVIhJR6brbSwo8oP8uwiHaS1fyEUGBasPY4zhy65+B94Z0ld 6vU8Vbbzspr3TivgQ0FXu0HPWEyy4kSYm/PLr5wR8chNPh3AkBdWlcQZ4QpVLeBNKk1W xSfA==
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; bh=I3muArErvcC+9FBxDbcgc2Epjt51tDEJfGasPoj0lyw=; b=K/+vJORNmhBPKUi4N2xcTPmmd6Sk5Cn2Tk/cexyEC0tV05McybmHrSWP1hXs8553cx fa4UtGkSa/6nUpl5QGJdd5pSBnRphiOWd+jeF898eTo7Qm1enI7e6jUuI6XaOZp6LblU bZplVMvr1VjnzYZx//EZvbUahbXw/k/4fFdWYBimGrqn+PRkphjEkfcKba/9G6TFK/hm ZvdKYVuC7rv9cIU7oy+Z+3wC47FDtZnlthHFGWKRSF1I+VQDr9opFdzDlWmmXQ0nkBhp wo2lQYYyOY7M7/7mGbDLdcP4EkGZygDPifAACc/ojVziN7KEtfQi34KLHcF4qTBD+5KB VSXQ==
X-Gm-Message-State: AOAM5309IZlWcx3+my8q7tqduFbPLslerkd3Iy8s+VkBPuzxLa8pXa3W ADWutSyd9O0PIilPxbaza46BZV7FKFMH3sKKprk=
X-Google-Smtp-Source: ABdhPJz3azufanvmxKw/m7nSNfVmCO9KjWQUowzsMjI5zMpfUzGJWx/GdIyYvIeSmpC9RRDddmfGrQ==
X-Received: by 2002:a05:620a:2004:: with SMTP id c4mr36815047qka.428.1626110407182;  Mon, 12 Jul 2021 10:20:07 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id x3sm6716058qkj.105.2021.07.12.10.20.06 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 10:20:06 -0700 (PDT)
To: rfced-future@iab.org
References:  
From: Michael StJohns 
Message-ID: <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com>
Date: Mon, 12 Jul 2021 13:20:03 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------118166E2E99326969E731DF9"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jul 2021 17:20:12 -0000

This is a multi-part message in MIME format.
--------------118166E2E99326969E731DF9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Bob said it better than I can.   Mike

On 7/12/2021 12:58 PM, Bob Hinden wrote:
> Hi,
>
>> On Jul 9, 2021, at 2:03 PM, Peter Saint-Andre  wrote:
>>
>> The role played by the technical publishing expert in version 3 of the
>> model is different enough from past roles that I suggest we should not
>> use the name "RFC Series Editor" but instead "RFC Series Advisor”.
> I strongly disagree.
>
> The RFC Editor role has changed multiple times in the past in many ways and we still call it the RFC Editor.
>
> This includes:
>
> Administrative support and direction changed from Defense Advanced Project Agency (DARPA), the Internet Society, IAOC, and currently the IETF LLC.
>
> It has been performed by Jon Postel, Bob Braden, Joyce Reynolds, Glenn Kowack, Olaf Kolkman, and Heather Flanagan.
>
> Actual editing has transitioned from an individual to a contracted company.
>
> The scope and the context of this position has changed as the administration and the person doing the job changed.   It has great name recognition.   I don’t see any reason why what we are defining now can not be called the RFC Editor.   Changing it the “RFC Series Advisor” will cause considerable confusion in the larger community.
>
> Bob
>
>
>


--------------118166E2E99326969E731DF9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Bob said it better than I can.   Mike

    

    


    

    
On 7/12/2021 12:58 PM, Bob Hinden
      wrote:

    

    

      
Hi,



      

        
On Jul 9, 2021, at 2:03 PM, Peter Saint-Andre <stpeter@mozilla.com> wrote:

The role played by the technical publishing expert in version 3 of the
model is different enough from past roles that I suggest we should not
use the name "RFC Series Editor" but instead "RFC Series Advisor”.


      

      
I strongly disagree.

The RFC Editor role has changed multiple times in the past in many ways and we still call it the RFC Editor.

This includes:

Administrative support and direction changed from Defense Advanced Project Agency (DARPA), the Internet Society, IAOC, and currently the IETF LLC.

It has been performed by Jon Postel, Bob Braden, Joyce Reynolds, Glenn Kowack, Olaf Kolkman, and Heather Flanagan.

Actual editing has transitioned from an individual to a contracted company.

The scope and the context of this position has changed as the administration and the person doing the job changed.   It has great name recognition.   I don’t see any reason why what we are defining now can not be called the RFC Editor.   Changing it the “RFC Series Advisor” will cause considerable confusion in the larger community.

Bob




      

      

    

    


    

  


--------------118166E2E99326969E731DF9--


From nobody Mon Jul 12 11:00:10 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D2C3A010A for ; Mon, 12 Jul 2021 10:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.006
X-Spam-Level: 
X-Spam-Status: No, score=0.006 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ7oKYfP5F8B for ; Mon, 12 Jul 2021 10:59:49 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 8B5DE3A02F7 for ; Mon, 12 Jul 2021 10:59:47 -0700 (PDT)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16CHxh24024132; Mon, 12 Jul 2021 18:59:43 +0100
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 764694604A; Mon, 12 Jul 2021 18:59:43 +0100 (BST)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 60F4146043; Mon, 12 Jul 2021 18:59:43 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs4.iomartmail.com (Postfix) with ESMTPS; Mon, 12 Jul 2021 18:59:43 +0100 (BST)
Received: from LAPTOPK7AS653V ([195.166.134.8]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16CHxguR008251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Jul 2021 18:59:43 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Eliot Lear'" , 
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch>
In-Reply-To: <6125a073-3779-d32d-0252-28833a957d34@lear.ch>
Date: Mon, 12 Jul 2021 18:59:42 +0100
Organization: Old Dog Consulting
Message-ID: <018a01d77747$b168fcb0$143af610$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_018B_01D77750.132DD9E0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJqFfjdjPw+i7UkbiIi9UTIDBCypqoaVciw
Content-Language: en-gb
X-Originating-IP: 195.166.134.8
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26278.001
X-TM-AS-Result: No--21.211-10.0-31-10
X-imss-scan-details: No--21.211-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26278.001
X-TMASE-Result: 10--21.211300-10.000000
X-TMASE-MatchedRID: b/1IsOqez6fkQwDXuLnCoXFPUrVDm6jtiRPU6vvejXK1bAar5ypkWSMn HClP1IKbuBVFqK4EY2ET3qD7eKafub67D/tLVqWhuZBZOg7RfX+lY4F8r0vXPy196sn93sBvXo7 nd5tyAc2POou8AFz7yO3Yrzf7S5PMcJsCSs5qF7wSEYfcJF0pRQ5k1ea+clp6CD7rjpXrwMot5c ux/0Cb0xeC0dhwGr5VYgVxjOC5LZURvH0qFauTNM9R/UqWnLW42gp+A6golza2TkeS9tjW4xsvC 2oZFQHfGsqFwzrE3ao54EyL9veg9w/OnCkhDfxIlVHM/F6YkvQacZilk37ECJa6kPmQ+AgD+03a +MQ8RE2TR+S9fvhAeqqa7Uh57M3hfrCVjQeoDBAM6z3iDvziBz0Ol1nHkdplwowduEyfn2C2hrf vb/FTQysG3vKE6A2G4TGI74oWaaqw/qTwOqsja1VeGWZmxN2MOhJ9m53n4aDzlv7FEwWOy4EMwQ 9YwyyfrpIXOuGmFGtvw/VYBDi9eRadv+F8ucSI/Sl5cYQQGW8O8pJojG7qSlcbfIj2Ta9sn3HS2 bO+krbCfvo3UgFFJH7Iz4Xfn0uR1LFdtmiebE6A3KVVsj8QDKgJ/sh288AnnGLdjiSqk4DQ0pyF ljzBR/8Q1xpjR7Q/vUfrcBOghlmtVGfC/VjEBwA+Y0oNaxbQ4y6x6rwIksu7wwXk7nDSVsfYl7I vYClzSpAFNe4DUJ6dma75/Tybj9r1K4maT4N8Ij0zFI5DoJKKMa8PCKgA/bjXwg7sFIZQuj84zz hk0gNu1m6K/uMtBcpHfDgT/LTElwV2iaAfSWdr34lUqic7t4tkBWmEtb9teSC65CityAwtQN6OI cF6Na0ww33eR8cuyrkgRi0IRH+effzagS0mRn7cGd19dSFd
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jul 2021 18:00:00 -0000

This is a multipart message in MIME format.

------=_NextPart_000_018B_01D77750.132DD9E0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

I=E2=80=99m struggling with this one a bit.

=20

Sadly, I think this is not the small question that it might appear from =
your email. To me it is essential to the definition of the =E2=80=9CRFC =
Series=E2=80=9D to define what streams exist.

=20

I think there are two classes of stream:

a.	Those that the IETF would like to exist
b.	Those that exist outwith the IETF

=20

In class a) we have all of the current streams (IETF, IAB, IRTF, IS) and =
they are defined and controlled by existing RFCs. To remove one, to =
merge two, or to create another would be acts of IETF consensus (in one =
way or another).=20

=20

In class b) we could envision another SDO or forum that works on =
Internet specifications coming to the RSE and asking to be published as =
RFCs. I can see the IETF having a strong opinion on this, and I can see =
=E2=80=9Cthe decision-maker=E2=80=9D taking those opinions very =
seriously, but I can=E2=80=99t see why that would be the IETF=E2=80=99s =
decision or the IAB=E2=80=99s decision. The crunch here is =E2=80=9CWhat =
is the RFC Series?=E2=80=9D and I think we have been dodging this =
question despite it being fundamental to how we got here, today.

=20

Now I realise that Peter=E2=80=99s question is a meta-question. Not =
=E2=80=9Cwhat should be the process?=E2=80=9D but =E2=80=9Cwho gets to =
decide what the process is?=E2=80=9D Nevertheless, the question is so =
fundamental to what the RFC Series is and what the responsibilities of =
the various actors are, that I think we have to look at it to uncover =
the implications. Otherwise we are simply making a decision by hiding =
from the question.

=20

Cheers,

Adrian

=20

From: Rfced-future  On Behalf Of Eliot =
Lear
Sent: 12 July 2021 10:47
To: rfced-future@iab.org
Subject: [Rfced-future] Issue #73 Who is responsible for creating new =
streams?

=20

Hi there,

I opened this issue, and while it is related to who sits on the RSAB, =
it's a little different.  The question is really this: what is the =
process to create / delete editorial streams?  Does it go through the =
IETF process?  Does it go to the IAB?  Does it go through th RSWG/RSAB =
process?

Peter asks this question: is it beyond the remit of this group to decide =
that?  My gut says that this is not this group's decision but perhaps an =
IAB decision or IETF decision or something in between.  To say otherwise =
would seem the tail wagging the dog.  Unless people disagree with this =
logic, I'll close the issue.  Please comment by the 26th.

This having been said, I do think this may be an issue for Brian's 2850 =
update doc, since the IAB has previously held authority to manage that =
process.

Eliot


------=_NextPart_000_018B_01D77750.132DD9E0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,
 
I=E2=80=99m =
struggling with this one a bit.
 
Sadly, I =
think this is not the small question that it might appear from your =
email. To me it is essential to the definition of the =E2=80=9CRFC =
Series=E2=80=9D to define what streams exist.
 
I think =
there are two classes of stream:
  1. Those that the IETF would like to =
exist
  2. Those that exist outwith the =
IETF
 
In class a) =
we have all of the current streams (IETF, IAB, IRTF, IS) and they are =
defined and controlled by existing RFCs. To remove one, to merge two, or =
to create another would be acts of IETF consensus (in one way or =
another). 
 
In class b) =
we could envision another SDO or forum that works on Internet =
specifications coming to the RSE and asking to be published as RFCs. I =
can see the IETF having a strong opinion on this, and I can see =
=E2=80=9Cthe decision-maker=E2=80=9D taking those opinions very =
seriously, but I can=E2=80=99t see why that would be the IETF=E2=80=99s =
decision or the IAB=E2=80=99s decision. The crunch here is =E2=80=9CWhat =
is the RFC Series?=E2=80=9D and I think we have been dodging this =
question despite it being fundamental to how we got here, =
today.
 
Now I =
realise that Peter=E2=80=99s question is a meta-question. Not =
=E2=80=9Cwhat should be the process?=E2=80=9D but =E2=80=9Cwho gets to =
decide what the process is?=E2=80=9D Nevertheless, the question is so =
fundamental to what the RFC Series is and what the responsibilities of =
the various actors are, that I think we have to look at it to uncover =
the implications. Otherwise we are simply making a decision by hiding =
from the question.
 
Cheers,
Adrian
 
From: Rfced-future =
<rfced-future-bounces@iab.org> On Behalf Of Eliot =
Lear
Sent: 12 July 2021 10:47
To: =
rfced-future@iab.org
Subject: [Rfced-future] Issue #73 Who is =
responsible for creating new =
streams?
 
Hi there,
I =
opened this issue, and while it is related to who sits on the RSAB, it's =
a little different.  The question is really this: what is the =
process to create / delete editorial streams?  Does it go through =
the IETF process?  Does it go to the IAB?  Does it go through =
th RSWG/RSAB process?
Peter asks this question: is it =
beyond the remit of this group to decide that?  My gut says =
that this is not this group's decision but perhaps an IAB decision or =
IETF decision or something in between.  To say otherwise would seem =
the tail wagging the dog.  Unless people disagree with this logic, =
I'll close the issue.  Please comment by the =
26th.
This having been said, I do think this may be an =
issue for Brian's 2850 update doc, since the IAB has previously held =
authority to manage that =
process.
Eliot

------=_NextPart_000_018B_01D77750.132DD9E0--


From nobody Mon Jul 12 11:04:43 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39A83A0779 for ; Mon, 12 Jul 2021 11:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.647
X-Spam-Level: 
X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHzmrE2-CllR for ; Mon, 12 Jul 2021 11:04:37 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C2F3A0776 for ; Mon, 12 Jul 2021 11:04:37 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 16CHj3g0005968; Mon, 12 Jul 2021 19:04:35 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=JVx1703EimaMHUKOnX0CDK9tIcW53C0sALM4aR33oSI=; b=aLHfvuj3LHRUIfRyPd10yeFP1tiRcdyXph7i/vGXB6YbgIlm11ZeUIEeQj7S3/5zbmZo W4cMW6bM2iCfoSDeBk79BEG0suPKDV4OOAwAoA/ygNBm/W/BWVPgIOvZZe6Sm2hMRcE4 Ktuf495O06Y0lj+w7x/nVepAlQnciXL/gJMOv+kTqMeypsXvMiJermuwVYKPUVr8RCQc M3oVzsxXZN/gk/ZAhR9Gnkm62y+FNpf7k1NqaV4hGLPqOXnNJq3GL7kvBgNMDH8Ud157 aeBPOLISAA9UAICLZRWFUF+6korpQXeXZT2w3nue+A/yBoq2fcfItYUSI4bMBnw/uZcV Ag== 
Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 39rdp92pdg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jul 2021 19:04:35 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 16CI47RB016656; Mon, 12 Jul 2021 14:04:34 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint4.akamai.com with ESMTP id 39q6vykqws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Jul 2021 14:04:34 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 12 Jul 2021 13:04:33 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.018; Mon, 12 Jul 2021 13:04:33 -0500
From: "Salz, Rich" 
To: "adrian@olddog.co.uk" , 'Eliot Lear' ,  "rfced-future@iab.org" 
Thread-Topic: [Rfced-future] Issue #73 Who is responsible for creating new streams?
Thread-Index: AQHXdwLoO/kP5aYV+UuBQQ8+tOxKXas/9S0A//++bQA=
Date: Mon, 12 Jul 2021 18:04:33 +0000
Message-ID: 
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <018a01d77747$b168fcb0$143af610$@olddog.co.uk>
In-Reply-To: <018a01d77747$b168fcb0$143af610$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.50.21061301
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: multipart/alternative; boundary="_000_C4CE8C7B4CBA4B3F9FA62FF8EC088379akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-12_10:2021-07-12, 2021-07-12 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxscore=0 phishscore=0 mlxlogscore=744 spamscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107120129
X-Proofpoint-GUID: BtrmymCbMSnF5DOxBeoq9L8dev8FxIqy
X-Proofpoint-ORIG-GUID: BtrmymCbMSnF5DOxBeoq9L8dev8FxIqy
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-12_10:2021-07-12, 2021-07-12 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 malwarescore=0 suspectscore=0 phishscore=0 impostorscore=0 priorityscore=1501 clxscore=1011 bulkscore=0 adultscore=0 lowpriorityscore=0 mlxlogscore=685 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107120128
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.32) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint4
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jul 2021 18:04:42 -0000

--_000_C4CE8C7B4CBA4B3F9FA62FF8EC088379akamaicom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UkZD4oCZcyBzaG91bGQgbm90IGV4aXN0IG91dHNpZGUgb2YgdGhlIElFVEYgb3IgaXRzIGRlc2ln
bmVlcy4NCg==

--_000_C4CE8C7B4CBA4B3F9FA62FF8EC088379akamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: <3F4813AFDA57DC40A8A68E9DA6D69E4B@akamai.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z
ICovDQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N
Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6
ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h
cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6
V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s
aXN0LWlkOjgxNjM4NjA0NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w
bGF0ZS1pZHM6MTc0Njk0MDAyOCAtMTg4MjgzMzE3NCAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgw
NzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3O30N
CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN
Cgltc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t
YXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp
YnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg
bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0
IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE1NTEzODUxMDY7DQoJbXNvLWxpc3QtdGVt
cGxhdGUtaWRzOi0zMzUxMzEwNjI7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg
bDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s
ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs
MTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx
OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6
bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl
bC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpvbA0KCXttYXJn
aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0K
PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy
IiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x
Ij4NCjxwPlJGQ+KAmXMgc2hvdWxkIG5vdCBleGlzdCBvdXRzaWRlIG9mIHRoZSBJRVRGIG9yIGl0
cyBkZXNpZ25lZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_C4CE8C7B4CBA4B3F9FA62FF8EC088379akamaicom_--


From nobody Mon Jul 12 11:12:12 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E113A08F3 for ; Mon, 12 Jul 2021 11:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.31
X-Spam-Level: *
X-Spam-Status: No, score=1.31 tagged_above=-999 required=5 tests=[DKIM_ADSP_ALL=1.1, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBiQZx3pcboo for ; Mon, 12 Jul 2021 11:12:04 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 81B1C3A08DC for ; Mon, 12 Jul 2021 11:12:04 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1004::18c] ([IPv6:2001:420:c0c0:1004:0:0:0:18c]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16CIBtqE201178 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 12 Jul 2021 20:11:55 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626113516; bh=bIrLAP19kig/CQG8Ej8mUWhQtc/dQNRRek12MzKl5/w=; h=To:References:From:Subject:Date:In-Reply-To:From; b=L+ShAEwpmkFBkl7710bM3MrhFsW1CNKJsXoOT5XdrgCoa/RrBqqG9S4ZLUSqFTrE7 URdZWxYR3vkLDhXOhCj1cOqI0fYxnAIYlbPM5Hb+LrtC1KEkAqWqbOrAN/SVw6SVjo vavXMkstupf6DP90cl0J+JcNJrxNnrKHEi5XPCoA=
To: "Salz, Rich" , "adrian@olddog.co.uk" , "rfced-future@iab.org" 
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <018a01d77747$b168fcb0$143af610$@olddog.co.uk> 
From: Eliot Lear 
Message-ID: 
Date: Mon, 12 Jul 2021 20:11:54 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2TmKwqTSxAd6aihJhTTGtn4pxmB6h0xrD"
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jul 2021 18:12:10 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2TmKwqTSxAd6aihJhTTGtn4pxmB6h0xrD
Content-Type: multipart/mixed; boundary="CCGCPqxB8D0RMExkFTSsnuzZwSWBLlo1p";
 protected-headers="v1"
From: Eliot Lear 
To: "Salz, Rich" , "adrian@olddog.co.uk"
 , "rfced-future@iab.org" 
Message-ID: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new
 streams?
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch>
 <018a01d77747$b168fcb0$143af610$@olddog.co.uk>
 
In-Reply-To: 

--CCGCPqxB8D0RMExkFTSsnuzZwSWBLlo1p
Content-Type: multipart/alternative;
 boundary="------------5A6DB3D7F1F7187BC01FA96D"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------5A6DB3D7F1F7187BC01FA96D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Rich,

On 12.07.21 20:04, Salz, Rich wrote:
>
> RFC=E2=80=99s should not exist outside of the IETF or its designees.
>
This is a bit too terse.=C2=A0 After all, the IAB, IRTF, and ISE streams =
all=20
exist outside of the IETF today. But maybe you mean that the IETF should =

have a say about new streams.

One could invert this question:

Who has the authority to close down a stream?=C2=A0 If today it is the IA=
B,=20
then who is it tomorrow?=C2=A0 One=C2=A0 answer is: the IAB.=C2=A0 Anothe=
r answer might=20
be the IETF.

Adrian wrote:

> The crunch here is =E2=80=9CWhat is the RFC Series?=E2=80=9D and I thin=
k we have been=20
> dodging this question despite it being fundamental to how we got here, =

> today.

Beyond its editorial process and output definition, do we even get to=20
say more?

Eliot



--------------5A6DB3D7F1F7187BC01FA96D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Rich,

    
On 12.07.21 20:04, Salz, Rich wrote:
    

    

      
      
      
      

        
RFC=E2=80=99s should not exist outside of the IETF or its desi=
gnees.

      

    

    
This is a bit too terse.=C2=A0 After all, the IAB, IRTF, and ISE
      streams all exist outside of the IETF today. But maybe you mean
      that the IETF should have a say about new streams.

    
One could invert this question:

    
Who has the authority to close down a stream?=C2=A0 If today it is=
 the
      IAB, then who is it tomorrow?=C2=A0 One=C2=A0 answer is: the IAB.=C2=
=A0 Another
      answer might be the IETF.

    
Adrian wrote:

    

      
The
          crunch here is =E2=80=9CWhat is the RFC Series?=E2=80=9D and I =
think we have
          been dodging this question despite it being fundamental to how
          we got here, today.

    

    
Beyond its editorial process and output definition, do we even
      get to say more?

    
Eliot

    

    


    

  


--------------5A6DB3D7F1F7187BC01FA96D--

--CCGCPqxB8D0RMExkFTSsnuzZwSWBLlo1p--

--2TmKwqTSxAd6aihJhTTGtn4pxmB6h0xrD
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDsheoFAwAAAAAACgkQh7ZrRtnSejMR
HQf+LMvKahtteyWqmMdkDpZ9qXvR5tMpmqkDg8XP2HmCmlZn5Jbe1vlEa8z6BWh65MYiDnT5uoja
B+t1KFIirjYlkz5WSyA5WLQw487uUN6OuwRIsXfIEzlHzMGHX+H9tUvIVY+P9q2xiZxGTpndxWlh
4RYzwRHx8XFBD/khLSABf0NBh3B1m50VbDudhmI1xMhiezQBPyH52yG4GnRQgs5aBMaDsg966gV1
SkTyYIK6yFH/7ZpdReoQMW9DFM0hR0zkxlhMXuxaVip+a/UhP2QQXLFC49imzoHH5wtiHAqH0zAW
ewmRu0cOI/aLgmjm9qfD3/g/lSR94zQRzAXcOTv+Pg==
=MwKh
-----END PGP SIGNATURE-----

--2TmKwqTSxAd6aihJhTTGtn4pxmB6h0xrD--


From nobody Mon Jul 12 11:16:55 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E213A0BFE for ; Mon, 12 Jul 2021 11:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.648
X-Spam-Level: 
X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG2eO3WUgfCD for ; Mon, 12 Jul 2021 11:16:51 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099E63A0BD4 for ; Mon, 12 Jul 2021 11:16:50 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 16CIFNrJ005057; Mon, 12 Jul 2021 19:16:49 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=HpXY7zdcIrsfoSmbpp2yJyB+CiO8y40kvaOnL3d4V6E=; b=U2ASATnwQvLkTR+fctpC8xay0i0mfl+yppKgPsxiH8B0tkErSKSxpRc0WVERKB1pkInS SramT/pBSOfRA2/QrAxpm+dHtLTDeMGrlmPChFxn1jumy4+9884W75HLNU3fnlMDZ5BM hiHlVCk1/qorTXmkJULTyqTH3eOhWaQu3C5A5qjzjDU82ssF0JQiuG2WMbHMVpcU8eq1 7MJTuCe1G48kG7At3sRdGfGg6h8bpM5A2R5e/xuVJP29dwr8yF0sfnE2MsTHyN3N0deu l02FdAaGQZnSGpwhQsxwUg0rKQZfSAND58w7KZEtvV2EVNslwiILu4zAAzjwl2EqDxI6 Uw== 
Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 39rc4xb7e9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jul 2021 19:16:48 +0100
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 16CI4ttM018869; Mon, 12 Jul 2021 14:16:47 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint8.akamai.com with ESMTP id 39q6w03v3m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Jul 2021 14:16:47 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 12 Jul 2021 13:16:46 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.018; Mon, 12 Jul 2021 13:16:46 -0500
From: "Salz, Rich" 
To: Eliot Lear , "adrian@olddog.co.uk" , "rfced-future@iab.org" 
Thread-Topic: [Rfced-future] Issue #73 Who is responsible for creating new streams?
Thread-Index: AQHXdwLoO/kP5aYV+UuBQQ8+tOxKXas/9S0A//++bQCAAET7AP//vm0A
Date: Mon, 12 Jul 2021 18:16:45 +0000
Message-ID: <3DB3AF3D-19F7-4963-82D3-50C5F718A0FA@akamai.com>
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <018a01d77747$b168fcb0$143af610$@olddog.co.uk>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.50.21061301
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: multipart/alternative; boundary="_000_3DB3AF3D19F7496382D350C5F718A0FAakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-12_10:2021-07-12, 2021-07-12 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 bulkscore=0 malwarescore=0 mlxscore=0 suspectscore=0 mlxlogscore=566 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107120129
X-Proofpoint-ORIG-GUID: 5fUvOoXRzfzGzvgNhyogsBkWo8tYiVRW
X-Proofpoint-GUID: 5fUvOoXRzfzGzvgNhyogsBkWo8tYiVRW
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-12_10:2021-07-12, 2021-07-12 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 adultscore=0 spamscore=0 clxscore=1015 malwarescore=0 impostorscore=0 mlxscore=0 bulkscore=0 mlxlogscore=524 phishscore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107120130
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint8
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jul 2021 18:16:55 -0000

--_000_3DB3AF3D19F7496382D350C5F718A0FAakamaicom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Pk9uIDEyLjA3LjIxIDIwOjA0LCBTYWx6LCBSaWNoIHdyb3RlOg0KDQo+IFJGQ+KAmXMgc2hvdWxk
IG5vdCBleGlzdCBvdXRzaWRlIG9mIHRoZSBJRVRGIG9yIGl0cyBkZXNpZ25lZXMuDQoNCj4gVGhp
cyBpcyBhIGJpdCB0b28gdGVyc2UuICBBZnRlciBhbGwsIHRoZSBJQUIsIElSVEYsIGFuZCBJU0Ug
c3RyZWFtcyBhbGwgZXhpc3Qgb3V0c2lkZSBvZiB0aGUgSUVURiB0b2RheS4NCg0KSSBzYWlkIOKA
nG9yIGl0cyBkZXNpZ25lZXPigJ0gd2hpY2ggSSBpbnRlbmRlZCB0byBjb3ZlciB5b3VyIGV4YW1w
bGUuIEl0IGNvdWxkIGJlIGludGVyZXN0aW5nIGZvciBhbiBoaXN0b3JpYW4gdG8gZmluZCBvdXQg
d2hhdCBvcmdzIGV4aXN0ZWQgYXQgdGhlIHRpbWUgdGhvc2Ugc3RyZWFtcyB3ZXJlIGNyZWF0ZWQg
YnV0IG1vcmUgdGhhbiBJIHdhbnQgdG8gZG8uIDspDQoNClBlcmhhcHMgd2Ugc2F5IOKAnG5vdCBj
b3ZlcmVkIGFzIGFuIElFVEYgYWN0aXZpdGllcyBhcyBkZWZpbmVkIGJ5IHRoZSBMTEPigJ0gQWZ0
ZXIgYWxsLCBJIHdvdWxkIGV4cGVjdCB0aGUgTExDIHRyYWRlbWFyayBwcm90ZWN0aW9uIHdvdWxk
IHByZXZlbnQgdGhhdCBmcm9tIGhhcHBlbmluZy4NCg0KSWYgc29tZSByYW5kb20gU0RPIHdhbnRz
IHRvIHB1Ymxpc2ggYW4gUkZDLCBnbyBhaGVhZC4gIEp1c3Qgbm90IGhlcmUuDQo=

--_000_3DB3AF3D19F7496382D350C5F718A0FAakamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: <08AB5EF4790F3446860D719C60DF8E2E@akamai.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6
ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw
YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w
aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi
IHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7T24gMTIu
MDcuMjEgMjA6MDQsIFNhbHosIFJpY2ggd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PHA+Jmd0OyBSRkPigJlzIHNob3VsZCBub3QgZXhpc3Qgb3V0c2lkZSBvZiB0aGUgSUVURiBvciBp
dHMgZGVzaWduZWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jmd0OyBUaGlz
IGlzIGEgYml0IHRvbyB0ZXJzZS4mbmJzcDsgQWZ0ZXIgYWxsLCB0aGUgSUFCLCBJUlRGLCBhbmQg
SVNFIHN0cmVhbXMgYWxsIGV4aXN0IG91dHNpZGUgb2YgdGhlIElFVEYgdG9kYXkuDQo8bzpwPjwv
bzpwPjwvcD4NCjxwPkkgc2FpZCDigJxvciBpdHMgZGVzaWduZWVz4oCdIHdoaWNoIEkgaW50ZW5k
ZWQgdG8gY292ZXIgeW91ciBleGFtcGxlLiBJdCBjb3VsZCBiZSBpbnRlcmVzdGluZyBmb3IgYW4g
aGlzdG9yaWFuIHRvIGZpbmQgb3V0IHdoYXQgb3JncyBleGlzdGVkIGF0IHRoZSB0aW1lIHRob3Nl
IHN0cmVhbXMgd2VyZSBjcmVhdGVkIGJ1dCBtb3JlIHRoYW4gSSB3YW50IHRvIGRvLiA7KTxvOnA+
PC9vOnA+PC9wPg0KPHA+UGVyaGFwcyB3ZSBzYXkg4oCcbm90IGNvdmVyZWQgYXMgYW4gSUVURiBh
Y3Rpdml0aWVzIGFzIGRlZmluZWQgYnkgdGhlIExMQ+KAnSBBZnRlciBhbGwsIEkgd291bGQgZXhw
ZWN0IHRoZSBMTEMgdHJhZGVtYXJrIHByb3RlY3Rpb24gd291bGQgcHJldmVudCB0aGF0IGZyb20g
aGFwcGVuaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHA+SWYgc29tZSByYW5kb20gU0RPIHdhbnRzIHRv
IHB1Ymxpc2ggYW4gUkZDLCBnbyBhaGVhZC4mbmJzcDsgSnVzdCBub3QgaGVyZS48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_3DB3AF3D19F7496382D350C5F718A0FAakamaicom_--


From nobody Mon Jul 12 11:26:11 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B31E3A0D0B for ; Mon, 12 Jul 2021 11:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 iSafTvhFNwnT for ; Mon, 12 Jul 2021 11:26:06 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 B84213A0D09 for ; Mon, 12 Jul 2021 11:26:06 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id w13so14667087qtc.0 for ; Mon, 12 Jul 2021 11:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=udHhU0ls8jium2D2X6lLMz9pdjEV7zMgTxZitSK+pXA=; b=RDmLUWetEZfBhG16eLFFalbozQyLghOLExQ9vOYkQohzH/5UnPcqVcgvH4CRjIAHHC 8Gigk7icb3u7rvVNkv+89c2v+Kv27RSWq6qwZzKKvW+k3xrqQhZOyMBfIIVTYKJ7rHPE Rf/vURBq77Z92eiNfuYgW9BR1leJ/Lch6wgwH55v6xgR2pFtg7IojTCwsDJj06eeGhoj aXvdNDm4tVdXukrUJnQansN9nxZHxj+0tRrl2b+wfo2ITYJiW7mztg9olnqawYgd8yd0 oc6Lm+xeoODc4LXNROv+fYNr0GkkRafXmhfuOJYqdOs7j+rmmKk1G4D/YbqNajmP5vwA KPQg==
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; bh=udHhU0ls8jium2D2X6lLMz9pdjEV7zMgTxZitSK+pXA=; b=etu3dsE4wRpXlCak9Lcy2GPkEvPwIoQ4sGPW/tPrmkSheBOFljYnnCnSGW6Y2ph9S/ x56POl5Pr01rkL6/o4/vEWqRq/HS8gpvGY+ec6Wa9rokI/r+ouhidZhSUArYbAXV3gur Gp3o6V8OdDFERua6754eymVj3Uc9jgn8raFO5OUSl7fWzLFkVY7OCUkoseg1bh88N8Ae jFGPEmzeuZ+aYKISA6Z1C+3uIz7aCZm2USjV0fTGkf7eHtsl2XMrwOGf5RsPFqXAskKX Dg8kUBMvikl2mbjKRoAPelHzhCSKC2ghDuXJyRlFKAe90DvGxyt6qxvNh4k0769Me/+a z12w==
X-Gm-Message-State: AOAM533dvusM9Z0ycCrr8vAzSUCssOlnB8qy9b8xjYSy3bGpGwCk3VKM yo0XcPZsE9faukLGbRt7MVx4WUWQQF4ml4nSJZM=
X-Google-Smtp-Source: ABdhPJwpW2r8IODeY3w2TaqkNwuXzzVmLHj3BqrWGEQ49ng+j1Xj3qE2VaYhyn/JBiH0qPO9wUwZRg==
X-Received: by 2002:ac8:13c4:: with SMTP id i4mr201940qtj.136.1626114363854; Mon, 12 Jul 2021 11:26:03 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id d21sm6813945qkl.42.2021.07.12.11.26.03 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 11:26:03 -0700 (PDT)
To: rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <018a01d77747$b168fcb0$143af610$@olddog.co.uk>  
From: Michael StJohns 
Message-ID: <0e3bc4e8-ccbc-785f-06cf-4dc742ffd545@nthpermutation.com>
Date: Mon, 12 Jul 2021 14:26:02 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------BEC3DC096F4562732365D74C"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jul 2021 18:26:10 -0000

This is a multi-part message in MIME format.
--------------BEC3DC096F4562732365D74C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Eliot -

On 7/12/2021 2:11 PM, Eliot Lear wrote:
>
> Hi Rich,
>
> On 12.07.21 20:04, Salz, Rich wrote:
>>
>> RFC’s should not exist outside of the IETF or its designees.
>>
> This is a bit too terse.  After all, the IAB, IRTF, and ISE streams 
> all exist outside of the IETF today. But maybe you mean that the IETF 
> should have a say about new streams.
>
> One could invert this question:
>
> Who has the authority to close down a stream?  If today it is the IAB, 
> then who is it tomorrow?  One  answer is: the IAB. Another answer 
> might be the IETF.
>
The third leg of this is - who pays for new streams?   There is a cost 
per RFC that is borne by the LLC (and additional indirect support from 
the ISOC).  If some SDO came to us, said they'd contribute, had a set of 
documents that were not anathema to the Internet, and was willing to 
follow the RFC series editorial guidelines, I'd probably have a quick 
chat with the ISOC and IAB (as our outwardly facing organization), and 
the LLC with respect to any financial considerations and then put it to 
the RSAB's vote to add the stream if recommended by those three groups.

For deleting a stream, the stream owner (if they've gotten out of the 
publication business or no longer want to bear the costs), the RSAB if 
the stream has become moribund (abandoned), the LLC if they're behind in 
their contributions, and the RSAB, ISOC and IAB collectively if the 
relationship with the stream owner has diverged from our interests.

> Adrian wrote:
>
>> The crunch here is “What is the RFC Series?” and I think we have been 
>> dodging this question despite it being fundamental to how we got 
>> here, today.
>
> Beyond its editorial process and output definition, do we even get to 
> say more?
>
If I tell you I'm giving you an elephant, and you've never seen such a 
thing, and you have to provide for its care and feeding, wouldn't I be 
remiss if I didn't provide you with said requirements?   That's not a 
great analogy, because and elephant is a physical object with well known 
properties, whereas the RFC series is an implemented idea or ideal.  But 
this is all about the care and feeding of the series so...

I think we're doing too much of "I'll know it when I see it" here and my 
view of what the RFC series is and others views of what the RFC series 
is diverge widely.   At some point what the RFC series is and where it's 
headed needs to be considered and the document that Peter is authoring 
is much weaker for not having that front and center.

Later, mike



> Eliot
>
>
>


--------------BEC3DC096F4562732365D74C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Eliot - 

    

    


    

    
On 7/12/2021 2:11 PM, Eliot Lear wrote:

    

    

      
      
Hi Rich,

      
On 12.07.21 20:04, Salz, Rich wrote:

      

      

        
        
        
        

          
RFC’s should not exist outside of the IETF or its
            designees.

        

      

      
This is a bit too terse.  After all, the IAB, IRTF, and ISE
        streams all exist outside of the IETF today. But maybe you mean
        that the IETF should have a say about new streams.

      
One could invert this question:

      
Who has the authority to close down a stream?  If today it is
        the IAB, then who is it tomorrow?  One  answer is: the IAB. 
        Another answer might be the IETF.

    

    
The third leg of this is - who pays for new streams?   There is a
      cost per RFC that is borne by the LLC (and additional indirect
      support from the ISOC).  If some SDO came to us, said they'd
      contribute, had a set of documents that were not anathema to the
      Internet, and was willing to follow the RFC series editorial
      guidelines, I'd probably have a quick chat with the ISOC and IAB
      (as our outwardly facing organization), and the LLC with respect
      to any financial considerations and then put it to the RSAB's vote
      to add the stream if recommended by those three groups.

    
For deleting a stream, the stream owner (if they've gotten out of
      the publication business or no longer want to bear the costs), the
      RSAB if the stream has become moribund (abandoned), the LLC if
      they're behind in their contributions, and the RSAB, ISOC and IAB
      collectively if the relationship with the stream owner has
      diverged from our interests.

    

    

      
Adrian wrote:

      
 

      
The
          crunch here is “What is the RFC Series?” and I think we have
          been dodging this question despite it being fundamental to how
          we got here, today.

      
Beyond its editorial process and output definition, do we even
        get to say more?

    

    
If I tell you I'm giving you an elephant, and you've never seen
      such a thing, and you have to provide for its care and feeding,
      wouldn't I be remiss if I didn't provide you with said
      requirements?   That's not a great analogy, because and elephant
      is a physical object with well known properties, whereas the RFC
      series is an implemented idea or ideal.  But this is all about the
      care and feeding of the series so...

    

    
 I think we're doing too much of "I'll know it when I see it"
      here and my view of what the RFC series is and others views of
      what the RFC series is diverge widely.   At some point what the
      RFC series is and where it's headed needs to be considered and the
      document that Peter is authoring is much weaker for not having
      that front and center.

    
Later, mike

    


    

    


    

    

      
Eliot

      

      


      

      

      

    

    


    

  


--------------BEC3DC096F4562732365D74C--


From nobody Mon Jul 12 11:27:19 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3AB3A0D0F for ; Mon, 12 Jul 2021 11:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 Fciw6-7ZdiEg for ; Mon, 12 Jul 2021 11:27:15 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D173A0CAE for ; Mon, 12 Jul 2021 11:27:15 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id 9so18924781qkf.3 for ; Mon, 12 Jul 2021 11:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=3Xl0lk8+rRRj6Zcz8nWub7VX7TlcdcWWBINItiSKM5c=; b=L983UJwqBsMusd99Xuipaf5Mk3BloamQv+ucsyDaKSI4jsez0DtjcfM3l2JRsxtFtO UgI/xcCEXihtYyfuAdzAn6JWaZdm2reLI9uYq95JvSKQvcD/Yw3VhgWHUQFnGLHnDxFe Yg0ihNIounfl395uViOh0EmawMk2Cbhj6tBpk54fOWkGK8jp1JMgHfWPIea35QVASk1r 4pJRmhDBuBFIOO7/VU1S0adTZkLtsnB8A6qopleKZHyvwLeVYSkji5Uh5GLedZCnNqbP xmF2eunWI46P/HyDSqWzbMw2BgWCyLOexbTazBhFy8fihZVl/JwIIFTEcJ8bRXgOfKen oCCw==
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; bh=3Xl0lk8+rRRj6Zcz8nWub7VX7TlcdcWWBINItiSKM5c=; b=E5F+vOiwZDe2Uc7mwJsQA4s2ZLuAjyYq68n6tFIuIkxhiPZRpENr3OzaHfGwvOspoj WiX+GXeUPmGlTLF5od74wKW46GgLOsESMUGWfgNWan5ZfiQ2gmKGxc6KjdaLjZtozNcb U0m5pSEImHi9iyueoDb3EYOn/JEHbKvpuxjws2cFFdFZOAZSMIbxZxb+6ek7CA0PUi9P X8UW62GoruzwgRJehmByIGSmHUdoY3+tj/KLDM4jQV+XWorasBQ8eNGnVCaXyErdTgEs 6n/2e94m7gd9HIYJ2UTrvWRcX7abwlR7RLXxGpuIW5KHDU9DemysrvCA92cBQkBwO3mg EuXw==
X-Gm-Message-State: AOAM533PyKqBQXU5TUgJWCZGPwe53ASsK0niaadE+M13hZxv3txEs4Lz uupCC3gYZNBLxxh8prFy6RK69g/ObmCXnuhHnWU=
X-Google-Smtp-Source: ABdhPJw6x2YZmOTV5J/TbQ1NDHPdDhTGKVTeJvl1yavwR5p09VRbcoaYKartmzv5aZJc9YS53tc1wQ==
X-Received: by 2002:a37:a013:: with SMTP id j19mr32101qke.77.1626114432054; Mon, 12 Jul 2021 11:27:12 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id u4sm5735290qtw.86.2021.07.12.11.27.11 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 11:27:11 -0700 (PDT)
To: rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <018a01d77747$b168fcb0$143af610$@olddog.co.uk>   <3DB3AF3D-19F7-4963-82D3-50C5F718A0FA@akamai.com>
From: Michael StJohns 
Message-ID: 
Date: Mon, 12 Jul 2021 14:27:10 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <3DB3AF3D-19F7-4963-82D3-50C5F718A0FA@akamai.com>
Content-Type: multipart/alternative; boundary="------------F7E4B6F6F59E3E3910E50BEE"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Jul 2021 18:27:18 -0000

This is a multi-part message in MIME format.
--------------F7E4B6F6F59E3E3910E50BEE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 7/12/2021 2:16 PM, Salz, Rich wrote:
>
> >On 12.07.21 20:04, Salz, Rich wrote:
>
>     > RFC’s should not exist outside of the IETF or its designees.
>
> > This is a bit too terse.  After all, the IAB, IRTF, and ISE streams 
> all exist outside of the IETF today.
>
> I said “or its designees” which I intended to cover your example. It 
> could be interesting for an historian to find out what orgs existed at 
> the time those streams were created but more than I want to do. ;)
>
Streams are a recent invention.  The answer is pretty much all of them 
existed at the times streams were created.


> Perhaps we say “not covered as an IETF activities as defined by the 
> LLC” After all, I would expect the LLC trademark protection would 
> prevent that from happening.
>
> If some random SDO wants to publish an RFC, go ahead.  Just not here.
>
>


--------------F7E4B6F6F59E3E3910E50BEE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 7/12/2021 2:16 PM, Salz, Rich wrote:

    

    

      
      
      
      

        

          
>On 12.07.21 20:04, Salz, Rich wrote:

        

        

          
> RFC’s should not exist outside of the IETF or its
            designees.

        

        
> This is a bit too terse.  After all, the IAB, IRTF, and
          ISE streams all exist outside of the IETF today.
          

        
I said “or its designees” which I intended to cover your
          example. It could be interesting for an historian to find out
          what orgs existed at the time those streams were created but
          more than I want to do. ;)

      

    

    
Streams are a recent invention.  The answer is pretty much all of
      them existed at the times streams were created.

    

    


    

    

      

        

        
Perhaps we say “not covered as an IETF activities as defined
          by the LLC” After all, I would expect the LLC trademark
          protection would prevent that from happening.

        
If some random SDO wants to publish an RFC, go ahead.  Just
          not here.

      

      

      

    

    


    

  


--------------F7E4B6F6F59E3E3910E50BEE--


From nobody Mon Jul 12 17:03:41 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3F13A0DA6 for ; Mon, 12 Jul 2021 17:03:39 -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_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=mozilla.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 kUcTHiK3W0ND for ; Mon, 12 Jul 2021 17:03:35 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 DAE923A0DA0 for ; Mon, 12 Jul 2021 17:03:34 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id k16so24841725ios.10 for ; Mon, 12 Jul 2021 17:03:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=hk1O4/mXhDFPqkkrrmwAAKCHvSzA/fpmli8XI7OqN/c=; b=Z+7D3tCd27KxG/yF7Hr0dH05cRh/ASOHmJHH3Ex3Uz/0benXKvj0ZHlhADnSYhiSit JAuV7jEdbLDxsJL8gsujZ+H7nJ7k2nQmEZ0ur2zh7iRVjk1B63tCXozkDRLpDN73Hqnd f3VUx3FQvD4wWpJWrUEmyTQzgzi37HFBVA/OI=
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=hk1O4/mXhDFPqkkrrmwAAKCHvSzA/fpmli8XI7OqN/c=; b=Xbb3EDL14pAqXrCKO1bCN9kohJWuQXfrHmGhA1/HO2LxjqwmLLKbgL74w/7JCRdx2f 2plZ05S8waOxYudJcg8n6GL+kOQXk7mBlP07lIwbXKuay824ezsAPJPYhiTGBWjhn2rG 7k7jmoXd6cJh4pxk8jZ+eqHwqT+EaMAL+gD4Cmkg5fh74Em3NDYL5GlXigA9PH1Bwt2w A3Pv8ZLIzXSLG+gF6KTzlwYOFNida8eVIFE6K+F+WpW8sUphaF41OF9Y3/Kd8GKxxEnl XSqwN/r7B7BOSFbAPiIbvPRfpiTwbLxP1VHg57ubhfnUliabFlGZtG2xuGHMMMY5vaoN fXJg==
X-Gm-Message-State: AOAM532IkbKP7NrLQ62BPTdlU9JKBNooX6dKJzlMFPAWnWhAjwR+LBb3 gh0oZUuvnFTDOoRQjsqmZiiLyw==
X-Google-Smtp-Source: ABdhPJwM/wgMXTDUy7O758lGGA/jMGJKvjtmEH6DEmMw2DtXxJrjekapTN6pnH8KBlFy3UqUbBFe8g==
X-Received: by 2002:a05:6638:22f:: with SMTP id f15mr1308824jaq.141.1626134612345;  Mon, 12 Jul 2021 17:03:32 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id x9sm8412935iov.45.2021.07.12.17.03.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 17:03:31 -0700 (PDT)
To: rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <018a01d77747$b168fcb0$143af610$@olddog.co.uk>   <0e3bc4e8-ccbc-785f-06cf-4dc742ffd545@nthpermutation.com>
From: Peter Saint-Andre 
Message-ID: <239411e3-ee07-b571-e57e-93c76de61857@mozilla.com>
Date: Mon, 12 Jul 2021 18:03:30 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <0e3bc4e8-ccbc-785f-06cf-4dc742ffd545@nthpermutation.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 00:03:40 -0000

On 7/12/21 12:26 PM, Michael StJohns wrote:

>> Adrian wrote:
>>
>>> The crunch here is “What is the RFC Series?” and I think we have been
>>> dodging this question despite it being fundamental to how we got
>>> here, today.
>>
>> Beyond its editorial process and output definition, do we even get to
>> say more?
>>
> If I tell you I'm giving you an elephant, and you've never seen such a
> thing, and you have to provide for its care and feeding, wouldn't I be
> remiss if I didn't provide you with said requirements?   That's not a
> great analogy, because and elephant is a physical object with well known
> properties, whereas the RFC series is an implemented idea or ideal.  But
> this is all about the care and feeding of the series so...
> 
> I think we're doing too much of "I'll know it when I see it" here and my
> view of what the RFC series is and others views of what the RFC series
> is diverge widely.   At some point what the RFC series is and where it's
> headed needs to be considered and the document that Peter is authoring

Correction: I'm just editing.

> is much weaker for not having that front and center.

We could pull in some text from RFC 4844.

Peter


From nobody Mon Jul 12 17:08:13 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3B03A0E18 for ; Mon, 12 Jul 2021 17:08:11 -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_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=mozilla.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 JCB3Jpy_rJqA for ; Mon, 12 Jul 2021 17:08:05 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 C24723A0E13 for ; Mon, 12 Jul 2021 17:08:05 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id w1so19377175ilg.10 for ; Mon, 12 Jul 2021 17:08:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RT+YuVDYvQMxX5lBHRrnzCw7jJ+8T5Cr8WX75HeG2Oc=; b=RU6A+47QUpyvyNbafGkbLx5nSkc6RLPHVLYoNW/y+19foFb2mOvghvccqGp+OyhPq9 6nZRvNpmh5xb2ydf8C8aGzX7yLpmT1ZEwYGcFZVsit+d+G0wWBlEtSGa8YOIWBkk9sHZ Vm9iJZHe6lj4rJtTTF92GuZo7A62/55sT4VbA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RT+YuVDYvQMxX5lBHRrnzCw7jJ+8T5Cr8WX75HeG2Oc=; b=nVOA9LaCc5XLtT/A+Ia5Xbgt9Kg9LpRUzCZJw8JVps45gEb2/pL1aL+WKx1MDCJ7Cq Ok+Ov8Q34KJEcNN5W74H4zwVRlTHcXlMmpWKYtjEVne0h+weo9NbmeX+cPOyw695I6cs VkFlhqWDdSwy+i7Lh3+ly/VIOmIw0yH4ZF7m8DSOCp7OnHHQheRlcUPwV331Cij3rDkF HP6c6mksZI1hb0SIYMI8fXQq5eQEe18A4y7e6lIS4SpEv2TxKbYFAJ97Kr2uKSBHQk/z JDUCFYmyyZZ3Od+nUpBkKHuuAxVIXl6mta1eR89Qe536jWhsiuAMU20RHjReMpNFzvEA LnVg==
X-Gm-Message-State: AOAM533mMKIcgu905AxLtG7nzGP9rC6OfMMJZj26ydlWdfERtsNQqKzR B7aV3T/JSEORoQqbUa0IUISrRw==
X-Google-Smtp-Source: ABdhPJzyGvsIDWYM6FSSMVM/kNiMjfK9WAofRZRpt0Fz7xrYhBkwReeo/GD1uetC+2spbOlJbMbVKA==
X-Received: by 2002:a05:6e02:1be8:: with SMTP id y8mr983183ilv.152.1626134884056;  Mon, 12 Jul 2021 17:08:04 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id d8sm881615iom.49.2021.07.12.17.08.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 17:08:03 -0700 (PDT)
To: adrian@olddog.co.uk, 'Eric Rescorla' , 'Eliot Lear' 
Cc: rfced-future@iab.org
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com> <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>
From: Peter Saint-Andre 
Message-ID: 
Date: Mon, 12 Jul 2021 18:08:02 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 00:08:12 -0000

On 7/11/21 7:30 AM, Adrian Farrel wrote:
> I *still* don't object to this, but (just so you know) you haven't convinced me this isn't odd.

It's my job here to (try to) capture the sense of the discussions and,
once we have it, rough consensus. AIUI, the argument is that whoever is
on the RSAB needs to be chosen more directly by the community than a
random appointee might be. I am not completely sure that this makes a
great difference in the end because a random appointee can be recalled
just as easily as an AD, or perhaps more so. In this specific case, we
might ask the IESG if they have a preference.

Peter


From nobody Mon Jul 12 17:16:39 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39C33A0FCB for ; Mon, 12 Jul 2021 17:16:36 -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_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=mozilla.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 MUM_S-Gx7fIx for ; Mon, 12 Jul 2021 17:16:33 -0700 (PDT)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 EDFDA3A0FC9 for ; Mon, 12 Jul 2021 17:16:32 -0700 (PDT)
Received: by mail-il1-x135.google.com with SMTP id e13so21447943ilc.1 for ; Mon, 12 Jul 2021 17:16:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Bo4ZlsDtjF2MUGXmTmck/gCHQD5RNVLh06ufkV14LOs=; b=J4og3uciMLBMAXhhn6ck6/3160UmZi9vav38YyaPq8/h4LQwIEO2ff5DQvNzsygtGc FajawziZMUJUpL/m0Ns9WzmHz2yowHNsalCIPUCU8L01ZF3E/ir7uR4UMWHT4Hkw3lC/ U+Bjme9g2pXYAPXCzGQm73TAWExLoY5WvyGzY=
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=Bo4ZlsDtjF2MUGXmTmck/gCHQD5RNVLh06ufkV14LOs=; b=At1IvsoNsCfsWyNbcs5va/kwdVrrnpE2ZZrfwBge16iXvM0YDakhpgpYBx0LDIzdkb Gb62dKbdVFFzce3lREFUlOli+GxQamUECBDYMZ6nyigg8VJ1tH6zf7RFU6XQVpD1D5ZA 5sVvS5terVl3aPnnFZM0DUdW3Ch4ykDe3N1Y+0HkVJqCxjk/E7LFhxR/Pm5zyJ63wtBO ZJVXsas7FcE3zS7ChoU4S071/Jhxy3fyzSwZvV3MufI9ELOX5ehcEegKnfpDT75IXJOP bZlK3FZFy8H7dUhmZuOudCElfTY66eJyPeot0nQTwYSWrQnxwR7jq2RFCchmTSza2oPf rULg==
X-Gm-Message-State: AOAM533xik2aQuqSc+od/egvcXyrkB0lin+HIEWEHY+wBVFlIAj1vBoN q6r39a1HgXD17HUSIgHT36D0cg==
X-Google-Smtp-Source: ABdhPJzR0ak66IkwPqM+2+501fTz8LYsy+n6wubjXtr+5+jG/bfcyW5qpHRPiAhoYgLA5Qk9wfqnfA==
X-Received: by 2002:a05:6e02:1e02:: with SMTP id g2mr1014536ila.6.1626135391116;  Mon, 12 Jul 2021 17:16:31 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id x9sm9134836iol.2.2021.07.12.17.16.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 17:16:30 -0700 (PDT)
To: adrian@olddog.co.uk, 'Eliot Lear' , rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <018a01d77747$b168fcb0$143af610$@olddog.co.uk>
From: Peter Saint-Andre 
Message-ID: <62abcd04-ec1f-ed5b-5c9b-159f52b79b9a@mozilla.com>
Date: Mon, 12 Jul 2021 18:16:29 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <018a01d77747$b168fcb0$143af610$@olddog.co.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 00:16:37 -0000

On 7/12/21 11:59 AM, Adrian Farrel wrote:
> Hi,
> 
>  
> 
> I’m struggling with this one a bit.
> 
>  
> 
> Sadly, I think this is not the small question that it might appear from
> your email. To me it is essential to the definition of the “RFC Series”
> to define what streams exist.
> 
>  
> 
> I think there are two classes of stream:
> 
>  1. Those that the IETF would like to exist
>  2. Those that exist outwith the IETF
> 
>  
> 
> In class a) we have all of the current streams (IETF, IAB, IRTF, IS) and
> they are defined and controlled by existing RFCs. To remove one, to
> merge two, or to create another would be acts of IETF consensus (in one
> way or another).
> 
>  
> 
> In class b) we could envision another SDO or forum that works on
> Internet specifications coming to the RSE and asking to be published as
> RFCs. I can see the IETF having a strong opinion on this, and I can see
> “the decision-maker” taking those opinions very seriously, but I can’t
> see why that would be the IETF’s decision or the IAB’s decision. The
> crunch here is “What is the RFC Series?” and I think we have been
> dodging this question despite it being fundamental to how we got here,
> today.

I don't disagree.

> Now I realise that Peter’s question is a meta-question. 

Actually I was just replying in thread. :-)

> Not “what should
> be the process?” but “who gets to decide what the process is?”
> Nevertheless, the question is so fundamental to what the RFC Series is
> and what the responsibilities of the various actors are, that I think we
> have to look at it to uncover the implications. Otherwise we are simply
> making a decision by hiding from the question.

After I posted in this issue / thread, while working on our I-D I
realized that this document needs to specify what the process is. How we
bootstrap the authority to specify that is another question...

Peter


From nobody Mon Jul 12 17:22:39 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE64D3A106D for ; Mon, 12 Jul 2021 17:22:37 -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 nHOdsLFkaOUL for ; Mon, 12 Jul 2021 17:22:32 -0700 (PDT)
Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60703A106A for ; Mon, 12 Jul 2021 17:22:32 -0700 (PDT)
Received: by mail-vk1-xa2e.google.com with SMTP id x125so4444416vkf.0 for ; Mon, 12 Jul 2021 17:22:32 -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:content-transfer-encoding; bh=hXHcqSGLYihUJcHzai6jF8Mjmx8kXQB3DcFXPAA44qE=; b=lSkWmTWv1Of7AqnyHrVV5e9ClJ5EkLuMzKUoZKVQcn5DZpEyyUeMhyv+gwXYD+ENqo bxYKPiBGxtgFvHuUx2jrVDJZg8h+DmiWMSLGDlRKjzVjvrGkq+oAmtzJi/tk3CWjx3lR 7L7X6SV/3MmnHpA6naxZUnpg/iLpk3/xoKu6Wf/imm2yuRL8MxrkbUahuDF9vFkXfx9L 4oOjGlJi4ArMkfcgZTp3oLBsiUBpATMwixyQ9/WhG5bmr39jkSPxr6PuYY2S3RaXvumR KklwFOi/waWCdujSgTCZ3M71PVm6yaQXM/BScYvqvR4LxhjDLjhPBAatpB4mgYnHz1Tt 6z0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hXHcqSGLYihUJcHzai6jF8Mjmx8kXQB3DcFXPAA44qE=; b=RHBNDDRVV1G581+b+u/dRyziWGCQQMDZSik/+H+jxCxKyZKDD3Xh5+Vu9gxC0HA/pA +mrGXCm47eWH3qW/GEkwV87bFp7FsU3p8uIOtq+IdYhBkg6nkjfgKG5eS1hoUPRsjfNj /V6EyWcpy6ZH6bq7IZWmcMo2q8Zgy9DUYtuFAMgjrxcDsdBYLqNfnEQzyruTN1oc1rt5 CdnoXwPWC2FJrPjgxzgeYiLfigxVpyrgywLaEYouDM688tMV73kspqf0+Qc31HuVZNUs QN/njbhOAVWTKRE7t64+N9nXkOB3rFtpmy62poOw7vW8jN7Su3FUnYwfnulOzaHBBdf5 QhxQ==
X-Gm-Message-State: AOAM5325G+Vrrrjz6z6X5CONS4D/SjTqIQbMFXSHvzx1BeJQeZHR678Q 0ZuZ2J26Qgt0fWCnLbJ0g+MQR0zMfv4P5ntBxoYJJ2gJ31A=
X-Google-Smtp-Source: ABdhPJz6U6iPmZFRJN4cpImfTCZSmt/ymX8fOLQK8URpDU3yM/IM2n1fIkYjvzYEIuJW8hdb8iCBYFX6i4ZfvzUkeVo=
X-Received: by 2002:ac5:c392:: with SMTP id s18mr1918200vkk.17.1626135750651;  Mon, 12 Jul 2021 17:22:30 -0700 (PDT)
MIME-Version: 1.0
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <018a01d77747$b168fcb0$143af610$@olddog.co.uk>
In-Reply-To: <018a01d77747$b168fcb0$143af610$@olddog.co.uk>
From: Nevil Brownlee 
Date: Tue, 13 Jul 2021 12:22:03 +1200
Message-ID: 
To: Adrian Farrel 
Cc: rfced-future@iab.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 00:22:38 -0000

Hi Adrian et al:
A little bit of history of "new streams."  Back about 2012 Heather was
approached by another organisation asking "could you publish our
documents (as RFCs)"?
That caused a fairly long discussion by the IAB and IESG of the day;
the outcome was "no, you're likely to have very few documents, submit
those to the Independent Stream (via the RSE)".
That still seems sensible to me, this group could just ignore it, or
maybe say something like "if a new stream is created (by the IAB), the
stream manager for that new stream should - in principle - become a
member of the RSAB".
Cheers, Nevil


On Tue, Jul 13, 2021 at 6:00 AM Adrian Farrel  wrote:
>
> Hi,
>
>
>
> I=E2=80=99m struggling with this one a bit.
>
>
>
> Sadly, I think this is not the small question that it might appear from y=
our email. To me it is essential to the definition of the =E2=80=9CRFC Seri=
es=E2=80=9D to define what streams exist.
>
>
>
> I think there are two classes of stream:
>
> Those that the IETF would like to exist
> Those that exist outwith the IETF
>
>
>
> In class a) we have all of the current streams (IETF, IAB, IRTF, IS) and =
they are defined and controlled by existing RFCs. To remove one, to merge t=
wo, or to create another would be acts of IETF consensus (in one way or ano=
ther).
>
>
>
> In class b) we could envision another SDO or forum that works on Internet=
 specifications coming to the RSE and asking to be published as RFCs. I can=
 see the IETF having a strong opinion on this, and I can see =E2=80=9Cthe d=
ecision-maker=E2=80=9D taking those opinions very seriously, but I can=E2=
=80=99t see why that would be the IETF=E2=80=99s decision or the IAB=E2=80=
=99s decision. The crunch here is =E2=80=9CWhat is the RFC Series?=E2=80=9D=
 and I think we have been dodging this question despite it being fundamenta=
l to how we got here, today.
>
>
>
> Now I realise that Peter=E2=80=99s question is a meta-question. Not =E2=
=80=9Cwhat should be the process?=E2=80=9D but =E2=80=9Cwho gets to decide =
what the process is?=E2=80=9D Nevertheless, the question is so fundamental =
to what the RFC Series is and what the responsibilities of the various acto=
rs are, that I think we have to look at it to uncover the implications. Oth=
erwise we are simply making a decision by hiding from the question.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> From: Rfced-future  On Behalf Of Eliot Lear
> Sent: 12 July 2021 10:47
> To: rfced-future@iab.org
> Subject: [Rfced-future] Issue #73 Who is responsible for creating new str=
eams?
>
>
>
> Hi there,
>
> I opened this issue, and while it is related to who sits on the RSAB, it'=
s a little different.  The question is really this: what is the process to =
create / delete editorial streams?  Does it go through the IETF process?  D=
oes it go to the IAB?  Does it go through th RSWG/RSAB process?
>
> Peter asks this question: is it beyond the remit of this group to decide =
that?  My gut says that this is not this group's decision but perhaps an IA=
B decision or IETF decision or something in between.  To say otherwise woul=
d seem the tail wagging the dog.  Unless people disagree with this logic, I=
'll close the issue.  Please comment by the 26th.
>
> This having been said, I do think this may be an issue for Brian's 2850 u=
pdate doc, since the IAB has previously held authority to manage that proce=
ss.
>
> Eliot
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future



--=20
-----------------------------------
Nevil Brownlee, Taupo, NZ


From nobody Mon Jul 12 19:53:06 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D853A0D7B for ; Mon, 12 Jul 2021 19:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YsB5jQVf2fO for ; Mon, 12 Jul 2021 19:53:02 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 120DC3A0D7C for ; Mon, 12 Jul 2021 19:53:01 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id c15so10310400pls.13 for ; Mon, 12 Jul 2021 19:53:01 -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=G8Cnz0nU5t6WAC+ybeVU2vC6BhHKAvs8YNBA97QFodI=; b=ECwTqnvghu+aNqJcmqPrlh2ZN/MLVD6R2D6+iBCLTdzM+KtUSyxeEJFxb7p2w6gNyp e8l78qTnLE/jlDYtmzuwKcPMqeKF7/MU/7LaPIyLRwLKuDs4bIC8A8vv/qdpl+okFdDs c+n+ARB0ZOulkn0Fy8aCbVsFhSV/Sf0l1EL7l/4CRgnN/ueQIsTcw/GsVaEIwgdSEslT 4hFWB4h87CeTAKJy5txSikZsN2moB2HTBNMn+WT8xab6k0qH26vy01tptYsM3pDyifHV ZgzgZs5THw1TMil1wH8XRHVrmXxfzohf7wkARYNFjSn+tiC3Vaj2V6tiJnhAFG6X5Cq7 5CeA==
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=G8Cnz0nU5t6WAC+ybeVU2vC6BhHKAvs8YNBA97QFodI=; b=ZsZDF+baXRm2aOormtkfn2ClbCfAeXGDC9YTc7T/uCm3md0Ez/kDAa7Ln/8MUJDg+E Mb5g3H+K4mqW67FyJGjfIvzJs4mbhJ0NWrCCFx4eQBDkCFy1OlFmkj7/FfASSjGw5ySj /EynDaryCZkJifZracTl1CuDp/xcgrdoAHOEIoC4KIayBfzZttRFv4vhKah5Ls2Hg7q2 9ZJtAqJ8YbVluS8s4OxxJ0/pr+YSdw2tGD74Laxoi4SlbSIGvTE0QsJVeVeZZDxhAul5 MfRZAHqTTocG4jHBTwGe2WifmgvEUZPGD5+9TWtUsy8gBfVXWhtQkXdm0Zw4vSX+pFZR I64w==
X-Gm-Message-State: AOAM5316+KBjKm0udzbbDS17lEqhZxycEWieM01+ERxDEdLlgRO7cOFx IP0luFy/VjPMqioaPxsicb/dzRkX/u9RJQ==
X-Google-Smtp-Source: ABdhPJzSO1ltfFKBKoEqmQRVSAMBqjupTA/KSqzCw17Hj7bgrS2KG1jlLOZ2D+otkentrZy37D9U0Q==
X-Received: by 2002:a17:90a:5b07:: with SMTP id o7mr2043260pji.35.1626144780770;  Mon, 12 Jul 2021 19:53:00 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id g18sm17244829pfi.199.2021.07.12.19.52.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 19:53:00 -0700 (PDT)
To: Michael StJohns , rfced-future@iab.org
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com>
From: Brian E Carpenter 
Message-ID: <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com>
Date: Tue, 13 Jul 2021 14:52:56 +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: <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 02:53:05 -0000

I don't think there is any proposal to retire the term "RFC Editor".
But for many years it has referred to the function as well as to
the figurehead. RFC2850 refers to "an organization to act as
RFC Editor" because even in May 2000 it wasn't a person, although
Bob Braden led the team. And also "The Internet Society, the RFC Editor,
the IANA and the IESG each appoints a liaison member to the IAB."

Given the job description and role of the RSEA, I really don't see
how we can call the person an editor.

Regards
   Brian Carpenter

On 13-Jul-21 05:20, Michael StJohns wrote:
> Bob said it better than I can.=C2=A0=C2=A0 Mike
>=20
> On 7/12/2021 12:58 PM, Bob Hinden wrote:
>> Hi,
>>
>>> On Jul 9, 2021, at 2:03 PM, Peter Saint-Andre  w=
rote:
>>>
>>> The role played by the technical publishing expert in version 3 of th=
e
>>> model is different enough from past roles that I suggest we should no=
t
>>> use the name "RFC Series Editor" but instead "RFC Series Advisor=E2=80=
=9D.
>> I strongly disagree.
>>
>> The RFC Editor role has changed multiple times in the past in many way=
s and we still call it the RFC Editor.
>>
>> This includes:
>>
>> Administrative support and direction changed from Defense Advanced Pro=
ject Agency (DARPA), the Internet Society, IAOC, and currently the IETF L=
LC.
>>
>> It has been performed by Jon Postel, Bob Braden, Joyce Reynolds, Glenn=20
Kowack, Olaf Kolkman, and Heather Flanagan.
>>
>> Actual editing has transitioned from an individual to a contracted com=
pany.
>>
>> The scope and the context of this position has changed as the administ=
ration and the person doing the job changed.   It has great name recognit=
ion.   I don=E2=80=99t see any reason why what we are defining now can no=
t be called the RFC Editor.   Changing it the =E2=80=9CRFC Series Advisor=
=E2=80=9D will cause considerable confusion in the larger community.
>>
>> Bob
>>
>>
>>
>=20
>=20


From nobody Mon Jul 12 20:06:36 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506C43A0E79 for ; Mon, 12 Jul 2021 20:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHlUjxANOLn9 for ; Mon, 12 Jul 2021 20:06:33 -0700 (PDT)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 1BDCC3A0E78 for ; Mon, 12 Jul 2021 20:06:33 -0700 (PDT)
Received: by mail-pj1-x1031.google.com with SMTP id me13-20020a17090b17cdb0290173bac8b9c9so522500pjb.3 for ; Mon, 12 Jul 2021 20:06:32 -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=bI041REjfLzuv6L4w6BUjEYjndzUj04eDlmoqHJVAis=; b=g+3qh0Js48xT5qgfSZSvm+M9d5OySMJncVLXalgvRfUvDC/vE4JdvXI7gI+r6pKwJX zCHGW+rnl+TptWEaiLAN2Hw8f6FPvZr2Mg4xOTQvv7ukhy44iit3DhE2IJ9toMVVBtqT aZzxFe2YXNvij2Z7vbG/2Lh7mnMPqHm1ZgsmmOTX3+AxQWS8R9xPvy4DTtiOUL7p8Feq T+ml4ekml2ytHQHiuHbKUnxVF8m7IK0pwN9hkKA8sRJc6QQdMW64S6K9Qb9GRZOJnFBQ YVSttj0fREBYe4nUwu+abBwdRSX/xEHZki4lz6ZSbj+oOyVR/EQNJZ9tta6dZlX0Ub9J FQNg==
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=bI041REjfLzuv6L4w6BUjEYjndzUj04eDlmoqHJVAis=; b=mei4Bl/MezsZ2Cg+AHTTyJ56L9vOZvJQNnwZjwvfQkKqWqIycAFpSdndc9mhACVgFP woQTsO+OZRfUPx6Cz6Ga+713pnSWidpouNDyI0a3skukJGvKjLKNroCUfbUEa77txI+m GMlrDg78aaaf9DFJd0keiS2p1iQh1lIpCyXeL8t7SS92gH7N189qw3AACnRze2iUWSAw t+cHCW1eOLgwruXx6Gc4ZB/ClSAEDSunZWb7KYL/sRpYulPlVkGRa0HU8a1uFCmRqQ0q vhnnHHgtoNFx+i3mh5KzM47e9i/upNaXAhzUOvP5szjEedCWkCJNAYRe7MFmerYFUz6f U7UQ==
X-Gm-Message-State: AOAM533LmqdM37xTvAbehH3VNT7D3atDiIOS7K+snVNdg+Hoph4D/4f2 hjR1KvkZMVp6Wt8gAzZjGU0OBTgIoXAhEQ==
X-Google-Smtp-Source: ABdhPJy2FcsG16wn74uGPDUtHY7Lqx0uL/6WkE6c8ppRtdefV8d4C4Joz7GzPjqLTm7JDijDfNW06w==
X-Received: by 2002:a17:903:2c2:b029:101:9c88:d928 with SMTP id s2-20020a17090302c2b02901019c88d928mr1906138plk.62.1626145591724;  Mon, 12 Jul 2021 20:06:31 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id j21sm17037672pfn.35.2021.07.12.20.06.29 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 20:06:31 -0700 (PDT)
To: rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <018a01d77747$b168fcb0$143af610$@olddog.co.uk> 
From: Brian E Carpenter 
Message-ID: <2b337c4d-b724-d944-c641-c783bacffb81@gmail.com>
Date: Tue, 13 Jul 2021 15:06:28 +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: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 03:06:34 -0000

On 13-Jul-21 06:04, Salz, Rich wrote:
> RFC=E2=80=99s should not exist outside of the IETF or its designees.

So all RFCs before 1986 don't exist?

The IETF is not, and never has been, in charge of the IRTF, nor
in charge of independent submissions (even before the streams
were formally designated). The IAB created the streams, not
the IETF.

In short, the IETF does not, and never did, own the RFC series.

We have backed off from discussing whether an independent
RFC Series Foundation is needed, but if you'd like to spend
six months debating that question, let's do it. Personally
I think we're better off with the chain of responsibility
being RSWG->RSAB->IAB->ISOC (with an IPR side branch to
the IETF Trust and a financial side branch to IETF LLC).
But the IETF *is not* in the chain of responsibility and
never has been.

   Brian


From nobody Mon Jul 12 20:25:44 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFF33A103D for ; Mon, 12 Jul 2021 20:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMuQmUEQ7nVq for ; Mon, 12 Jul 2021 20:25:38 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 05C2C3A1039 for ; Mon, 12 Jul 2021 20:25:37 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id me13-20020a17090b17cdb0290173bac8b9c9so545713pjb.3 for ; Mon, 12 Jul 2021 20:25:37 -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=jNy1CnjfPc9qa1hyQDXlFcS7Si5zY55YE9tJUzCeLHM=; b=BcaiZOeVpDZHCCE4scytuSsjPsXwxCmlWSe1iJ5yty4jMcMlCnGommg82ou1gCBs1A fD2IcA3s+uPWBKQM+99OMOeNtxlvdvk0yO6fku6MxnIYOPgUbLNKbw36L7i4WhU4Ne8l oZC4//xpEZH+zMnjaE+vFH0Ac+vm4VOvAv6su2QsFt2n86dIXDkts4jxJqDtBKg1pb7G Dm5GlMNnKMqhYt7M7W5Q58ELLOxodfNrkQqKeZ8hXVuV/RnjG8VmMEC+slQltJbN0rAU rNFZZRa8nhIiwNRdbe4f/pOGxDg3Luhf1ee8dL60N0g5j9j0n3EqthM3XqISL7OQ4Wkd j9AA==
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=jNy1CnjfPc9qa1hyQDXlFcS7Si5zY55YE9tJUzCeLHM=; b=tUUEQa0+3oJYThWJsoCg1HLBaX2ZuUFxSyuIxGTrrL90w7Naw3rz8JGFJU1xg+frFw pE0vh70XVHSyJNW57HbYb9Gmyz7eP30f/qyRH8JcB6Ads9n2xp7YD5G1ZYjwyJCBykOh aPXWdve1qb0Q7bMrMFH+G0QEDap2zJ5nH+lL2HDKmA3+Wm7PnHdFquM0cfxik38mvfHH yddVuunB9dgXHMmHuDlY7Oorsn8BaylmprPakca9vkx/ON+mWIHJb7j3noT5Alk+Om+q Bnu0V0zmQ/rzaokw89z0eHozlhOKP9oXc9SvoAiVddsQGTMKAesiYS9aTv+HcDqwyuul +C5w==
X-Gm-Message-State: AOAM530vPNeTLNvfNzCFPfZq5xkPpGX/iAnJ+ilMfYNhzym78ZSLmnbu KURHJdL+3pMYTpFPSUB7leLy5fzIky+L5w==
X-Google-Smtp-Source: ABdhPJyRFJiT4eM1kirRkFOzfNLRxL6WbgDO+IfsbAxzVfd4yNIzYFhHGbJa0Qe8voQ0f3WPDjFLYg==
X-Received: by 2002:a17:902:e852:b029:128:e56b:3227 with SMTP id t18-20020a170902e852b0290128e56b3227mr1782184plg.81.1626146736290;  Mon, 12 Jul 2021 20:25:36 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id b13sm16273588pgk.66.2021.07.12.20.25.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 20:25:35 -0700 (PDT)
To: adrian@olddog.co.uk, 'Eliot Lear' , rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <018a01d77747$b168fcb0$143af610$@olddog.co.uk>
From: Brian E Carpenter 
Message-ID: <10f56b5d-d5c9-5aa8-9ee5-8a1c7fa75518@gmail.com>
Date: Tue, 13 Jul 2021 15:25:32 +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: <018a01d77747$b168fcb0$143af610$@olddog.co.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 03:25:42 -0000

Adrian,

On 13-Jul-21 05:59, Adrian Farrel wrote:
> Hi,
>=20
> =C2=A0
>=20
> I=E2=80=99m struggling with this one a bit.

I suspect we are making it more complicated than it needs to be.
I fully agree with Peter that more (much more) material from RFC 4844
needs to be brought in. If we accept the mission statement from there:

   The RFC Series is the archival series dedicated to documenting
   Internet technical specifications, including general contributions
   from the Internet research and engineering community as well as
   standards documents.

that already sets a (fairly wide) boundary on what new streams might
exist. But I don't agonise about who has authority once we set up
the RSWG and RSAB: they do. We can charge them with ensuring that any
proposed new stream meets the above mission statement *and* is adequately=

funded. So let's try a thought experiment. The people from the Martian
Internet (that's the Internet on planet Mars) start writing their own
standards and want to publish them as RFCs. However, after a while,
the Independent Stream no longer suits them and they propose to add a
Martian stream. The RSWG discusses this, does a polite cross-check
with the IESG, and decides there's no conflict.

Then the RSWG asks the RPC how much this would cost, and the answer
is far too much for IETF LLC to absorb. So they tell the Martians
they need to find 30 Bitcoins a year, and they never hear from Mars
again.
=20
> Sadly, I think this is not the small question that it might appear from=20
your email. To me it is essential to the definition of the =E2=80=9CRFC S=
eries=E2=80=9D to define what streams exist.

Yes. But why wouldn't that be the ongoing responsibility of RSWG+RSAB?
If not, what are we doing here?

    Brian

P.S. This will not be a re-run of the ICANN/TLD horror show, for reasons
that seem obvious. Having your own vanity RFC stream will never be a thin=
g.

>=20
> =C2=A0
>=20
> I think there are two classes of stream:
>=20
>  1. Those that the IETF would like to exist
>  2. Those that exist outwith the IETF
>=20
> =C2=A0
>=20
> In class a) we have all of the current streams (IETF, IAB, IRTF, IS) an=
d they are defined and controlled by existing RFCs. To remove one, to mer=
ge two, or to create another would be acts of IETF consensus (in one way =
or another).
>=20
> =C2=A0
>=20
> In class b) we could envision another SDO or forum that works on Intern=
et specifications coming to the RSE and asking to be published as RFCs. I=20
can see the IETF having a strong opinion on this, and I can see =E2=80=9C=
the decision-maker=E2=80=9D taking those opinions very seriously, but I c=
an=E2=80=99t see why that would be the IETF=E2=80=99s decision or the IAB=
=E2=80=99s decision. The crunch here is =E2=80=9CWhat is the RFC Series?=E2=
=80=9D and I think we have been dodging this question despite it being fu=
ndamental to how we got here, today.
>=20
> =C2=A0
>=20
> Now I realise that Peter=E2=80=99s question is a meta-question. Not =E2=
=80=9Cwhat should be the process?=E2=80=9D but =E2=80=9Cwho gets to decid=
e what the process is?=E2=80=9D Nevertheless, the question is so fundamen=
tal to what the RFC Series is and what the responsibilities of the variou=
s actors are, that I think we have to look at it to uncover the implicati=
ons. Otherwise we are simply making a decision by hiding from the questio=
n.
>=20
> =C2=A0
>=20
> Cheers,
>=20
> Adrian
>=20
> =C2=A0
>=20
> *From:*Rfced-future  *On Behalf Of *Eliot=20
Lear
> *Sent:* 12 July 2021 10:47
> *To:* rfced-future@iab.org
> *Subject:* [Rfced-future] Issue #73 Who is responsible for creating new=20
streams?
>=20
> =C2=A0
>=20
> Hi there,
>=20
> I opened this issue, and while it is related to who sits on the RSAB, i=
t's a little different.=C2=A0 The question is really this: what is the pr=
ocess to create / delete editorial streams?=C2=A0 Does it go through the =
IETF process?=C2=A0 Does it go to the IAB?=C2=A0 Does it go through th RS=
WG/RSAB process?
>=20
> Peter asks this question: is it beyond the remit of *this* group to dec=
ide that?=C2=A0 My gut says that this is not this group's decision but pe=
rhaps an IAB decision or IETF decision or something in between.=C2=A0 To =
say otherwise would seem the tail wagging the dog.=C2=A0 Unless people di=
sagree with this logic, I'll close the issue.=C2=A0 Please comment by the=20
26th.
>=20
> This having been said, I do think this may be an issue for Brian's 2850=20
update doc, since the IAB has previously held authority to manage that pr=
ocess.
>=20
> Eliot
>=20
>=20


From nobody Mon Jul 12 21:00:16 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEF43A11BD for ; Mon, 12 Jul 2021 21:00:15 -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 S_ORJmY139wc for ; Mon, 12 Jul 2021 21:00:09 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAD83A11BC for ; Mon, 12 Jul 2021 21:00:09 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id l6so4394743wmq.0 for ; Mon, 12 Jul 2021 21:00:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TsS+5i8/dOpBLSP2bfFKktUyBPH21S8BB4bz4AkGB0M=; b=YZWQ1u400cNVfD0l/97kIqMDOdBDc54XreLyMBWepXNtoH7QEkTBubDxPTmg56pcBN pv0dR8PlFylA29mEQcLx7B0YHWbzqw0NSW9zFkZuTs1Q/MKGIlmYtiwzwgj2EoToRxBX r7k/wGWZsD+/MuLsccwk2t4m9DsvsjOFc+UxDdy9DhQexgsPN0IrQNXl3LiCaLTDq/lQ IGgR2Bl/aUKm8iReDei5e9PxZm+AQ1rXDeH5Dkt2CWYOYd/S6Umdt15FQk9M6tsxHsXg G04NTPnKVWTDkQoWv92528dkduIbJRjVHdOiJJk2LiikMFAWCVter/qk9CVmV0lZjrIM cWgg==
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=TsS+5i8/dOpBLSP2bfFKktUyBPH21S8BB4bz4AkGB0M=; b=HLi82GFWHSaankRr+E6HW5a9TM/lF66oSoxw3s3Tz6dCtEkG/Kw2UK/58tDWQv579B 7rUO/OlfW9wjtuEYiN+CqO1c9gph0UC7/JZ42VGAFR/VgttgWHxAIMgZzxVmtXg2kz+G llpIwRZmEA8xe0pw4JJMfU8aCNGOnlCzH2q64t6GexO9+zED/Hvq0D9QIiZldPGroYdN kwz8I/HsQa/paOJbfUd68GoG81ztiX6zwJc6F7aB0plbT12kKFm0sUS1H97VFL9aGS4v P0AlJL0y/OThwRKQuTgIaC3KLpiY2x6duqoVgHYU3YB3lPFhQEO4xvhrbSnTHAoK0R2T uz1A==
X-Gm-Message-State: AOAM532XSbkqzjfX92i6fGPRJ4TXR5UV8YvuFNuMyplcjcwfFW19MjC4 GsLWrX1ujpVTcCTD3iJyCug=
X-Google-Smtp-Source: ABdhPJyR9X3LaYmUcJHMHHF5Qd7y/sBA4HFOFjGZuJwQja0z/yeKavc25dCRulroBzidICrHASHxaw==
X-Received: by 2002:a7b:c316:: with SMTP id k22mr17673719wmj.56.1626148806426;  Mon, 12 Jul 2021 21:00:06 -0700 (PDT)
Received: from [10.0.0.199] (c-73-223-183-113.hsd1.ca.comcast.net. [73.223.183.113]) by smtp.gmail.com with ESMTPSA id n18sm5758653wrt.89.2021.07.12.21.00.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jul 2021 21:00:05 -0700 (PDT)
From: Bob Hinden 
Message-Id: <02994423-D9CB-4996-B831-E87900EC9250@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_6789B0F7-7A3E-4E1C-807B-4CF7672B64F3"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Mon, 12 Jul 2021 21:00:01 -0700
In-Reply-To: <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com>
Cc: Bob Hinden , Michael StJohns , rfced-future@iab.org
To: Brian Carpenter 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 04:00:15 -0000

--Apple-Mail=_6789B0F7-7A3E-4E1C-807B-4CF7672B64F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Brian,

> On Jul 12, 2021, at 7:52 PM, Brian E Carpenter =
 wrote:
>=20
> I don't think there is any proposal to retire the term "RFC Editor".
> But for many years it has referred to the function as well as to
> the figurehead. RFC2850 refers to "an organization to act as
> RFC Editor" because even in May 2000 it wasn't a person, although
> Bob Braden led the team. And also "The Internet Society, the RFC =
Editor,
> the IANA and the IESG each appoints a liaison member to the IAB."
>=20
> Given the job description and role of the RSEA, I really don't see
> how we can call the person an editor.

Think about it like positions in the US called =E2=80=9CSecretary of =
State=E2=80=9D, see:

https://www.state.gov/secretary/

They are not performing secretarial duties.

Bob


>=20
> Regards
>   Brian Carpenter
>=20
> On 13-Jul-21 05:20, Michael StJohns wrote:
>> Bob said it better than I can.   Mike
>>=20
>> On 7/12/2021 12:58 PM, Bob Hinden wrote:
>>> Hi,
>>>=20
>>>> On Jul 9, 2021, at 2:03 PM, Peter Saint-Andre  =
wrote:
>>>>=20
>>>> The role played by the technical publishing expert in version 3 of =
the
>>>> model is different enough from past roles that I suggest we should =
not
>>>> use the name "RFC Series Editor" but instead "RFC Series =
Advisor=E2=80=9D.
>>> I strongly disagree.
>>>=20
>>> The RFC Editor role has changed multiple times in the past in many =
ways and we still call it the RFC Editor.
>>>=20
>>> This includes:
>>>=20
>>> Administrative support and direction changed from Defense Advanced =
Project Agency (DARPA), the Internet Society, IAOC, and currently the =
IETF LLC.
>>>=20
>>> It has been performed by Jon Postel, Bob Braden, Joyce Reynolds, =
Glenn
> Kowack, Olaf Kolkman, and Heather Flanagan.
>>>=20
>>> Actual editing has transitioned from an individual to a contracted =
company.
>>>=20
>>> The scope and the context of this position has changed as the =
administration and the person doing the job changed.   It has great name =
recognition.   I don=E2=80=99t see any reason why what we are defining =
now can not be called the RFC Editor.   Changing it the =E2=80=9CRFC =
Series Advisor=E2=80=9D will cause considerable confusion in the larger =
community.
>>>=20
>>> Bob
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>=20
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future


--Apple-Mail=_6789B0F7-7A3E-4E1C-807B-4CF7672B64F3
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-----

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmDtD8EACgkQrut0EXfn
u6hXmgf+JxldWa4ruULfLjx4XFZ04MXPYqFEg/laTQ3lxOSgcRETE1TZHL/9TKaT
2jMxHfDtFlG0NaJBMY86GXevkr3kJOgjmwIvcsp169ciQ880+XEXSLrI4BRtvb+d
FadtHllkmfsm+Ta5vZBWd4B5Ke+55o7onGo030OAVWn0T+IW3hsGfZrSnS7CkQRT
ZnGni4KXxgTjUkqpkd7vzAJ1kaZaYIv6/mzixc7WcAq64ErSfh4mZL084e3q+9GL
sPUbDU9fmfaNqz6oarcZnO8DrftKvY2WKoGmbDhtrUPydj68VUlpmXRMD7Ed3Yiv
BvjthQ8/nha3WBjYHz/WM9CkJ/V/VQ==
=7va8
-----END PGP SIGNATURE-----

--Apple-Mail=_6789B0F7-7A3E-4E1C-807B-4CF7672B64F3--


From nobody Mon Jul 12 21:11:21 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEA23A121D for ; Mon, 12 Jul 2021 21:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1Cu5K6mb-A4 for ; Mon, 12 Jul 2021 21:11:14 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 D8ED83A121C for ; Mon, 12 Jul 2021 21:11:14 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id b8-20020a17090a4888b02901725eedd346so1277889pjh.4 for ; Mon, 12 Jul 2021 21:11:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Ra+hD6HGH2MbgHYOA4lIQdH11trEV2bTt2lcZYrxu1E=; b=fI4e+85DbiN792bwu7glr99k0aCQzhYr1RXar0PIfeSDcUQaNhHjM0rQE690IRWCsp 5u0iCiIpvinVB8a6dw7SxpoIzqSPDfN/oHuluU+NYf2P5jArCk0RVeZCJqRLMWBHo9kE 2zXeVyprgNRSwARjfnONPp+kq6V1zlu5BB7fxVj3BKcy1kYGPzTD5LSMt2bWbaOP3R34 XczBHNi2j6h+X1q9PNnw2To2Pzb7w5yAZsUZnLSDGCja3uzAGBfvG4Etkitcg2KSvSfG jhkKQMAMmOyDGSqDlOkvO+WxedhE0lCej2D6bg6OJL0H2OTD9k/E1as9t2T8WVf70uYY DiLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ra+hD6HGH2MbgHYOA4lIQdH11trEV2bTt2lcZYrxu1E=; b=cgnetquhzM+vPrNMtVzHNcyKokw/dpd0tCWeK/ZkeVYWdnLAdg+BI3bEypDHABkvLi dHOIVR9O0Ghg8j0H/9XQS2APOojz+df6SKuxsAtFs1suBv1nJvZvlPqxC+yLo3s7PL6L m9/Td1LGDtl5QEmbsY/s9Qt0dBU4pGZLQ+pMGDHzSMfQDlROwLRYy4MNK3R4hc8TZFtq lUten0SsgePYCvRCWK+87WfAhYnx5IjW04ZtW2Q7Xivs41L8SxzU1v6JxXWUDp8pJqWm 5SOu7uYkv8NnXKyNWblnbS8/KrxM7B0UGwwIRtBSWboBKgF3PTK4KXlxSDllsMsmvNCM sg9A==
X-Gm-Message-State: AOAM531ed/uOTZdcGnlf6wWEX7WRJAPlp0/mh0lG/Y1DsTNiHxHvYUQf 8SZMTnj5o6BQuAdwMandbI71dx/x9cFiiA==
X-Google-Smtp-Source: ABdhPJz/tvE3nGz4BSy3tN06mC6yRys6Fa96htdWPpq9TwCHQjRLaNQrzzAs4p15ip2rJ7qGFR4KkQ==
X-Received: by 2002:a17:90a:7884:: with SMTP id x4mr17920898pjk.53.1626149473116;  Mon, 12 Jul 2021 21:11:13 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id e30sm620701pga.63.2021.07.12.21.11.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 21:11:12 -0700 (PDT)
To: Bob Hinden 
Cc: Michael StJohns , rfced-future@iab.org
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com>
From: Brian E Carpenter 
Message-ID: <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>
Date: Tue, 13 Jul 2021 16:11:08 +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: <02994423-D9CB-4996-B831-E87900EC9250@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 04:11:20 -0000

Could we compromise on "RFC Series Advisory Editor"?

The term is used quite widely and it even seems accurate.

Regards
   Brian Carpenter

On 13-Jul-21 16:00, Bob Hinden wrote:
> Brian,
>=20
>> On Jul 12, 2021, at 7:52 PM, Brian E Carpenter  wrote:
>>
>> I don't think there is any proposal to retire the term "RFC Editor".
>> But for many years it has referred to the function as well as to
>> the figurehead. RFC2850 refers to "an organization to act as
>> RFC Editor" because even in May 2000 it wasn't a person, although
>> Bob Braden led the team. And also "The Internet Society, the RFC Edito=
r,
>> the IANA and the IESG each appoints a liaison member to the IAB."
>>
>> Given the job description and role of the RSEA, I really don't see
>> how we can call the person an editor.
>=20
> Think about it like positions in the US called =E2=80=9CSecretary of St=
ate=E2=80=9D, see:
>=20
> https://www.state.gov/secretary/
>=20
> They are not performing secretarial duties.
>=20
> Bob
>=20
>=20
>>
>> Regards
>>   Brian Carpenter
>>
>> On 13-Jul-21 05:20, Michael StJohns wrote:
>>> Bob said it better than I can.   Mike
>>>
>>> On 7/12/2021 12:58 PM, Bob Hinden wrote:
>>>> Hi,
>>>>
>>>>> On Jul 9, 2021, at 2:03 PM, Peter Saint-Andre =20
wrote:
>>>>>
>>>>> The role played by the technical publishing expert in version 3 of =
the
>>>>> model is different enough from past roles that I suggest we should =
not
>>>>> use the name "RFC Series Editor" but instead "RFC Series Advisor=E2=
=80=9D.
>>>> I strongly disagree.
>>>>
>>>> The RFC Editor role has changed multiple times in the past in many w=
ays and we still call it the RFC Editor.
>>>>
>>>> This includes:
>>>>
>>>> Administrative support and direction changed from Defense Advanced P=
roject Agency (DARPA), the Internet Society, IAOC, and currently the IETF=20
LLC.
>>>>
>>>> It has been performed by Jon Postel, Bob Braden, Joyce Reynolds, Gle=
nn
>> Kowack, Olaf Kolkman, and Heather Flanagan.
>>>>
>>>> Actual editing has transitioned from an individual to a contracted c=
ompany.
>>>>
>>>> The scope and the context of this position has changed as the admini=
stration and the person doing the job changed.   It has great name recogn=
ition.   I don=E2=80=99t see any reason why what we are defining now can =
not be called the RFC Editor.   Changing it the =E2=80=9CRFC Series Advis=
or=E2=80=9D will cause considerable confusion in the larger community.
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>=20


From nobody Mon Jul 12 21:30:12 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578AF3A1306 for ; Mon, 12 Jul 2021 21:30:11 -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=nthpermutation-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 zlJdsM81MAUs for ; Mon, 12 Jul 2021 21:30:06 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 07BA53A1301 for ; Mon, 12 Jul 2021 21:30:05 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id a6so27953111ljq.3 for ; Mon, 12 Jul 2021 21:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tcEiRc9VZxeCGwuMpHdKd6BUNUuJOsyQW4WYbYRFeFk=; b=i1sSASGiJ5AMuVWIcLHJheM8QTA8hbLnoJ/KXjSp6YX+wZ6fNupNan+KERlii7EQsi siPNXlRImMmuE/MWs0xeLue75NuYjPtbQP7mDWO2xGpWBGPTbn07UvOQaRg0SYYaTneq rveHVB37GbnWU4MXsnpJUlGEiDD4dQCHVuV2klE9v0BUCDuAZ88v/7DvMVvFgOBYh6l/ dLS6/Z9NNWDv9P9TiMI1kh0PYpMBwM6ZR5n7fuBGouTNmIkhknNwfyiE9uLSIEAj6TnP 9oJOIVlUuv2WvXPn8/rOiNpyLg/ApX9KiN9iOsBt6fLWFNTf5Ry0FrptOyEA4e+zVgo4 vL8A==
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=tcEiRc9VZxeCGwuMpHdKd6BUNUuJOsyQW4WYbYRFeFk=; b=q7/YpBaDdcKOxgJ6LD93WDgQcwyhjv13oGTiOMP21TrWNNclYcjc8+xrryVSZje6BE y/4GCOz/M7M3DskhuUgnIDF545GM9SoIm/6JV0SYTigPo3cUsl9UYY5s83RD9ESgFBxe CCteQWYl8jnaLjJfxgPUn35H1+0uhxHHRy5nI2++2+NAFW7YXdXyrE6Jd3NzxdZxZJxM lgyMZ27wCTmCA6QKP1TVuyeu7pvUd1gASRdIJNhKPxO1zM9Z+Y38VaQnTVYgWnERGj2j lMwa3H9q9FiubWY0+RoUor+SMk7mLvw6L7yGc2VR3rhRoAHvqBNrnbyM1DBhlairTRKS 0paQ==
X-Gm-Message-State: AOAM531L9/rLHs+4xhc1mwHTTpKpeALIoFsXodxHK4/fO64wkbPnyyxk AS4IA6U9AzZwjr9Imkknk0YW2CDqAApFekeyOOY1cg==
X-Google-Smtp-Source: ABdhPJwZ/Qs2jpyO4nmrG8h21AirtqdqY5rsEyf1XmGr9D+KzhmRgfccEHvkHJdZUA/iU4aIWkP+KqKbnc4iB6KMy9k=
X-Received: by 2002:a05:651c:543:: with SMTP id q3mr2362396ljp.432.1626150602383;  Mon, 12 Jul 2021 21:30:02 -0700 (PDT)
MIME-Version: 1.0
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>
In-Reply-To: <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>
From: "StJohns, Michael" 
Date: Tue, 13 Jul 2021 00:29:51 -0400
Message-ID: 
To: Brian E Carpenter 
Cc: Bob Hinden , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="00000000000001b3fa05c6f9b19f"
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 04:30:11 -0000

--00000000000001b3fa05c6f9b19f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't think so.  I=E2=80=99m not even sure we could get anyone to apply f=
or
something with that job title.  Mike

On Tue, Jul 13, 2021 at 00:11 Brian E Carpenter 
wrote:

> Could we compromise on "RFC Series Advisory Editor"?
>
> The term is used quite widely and it even seems accurate.
>
> Regards
>    Brian Carpenter
>
> On 13-Jul-21 16:00, Bob Hinden wrote:
> > Brian,
> >
> >> On Jul 12, 2021, at 7:52 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> >>
> >> I don't think there is any proposal to retire the term "RFC Editor".
> >> But for many years it has referred to the function as well as to
> >> the figurehead. RFC2850 refers to "an organization to act as
> >> RFC Editor" because even in May 2000 it wasn't a person, although
> >> Bob Braden led the team. And also "The Internet Society, the RFC Edito=
r,
> >> the IANA and the IESG each appoints a liaison member to the IAB."
> >>
> >> Given the job description and role of the RSEA, I really don't see
> >> how we can call the person an editor.
> >
> > Think about it like positions in the US called =E2=80=9CSecretary of St=
ate=E2=80=9D, see:
> >
> > https://www.state.gov/secretary/
> >
> > They are not performing secretarial duties.
> >
> > Bob
> >
> >
> >>
> >> Regards
> >>   Brian Carpenter
> >>
> >> On 13-Jul-21 05:20, Michael StJohns wrote:
> >>> Bob said it better than I can.   Mike
> >>>
> >>> On 7/12/2021 12:58 PM, Bob Hinden wrote:
> >>>> Hi,
> >>>>
> >>>>> On Jul 9, 2021, at 2:03 PM, Peter Saint-Andre 
> wrote:
> >>>>>
> >>>>> The role played by the technical publishing expert in version 3 of
> the
> >>>>> model is different enough from past roles that I suggest we should
> not
> >>>>> use the name "RFC Series Editor" but instead "RFC Series Advisor=E2=
=80=9D.
> >>>> I strongly disagree.
> >>>>
> >>>> The RFC Editor role has changed multiple times in the past in many
> ways and we still call it the RFC Editor.
> >>>>
> >>>> This includes:
> >>>>
> >>>> Administrative support and direction changed from Defense Advanced
> Project Agency (DARPA), the Internet Society, IAOC, and currently the IET=
F
> LLC.
> >>>>
> >>>> It has been performed by Jon Postel, Bob Braden, Joyce Reynolds, Gle=
nn
> >> Kowack, Olaf Kolkman, and Heather Flanagan.
> >>>>
> >>>> Actual editing has transitioned from an individual to a contracted
> company.
> >>>>
> >>>> The scope and the context of this position has changed as the
> administration and the person doing the job changed.   It has great name
> recognition.   I don=E2=80=99t see any reason why what we are defining no=
w can not
> be called the RFC Editor.   Changing it the =E2=80=9CRFC Series Advisor=
=E2=80=9D will cause
> considerable confusion in the larger community.
> >>>>
> >>>> Bob
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >> --
> >> Rfced-future mailing list
> >> Rfced-future@iab.org
> >> https://www.iab.org/mailman/listinfo/rfced-future
> >
>
>

--00000000000001b3fa05c6f9b19f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I don't think so.=C2=A0 I=E2=80=99m not even sure we =
could get anyone to apply for something with that job title.=C2=A0 Mike

On Tue, Jul 13, 2021 at 00:11 Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Could we compromise on "RFC Series Ad=
visory Editor"?



The term is used quite widely and it even seems accurate.



Regards

=C2=A0 =C2=A0Brian Carpenter



On 13-Jul-21 16:00, Bob Hinden wrote:

> Brian,

> 

>> On Jul 12, 2021, at 7:52 PM, Brian E Carpenter <brian.e.carpenter@gmail.c=
om> wrote:

>>

>> I don't think there is any proposal to retire the term "R=
FC Editor".

>> But for many years it has referred to the function as well as to
>> the figurehead. RFC2850 refers to "an organization to act as<=
br>
>> RFC Editor" because even in May 2000 it wasn't a person, =
although

>> Bob Braden led the team. And also "The Internet Society, the =
RFC Editor,

>> the IANA and the IESG each appoints a liaison member to the IAB.&q=
uot;

>>

>> Given the job description and role of the RSEA, I really don't=
 see

>> how we can call the person an editor.

> 

> Think about it like positions in the US called =E2=80=9CSecretary of S=
tate=E2=80=9D, see:

> 

> https://www.state.gov/secretary/

> 

> They are not performing secretarial duties.

> 

> Bob

> 

> 

>>

>> Regards

>>=C2=A0 =C2=A0Brian Carpenter

>>

>> On 13-Jul-21 05:20, Michael StJohns wrote:

>>> Bob said it better than I can.=C2=A0 =C2=A0Mike

>>>

>>> On 7/12/2021 12:58 PM, Bob Hinden wrote:

>>>> Hi,

>>>>

>>>>> On Jul 9, 2021, at 2:03 PM, Peter Saint-Andre <stpeter@mozilla.com> 

wrote:

>>>>>

>>>>> The role played by the technical publishing expert in =
version 3 of the

>>>>> model is different enough from past roles that I sugge=
st we should not

>>>>> use the name "RFC Series Editor" but instead=
 "RFC Series Advisor=E2=80=9D.

>>>> I strongly disagree.

>>>>

>>>> The RFC Editor role has changed multiple times in the past=
 in many ways and we still call it the RFC Editor.

>>>>

>>>> This includes:

>>>>

>>>> Administrative support and direction changed from Defense =
Advanced Project Agency (DARPA), the Internet Society, IAOC, and currently =
the IETF 

LLC.

>>>>

>>>> It has been performed by Jon Postel, Bob Braden, Joyce Rey=
nolds, Glenn

>> Kowack, Olaf Kolkman, and Heather Flanagan.

>>>>

>>>> Actual editing has transitioned from an individual to a co=
ntracted company.

>>>>

>>>> The scope and the context of this position has changed as =
the administration and the person doing the job changed.=C2=A0 =C2=A0It has=
 great name recognition.=C2=A0 =C2=A0I don=E2=80=99t see any reason why wha=
t we are defining now can not be called the RFC Editor.=C2=A0 =C2=A0Changin=
g it the =E2=80=9CRFC Series Advisor=E2=80=9D will cause considerable confu=
sion in the larger community.

>>>>

>>>> Bob

>>>>

>>>>

>>>>

>>>

>>>

>>

>> --

>> Rfced-future mailing list

>> Rfced-fu=
ture@iab.org

>> https://www.iab.org/mailman/listinfo/rfce=
d-future

> 






--00000000000001b3fa05c6f9b19f--


From nobody Mon Jul 12 21:55:43 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D8E3A1413 for ; Mon, 12 Jul 2021 21:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.08
X-Spam-Level: 
X-Spam-Status: No, score=-2.08 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0I7l3EDdgdx for ; Mon, 12 Jul 2021 21:55:36 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4053B3A1410 for ; Mon, 12 Jul 2021 21:55:36 -0700 (PDT)
Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16D4tVIc090630 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 12 Jul 2021 23:55:32 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1626152132; bh=cBq/Ggkym/3C+WOFyrcf6oE6bRC3aHdQgG34nqAHIOY=; h=Subject:To:References:From:Date:In-Reply-To; b=NMYrykXyPIGzgqmS+FyyUUzLh1rAGPzY4Bvj4OO/T24yfKHaml8m3mjhgwXtb1MOe TY7ANQCzSOI1xfQAwBzHQwmoqcl4l5/uJ0p/Op2PbvfOxltnIvOlDkF0/D63gUQ85V MRFhX402iEHu2Ej1vezKJ3rxtBP9OcT03Zb2oEp4=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48]
To: rfced-future@iab.org
References:  
From: Adam Roach 
Message-ID: <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com>
Date: Mon, 12 Jul 2021 23:55:25 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 04:55:41 -0000

On 7/12/2021 11:58 AM, Bob Hinden wrote:
> Changing it the “RFC Series Advisor” will cause considerable confusion in the larger community.


On the contrary, I believe it will clear up a long-running and 
frequently harmful source of major confusion in at least the IETF 
community. There have been a large number of conversations in which it 
became clear that seasoned IETF participants who are otherwise quite 
knowledgeable about the RFC publication process clearly believed that 
Heather actually edited documents.

I don't have a position either way on whether "RSA" is the right term, 
but it's something I'm happy to live with. What I *do* know is that 
"Editor" has caused significant confusion in the past, and there's every 
reason to believe that it will cause significant confusion in the 
future. Replace it with something else.

/a


From nobody Tue Jul 13 01:58:42 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC433A0D7B for ; Tue, 13 Jul 2021 01:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mswYONJwsIjX for ; Tue, 13 Jul 2021 01:58:36 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 BF4DA3A0D78 for ; Tue, 13 Jul 2021 01:58:35 -0700 (PDT)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16D8wWe3001780; Tue, 13 Jul 2021 09:58:32 +0100
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 14E824604D; Tue, 13 Jul 2021 09:58:32 +0100 (BST)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 12D844604C; Tue, 13 Jul 2021 09:58:32 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs4.iomartmail.com (Postfix) with ESMTPS; Tue, 13 Jul 2021 09:58:32 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.103.107]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16D8wU8s015627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Jul 2021 09:58:31 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Peter Saint-Andre'" 
Cc: 
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com> <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk> 
In-Reply-To: 
Date: Tue, 13 Jul 2021 09:58:30 +0100
Organization: Old Dog Consulting
Message-ID: <00b501d777c5$417ad2b0$c4707810$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJYLqiQ/XeTdq1mmedVrtykX7nyGwI9AqC2AbAelv8BWB++mAGhkz6xAYlQOM+p+6jz0A==
Content-Language: en-gb
X-Originating-IP: 84.93.103.107
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26278.006
X-TM-AS-Result: No-0.033-10.0-31-10
X-imss-scan-details: No-0.033-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26278.006
X-TMASE-Result: 10-0.032900-10.000000
X-TMASE-MatchedRID: X4bcv0S75KnkQwDXuLnCoXFPUrVDm6jtt3aeg7g/usAgUEQTkIWiYrV9 VngM+vu8kByLlkkN36piWM9atbL23n1TTJmcLa3p+ACG5oWJ7tI7GNv1BBu35LobGHR5ejtrZYD o1TV938SitiouylJVoLNGDIYItVFmcKE8cHrXBCPN+qWlu2ZxaMd8fl5yHAjEmXw0RNbqkoIACh 5alwhWMseor7GM3ISUM3GJRvA/vwm29CW3ILLb8gBIKk3OC0uET5ysQDj6eFkYci5tX6N1/VJJg lOwAe6H70XlCYi9UKdA+p2C4UOMacdOzEf7OUPk2os3ueKAsFQBqNb4Qv6VowJRjXQLiyc9ethZ eskUR64Equ49IC+1EgWgef1C0L+e2DRLgpZEiUYMcSDq2FtE7E1+gA26WB/Ri2QFaYS1v20qtq5 d3cxkNZN5Fxj/DdmeltoV4uGkeNXYh5NMsFVWB27DKtPeggD7G7eCNxocC4zCEosOifX4ZLjMc9 ZgJhVSt6h06gCavO//IHDzSOv1ifBfwGvvhZjPp8i26iGCN+fD/c2Y8mxrik1Z+dSdugwvQbnlF uFUfWjvdCUIFuasqw==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 08:58:40 -0000

>> I *still* don't object to this, but (just so you know) you haven't
>> convinced me this isn't odd.
>
> It's my job here to (try to) capture the sense of the discussions and,
> once we have it, rough consensus.

Sure, sure. Not directly blaming you for the (non)sense of the =
discussion =F0=9F=98=8A

> AIUI, the argument is that whoever is
> on the RSAB needs to be chosen more directly by the community than a
> random appointee might be.

Well, erm, "random" might be prejudicial in this discussion since, I =
believe no suggestion of randomness was made. I think the question is =
whether the stream head is able to make a free choice of delegate or =
must be confined to a specific pool.

As I read the suggestion:
- The head of the IETF stream may delegate to another AD
- The head of the IAB stream may delegate to another NomCom-appointed =
IAB member
- The heads of the IRTF and IS streams may not delegate

I don't understand these constraints.

Compare with a recent email calling for an IETF Delegate to the ICANN =
2022 Nominating Committee [1]. There is no requirement that that =
volunteer (appointed by the IAB) should be drawn from the IAB. Yet the =
IAB is clearly responsible for their actions.

> I am not completely sure that this makes a great difference in the end
> because a random appointee can be recalled just as easily as an AD, or
> perhaps more so. In this specific case, we might ask the IESG if they =
have
> a preference.

Certainly, asking the IESG (and the IAB) would give us another data =
point.

But did I miss someone giving the reason behind the suggestion to =
constrain the delegation pool?

Cheers,
Adrian

[1] =
https://mailarchive.ietf.org/arch/msg/ietf-announce/o-q6AfhJmXAqulmuR-As4=
alE_wM/


From nobody Tue Jul 13 02:06:27 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED023A0DE1 for ; Tue, 13 Jul 2021 02:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCQoyf7oE7LK for ; Tue, 13 Jul 2021 02:06:23 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154273A0DE0 for ; Tue, 13 Jul 2021 02:06:23 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GPF9m71RNz2xJ4; Tue, 13 Jul 2021 11:06:20 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann 
In-Reply-To: 
Date: Tue, 13 Jul 2021 11:06:20 +0200
Cc: Peter Saint-Andre , Bob Hinden 
X-Mao-Original-Outgoing-Id: 647859980.523916-15fe2b982c8a3b023cc8cfb291555c97
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EE95252-EF36-40CB-A2A6-314A888D7AAA@tzi.org>
References:  
To: "rfced-future@iab.org" 
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 09:06:26 -0000

> The scope and the context of this position has changed as the =
administration and the person doing the job changed.   It has great name =
recognition.   I don=E2=80=99t see any reason why what we are defining =
now can not be called the RFC Editor.   Changing it the =E2=80=9CRFC =
Series Advisor=E2=80=9D will cause considerable confusion in the larger =
community.

+1

Re Adam=E2=80=99s concern about the term =E2=80=9Ceditor=E2=80=9D: I =
don=E2=80=99t think we can treat the symptom of people not understanding =
the publishing process by inventing ever longer, ever more confusing =
terms.

My institute is called =E2=80=9CCenter for Computing and Communications =
Technologies=E2=80=9D (TZI in German).  Center?   What is that supposed =
to be?
Of course, =E2=80=9CCenter=E2=80=9D has been the go-to name for =
organizations where nobody quite knows (or wants to say) what they =
actually do.
Let=E2=80=99s not ride the trend of meaningless words.

(Well, I do know what my tax advisor does, and I sure don=E2=80=99t want =
the RSE to be seen as the equivalent of *that*.)

Gr=C3=BC=C3=9Fe, Carsten


From nobody Tue Jul 13 02:08:09 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7673A0DFC for ; Tue, 13 Jul 2021 02:08:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SGyGGDfKZJCI for ; Tue, 13 Jul 2021 02:08:05 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (pop.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56BD43A0DFA for ; Tue, 13 Jul 2021 02:08:04 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GPFCk0d68z2xJ4; Tue, 13 Jul 2021 11:08:02 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann 
In-Reply-To: <6EE95252-EF36-40CB-A2A6-314A888D7AAA@tzi.org>
Date: Tue, 13 Jul 2021 11:08:01 +0200
Cc: Bob Hinden , Peter Saint-Andre 
X-Mao-Original-Outgoing-Id: 647860081.62233-befc24fd592c3ec74de5df9b64b26982
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <6EE95252-EF36-40CB-A2A6-314A888D7AAA@tzi.org>
To: "rfced-future@iab.org" 
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 09:08:09 -0000

On 2021-07-13, at 11:06, Carsten Bormann  wrote:
>=20
> Center

(Oops, I forgot about the RPC :-)

Gr=C3=BC=C3=9Fe, Carsten


From nobody Tue Jul 13 04:20:15 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C038F3A1463 for ; Tue, 13 Jul 2021 04:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqFKnRrSIMqU for ; Tue, 13 Jul 2021 04:20:09 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30126.outbound.protection.outlook.com [40.107.3.126]) (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 A82843A145F for ; Tue, 13 Jul 2021 04:20:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fUOH8iJQ/r5vvP270I0zd4Mtw1B1YhE5Ws3TAQiKHNGidXa7V0/YALO+oCN9U/+MbLlMXgIP+Lnsqs5/X5Eq8zSQF8/bAHOy1D36bsRJOitVThuMeDKhgVYz6xV+ylbZrJpyIT5aqq3hlL9H602jlQ0Oay22k7rSD6fBBBYP6VytVZH4t0nfsRT9k4pxW+saSdlUEj2MQUymFciDvzGx4cJjnYH+VPVf1JkCB8EZWrJvaZKTwoaJLIDjStRq7V9KtjlQeEObRzKK45AggNGPmBCQqVhmrq7biwpMWpVchvmTRzKjtX+HFwMms7KG4NcCicPrYk2LLC35rm6zULLh6Q==
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=hJO+deDqyjItxOqLNhDC4BZluCENsViTbiAYDPPWXSo=; b=aA+pGwioDxoAuPRlS6N+brxiro1YvqcQhr4pkjAq1pxaco9c2SUcY5vi+B6buiTW2Bce3wTI75l9OJh3JgZ8JN/J/rHO6cxnrYRv6eBkT28I6af0oWTLWyhCeHkLvAVX1q2svC4JqbYNQkuHyI5VUVbE4bRRcR4YPrRONzogq7DkkW0e3FMe+pwiA5FUwtzBDtnAa6dhWtUIKUkl5GMEQ6nG6AGbe50ez9FGIgv2oip2gHg/oSU4EWmX4aL6P76RccHLB4ok6xCc50dbkQ5UgZSlSyyX6twRz6UiSWv4gStRQmENAz9ZS/jL4U0gi0VwtrIfweE8NH+gByvGusCL0g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hJO+deDqyjItxOqLNhDC4BZluCENsViTbiAYDPPWXSo=; b=KToGsidvVwZmy3wO+qsFYVF+i49nqEo/5QnNiZImCtngq0ChQyRWAxeFqGu26A5Lc4oi0dgwF4q7LMQavmW8tXxfHdRf2zKHd45d+HiBgHUziE4jE4mqxMdwxT/QPbhT9KoJ7G9O+1Hwi2xS3CEH6d86SPmusPgx9wvMbUlMmNQXlQ4aUD0zdvlPjj/GqYhVDNaMIODBmm7/1D+btXcIsVUaeSyTU7HtE+uC97zp2o6KW7DqFyFUIgEFSEdOOgIs435Ein3ABXFagFKT21IPcgWAXAAFUUOKV79FLqBgk7i75UfwSGllUN/H5Astbcx77kMzCOcdGqlHdAyA/MTfpw==
Authentication-Results: mozilla.com; dkim=none (message not signed) header.d=none;mozilla.com; dmarc=none action=none header.from=cs.tcd.ie;
Received: from AM6PR02MB5112.eurprd02.prod.outlook.com (2603:10a6:20b:90::21) by AM6PR02MB4389.eurprd02.prod.outlook.com (2603:10a6:20b:3e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.23; Tue, 13 Jul 2021 11:20:01 +0000
Received: from AM6PR02MB5112.eurprd02.prod.outlook.com ([fe80::c0d5:2359:eae3:f5d4]) by AM6PR02MB5112.eurprd02.prod.outlook.com ([fe80::c0d5:2359:eae3:f5d4%7]) with mapi id 15.20.4287.033; Tue, 13 Jul 2021 11:20:01 +0000
To: Carsten Bormann , "rfced-future@iab.org" 
Cc: Bob Hinden , Peter Saint-Andre 
References:   <6EE95252-EF36-40CB-A2A6-314A888D7AAA@tzi.org>
From: Stephen Farrell 
Message-ID: <7764f25d-d353-3dd1-3f0c-4d10bb07a37c@cs.tcd.ie>
Date: Tue, 13 Jul 2021 12:19:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
In-Reply-To: <6EE95252-EF36-40CB-A2A6-314A888D7AAA@tzi.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0NBLOGTnrRn054yWdD63Vx8KyyVogIBI4"
X-ClientProxiedBy: DU2P250CA0024.EURP250.PROD.OUTLOOK.COM (2603:10a6:10:231::29) To AM6PR02MB5112.eurprd02.prod.outlook.com (2603:10a6:20b:90::21)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [IPv6:2001:bb6:5e5e:b458:29bf:eb6:1a5c:c28] (2001:bb6:5e5e:b458:29bf:eb6:1a5c:c28) by DU2P250CA0024.EURP250.PROD.OUTLOOK.COM (2603:10a6:10:231::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.19 via Frontend Transport; Tue, 13 Jul 2021 11:20:00 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 482cbe28-e6c4-462b-9701-08d945f027dc
X-MS-TrafficTypeDiagnostic: AM6PR02MB4389:
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-Microsoft-Antispam-PRVS: 
X-TCD-Routed-via-EOP: Routed via EOP
X-TCD-ROUTED: Passed-Transport-Routing-Rules
X-MS-Oob-TLC-OOBClassifiers: OLM:1360;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: HJY9Revo61hIwOggisOSbwAfwlrGtvXnrsJh2IYz34LAXpruFptgXYkaYQCllcs7aE2V0wVjCGYPzZABuMZp6/sTwmUBb/bFMfaxP3UaKL1BTRG0lFCAD3zyxzqjP+AHWxY9Gs8kOh2QAT5OJLEvSYVMa4qkFPlSSfmf40jmEkxonEw3vi8RVvd585Seb6XY2MKRfMc89kFsonoM1Vn8rcfL60GgVR4vpSzbJ4HGe8G4bhdS3SwilASRi+KyTss2JH/i++X6ilEdrQ8co56QTe+A0YdcF4IkvLD2uHaXt75KsLuxb164wi8Pajfbl5SlyZHTg4kRaOxry99PvdnIMroVroa9XSFJHVEKqVtRaclAsVZz46ciJqgochzOEi+mJSXQwjgSYjrFzG/uyS/W+X3VkQf40Y/R+x5UZmm7mxgX6rw7QT1YOaMNXZ4D0sfjVNM6PSZTXSitu3gT6rrrOgXrq55+1WHX8v+luzZ6iqPeUPuCfxTpphuJ06NbNjKoAJNVtRm3B/I0UwcSL22GPuTBuoxxuKHITuXOQdZ8h85RUWfw8Y9jiCi+7rHECSrdUxSfvGg4bd5N+EMYZzRBgCCsr4tn0dLw6AQIuTXRJ0thFxmX7PKB5JJImDzxBAz1oSD5DspqPJbwmAZ6crHXb6BOGHMvfX3e+7q0FNFW5Y7YN0so7QS8BH7GYI6squBDiOofuwxPkpTth+9BAprU1Vfm/uiKOog75w+2XhMWKeg=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM6PR02MB5112.eurprd02.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(39860400002)(346002)(376002)(136003)(396003)(366004)(53546011)(110136005)(235185007)(316002)(786003)(36756003)(8676002)(2616005)(31686004)(21480400003)(4326008)(33964004)(8936002)(83380400001)(86362001)(5660300002)(6486002)(2906002)(54906003)(478600001)(31696002)(44832011)(66476007)(66556008)(186003)(38100700002)(6666004)(66946007)(66616009)(45980500001)(43740500002); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T2VOT0gyYmc4eCtOcG5mSmxLUldWeldNbWpEaXRXcTdkRHBCd2FqbGVWQWRE?= =?utf-8?B?eGRpc0tDK2UwVlZOU2RLaFpkaTh5bjlkRnIxcERHdk1sUS8zV1BLVnBlNGpl?= =?utf-8?B?akVqelZKampQUisxR0ZvVi92SUdVOFE2SXdkZ2RPUE1ZNkVSeUZIT0VqNC9S?= =?utf-8?B?VmlaQ3ArZjlvTkdJNlhIeU83Z3B1bVRHNU5yRWlKQ1FpV1pFK3h2QkRyOHA3?= =?utf-8?B?QTlpU1E4TmZnWVZ0YUZRQ0o1K3BvaGZhUTZLclA1bUxPN2pEdVhLV3FLWmxl?= =?utf-8?B?ZHpnb3ZoRDlhdU5DNG9jenMwKzB6MXBscG9vRkhUN3FFbFdyRkdoR2pHUFli?= =?utf-8?B?Q1RFT2FPZ0hVOUtXNjBVMERBWmlBOVo1UGt3V2M4QTZYQmNOSmJXZXVUQ21h?= =?utf-8?B?eTk5aWMrbWE1OUlwbUwvOE9na3dyNWxjTzFWT2hBczlFQ05hVTVQaFFQRlNx?= =?utf-8?B?RW1XT01BMHRYYk5lNm1ENEkwVHVkQjRGU0I0aU1xWVhnSTdaUUM5RnNlVVYr?= =?utf-8?B?bGFMN1pEVFpxNkJKMExYOTVLWGdCeEppd0dVODd2N1NkS2tjZERGdmNqd2No?= =?utf-8?B?UUdINXFYaWIzT2xMeTBsdnFROWUxWXQrdExSekJadlJFN2NFdkE5a2RLRDVZ?= =?utf-8?B?UWRUK09RTDVRaWEyU0JWSnpzSy9mSlptMXZjUWRWbFJHaVRZZHc4QWsvdDRH?= =?utf-8?B?aUJqcWlkTnltS2JxNjVlQUFlRGhwV2lGai9CUVRKU0djZXVoa0lybllVdGVv?= =?utf-8?B?VFZ2djJ5V1owOFZhMy9KYXdrN3NKOEJ1MytZNUJpeXF6Vk1kcVFmeFZvdVRo?= =?utf-8?B?WTNLa1IxM0IvU01hSFJyUWU1OXVtYXhuZlR4NVhiS0RTbndiTXVxaDhRM1k1?= =?utf-8?B?Z1NxV0dZM2FsWS94aTc3REtvRjdFSm5FcGFNYzAyU21oRnNGY1NCR2ptM0VG?= =?utf-8?B?YkdERFdybDdHRVViOVZPME9ZQjNUVUp3NE1HcmFkZ29jY2lzNFF5S2xrQnVN?= =?utf-8?B?NmNPTUt0dXh3SFlPWkMreVFZL3dUMG4zN3A3aHQrY084d2MvUTN5TFR2Wmtl?= =?utf-8?B?K3dZMFFxT3pIQ0VCeXpjaUtKZU1SVEtobFd0ZmIyMlNMTGk0TzdINjFKbjQr?= =?utf-8?B?VHUvVWoySVJLeEJhTVJpbTU2OGFrajBUYzJnNWo4RGY0ZXgyN3NYcG9weHN3?= =?utf-8?B?UmsxTkkyMXVWNXF2UHhnb3psTklqeC90S09KYk9KMHpkWjhvcmNhclduT0cr?= =?utf-8?B?WlQzZ3hDTWVEY25oZnhuT09JbUhXN0xwU2dEYi9WeFJlMmdQVmZ4UEFBekVw?= =?utf-8?B?NEl6MzFFSzg5YmdqUVJkL0liTDBmTHdsdkorcGQzMVlFWDZTYm40MkFUekVK?= =?utf-8?B?S1NnTWNkSGdteU9jSmdwMDUvTDJLUjhkdHhxMzFtWGpDUS9PK0VINjVrOVQ0?= =?utf-8?B?MlZhVGhxbzdOc1pNNFdEMzZSbVlONFJ1dE96UmpKK1JNbk83SXhoZGJFcUxT?= =?utf-8?B?TFZRZWhLMm1hbnpqMkpxL0tsNkl1YWVnNmZpWkxnamhFQmN4Y2o5b3ZMU2FR?= =?utf-8?B?djU3dGJCOEE2MzZyUVB5RFQ3RzB0YmlNYWhLVTlUeEtKMW81bU5xQk94N2tB?= =?utf-8?B?TStWU2pNbXZOSlFyQTBTM2tZQTl5MWsvZHVRTU84d1lmeVQ0USttckJPRERw?= =?utf-8?B?NldlT1FHZFk3eDhGd3hMN1hDbEM5aFNLMFpYZHNackFWSW1KUkllZ0JNa0t2?= =?utf-8?B?R0JWTW9DekJFMk0rVklTS200SDhzd2YwTGd0cDFhNTdRQ05rb0pmVktBZE5u?= =?utf-8?B?b2tUNE9ZcGtVZWd5UXRGUVJOeFJFNjBaeHVTbXk5Y0lKaStKUHNyaWMrbSty?= =?utf-8?Q?Al0bF6/IOq6Nc?=
X-OriginatorOrg: cs.tcd.ie
X-MS-Exchange-CrossTenant-Network-Message-Id: 482cbe28-e6c4-462b-9701-08d945f027dc
X-MS-Exchange-CrossTenant-AuthSource: AM6PR02MB5112.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jul 2021 11:20:01.4330 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: XjGko64sVRRMMTfHS/A93L1TY/saj8efgSxF6Jn0L5NoqhBkV/XHx8px9Ck+KpSi
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR02MB4389
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 11:20:14 -0000

--0NBLOGTnrRn054yWdD63Vx8KyyVogIBI4
Content-Type: multipart/mixed; boundary="gJYRiBfG9ff58C0j9ySOY9upkdKaAKgud";
 protected-headers="v1"
From: Stephen Farrell 
To: Carsten Bormann ,
 "rfced-future@iab.org" 
Cc: Bob Hinden , Peter Saint-Andre 
Message-ID: <7764f25d-d353-3dd1-3f0c-4d10bb07a37c@cs.tcd.ie>
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
References: 
 
 <6EE95252-EF36-40CB-A2A6-314A888D7AAA@tzi.org>
In-Reply-To: <6EE95252-EF36-40CB-A2A6-314A888D7AAA@tzi.org>

--gJYRiBfG9ff58C0j9ySOY9upkdKaAKgud
Content-Type: multipart/mixed;
 boundary="------------12E7794020A04275DE104CE5"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------12E7794020A04275DE104CE5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable



On 13/07/2021 10:06, Carsten Bormann wrote:
>> The scope and the context of this position has changed as the administ=
ration and the person doing the job changed.   It has great name recognit=
ion.   I don=E2=80=99t see any reason why what we are defining now can no=
t be called the RFC Editor.   Changing it the =E2=80=9CRFC Series Advisor=
=E2=80=9D will cause considerable confusion in the larger community.
> +1

Same here.

S

--------------12E7794020A04275DE104CE5
Content-Type: application/pgp-keys;
 name="OpenPGP_0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Description: OpenPGP public key
Content-Disposition: attachment;
 filename="OpenPGP_0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5=
Cg8
gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq=
978
CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu=
D/Q
9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4=
tNn
cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB=
wV+
4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir=
1GC
YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav=
ACY
Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D=
VQu
8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER=
8la
5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE=
wEI
ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC=
xAA
pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX=
Az9
+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL=
F+X
+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4=
g1U
QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre=
k3U
P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2=
niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL=
4Nw
tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m=
6vt
ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7=
+8A
CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ=
LvC
wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8=
rpK
o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr=
qJs
CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa=
W/r
KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG=
gMW
rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u=
rqR
1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/=
0A9
J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc=
JBD
EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4=
vrp
2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA=
xvK
dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK=
xlf
tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg=
Uky
o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO=
aHv
X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp=
yyz
JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ=
uLE
FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w=
sDc
BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer=
3UM
TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP=
jt5
uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK=
171
RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR=
Lpg
RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov=
wza
tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0=
zG3
6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ=
eah
r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ=
GNz
LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o=
3cC
GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo=
w5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h=
Rcs
RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC=
Y98
iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd=
h2k
4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4=
EIk
CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ=
DIJ
pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4=
tvy
a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4=
ul3
qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc=
G9g
ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt=
w/r
1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ=
Jaf
3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1=
4Q0
7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf=
qtu
Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C=
gHw
26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC=
wIE
FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL=
rfb
e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF=
etu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8=
v39
+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr=
1oD
3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr=
m2D
Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby=
y/A
UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO=
jao
P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz=
leL
Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC=
2X4
pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g=
1MS
BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34=
YT0
auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb=
edD
Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3=
1qG
/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV=
YW6
R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg=
4Im
VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm=
qyH
eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx=
qnk
SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ=
Esc
YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n=
2Hw
xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F=
eIY
jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E=
AuF
CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4=
2AY
R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH=
X5v
aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q=
Csw
Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq=
yA4
3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m=
Eer
0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI=
Dxz
dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC=
QgH
AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ=
i0B
igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn=
i9g
OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy=
sIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n=
66v
xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/=
3r2
BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM=
YtU
N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr=
5iW
XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/=
zek
ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b=
a0H
Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP=
Ic2
gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6=
XE6
i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1=
16u
/HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J=
G9a
SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW=
OMq
N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz=
0YO
K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4=
vYl
zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx=
nNb
KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+=
5HN
HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq=
4hn
l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn=
Zbg
JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d=
nJj
j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8=
WLI
aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc=
dPC
Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX=
o4+
Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO=
Tyk
rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9=
hZM
0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5=
P3f
WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp=
cL2
lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk=
etP
GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3=
zRq
k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0=
20q
pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U=
DIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x=
/nL
PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE=
hOV
fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D=
VI9
DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT=
uW/
eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD=
aWT
3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6=
1df
mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8=
MAv
2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA=
HZR
5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo=
qj1
gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6=
Mas
qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi=
RkM
dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB=
++/
KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX=
xMD
rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf=
ZtA
ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN=
2OE
0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT=
zcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7=
IKP
3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW=
Iys
s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3D40Nd
-----END PGP PUBLIC KEY BLOCK-----

--------------12E7794020A04275DE104CE5--

--gJYRiBfG9ff58C0j9ySOY9upkdKaAKgud--

--0NBLOGTnrRn054yWdD63Vx8KyyVogIBI4
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmDtdt0FAwAAAAAACgkQWrL68XsXK+ob
uxAAthZ/JdPxDlPa2K3zVZA5pwNnzCglgdr/S8ey/6uah5poBRTN8Iqpj6oiLWpxfBwO0joOp+vd
pbNxVPfAkzXkI1JNLZ2Q4llIoPXmbDZwAmQpNmym2Vgjy9M4d1Hqt0SRmAABrCHbCKAXkeAviunv
Kpa2dMyTABwJ0RzlTOcxeaXQVz1aWdWwsGw6tXAjuHFrxFBc8bshRPi2A7GMEWWubWeaq6k9GHB8
ewOzbftsUq+F3Patg6cJ0e8a32crrWd3PruT2qtk/WPriKn6rY0fIexDGD1RO35F8fHMlOicqmvP
Zpguav3KTLftQwLpwIwb0SOCwaSM1SSVd2dTkWMO6M4QhyBI53huUJPCAz7jzbJ8B1wAzmsiswNw
FEVybslZ9lvir+mo04uSeyvYcOT5bj1DN5jJQv5S7lU8FS7tyNomC713SoYmHF+71pcw4n/Fp79v
5WzaUGGPrfsvL6J9FypEVP0e9+mLr1vJ3xCl1mJpnqpqxvWEMgl1IakrLQvU5fOkpRgvDbdyIR2F
N4UnT8zG9uYDu88x6wRAAaBxYW2rotdKImbalUyvWKhjc/YirDpWZ/ZXg9q4zQ9QLsVmtOREfF3P
EOw2USrwtbMJs8ZMyG0KzFc79rbQXgTrsnPdniSsMg4m1wB26SitbP2ZNtzORrsqWrVog+8BiZhY
S7E=
=KovC
-----END PGP SIGNATURE-----

--0NBLOGTnrRn054yWdD63Vx8KyyVogIBI4--


From nobody Tue Jul 13 06:41:07 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6463D3A0EC9 for ; Tue, 13 Jul 2021 06:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2AmonfSF2GZ for ; Tue, 13 Jul 2021 06:41:02 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF173A0EB8 for ; Tue, 13 Jul 2021 06:41:02 -0700 (PDT)
Received: from p200300dee70cfa0041f532c7c70c9597.dip0.t-ipconnect.de ([2003:de:e70c:fa00:41f5:32c7:c70c:9597]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1m3Ief-0007EU-BY; Tue, 13 Jul 2021 15:40:57 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Mirja Kuehlewind 
In-Reply-To: 
Date: Tue, 13 Jul 2021 15:40:56 +0200
Cc: Adrian Farrel , Eric Rescorla , Eliot Lear , rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com> <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk> 
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1626183662;63d008f8;
X-HE-SMSGID: 1m3Ief-0007EU-BY
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 13:41:06 -0000

I think it would be important for the appointee to be a member of the =
IESG or IAB respectively, mainly so that person knows what=E2=80=99s =
going on there. Similarly I think it would be hard for the IRTF chair or =
ISE to delegate to someone how is not involved in the processes there. =
However, the IRTF chair does involve the IRSG members more than it used =
to be the case, so leaving a bit of slack in the formulation to give =
them a choice in future is probably a good thing.



> On 13. Jul 2021, at 02:08, Peter Saint-Andre  =
wrote:
>=20
> On 7/11/21 7:30 AM, Adrian Farrel wrote:
>> I *still* don't object to this, but (just so you know) you haven't =
convinced me this isn't odd.
>=20
> It's my job here to (try to) capture the sense of the discussions and,
> once we have it, rough consensus. AIUI, the argument is that whoever =
is
> on the RSAB needs to be chosen more directly by the community than a
> random appointee might be. I am not completely sure that this makes a
> great difference in the end because a random appointee can be recalled
> just as easily as an AD, or perhaps more so. In this specific case, we
> might ask the IESG if they have a preference.
>=20
> Peter
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>=20


From nobody Tue Jul 13 06:43:34 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247743A0F09 for ; Tue, 13 Jul 2021 06:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVR0TxImpE_s for ; Tue, 13 Jul 2021 06:43:28 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDA73A0EF4 for ; Tue, 13 Jul 2021 06:43:28 -0700 (PDT)
Received: from p200300dee70cfa0041f532c7c70c9597.dip0.t-ipconnect.de ([2003:de:e70c:fa00:41f5:32c7:c70c:9597]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1m3Ih1-0001rx-5v; Tue, 13 Jul 2021 15:43:23 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Mirja Kuehlewind 
In-Reply-To: <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com>
Date: Tue, 13 Jul 2021 15:43:22 +0200
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net>
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1626183808;8dc570fb;
X-HE-SMSGID: 1m3Ih1-0001rx-5v
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 13:43:33 -0000

+1

> On 13. Jul 2021, at 06:55, Adam Roach  wrote:
>=20
> On 7/12/2021 11:58 AM, Bob Hinden wrote:
>> Changing it the =E2=80=9CRFC Series Advisor=E2=80=9D will cause =
considerable confusion in the larger community.
>=20
>=20
> On the contrary, I believe it will clear up a long-running and =
frequently harmful source of major confusion in at least the IETF =
community. There have been a large number of conversations in which it =
became clear that seasoned IETF participants who are otherwise quite =
knowledgeable about the RFC publication process clearly believed that =
Heather actually edited documents.
>=20
> I don't have a position either way on whether "RSA" is the right term, =
but it's something I'm happy to live with. What I *do* know is that =
"Editor" has caused significant confusion in the past, and there's every =
reason to believe that it will cause significant confusion in the =
future. Replace it with something else.
>=20
> /a
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future


From nobody Tue Jul 13 07:07:37 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C7F3A11D2 for ; Tue, 13 Jul 2021 07:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level: 
X-Spam-Status: No, score=-1.887 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZNqzR1EBkUR for ; Tue, 13 Jul 2021 07:07:30 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 17F8B3A11D1 for ; Tue, 13 Jul 2021 07:07:30 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id g22so27371916iom.1 for ; Tue, 13 Jul 2021 07:07:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=h+nBxeX8S8+dkMACEAzkBSZ0NE05BBxeLEzj8V1Qda0=; b=KH0oyChJrtnOKU+eieMTsK186lOCBlybowEsBtHR756+oPBK+sNOs2PfkwSScULf43 RzgXskcmcaTEaktWrnLohmfSOhxFErP2OYSvE8epW1NahFmZxj9GFG0g1EESgOC4aOF5 dO2Fv8TjR8Onaee+ZxGRDjVFNd0ExELJXm6YHL+m01yaGKIS1UGDTcRD11a7oh7m3//+ ZcDgCvYWi8oICRWi8FN1iXpZpZmDn1es7z6XyF0i3ecslU/jgIOcPM/qjbAKe1X793O3 dt98Ir93Y6zTYuq87WGY+Uau+boWL6uS8SFYBY/cvXeAuEUJk6o0vC0wiEQlnd56DsoY YzFw==
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=h+nBxeX8S8+dkMACEAzkBSZ0NE05BBxeLEzj8V1Qda0=; b=pYlNQqv9QNXPQWdfaZtlyT7MK+HRxg3EArs3FBc+yoGKSqeaACf8C0UtJW5yFUhS5r b4AjcN95vXcnihVn2ld8Lxzv010Uybd1GqOjhkN/W6K0UrL9NTQZuUl2NVpz2bux+qRQ oQ1wOuGlI48jGvTj6G03ROxdfZ5Xt8d2iBJrG9HrZ4n/zFEXWybMHXsUQIZQCkPQX7qk WDW8/8dfTRTXqmeeGe5/VKniGca5Cc2b8WddzFdNbJFohRWIjmTU4raMHByGgquwMZzJ XO45q8ioj6gZTtf5BJ36h00WbFE+G4WSlTWe+2T31LyuE/9ofBs+zjybVc3vLMN1AmyS +SUA==
X-Gm-Message-State: AOAM532t0CnNr32asF8HsFY9l+sHNCkNqvBy1FfzdsvwbXHCigoGT8he uE9JVM7corwuHYo8tWpaEGzPKQ==
X-Google-Smtp-Source: ABdhPJz2b9NV6hX6Jq1yUjzYbyJOiBrXbaulJF1pfTgJnXgRFYu/KNMiArA67hFOXep1Fr4HNMy39g==
X-Received: by 2002:a02:2382:: with SMTP id u124mr4138250jau.138.1626185248370;  Tue, 13 Jul 2021 07:07:28 -0700 (PDT)
Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id r6sm9864768ioh.27.2021.07.13.07.07.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jul 2021 07:07:27 -0700 (PDT)
From: Brian Rosen 
Message-Id: <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F4DE731-30C4-45C1-BB06-574BCF9BDA8E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Tue, 13 Jul 2021 10:07:26 -0400
In-Reply-To: <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net>
Cc: Adam Roach , rfced-future@iab.org
To: Mirja Kuehlewind 
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 14:07:36 -0000

--Apple-Mail=_0F4DE731-30C4-45C1-BB06-574BCF9BDA8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


The editor of any major newspaper doesn=E2=80=99t edit the news any =
more, but we call that position =E2=80=9CEditor=E2=80=9D. =20

Are you proposing to change the entire edifice we call the RFC Editor?  =
Is rfced@ietf.org  going to go away?  Will the =
website be moved and renamed?

I=E2=80=99d prefer to leave it as RFC Editor.  I also think it will be =
easier to hire someone if that=E2=80=99s the title, regardless of the =
job description.  Titles are cheap, and I=E2=80=99m sure you have been =
through some form of corporate title reclamation process that was well =
intentioned, but ultimately hurt a whole lot more than it helped.=20

Brian

> On Jul 13, 2021, at 9:43 AM, Mirja Kuehlewind  =
wrote:
>=20
> +1
>=20
>> On 13. Jul 2021, at 06:55, Adam Roach  wrote:
>>=20
>> On 7/12/2021 11:58 AM, Bob Hinden wrote:
>>> Changing it the =E2=80=9CRFC Series Advisor=E2=80=9D will cause =
considerable confusion in the larger community.
>>=20
>>=20
>> On the contrary, I believe it will clear up a long-running and =
frequently harmful source of major confusion in at least the IETF =
community. There have been a large number of conversations in which it =
became clear that seasoned IETF participants who are otherwise quite =
knowledgeable about the RFC publication process clearly believed that =
Heather actually edited documents.
>>=20
>> I don't have a position either way on whether "RSA" is the right =
term, but it's something I'm happy to live with. What I *do* know is =
that "Editor" has caused significant confusion in the past, and there's =
every reason to believe that it will cause significant confusion in the =
future. Replace it with something else.
>>=20
>> /a
>>=20
>> --=20
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future


--Apple-Mail=_0F4DE731-30C4-45C1-BB06-574BCF9BDA8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<as individual>
The editor of any major =
newspaper doesn=E2=80=99t edit the news any more, but we call that =
position =E2=80=9CEditor=E2=80=9D.  

Are you proposing to change the entire =
edifice we call the RFC Editor?  Is rfced@ietf.org going to go away?  Will the =
website be moved and renamed?

I=E2=80=99d prefer to leave it as RFC =
Editor.  I also think it will be easier to hire someone if that=E2=80=
=99s the title, regardless of the job description.  Titles are =
cheap, and I=E2=80=99m sure you have been through some form of corporate =
title reclamation process that was well intentioned, but ultimately hurt =
a whole lot more than it helped. 

Brian

On Jul =
13, 2021, at 9:43 AM, Mirja Kuehlewind <ietf@kuehlewind.net>=
 wrote:

+1

On 13. Jul 2021, at 06:55, Adam Roach <adam@nostrum.com> =
wrote:

On 7/12/2021 11:58 AM, Bob Hinden =
wrote:
Changing it =
the =E2=80=9CRFC Series Advisor=E2=80=9D will cause considerable =
confusion in the larger community.


On the contrary, I believe it will clear up a =
long-running and frequently harmful source of major confusion in at =
least the IETF community. There have been a large number of =
conversations in which it became clear that seasoned IETF participants =
who are otherwise quite knowledgeable about the RFC publication process =
clearly believed that Heather actually edited documents.
I don't have a position either way on whether "RSA" is the =
right term, but it's something I'm happy to live with. What I *do* know =
is that "Editor" has caused significant confusion in the past, and =
there's every reason to believe that it will cause significant confusion =
in the future. Replace it with something else.

/a

-- 
Rfced-future =
mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- 
Rfced-future =
mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

=

--Apple-Mail=_0F4DE731-30C4-45C1-BB06-574BCF9BDA8E--


From nobody Tue Jul 13 07:18:08 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406613A1233 for ; Tue, 13 Jul 2021 07:18:07 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed0sAWNAfXLR for ; Tue, 13 Jul 2021 07:18:02 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0B03A122D for ; Tue, 13 Jul 2021 07:18:02 -0700 (PDT)
Received: from p200300dee70cfa0041f532c7c70c9597.dip0.t-ipconnect.de ([2003:de:e70c:fa00:41f5:32c7:c70c:9597]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1m3JEV-0001C7-0v; Tue, 13 Jul 2021 16:17:59 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Mirja Kuehlewind 
In-Reply-To: <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>
Date: Tue, 13 Jul 2021 16:17:58 +0200
Cc: Adam Roach , rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>
To: Brian Rosen 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1626185882;515c7c94;
X-HE-SMSGID: 1m3JEV-0001C7-0v
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 14:18:07 -0000

As someone else already said, I think we can still have an RFC editor =
_function_ but the person we hire should not be called the RFC Editor. =
That has caused more confusion that it was helpful in our community (at =
least when that term is related to a concrete person).

Mirja


> On 13. Jul 2021, at 16:07, Brian Rosen  wrote:
>=20
> 
> The editor of any major newspaper doesn=E2=80=99t edit the news any =
more, but we call that position =E2=80=9CEditor=E2=80=9D. =20
>=20
> Are you proposing to change the entire edifice we call the RFC Editor? =
 Is rfced@ietf.org going to go away?  Will the website be moved and =
renamed?
>=20
> I=E2=80=99d prefer to leave it as RFC Editor.  I also think it will be =
easier to hire someone if that=E2=80=99s the title, regardless of the =
job description.  Titles are cheap, and I=E2=80=99m sure you have been =
through some form of corporate title reclamation process that was well =
intentioned, but ultimately hurt a whole lot more than it helped.=20
>=20
> Brian
>=20
>> On Jul 13, 2021, at 9:43 AM, Mirja Kuehlewind  =
wrote:
>>=20
>> +1
>>=20
>>> On 13. Jul 2021, at 06:55, Adam Roach  wrote:
>>>=20
>>> On 7/12/2021 11:58 AM, Bob Hinden wrote:
>>>> Changing it the =E2=80=9CRFC Series Advisor=E2=80=9D will cause =
considerable confusion in the larger community.
>>>=20
>>>=20
>>> On the contrary, I believe it will clear up a long-running and =
frequently harmful source of major confusion in at least the IETF =
community. There have been a large number of conversations in which it =
became clear that seasoned IETF participants who are otherwise quite =
knowledgeable about the RFC publication process clearly believed that =
Heather actually edited documents.
>>>=20
>>> I don't have a position either way on whether "RSA" is the right =
term, but it's something I'm happy to live with. What I *do* know is =
that "Editor" has caused significant confusion in the past, and there's =
every reason to believe that it will cause significant confusion in the =
future. Replace it with something else.
>>>=20
>>> /a
>>>=20
>>> --=20
>>> Rfced-future mailing list
>>> Rfced-future@iab.org
>>> https://www.iab.org/mailman/listinfo/rfced-future
>>=20
>> --=20
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>=20


From nobody Tue Jul 13 07:21:18 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333203A1271 for ; Tue, 13 Jul 2021 07:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level: 
X-Spam-Status: No, score=-2.795 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 g9_rWAsMUvPN for ; Tue, 13 Jul 2021 07:21:11 -0700 (PDT)
Received: from mr85p00im-ztdg06011901.me.com (mr85p00im-ztdg06011901.me.com [17.58.23.198]) (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 172683A1260 for ; Tue, 13 Jul 2021 07:21:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1626186070; bh=NijWDKe4dEEzQFC+t/uXywJSs/FTHBM2zqGmPaoJkHc=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=O8PS+aE6753tIdjr2td7FGMs/IrPUX4cdk3tarZcyC3U4Y89y3PZotT9vtlmeGrL+ wCDkzjqWdcPltV4TQW3tNYyHILjp8Fu7iWw+bivJcq85F1MnOzTOsuCoyC/7caURfr 4bQZOA1Hn8Ar+GzFPFSVXWLvOGRhLPl0TdAIqrRBPIdTMO5kxXv/Pm8Wf2aPv5cVdi UqrhQ3VYcPC2RbQ2n7+Zd0MoKp+e5aceCpqJcy33IB6R0OPwZCAzvmjM4J+yfdPyB5 TsenMV/DGf7A5NjjY2wfPVA2WnfKidaHhUb6jt9xJwcG053WBP9Y5QqG5u+4GLtHr2 MaAhHIHJLs7Ew==
Received: from smtpclient.apple (157-131-155-250.fiber.dynamic.sonic.net [157.131.155.250]) by mr85p00im-ztdg06011901.me.com (Postfix) with ESMTPSA id 29B13A60BA6; Tue, 13 Jul 2021 14:21:10 +0000 (UTC)
From: Ole Jacobsen 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_17F12BD2-2EEC-4BA8-90D4-8A9B8F90A685"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Tue, 13 Jul 2021 07:21:09 -0700
In-Reply-To: <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>
Cc: Ole Jacobsen , Mirja Kuehlewind ,  rfced-future@iab.org, Adam Roach 
To: Brian Rosen 
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-07-13=5F07:2021-07-12=5F02,2021-07-13=5F07,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 suspectscore=0 mlxscore=0 clxscore=1011 spamscore=0 malwarescore=0 adultscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2107130092
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 14:21:16 -0000

--Apple-Mail=_17F12BD2-2EEC-4BA8-90D4-8A9B8F90A685
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1

The terms "editor" and "publisher" have various meanings depending on =
context.

While it is certainly true that the RFC Editor neither decides what gets =
published
nor actually does the copy-editing of the material, it is still the case =
that he=20
or she manages a process of document publication/editing and it is not =
at all unreasonable
to use the title "RFC Editor" for this function.

Ole (who is both an Editor (both meanings) and Publisher (various =
meanings).


> On Jul 13, 2021, at 07:07, Brian Rosen  wrote:
>=20
> 
> The editor of any major newspaper doesn=E2=80=99t edit the news any =
more, but we call that position =E2=80=9CEditor=E2=80=9D. =20
>=20
> Are you proposing to change the entire edifice we call the RFC Editor? =
 Is rfced@ietf.org  going to go away?  Will the =
website be moved and renamed?
>=20
> I=E2=80=99d prefer to leave it as RFC Editor.  I also think it will be =
easier to hire someone if that=E2=80=99s the title, regardless of the =
job description.  Titles are cheap, and I=E2=80=99m sure you have been =
through some form of corporate title reclamation process that was well =
intentioned, but ultimately hurt a whole lot more than it helped.=20
>=20
> Brian
>=20
>> On Jul 13, 2021, at 9:43 AM, Mirja Kuehlewind > wrote:
>>=20
>> +1
>>=20
>>> On 13. Jul 2021, at 06:55, Adam Roach > wrote:
>>>=20
>>> On 7/12/2021 11:58 AM, Bob Hinden wrote:
>>>> Changing it the =E2=80=9CRFC Series Advisor=E2=80=9D will cause =
considerable confusion in the larger community.
>>>=20
>>>=20
>>> On the contrary, I believe it will clear up a long-running and =
frequently harmful source of major confusion in at least the IETF =
community. There have been a large number of conversations in which it =
became clear that seasoned IETF participants who are otherwise quite =
knowledgeable about the RFC publication process clearly believed that =
Heather actually edited documents.
>>>=20
>>> I don't have a position either way on whether "RSA" is the right =
term, but it's something I'm happy to live with. What I *do* know is =
that "Editor" has caused significant confusion in the past, and there's =
every reason to believe that it will cause significant confusion in the =
future. Replace it with something else.
>>>=20
>>> /a
>>>=20
>>> --=20
>>> Rfced-future mailing list
>>> Rfced-future@iab.org 
>>> https://www.iab.org/mailman/listinfo/rfced-future
>>=20
>> --=20
>> Rfced-future mailing list
>> Rfced-future@iab.org 
>> https://www.iab.org/mailman/listinfo/rfced-future
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocoljournal.org
E-mail: olejacobsen@me.com
E-mail: ole@protocoljournal.org
Skype: organdemo




--Apple-Mail=_17F12BD2-2EEC-4BA8-90D4-8A9B8F90A685
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1

The =
terms "editor" and "publisher" have various meanings depending on =
context.

While =
it is certainly true that the RFC Editor neither decides what gets =
published
nor actually does the copy-editing of the =
material, it is still the case that he 
or she =
manages a process of document publication/editing and it is not at all =
unreasonable
to use the title "RFC Editor" for this =
function.

Ole =
(who is both an Editor (both meanings) and Publisher (various =
meanings).


On Jul =
13, 2021, at 07:07, Brian Rosen <br@brianrosen.net> wrote:

<as =
individual>
The editor of any major newspaper =
doesn=E2=80=99t edit the news any more, but we call that position =
=E2=80=9CEditor=E2=80=9D.  

Are you proposing to change the entire =
edifice we call the RFC Editor?  Is rfced@ietf.org going to go away?  Will the =
website be moved and renamed?

I=E2=80=99d prefer to leave it as RFC =
Editor.  I also think it will be easier to hire someone if that=E2=80=
=99s the title, regardless of the job description.  Titles are =
cheap, and I=E2=80=99m sure you have been through some form of corporate =
title reclamation process that was well intentioned, but ultimately hurt =
a whole lot more than it helped. 

Brian

On Jul =
13, 2021, at 9:43 AM, Mirja Kuehlewind <ietf@kuehlewind.net>=
 wrote:

+1

On 13. Jul 2021, at 06:55, Adam Roach <adam@nostrum.com> =
wrote:

On 7/12/2021 11:58 AM, Bob Hinden =
wrote:
Changing it =
the =E2=80=9CRFC Series Advisor=E2=80=9D will cause considerable =
confusion in the larger community.


On the contrary, I believe it will clear up a =
long-running and frequently harmful source of major confusion in at =
least the IETF community. There have been a large number of =
conversations in which it became clear that seasoned IETF participants =
who are otherwise quite knowledgeable about the RFC publication process =
clearly believed that Heather actually edited documents.
I don't have a position either way on whether "RSA" is the =
right term, but it's something I'm happy to live with. What I *do* know =
is that "Editor" has caused significant confusion in the past, and =
there's every reason to believe that it will cause significant confusion =
in the future. Replace it with something else.

/a

-- 
Rfced-future =
mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- 
Rfced-future =
mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- =

Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future



Ole J. Jacobsen
Editor and Publisher
The Internet =
Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocoljournal.org
E-mail: olejacobsen@me.com
E-mail: ole@protocoljournal.org
Skype: =
organdemo






=

--Apple-Mail=_17F12BD2-2EEC-4BA8-90D4-8A9B8F90A685--


From nobody Tue Jul 13 07:39:52 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981E73A13B4; Tue, 13 Jul 2021 07:39:50 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7DmDDE8n3vO; Tue, 13 Jul 2021 07:39:45 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1EB3A13B1; Tue, 13 Jul 2021 07:39:44 -0700 (PDT)
Received: from p200300dee70cfa0041f532c7c70c9597.dip0.t-ipconnect.de ([2003:de:e70c:fa00:41f5:32c7:c70c:9597]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1m3JZU-0003mL-Ky; Tue, 13 Jul 2021 16:39:40 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Mirja Kuehlewind 
In-Reply-To: 
Date: Tue, 13 Jul 2021 16:39:39 +0200
Cc: Brian Rosen , rfced-future@iab.org, Ole Jacobsen , Adam Roach 
Content-Transfer-Encoding: quoted-printable
Message-Id: <641F94A3-D5C2-42A7-9075-E1E871FEC1A3@kuehlewind.net>
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net> 
To: Ole Jacobsen 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1626187185;1bb1b0b1;
X-HE-SMSGID: 1m3JZU-0003mL-Ky
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 14:39:51 -0000

I believe with the new model we are creating now the person who "manages =
a process of document publication/editing=E2=80=9D who be someone in the =
RPC.


> On 13. Jul 2021, at 16:21, Ole Jacobsen =
 wrote:
>=20
> +1
>=20
> The terms "editor" and "publisher" have various meanings depending on =
context.
>=20
> While it is certainly true that the RFC Editor neither decides what =
gets published
> nor actually does the copy-editing of the material, it is still the =
case that he=20
> or she manages a process of document publication/editing and it is not =
at all unreasonable
> to use the title "RFC Editor" for this function.
>=20
> Ole (who is both an Editor (both meanings) and Publisher (various =
meanings).
>=20
>=20
>> On Jul 13, 2021, at 07:07, Brian Rosen  wrote:
>>=20
>> 
>> The editor of any major newspaper doesn=E2=80=99t edit the news any =
more, but we call that position =E2=80=9CEditor=E2=80=9D. =20
>>=20
>> Are you proposing to change the entire edifice we call the RFC =
Editor?  Is rfced@ietf.org going to go away?  Will the website be moved =
and renamed?
>>=20
>> I=E2=80=99d prefer to leave it as RFC Editor.  I also think it will =
be easier to hire someone if that=E2=80=99s the title, regardless of the =
job description.  Titles are cheap, and I=E2=80=99m sure you have been =
through some form of corporate title reclamation process that was well =
intentioned, but ultimately hurt a whole lot more than it helped.=20
>>=20
>> Brian
>>=20
>>> On Jul 13, 2021, at 9:43 AM, Mirja Kuehlewind  =
wrote:
>>>=20
>>> +1
>>>=20
>>>> On 13. Jul 2021, at 06:55, Adam Roach  wrote:
>>>>=20
>>>> On 7/12/2021 11:58 AM, Bob Hinden wrote:
>>>>> Changing it the =E2=80=9CRFC Series Advisor=E2=80=9D will cause =
considerable confusion in the larger community.
>>>>=20
>>>>=20
>>>> On the contrary, I believe it will clear up a long-running and =
frequently harmful source of major confusion in at least the IETF =
community. There have been a large number of conversations in which it =
became clear that seasoned IETF participants who are otherwise quite =
knowledgeable about the RFC publication process clearly believed that =
Heather actually edited documents.
>>>>=20
>>>> I don't have a position either way on whether "RSA" is the right =
term, but it's something I'm happy to live with. What I *do* know is =
that "Editor" has caused significant confusion in the past, and there's =
every reason to believe that it will cause significant confusion in the =
future. Replace it with something else.
>>>>=20
>>>> /a
>>>>=20
>>>> --=20
>>>> Rfced-future mailing list
>>>> Rfced-future@iab.org
>>>> https://www.iab.org/mailman/listinfo/rfced-future
>>>=20
>>> --=20
>>> Rfced-future mailing list
>>> Rfced-future@iab.org
>>> https://www.iab.org/mailman/listinfo/rfced-future
>>=20
>> --=20
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>=20
> Ole J. Jacobsen
> Editor and Publisher
> The Internet Protocol Journal
> Office: +1 415-550-9433
> Cell:   +1 415-370-4628
> Web: protocoljournal.org
> E-mail: olejacobsen@me.com
> E-mail: ole@protocoljournal.org
> Skype: organdemo
>=20
>=20
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future


From nobody Tue Jul 13 07:46:32 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7864E3A143B for ; Tue, 13 Jul 2021 07:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zayFuiT6YKTT for ; Tue, 13 Jul 2021 07:46:29 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0103A143A for ; Tue, 13 Jul 2021 07:46:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 60397300C74 for ; Tue, 13 Jul 2021 10:46:28 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6YZchKH4tf5Y for ; Tue, 13 Jul 2021 10:46:23 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id E4729300A2F; Tue, 13 Jul 2021 10:46:22 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley 
In-Reply-To: 
Date: Tue, 13 Jul 2021 10:46:22 -0400
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net> 
To: Mirja Kuehlewind 
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 14:46:31 -0000

Mirja:

> As someone else already said, I think we can still have an RFC editor =
_function_ but the person we hire should not be called the RFC Editor.

We had this same discussion for RFC Editor Model Version 2 (RFC 6635).  =
Those discussions created the term  RFC Series Editor (RSE) to =
distinguish this position from the overall RFC Editor function.

Russ


From nobody Tue Jul 13 07:46:56 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600963A143B for ; Tue, 13 Jul 2021 07:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level: 
X-Spam-Status: No, score=-2.796 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 r2equVYj3sgI for ; Tue, 13 Jul 2021 07:46:50 -0700 (PDT)
Received: from mr85p00im-zteg06012001.me.com (mr85p00im-zteg06012001.me.com [17.58.23.197]) (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 CA8223A143A for ; Tue, 13 Jul 2021 07:46:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1626187610; bh=7xPXLucKWouNU+tUU3blZrRe8YUbnDL0P5aXtezWYiQ=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=TMbhOQppf/cDCogtFN9Q7Y66qWd+y3Ct7NASk5vifZvvRMOorBC2fg267dKWIv+gm JcEuadREcj6a8ufL540lFHL1XK3Gsptz8cO1tYlJ+dbiIO5/3r3VKxOa4i330auosb INJsb0aZnJqYvXcMHigN7WAqmyQZwH39o9RAvMut9bfNCbStM5H8aDJxH9Fy2k8wZd n6RWV9eJVk7IpOr+Ua6mqbsRYdkR8AzV25WzWdBpWsh9AyvhvT5k9COaTHgSyrHjW8 K7NE1rxh8QYep4naAG/SpnCzlGhktDSdE7NR34RKAAE4dmgxV3G4gwgOROUqX5R2V5 5e2DbOTkaRflw==
Received: from smtpclient.apple (157-131-155-250.fiber.dynamic.sonic.net [157.131.155.250]) by mr85p00im-zteg06012001.me.com (Postfix) with ESMTPSA id C185AA00B51; Tue, 13 Jul 2021 14:46:49 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Ole Jacobsen 
In-Reply-To: <641F94A3-D5C2-42A7-9075-E1E871FEC1A3@kuehlewind.net>
Date: Tue, 13 Jul 2021 07:46:49 -0700
Cc: Ole Jacobsen , Brian Rosen , rfced-future@iab.org, Adam Roach 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>  <641F94A3-D5C2-42A7-9075-E1E871FEC1A3@kuehlewind.net>
To: Mirja Kuehlewind 
X-Mailer: Apple Mail (2.3654.100.0.2.22)
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-07-13=5F07:2021-07-13=5F03,2021-07-13=5F07,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 adultscore=0 clxscore=1015 bulkscore=0 suspectscore=0 spamscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2107130094
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 14:46:55 -0000

At one level, "yes" the RPC manages the *mechanics* of =
producing/publishing the documents,
but they report to another person/entity that we have traditionally =
called the RFC Editor.
In the publication industry, we would probably call that person anything =
from Publisher
to -Editor, where  could have a wide range of =
titles.

Context and history matters a lot in our case.

> On Jul 13, 2021, at 07:39, Mirja Kuehlewind  =
wrote:
>=20
> I believe with the new model we are creating now the person who =
"manages a process of document publication/editing=E2=80=9D who be =
someone in the RPC.
>=20
>=20
>> On 13. Jul 2021, at 16:21, Ole Jacobsen =
 wrote:
>>=20
>> +1
>>=20
>> The terms "editor" and "publisher" have various meanings depending on =
context.
>>=20
>> While it is certainly true that the RFC Editor neither decides what =
gets published
>> nor actually does the copy-editing of the material, it is still the =
case that he=20
>> or she manages a process of document publication/editing and it is =
not at all unreasonable
>> to use the title "RFC Editor" for this function.
>>=20
>> Ole (who is both an Editor (both meanings) and Publisher (various =
meanings).
>>=20
>>=20
>>> On Jul 13, 2021, at 07:07, Brian Rosen  wrote:
>>>=20
>>> 
>>> The editor of any major newspaper doesn=E2=80=99t edit the news any =
more, but we call that position =E2=80=9CEditor=E2=80=9D. =20
>>>=20
>>> Are you proposing to change the entire edifice we call the RFC =
Editor?  Is rfced@ietf.org going to go away?  Will the website be moved =
and renamed?
>>>=20
>>> I=E2=80=99d prefer to leave it as RFC Editor.  I also think it will =
be easier to hire someone if that=E2=80=99s the title, regardless of the =
job description.  Titles are cheap, and I=E2=80=99m sure you have been =
through some form of corporate title reclamation process that was well =
intentioned, but ultimately hurt a whole lot more than it helped.=20
>>>=20
>>> Brian
>>>=20
>>>> On Jul 13, 2021, at 9:43 AM, Mirja Kuehlewind  =
wrote:
>>>>=20
>>>> +1
>>>>=20
>>>>> On 13. Jul 2021, at 06:55, Adam Roach  wrote:
>>>>>=20
>>>>> On 7/12/2021 11:58 AM, Bob Hinden wrote:
>>>>>> Changing it the =E2=80=9CRFC Series Advisor=E2=80=9D will cause =
considerable confusion in the larger community.
>>>>>=20
>>>>>=20
>>>>> On the contrary, I believe it will clear up a long-running and =
frequently harmful source of major confusion in at least the IETF =
community. There have been a large number of conversations in which it =
became clear that seasoned IETF participants who are otherwise quite =
knowledgeable about the RFC publication process clearly believed that =
Heather actually edited documents.
>>>>>=20
>>>>> I don't have a position either way on whether "RSA" is the right =
term, but it's something I'm happy to live with. What I *do* know is =
that "Editor" has caused significant confusion in the past, and there's =
every reason to believe that it will cause significant confusion in the =
future. Replace it with something else.
>>>>>=20
>>>>> /a
>>>>>=20
>>>>> --=20
>>>>> Rfced-future mailing list
>>>>> Rfced-future@iab.org
>>>>> https://www.iab.org/mailman/listinfo/rfced-future
>>>>=20
>>>> --=20
>>>> Rfced-future mailing list
>>>> Rfced-future@iab.org
>>>> https://www.iab.org/mailman/listinfo/rfced-future
>>>=20
>>> --=20
>>> Rfced-future mailing list
>>> Rfced-future@iab.org
>>> https://www.iab.org/mailman/listinfo/rfced-future
>>=20
>> Ole J. Jacobsen
>> Editor and Publisher
>> The Internet Protocol Journal
>> Office: +1 415-550-9433
>> Cell:   +1 415-370-4628
>> Web: protocoljournal.org
>> E-mail: olejacobsen@me.com
>> E-mail: ole@protocoljournal.org
>> Skype: organdemo
>>=20
>>=20
>>=20
>> --=20
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>=20

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocoljournal.org
E-mail: olejacobsen@me.com
E-mail: ole@protocoljournal.org
Skype: organdemo




From nobody Tue Jul 13 08:00:00 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EF03A153C for ; Tue, 13 Jul 2021 07:59:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 8JSyAjEb1k0F for ; Tue, 13 Jul 2021 07:59:57 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 A9BE33A153A for ; Tue, 13 Jul 2021 07:59:52 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id z11so5809015iow.0 for ; Tue, 13 Jul 2021 07:59:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uQ/PznYc1a9hFpe4h5zsfRFRH4a45qANxtYk9rfqWHc=; b=QTBHzHZKwMF0oOASLilZsS7yDbO0IGusUPyWCrVzsUKttrRiUIM+8QRgOTMl9GVxTw tFvUTzKVu4N+7VDV6N7zYq0xYr2BVmigshyKOBukY37Tnq+cR913qjLCc4i/MW9PXj7r IECiILzx+WJOkt4plkvYOVAl4WfTcoXdzbgQk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uQ/PznYc1a9hFpe4h5zsfRFRH4a45qANxtYk9rfqWHc=; b=sat4g07+QBTsBVC+2S9D62EfilSnVe7Iq5WElYnFRGBbCxYm2o+nzl8XqVJaRy7/CZ 0adovxNsG9uas9rzvGG6MjRwEhRGGeWdWfD8OY3mQ+GXSCXqgbMn/DXgJco2FRr5G9Dr AjyM2VkZS2NOZy0waiUHRbQYAyHc7wIhDkNElEQLV7/3qb4rhe3YXGR37Fj36JgAK3G5 2BUkcmaAZe5Qx/j9cscv9ho/Knbs9MDVyfRlM/tF3Ch7/UvyACQi5m2ZVFbUiabDE1S3 zSR8GQzmZoWs2n1kSPv33YUvp7LRTq3vyYwXHpyGxSGHpfe2QhOr4Nb52cS2TawChdY/ 7dRw==
X-Gm-Message-State: AOAM533wpeZ0Nciaa9QmIVferqmH4I8NG5mER36tp09AyJFGycI+SGN4 wk2a5RDvYfuy3vwGoPQBhmdmng==
X-Google-Smtp-Source: ABdhPJwyaMIXqSFSKdw2JM8roWzBfztl8H/m7Hjo3VMLqTE0vAfDjP9+Pr3Y54xHxV3WtKTVfa2VyQ==
X-Received: by 2002:a05:6602:1501:: with SMTP id g1mr3577448iow.189.1626188390996;  Tue, 13 Jul 2021 07:59:50 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id i7sm9479984ilb.67.2021.07.13.07.59.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 07:59:50 -0700 (PDT)
To: Ole Jacobsen 
Cc: rfced-future@iab.org
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>  <641F94A3-D5C2-42A7-9075-E1E871FEC1A3@kuehlewind.net> 
From: Peter Saint-Andre 
Message-ID: <970cd331-985c-8267-6969-7c41f151ac50@mozilla.com>
Date: Tue, 13 Jul 2021 08:59:48 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 14:59:59 -0000

On 7/13/21 8:46 AM, Ole Jacobsen wrote:
> At one level, "yes" the RPC manages the *mechanics* of producing/publishing the documents,
> but they report to another person/entity that we have traditionally called the RFC Editor.
> In the publication industry, we would probably call that person anything from Publisher
> to -Editor, where  could have a wide range of titles.

Except that in version 3 of the model as we have defined it so far, (1)
the RPC doesn't report to the technical publishing expert and (2) policy
direction is defined by the community (in the form of the RFC Series
Working Group, whose proposals are reviewed and ratified by the RFC
Series Approval Board, one member of which is the technical publishing
expert). Thus it seems that in version 3 the technical publishing expert
doesn't act as, say, an executive editor at a journal or press would,
and instead plays a significant yet advisory role.

> Context and history matters a lot in our case.

As a Nobel prize winner once said, the times they are a-changin'...

Peter


From nobody Tue Jul 13 08:34:58 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98C13A1822 for ; Tue, 13 Jul 2021 08:34:56 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 lIalb9-fysEQ for ; Tue, 13 Jul 2021 08:34:52 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 5FC573A1818 for ; Tue, 13 Jul 2021 08:34:52 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id a11so23619903ilf.2 for ; Tue, 13 Jul 2021 08:34:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4XwFWEbA+zTlYipQPFR+aDwNHrYNuHy/hy1QpIxGYz8=; b=M1ND6yCZI/7KdD39L7r8hY9pO8cnUr5HhNUeu1c9fTaKSS9RCLHVuOSqFD+UAvpPEO p04j6DI74Q3Tdphx5OxG1pkeX0iSvoHuLQMtj7W+39jqJ9W/Oq+W0QT87ftf1iH9+bDG cY4aDiXklsIaXbRcUuUi6rHauy8gUpBbrDcqs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4XwFWEbA+zTlYipQPFR+aDwNHrYNuHy/hy1QpIxGYz8=; b=nkwwuaeXktCStpKd16phxXIQdFRSgoeqCtm3oZN4yyL7iwpCDmWeLfLr7+rzybRzvB Rmvu4LRdi9CSqVTAoa5/ymWq968sZt4anaAJ0Q/OcpuJSbw8VoXfnMNTicOU4i5/XN5/ vJgewGi8ouvN9MyZyRyjl+Vgc1PfvYOReprftux0b/GRV8+/jXFjnudskNRos3TmPMg/ 2f5ag1hl9BKqSgC4gz+TMpTv8ifiV924q/cwZuWTxY0Ss40RgvYUwebc47d/H6P53TjG TTpU2ix4HLTJf1LmevIIbVS/85f56hvoTftnQS/03UYr6KhFfBKAOxavzC3N52C4Emn4 WQ5w==
X-Gm-Message-State: AOAM5328PfVMrG7VkHVsjloe8Oo7/sn4CCVufMyD7FMHVAfEew60uhPX ff9k05QVY9TheIjyW+DSFWb3Aw==
X-Google-Smtp-Source: ABdhPJxsZzuQCt/vgPIVgEVABR5soIWKv7bV/wA1VduURP8e3JrHPQlLbdAGATsCduESR3JCGCqEfw==
X-Received: by 2002:a05:6e02:eac:: with SMTP id u12mr3475503ilj.216.1626190489934;  Tue, 13 Jul 2021 08:34:49 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id z22sm1854020iog.13.2021.07.13.08.34.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 08:34:49 -0700 (PDT)
To: "StJohns, Michael" , Brian E Carpenter 
Cc: rfced-future@iab.org, Bob Hinden 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com> 
From: Peter Saint-Andre 
Message-ID: 
Date: Tue, 13 Jul 2021 09:34:47 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 15:34:57 -0000

We seem to speculate with fair frequency about the titles that will make
it possible to attract candidates for the role of technical publishing
expert within version 3 of the model. I'm not so sure how important that
is (after all, a role like the National Security Advisor in the U.S.
government is perceived as significant even though it has "advisor" in
the name); what might matter most is the actual activities the person
will perform, the respect accorded to the role, the perceived importance
of the RFC Series, etc.

Peter

On 7/12/21 10:29 PM, StJohns, Michael wrote:
> I don't think so.  I’m not even sure we could get anyone to apply for
> something with that job title.  Mike
> 
> On Tue, Jul 13, 2021 at 00:11 Brian E Carpenter
> > wrote:
> 
>     Could we compromise on "RFC Series Advisory Editor"?
> 
>     The term is used quite widely and it even seems accurate.
> 
>     Regards
>        Brian Carpenter
> 
>     On 13-Jul-21 16:00, Bob Hinden wrote:
>     > Brian,
>     >
>     >> On Jul 12, 2021, at 7:52 PM, Brian E Carpenter
>     >
>     wrote:
>     >>
>     >> I don't think there is any proposal to retire the term "RFC Editor".
>     >> But for many years it has referred to the function as well as to
>     >> the figurehead. RFC2850 refers to "an organization to act as
>     >> RFC Editor" because even in May 2000 it wasn't a person, although
>     >> Bob Braden led the team. And also "The Internet Society, the RFC
>     Editor,
>     >> the IANA and the IESG each appoints a liaison member to the IAB."
>     >>
>     >> Given the job description and role of the RSEA, I really don't see
>     >> how we can call the person an editor.
>     >
>     > Think about it like positions in the US called “Secretary of
>     State”, see:
>     >
>     > https://www.state.gov/secretary/ 
>     >
>     > They are not performing secretarial duties.
>     >
>     > Bob
>     >
>     >
>     >>
>     >> Regards
>     >>   Brian Carpenter
>     >>
>     >> On 13-Jul-21 05:20, Michael StJohns wrote:
>     >>> Bob said it better than I can.   Mike
>     >>>
>     >>> On 7/12/2021 12:58 PM, Bob Hinden wrote:
>     >>>> Hi,
>     >>>>
>     >>>>> On Jul 9, 2021, at 2:03 PM, Peter Saint-Andre
>     >
>     wrote:
>     >>>>>
>     >>>>> The role played by the technical publishing expert in version
>     3 of the
>     >>>>> model is different enough from past roles that I suggest we
>     should not
>     >>>>> use the name "RFC Series Editor" but instead "RFC Series Advisor”.
>     >>>> I strongly disagree.
>     >>>>
>     >>>> The RFC Editor role has changed multiple times in the past in
>     many ways and we still call it the RFC Editor.
>     >>>>
>     >>>> This includes:
>     >>>>
>     >>>> Administrative support and direction changed from Defense
>     Advanced Project Agency (DARPA), the Internet Society, IAOC, and
>     currently the IETF
>     LLC.
>     >>>>
>     >>>> It has been performed by Jon Postel, Bob Braden, Joyce
>     Reynolds, Glenn
>     >> Kowack, Olaf Kolkman, and Heather Flanagan.
>     >>>>
>     >>>> Actual editing has transitioned from an individual to a
>     contracted company.
>     >>>>
>     >>>> The scope and the context of this position has changed as the
>     administration and the person doing the job changed.   It has great
>     name recognition.   I don’t see any reason why what we are defining
>     now can not be called the RFC Editor.   Changing it the “RFC Series
>     Advisor” will cause considerable confusion in the larger community.
>     >>>>
>     >>>> Bob
>     >>>>
>     >>>>
>     >>>>
>     >>>
>     >>>
>     >>
>     >> --
>     >> Rfced-future mailing list
>     >> Rfced-future@iab.org 
>     >> https://www.iab.org/mailman/listinfo/rfced-future
>     
>     >
> 
> 


From nobody Tue Jul 13 08:37:25 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58913A1887 for ; Tue, 13 Jul 2021 08:37:16 -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=nthpermutation-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 Q69v459FGJ-a for ; Tue, 13 Jul 2021 08:37:11 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52EA83A1842 for ; Tue, 13 Jul 2021 08:37:11 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id n14so51008388lfu.8 for ; Tue, 13 Jul 2021 08:37:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0/ArpbLc7uLJjSWot7XCY6vnPxfBw7tVWk5wDMIb6xs=; b=vSzC5jU1n5FbAkiG4mKnekK5sXmXRCi9hPN1I7DN/rT+WQdWz32Zov8P2LfdLUrp7K 4kC6gv4ch/GixYDIKfx6rKKEZhIrDKDYKHe0k7zTX74BW8GGvFfqF0N1NoQY+RZTGDzT 0J8jnUl8nNA0uUNAeyGK7Vl+1efbmz0z9yJwycZ6EKI9F2gty+NwrJCXSEFzzVTGvDNv frDuK15x5K0KroJicNFWr1/dw+3/4hbn8Xj1kTqQZVML71qqy1DFHs3UiS4r+7VlBvo1 FGRnTTcsaGQLsSfGiMsYavf6kXlBWr/qFdzgeo7dh/p8LSJ43hEbaTiZMysbc4ewpirw TXbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0/ArpbLc7uLJjSWot7XCY6vnPxfBw7tVWk5wDMIb6xs=; b=W1W3C7loncOJKmrSa/JuUnC1D2arCzxua7PC+KV7LH5eXMjcMrUaUpLX+IWtpJb0JS ZavnDfSHaOGSD1xABpHlOIK3z9a32j/vA6rnI0o8uRD7zglNhbOulMpbYbYx9UK6yX7y LF9nuVY6tWeBVKh8f1NQ1QB+p93K6dyvfIHKt2hAEyG18DSWazchhBgT4h0HI8tXfFXq SJs8vq7LMh9xjoPRD4S0bZOKyxQU41BNNlOxrF4zf5V+kDXHcGEij1nWsgpQ/YcA3MGj yl18NID+mN/nd7mO+rOlcNj2izdtyi3dkOqUImWyIvw2qP/7MP01bMolXZ6RJObb5eGl 7CcA==
X-Gm-Message-State: AOAM533IUcM6QciymSti8j/QXT4dA4DTjFRBPiQWn0uzAlQpNnRGaGQv hp2uhXEAI6s7oVRFWcIwZQ9Yc04EbdshPL0yhG0jRs/s2/ATP/K5
X-Google-Smtp-Source: ABdhPJyS9GT2dG62DCMQMChskTAwucj3TrtOHySvNOe1YpV4ldqL+z4xvxnpvi4y/HQU56xfvodnfMWd1OxU9LVgmNY=
X-Received: by 2002:a19:790f:: with SMTP id u15mr3912490lfc.267.1626190628574;  Tue, 13 Jul 2021 08:37:08 -0700 (PDT)
MIME-Version: 1.0
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> 
In-Reply-To: 
From: "StJohns, Michael" 
Date: Tue, 13 Jul 2021 11:36:57 -0400
Message-ID: 
To: "rfced-future@iab.org" 
Content-Type: multipart/alternative; boundary="000000000000c0e96805c7030268"
Archived-At: 
Subject: [Rfced-future] Fwd:  Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 15:37:24 -0000

--000000000000c0e96805c7030268
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

*sigh* This should have gone to the list.  Mike

---------- Forwarded message ---------
From: StJohns, Michael 
Date: Tue, Jul 13, 2021 at 01:23
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
To: Adam Roach 


Hi Adam -

Can you point us to an email thread or two where this =E2=80=9Csignificant=
=E2=80=9D
confusion manifested itself?   Ideally one where said confusion had some
material impact on the publication process?   I=E2=80=99m actually surprise=
d to
hear this as that seems a topic that would probably drive us down a rathole
on the IETF mailing list and I don=E2=80=99t remember such a thing.

In any event, an editor does not necessarily edit - a 30 second perusal of
a dictionary should have been sufficient to clear up any confusion.

Thanks Mike




On Tue, Jul 13, 2021 at 00:55 Adam Roach  wrote:

> On 7/12/2021 11:58 AM, Bob Hinden wrote:
> > Changing it the =E2=80=9CRFC Series Advisor=E2=80=9D will cause conside=
rable confusion
> in the larger community.
>
>
> On the contrary, I believe it will clear up a long-running and
> frequently harmful source of major confusion in at least the IETF
> community. There have been a large number of conversations in which it
> became clear that seasoned IETF participants who are otherwise quite
> knowledgeable about the RFC publication process clearly believed that
> Heather actually edited documents.
>
> I don't have a position either way on whether "RSA" is the right term,
> but it's something I'm happy to live with. What I *do* know is that
> "Editor" has caused significant confusion in the past, and there's every
> reason to believe that it will cause significant confusion in the
> future. Replace it with something else.
>
> /a
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--000000000000c0e96805c7030268
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


*sigh* This should have gone to the list.=C2=A0 Mike

=
---------- Forwarded message ---------
From: StJohns, Michael <msj@nthpermutation.com><=
br>Date: Tue, Jul 13, 2021 at 01:23
Subject: Re: [Rfced-future] Issue 24=
: What is the name of the role?
To: Adam Roach <adam@nostrum.com>


=
Hi Adam -=C2=A0

Can you =
point us to an email thread or two where this =E2=80=9Csignificant=E2=80=9D=
 confusion manifested itself? =C2=A0 Ideally one where said confusion had s=
ome material impact on the publication process? =C2=A0 I=E2=80=99m actually=
 surprised to hear this as that seems a topic that would probably drive us =
down a rathole on the IETF mailing list and I don=E2=80=99t remember such a=
 thing. =C2=A0

In any ev=
ent, an editor does not necessarily edit - a 30 second perusal of a diction=
ary should have been sufficient to clear up any=C2=A0confusion. =C2=A0

Thanks Mike




On =
Tue, Jul 13, 2021 at 00:55 Adam Roach <adam@nostrum.com> wrote:
On 7/12/2021 11:58 AM, Bob Hinden wrote:

> Changing it the =E2=80=9CRFC Series Advisor=E2=80=9D will cause consid=
erable confusion in the larger community.





On the contrary, I believe it will clear up a long-running and 

frequently harmful source of major confusion in at least the IETF 

community. There have been a large number of conversations in which it 

became clear that seasoned IETF participants who are otherwise quite 

knowledgeable about the RFC publication process clearly believed that 

Heather actually edited documents.



I don't have a position either way on whether "RSA" is the ri=
ght term, 

but it's something I'm happy to live with. What I *do* know is that=
 

"Editor" has caused significant confusion in the past, and there&=
#39;s every 

reason to believe that it will cause significant confusion in the 

future. Replace it with something else.



/a



-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future






--000000000000c0e96805c7030268--


From nobody Tue Jul 13 08:41:57 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF293A188B for ; Tue, 13 Jul 2021 08:41:55 -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=nthpermutation-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 d2_jl6YLikId for ; Tue, 13 Jul 2021 08:41:50 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 692BF3A1886 for ; Tue, 13 Jul 2021 08:41:50 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id y42so51087862lfa.3 for ; Tue, 13 Jul 2021 08:41:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7IGCrMzb2yGDTYjcfdvbCCWS/din/hsqLWnavODRDeU=; b=U1eBoy9/jFub198ZZVwT2PKxRdXp5Or3DM2t7EfgLdABPmNNvESrQOaicam/SY+pBu mO//Tlog8OY5cEiqaXe6/pt/jMscf9VNJwHo8KUZE5TEktHsumngdHZcYCu7sTCVnsqU qmtnrh9NO7IfsZn8XoqeYSTd/boHFyW+EBixAOhEKPWis/IEShHFvbKHpnY38XmTjsRJ TCdgBR03mvNFsV78DQg89j2JCkCIqstGLjJoxPl2VknmdKD2X1KuSjidByIubds6QlbY a3sISkgnwh0YRRy5s2qnwALDob8MuHJawWM5b1CzJsYNmGDIbh5etvGvSVYi3msvMDO3 bzgw==
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=7IGCrMzb2yGDTYjcfdvbCCWS/din/hsqLWnavODRDeU=; b=S+tf91ebfwI9okbFPUJbg5+FFeQ+OIR4qLNOUr0i5yP/biT0xhV8OHL/F2grarkY2w 0dudF4PLzPTrH2ZeLAqai8Z7L2Pxx5Txgh9lQ2144SjNu8b6RTcQpokrC4UVAA9YU/Oo SztbTVD5LHvUzZ1V0CNGEjPVwb9Cma/2jqjCyvHRLcUfkwRyWz+vdPEPIpagda/XiE4n sTlSOPUPySO8sIOJT+3iuwuWiPHmhaVX4kPwSVf2hvRjO62kHidJ75sX/B+XyBBENIak 0zPmT1dfwNdxu2F6mHxBeWCo8W+zK0g+O8C2CiBpozrrf0PfWpWECeRiilPg80BzX90o jlvg==
X-Gm-Message-State: AOAM532VJOu7p7s1vG9vyEZaFsU5B7GtbHRcuhqmivHWqBVhQneFYd+B Nb8anXLO2MhOib0oNAjXSYraIdBlXuvZv/Rk3SJBnQ==
X-Google-Smtp-Source: ABdhPJwe6m1B3ZsuuFi3s2gxFvZc7+aqw9AC2d2aIRE7qgou86peQ53sAdHmH1N13vwWho3X9QoEa+1iotf/dtMJDa0=
X-Received: by 2002:ac2:54a4:: with SMTP id w4mr4119826lfk.344.1626190907331;  Tue, 13 Jul 2021 08:41:47 -0700 (PDT)
MIME-Version: 1.0
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>  
In-Reply-To: 
From: "StJohns, Michael" 
Date: Tue, 13 Jul 2021 11:41:36 -0400
Message-ID: 
To: Peter Saint-Andre 
Cc: Bob Hinden , Brian E Carpenter , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000005e681405c7031332"
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 15:41:56 -0000

--0000000000005e681405c7031332
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter.

National Security Advisor, like RFC Series Editor has a history that
associates a level of significance to the role, even with the term advisor
in the title.   That applies also to Secretary of State, etc.  So your
argument by comparison doesn=E2=80=99t actually point to changing the name.

I think you=E2=80=99re going to have problems finding consensus to change t=
he
name.  Unfortunately, we may also have a problem finding consensus to keep
the name.

Mike

On Tue, Jul 13, 2021 at 11:34 Peter Saint-Andre  wrote=
:

> We seem to speculate with fair frequency about the titles that will make
> it possible to attract candidates for the role of technical publishing
> expert within version 3 of the model. I'm not so sure how important that
> is (after all, a role like the National Security Advisor in the U.S.
> government is perceived as significant even though it has "advisor" in
> the name); what might matter most is the actual activities the person
> will perform, the respect accorded to the role, the perceived importance
> of the RFC Series, etc.
>
> Peter
>
> On 7/12/21 10:29 PM, StJohns, Michael wrote:
> > I don't think so.  I=E2=80=99m not even sure we could get anyone to app=
ly for
> > something with that job title.  Mike
> >
> > On Tue, Jul 13, 2021 at 00:11 Brian E Carpenter
> > >
> wrote:
> >
> >     Could we compromise on "RFC Series Advisory Editor"?
> >
> >     The term is used quite widely and it even seems accurate.
> >
> >     Regards
> >        Brian Carpenter
> >
> >     On 13-Jul-21 16:00, Bob Hinden wrote:
> >     > Brian,
> >     >
> >     >> On Jul 12, 2021, at 7:52 PM, Brian E Carpenter
> >     >
> >     wrote:
> >     >>
> >     >> I don't think there is any proposal to retire the term "RFC
> Editor".
> >     >> But for many years it has referred to the function as well as to
> >     >> the figurehead. RFC2850 refers to "an organization to act as
> >     >> RFC Editor" because even in May 2000 it wasn't a person, althoug=
h
> >     >> Bob Braden led the team. And also "The Internet Society, the RFC
> >     Editor,
> >     >> the IANA and the IESG each appoints a liaison member to the IAB.=
"
> >     >>
> >     >> Given the job description and role of the RSEA, I really don't s=
ee
> >     >> how we can call the person an editor.
> >     >
> >     > Think about it like positions in the US called =E2=80=9CSecretary=
 of
> >     State=E2=80=9D, see:
> >     >
> >     > https://www.state.gov/secretary/  >
> >     >
> >     > They are not performing secretarial duties.
> >     >
> >     > Bob
> >     >
> >     >
> >     >>
> >     >> Regards
> >     >>   Brian Carpenter
> >     >>
> >     >> On 13-Jul-21 05:20, Michael StJohns wrote:
> >     >>> Bob said it better than I can.   Mike
> >     >>>
> >     >>> On 7/12/2021 12:58 PM, Bob Hinden wrote:
> >     >>>> Hi,
> >     >>>>
> >     >>>>> On Jul 9, 2021, at 2:03 PM, Peter Saint-Andre
> >     >
> >     wrote:
> >     >>>>>
> >     >>>>> The role played by the technical publishing expert in version
> >     3 of the
> >     >>>>> model is different enough from past roles that I suggest we
> >     should not
> >     >>>>> use the name "RFC Series Editor" but instead "RFC Series
> Advisor=E2=80=9D.
> >     >>>> I strongly disagree.
> >     >>>>
> >     >>>> The RFC Editor role has changed multiple times in the past in
> >     many ways and we still call it the RFC Editor.
> >     >>>>
> >     >>>> This includes:
> >     >>>>
> >     >>>> Administrative support and direction changed from Defense
> >     Advanced Project Agency (DARPA), the Internet Society, IAOC, and
> >     currently the IETF
> >     LLC.
> >     >>>>
> >     >>>> It has been performed by Jon Postel, Bob Braden, Joyce
> >     Reynolds, Glenn
> >     >> Kowack, Olaf Kolkman, and Heather Flanagan.
> >     >>>>
> >     >>>> Actual editing has transitioned from an individual to a
> >     contracted company.
> >     >>>>
> >     >>>> The scope and the context of this position has changed as the
> >     administration and the person doing the job changed.   It has great
> >     name recognition.   I don=E2=80=99t see any reason why what we are =
defining
> >     now can not be called the RFC Editor.   Changing it the =E2=80=9CRF=
C Series
> >     Advisor=E2=80=9D will cause considerable confusion in the larger co=
mmunity.
> >     >>>>
> >     >>>> Bob
> >     >>>>
> >     >>>>
> >     >>>>
> >     >>>
> >     >>>
> >     >>
> >     >> --
> >     >> Rfced-future mailing list
> >     >> Rfced-future@iab.org 
> >     >> https://www.iab.org/mailman/listinfo/rfced-future
> >     
> >     >
> >
> >
>

--0000000000005e681405c7031332
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Peter.=C2=A0

National Security Advisor, like RFC Series Editor has a history t=
hat associates a level of significance to the role, even with the term advi=
sor in the title. =C2=A0 That applies also to Secretary of State, etc.=C2=
=A0 So your argument by comparison doesn=E2=80=99t actually point to changi=
ng the name. =C2=A0

I th=
ink you=E2=80=99re going to have problems finding consensus to change the n=
ame.=C2=A0 Unfortunately, we may also have a problem finding consensus to k=
eep the name. =C2=A0=C2=A0

Mike

On Tue, Jul 13, 2021 at 11:34 Peter Saint-Andre <stpeter@mozilla.com> wrote:
We seem to speculate with fair frequency about =
the titles that will make

it possible to attract candidates for the role of technical publishing

expert within version 3 of the model. I'm not so sure how important tha=
t

is (after all, a role like the National Security Advisor in the U.S.

government is perceived as significant even though it has "advisor&quo=
t; in

the name); what might matter most is the actual activities the person

will perform, the respect accorded to the role, the perceived importance
of the RFC Series, etc.



Peter



On 7/12/21 10:29 PM, StJohns, Michael wrote:

> I don't think so.=C2=A0 I=E2=80=99m not even sure we could get any=
one to apply for

> something with that job title.=C2=A0 Mike

> 

> On Tue, Jul 13, 2021 at 00:11 Brian E Carpenter

> <b=
rian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wro=
te:

> 

>=C2=A0 =C2=A0 =C2=A0Could we compromise on "RFC Series Advisory Ed=
itor"?

> 

>=C2=A0 =C2=A0 =C2=A0The term is used quite widely and it even seems acc=
urate.

> 

>=C2=A0 =C2=A0 =C2=A0Regards

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian Carpenter

> 

>=C2=A0 =C2=A0 =C2=A0On 13-Jul-21 16:00, Bob Hinden wrote:

>=C2=A0 =C2=A0 =C2=A0> Brian,

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>> On Jul 12, 2021, at 7:52 PM, Brian E Carpe=
nter

>=C2=A0 =C2=A0 =C2=A0<brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.=
com>>

>=C2=A0 =C2=A0 =C2=A0wrote:

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> I don't think there is any proposal to=
 retire the term "RFC Editor".

>=C2=A0 =C2=A0 =C2=A0>> But for many years it has referred to the =
function as well as to

>=C2=A0 =C2=A0 =C2=A0>> the figurehead. RFC2850 refers to "an=
 organization to act as

>=C2=A0 =C2=A0 =C2=A0>> RFC Editor" because even in May 2000 =
it wasn't a person, although

>=C2=A0 =C2=A0 =C2=A0>> Bob Braden led the team. And also "Th=
e Internet Society, the RFC

>=C2=A0 =C2=A0 =C2=A0Editor,

>=C2=A0 =C2=A0 =C2=A0>> the IANA and the IESG each appoints a liai=
son member to the IAB."

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> Given the job description and role of the =
RSEA, I really don't see

>=C2=A0 =C2=A0 =C2=A0>> how we can call the person an editor.

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> Think about it like positions in the US called=
 =E2=80=9CSecretary of

>=C2=A0 =C2=A0 =C2=A0State=E2=80=9D, see:

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> https://www.state.gov/secretary/ &l=
t;https://www.state.gov/secretary/>

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> They are not performing secretarial duties.
>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> Bob

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> Regards

>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0Brian Carpenter

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> On 13-Jul-21 05:20, Michael StJohns wrote:=


>=C2=A0 =C2=A0 =C2=A0>>> Bob said it better than I can.=C2=A0 =
=C2=A0Mike

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> On 7/12/2021 12:58 PM, Bob Hinden wrot=
e:

>=C2=A0 =C2=A0 =C2=A0>>>> Hi,

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> On Jul 9, 2021, at 2:03 PM, Pe=
ter Saint-Andre

>=C2=A0 =C2=A0 =C2=A0<stpeter@mozilla.com <mailto:stpeter@mozilla.com>>

>=C2=A0 =C2=A0 =C2=A0wrote:

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> The role played by the technic=
al publishing expert in version

>=C2=A0 =C2=A0 =C2=A03 of the

>=C2=A0 =C2=A0 =C2=A0>>>>> model is different enough from=
 past roles that I suggest we

>=C2=A0 =C2=A0 =C2=A0should not

>=C2=A0 =C2=A0 =C2=A0>>>>> use the name "RFC Series =
Editor" but instead "RFC Series Advisor=E2=80=9D.

>=C2=A0 =C2=A0 =C2=A0>>>> I strongly disagree.

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> The RFC Editor role has changed mu=
ltiple times in the past in

>=C2=A0 =C2=A0 =C2=A0many ways and we still call it the RFC Editor.

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> This includes:

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> Administrative support and directi=
on changed from Defense

>=C2=A0 =C2=A0 =C2=A0Advanced Project Agency (DARPA), the Internet Socie=
ty, IAOC, and

>=C2=A0 =C2=A0 =C2=A0currently the IETF

>=C2=A0 =C2=A0 =C2=A0LLC.

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> It has been performed by Jon Poste=
l, Bob Braden, Joyce

>=C2=A0 =C2=A0 =C2=A0Reynolds, Glenn

>=C2=A0 =C2=A0 =C2=A0>> Kowack, Olaf Kolkman, and Heather Flanagan=
.

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> Actual editing has transitioned fr=
om an individual to a

>=C2=A0 =C2=A0 =C2=A0contracted company.

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> The scope and the context of this =
position has changed as the

>=C2=A0 =C2=A0 =C2=A0administration and the person doing the job changed=
.=C2=A0 =C2=A0It has great

>=C2=A0 =C2=A0 =C2=A0name recognition.=C2=A0 =C2=A0I don=E2=80=99t see a=
ny reason why what we are defining

>=C2=A0 =C2=A0 =C2=A0now can not be called the RFC Editor.=C2=A0 =C2=A0C=
hanging it the =E2=80=9CRFC Series

>=C2=A0 =C2=A0 =C2=A0Advisor=E2=80=9D will cause considerable confusion =
in the larger community.

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> Bob

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> --

>=C2=A0 =C2=A0 =C2=A0>> Rfced-future mailing list

>=C2=A0 =C2=A0 =C2=A0>> Rfced-future@iab.org <mailto:Rfced-future@iab.org>

>=C2=A0 =C2=A0 =C2=A0>> https://www.iab.or=
g/mailman/listinfo/rfced-future

>=C2=A0 =C2=A0 =C2=A0<https://www.iab.org/mai=
lman/listinfo/rfced-future>

>=C2=A0 =C2=A0 =C2=A0>

> 

> 




--0000000000005e681405c7031332--


From nobody Tue Jul 13 09:26:41 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D1D3A0365 for ; Tue, 13 Jul 2021 09:26:39 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yje87t1W07fM for ; Tue, 13 Jul 2021 09:26:37 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (smtp.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F313A0332 for ; Tue, 13 Jul 2021 09:26:37 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GPQxl1wQ7z31j7; Tue, 13 Jul 2021 18:26:35 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann 
In-Reply-To: 
Date: Tue, 13 Jul 2021 18:26:34 +0200
X-Mao-Original-Outgoing-Id: 647886394.8507-e513902a9e20f0dab50ba3a0cc21deac
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>   
To: rfced-future@iab.org
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 16:26:39 -0000

> National Security Advisor

That is an advisor to the President, an Important Person.

To which Important Person would the RSA advise?
The IETF President?

Gr=C3=BC=C3=9Fe, Carsten


From nobody Tue Jul 13 09:36:32 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EE83A0813 for ; Tue, 13 Jul 2021 09:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level: 
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrcU2o20S-U1 for ; Tue, 13 Jul 2021 09:36:24 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 2C5943A07FA for ; Tue, 13 Jul 2021 09:36:23 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1004::18c] ([IPv6:2001:420:c0c0:1004:0:0:0:18c]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16DGaC4o215784 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 13 Jul 2021 18:36:13 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626194175; bh=yx41KpLfiHo/+LtFVqcVxYKEGS+Wnv1tyWJVVrMMsvo=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=VVD0xAEb/dELOgNqUS0yLTmOTUDqolAcNGegIQpnG1NHLH3Q2SOtw7o3fsFkCgo+w mrGGvCGlPovTztkREA6ATx6bbWIbH6qJEnKoVKVvUypE7j5cAlQJjGK0/83LdXElYe bl8U5soAaiFoKDq6X/1gDUwdeIVwDWTjSUCAu7/w=
To: "StJohns, Michael" , Peter Saint-Andre 
Cc: rfced-future@iab.org, Bob Hinden 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>   
From: Eliot Lear 
Message-ID: <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch>
Date: Tue, 13 Jul 2021 18:36:11 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Dgk4feqSj79xbymFt5jly1DR3Yi44Xn0k"
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 16:36:30 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Dgk4feqSj79xbymFt5jly1DR3Yi44Xn0k
Content-Type: multipart/mixed; boundary="YEmkROUraFSmQtEcOP25AUYmKNZDmzvOB";
 protected-headers="v1"
From: Eliot Lear 
To: "StJohns, Michael" ,
 Peter Saint-Andre 
Cc: rfced-future@iab.org, Bob Hinden 
Message-ID: <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch>
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
References: 
 
 <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com>
 <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com>
 <02994423-D9CB-4996-B831-E87900EC9250@gmail.com>
 <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>
 
 
 
In-Reply-To: 

--YEmkROUraFSmQtEcOP25AUYmKNZDmzvOB
Content-Type: multipart/alternative;
 boundary="------------11A30D5AFBA0B1D1C3C84DFA"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------11A30D5AFBA0B1D1C3C84DFA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Ok, this seems like a good time to try to catalog the arguments. Please=20
correct me or add:

RSE

  * Brand name value for hiring purposes
  * RSA not a term of art

RSA

  * Because there is no direct editorial control, the term advisor is
    more accurate.=C2=A0 Let's not confuse the community.

All of these are rebuttable points.=C2=A0 I would suggest that more=20
information about how prospective applicants or people from that=20
profession would view the role would help us [in]validate the first two=20
bullets.=C2=A0 Would people like that input?

Eliot

On 13.07.21 17:41, StJohns, Michael wrote:
> Hi Peter.
>
> National Security Advisor, like RFC Series Editor has a history that=20
> associates a level of significance to the role, even with the term=20
> advisor in the title. =C2=A0 That applies also to Secretary of State, e=
tc.=C2=A0=20
> So your argument by comparison doesn=E2=80=99t actually point to changi=
ng the=20
> name.
>
> I think you=E2=80=99re going to have problems finding consensus to chan=
ge the=20
> name.=C2=A0 Unfortunately, we may also have a problem finding consensus=
 to=20
> keep the name.
>
> Mike
>
> On Tue, Jul 13, 2021 at 11:34 Peter Saint-Andre  > wrote:
>
>     We seem to speculate with fair frequency about the titles that
>     will make
>     it possible to attract candidates for the role of technical publish=
ing
>     expert within version 3 of the model. I'm not so sure how
>     important that
>     is (after all, a role like the National Security Advisor in the U.S=
=2E
>     government is perceived as significant even though it has "advisor"=
 in
>     the name); what might matter most is the actual activities the pers=
on
>     will perform, the respect accorded to the role, the perceived
>     importance
>     of the RFC Series, etc.
>
>     Peter
>
>     On 7/12/21 10:29 PM, StJohns, Michael wrote:
>     > I don't think so.=C2=A0 I=E2=80=99m not even sure we could get an=
yone to
>     apply for
>     > something with that job title.=C2=A0 Mike
>     >
>     > On Tue, Jul 13, 2021 at 00:11 Brian E Carpenter
>     >      
>          >> wrote:
>     >
>     >=C2=A0 =C2=A0 =C2=A0Could we compromise on "RFC Series Advisory Ed=
itor"?
>     >
>     >=C2=A0 =C2=A0 =C2=A0The term is used quite widely and it even seem=
s accurate.
>     >
>     >=C2=A0 =C2=A0 =C2=A0Regards
>     >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian Carpenter
>     >
>     >=C2=A0 =C2=A0 =C2=A0On 13-Jul-21 16:00, Bob Hinden wrote:
>     >=C2=A0 =C2=A0 =C2=A0> Brian,
>     >=C2=A0 =C2=A0 =C2=A0>
>     >=C2=A0 =C2=A0 =C2=A0>> On Jul 12, 2021, at 7:52 PM, Brian E Carpen=
ter
>     >=C2=A0 =C2=A0 =C2=A0     
>          >>
>     >=C2=A0 =C2=A0 =C2=A0wrote:
>     >=C2=A0 =C2=A0 =C2=A0>>
>     >=C2=A0 =C2=A0 =C2=A0>> I don't think there is any proposal to reti=
re the term
>     "RFC Editor".
>     >=C2=A0 =C2=A0 =C2=A0>> But for many years it has referred to the f=
unction as
>     well as to
>     >=C2=A0 =C2=A0 =C2=A0>> the figurehead. RFC2850 refers to "an organ=
ization to act as
>     >=C2=A0 =C2=A0 =C2=A0>> RFC Editor" because even in May 2000 it was=
n't a person,
>     although
>     >=C2=A0 =C2=A0 =C2=A0>> Bob Braden led the team. And also "The Inte=
rnet Society,
>     the RFC
>     >=C2=A0 =C2=A0 =C2=A0Editor,
>     >=C2=A0 =C2=A0 =C2=A0>> the IANA and the IESG each appoints a liais=
on member to
>     the IAB."
>     >=C2=A0 =C2=A0 =C2=A0>>
>     >=C2=A0 =C2=A0 =C2=A0>> Given the job description and role of the R=
SEA, I really
>     don't see
>     >=C2=A0 =C2=A0 =C2=A0>> how we can call the person an editor.
>     >=C2=A0 =C2=A0 =C2=A0>
>     >=C2=A0 =C2=A0 =C2=A0> Think about it like positions in the US call=
ed =E2=80=9CSecretary of
>     >=C2=A0 =C2=A0 =C2=A0State=E2=80=9D, see:
>     >=C2=A0 =C2=A0 =C2=A0>
>     >=C2=A0 =C2=A0 =C2=A0> https://www.state.gov/secretary/
>     
>     >
>     >=C2=A0 =C2=A0 =C2=A0>
>     >=C2=A0 =C2=A0 =C2=A0> They are not performing secretarial duties.
>     >=C2=A0 =C2=A0 =C2=A0>
>     >=C2=A0 =C2=A0 =C2=A0> Bob
>     >=C2=A0 =C2=A0 =C2=A0>
>     >=C2=A0 =C2=A0 =C2=A0>
>     >=C2=A0 =C2=A0 =C2=A0>>
>     >=C2=A0 =C2=A0 =C2=A0>> Regards
>     >=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0Brian Carpenter
>     >=C2=A0 =C2=A0 =C2=A0>>
>     >=C2=A0 =C2=A0 =C2=A0>> On 13-Jul-21 05:20, Michael StJohns wrote:
>     >=C2=A0 =C2=A0 =C2=A0>>> Bob said it better than I can.=C2=A0 =C2=A0=
Mike
>     >=C2=A0 =C2=A0 =C2=A0>>>
>     >=C2=A0 =C2=A0 =C2=A0>>> On 7/12/2021 12:58 PM, Bob Hinden wrote:
>     >=C2=A0 =C2=A0 =C2=A0>>>> Hi,
>     >=C2=A0 =C2=A0 =C2=A0>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>>> On Jul 9, 2021, at 2:03 PM, Peter Saint-=
Andre
>     >=C2=A0 =C2=A0 =C2=A0
>     >>
>     >=C2=A0 =C2=A0 =C2=A0wrote:
>     >=C2=A0 =C2=A0 =C2=A0>>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>>> The role played by the technical publish=
ing expert in
>     version
>     >=C2=A0 =C2=A0 =C2=A03 of the
>     >=C2=A0 =C2=A0 =C2=A0>>>>> model is different enough from past role=
s that I
>     suggest we
>     >=C2=A0 =C2=A0 =C2=A0should not
>     >=C2=A0 =C2=A0 =C2=A0>>>>> use the name "RFC Series Editor" but ins=
tead "RFC
>     Series Advisor=E2=80=9D.
>     >=C2=A0 =C2=A0 =C2=A0>>>> I strongly disagree.
>     >=C2=A0 =C2=A0 =C2=A0>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>> The RFC Editor role has changed multiple =
times in the
>     past in
>     >=C2=A0 =C2=A0 =C2=A0many ways and we still call it the RFC Editor.=

>     >=C2=A0 =C2=A0 =C2=A0>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>> This includes:
>     >=C2=A0 =C2=A0 =C2=A0>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>> Administrative support and direction chan=
ged from Defense
>     >=C2=A0 =C2=A0 =C2=A0Advanced Project Agency (DARPA), the Internet =
Society, IAOC, and
>     >=C2=A0 =C2=A0 =C2=A0currently the IETF
>     >=C2=A0 =C2=A0 =C2=A0LLC.
>     >=C2=A0 =C2=A0 =C2=A0>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>> It has been performed by Jon Postel, Bob =
Braden, Joyce
>     >=C2=A0 =C2=A0 =C2=A0Reynolds, Glenn
>     >=C2=A0 =C2=A0 =C2=A0>> Kowack, Olaf Kolkman, and Heather Flanagan.=

>     >=C2=A0 =C2=A0 =C2=A0>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>> Actual editing has transitioned from an i=
ndividual to a
>     >=C2=A0 =C2=A0 =C2=A0contracted company.
>     >=C2=A0 =C2=A0 =C2=A0>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>> The scope and the context of this positio=
n has changed
>     as the
>     >=C2=A0 =C2=A0 =C2=A0administration and the person doing the job ch=
anged.=C2=A0 =C2=A0It
>     has great
>     >=C2=A0 =C2=A0 =C2=A0name recognition.=C2=A0 =C2=A0I don=E2=80=99t =
see any reason why what we are
>     defining
>     >=C2=A0 =C2=A0 =C2=A0now can not be called the RFC Editor.=C2=A0 =C2=
=A0Changing it the =E2=80=9CRFC
>     Series
>     >=C2=A0 =C2=A0 =C2=A0Advisor=E2=80=9D will cause considerable confu=
sion in the larger
>     community.
>     >=C2=A0 =C2=A0 =C2=A0>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>> Bob
>     >=C2=A0 =C2=A0 =C2=A0>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>
>     >=C2=A0 =C2=A0 =C2=A0>>>
>     >=C2=A0 =C2=A0 =C2=A0>>
>     >=C2=A0 =C2=A0 =C2=A0>> --
>     >=C2=A0 =C2=A0 =C2=A0>> Rfced-future mailing list
>     >=C2=A0 =C2=A0 =C2=A0>> Rfced-future@iab.org 
>     >
>     >=C2=A0 =C2=A0 =C2=A0>> https://www.iab.org/mailman/listinfo/rfced-=
future
>     
>     >=C2=A0 =C2=A0 =C2=A0     >
>     >=C2=A0 =C2=A0 =C2=A0>
>     >
>     >
>
>

--------------11A30D5AFBA0B1D1C3C84DFA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Ok, this seems like a good time to try to catalog the arguments.=C2=
=A0
      Please correct me or add:

    
RSE

    
    
      
  • Brand name value for hiring purposes
    • 
      
  • RSA not a term of art
    
      
    • 
    

    
RSA

    
    
      
  • Because there is no direct editorial control, the term advisor
        is more accurate.=C2=A0 Let's not confuse the community.
    
      
    • 
    

    
All of these are rebuttable points.=C2=A0 I would suggest that mor=
e
      information about how prospective applicants or people from that
      profession would view the role would help us [in]validate the
      first two bullets.=C2=A0 Would people like that input?

    
Eliot

    

    
On 13.07.21 17:41, StJohns, Michael
      wrote:

    

    

      
      
Hi Peter.=C2=A0

      


      

      
National Security Advisor, like RFC Series Editor=

        has a history that associates a level of significance to the
        role, even with the term advisor in the title. =C2=A0 That applie=
s
        also to Secretary of State, etc.=C2=A0 So your argument by compar=
ison
        doesn=E2=80=99t actually point to changing the name. =C2=A0
=

      


      

      
I think you=E2=80=99re going to have problems fin=
ding
        consensus to change the name.=C2=A0 Unfortunately, we may also ha=
ve a
        problem finding consensus to keep the name. =C2=A0=C2=A0

      


      

      
Mike

      


        

          
On Tue, Jul 13, 2021 at
            11:34 Peter Saint-Andre <stpeter@mozilla.com>
            wrote:

          

          
We seem to
            speculate with fair frequency about the titles that will
            make

            it possible to attract candidates for the role of technical
            publishing

            expert within version 3 of the model. I'm not so sure how
            important that

            is (after all, a role like the National Security Advisor in
            the U.S.

            government is perceived as significant even though it has
            "advisor" in

            the name); what might matter most is the actual activities
            the person

            will perform, the respect accorded to the role, the
            perceived importance

            of the RFC Series, etc.

            

            Peter

            

            On 7/12/21 10:29 PM, StJohns, Michael wrote:

            > I don't think so.=C2=A0 I=E2=80=99m not even sure we cou=
ld get
            anyone to apply for

            > something with that job title.=C2=A0 Mike

            > 

            > On Tue, Jul 13, 2021 at 00:11 Brian E Carpenter

            > <brian.e.carpente=
r@gmail.com
            <mailto:brian.e.carpente=
r@gmail.com>>
            wrote:

            > 

            >=C2=A0 =C2=A0 =C2=A0Could we compromise on "RFC Series Ad=
visory
            Editor"?

            > 

            >=C2=A0 =C2=A0 =C2=A0The term is used quite widely and it =
even seems
            accurate.

            > 

            >=C2=A0 =C2=A0 =C2=A0Regards

            >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian Carpenter

            > 

            >=C2=A0 =C2=A0 =C2=A0On 13-Jul-21 16:00, Bob Hinden wrote:=


            >=C2=A0 =C2=A0 =C2=A0> Brian,

            >=C2=A0 =C2=A0 =C2=A0>

            >=C2=A0 =C2=A0 =C2=A0>> On Jul 12, 2021, at 7:52 PM,=
 Brian E
            Carpenter

            >=C2=A0 =C2=A0 =C2=A0<brian.e.carpente=
r@gmail.com
            <mailto:brian.e.carpente=
r@gmail.com>>

            >=C2=A0 =C2=A0 =C2=A0wrote:

            >=C2=A0 =C2=A0 =C2=A0>>

            >=C2=A0 =C2=A0 =C2=A0>> I don't think there is any p=
roposal to
            retire the term "RFC Editor".

            >=C2=A0 =C2=A0 =C2=A0>> But for many years it has re=
ferred to the
            function as well as to

            >=C2=A0 =C2=A0 =C2=A0>> the figurehead. RFC2850 refe=
rs to "an
            organization to act as

            >=C2=A0 =C2=A0 =C2=A0>> RFC Editor" because even in =
May 2000 it
            wasn't a person, although

            >=C2=A0 =C2=A0 =C2=A0>> Bob Braden led the team. And=
 also "The
            Internet Society, the RFC

            >=C2=A0 =C2=A0 =C2=A0Editor,

            >=C2=A0 =C2=A0 =C2=A0>> the IANA and the IESG each a=
ppoints a
            liaison member to the IAB."

            >=C2=A0 =C2=A0 =C2=A0>>

            >=C2=A0 =C2=A0 =C2=A0>> Given the job description an=
d role of the
            RSEA, I really don't see

            >=C2=A0 =C2=A0 =C2=A0>> how we can call the person a=
n editor.

            >=C2=A0 =C2=A0 =C2=A0>

            >=C2=A0 =C2=A0 =C2=A0> Think about it like positions in=
 the US called
            =E2=80=9CSecretary of

            >=C2=A0 =C2=A0 =C2=A0State=E2=80=9D, see:

            >=C2=A0 =C2=A0 =C2=A0>

            >=C2=A0 =C2=A0 =C2=A0> https://www.state.gov/secretary/
            <https://www.state.gov/secretary/>

            >=C2=A0 =C2=A0 =C2=A0>

            >=C2=A0 =C2=A0 =C2=A0> They are not performing secretar=
ial duties.

            >=C2=A0 =C2=A0 =C2=A0>

            >=C2=A0 =C2=A0 =C2=A0> Bob

            >=C2=A0 =C2=A0 =C2=A0>

            >=C2=A0 =C2=A0 =C2=A0>

            >=C2=A0 =C2=A0 =C2=A0>>

            >=C2=A0 =C2=A0 =C2=A0>> Regards

            >=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0Brian Carpenter<=
br>
            >=C2=A0 =C2=A0 =C2=A0>>

            >=C2=A0 =C2=A0 =C2=A0>> On 13-Jul-21 05:20, Michael =
StJohns wrote:

            >=C2=A0 =C2=A0 =C2=A0>>> Bob said it better than =
I can.=C2=A0 =C2=A0Mike

            >=C2=A0 =C2=A0 =C2=A0>>>

            >=C2=A0 =C2=A0 =C2=A0>>> On 7/12/2021 12:58 PM, B=
ob Hinden
            wrote:

            >=C2=A0 =C2=A0 =C2=A0>>>> Hi,

            >=C2=A0 =C2=A0 =C2=A0>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>>> On Jul 9, 2021, =
at 2:03 PM,
            Peter Saint-Andre

            >=C2=A0 =C2=A0 =C2=A0<stpeter@mozilla.=
com
            <mailto:stpeter@mozilla.=
com>>

            >=C2=A0 =C2=A0 =C2=A0wrote:

            >=C2=A0 =C2=A0 =C2=A0>>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>>> The role played =
by the
            technical publishing expert in version

            >=C2=A0 =C2=A0 =C2=A03 of the

            >=C2=A0 =C2=A0 =C2=A0>>>>> model is differe=
nt enough from
            past roles that I suggest we

            >=C2=A0 =C2=A0 =C2=A0should not

            >=C2=A0 =C2=A0 =C2=A0>>>>> use the name "RF=
C Series
            Editor" but instead "RFC Series Advisor=E2=80=9D.

            >=C2=A0 =C2=A0 =C2=A0>>>> I strongly disagree.=


            >=C2=A0 =C2=A0 =C2=A0>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>> The RFC Editor role =
has changed
            multiple times in the past in

            >=C2=A0 =C2=A0 =C2=A0many ways and we still call it the RF=
C Editor.

            >=C2=A0 =C2=A0 =C2=A0>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>> This includes:

            >=C2=A0 =C2=A0 =C2=A0>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>> Administrative suppo=
rt and
            direction changed from Defense

            >=C2=A0 =C2=A0 =C2=A0Advanced Project Agency (DARPA), the =
Internet
            Society, IAOC, and

            >=C2=A0 =C2=A0 =C2=A0currently the IETF

            >=C2=A0 =C2=A0 =C2=A0LLC.

            >=C2=A0 =C2=A0 =C2=A0>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>> It has been performe=
d by Jon
            Postel, Bob Braden, Joyce

            >=C2=A0 =C2=A0 =C2=A0Reynolds, Glenn

            >=C2=A0 =C2=A0 =C2=A0>> Kowack, Olaf Kolkman, and He=
ather
            Flanagan.

            >=C2=A0 =C2=A0 =C2=A0>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>> Actual editing has t=
ransitioned
            from an individual to a

            >=C2=A0 =C2=A0 =C2=A0contracted company.

            >=C2=A0 =C2=A0 =C2=A0>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>> The scope and the co=
ntext of this
            position has changed as the

            >=C2=A0 =C2=A0 =C2=A0administration and the person doing t=
he job
            changed.=C2=A0 =C2=A0It has great

            >=C2=A0 =C2=A0 =C2=A0name recognition.=C2=A0 =C2=A0I don=E2=
=80=99t see any reason why what
            we are defining

            >=C2=A0 =C2=A0 =C2=A0now can not be called the RFC Editor.=
=C2=A0 =C2=A0Changing it
            the =E2=80=9CRFC Series

            >=C2=A0 =C2=A0 =C2=A0Advisor=E2=80=9D will cause considera=
ble confusion in the
            larger community.

            >=C2=A0 =C2=A0 =C2=A0>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>> Bob

            >=C2=A0 =C2=A0 =C2=A0>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>>

            >=C2=A0 =C2=A0 =C2=A0>>>

            >=C2=A0 =C2=A0 =C2=A0>>>

            >=C2=A0 =C2=A0 =C2=A0>>

            >=C2=A0 =C2=A0 =C2=A0>> --

            >=C2=A0 =C2=A0 =C2=A0>> Rfced-future mailing list
            >=C2=A0 =C2=A0 =C2=A0>> Rfced-future@iab=
=2Eorg
            <mailto:Rfced-future@iab=
=2Eorg>

            >=C2=A0 =C2=A0 =C2=A0>> https://www.iab.org/mailman/listinfo/rfced-future

            >=C2=A0 =C2=A0 =C2=A0<https://www.iab.org/mailman/listinfo/rfced-future>

            >=C2=A0 =C2=A0 =C2=A0>

            > 

            > 

          

        

      

      

      

    

  


--------------11A30D5AFBA0B1D1C3C84DFA--

--YEmkROUraFSmQtEcOP25AUYmKNZDmzvOB--

--Dgk4feqSj79xbymFt5jly1DR3Yi44Xn0k
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDtwPsFAwAAAAAACgkQh7ZrRtnSejNM
xwf+KPftoK9Jtzqcj4qoHSGCgxg7pgdXt/xWFinzapuX3pc6AzWQQISsN9oZO2H1jpql+BSOBJ+D
ZHvKQm5LZWN2w3lOBL/WZ0yRGSX84+/ZBwHoQys65cxK4PtA2PSY0oFqOO0URyizuTperNsM+00m
UQDmjBXfDt8vLzPJnzrPBRCUjfPF/Xjt48e1+nBZaPstQHLQPi+w9Aj1Ys53s+5BYTnciS0d5BUt
seQVDL/7y7djDqcTUc3NLkj6A2N9uBy2XiKaIyz3aTC89I3ffkbhqDLjbmPD2ETtojohDFj4eAaK
I8G4JA7+5stAUOpdOxxhjmPeSOMlUFOMKL0BpVvJZg==
=gQvh
-----END PGP SIGNATURE-----

--Dgk4feqSj79xbymFt5jly1DR3Yi44Xn0k--


From nobody Tue Jul 13 09:56:39 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D733A3A0CCC for ; Tue, 13 Jul 2021 09:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 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_BLOCKED=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=me.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 E6qothP29xqt for ; Tue, 13 Jul 2021 09:56:31 -0700 (PDT)
Received: from mr85p00im-zteg06011601.me.com (mr85p00im-zteg06011601.me.com [17.58.23.186]) (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 427C03A0CC7 for ; Tue, 13 Jul 2021 09:56:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1626195390; bh=yIJNxHTYOUK++d4XFsK+ulN708mIL44G+DcWCG0eQ5U=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=jJj34ZJbKnP0JWzBvIpsA2PSV0kRkI1hY4wBbUeadHp1DRRZxu15O0FBvYJe+Rqtw jdKT+j47k4s5IMzmmh3k9gc03GpnYl69EcQ+tyiNZr6FHMjysa08l5uGOsqaGlUCZu BwtwKPaur9WoIExfIdeCgNDURCaAo7ZI8u57ud9xVyIYLgSgtDC7V3NLfQd1AuAYTJ C0yH8QJ+D6+5fY5q4Bj2X4NEB5ybxGK4p08/wrH8KWYuvG1RQM+rHNB8KzzpablIl8 cG88+nB2CO3/om84GT8qLB6ANJWMG0yAGvjmC68GfGSsf7U99BuuuPvOoa6xB7Pq2O 4jjsO8hTc6LVw==
Received: from smtpclient.apple (157-131-155-250.fiber.dynamic.sonic.net [157.131.155.250]) by mr85p00im-zteg06011601.me.com (Postfix) with ESMTPSA id 28D5A9209FA; Tue, 13 Jul 2021 16:56:30 +0000 (UTC)
From: Ole Jacobsen 
Message-Id: <7C41B6AA-5DCB-4908-AF6D-41A7D92E7C6A@me.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_36285A84-94C9-41F5-BFE2-03E1318AC2A4"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Tue, 13 Jul 2021 09:56:29 -0700
In-Reply-To: <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch>
Cc: Ole Jacobsen , "StJohns, Michael" , Peter Saint-Andre , rfced-future@iab.org, Bob Hinden 
To: Eliot Lear 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>    <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-07-13=5F08:2021-07-13=5F03,2021-07-13=5F08,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 suspectscore=0 mlxscore=0 spamscore=0 bulkscore=0 phishscore=0 malwarescore=0 adultscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2107130108
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 16:56:38 -0000

--Apple-Mail=_36285A84-94C9-41F5-BFE2-03E1318AC2A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

Without going into the details of the current model, it might be useful =
to
to look at the original call for RSE candidates that was posted to the =
IETF
list on June 9, 2009 (from Olaf Kolkman). The original message contained =
a
link to an IAOC page with the job description, but sadly that link is =
now
dead [for reference it was: https://iaoc.ietf.org/rfced-procurement.html =
]

However, the message itself is pretty clear on the roles and =
responsibilities
of the RSE, so I would ask: "Are we seeking someone for an entirely =
different
role this time? If not, why change the well-established title?"

Here is the text:


Dear Colleagues,

The Internet Architecture Board (IAB) seeks nominations for the
position of an RFC Series Editor (RSE). The appointee's term will
begin on January 1, 2010. The IAB desires a lengthy relationship
with a successful candidate and would like to structure a 5 year
term with a performance review at the 2 year point and renewal for 3
additional years for successful performance as RSE in an RFC Editor
model. The position is open to all with the requisite knowledge,
skills and experience. The position is not limited to current
participants in the Internet Engineering Task Force. The incumbent
is Bob Braden, who is not seeking another appointment.

The RSE is responsible for:

 1.  Identifying appropriate steps for RFC Series continuity

 2.  Exercising executive-level management over the implementation of
     policies, processes and procedures established to ensure the
     quality and consistency for the RFC Series.  The RFC Series
     Editor will work with the RSAG, and, where appropriate, the IAB
     and IAOC to develop, new policy and see that contractual
     agreements are met.

 3.  Taking proposed changes to the community, and working with the
     IAB so that the IAB can ensure that there is sufficient community
     review before significant policies or policy changes are adopted.

 4.  Coordinating with IAB and/or IAOC, and together with the IAB
     and/or IAOC participating in reviews of the RFC Publisher, RFC
     Publication Center, and Independent Stream Editor functions to
     ensure the above mentioned continuity.

 5.  Developing, maintaining, and publishing the RFC Style Manual
     for use by authors, editors, the stream managers, the RFC
     Production Center and the RFC Publisher.  publication for use
     by authors, editors, and the RFC publisher.

 6.  Managing the RFC errata process.

 7.  Liaising with the IAB.

 8.  Overseeing consistency of RFCs with the RFC Series and RFC Style
     Manual.

 The RFC Series Editor is a senior technology professional with the
 following qualifications:


  1.  Strong understanding of the IETF and RFC process.

  2.  Executive management experience suitable to managing the
      requirements outlined elsewhere in this document and the many
      aspects of this role and to coordinating the overall RFC Editor
      process.

  3.  Good understanding of the English language and technical
      terminology related to the Internet.

  4.  Good communication skills.

  5.  Experience with editorial processes.

  6.  Independent worker.

  7.  Experience as an RFC author desired.

 Nominations are to be submitted to: RSE-Nom@ietf.org in txt format
 no later than 8 July 2009 in the form of the package described
 below. Individuals may nominate themselves. The names of all
 people who declare themselves willing to serve will be made public
 on the ietf-announce at ietf.org and rfc-interest at ietf.org lists
 after the end of the solicitation period. The plan is to post the
 list of willing candidates on 13 July 2009.

A nomination package shall consist of:

 1. Details about the candidate's background and qualifications for the
  position

 2. Explanation of one's view of the role

 3. Recommendations to change the position description, if any

 4. Thoughts about staffing support requirements, if any

 5. Name and contact information for each candidate.

 The list of nominated persons will be made public prior to making a
 decision, allowing time for the community to pass any relevant
 comments.

Interviews will be conducted in person at the IETF 75 meeting in
Stockholm and/or by teleconference before and after the meeting.
Interviews will be conducted by members of an Advisory Committee
appointed by the IAB.  Presence in Stockholm will be at the
individual's own expense. Attendance in Stockholm is optional and
will not be used in the selection criteria.

The Advisory Committee may conduct testing of the candidate
performing the role of the RSE.

The Advisory Committee will submit RSE nominees with its
recommendations to the IAB for its selection and appointment of an
RFC Series Editor.


> On Jul 13, 2021, at 09:36, Eliot Lear  wrote:
>=20
> Ok, this seems like a good time to try to catalog the arguments.  =
Please correct me or add:
>=20
> RSE
>=20
> Brand name value for hiring purposes
> RSA not a term of art
> RSA
>=20
> Because there is no direct editorial control, the term advisor is more =
accurate.  Let's not confuse the community.
> All of these are rebuttable points.  I would suggest that more =
information about how prospective applicants or people from that =
profession would view the role would help us [in]validate the first two =
bullets.  Would people like that input?
>=20
> Eliot
>=20
> On 13.07.21 17:41, StJohns, Michael wrote:


Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocoljournal.org
E-mail: olejacobsen@me.com
E-mail: ole@protocoljournal.org
Skype: organdemo




--Apple-Mail=_36285A84-94C9-41F5-BFE2-03E1318AC2A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi,

Without=
 going into the details of the current model, it might be useful =
to
to look at the original call for RSE candidates =
that was posted to the IETF
list on June 9, 2009 =
(from Olaf Kolkman). The original message contained a
link to an IAOC page with the job description, but sadly that =
link is now
dead [for reference it was: https://iaoc.ietf.org/rfced-procurement.html]

However, the message =
itself is pretty clear on the roles and responsibilities
of the RSE, so I would ask: "Are we seeking someone for an =
entirely different
role this time? If not, why =
change the well-established title?"

Here is the text:


Dear Colleagues,

The Internet Architecture Board (IAB) =
seeks nominations for the
position of an RFC Series =
Editor (RSE). The appointee's term will
begin on =
January 1, 2010. The IAB desires a lengthy relationship
with a successful candidate and would like to structure a 5 =
year
term with a performance review at the 2 year =
point and renewal for 3
additional years for =
successful performance as RSE in an RFC Editor
model.=
 The position is open to all with the requisite knowledge,
skills and experience. The position is not limited to =
current
participants in the Internet Engineering =
Task Force. The incumbent
is Bob Braden, who is not =
seeking another appointment.

The RSE is responsible for:

 1. =
 Identifying appropriate steps for RFC Series continuity

 2. =
 Exercising executive-level management over the implementation =
of
     policies, processes and =
procedures established to ensure the
    =
 quality and consistency for the RFC Series.  The RFC =
Series
     Editor will work with =
the RSAG, and, where appropriate, the IAB
  =
   and IAOC to develop, new policy and see that =
contractual
     agreements are =
met.

 3. =
 Taking proposed changes to the community, and working with =
the
     IAB so that the IAB can =
ensure that there is sufficient community
  =
   review before significant policies or policy changes are =
adopted.

 4.  Coordinating with IAB and/or IAOC, and =
together with the IAB
     and/or =
IAOC participating in reviews of the RFC Publisher, RFC
     Publication Center, and Independent =
Stream Editor functions to
    =
 ensure the above mentioned continuity.

 5.  Developing, maintaining, =
and publishing the RFC Style Manual
    =
 for use by authors, editors, the stream managers, the =
RFC
     Production Center and the =
RFC Publisher.  publication for use
  =
   by authors, editors, and the RFC publisher.

 6.  Managing =
the RFC errata process.

 7.  Liaising with the IAB.

 8.  Overseeing consistency =
of RFCs with the RFC Series and RFC Style
  =
   Manual.

 The RFC Series Editor is a senior technology =
professional with the
 following =
qualifications:


  1.  Strong =
understanding of the IETF and RFC process.

  2.  Executive management =
experience suitable to managing the
    =
  requirements outlined elsewhere in this document and the =
many
      aspects of this role and =
to coordinating the overall RFC Editor
  =
    process.

  3.  Good understanding of the English language =
and technical
      terminology =
related to the Internet.

  4.  Good communication skills.

  5. =
 Experience with editorial processes.

  6.  Independent =
worker.

  =
7.  Experience as an RFC author desired.

 Nominations are to be submitted =
to: RSE-Nom@ietf.org =
in txt format
 no later than 8 July 2009 in =
the form of the package described
 below. =
Individuals may nominate themselves. The names of all
 people who declare themselves willing to serve will be =
made public
 on the ietf-announce at ietf.org and rfc-interest at ietf.org lists
 after the end of the solicitation period. The plan is =
to post the
 list of willing candidates on 13 =
July 2009.

A =
nomination package shall consist of:

 1. Details about the candidate's =
background and qualifications for the
  =
position

 2. Explanation of one's view of the role

 3. Recommendations =
to change the position description, if any

 4. Thoughts about staffing =
support requirements, if any

 5. Name and contact information =
for each candidate.

 The list of nominated persons will be made public prior =
to making a
 decision, allowing time for the =
community to pass any relevant
 comments.

Interviews will be conducted in person at the IETF 75 meeting =
in
Stockholm and/or by teleconference before and =
after the meeting.
Interviews will be conducted by =
members of an Advisory Committee
appointed by the =
IAB.  Presence in Stockholm will be at the
individual's own expense. Attendance in Stockholm is optional =
and
will not be used in the selection =
criteria.

The =
Advisory Committee may conduct testing of the candidate
performing the role of the RSE.

The Advisory Committee will submit RSE =
nominees with its
recommendations to the IAB for =
its selection and appointment of an
RFC Series =
Editor.


On Jul =
13, 2021, at 09:36, Eliot Lear <lear@lear.ch> wrote:


 =20
    
 =20
  
Ok, this seems like a good time to try =
to catalog the arguments. 
      Please correct me or add:
RSE

    
    
      
  • Brand name value for hiring purposes
    • 
      
  • RSA not a term of art
    
      
    • 
    
RSA

    
    
      
  • Because there is no direct editorial control, the =
term advisor
        is more accurate.  Let's not confuse the community.
    
      
    • 
    
All of these are rebuttable points.  I would =
suggest that more
      information about how prospective applicants or people from that
      profession would view the role would help us [in]validate the
      first two bullets.  Would people like that input?
Eliot

    

    
On 13.07.21 17:41, StJohns, Michael
      wrote:

    

    

Ole J. =
Jacobsen
Editor and Publisher
The Internet =
Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocoljournal.org
E-mail: olejacobsen@me.com
E-mail: ole@protocoljournal.org
Skype: =
organdemo






=

--Apple-Mail=_36285A84-94C9-41F5-BFE2-03E1318AC2A4--


From nobody Tue Jul 13 10:11:24 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7F3A0DD8 for ; Tue, 13 Jul 2021 10:11:23 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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=mozilla.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 EhiG5BOLcv0D for ; Tue, 13 Jul 2021 10:11:20 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 5FDBD3A0DD6 for ; Tue, 13 Jul 2021 10:11:20 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id d9so28075516ioo.2 for ; Tue, 13 Jul 2021 10:11:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=aYaI4QcAWTFnx3dFqmQ1z3yHItU2XzSJFI2FTk4JVcE=; b=K37+5pQo5SDXIgHT0hjdjpiDPj6zHJTnBmzKiD5R/CaQm3/Glzxk4Phtm/Wxcrncze 63JDIF77zH3X3UqArWF9tzS3jom2qsW4fouMMIz5ITyenvcsyKyaKmuKsbrJmX8Rg4m7 RVcTPTpqoDk1LvQkWCoz72ygAT0HKXU2WR1jQ=
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=aYaI4QcAWTFnx3dFqmQ1z3yHItU2XzSJFI2FTk4JVcE=; b=etiM5L7tM3lLOS3n1LMW63lGF7OdqqLe5e5gdTuxEm29+7hZEUq0xVlk5srpT0Q97C tTcZ+H2WWmrsgRSSizqOhkp+Y4HBOFHzszGzqQvIiqq25qZVegqJv8cvZXOyQB1e0Zok c8yflTdZwgfRrskQs6kA+G7HPeOEDI5TLl1v2iq1hRFpsD7VWXdg04+3wFyvPqhtxvLS coughzy2lWgi3h2/xARAN4aHo33p48/haKgn0+ssYkukUHbwGtOBADaiPhr2dfFvYxPn 1Syd2XBXj3i62qiesVDZRmuHWDB64mZvXgie1/XnwyGCeL1u55SJIs52QTvJH4hQYtd3 d7fA==
X-Gm-Message-State: AOAM530cJwEzoeYDJj3rq47UuQIoedaUT080QsqWQXK3xSUeJr48a3o4 cl/xI9XiMftqbkXVUSxCMgTM1g==
X-Google-Smtp-Source: ABdhPJwLM44nd+qBF4LtTx2oH4nIST6HEAmaulOZ1vNUsYH4H0lKhI6ThcMMiT/XE3jVdErCMA6FdA==
X-Received: by 2002:a6b:f41a:: with SMTP id i26mr3939556iog.162.1626196278773;  Tue, 13 Jul 2021 10:11:18 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id t15sm9763424ile.28.2021.07.13.10.11.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 10:11:18 -0700 (PDT)
To: rfced-future@iab.org
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com>
From: Peter Saint-Andre 
Message-ID: <2ed9bc40-b341-fe51-ac04-0b9ccf1f883d@mozilla.com>
Date: Tue, 13 Jul 2021 11:11:16 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 17:11:23 -0000

On 7/12/21 8:52 PM, Brian E Carpenter wrote:
> I don't think there is any proposal to retire the term "RFC Editor".
> But for many years it has referred to the function as well as to
> the figurehead. 

This can indeed be confusing. Consider this text from RFC 4844:

   Originally, there was a single person acting as editor of the RFC
   Series (the RFC Editor).  The task has grown, and the work now
   requires the organized activity of several experts, so there are RFC
   Editors, or an RFC Editor organization.  In time, there may be
   multiple organizations working together to undertake the work
   required by the RFC Series.  For simplicity's sake, and without
   attempting to predict how the role might be subdivided among them,
   this document refers to this collection of experts and organizations
   as the "RFC Editor".

   The RFC Editor is an expert technical editor and series editor,
   acting to support the mission of the RFC Series.  As such, the RFC
   Editor is the implementer handling the editorial management of the
   RFC Series, in accordance with the defined processes.  In addition,
   the RFC Editor is expected to be the expert and prime mover in
   discussions about policies for editing, publishing, and archiving
   RFCs.

The first paragraph says that the RFC Editor is a collection of experts
and organizations. Yet if one were to read the second paragraph in
isolation one couldn't be blamed for concluding that it refers to an
individual person, not a collectivity.

Peter


From nobody Tue Jul 13 10:58:00 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96C83A125D for ; Tue, 13 Jul 2021 10:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 t4Hx7Sacbhtl for ; Tue, 13 Jul 2021 10:57:54 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45923A0FE7 for ; Tue, 13 Jul 2021 10:57:53 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id r125so14925007qkf.1 for ; Tue, 13 Jul 2021 10:57:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=VdJXSjTppufgWWZwqnEzYRNNH6p3TmE80mWDxmd7m+g=; b=1JWzUwhfOO+ARPL7ga3bfphs7X2XUmmBW5fm+5OUAXAlj5kmLvyBvJSN+fS5ms/FQ0 ubI2NPR41MtqYLPzpVkPKPr6FHfWsCrrU3UpzLzkeN7HtUAD4OoLImpjVNu7YA5j6w3E YpYEpXBIgn7KOtFsh6BCMFeb9LDoLIL0oz+pzswQqBN+xzM67AlqWgYU3BjUZYQbrpiU PwbO+yXAQmMd16PwWWfAqYMzO9p+Kb8DIILo2fuD3kCygTMW1xXJpEWJZuRrTAw0SCVE pWeJnkX5iZ5e1QkuekK90c9kPJ6Vs9f26MRZzRqcluYHHDySCtbW9qwc2znDxMzAr4M+ xbJg==
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-transfer-encoding :content-language; bh=VdJXSjTppufgWWZwqnEzYRNNH6p3TmE80mWDxmd7m+g=; b=ZOuEjjlX/pVsrlAKfzT4TvrSD2+mFclEF7oiOwep/EtY9kTt9eqvOWqwYl+6uVh7gP rxBSqX2lnrXpSVvtSrnBJoNmDRwp7S35Qg7uwQuqt3Wkwcd6RcVKrIGFZ7qYig2hRhn0 LCT5U2UqrEoZ4yA8L8MCh2ovXtgKlYLL2WSrI7hs8MrLiPzZ8qF5DJxA/l8kMoEGZ/VC GowbCBHZZ+oLYkIOmM9/3wjG5qhlIDBFj4ZP4Nug6bsw1WnXndOOKuxVamftvV40j9LL /iUNspEjgIzH8jIWBRCHWsPcX/49ak0jg+Gg0US/nlGA20K/k2lv/j/VR16UC6rIDPvB O0Kw==
X-Gm-Message-State: AOAM533iDpCHRaj4M7b8JFT1fgqZ+uo5Wv1md0BLCJde8uUy77awN2mX FH92JaSyZll8IYhmqwWDNf3YC3toyOJhGTzR1Us=
X-Google-Smtp-Source: ABdhPJy06sCu3OuF+eKm5vUk/nzScfYN/Kfr53RkOPAjj6gdTVNoP2KqKLcBmPKlzsvytUcrminzBQ==
X-Received: by 2002:a37:641:: with SMTP id 62mr5370570qkg.149.1626199070969; Tue, 13 Jul 2021 10:57:50 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id a17sm8045701qkk.121.2021.07.13.10.57.49 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 10:57:50 -0700 (PDT)
To: rfced-future@iab.org
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <2ed9bc40-b341-fe51-ac04-0b9ccf1f883d@mozilla.com>
From: Michael StJohns 
Message-ID: <8ff476a0-e04d-9a01-3cf4-4bc9dad86784@nthpermutation.com>
Date: Tue, 13 Jul 2021 13:57:48 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <2ed9bc40-b341-fe51-ac04-0b9ccf1f883d@mozilla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 17:57:59 -0000

On 7/13/2021 1:11 PM, Peter Saint-Andre wrote:
> On 7/12/21 8:52 PM, Brian E Carpenter wrote:
>> I don't think there is any proposal to retire the term "RFC Editor".
>> But for many years it has referred to the function as well as to
>> the figurehead.
> This can indeed be confusing. Consider this text from RFC 4844:
>
>     Originally, there was a single person acting as editor of the RFC
>     Series (the RFC Editor).  The task has grown, and the work now
>     requires the organized activity of several experts, so there are RFC
>     Editors, or an RFC Editor organization.  In time, there may be
                                                          ^^^^^^^
>     multiple organizations working together to undertake the work
>     required by the RFC Series.  For simplicity's sake, and without
>     attempting to predict how the role might be subdivided among them,
>     this document refers to this collection of experts and organizations
>     as the "RFC Editor".
Because that was shorter than "RFC Editor or RFC Editor Organization"
>
>     The RFC Editor is an expert technical editor and series editor,
>     acting to support the mission of the RFC Series.  As such, the RFC
>     Editor is the implementer handling the editorial management of the
>     RFC Series, in accordance with the defined processes.  In addition,
>     the RFC Editor is expected to be the expert and prime mover in
>     discussions about policies for editing, publishing, and archiving
>     RFCs.
>
> The first paragraph says that the RFC Editor is a collection of experts
> and organizations. Yet if one were to read the second paragraph in
> isolation one couldn't be blamed for concluding that it refers to an
> individual person, not a collectivity.

 From context, it is clear that this second paragraph refers to the 
individual.  And running through the document, some (most?) instances of 
RFC Editor refer contextually to the individual rather than the 
organization.

Might be worthwhile to ask Leslie to chime in...

Mike


>
> Peter
>


From nobody Tue Jul 13 11:32:25 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E853A07F7; Tue, 13 Jul 2021 11:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level: 
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZGqmpvt7JO6; Tue, 13 Jul 2021 11:32:20 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 634483A07E6; Tue, 13 Jul 2021 11:32:19 -0700 (PDT)
Received: from Zephyrus.local (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16DIW79s053706 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 13 Jul 2021 13:32:08 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1626201129; bh=R+QuypqqnmBlEwCMaEkekaddgvVjLim+TREUA0C9WF0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=XNQeqYqEnkDXRxcTAbrBwXXbQHiUUbSd4FBni+yDZ2vly8A7AP3BVmQsso6KJvrLd k+DvxgyMnoJyj9vf/VLUkKRU3qlCm7GrZOT0t8wrY60AafD14uV+okMW06wjTBnbFs YxD2wsd7SKKdEKV+kNA9A4mz4KU8rgYhms0rBOhI=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be Zephyrus.local
To: Ole Jacobsen , Eliot Lear 
Cc: rfced-future@iab.org, Bob Hinden , Peter Saint-Andre , Ole Jacobsen , "StJohns, Michael" 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>    <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch> <7C41B6AA-5DCB-4908-AF6D-41A7D92E7C6A@me.com>
From: Adam Roach 
Message-ID: 
Date: Tue, 13 Jul 2021 13:32:02 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <7C41B6AA-5DCB-4908-AF6D-41A7D92E7C6A@me.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 18:32:25 -0000

On 7/13/21 11:56, Ole Jacobsen wrote:
> Are we seeking someone for an entirely different role this time?


I *think* so, depending on how rigorously you intend to apply "entirely."

/a


From nobody Tue Jul 13 11:39:14 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1458F3A0924 for ; Tue, 13 Jul 2021 11:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.891
X-Spam-Level: 
X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gRHkxg2cH-7 for ; Tue, 13 Jul 2021 11:39:08 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 7C7B23A091F for ; Tue, 13 Jul 2021 11:39:08 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1004::18c] ([IPv6:2001:420:c0c0:1004:0:0:0:18c]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16DId23d216814 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 13 Jul 2021 20:39:03 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626201544; bh=v/3vfPzOa2kN1CRzKzAit5r7sQI3N9VjtkHx3/HdayI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=PJ1JqhnVUEN7IZ4t15nfb1rxfXVyQaG2EprbTAqrfoybD5c2cgjiBreJ7g5gZBeAc nstoddcLygEhvTvUz2YsjkruqvN0hUWag0Fg74nspNlWjxEizRypLAgxBngKJp66YU HV7wnMPnM+XpXQVKyDUGM/y2lkJoDYGz2T64FLso=
To: Adam Roach , Ole Jacobsen 
Cc: rfced-future@iab.org, Ole Jacobsen , "StJohns, Michael" , Bob Hinden , Peter Saint-Andre 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>    <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch> <7C41B6AA-5DCB-4908-AF6D-41A7D92E7C6A@me.com> 
From: Eliot Lear 
Message-ID: <71b586a9-0185-683d-c88f-11803904cf21@lear.ch>
Date: Tue, 13 Jul 2021 20:39:01 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HDkgRddcsmtFn05DMUUcUNvZ70WyYwIIM"
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 18:39:13 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HDkgRddcsmtFn05DMUUcUNvZ70WyYwIIM
Content-Type: multipart/mixed; boundary="zeqGaR7drMDZ2DRJ2303orJiEXVG4gD3N";
 protected-headers="v1"
From: Eliot Lear 
To: Adam Roach ,
 Ole Jacobsen 
Cc: rfced-future@iab.org, Ole Jacobsen ,
 "StJohns, Michael" ,
 Bob Hinden , Peter Saint-Andre 
Message-ID: <71b586a9-0185-683d-c88f-11803904cf21@lear.ch>
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
References: 
 
 <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com>
 <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com>
 <02994423-D9CB-4996-B831-E87900EC9250@gmail.com>
 <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>
 
 
 
 <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch>
 <7C41B6AA-5DCB-4908-AF6D-41A7D92E7C6A@me.com>
 
In-Reply-To: 

--zeqGaR7drMDZ2DRJ2303orJiEXVG4gD3N
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

I think we have some words in the draft about this, and I don't think we =

should be binary, nor do I think it is helpful to go too deep into=20
history.=C2=A0 If there is brand value or ease of hiring, that's good to =

know.=C2=A0 We could also give this person another title like director or=
=20
vice president of publications.=C2=A0 All of these titles only matter in =
as=20
much as they serve a purpose...


On 13.07.21 20:32, Adam Roach wrote:
> On 7/13/21 11:56, Ole Jacobsen wrote:
>> Are we seeking someone for an entirely different role this time?
>
>
> I *think* so, depending on how rigorously you intend to apply "entirely=
=2E"
>
> /a
>


--zeqGaR7drMDZ2DRJ2303orJiEXVG4gD3N--

--HDkgRddcsmtFn05DMUUcUNvZ70WyYwIIM
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDt3cUFAwAAAAAACgkQh7ZrRtnSejMQ
mggAwLdp5spIr7NZAPdCPldKmMpynQjKYpf2kXNnIMBvy3YE3/PcOcIotxWzuLESg7lauVn9nd5M
ExZv5Y/FCOn7/LIBQIEZjwMKLi48xfVZMsGnyago+A5gIhM7Zs63Vu8PxgXt0zdsLzfOlwe1eCjy
/KKPgKn279y6/EaUPCNcQmNIV/UIGTVmXcRpTxrrXXDHYAQXrbfMdbL0Un3MQzYwzLfzmstyNhwF
4oHU41PL7kzL55MseZseEZSqa+Mq0tpm41M8yALyX0/NGndycWyqcz1SvuOwbZlaQ/iPuJQ90E6O
rz/hw6eSE+gE6UwzP+2wMQL0xrAqJ2iyJBpUMTfn1g==
=2DBI
-----END PGP SIGNATURE-----

--HDkgRddcsmtFn05DMUUcUNvZ70WyYwIIM--


From nobody Tue Jul 13 11:39:28 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428953A091B for ; Tue, 13 Jul 2021 11:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjh6uN57lqop for ; Tue, 13 Jul 2021 11:39:21 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 995843A091E for ; Tue, 13 Jul 2021 11:39:21 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16DIdD6s015930; Tue, 13 Jul 2021 19:39:13 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 407644604B; Tue, 13 Jul 2021 19:39:13 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1E7804604A; Tue, 13 Jul 2021 19:39:13 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS; Tue, 13 Jul 2021 19:39:13 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.103.107]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16DIdBvC001954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Jul 2021 19:39:11 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Eliot Lear'" , "'StJohns, Michael'" , "'Peter Saint-Andre'" 
Cc: , "'Bob Hinden'" 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>    <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch>
In-Reply-To: <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch>
Date: Tue, 13 Jul 2021 19:39:11 +0100
Organization: Old Dog Consulting
Message-ID: <019401d77816$60782860$21687920$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0195_01D7781E.C23DEFF0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHyUCp3GMpBMVJOs5qcBg6JXJDdnAJv+y1uAl0ExT8BcJZYIQJNtDJiAggcd0IB9bkBpgJjh6IsAp5ROb0BtKzjH6pxi0ug
Content-Language: en-gb
X-Originating-IP: 84.93.103.107
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26280.002
X-TM-AS-Result: No--19.776-10.0-31-10
X-imss-scan-details: No--19.776-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26280.002
X-TMASE-Result: 10--19.776000-10.000000
X-TMASE-MatchedRID: yebcs53SkkDkQwDXuLnCoXFPUrVDm6jt82SgwNf6SK5vd96Stg5JDz6a xtyLU8r/2TNVD6X3imHMni6Z8Tfo8VcprmZ1YSCJUgKYbZFF6GjcbNJY9S/K76O8oByS0pMBmjW se8O3KkAhjxbeo5NwNH0biRgn1pFpRCaWYV6Qw3yXmVAzMqYX0r/kINU/9Cx+8Pai+iraq2jp2H iRYtlPEf56uq6ZOu+s0veZ06lX0f+VXNtk5QC4Z8HpLt99Ld5rOhJ9m53n4aDozDhGeQC9EtWpc Dep9glg1pTtLKMW2+kWaIGlrsAXgrYpml+YngKl54eqweLWaL6rDPxf3LbqpGh76/bDpGErgat6 XIzTIPoe4cCzUH0sZU1jHdyKG1U5ePC4bGeaL3emAgeB6dclcvIK8gK4rjpyoPYtyKOX/wBjwrh W0Xv2knCBPdZX1PWkTVqNx2ax7cFlb+6t0hAZoCSnuJJeKKeEuHJW4tKGYCxrRM6wvXgDaUIlhu oendEbG6ikLKAxOzOHFShmNuSfWry3/9UX/zhzKABBZZ3PPkUL//VMxXlyE1AoBBK61BhcDHtD2 tf9oeooycTqiNHD8/nKJdf9vmsFGFrXx4eeC3OCdpZrJ0mGvQvxMaV6x4s8G5CsehCRO+nLN4d4 W89LkaMCxuXrI5xZO/Yqvm+/OOZUioY0zUhrN3YZxYoZm58FBFF0/8xJ1RMS+jFO7d+PW1KELl0 /Umwg8KHye8V4bWQ5mqWl6lNrk+7ou6E91dhwhL9NX2TqmkCXwNAvAOphpOCbuVI7hVbLe4t0yV pGKXndD4nD3zNdvqq9Ibq1lgM9egZYiFBeiQeeAiCmPx4NwCIWyOG3VFHjU2Qzq85WfnCEFYiZR sDydfbHepi60VNbfywj+0e2KwXg7ZrF2MZA4YptCma4d/2Jzc2NVj+z1wBl90D752iez03N380d xYrz7i1K7NHTBz/1IB/lc2EXP2A7bUFBqh2V
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 18:39:27 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0195_01D7781E.C23DEFF0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I don=E2=80=99t know where I stand on your summary, Eliot.

=20

It=E2=80=99s the =E2=80=9Cno direct editorial control=E2=80=9D. I may =
have missed discussion of:

*	Who authors the style guide?
*	Who sets the house style?
*	Who oversees the RPC in things like assignment of RFC numbers, =
processing of errata, Auth-48 process, etc.?

Maybe these are considered =E2=80=9Chanded over to the WG=E2=80=9D.

Maybe these are not considered editorial control.

=20

I don=E2=80=99t know.

=20

I think we are back to the job description. My suggestion is that only =
once we have agreement on the job description can we name the job. Do we =
have agreement on the job description?

=20

Cheers,

Adrian

=20

From: Rfced-future  On Behalf Of Eliot =
Lear
Sent: 13 July 2021 17:36
To: StJohns, Michael ; Peter Saint-Andre =

Cc: rfced-future@iab.org; Bob Hinden 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?

=20

Ok, this seems like a good time to try to catalog the arguments.  Please =
correct me or add:

RSE

*	Brand name value for hiring purposes
*	RSA not a term of art

RSA

*	Because there is no direct editorial control, the term advisor is more =
accurate.  Let's not confuse the community.

All of these are rebuttable points.  I would suggest that more =
information about how prospective applicants or people from that =
profession would view the role would help us [in]validate the first two =
bullets.  Would people like that input?

Eliot

On 13.07.21 17:41, StJohns, Michael wrote:

Hi Peter.=20

=20

National Security Advisor, like RFC Series Editor has a history that =
associates a level of significance to the role, even with the term =
advisor in the title.   That applies also to Secretary of State, etc.  =
So your argument by comparison doesn=E2=80=99t actually point to =
changing the name. =20

=20

I think you=E2=80=99re going to have problems finding consensus to =
change the name.  Unfortunately, we may also have a problem finding =
consensus to keep the name.  =20

=20

Mike

=20

On Tue, Jul 13, 2021 at 11:34 Peter Saint-Andre  > wrote:

We seem to speculate with fair frequency about the titles that will make
it possible to attract candidates for the role of technical publishing
expert within version 3 of the model. I'm not so sure how important that
is (after all, a role like the National Security Advisor in the U.S.
government is perceived as significant even though it has "advisor" in
the name); what might matter most is the actual activities the person
will perform, the respect accorded to the role, the perceived importance
of the RFC Series, etc.

Peter

On 7/12/21 10:29 PM, StJohns, Michael wrote:
> I don't think so.  I=E2=80=99m not even sure we could get anyone to =
apply for
> something with that job title.  Mike
>=20
> On Tue, Jul 13, 2021 at 00:11 Brian E Carpenter
>   =
 =
>> wrote:
>=20
>     Could we compromise on "RFC Series Advisory Editor"?
>=20
>     The term is used quite widely and it even seems accurate.
>=20
>     Regards
>        Brian Carpenter
>=20
>     On 13-Jul-21 16:00, Bob Hinden wrote:
>     > Brian,
>     >
>     >> On Jul 12, 2021, at 7:52 PM, Brian E Carpenter
>       =
 =
>>
>     wrote:
>     >>
>     >> I don't think there is any proposal to retire the term "RFC =
Editor".
>     >> But for many years it has referred to the function as well as =
to
>     >> the figurehead. RFC2850 refers to "an organization to act as
>     >> RFC Editor" because even in May 2000 it wasn't a person, =
although
>     >> Bob Braden led the team. And also "The Internet Society, the =
RFC
>     Editor,
>     >> the IANA and the IESG each appoints a liaison member to the =
IAB."
>     >>
>     >> Given the job description and role of the RSEA, I really don't =
see
>     >> how we can call the person an editor.
>     >
>     > Think about it like positions in the US called =
=E2=80=9CSecretary of
>     State=E2=80=9D, see:
>     >
>     > https://www.state.gov/secretary/ =

>     >
>     > They are not performing secretarial duties.
>     >
>     > Bob
>     >
>     >
>     >>
>     >> Regards
>     >>   Brian Carpenter
>     >>
>     >> On 13-Jul-21 05:20, Michael StJohns wrote:
>     >>> Bob said it better than I can.   Mike
>     >>>
>     >>> On 7/12/2021 12:58 PM, Bob Hinden wrote:
>     >>>> Hi,
>     >>>>
>     >>>>> On Jul 9, 2021, at 2:03 PM, Peter Saint-Andre
>       =
 >>
>     wrote:
>     >>>>>
>     >>>>> The role played by the technical publishing expert in =
version
>     3 of the
>     >>>>> model is different enough from past roles that I suggest we
>     should not
>     >>>>> use the name "RFC Series Editor" but instead "RFC Series =
Advisor=E2=80=9D.
>     >>>> I strongly disagree.
>     >>>>
>     >>>> The RFC Editor role has changed multiple times in the past in
>     many ways and we still call it the RFC Editor.
>     >>>>
>     >>>> This includes:
>     >>>>
>     >>>> Administrative support and direction changed from Defense
>     Advanced Project Agency (DARPA), the Internet Society, IAOC, and
>     currently the IETF
>     LLC.
>     >>>>
>     >>>> It has been performed by Jon Postel, Bob Braden, Joyce
>     Reynolds, Glenn
>     >> Kowack, Olaf Kolkman, and Heather Flanagan.
>     >>>>
>     >>>> Actual editing has transitioned from an individual to a
>     contracted company.
>     >>>>
>     >>>> The scope and the context of this position has changed as the
>     administration and the person doing the job changed.   It has =
great
>     name recognition.   I don=E2=80=99t see any reason why what we are =
defining
>     now can not be called the RFC Editor.   Changing it the =
=E2=80=9CRFC Series
>     Advisor=E2=80=9D will cause considerable confusion in the larger =
community.
>     >>>>
>     >>>> Bob
>     >>>>
>     >>>>
>     >>>>
>     >>>
>     >>>
>     >>
>     >> --
>     >> Rfced-future mailing list
>     >> Rfced-future@iab.org   =
 >
>     >> https://www.iab.org/mailman/listinfo/rfced-future
>     
>     >
>=20
>=20






------=_NextPart_000_0195_01D7781E.C23DEFF0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


I don=E2=80=99t know where I stand =
on your summary, Eliot.
 
It=E2=80=99s the =E2=80=9Cno direct =
editorial control=E2=80=9D. I may have missed discussion =
of:
  • Who authors the style =
guide?
  • Who sets the house =
style?
  • Who oversees the RPC in things like =
assignment of RFC numbers, processing of errata, Auth-48 process, =
etc.?
Maybe these are considered =
=E2=80=9Chanded over to the WG=E2=80=9D.
Maybe these =
are not considered editorial control.
 
I =
don=E2=80=99t know.
 
I think we =
are back to the job description. My suggestion is that only once we have =
agreement on the job description can we name the job. Do we have =
agreement on the job description?
 
Cheers,
Adrian
 
From: Rfced-future =
<rfced-future-bounces@iab.org> On Behalf Of Eliot =
Lear
Sent: 13 July 2021 17:36
To: StJohns, Michael =
<msj@nthpermutation.com>; Peter Saint-Andre =
<stpeter@mozilla.com>
Cc: rfced-future@iab.org; Bob =
Hinden <bob.hinden@gmail.com>
Subject: Re: =
[Rfced-future] Issue 24: What is the name of the =
role?
 
Ok, this seems like a good =
time to try to catalog the arguments.  Please correct me or =
add:
RSE
  • Brand name value for hiring purposes
  • RSA not a term of =
art
RSA
  • Because there is no direct editorial control, the term =
advisor is more accurate.  Let's not confuse the =
community.
All of these are rebuttable =
points.  I would suggest that more information about how =
prospective applicants or people from that profession would view the =
role would help us [in]validate the first two bullets.  Would =
people like that input?
Eliot
On 13.07.21 17:41, StJohns, Michael =
wrote:
Hi Peter. 
 
National Security Advisor, like RFC Series Editor has =
a history that associates a level of significance to the role, even with =
the term advisor in the title.   That applies also to Secretary of =
State, etc.  So your argument by comparison doesn=E2=80=99t =
actually point to changing the name.  
 
I =
think you=E2=80=99re going to have problems finding consensus to change =
the name.  Unfortunately, we may also have a problem finding =
consensus to keep the name.   
 
Mike
 
On =
Tue, Jul 13, 2021 at 11:34 Peter Saint-Andre <stpeter@mozilla.com> =
wrote:
We seem =
to speculate with fair frequency about the titles that will make
it =
possible to attract candidates for the role of technical =
publishing
expert within version 3 of the model. I'm not so sure how =
important that
is (after all, a role like the National Security =
Advisor in the U.S.
government is perceived as significant even =
though it has "advisor" in
the name); what might matter =
most is the actual activities the person
will perform, the respect =
accorded to the role, the perceived importance
of the RFC Series, =
etc.

Peter

On 7/12/21 10:29 PM, StJohns, Michael =
wrote:
> I don't think so.  I=E2=80=99m not even sure we =
could get anyone to apply for
> something with that job =
title.  Mike
> 
> On Tue, Jul 13, 2021 at 00:11 Brian E =
Carpenter
> <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> =

>     Could we compromise on "RFC Series =
Advisory Editor"?
> 
>     The term is =
used quite widely and it even seems accurate.
> 
>  =
   Regards
>        Brian =
Carpenter
> 
>     On 13-Jul-21 16:00, Bob =
Hinden wrote:
>     > Brian,
>  =
   >
>     >> On Jul 12, 2021, =
at 7:52 PM, Brian E Carpenter
>     <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>
>  =
   wrote:
>     >>
>  =
   >> I don't think there is any proposal to retire the =
term "RFC Editor".
>     >> But for =
many years it has referred to the function as well as to
>  =
   >> the figurehead. RFC2850 refers to "an =
organization to act as
>     >> RFC =
Editor" because even in May 2000 it wasn't a person, =
although
>     >> Bob Braden led the team. =
And also "The Internet Society, the RFC
>    =
 Editor,
>     >> the IANA and the IESG =
each appoints a liaison member to the IAB."
>    =
 >>
>     >> Given the job =
description and role of the RSEA, I really don't see
>  =
   >> how we can call the person an =
editor.
>     >
>     > =
Think about it like positions in the US called =E2=80=9CSecretary =
of
>     State=E2=80=9D, see:
>    =
 >
>     > https://www.state.gov/secretary/ <https://www.state.gov/secretary/>
>  =
   >
>     > They are not =
performing secretarial duties.
>    =
 >
>     > Bob
>    =
 >
>     >
>    =
 >>
>     >> Regards
>  =
   >>   Brian Carpenter
>    =
 >>
>     >> On 13-Jul-21 05:20, =
Michael StJohns wrote:
>     >>> Bob said =
it better than I can.   Mike
>    =
 >>>
>     >>> On 7/12/2021 =
12:58 PM, Bob Hinden wrote:
>     >>>> =
Hi,
>     >>>>
>    =
 >>>>> On Jul 9, 2021, at 2:03 PM, Peter =
Saint-Andre
>     <stpeter@mozilla.com <mailto:stpeter@mozilla.com>>
>    =
 wrote:
>    =
 >>>>>
>    =
 >>>>> The role played by the technical publishing =
expert in version
>     3 of the
>  =
   >>>>> model is different enough from past =
roles that I suggest we
>     should =
not
>     >>>>> use the name =
"RFC Series Editor" but instead "RFC Series =
Advisor=E2=80=9D.
>     >>>> I strongly =
disagree.
>     >>>>
>  =
   >>>> The RFC Editor role has changed multiple =
times in the past in
>     many ways and we still =
call it the RFC Editor.
>    =
 >>>>
>     >>>> This =
includes:
>     >>>>
>  =
   >>>> Administrative support and direction =
changed from Defense
>     Advanced Project Agency =
(DARPA), the Internet Society, IAOC, and
>    =
 currently the IETF
>     LLC.
>  =
   >>>>
>    =
 >>>> It has been performed by Jon Postel, Bob Braden, =
Joyce
>     Reynolds, Glenn
>    =
 >> Kowack, Olaf Kolkman, and Heather Flanagan.
>  =
   >>>>
>    =
 >>>> Actual editing has transitioned from an =
individual to a
>     contracted =
company.
>     >>>>
>  =
   >>>> The scope and the context of this position =
has changed as the
>     administration and the =
person doing the job changed.   It has great
>  =
   name recognition.   I don=E2=80=99t see any =
reason why what we are defining
>     now can not =
be called the RFC Editor.   Changing it the =E2=80=9CRFC =
Series
>     Advisor=E2=80=9D will cause =
considerable confusion in the larger community.
>    =
 >>>>
>     >>>> =
Bob
>     >>>>
>    =
 >>>>
>    =
 >>>>
>    =
 >>>
>     >>>
>  =
   >>
>     >> =
--
>     >> Rfced-future mailing =
list
>     >> Rfced-future@iab.org <mailto:Rfced-future@iab.org>
>    =
 >> https://www.iab.org/mailman/listinfo/rfced-future>     <https://www.iab.org/mailman/listinfo/rfced-future&g=
t;
>     >
> 
> =




------=_NextPart_000_0195_01D7781E.C23DEFF0--


From nobody Tue Jul 13 11:44:11 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370CB3A0AA3 for ; Tue, 13 Jul 2021 11:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QSKmXJmEpHZ for ; Tue, 13 Jul 2021 11:44:02 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 C25E13A0A04 for ; Tue, 13 Jul 2021 11:44:02 -0700 (PDT)
Received: from smtpclient.apple (unknown [85.131.57.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 3DD3C60034E; Tue, 13 Jul 2021 21:43:54 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626201834; bh=KIyEhASvmdiO888D8iUY3MZkgWDWyFyC4F/+N7cypas=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=AUE0woHX82wuTgB/SY9Gg6p/WsbDLnl1o6lACDVbaKnf2uZ6AJF957vbk3oBdR/+3 J3GwFvjv32YVV5uSjH0+u7jTFlYwgxsfx/w7H5vO0ATM2QMz5YQEJidi9g1cM3rOY5 ErprUxg9FwviIkuc+AFKCu7R2h0iS1LF6TPgt/dA=
From: Lars Eggert 
Message-Id: <6DC81594-780C-4BF0-8D68-B33AB33F289A@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_3A9CE434-81A9-4D24-9CFA-7A52800F6352"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Tue, 13 Jul 2021 21:43:53 +0300
In-Reply-To: <7C41B6AA-5DCB-4908-AF6D-41A7D92E7C6A@me.com>
Cc: Eliot Lear , rfced-future@iab.org, Bob Hinden , Peter Saint-Andre , Ole Jacobsen , "StJohns, Michael" 
To: Ole Jacobsen 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>    <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch> <7C41B6AA-5DCB-4908-AF6D-41A7D92E7C6A@me.com>
X-MailScanner-ID: 3DD3C60034E.A24C4
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 18:44:09 -0000

--Apple-Mail=_3A9CE434-81A9-4D24-9CFA-7A52800F6352
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 2021-7-13, at 19:56, Ole Jacobsen =
 wrote:
> The original message contained a
> link to an IAOC page with the job description, but sadly that link is =
now
> dead [for reference it was: =
https://iaoc.ietf.org/rfced-procurement.html]

FWIW, archive.org has a copy: =
https://web.archive.org/web/20120506194312/http://iaoc.ietf.org/rfced-proc=
urement.html

Thanks,
Lars


--Apple-Mail=_3A9CE434-81A9-4D24-9CFA-7A52800F6352
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-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmDt3ukACgkQVLXDCb9w
wVdRHxAAwFdTiwOYfRe0QAsZpMCa3iMoLgZ1qooH4CVX453EVHg5/ejxcVNzArg2
9ejpsK7uLKe6s44Jwdw4OcQXXknSbFmXDyCAgTO71XO7lWw6X2czgK8BkVU1rExr
+ZUKjMB1++vCYrzfU9DSBzbml0HZk/3PUJUUOmad64XUH65qFiKlPBzfYcKAImFN
vip+Sumbgen2ZwQ4h6uVOeNpg9nN1MWZJ19i/JstSrnHyBB7O1GIt+1rYVi9WQrU
A1KJZG5Yc+4POkOyrre7Iepl46B3D+RMnUSNyHzktjo8BPWW6l4qY2/of8T6jdM3
cWJOgk3NIOecH68rX8KX0hyCD+VlchOk0cAJzlcGE1oLbVwMeMhXz0RKAkcFCQhk
0jaF1T9UJzQUeVWWCk4h/SN6FSSOxrRMgSsIHVR4bJoYpds8/dDizu7JolNgT8v0
JIPiyIRyjIFSB8Wer1YWuV6xsncilamOzXlb++/KIByIJcgwnJezh9hDJYfeTupe
xBv7yYxT9xMTOU4go1qVpJzwWg1oX8mYxdrhXTTjzgHS3hJcERwbUfxmKlc2O/3w
8tilq37tDfIOnqtzZ90LZpJ/gbi5KTj7QJl44y1pddiqN3qhKisxW0zOn3AFyDnx
GW2bb+Bz5DJ92TnpiT8oZh+45/JBsD10MqJosrUH8S/8paV80EI=
=tbP/
-----END PGP SIGNATURE-----

--Apple-Mail=_3A9CE434-81A9-4D24-9CFA-7A52800F6352--


From nobody Tue Jul 13 13:05:43 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF68D3A1737 for ; Tue, 13 Jul 2021 13:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOFdJ-9rI-_T for ; Tue, 13 Jul 2021 13:05:35 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 40C1A3A1732 for ; Tue, 13 Jul 2021 13:05:34 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1004::18c] ([IPv6:2001:420:c0c0:1004:0:0:0:18c]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16DK5P36217550 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 13 Jul 2021 22:05:26 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626206729; bh=4+7AmtaNo6XaV9qrmWVZspTEUeyP/0SoUWmuO2nlMsY=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=cAwLieFFjr3odLotljV0+umd5dVXfPDod2OHaqLrW7R0w+JAIIoXOtE1osIFGParm UKtQPI9DeDDVd3SJrKw8ggKj1z54oggNRt7SdAKlNr19Dmvm7BUz2afwO8kPbCAFE9 +fyZAHjQhpXAQJ0KDQ3orDh/Faj8YUUuJRMy0DCY=
To: adrian@olddog.co.uk, "'StJohns, Michael'" , "'Peter Saint-Andre'" 
Cc: rfced-future@iab.org, "'Bob Hinden'" 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>    <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch> <019401d77816$60782860$21687920$@olddog.co.uk>
From: Eliot Lear 
Message-ID: <2c76d4b9-950f-3e2e-0897-2e8e018d202a@lear.ch>
Date: Tue, 13 Jul 2021 22:05:23 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <019401d77816$60782860$21687920$@olddog.co.uk>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ts6hOw5w8lXuGS2wEIhsBul0zzqmnzI3e"
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 20:05:42 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ts6hOw5w8lXuGS2wEIhsBul0zzqmnzI3e
Content-Type: multipart/mixed; boundary="Kx5KMb3nAXt9k12Yx17AfbdLV8ZxC78jn";
 protected-headers="v1"
From: Eliot Lear 
To: adrian@olddog.co.uk, "'StJohns, Michael'" ,
 'Peter Saint-Andre' 
Cc: rfced-future@iab.org, 'Bob Hinden' 
Message-ID: <2c76d4b9-950f-3e2e-0897-2e8e018d202a@lear.ch>
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
References: 
 
 <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com>
 <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com>
 <02994423-D9CB-4996-B831-E87900EC9250@gmail.com>
 <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>
 
 
 
 <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch>
 <019401d77816$60782860$21687920$@olddog.co.uk>
In-Reply-To: <019401d77816$60782860$21687920$@olddog.co.uk>

--Kx5KMb3nAXt9k12Yx17AfbdLV8ZxC78jn
Content-Type: multipart/alternative;
 boundary="------------15656842EA75D5535C20A64B"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------15656842EA75D5535C20A64B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Adrian

On 13.07.21 20:39, Adrian Farrel wrote:
>
> I don=E2=80=99t know where I stand on your summary, Eliot.
>
> It=E2=80=99s the =E2=80=9Cno direct editorial control=E2=80=9D. I may h=
ave missed discussion of:
>
>   * Who authors the style guide?
>   * Who sets the house style?
>   * Who oversees the RPC in things like assignment of RFC numbers,
>     processing of errata, Auth-48 process, etc.?
>
I want to confirm the others, but we spent a fair amount of time on=20
AUTH48.=C2=A0 I didn't realize RFC#s are a thing, but I imagine that is a=
=20
pretty easy thing to sort.=C2=A0 The processing of errata seem to me a ma=
tter=20
for stream owners.=C2=A0 Is there more complexity there?


> I think we are back to the job description. My suggestion is that only =

> once we have agreement on the job description can we name the job. Do=20
> we have agreement on the job description?
>
We have SOME text in the draft today:

> =C2=A0 The primary responsibilities of the RSEA are as follows:
>
> =C2=A0=C2=A0 o=C2=A0 Serve as a voting member on the RSAB.
>
> =C2=A0=C2=A0 o=C2=A0 Identify problems with the RFC publication process=
 and
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opportunities for improvement.
>
> =C2=A0=C2=A0 o=C2=A0 Provide expert advice regarding policy proposals w=
ithin the RSWG.
>
> =C2=A0=C2=A0 o=C2=A0 If requested, provide expert advice to the RPC and=
 IETF LLC.
>
> =C2=A0=C2=A0 Matters on which the RSEA might be consulted could include=
 proposed
> =C2=A0=C2=A0 changes to the RFC style guide [RFC7322], RFC formatting i=
n general,
> =C2=A0=C2=A0 web presence, copyright matters, archiving policy, and dis=
semination
> =C2=A0=C2=A0 and cataloguing of RFCs.

Feel free to propose elaborations, of course.=C2=A0 I think we might need=
=20
some with regard to the style guide in particular.

Eliot



--------------15656842EA75D5535C20A64B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Adrian

    

    
On 13.07.21 20:39, Adrian Farrel wrote=
:

    

    

      
      
      
      

        
I
            don=E2=80=99t know where I stand on your summary, Eliot.=


        
=C2=A0

        
It=E2=80=99s
            the =E2=80=9Cno direct editorial control=E2=80=9D. I may have=
 missed
            discussion of:

        
    
          
  • Who authors the style
              guide?
    • 
          
  • Who sets the house
              style?
    • 
          
  • Who oversees the RPC i=
n
              things like assignment of RFC numbers, processing of
              errata, Auth-48 process, etc.?
    • 
        

      

    

    
I want to confirm the others, but we spent a fair amount of time
      on AUTH48.=C2=A0 I didn't realize RFC#s are a thing, but I imagine =
that
      is a pretty easy thing to sort.=C2=A0 The processing of errata seem=
 to
      me a matter for stream owners.=C2=A0 Is there more complexity there=
?

    

    

    

      

        
I
            think we are back to the job description. My suggestion is
            that only once we have agreement on the job description can
            we name the job. Do we have agreement on the job
            description?

      

    

    
We have SOME text in the draft today:

    

    

      
=C2=A0 The primary responsibilities of th=
e RSEA
        are as follows:

        

        =C2=A0=C2=A0 o=C2=A0 Serve as a voting member on the RSAB.

        

        =C2=A0=C2=A0 o=C2=A0 Identify problems with the RFC publication p=
rocess and

        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opportunities for improvement.
=

        

        =C2=A0=C2=A0 o=C2=A0 Provide expert advice regarding policy propo=
sals within
        the RSWG.

        

        =C2=A0=C2=A0 o=C2=A0 If requested, provide expert advice to the R=
PC and IETF
        LLC.

        

        =C2=A0=C2=A0 Matters on which the RSEA might be consulted could i=
nclude
        proposed

        =C2=A0=C2=A0 changes to the RFC style guide [RFC7322], RFC format=
ting in
        general,

        =C2=A0=C2=A0 web presence, copyright matters, archiving policy, a=
nd
        dissemination

        =C2=A0=C2=A0 and cataloguing of RFCs.

      

      

    

    
Feel free to propose elaborations, of course.=C2=A0 I think we mig=
ht
      need some with regard to the style guide in particular.

    

    
Eliot

    

    

  


--------------15656842EA75D5535C20A64B--

--Kx5KMb3nAXt9k12Yx17AfbdLV8ZxC78jn--

--ts6hOw5w8lXuGS2wEIhsBul0zzqmnzI3e
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDt8gMFAwAAAAAACgkQh7ZrRtnSejPX
CggAynt93Hr4JyBI0d/si5tQJxnfR5YxtfZFQAagmCBNl67aWShMVj3Oexrb1gZNcrP3dB12OJcH
VY8UiEeqj7bzHqVfBjMeqhEFGnK7b9w1YIVCffYNlaF8FaF5PyVU1MgCoomsCmNFfLBdMRYcPORv
qwT96P1tSstYciThp5QIVYRM/VZ+FTeE82eTCA2kD+tc6PPzmmbJMOuRxaMxKCT/AoeR0RJLAH8d
vu6dqfg8cvG7oUXgCZD/TEre7nqiM12eWpx5wlt2ZRE4auJAhfdC3qUQOIJJCfXeE/Dqgipnn2Mq
ImqXvILVo5l+hKaWb3Go+fzeBTsozKTFxeDuBhpnvA==
=jnz2
-----END PGP SIGNATURE-----

--ts6hOw5w8lXuGS2wEIhsBul0zzqmnzI3e--


From nobody Tue Jul 13 16:47:34 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247C63A0E9B for ; Tue, 13 Jul 2021 16:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORTFJ010LEIf for ; Tue, 13 Jul 2021 16:47:32 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 039BA3A0E99 for ; Tue, 13 Jul 2021 16:47:31 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id z2so279913plg.8 for ; Tue, 13 Jul 2021 16:47:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7Ee/Xhnq7/fOdfeYVEYFcLoV+YsEBIDm/hscF9/Pzgw=; b=thTK8I+98Tz7reOLuSD9WCccTAqYegy3q0nKEEHHUkBuR4y39WQs84UMp2FjRg4phy FRhSYIDnkRepneK0dJd4LqhC/2RVqmoPDP7pus3KtCpSsWEObjQA6JdfdLr8un4SmmnZ vZK54dL7IFxNBVw/gMOi28MPDOAaEeCOAsIAe1qpIAZGlbyebMNvWhbJBYbVteb4ea5W eZWneRykrTSgdL7sbLotKZ7QSjtBSEeJ9LhUS7uwkP4y6rc9pfDwWO3iKhICA5bp1Ter 1cXVWvsI0+SXQJZOl84ndTP/M9KHIaKfBBxv62SKMTKy+3dFt2O4kWY7ir6n941uy2gt PtRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7Ee/Xhnq7/fOdfeYVEYFcLoV+YsEBIDm/hscF9/Pzgw=; b=bAirDrZ+KFHIcqAJXxJmA/8AsflcMHwb7bu7C2w7CtxApBumanS+pxifXsGpz/umzP b2fkg5UEPs31E5iYzvjTUCxGdec+lWs0OphHfHBwmbnLawNd93aQLnLfGZt2kz/51+Sf hNi54OJ1cWPUBo6fWvvYknQWB7bjBnlZdJoYH7QP+xLygrbfFajX2+gBBUzg57G9XGJi KEAWxqMmPs/m7daBTReOe7lAUXRH2b6evIpIEf0FC4YLGZlDIqm/HWOS+UhnKqZEabvI KUnfYbPIVNH5jT6KVHnJveqPyhFPPMcwWoD5yKYtnb6xbKQLg7VII8Lk3eVEGu50ByNx Iy3Q==
X-Gm-Message-State: AOAM5339yX0BL7XB7LKv41FohdVSuBI3UZB482tO/e+fulx8eO85QHx1 g4PbsWEfIQIPjcex/uNz/gqdQVbMpGSHYA==
X-Google-Smtp-Source: ABdhPJxcbIDtY79r27f72e8NdU7BwNfAzafXOEBC8wScEKiUiCHs8y5tLwYsxsZIfd29rCJNX22vcg==
X-Received: by 2002:a17:90b:1109:: with SMTP id gi9mr741180pjb.61.1626220050288;  Tue, 13 Jul 2021 16:47:30 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id a22sm206962pgv.84.2021.07.13.16.47.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 16:47:29 -0700 (PDT)
To: Russ Housley , Mirja Kuehlewind 
Cc: rfced-future@iab.org
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>  
From: Brian E Carpenter 
Message-ID: 
Date: Wed, 14 Jul 2021 11:47:27 +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: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 23:47:33 -0000

On 14-Jul-21 02:46, Russ Housley wrote:
> Mirja:
> 
>> As someone else already said, I think we can still have an RFC editor _function_ but the person we hire should not be called the RFC Editor.
> 
> We had this same discussion for RFC Editor Model Version 2 (RFC 6635).  Those discussions created the term  RFC Series Editor (RSE) to distinguish this position from the overall RFC Editor function.

We did indeed. And now we are substantially changing the role, so I continue to believe that we should create a term to distinguish this position from the overall RFC Editor function *and* from the previous RSE role.

Whether people wish to apply for the job will depend much more on the job description and the pay, rather than the job title.

My best effort is still "RFC Series Advisory Editor", or we could try "RFC Series Consulting Editor" if we think that sounds grander.

     Brian


From nobody Tue Jul 13 16:56:18 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491D73A127D for ; Tue, 13 Jul 2021 16:56:16 -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 NXOklOWQmIlZ for ; Tue, 13 Jul 2021 16:56:13 -0700 (PDT)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4633A127C for ; Tue, 13 Jul 2021 16:56:13 -0700 (PDT)
Received: by mail-pj1-x1030.google.com with SMTP id l11so124140pji.5 for ; Tue, 13 Jul 2021 16:56:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7Eenr4iFLP5xDGEUpHWHNmYTE8tkGQ7CHj0tKrKHI0c=; b=VcDDUVxViHxbra0hycKwMEwZQzKnuKKjDSn8SP0wjw3oTKjNUPznvBfzIPOe1xhE++ IH3NAKzNJyzrPE+eOPubWydNTuZUMK8nsNJRVmi2xpxEsXsALC9nRriA5NCxvmQmXzml TsZbchxfzoEXwydXhLVH6htKuhEnxMbs1VdbnT6X+BDex3aCcvFfQ5T5KTFKbmOoCQCV PRIPQDAjg47NZHOU/10MxWgT660zdftT1aPhm1aYnrWqwy08huVhr2Fr0bpdIPJoWOvx sKGNtkf0qB023JmfoK9udeOz1neNnoiyVprW91hC6rWreYrehnTMnUwDIOxPaOsIP77d jIgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7Eenr4iFLP5xDGEUpHWHNmYTE8tkGQ7CHj0tKrKHI0c=; b=JsnTRzCuNc1DZjvqiBWLEe+UZbDPWhzOt+QGnZTKgYD7xClEJc4/1cifpu1wHovEgN 8Ig81QQwaYpMkQVlEKloqFxX4RciGV8J7Lv1PrhdIeWw9F2W+R8FS/LtziLDY32JCJ1p M+t9epmKo3AlNBr9GPUPgVh70+4KTrDbNVTYond5lgFl2MmoMN5d3ckyy6a30z5nkRNq 4220xrPcvjGTBbf14MS4FttTXnYcyLfH73ltKseSni1Fb7fxNRsv4v9gb4lCjar78ph1 DtZIBZc9Au/AF5Ls9H80TtutMniTByxquiWxmRGJivNu+HZs7v7wv22hocJKezpYipKv rAKQ==
X-Gm-Message-State: AOAM532/JvSXNES/qWFtL24daf0QxbDD3qtfevGR32qKQAou5V8updHU MCIl91aLXJtr5LPPBGDaUSk=
X-Google-Smtp-Source: ABdhPJya7PqQ46Tp39yVX4LOggtIGX0z2U8+KV0gDdZAPBJt+jL8Wh7U4Tn+62KemsBL+hDVfgU6Kw==
X-Received: by 2002:a17:902:e891:b029:12b:1c4f:4ce3 with SMTP id w17-20020a170902e891b029012b1c4f4ce3mr5289595plg.20.1626220571291;  Tue, 13 Jul 2021 16:56:11 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id js5sm251322pjb.40.2021.07.13.16.56.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 16:56:10 -0700 (PDT)
To: Eliot Lear , adrian@olddog.co.uk, "'StJohns, Michael'" , 'Peter Saint-Andre' 
Cc: rfced-future@iab.org, 'Bob Hinden' 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>    <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch> <019401d77816$60782860$21687920$@olddog.co.uk> <2c76d4b9-950f-3e2e-0897-2e8e018d202a@lear.ch>
From: Brian E Carpenter 
Message-ID: <182f2706-28fd-ef26-5965-c95ea31f5439@gmail.com>
Date: Wed, 14 Jul 2021 11:56:07 +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: <2c76d4b9-950f-3e2e-0897-2e8e018d202a@lear.ch>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Jul 2021 23:56:16 -0000

On 14-Jul-21 08:05, Eliot Lear wrote:
> Hi Adrian
>=20
> On 13.07.21 20:39, Adrian Farrel wrote:
>>
>> I don=E2=80=99t know where I stand on your summary, Eliot.
>>
>> =C2=A0
>>
>> It=E2=80=99s the =E2=80=9Cno direct editorial control=E2=80=9D. I may =
have missed discussion of:
>>
>>   * Who authors the style guide?
>>   * Who sets the house style?

I think those are the same question, and yes, I would expect the RSEA to =
take the lead in *drafting* such things but it's the RSWG that decides an=
d the RSAB that approves.

>>   * Who oversees the RPC in things like assignment of RFC numbers, pro=
cessing of errata, Auth-48 process, etc.?

Nobody new. That's part of their job, part of their contract, and presuma=
bly they have some internal management structure that isn't our business.=20
If they need a policy for assigning numbers, I guess that could become an=20
RSWG issue like the style guide.

> I want to confirm the others, but we spent a fair amount of time on AUT=
H48.=C2=A0 I didn't realize RFC#s are a thing, but I imagine that is a pr=
etty easy thing to sort.=C2=A0 The processing of errata seem to me a matt=
er for stream owners.=C2=A0 Is there more complexity there?
>=20
>=20
>> I think we are back to the job description. My suggestion is that only=20
once we have agreement on the job description can we name the job. Do we =
have agreement on the job description?
>>
> We have SOME text in the draft today:
>=20
>> =C2=A0 The primary responsibilities of the RSEA are as follows:
>>
>> =C2=A0=C2=A0 o=C2=A0 Serve as a voting member on the RSAB.
>>
>> =C2=A0=C2=A0 o=C2=A0 Identify problems with the RFC publication proces=
s and
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opportunities for improvement.
>>
>> =C2=A0=C2=A0 o=C2=A0 Provide expert advice regarding policy proposals =
within the RSWG.
>>
>> =C2=A0=C2=A0 o=C2=A0 If requested, provide expert advice to the RPC an=
d IETF LLC.
>>
>> =C2=A0=C2=A0 Matters on which the RSEA might be consulted could includ=
e proposed
>> =C2=A0=C2=A0 changes to the RFC style guide [RFC7322], RFC formatting =
in general,
>> =C2=A0=C2=A0 web presence, copyright matters, archiving policy, and di=
ssemination
>> =C2=A0=C2=A0 and cataloguing of RFCs.
>=20
> Feel free to propose elaborations, of course.=C2=A0 I think we might ne=
ed some with regard to the style guide in particular.

As long as it's clear that the power of decision is with the RSWG, I'm no=
t sure why. Over-specification should be avoided as much as possible.

    Brian


From nobody Tue Jul 13 17:35:44 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955B93A041D for ; Tue, 13 Jul 2021 17:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=dRdEq+Qn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QY7LfWZ5
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e92keHASMmOV for ; Tue, 13 Jul 2021 17:35:37 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82F63A0414 for ; Tue, 13 Jul 2021 17:35:37 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 38AF65C018A for ; Tue, 13 Jul 2021 20:35:36 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 13 Jul 2021 20:35:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=sPmzb2yF7Uyn44zNyTDmYRi8XHuM5y8 17anyPoNQ9vM=; b=dRdEq+Qn6SmnRcvktcbKIA7x88QrVGJpxfxxfNr5iWqFWfE r1umndtfKbj/U0LxsnHvFMhlk2jt/5LPVFWrpJ7WM0c1MtR1ylrKiLjYdX/uEYPt QvFrdSH162jP0GtIbRVDWIf0O/zbswWGMuCQw+gjAuGMzXUrF6iUcboJddPADu3+ MNc4C2fCSDjCBuQvSljktxy9uOZyUQOC56LHE8ltBTIdkAmU32XNUDGTsLoQtIhC g7vOgBrkmRQjA0opYCCaBrtZhu406W73DUDTd6e7w613KMOSWFLJCc9hUJjD1+Qu AzVXFWYuzdUWmACeT8fOeZC7qyCNdeRySU/nzAQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=sPmzb2 yF7Uyn44zNyTDmYRi8XHuM5y817anyPoNQ9vM=; b=QY7LfWZ5dn/JAuLMk1+8Sx D2oNrmkCflMeXnpD9HLwQrDBT3ONNvHQFSs3rIqRHIU4W8oWeVOaXS6a6PqlsA2z Vosr9l5nsc86q5aBZnVpXdefkaXr5Tez2usFEwBbbtGqJ7b/rKPqYhZPzu4N2IJB kVC3jiMwSd8drTKPcxGsXy9/Y8O5srez/V0fZTGH6fzdFCMwdNNq+O4cCDhJu452 3hoI/dxUm1r1+/8ih3hHbfFamRDjSfrFhuApRAXWSFruIKQUZGNbzY24sWa8mdst bVV5yTm2+EZBXO9zxSDkzOJek0vgkfEMvptKxbaMl7x8t3M2jkAxADIJpBG71dBQ ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudejgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id CCD083C0B35; Tue, 13 Jul 2021 20:35:35 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b
Mime-Version: 1.0
Message-Id: <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com>
In-Reply-To: 
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>   
Date: Wed, 14 Jul 2021 10:34:45 +1000
From: "Martin Thomson" 
To: rfced-future@iab.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 00:35:43 -0000

On Wed, Jul 14, 2021, at 09:47, Brian E Carpenter wrote:
>[..] we are substantially changing the role, so I 
> continue to believe that we should create a term to distinguish this 
> position from the overall RFC Editor function *and* from the previous 
> RSE role.

This strongly motivates a name change for me.  I do somewhat like "consulting editor", but I don't want to be forced to pick a name at the same time as deciding that a name change is appropriate.  That sort of conflation of concerns can be a cynical political ploy employed by those who seek to protect status quo[*].

So I would say that a name change is important, but I don't much care which name is ultimately chosen.

[*] To be clear, absolutely no accusation of that is intended by mention of this, unless you want to talk about a former Australian prime minister who managed to use that technique very effectively to get his way on a particular subject.


From nobody Tue Jul 13 17:52:41 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FB93A0896 for ; Tue, 13 Jul 2021 17:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 qzOmQ_gSgUB9 for ; Tue, 13 Jul 2021 17:52:35 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2ACA3A0891 for ; Tue, 13 Jul 2021 17:52:34 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id j184so23668707qkd.6 for ; Tue, 13 Jul 2021 17:52:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=PjPxHl1eRAd1C0lPkc3FN8xHS6RxFWCsgBK6EC4BVyc=; b=rPqn/hwk3roKbFAAGeb14WejlL1pXnBz9xer1/MtNVQUoETbDZpASza0dfdhZH2hQ8 7xDLQMRzQsuDy4drS6k8C3qvvWnizJuv5LdXy4UCISlMP6e21R1pvpvbHN2mGDoulFCN o8S4D3kQdrd1nBeLvRftPpz6/KXYImpL6Yc9TreLChvM8L5vgLO+0vNk12NiGSZyeFQH McpWNYMYtow5lXF2lY3YnlOPRmAuXh9jF6oeOh6lApq6YFwiErjpr/Su2TIjiYTqEKfw v5XjjATwpC7tpqha2JdcYNDpyIBGuGstaJGn5R0tSZTlFGTTdYG+6esdnTc2L3E7jw0W O8Hg==
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-transfer-encoding :content-language; bh=PjPxHl1eRAd1C0lPkc3FN8xHS6RxFWCsgBK6EC4BVyc=; b=V44qwqIKLwE2YmsnR5CJBU6BHle+wT6MqnhpbxmIb1W59PD91gKEcozsTR/VeXD0TN rCNFvX96Qu9DlMpqLwNmTK8GYmlMnY5eqdHTRGLwkhpS+rCJtZgIajP28CcL/Tp5nS6K gps9ErgYBxeib6qguNsAqRnhiXzIU9flGxvjTt+84myeF42RVyB3seV7VAqd/ZK77HyX NvN/kywrwrsAeJW+OKXx2ZvYoU3hxJLiNL6aafveMUOkj8/P354ncU4PuRoXpkjd83N6 o/LpXQuLB9XgHOhjG3YWTSvEa/ZDpXATRp5+huO9PSec3UUlXHZn6QwPDyskU+r1jHpP XK8A==
X-Gm-Message-State: AOAM530pT+9atTzQ/b2iQx74VW7bYTjiMw+vdXCt9dne82kgo3cHR/8e L+o+TPLZRIHyoJ4Ap+Ysp0o5AGCyBMjjfYx8D2U=
X-Google-Smtp-Source: ABdhPJyFxMI4R3Zx7f3j3prxteNBQh5Y1p68tJa1z7r1SFJmR5cbtYr0JzOOqxX9UOAwgWLfsplKmQ==
X-Received: by 2002:a05:620a:b4a:: with SMTP id x10mr7207312qkg.496.1626223952443;  Tue, 13 Jul 2021 17:52:32 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id x125sm291841qkd.8.2021.07.13.17.52.31 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 17:52:31 -0700 (PDT)
To: rfced-future@iab.org
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>    <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com>
From: Michael StJohns 
Message-ID: <8bd4dd63-c11d-5a67-caf2-d870c610f01c@nthpermutation.com>
Date: Tue, 13 Jul 2021 20:52:30 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 00:52:39 -0000

On 7/13/2021 8:34 PM, Martin Thomson wrote:
> On Wed, Jul 14, 2021, at 09:47, Brian E Carpenter wrote:
>> [..] we are substantially changing the role, so I
>> continue to believe that we should create a term to distinguish this
>> position from the overall RFC Editor function *and* from the previous
>> RSE role.
> This strongly motivates a name change for me.  I do somewhat like "consulting editor", but I don't want to be forced to pick a name at the same time as deciding that a name change is appropriate.  That sort of conflation of concerns can be a cynical political ploy employed by those who seek to protect status quo[*].
>
> So I would say that a name change is important, but I don't much care which name is ultimately chosen.
>
> [*] To be clear, absolutely no accusation of that is intended by mention of this, unless you want to talk about a former Australian prime minister who managed to use that technique very effectively to get his way on a particular subject.
>
But Martin -

Wouldn't a ploy where a name change is used to upset the status quo be 
just as cynical?

Mike



From nobody Tue Jul 13 18:02:39 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FA93A0C29 for ; Tue, 13 Jul 2021 18:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=2pAP/0ir; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DkluAiZL
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1O_adEIm0wg for ; Tue, 13 Jul 2021 18:02:33 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9186E3A0C1E for ; Tue, 13 Jul 2021 18:02:33 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C88E75C00AA for ; Tue, 13 Jul 2021 21:02:31 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 13 Jul 2021 21:02:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=v1cTKdDDn2hCzsUolOW6H/IgvPd9gYP WNxqVxKOeC7A=; b=2pAP/0irSsHoygF8EeRrdiCjYMyB2prSw1Qh6YONdqFirl0 7KZ+10MmMcQrmjN/qahwGmilW1Gog6L7EZ8/jR14vL+L0k34aCsTO1bfdhSwOhTy 2ElNDAv1R1CDtvI3TtXK6rh0SazyrBkeUcUkmsWbMPYltc/fYHB9+69EWVkDyZ9T yFlRBkUFR2wQJh11A/ihC0KkGPXkea4l/w22rF5IhkpYZHFqL6YCJ0prEgDrrUP9 wVmVZNPOaioL3ftF2ZvBF3ArNe5s9VrW3exS5wlgC1ZkGl0Qtjm24vvI9+CA1XSP W7dhw7k2F3rRxKNJd6meS+Ar6X2D/VO2zdQPpbA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=v1cTKd DDn2hCzsUolOW6H/IgvPd9gYPWNxqVxKOeC7A=; b=DkluAiZL755HSR31QyBhiu hK1TrEmMS21dlwSvEHNAb2DWh1+3GOVVFwv/TkgZGLikpPvpMHWytg2eJ2F5sB5j qUpfI6O8yhIOrgfQ90c+GFpPy9OEeuQuxuquNmuVqGYnxwSznhMpxhNwBmv4COyV GqAFLaYYK4fG8zPPOZA73VuIi7IFzqSav1pBY2RV36evDQFIWeQ9zvezVSQIEeK5 usdzpqScMg5ilXXHiTcNyllIE22l4vkf9VwLUlrPI6rJ9+sm1CkP1cuiMMlhhGGH VikZDRamc+YwLB/UPObdB9sJf/+8Fs4qcvQxjicrb/3y9LFHq3/oZyRHS6jSMmqA ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudejgdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 342753C0B35; Tue, 13 Jul 2021 21:02:31 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b
Mime-Version: 1.0
Message-Id: <1e470dd8-d3f2-4cc9-9e1e-e728843711b0@www.fastmail.com>
In-Reply-To: <8bd4dd63-c11d-5a67-caf2-d870c610f01c@nthpermutation.com>
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>    <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com> <8bd4dd63-c11d-5a67-caf2-d870c610f01c@nthpermutation.com>
Date: Wed, 14 Jul 2021 11:02:12 +1000
From: "Martin Thomson" 
To: rfced-future@iab.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 01:02:39 -0000

On Wed, Jul 14, 2021, at 10:52, Michael StJohns wrote:
> Wouldn't a ploy where a name change is used to upset the status quo be 
> just as cynical?

Good thing we don't use ploys here.  Instead we try to resolve our differences regarding the principles that drive decisions before making those decisions.  And we recognize when status quo bias is confounding that process, while also regarding unmotivated change as similarly harmful.


From nobody Tue Jul 13 22:34:16 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAD53A0FE2 for ; Tue, 13 Jul 2021 22:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.281
X-Spam-Level: 
X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixXvBVSpTZ9u for ; Tue, 13 Jul 2021 22:34:09 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1ED3A0FE3 for ; Tue, 13 Jul 2021 22:34:09 -0700 (PDT)
Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16E5Y1XJ080758 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Jul 2021 00:34:03 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1626240844; bh=ukfAWEleFqNN/71KiEKmXbggSz8Idgywx5xnz63fWBA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=N8fmkg+keYaWckhDHgMYR7xw9ho0BN4i5cH8ASk96fEWqJ9ls/SW5Qqlt/gQxvLA1 Qz1lexJphk6Xc3LSm8k52qcxDbcQC49+08O4YEb8IM4oQi444wikjaQqcBOI13RvPg pcGV0K7Y3XMP6e6cqP2+FkLzuVtslhwL3Meni+ls=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48]
To: Eliot Lear , adrian@olddog.co.uk, "'StJohns, Michael'" , "'Peter Saint-Andre'" 
Cc: rfced-future@iab.org, "'Bob Hinden'" 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>    <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch> <019401d77816$60782860$21687920$@olddog.co.uk> <2c76d4b9-950f-3e2e-0897-2e8e018d202a@lear.ch>
From: Adam Roach 
Message-ID: <8f01fe5d-bbe6-a3f9-adda-74bf98c4e661@nostrum.com>
Date: Wed, 14 Jul 2021 00:33:56 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <2c76d4b9-950f-3e2e-0897-2e8e018d202a@lear.ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 05:34:15 -0000

On 7/13/2021 3:05 PM, Eliot Lear wrote:
> I didn't realize RFC#s are a thing, but I imagine that is a pretty 
> easy thing to sort.


I don't know how much involvement the RSE recently had in this 
particular detail. In my roles as an AD and as an author, I can recall 
talking with Sandy a number of times about RFC number assignments 
(including trying to make the relatively complex knot of cluster 238 
numbering make some semblance of sense), but never with Heather. If this 
were formally part of RSE duties at some point, I believe it de facto 
devolved to the RPC many years ago.

/a


From nobody Tue Jul 13 22:44:41 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601B53A1066 for ; Tue, 13 Jul 2021 22:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.091
X-Spam-Level: 
X-Spam-Status: No, score=-2.091 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, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P-BztdqA4mp for ; Tue, 13 Jul 2021 22:44:33 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 27C7E3A103E for ; Tue, 13 Jul 2021 22:44:32 -0700 (PDT)
Received: from Lear-Air.local (31-10-155-187.cgn.dynamic.upc.ch [31.10.155.187]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16E5iPfH223387 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 14 Jul 2021 07:44:25 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626241465; bh=t+WYnIN8gEwHACnBihZDDxxJVN1Ok70Zo5tmG/F/dNw=; h=To:References:From:Subject:Date:In-Reply-To:From; b=Krrg8mNpRLqvsm7+40LM3MN1coUJSpxUQk/ORSYgQH2ogLqNnNviGm6TjwRFem+SB Lr96TIljj8BLKcc5CcVMgdvJOr1CDcBq2wI5JbMslnFv5COCRRGuTYOY9YVeWAASXP z8FSzN6D/HK/rjRHwMRF+O1lSglC4g6y+K1s+Nck=
To: Martin Thomson , rfced-future@iab.org
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>    <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com>
From: Eliot Lear 
Message-ID: 
Date: Wed, 14 Jul 2021 07:44:21 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rzwRfBE3g0WUCjivkQf7h4sr2f1F68LQg"
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 05:44:40 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--rzwRfBE3g0WUCjivkQf7h4sr2f1F68LQg
Content-Type: multipart/mixed; boundary="O54BDh8WVvUeToIWuHBI27jfIRMu1ZgNC";
 protected-headers="v1"
From: Eliot Lear 
To: Martin Thomson , rfced-future@iab.org
Message-ID: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
References: 
 
 <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com>
 <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net>
 <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>
 
 
 
 <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com>
In-Reply-To: <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com>

--O54BDh8WVvUeToIWuHBI27jfIRMu1ZgNC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Martin

On 14.07.21 02:34, Martin Thomson wrote:
> This strongly motivates a name change for me.  I do somewhat like "cons=
ulting editor", but I don't want to be forced to pick a name at the same =
time as deciding that a name change is appropriate.  That sort of conflat=
ion of concerns can be a cynical political ploy employed by those who see=
k to protect status quo[*].

We are long past the point where the status quo has been preserved, so=20
let's not worry about that.

Eliot



--O54BDh8WVvUeToIWuHBI27jfIRMu1ZgNC--

--rzwRfBE3g0WUCjivkQf7h4sr2f1F68LQg
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDuebUFAwAAAAAACgkQh7ZrRtnSejPQ
gAf+IbW+QDxJMmQnUzXbWJ8RYC7PAdVtX+wEeqW/v+16IpwOdw+ab+WbAiGbDER9pZMpdeMLXR8Z
e1etA89bOC9NzxwhdH+Xilgk2mYOF70hO7zeEuUibL3HXPANcfGyC9+apVUB3HCb3KOUvmOPoJY1
PzzUSF2+mxu+8PCZ2Zc/QeHyKD3xiyU9hojOhvnuPqo8hjJAoYdbc8vzWBPBRPZANP1gz2BF1Dap
jIEkPFibbkR9ja4Z/07+DZDuoQhxDXFVCsj883DYOTWX13nxeStcFtUVYAc4ymzHRabZ3BFUGPlm
DUdQ2CgDi5UTztKoyrKmxHhoqBCEpt9WGVQYtBX3dQ==
=4oub
-----END PGP SIGNATURE-----

--rzwRfBE3g0WUCjivkQf7h4sr2f1F68LQg--


From nobody Tue Jul 13 22:59:20 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D9A3A1121 for ; Tue, 13 Jul 2021 22:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.281
X-Spam-Level: 
X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGJn7sglMm1D for ; Tue, 13 Jul 2021 22:59:14 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605FA3A111D for ; Tue, 13 Jul 2021 22:59:12 -0700 (PDT)
Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16E5xA43085598 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Jul 2021 00:59:11 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1626242351; bh=Aiav7OEid1HzeQNg0TJi1fZZkIKGITVNuUzTYM/kRGY=; h=Subject:To:References:From:Date:In-Reply-To; b=cEEUTTR2qFyPmoSZ6drvmXOgwh0rGUpnlFYONK9vNKzMwiWCHSjQn9ym62rWFusG2 9flhe4vBdrRhqXydNBG/uKC8sB4mCoOP7qy+aYyvm0vLjoJH+YnaMDYt+UKk4kuceV ripuT2/37M+Ddt/wkdFMYkevjJR0yV7h4LPuIe3Q=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48]
To: Eliot Lear , Martin Thomson , rfced-future@iab.org
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>    <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com> 
From: Adam Roach 
Message-ID: <4b1a5bc7-a808-c122-5f7b-ca3c66d0ace0@nostrum.com>
Date: Wed, 14 Jul 2021 00:59:04 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 05:59:19 -0000

On 7/14/2021 12:44 AM, Eliot Lear wrote:
> Martin
>
> On 14.07.21 02:34, Martin Thomson wrote:
>> This strongly motivates a name change for me.  I do somewhat like 
>> "consulting editor", but I don't want to be forced to pick a name at 
>> the same time as deciding that a name change is appropriate.  That 
>> sort of conflation of concerns can be a cynical political ploy 
>> employed by those who seek to protect status quo[*].
>
> We are long past the point where the status quo has been preserved, so 
> let's not worry about that. 


I think Martin's diplomacy may have masked the point a bit, which makes 
it easy to miss (as you appear to have done).

I'll try to expand on the concern a bit more bluntly. There's been a 
long conversation in this group about whether this role under discussion 
is an executive role or a consultative one, and there's a pretty clear 
consensus that appears to have emerged from that conversation. The 
*appearance* is that the folks who were in the rough on that point are 
attempting to relitigate it by arguing to retain a title that has, for 
the past 12 years or so, been clearly associated with an executive role.

Whether this is *actually* the motivation is unclear, and I am (like 
Martin) giving folks the benefit of the doubt that it's not, but that's 
Martin's point as I understand it.

/a


From nobody Tue Jul 13 23:29:34 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44EF3A127C for ; Tue, 13 Jul 2021 23:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level: 
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouhRKkTMe4ZU for ; Tue, 13 Jul 2021 23:29:27 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 68E6B3A1278 for ; Tue, 13 Jul 2021 23:29:27 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1004::18c] ([IPv6:2001:420:c0c0:1004:0:0:0:18c]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16E6TMEt223860 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 14 Jul 2021 08:29:23 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626244163; bh=tVZ47Ge7vLTaO1tkN6n74DYNGkFmKnmRwREl3DxLYxQ=; h=To:References:From:Subject:Date:In-Reply-To:From; b=LGwNRebUOiKASFIAiTsJq79hboyf93xEfBs0hDJttFfsXdJuIsAv+9i4HifTWd+fC vr2mkKxrYbUOuKE5TyM+Ar3sUwzNOOc9bLOPZDR9wLA4uJ7iWiinQ7dElcgUwp8ame CR8N9xtaA5RatM++SPoCekW8fyWkP/aW/AgkPB/s=
To: Adam Roach , Martin Thomson , rfced-future@iab.org
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>    <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com>  <4b1a5bc7-a808-c122-5f7b-ca3c66d0ace0@nostrum.com>
From: Eliot Lear 
Message-ID: 
Date: Wed, 14 Jul 2021 08:29:19 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <4b1a5bc7-a808-c122-5f7b-ca3c66d0ace0@nostrum.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y3i3ToqfCOCJf2e6SCA8YU30uNBMQCVv8"
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 06:29:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--y3i3ToqfCOCJf2e6SCA8YU30uNBMQCVv8
Content-Type: multipart/mixed; boundary="rtJMgyDXpGmbLeOeODlgZuXZnaelv4hGp";
 protected-headers="v1"
From: Eliot Lear 
To: Adam Roach , Martin Thomson ,
 rfced-future@iab.org
Message-ID: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
References: 
 
 <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com>
 <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net>
 <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>
 
 
 
 <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com>
 
 <4b1a5bc7-a808-c122-5f7b-ca3c66d0ace0@nostrum.com>
In-Reply-To: <4b1a5bc7-a808-c122-5f7b-ca3c66d0ace0@nostrum.com>

--rtJMgyDXpGmbLeOeODlgZuXZnaelv4hGp
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Adam,

On 14.07.21 07:59, Adam Roach wrote:
>
>
> I think Martin's diplomacy may have masked the point a bit, which=20
> makes it easy to miss (as you appear to have done).

I'm sorry, I too was being polite.=C2=A0 I understand the dynamics.=C2=A0=
 I don't=20
think anyone is re-litigating the role. Moreover, it is not conducive to =

building consensus for people to say that they insist on a two step=20
process, since it leaves no basis for comparison. That's not how I think =

this group should proceed.=C2=A0 If people want to fill out the job=20
description a bit more, or seek input from the professionals on this=20
point, or take any action to inform ourselves about how best to proceed, =

that's one thing.=C2=A0 But let's not make this a political football.

Eliot





--rtJMgyDXpGmbLeOeODlgZuXZnaelv4hGp--

--y3i3ToqfCOCJf2e6SCA8YU30uNBMQCVv8
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDuhD8FAwAAAAAACgkQh7ZrRtnSejMM
+Af+NHNT//IrZqTrLWjqVX+qe0IsC2T0C+F6/rd+3EgqSmNKmlC5jE4Y7/2II6AjVEoo+n5KlrPx
CSKWfyBZPFk5ZAaGXRTcn6FOhqSRWOXZxtaZGjBER9Pi7y8bg6mSD9yeloSCQzccL4RClbR99uRD
c8GgEUSKnEmHYuKVUh6+xDDmXD2SGFkfgrE9v3j4tzMzx1BSFuuS7T7iyX+iE56cm5FMD5iEuQTE
nnGzE8K2v99OlTiEybMrHnMIA5gGfp+dKgPFCQW/Qioim1Ml5OfEGZbqe+iMHkjmS4vJZi9kjKRM
DYuyZJ5AEOmdIGjEylsO65Vsqlfb4veuFc41xvJ9yw==
=vU/6
-----END PGP SIGNATURE-----

--y3i3ToqfCOCJf2e6SCA8YU30uNBMQCVv8--


From nobody Tue Jul 13 23:35:14 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFACC3A12C0 for ; Tue, 13 Jul 2021 23:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level: 
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=fzb2F0NA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wgxdcg9k
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqNOa0gn0CSQ for ; Tue, 13 Jul 2021 23:35:07 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9833A12BB for ; Tue, 13 Jul 2021 23:35:07 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id BD0385C00E6; Wed, 14 Jul 2021 02:35:05 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 14 Jul 2021 02:35:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=G nlcU2rOB/kU+HZnN7uxJ8atBhsgCvxFPg4Z3uzq3U0=; b=fzb2F0NA9bmAUCK0T w7MP36hgqos0bgkU1iHn6Y2a3RCyxUfMPwdfAv6cu5p0cbRxdMXLMlegfofbgsXM ylyWshZHT84wTkZXPet6HtHCP+nP6gm/FQATa9vKDgwNF3Jhb8Njg4T2fHnEoc/W kX57rpe60MGcA9iY6JqLd0vzjqFknBNRzrchuTtD0vgwzMaywBZgpnSXEbC3YOEb UNDEOmxKoZc08B4SqmV5wQ6+PJlc082a7HEIWW/5B7ZG/rtpotzY4qgAGePuZ8k9 FHZnz0c29JHSdNzGySwlyJvT4/Ul6EvoSA94eWiY1yUovfbGDufLk2Zdphem71wJ ONszw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=GnlcU2rOB/kU+HZnN7uxJ8atBhsgCvxFPg4Z3uzq3 U0=; b=wgxdcg9kQ92a6/YX0YfhUTH3l/hQW3NdhcqX+DQXAn/JGbYB/dw2pQ7DU 3m2IRNKJix2Sj2/GzlDvzEFBFUafvQsbJk1vibRM/ZujVN4kxtM8DrLmjTMB17Pe tJ6Y9SwMYeXlnyHrcOXYd3rpNnKLrPUSkkAzUXD8xr45142EB1GrqFOce13pEo3J hkY7A+duX4XUDEio5NBoXmadRXmM91PfqV4vkAQaIjUq8cJAmQo4Dhn73BJ5rXgA sveYOKeMb/nSeX9MiKZzPGZyyouwUpsIqP88LdrjOMYgZqdt0kDuEST8IVc9GjsS aFqjs5pUV+TArdXAGex/ApaBTpWCw==
X-ME-Sender:  
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudejgddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeeutdekhfdtgffgjeejgeekveehfefhgfeugfehfefggeekhfeitdegudevudef ieenucffohhmrghinhepihgrsgdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgv th
X-ME-Proxy:    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 14 Jul 2021 02:35:02 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Nottingham 
In-Reply-To: <6125a073-3779-d32d-0252-28833a957d34@lear.ch>
Date: Wed, 14 Jul 2021 16:34:57 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch>
To: Eliot Lear 
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 06:35:13 -0000

I'm leaning towards saying that we should explicitly NOT give the =
ability to create streams to any single body, or define a process. If a =
situation comes up where we want to do this (for some value of 'we'), =
the expectation should be that there's buy-in from all concerned -- =
RSAB/WG, IETF, LLC, ISOC, etc. We can figure out a process then.


> On 12 Jul 2021, at 7:46 pm, Eliot Lear  wrote:
>=20
> Hi there,
>=20
> I opened this issue, and while it is related to who sits on the RSAB, =
it's a little different.  The question is really this: what is the =
process to create / delete editorial streams?  Does it go through the =
IETF process?  Does it go to the IAB?  Does it go through th RSWG/RSAB =
process?
>=20
> Peter asks this question: is it beyond the remit of this group to =
decide that?  My gut says that this is not this group's decision but =
perhaps an IAB decision or IETF decision or something in between.  To =
say otherwise would seem the tail wagging the dog.  Unless people =
disagree with this logic, I'll close the issue.  Please comment by the =
26th.
>=20
> This having been said, I do think this may be an issue for Brian's =
2850 update doc, since the IAB has previously held authority to manage =
that process.
>=20
> Eliot
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--
Mark Nottingham   https://www.mnot.net/


From nobody Tue Jul 13 23:38:02 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D283A12E4 for ; Tue, 13 Jul 2021 23:38:00 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=vamDnvnG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HN2AUdRr
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flnBW8glxR9V for ; Tue, 13 Jul 2021 23:37:55 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAE43A12E1 for ; Tue, 13 Jul 2021 23:37:55 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B7FC15C0079; Wed, 14 Jul 2021 02:37:51 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 14 Jul 2021 02:37:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=r sdbLSI8JbFpPPdI3+Kl35NeSluvsJQaw7xhS1tIT60=; b=vamDnvnGj9aQ9KjsU fk8kfFFdcSRDZ+78xEVTIhRXAhSrOsRoY6agrjmkQn9mCP/eO24ClGi4qGrwVO/z t6Eeejv9eLKflrr+TVP8No5cFic522UOMiKCDEu+FjwgqNq5iaPWo6fDr8H1dEQ3 uiJk3Xl0io2EEAYBUkLPFXk8+a8E572MvhsCzsMGzdxkl4bZN7++gEkg58VFPQNJ Ep97rHpv86FSgnZw7lwprAmV4frB9UCDsM7encIFm4CZk0JQtSiPDaZuhEA52ciP ETaNDZKkHiZvFLKMkZC1M/Lj6s/3EXhgX3g0nIKaX5xidxzDHBBXnmFur/0JqdxH RntYQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=rsdbLSI8JbFpPPdI3+Kl35NeSluvsJQaw7xhS1tIT 60=; b=HN2AUdRr0CKOQezdMm5OMwqlLlbdAUS12Denlxh7FLD55qmfAOiGTX0lv w/2N5j5kNHsrdBOVkivfYRYm9L3S7XSjlNc6jOy+1wlGhbv6NqOJLFdwvzONb/Ro PMbfQallr2h7aZb7yym54C94pBgvMtIBBRKh34aIsbkWO3cCERj8uuM9HXm2P3iU 3yqCCzj5fYluLIZr/7fT8d37J3DzpuVWmEtyY9LLiZi5yCW3T6OElWkVouF/KtoP RdF6zulVmi9W66FMxd6fPvZtmKFWUBS49ga1mouJDyH530oMvI/3xx2yVudiGdcZ /0UvOUcu871/XuGN7+cDvplvX61iw==
X-ME-Sender:  
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudejgddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 14 Jul 2021 02:37:48 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 14 Jul 2021 16:37:40 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E5B4000-84FD-4C07-98A9-FEEFB3AD09B8@mnot.net>
References: 
To: Eliot Lear 
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 06:38:00 -0000

> On 29 Jun 2021, at 3:54 pm, Eliot Lear  wrote:
>=20
>> The IAB and IESG delegates shall serve for one year renewable terms.  =
Should a delegate become unavailable, the appointing body MAY replace =
that individual to complete the term.

This text bothers me. Why are we defining how these bodies are =
represented in *this* document -- shouldn't they choose their own =
procedures for doing so?=20

Practically speaking, there are going to be times when it's a pain for a =
representative to be replaced on a top-down schedule, rather than at the =
convenience of the appointing body. Also, it raises questions about =
whether there's proper transfer of institutional knowledge.

Cheers,

--
Mark Nottingham   https://www.mnot.net/


From nobody Tue Jul 13 23:45:03 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492FF3A1333 for ; Tue, 13 Jul 2021 23:45:02 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Uab6rC7B; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EQhuivYb
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxHcnwM6KIWQ for ; Tue, 13 Jul 2021 23:44:57 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B833A1331 for ; Tue, 13 Jul 2021 23:44:57 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A26A95C014D; Wed, 14 Jul 2021 02:44:53 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 14 Jul 2021 02:44:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=p DM15H8OFWSfMbevTiiqF08Fe+58/nRsAGQPx0yAMQw=; b=Uab6rC7Bbl1Y1bbwA ZY/9Z/3HTMn9OfzFYO7ZnC1QJIzCXyqEUjFm6BSZ7r6mlrae8/0a5t56TyMxYl0/ Pm4t9CpBeOfqKxOdWXdeBlSMgjuUyiBoZwPbjeL6EEmZhp4wDe5u/ZX84GKLw1Ht Hu+TUSjD/nDDsD/ToqYDGoNORwA0cTGuE1WvVZTLloGCa/EuubU8sCNtZKQgXRl7 s+oVDhJketI52k2J51drhUz/wMgP9868Z3j+iPwlMuwn/lE12tTF9u5Og4SHYtFc blrqS0B4dh4S+0XPuQno9GPDFL+tPBYpAtG4ILaK46pFpuqQKMJ6AJf7apj3rEqK zpg2A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=pDM15H8OFWSfMbevTiiqF08Fe+58/nRsAGQPx0yAM Qw=; b=EQhuivYbnVA0pxH/ZtpUxWhW8uVwg7pNc4dR742nJ2+kUuRxRp1frYxN2 RaIYLDo7x0hTR2aOJkcsjE00la1DO71JNuNvBrOL8CrO1I+0p6BAdCN1elgZ16yt xiqXSi0ny5sR3dDQTbhKLj2ek/v2xsmXHi2PfvJhcqGkY5ffBeVTgc0ZMSKCpagR FbBFbTv9be6G5fB0sEapgnxvDGGPzKwxpH1M1nU+NtEvbqaEUZP6OOyGa65rDx3Q lqHzAXNp2JYRa97G6doT/m00hL0jLHZku97Yb3YmlaMja97rlKMjhXd5EOuaPOGi 6Xez7tH7MfpXUsUUECY/LP9RrcNEQ==
X-ME-Sender:  
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudejgddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeeutdekhfdtgffgjeejgeekveehfefhgfeugfehfefggeekhfeitdegudevudef ieenucffohhmrghinhepihgrsgdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgv th
X-ME-Proxy:    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 14 Jul 2021 02:44:49 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 14 Jul 2021 16:44:46 +1000
Cc: "rfced-future@iab.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A5203B5-C63D-44E0-8D72-245D4A3AAA93@mnot.net>
References: 
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 06:45:02 -0000

+1. This position is changing substantially, and the name should reflect =
that. We don't need the baggage associated with it.

To the folks giving examples of other positions which have inaccurate =
names: that's not a good argument for using an inaccurate name.

To the folks who are arguing that this will confuse the community: =
there's already substantial confusion in the community about the RFC =
Editor function. A new name gives us a clean break.


Cheers,


> On 10 Jul 2021, at 7:03 am, Peter Saint-Andre  =
wrote:
>=20
> The role played by the technical publishing expert in version 3 of the
> model is different enough from past roles that I suggest we should not
> use the name "RFC Series Editor" but instead "RFC Series Advisor".
>=20
> Peter
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--
Mark Nottingham   https://www.mnot.net/


From nobody Wed Jul 14 00:23:04 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AB33A14EC for ; Wed, 14 Jul 2021 00:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZXEXM5shOk5 for ; Wed, 14 Jul 2021 00:22:55 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 62B463A14EB for ; Wed, 14 Jul 2021 00:22:55 -0700 (PDT)
Received: from smtpclient.apple (unknown [85.131.57.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 2A30760034E; Wed, 14 Jul 2021 10:22:48 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626247368; bh=jdnmCw6f0A6Ri7ta+HMJEp7cNG7WBpGL91cuAbml8aY=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=AkCxcXqXHiYVAzuYxalRE/lc/wmvxI02ww3b8pgQ0x3ogX7Ety/kliC1yITmXO1y1 k5mKoUywzG84XGUvZaTfmTZdspTb1osoXsVBfzJSeBuEMRn0VfSKHsJaWsBBj9NFWV lk9p7ReFFUA8i0v/KXfROXuY0h2rKOyD/a92JlI4=
From: Lars Eggert 
Message-Id: <562A7D1A-0767-4EED-BFEB-B399FAAE4026@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_DB3EC7DF-D217-45E4-957B-56D0A4222AF5"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 14 Jul 2021 10:22:46 +0300
In-Reply-To: <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>
Cc: Eliot Lear , rfced-future@iab.org
To: Mark Nottingham 
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>
X-MailScanner-ID: 2A30760034E.A14B7
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 07:23:02 -0000

--Apple-Mail=_DB3EC7DF-D217-45E4-957B-56D0A4222AF5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 2021-7-14, at 9:34, Mark Nottingham  wrote:
> I'm leaning towards saying that we should explicitly NOT give the =
ability to create streams to any single body, or define a process. If a =
situation comes up where we want to do this (for some value of 'we'), =
the expectation should be that there's buy-in from all concerned -- =
RSAB/WG, IETF, LLC, ISOC, etc. We can figure out a process then.

+1

Creating a new stream is such a rare and often special event that I =
can't see us defining rules on this in the abstract.

Thanks,
Lars


--Apple-Mail=_DB3EC7DF-D217-45E4-957B-56D0A4222AF5
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-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmDukMcACgkQVLXDCb9w
wVeYDg/+L7G/QV3D04N2198/kiU5SCtS5eNgzCYPPmbCk9h4Asg/6e8SGSDZ3LYn
B2P1YyVN0C4Uze/2iT+Je5M/bwDyN/c9ogwhKo2RlOLMqx3T61Tmcl3HbJ6L7W93
PKBy/5o60Rk1INMYozLS+ciKRYtfFUVnUgX45uGrJsQXhSnlDIfMrsSCC/kQcEv7
NEdp+zmqKbW2tK4eD57IgRIEZq8oHUH6q/JuLZ1lIZcfIi3gecOlpS6/rNqS2vUC
3lZNFrQfokGeEqk/Hzm/R933d1kW/kkSQ5NeeYW8pnhL8U6B9xEgaIVlEBRFbg6z
qgIi/8C5JODmcnxjEZ5CE7nBz5ZYP+xFSYTO5sUwWlJo4sV5E5GsxJ2gqxigfO71
y54ZwO9j/6qyDnUOdLzVAgPzSHD8JCu8yuXjUZqrxYnuAca8G6/yVx7vEAcx/7S/
qppHiUxLKCZPyOqVvxUr7M2PYMdo9sPCQNDHC6hdAp90wvFh7Jk4wDllhtLtdMZF
ravCLIa+qATznSLoR50fKLVfEE4vmcRrgTVa5NuPaD+Ms9ZZOY10RdruuB+PGMGh
IN61fs7Zg2KII4qCRVwUxa0f4yp21vA8I5IsXRwwjQA+TLpySoZ9IRVZgmMvrWG8
xi/QpxdySH4OJqNAHC58002MVCFK6Uc92rjMWWRyzcxtD/jWpmo=
=FGMK
-----END PGP SIGNATURE-----

--Apple-Mail=_DB3EC7DF-D217-45E4-957B-56D0A4222AF5--


From nobody Wed Jul 14 00:25:37 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CB63A14FD for ; Wed, 14 Jul 2021 00:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g-_EiWmKjTt for ; Wed, 14 Jul 2021 00:25:29 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 0B2513A14FB for ; Wed, 14 Jul 2021 00:25:28 -0700 (PDT)
Received: from smtpclient.apple (unknown [85.131.57.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id DF56260034E; Wed, 14 Jul 2021 10:25:22 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626247523; bh=uJqODbTadCdf0jFO57ftS6dFQ/Iy/Yzpah2efGWlEkc=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=S1BK7bAU2e1+vt8pwmoyEJjvhnzhwcuuR4yC71ppbhqmoOoWBIFOlDcl1ELHEmtx0 zb9it+TKyBzSuS3es+8PWBv+stIqIAj8pFXH77A8ZG/WOrGYHWbd09v8U1RmM0iGc1 ilinPOM6/KQUdkrpnWCXGaDaSp+bKAByBhQ123QQ=
From: Lars Eggert 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_BE1E8B1C-D188-4843-881E-CAFEE69814CC"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 14 Jul 2021 10:25:22 +0300
In-Reply-To: <8f01fe5d-bbe6-a3f9-adda-74bf98c4e661@nostrum.com>
Cc: Eliot Lear , Adrian Farrel , "StJohns, Michael" , Peter Saint-Andre , rfced-future@iab.org, Bob Hinden 
To: Adam Roach 
References:   <92f0ed29-1689-e985-37ac-a45dd02d082c@nthpermutation.com> <3e7b97b7-253a-bdd6-1c0f-93758a8ac1cb@gmail.com> <02994423-D9CB-4996-B831-E87900EC9250@gmail.com> <5a3b32de-a8ee-a101-b3a7-b89e7871a2db@gmail.com>    <02a6a335-edb1-6b20-ac44-5655aa9359f6@lear.ch> <019401d77816$60782860$21687920$@olddog.co.uk> <2c76d4b9-950f-3e2e-0897-2e8e018d202a@lear.ch> <8f01fe5d-bbe6-a3f9-adda-74bf98c4e661@nostrum.com>
X-MailScanner-ID: DF56260034E.A2129
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 07:25:36 -0000

--Apple-Mail=_BE1E8B1C-D188-4843-881E-CAFEE69814CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 2021-7-14, at 8:33, Adam Roach  wrote:
> I don't know how much involvement the RSE recently had in this =
particular detail. In my roles as an AD and as an author, I can recall =
talking with Sandy a number of times about RFC number assignments =
(including trying to make the relatively complex knot of cluster 238 =
numbering make some semblance of sense), but never with Heather. If this =
were formally part of RSE duties at some point, I believe it de facto =
devolved to the RPC many years ago.

As another data point, the recent assignment of RFC numbers for QUIC was =
also coordinated solely with the RPC.

Thanks,
Lars


--Apple-Mail=_BE1E8B1C-D188-4843-881E-CAFEE69814CC
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-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmDukWIACgkQVLXDCb9w
wVcX4A/6A4nJkFu45nVcIVHReKZ1djiGjX7IuMMaiiXqyf/Xof4S+zQgztph644u
BnyjTXvZNA3aAqS6Pq3y54TpD/yotGNJPmdoCkZ4+aIzYPZpw0yCvonN2Z/9QneK
v+2xrg5isYySaLpH8wQJ+oghY0DUgd3syqdl31z1iMyyqaOuY5oO4JmAGFDWqwXu
MnE/adLcSsZAa+1LsABnVODGAwTjTNvUepEVHAKiRPyzJJfrvW6KLEZ0TlqkNLC0
oX6RvKZkytJbIkJVMC5yLGDW6tfXBQt1uc/ewRYkTuLTPGdBHaFgQ0ssGYExfGRg
m9UaAflnpNY/pdRJwNHoelz1So68CCkoDEnpyaz4BxQflofBCWBllvqJa9LYHZvf
PSuaaSbpuJzI7+dI9pCH3axmCBIHCIHYZU6OgFHQWb3oLPXwp8iMggg0lsXBZrtx
yrwddQqw42ybd7JpdPGLSa2tmvNDof/DUsnB30kKEbMajRwiUW1zr+5XngnUNoGO
NHleyT+OUlCPLvs2tgvvOZNi9bVaHVOGoQmGgYdY0yHOJU+HGomQNfXxqWNMCTNN
mxo6PMgE8mobRQwlNYkTG4RKstiw50ksv29NCZD0Uwi+L5sAHJ4I/jlGd2IERSZL
P8TU8ZsW8Bzo1FXf14L5Uj8pYvtIx8iWQZ9zaZYUwDxoEAOIXJs=
=3efA
-----END PGP SIGNATURE-----

--Apple-Mail=_BE1E8B1C-D188-4843-881E-CAFEE69814CC--


From nobody Wed Jul 14 01:11:40 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83633A17C1 for ; Wed, 14 Jul 2021 01:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejs0tUdDh1vg for ; Wed, 14 Jul 2021 01:11:35 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 A6B763A17BF for ; Wed, 14 Jul 2021 01:11:34 -0700 (PDT)
Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:29ad:f49:e23c:ee57]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16E8BSPd224756 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 14 Jul 2021 10:11:29 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626250289; bh=VbQayWCenoZbfLwq05rjaX9alRfon/4x+XpiS7dMNwQ=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=N+liDWPOj6z2W8xk8n8Kdo6o7Uvqj8Jpg/8V56WB/SYngFzyic3fVYRz5S/bQhOKT axnncdHLgnSLB9auaDPKHyysaMtF4xDsInYXzOqWs3XE42VOazobrpwx+Jge9poZx9 bgAFfxVOItRYlag78fqYag8Cymv3Zzk+P6juocZM=
To: Lars Eggert , Mark Nottingham 
Cc: rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net> <562A7D1A-0767-4EED-BFEB-B399FAAE4026@eggert.org>
From: Eliot Lear 
Message-ID: <9317e4f8-e0cb-c376-7937-deef62f19ef7@lear.ch>
Date: Wed, 14 Jul 2021 10:11:28 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <562A7D1A-0767-4EED-BFEB-B399FAAE4026@eggert.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IvfpMmWPIvjJFCIEKpMa1GKaubJNBzVYa"
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 08:11:40 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IvfpMmWPIvjJFCIEKpMa1GKaubJNBzVYa
Content-Type: multipart/mixed; boundary="jzb9GktIrJ8QVXDxGjZDzfeWB5xDQZ0sC";
 protected-headers="v1"
From: Eliot Lear 
To: Lars Eggert , Mark Nottingham 
Cc: rfced-future@iab.org
Message-ID: <9317e4f8-e0cb-c376-7937-deef62f19ef7@lear.ch>
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new
 streams?
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch>
 <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>
 <562A7D1A-0767-4EED-BFEB-B399FAAE4026@eggert.org>
In-Reply-To: <562A7D1A-0767-4EED-BFEB-B399FAAE4026@eggert.org>

--jzb9GktIrJ8QVXDxGjZDzfeWB5xDQZ0sC
Content-Type: multipart/alternative;
 boundary="------------A0E2414022572830B6015C11"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------A0E2414022572830B6015C11
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

If I understand you both correctly, you are saying that we should defer=20
this question until the next rare event.=A0 With the understanding that=20
there is very strong (albeit not perfect) consensus for a new stream for =

the RSWG/RSAB products, and that the existing process will prevail=20
(e.g., IAB approval) for this new stream, then we can defer the rest for =

later, if that is what people want.

Eliot

On 14.07.21 09:22, Lars Eggert wrote:
> On 2021-7-14, at 9:34, Mark Nottingham  wrote:
>> I'm leaning towards saying that we should explicitly NOT give the abil=
ity to create streams to any single body, or define a process. If a situa=
tion comes up where we want to do this (for some value of 'we'), the expe=
ctation should be that there's buy-in from all concerned -- RSAB/WG, IETF=
, LLC, ISOC, etc. We can figure out a process then.
> +1
>
> Creating a new stream is such a rare and often special event that I can=
't see us defining rules on this in the abstract.
>
> Thanks,
> Lars
>
>

--------------A0E2414022572830B6015C11
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
If I understand you both correctly, you are saying that we should
      defer this question until the next rare event.=A0 With the
      understanding that there is very strong (albeit not perfect)
      consensus for a new stream for the RSWG/RSAB products, and that
      the existing process will prevail (e.g., IAB approval) for this
      new stream, then we can defer the rest for later, if that is what
      people want.

    
Eliot

    
On 14.07.21 09:22, Lars Eggert wrote:<=
br>
    

    

      
On 2021-7-14, at 9:34, Mark =
Nottingham <mnot@mnot.net> wrote:


      

        
I'm leaning towards saying=
 that we should explicitly NOT give the ability to create streams to any =
single body, or define a process. If a situation comes up where we want t=
o do this (for some value of 'we'), the expectation should be that there'=
s buy-in from all concerned -- RSAB/WG, IETF, LLC, ISOC, etc. We can figu=
re out a process then.


      

      
+1

Creating a new stream is such a rare and often special event that I can't=
 see us defining rules on this in the abstract.

Thanks,
Lars



      

      

    

  


--------------A0E2414022572830B6015C11--

--jzb9GktIrJ8QVXDxGjZDzfeWB5xDQZ0sC--

--IvfpMmWPIvjJFCIEKpMa1GKaubJNBzVYa
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDunDAFAwAAAAAACgkQh7ZrRtnSejPY
8AgAv2TeToQaLoTXzfP4h4O8f4cA4mDlXCRyBK6alTneLxVoIi/SkGvI1/lbg9ENBBWC6C0q52lR
iq/HKpR8PE7NOG2S4R21rMiCVW1I6DzGVayWSi4RjBFeVbId7lRvPTZzrHoMJ3bCSgd6nQgBHruJ
BFhHPDGlF03olbYTbwO0La4w32NmAPSCYlknDCx7pwJu80mQ3eKnZwOQ2oe3qv1kY0uK8X/i6awG
pHFZjKgUUxi66omnE9GYOaRHIKeuO00sOEQZje8idpcGSFUwvhzXdLHtFn1bSGt7j1A0G8F4AYF3
c9z7bojPbTh8GfuiqpqDT81RNkHlwHM/qWyi0RF4+g==
=89LS
-----END PGP SIGNATURE-----

--IvfpMmWPIvjJFCIEKpMa1GKaubJNBzVYa--


From nobody Wed Jul 14 02:55:36 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4153A0C20 for ; Wed, 14 Jul 2021 02:55:34 -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 M7zxCKWUHUTD for ; Wed, 14 Jul 2021 02:55:28 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 DBF613A0C18 for ; Wed, 14 Jul 2021 02:55:27 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id a12so2611216lfb.7 for ; Wed, 14 Jul 2021 02:55:27 -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=woSfGvumYz6JzUs3QgGKEiSii/ZCLQG2ro6kY+36yfY=; b=t0v932cm1/4+WppJPKR9uzTKlwzTeSWizJGgfxe943IX8qART8BRhPz/JdtrR0kQwz dRxL5q9v5/GRzLA7UzfL2fstsciWKObPDXOw6ZgzzhL7M+vaLNd4BTvH6vzUln1gsJRr KXf7jnLOtxrPtvkdkmGw+O7XPf3KXs6pgP0hhf9weZLb+gbdYvIrfaEqxgOu3weEaj1C GKJYPQ5Lgy+xEmYhWjizEBiWkiLRfRiq/esyWmDtSsTR9URmeljWRMYP7bdoF1h7iASa C3uQMVYG2XsmNqGn+ULK2xm2dQZtF62l89Cy+OsLFXebY18EOIsap2N+OMVjCjgnVu7S dr1g==
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=woSfGvumYz6JzUs3QgGKEiSii/ZCLQG2ro6kY+36yfY=; b=aPtVfaq6Kh8udKEWwcfdUcs3eX4e0yjxj86DneQ1Mt5yZ62fqtounZULu7ZpRWpmce uE1wQOyfjaFr9S+Z9YmjLdxZWWdbWdImTIMbYW5VSXW6K8mkfnYGxbo/D3lBGUrxL8sZ nb+i6GK4SdBxXiA3xssYAoJN4WVU/SLJ0noty4KLT3vTNVSFUFDdpSwbVdML1TMjq2EX woAZ77LqGtDUNaHbIlht17KgMm9oj+u4BDgOj2IeaSvfMqndOPFiLP6I4cWjNtdqVwnP x6g80K+4rmoVnDb9AqwwapCfQVHSN3xr8YQ7NQwM2igoq2VudZ0Iis259vfvNepJ4nkO 6new==
X-Gm-Message-State: AOAM530ozH1GgtVCNaeSjE/3dc+PYYRz7DnWE2TnUDm3d37bu3iBeFmK zElzzfx5H3XjvgEak0TOcV31d3GzB/2dizopOiU=
X-Google-Smtp-Source: ABdhPJwfbIsuNwfL0WGYuRsx52XBYrKQcVlansGe3V2UY1unuCeIPm3R/AtCISs290lotOne2RG37c80/OgTb2MAay8=
X-Received: by 2002:ac2:48a9:: with SMTP id u9mr7327955lfg.277.1626256520894;  Wed, 14 Jul 2021 02:55:20 -0700 (PDT)
MIME-Version: 1.0
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net> <562A7D1A-0767-4EED-BFEB-B399FAAE4026@eggert.org>
In-Reply-To: <562A7D1A-0767-4EED-BFEB-B399FAAE4026@eggert.org>
From: Brian Carpenter 
Date: Wed, 14 Jul 2021 21:55:09 +1200
Message-ID: 
To: Lars Eggert 
Cc: Mark Nottingham , rfced-future@iab.org, Eliot Lear 
Content-Type: multipart/alternative; boundary="0000000000003ddd2305c7125ab9"
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 09:55:34 -0000

--0000000000003ddd2305c7125ab9
Content-Type: text/plain; charset="UTF-8"

We certainly shouldn't define a process, since every case would be
different anyway, and the question may never seriously arise. But I feel
the question of who has authority needs to be defined - or perhaps
explicitly stated to be undefined.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Wed, 14 Jul 2021, 19:23 Lars Eggert,  wrote:

> On 2021-7-14, at 9:34, Mark Nottingham  wrote:
> > I'm leaning towards saying that we should explicitly NOT give the
> ability to create streams to any single body, or define a process. If a
> situation comes up where we want to do this (for some value of 'we'), the
> expectation should be that there's buy-in from all concerned -- RSAB/WG,
> IETF, LLC, ISOC, etc. We can figure out a process then.
>
> +1
>
> Creating a new stream is such a rare and often special event that I can't
> see us defining rules on this in the abstract.
>
> Thanks,
> Lars
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--0000000000003ddd2305c7125ab9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


We certainly shouldn't define a process, since every =
case would be different anyway, and the question may never seriously arise.=
 But I feel the question of who has authority needs to be defined - or perh=
aps explicitly stated to be undefined.

Regards,
=C2=A0=C2=A0=C2=A0 Brian Carpenter
=C2=A0=C2=A0=
=C2=A0 (via tiny screen & keyboard)

On Wed, 14 Jul 2021, 19:23 Lar=
s Eggert, <lars@eggert.org> wr=
ote:
On 2021-7-14, at 9:34, Mark No=
ttingham <mnot@mnot.net> wrote:

> I'm leaning towards saying that we should explicitly NOT give the =
ability to create streams to any single body, or define a process. If a sit=
uation comes up where we want to do this (for some value of 'we'), =
the expectation should be that there's buy-in from all concerned -- RSA=
B/WG, IETF, LLC, ISOC, etc. We can figure out a process then.



+1



Creating a new stream is such a rare and often special event that I can'=
;t see us defining rules on this in the abstract.



Thanks,

Lars



-- 

Rfced-future mailing list

Rfced-future@iab.org

https://www.iab.org/mailman/listinfo/rfc=
ed-future




--0000000000003ddd2305c7125ab9--


From nobody Wed Jul 14 04:42:07 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8AB3A041D for ; Wed, 14 Jul 2021 04:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr_vNCucJ4oF for ; Wed, 14 Jul 2021 04:41:56 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2098.outbound.protection.outlook.com [40.107.22.98]) (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 00BE43A011D for ; Wed, 14 Jul 2021 04:41:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=edQFHah23GmutaH8VZ28sS5CNokZPuJ+RZmaT48B+Jr13Mpa2tE4vOt2iR6PBH9nUtg3KtevIr7f5Us5oV4UO2a3sS7yT8N9K/NlhJ4FWRUP3LPaPYdAb65/FNvpq1tQmrlTwxCIEjImoZv/r/ha3GwDigRpd16xvik1inQFm4I9Z/AwTpiOEVy5pJbIK7fs6WET3nJTlLT5EuVkI3xtsxxrT9ivnd+gtUOu2+cyHJDIA6xWOIog6MMZ1nKri7NJzSFtAjr8rkqdTtWPi4DU187aXhxXjCE7M28vsLIFa4ALtVhKERcimNYZEba7VYLx3vR4HjqWRMjivtTIbIbhRw==
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=2W4urKihs/6eiG/jEXF7VVb7ctOlShlr3G6LtXQ8Sq0=; b=MARYxLYw1ZIiZEWe5M1SroiW0lBV7qDjTT3F/mhiRoVIlPmKLhFyKJtVsdX5uLnU0B7UPiwqt4O7/fGKmPlCHBZkByBy/OKIkknGwk7ySHwNKnCgBtr1qOJY5QUWki0cICZAWXIaygwT6a1LddfT7YDX/AmB8H7+LFNEXRqagLKjfILSivHAIyD+Az0REI/HzkxW+r/ngNyhsuiHo/JzVzm93i79pGiwzTzGTrlXMymNzZFzEvpkKMT9lFUzgGWAYAmRq+LJ0IDBzjFHAyKY7mVvfQYPHBncZdktVenCQlV8uAoBUirQLByKD7JE+om/xoQxOKZsYyUQ16E+t0A8qw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2W4urKihs/6eiG/jEXF7VVb7ctOlShlr3G6LtXQ8Sq0=; b=p1iBlAK7BcQlKk7ax7KnX5U6QERqztqrcE5YJCYTTgPYtqzc19f0/++waHi3ODbUTBz4vBb/IOSZCDzlpH7Yks6OwQ4PalvQmkFNZxDVvOvWGIzVBn3W9WTbyJuO6uPH73QfwkQzkV+HKLVkvZAablnT6Bni62nWFH/CpqqBcKbydhXWbvvqnRP9GXdqadFcgPeFRfDMrOOG5p48kXlu0tB2MIQes0Yt8IJAs8icBw/p7AM3HFei4qXMTg+f/FOFqLraRj/wYP3o5emrODUrNPF9VNRdlrW8jAAKzdzznfJfyxhVquHUez/9pmm2V+8t9Ho6dy9Rg5RHg9noELn0wA==
Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=cs.tcd.ie;
Received: from AM6PR02MB5112.eurprd02.prod.outlook.com (2603:10a6:20b:90::21) by AS8PR02MB7045.eurprd02.prod.outlook.com (2603:10a6:20b:2e1::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.23; Wed, 14 Jul 2021 11:41:52 +0000
Received: from AM6PR02MB5112.eurprd02.prod.outlook.com ([fe80::c0d5:2359:eae3:f5d4]) by AM6PR02MB5112.eurprd02.prod.outlook.com ([fe80::c0d5:2359:eae3:f5d4%7]) with mapi id 15.20.4287.033; Wed, 14 Jul 2021 11:41:52 +0000
To: Mark Nottingham , Eliot Lear 
Cc: rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>
From: Stephen Farrell 
Message-ID: <05a5a9a0-c052-9a5a-1904-9d5a7aced59c@cs.tcd.ie>
Date: Wed, 14 Jul 2021 12:41:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
In-Reply-To: <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="254w3msH9cfM1m4aMDDZotSJ6HxulPzgp"
X-ClientProxiedBy: DB6PR0601CA0020.eurprd06.prod.outlook.com (2603:10a6:4:7b::30) To AM6PR02MB5112.eurprd02.prod.outlook.com (2603:10a6:20b:90::21)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [10.244.2.124] (95.45.153.252) by DB6PR0601CA0020.eurprd06.prod.outlook.com (2603:10a6:4:7b::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21 via Frontend Transport; Wed, 14 Jul 2021 11:41:52 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 3a2df0b4-b7b3-4d3a-e19b-08d946bc5fcf
X-MS-TrafficTypeDiagnostic: AS8PR02MB7045:
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-Microsoft-Antispam-PRVS: 
X-TCD-Routed-via-EOP: Routed via EOP
X-TCD-ROUTED: Passed-Transport-Routing-Rules
X-MS-Oob-TLC-OOBClassifiers: OLM:4714;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: kg8WNAWKpOAGNV4yDutTMiM1zpLBB3L8n2YyFKxmu1XmmeneeBkL/l6fNWzUeog3TGejw6/sMsT8pCHdQ5iCpFBktWgxU+9Qzo56N0BVHaxe2c7VSvBhHrr39vrg3GXf7GqWwsM+YwHcjzj+zHhh9QFJg3n0XAHG664jzQL6BOvg1OUTJsB1yQ21Kqa+vR5HC06lHBBP+kcjb8MqQzVYp+SEsJg8k6GWbl/Opdeows0/i+TvcQOJh9EUWSXI/tUmizfhFA0ADx9SpotvWiBm4uAig83ueK7KwECt0564mAKYBZHEZzAKJCtk/8tOQv1uuwSQLOiGGCBF9ftKax12OQeXXJiTQhmgXDGoUnHa4zzJqleqdAAIwznLIBB0zunmJhxWOjQgzIBjSYQORpWlkUeCRGmTWyhPJoU5K4xASEtlZ1xaspwJ4+qo6Zfsx0uxM9zEK26NpkJDJ1yClk7EaKA38WwoLQsLTZ3kiY8YzZGWl19VTuTYooZWQfIWkOHytY26TwrgiZp0WJm6YQ7MWr+ybfDrnMaxhPO2zeL3NvSdhrO0TwO/JTMnT6KBp9rEJe5QJzArRdltyuiF4KCfcprk57eXNUXJeikKlsjlFQI5Yc3Hlb2lFIwSqaw1YbDcIkELz+EJ4M5XjVicL6rK+BpkNEpkNrHgcv0ilgRDWqfjIOujSLKa6VwOWRKBXzaRBjZ8OvkSqvkrJqQVM1w/AaUmhqWDGf9WtQJMzurQ+qGzMCq4wjvscy3N69IYeVbloSipsDl+05OWQRf/pI4DgswI+LIfPm2kSQCVmC98qUBcQAzTrTQ/39LsVV95MhvZ
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM6PR02MB5112.eurprd02.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(346002)(376002)(136003)(396003)(39850400004)(366004)(31696002)(16576012)(21480400003)(786003)(2616005)(66946007)(86362001)(66556008)(36756003)(956004)(83380400001)(8676002)(31686004)(966005)(66616009)(2906002)(66476007)(316002)(44832011)(26005)(186003)(478600001)(8936002)(45954011)(4326008)(53546011)(6486002)(110136005)(33964004)(235185007)(5660300002)(38100700002)(43740500002)(45980500001); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WW9HTk9ERDJPRXFmbFVZd2poalB6N0V5cmpvaUUxcDdEdmtEclJyRWdVaWxY?= =?utf-8?B?blNkY3RoMlVVcG9QZUEyZEtSZUFnZFMxaHNRem5iVlJxNDh0S2p3VW1rUzAr?= =?utf-8?B?Nm9XaTI5bWVtVHNkcHdVbW0rMitJbGtUZUVxWkdWWEVGR3RlbTlkM3YvRDRk?= =?utf-8?B?NHhSbUlSTW9KeEtmbFp5WENlUFdyM1lqMXFCUVFHUHY5T044aUdzR1lNNEsw?= =?utf-8?B?U2lYdzVKcmNDb3NLWEdNY3UyTXhHY3FmandUZzlFYkNVZnU1OGhXYnJsQVlG?= =?utf-8?B?R1FUNGxGQ2YxSW1abE0vaEx2THJsN1IzUkdWOXg0cnFuUndsY2VOYjFkMjZv?= =?utf-8?B?UlBBQ2orUjkrRjNYMm9iSUZJdFFYWHhEQXBIcG8xUDNrNTNlN25WTERCRVZq?= =?utf-8?B?emNSazlYVmhKT2piZEh2eGRnMENOZTRSME9JYlpQV3Y4VkEwV1FnaWZpbUlq?= =?utf-8?B?YnpwN3k1Si9yMjJncmZYV2JXaDF1eHJablZkVTdDYkN5UkcrR0NpcmlYMmFr?= =?utf-8?B?YzZUcXRRcFE4OHlhdjNVY0NTNFhrRTZwc2ljUXFWczA0dUd0TVI0QkZ5UzBy?= =?utf-8?B?ZERQTDhua0JlZUkyQk1VcUhHU2hEbE51c0VuVytWMUlNWk1YY0F0MFExNXZI?= =?utf-8?B?czZPS3VCbno0TVpvRkRYdlIvdGU3N1Y4RnM2MXNmeWhrUEZtVXRzUE0rcWNp?= =?utf-8?B?OWtqelVDYUJaMndmS0N1ZHVJVm84YnF6LzRGN0VDb2hTS1RKL3g2VlB3cDJu?= =?utf-8?B?RkhFNW8vWkpHRmhyNzZIVFRyZTEzMGxiVnJjVFJicENDZUxyNmFQVlhuVUxk?= =?utf-8?B?YWFxWlQ0MllJTmROK1oyazNKZEgxTGRoMVo0aGx2QmNYYVRQQ001ZWJpRzA4?= =?utf-8?B?WjFnNFVmZGdpWGRSK2JadTFOWjhYbldJSkgzZU9KRVExaFo4TFBJL0NONlJu?= =?utf-8?B?NkMrcWF5Rjk2SDgzZ1hxRWRyY2JFbmttVFBNUjBPREdRbFU5bDZMUlNQR0FH?= =?utf-8?B?blVZNjNrQVZEdU9MbWVwMDF1T1hVMUpwUEZIblp0TFNHQS9jNkJoRFI2RlRv?= =?utf-8?B?SWdKd3grSEpjOE5KdGNHQzRicm5Cc3RRVitrL3JKRng0d2haMHpmWW5Ka0dH?= =?utf-8?B?dkNQQ1hHQkJJWW45YXBnb2czZHJKV0lJWmtVSzBGVFpxVGp6S0c5aWVBd0Uy?= =?utf-8?B?MzBIQldBS0F6dDRDRWFJOEtvVnVGdUtvdHFWN0NTZGRtcnZlVjNBNEtvQUVP?= =?utf-8?B?TXppQTBOYk9jUFBLeU51MDB5bkt1Sm03UDArZkdHUjZsTWZsVlNvUVFlQkw1?= =?utf-8?B?Ni9tbno5Z3Z4bHgzWnZ5blgwWFpvQ3BHM0M1VFVUWEsrVnc1OUlTS0JBemh5?= =?utf-8?B?YUVZU2NaUjh6c3U3K2FkSEwrMDBIQ3dNeEI1RGYvV3BJckptOUtFZ0x5aWtE?= =?utf-8?B?RmdZVGphbGkxdi9NMkNWQTdBZWVmQ080c0drbVhSaFhMWmc1aHg2TUZPbFBq?= =?utf-8?B?RHZKMmhZQlNDcnQzREJPM2R3VkkxekVqajNwNWYxbDVyK0g3MGQ5dXlNZktZ?= =?utf-8?B?Q2xGazY4bDNzN1hwSnRVYmlqQVhkdlJiK1lWQVJoVGJ0eDNLNTRmMkNrbDNP?= =?utf-8?B?dzVFaks4OS92T0ZyT0tkMkhicEhsdjlmenAwWmFUNGtYQnpKdEdZNzRvclBH?= =?utf-8?B?Szhpckx6NDkxQzhvQjFwYkQzMnZ5aFI2L2NMQWd5OXZheGEyTExDVU80Vlly?= =?utf-8?Q?BityE1YhVZfoelfX86KaraNkV2PT7VS++OiqFb0?=
X-OriginatorOrg: cs.tcd.ie
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a2df0b4-b7b3-4d3a-e19b-08d946bc5fcf
X-MS-Exchange-CrossTenant-AuthSource: AM6PR02MB5112.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2021 11:41:52.6050 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: E44jSyYcdu+PklB9I87fY/rQSQ636j3K7O8IFwfHEFrjVGhgqcBlBqf2M0O65BeN
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR02MB7045
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 11:42:06 -0000

--254w3msH9cfM1m4aMDDZotSJ6HxulPzgp
Content-Type: multipart/mixed; boundary="Ld9azXp4ay3uJ5SMxMBdoenUYLToY8Uvo";
 protected-headers="v1"
From: Stephen Farrell 
To: Mark Nottingham , Eliot Lear 
Cc: rfced-future@iab.org
Message-ID: <05a5a9a0-c052-9a5a-1904-9d5a7aced59c@cs.tcd.ie>
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new
 streams?
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch>
 <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>
In-Reply-To: <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>

--Ld9azXp4ay3uJ5SMxMBdoenUYLToY8Uvo
Content-Type: multipart/mixed;
 boundary="------------DEDE17CF942EE637AF43A9EE"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------DEDE17CF942EE637AF43A9EE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable



On 14/07/2021 07:34, Mark Nottingham wrote:
> I'm leaning towards saying that we should explicitly NOT give the
> ability to create streams to any single body, or define a process. If
> a situation comes up where we want to do this (for some value of
> 'we'), the expectation should be that there's buy-in from all
> concerned -- RSAB/WG, IETF, LLC, ISOC, etc. We can figure out a
> process then.

+1, though I'd maybe omit ISOC and add in the RSE, IRTF
and whomever is the proponent for a putative new stream.
Even better to not list those who need be involved though.

S.

>=20
>=20
>> On 12 Jul 2021, at 7:46 pm, Eliot Lear  wrote:
>>=20
>> Hi there,
>>=20
>> I opened this issue, and while it is related to who sits on the
>> RSAB, it's a little different.  The question is really this: what
>> is the process to create / delete editorial streams?  Does it go
>> through the IETF process?  Does it go to the IAB?  Does it go
>> through th RSWG/RSAB process?
>>=20
>> Peter asks this question: is it beyond the remit of this group to
>> decide that?  My gut says that this is not this group's decision
>> but perhaps an IAB decision or IETF decision or something in
>> between.  To say otherwise would seem the tail wagging the dog.
>> Unless people disagree with this logic, I'll close the issue.
>> Please comment by the 26th.
>>=20
>> This having been said, I do think this may be an issue for Brian's
>> 2850 update doc, since the IAB has previously held authority to
>> manage that process.
>>=20
>> Eliot
>>=20
>> -- Rfced-future mailing list Rfced-future@iab.org=20
>> https://www.iab.org/mailman/listinfo/rfced-future
>=20
> -- Mark Nottingham   https://www.mnot.net/
>=20

--------------DEDE17CF942EE637AF43A9EE
Content-Type: application/pgp-keys;
 name="OpenPGP_0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Description: OpenPGP public key
Content-Disposition: attachment;
 filename="OpenPGP_0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5=
Cg8
gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq=
978
CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu=
D/Q
9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4=
tNn
cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB=
wV+
4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir=
1GC
YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav=
ACY
Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D=
VQu
8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER=
8la
5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE=
wEI
ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC=
xAA
pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX=
Az9
+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL=
F+X
+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4=
g1U
QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre=
k3U
P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2=
niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL=
4Nw
tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m=
6vt
ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7=
+8A
CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ=
LvC
wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8=
rpK
o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr=
qJs
CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa=
W/r
KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG=
gMW
rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u=
rqR
1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/=
0A9
J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc=
JBD
EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4=
vrp
2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA=
xvK
dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK=
xlf
tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg=
Uky
o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO=
aHv
X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp=
yyz
JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ=
uLE
FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w=
sDc
BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer=
3UM
TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP=
jt5
uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK=
171
RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR=
Lpg
RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov=
wza
tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0=
zG3
6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ=
eah
r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ=
GNz
LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o=
3cC
GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo=
w5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h=
Rcs
RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC=
Y98
iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd=
h2k
4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4=
EIk
CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ=
DIJ
pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4=
tvy
a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4=
ul3
qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc=
G9g
ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt=
w/r
1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ=
Jaf
3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1=
4Q0
7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf=
qtu
Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C=
gHw
26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC=
wIE
FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL=
rfb
e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF=
etu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8=
v39
+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr=
1oD
3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr=
m2D
Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby=
y/A
UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO=
jao
P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz=
leL
Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC=
2X4
pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g=
1MS
BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34=
YT0
auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb=
edD
Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3=
1qG
/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV=
YW6
R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg=
4Im
VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm=
qyH
eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx=
qnk
SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ=
Esc
YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n=
2Hw
xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F=
eIY
jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E=
AuF
CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4=
2AY
R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH=
X5v
aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q=
Csw
Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq=
yA4
3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m=
Eer
0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI=
Dxz
dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC=
QgH
AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ=
i0B
igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn=
i9g
OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy=
sIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n=
66v
xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/=
3r2
BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM=
YtU
N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr=
5iW
XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/=
zek
ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b=
a0H
Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP=
Ic2
gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6=
XE6
i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1=
16u
/HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J=
G9a
SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW=
OMq
N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz=
0YO
K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4=
vYl
zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx=
nNb
KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+=
5HN
HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq=
4hn
l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn=
Zbg
JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d=
nJj
j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8=
WLI
aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc=
dPC
Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX=
o4+
Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO=
Tyk
rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9=
hZM
0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5=
P3f
WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp=
cL2
lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk=
etP
GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3=
zRq
k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0=
20q
pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U=
DIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x=
/nL
PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE=
hOV
fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D=
VI9
DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT=
uW/
eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD=
aWT
3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6=
1df
mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8=
MAv
2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA=
HZR
5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo=
qj1
gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6=
Mas
qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi=
RkM
dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB=
++/
KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX=
xMD
rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf=
ZtA
ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN=
2OE
0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT=
zcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7=
IKP
3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW=
Iys
s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3D40Nd
-----END PGP PUBLIC KEY BLOCK-----

--------------DEDE17CF942EE637AF43A9EE--

--Ld9azXp4ay3uJ5SMxMBdoenUYLToY8Uvo--

--254w3msH9cfM1m4aMDDZotSJ6HxulPzgp
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmDuzX4FAwAAAAAACgkQWrL68XsXK+ot
exAAn0c/ttBT3Xaec1bEUVbQn+Tl632sIaXRIpZ8PyPyYeyvV0VRhxjjuS5LNGO8BVdn2W3mHMJH
6RT9LiclUV1gbkaM5jmQHMqBzQt9S/X3Rj8u2OwzgjYfi4DwjbMzA+J26+MFDEIOpWq/rdIX6m/e
e7PYIcWSYMquaDT3cji47oT8Jhe01BmOKjqnC99lZL+1ec+rRGRph1pYiZ5Dkh1KuuT2gmykiQm6
7Ei/WkakxUbgOfwWh/LoIWEsNNr7TdjZ2amlFwAiloro9n01vQ4R8OqUyRaPCVhNjL4IpuanbxaP
plZ/hGXC05KZgHjfrIqWeboyAru9rrhwGg/LziuEdpjbhkRri687YuP3JStxNTFJI1YZCeo1QFm7
PEpDI9gKkqij/J5FE+n0zlfvVnOlXnK94ll39AdF26UbW7flznfaFF/xEY7k/lXGcxelD7U4weFx
HFIdaIIfC/b6IkhOLYGnElEGxshcPmjZqdBDizMth1hiY8f0ozzf1jwOdc+hKLMSE0brf1rpN+NZ
C4qQIP+3quKO32zSkrRxxKzxvYK0X56NcZ9cL3fWNlHRTgrTZyiYS3cRf8jElDj0Xg9+PZ6LDvyq
TlhsbslGXWzUZhMr2af+GAm43sCKHeONvMFLQAI9DEeUrReuzIxAHDeXFMxt6Mo1TA4O6eEd23Rj
KCc=
=59na
-----END PGP SIGNATURE-----

--254w3msH9cfM1m4aMDDZotSJ6HxulPzgp--


From nobody Wed Jul 14 06:40:09 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994293A16BF for ; Wed, 14 Jul 2021 06:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level: 
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BD0rbXNXTljr for ; Wed, 14 Jul 2021 06:40:03 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8CC3A16BE for ; Wed, 14 Jul 2021 06:40:03 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 16EDYV3S004237; Wed, 14 Jul 2021 14:39:54 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=bWeU3I+D5oPHzDRs+NQvbDCr1g0jTG1XcXqvgKx+ejo=; b=ltZRUUl7vw+0eJZ1QIpIMyZJ71KFzDZfPBh5gyH0pfMAxi9870w1tcyAizIxDYllFymS XllYNj/cRp8xndE1jLyyhzQV2NslBnJIzS7bfizs+t9D/Pq4uhGA7LT6oQUA/IMIhQ6t h1Gm2VBJ7EyBG7ezsLvaKoD5LTZyUSH+ZyAYVwjXM12fHvpptp8DeW6c0PIaUUEdYBjs lvpKUFlnZiIEhYMzaWwPApu1WhI1H5IQThAJtvZI1Je60ngwEcoiHe8BQQBvTKwUgy10 7ADN7h4465cUOg/qWTBdR4uPWN/WTVPFLOgGdE8/nFKs0xqAG3CL6FauzSjF6F1TBYMv 6A== 
Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 39sb0q9guf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jul 2021 14:39:54 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 16EDYQ16011266; Wed, 14 Jul 2021 09:39:53 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint3.akamai.com with ESMTP id 39swt0s9qv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 14 Jul 2021 09:39:53 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 14 Jul 2021 08:39:52 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.018; Wed, 14 Jul 2021 08:39:52 -0500
From: "Salz, Rich" 
To: Eliot Lear , Lars Eggert , Mark Nottingham 
CC: "rfced-future@iab.org" 
Thread-Topic: [Rfced-future] Issue #73 Who is responsible for creating new streams?
Thread-Index: AQHXdwLoO/kP5aYV+UuBQQ8+tOxKXatCWoWAgAANXACAAA2bAIAAGNkA
Date: Wed, 14 Jul 2021 13:39:52 +0000
Message-ID: <5CE15A86-6216-441B-B45A-75C08B7CB307@akamai.com>
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net> <562A7D1A-0767-4EED-BFEB-B399FAAE4026@eggert.org> <9317e4f8-e0cb-c376-7937-deef62f19ef7@lear.ch>
In-Reply-To: <9317e4f8-e0cb-c376-7937-deef62f19ef7@lear.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.50.21061301
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: multipart/alternative; boundary="_000_5CE15A866216441BB45A75C08B7CB307akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-14_07:2021-07-14, 2021-07-14 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 mlxlogscore=872 phishscore=0 mlxscore=0 adultscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107140084
X-Proofpoint-ORIG-GUID: ZCECMh4x7vtqgOomW1exRSHkVQhObt22
X-Proofpoint-GUID: ZCECMh4x7vtqgOomW1exRSHkVQhObt22
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-14_07:2021-07-14, 2021-07-14 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 clxscore=1015 mlxlogscore=812 spamscore=0 bulkscore=0 impostorscore=0 mlxscore=0 adultscore=0 priorityscore=1501 phishscore=0 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107140084
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 13:40:09 -0000

--_000_5CE15A866216441BB45A75C08B7CB307akamaicom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

ICAqICAgV2l0aCB0aGUgdW5kZXJzdGFuZGluZyB0aGF0IHRoZXJlIGlzIHZlcnkgc3Ryb25nIChh
bGJlaXQgbm90IHBlcmZlY3QpIGNvbnNlbnN1cyBmb3IgYSBuZXcgc3RyZWFtIGZvciB0aGUgUlNX
Ry9SU0FCIHByb2R1Y3RzLCBhbmQgdGhhdCB0aGUgZXhpc3RpbmcgcHJvY2VzcyB3aWxsIHByZXZh
aWwgKGUuZy4sIElBQiBhcHByb3ZhbCkgZm9yIHRoaXMgbmV3IHN0cmVhbSwgdGhlbiB3ZSBjYW4g
ZGVmZXIgdGhlIHJlc3QgZm9yIGxhdGVyLCBpZiB0aGF0IGlzIHdoYXQgcGVvcGxlIHdhbnQuDQoN
Clllcy4NCg==

--_000_5CE15A866216441BB45A75C08B7CB307akamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: <0890B604A404B94C8960826167043E16@akamai.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw
aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdp
bi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFy
Z2luLWxlZnQ6LjVpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp
bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7
DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx
MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg
bDANCgl7bXNvLWxpc3QtaWQ6MTYyNDAyMDYxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z
by1saXN0LXRlbXBsYXRlLWlkczoxOTk4NjI5NjI4IC04NzY5OTA5NjAgNjc2OTg2OTEgNjc2OTg2
OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7
fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo0Ow0KCW1zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1m
YW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9
DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90
dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFk
Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3
b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4N
Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29M
aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs
Zm8xIj5XaXRoIHRoZSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlcmUgaXMgdmVyeSBzdHJvbmcgKGFs
YmVpdCBub3QgcGVyZmVjdCkgY29uc2Vuc3VzIGZvciBhIG5ldyBzdHJlYW0gZm9yIHRoZSBSU1dH
L1JTQUIgcHJvZHVjdHMsIGFuZCB0aGF0IHRoZSBleGlzdGluZyBwcm9jZXNzIHdpbGwgcHJldmFp
bCAoZS5nLiwgSUFCIGFwcHJvdmFsKQ0KIGZvciB0aGlzIG5ldyBzdHJlYW0sIHRoZW4gd2UgY2Fu
IGRlZmVyIHRoZSByZXN0IGZvciBsYXRlciwgaWYgdGhhdCBpcyB3aGF0IHBlb3BsZSB3YW50Ljxv
OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_5CE15A866216441BB45A75C08B7CB307akamaicom_--


From nobody Wed Jul 14 11:13:49 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051163A110E for ; Wed, 14 Jul 2021 11:13:48 -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, 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=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoXo7_171jaO for ; Wed, 14 Jul 2021 11:13:41 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83833A1108 for ; Wed, 14 Jul 2021 11:13:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=Vyq9VbPYKtGSAAdmn/7i88aEl5OxyTtYg+IBVia/5aE=; b=Qb7LUYcicZpt4n3O4u2uEU0rI2 a3PZznVOzmBc5h3zkI32R6wUfEG0xP8zAEdOGkR1ZXgjbZ6z88Zi1D+LARSiJKq+I8xVMFCrY4m1X gioHM6ZfHWbUP94GPWyFApzflD6yFfY7P+zBq3NVCz0VIgYeVopuj4Uv04H7vSbl+VnfDVSOvDJbg hjhq9SUOQa0dBLzhKXKM1vSYJd2qUXl3j7h6GD+W677faDYbU3o72xS2MDU6LUHuYrVG7TtAMP+2i FGwmxilcH5QQgjiQYjXZEZ1DRA7sgADI55cRQL3xcQz1FnzP+H8jkfGG0oW3VtTgLECKGAeclEURC Qq0TCMUg==;
Received: from [81.187.2.149] (port=47416 helo=[192.168.0.83]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1m3jO6-0007az-0o; Wed, 14 Jul 2021 19:13:38 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Colin Perkins 
In-Reply-To: 
Date: Wed, 14 Jul 2021 19:13:31 +0100
Cc: Peter Saint-Andre , rfced-future@iab.org, Adrian Farrel , Eric Rescorla , Eliot Lear 
Content-Transfer-Encoding: quoted-printable
Message-Id: <02390CF3-6221-436E-A1B2-C455D79A1C7B@csperkins.org>
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com> <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>  
To: Mirja Kuehlewind 
X-Mailer: Apple Mail (2.3445.104.21)
X-BlackCat-Spam-Score: 4
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 18:13:48 -0000

I tend to agree =E2=80=93 it doesn=E2=80=99t seem unreasonable for the =
IRTF chair to have the option of delegating to an IRSG member.=20

Colin


> On 13 Jul 2021, at 14:40, Mirja Kuehlewind  =
wrote:
>=20
> I think it would be important for the appointee to be a member of the =
IESG or IAB respectively, mainly so that person knows what=E2=80=99s =
going on there. Similarly I think it would be hard for the IRTF chair or =
ISE to delegate to someone how is not involved in the processes there. =
However, the IRTF chair does involve the IRSG members more than it used =
to be the case, so leaving a bit of slack in the formulation to give =
them a choice in future is probably a good thing.
>=20
>=20
>=20
>> On 13. Jul 2021, at 02:08, Peter Saint-Andre  =
wrote:
>>=20
>> On 7/11/21 7:30 AM, Adrian Farrel wrote:
>>> I *still* don't object to this, but (just so you know) you haven't =
convinced me this isn't odd.
>>=20
>> It's my job here to (try to) capture the sense of the discussions =
and,
>> once we have it, rough consensus. AIUI, the argument is that whoever =
is
>> on the RSAB needs to be chosen more directly by the community than a
>> random appointee might be. I am not completely sure that this makes a
>> great difference in the end because a random appointee can be =
recalled
>> just as easily as an AD, or perhaps more so. In this specific case, =
we
>> might ask the IESG if they have a preference.
>>=20
>> Peter
>>=20
>> --=20
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>>=20
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future



--=20
Colin Perkins
https://csperkins.org/





From nobody Wed Jul 14 12:22:07 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC673A15A2 for ; Wed, 14 Jul 2021 12:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.891
X-Spam-Level: 
X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox7aHsWBYeN4 for ; Wed, 14 Jul 2021 12:22:00 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 44F5D3A15A1 for ; Wed, 14 Jul 2021 12:21:59 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1004::1cf] ([IPv6:2001:420:c0c0:1004:0:0:0:1cf]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16EJLq08231817 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 14 Jul 2021 21:21:53 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626290516; bh=XqNTSKRKy1EqWzk23ZPZKNS9lwVvp5JvVqnV1r+YZMs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JXQLv6zx2EEHB3wzJ0+G5v6LX6Wp4nCb8LUeSrRXYqq/qQCGCmYpuczwGi9+OaSq+ NS1OBNZGe1gHtXW/fJpAj2thIvOSBPve3biRIJ2dBq/FFVu9zOI9QrXvs3d6g4RQjr RPsruxLjL/Ye5Ki/sBd54ara+ki9fWtSvQYUceg8=
To: Colin Perkins , Mirja Kuehlewind 
Cc: rfced-future@iab.org, Adrian Farrel , Eric Rescorla , Peter Saint-Andre 
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com> <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>   <02390CF3-6221-436E-A1B2-C455D79A1C7B@csperkins.org>
From: Eliot Lear 
Message-ID: <1c1fea4a-ff85-3f41-ef82-b54fcf49ea58@lear.ch>
Date: Wed, 14 Jul 2021 21:21:51 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <02390CF3-6221-436E-A1B2-C455D79A1C7B@csperkins.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uxRjuida8PoLyqGfL5mETnL9g5XgACagY"
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 19:22:06 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--uxRjuida8PoLyqGfL5mETnL9g5XgACagY
Content-Type: multipart/mixed; boundary="rrcCLZUjA31ABsS5tmtnbDLCtaboz8abm";
 protected-headers="v1"
From: Eliot Lear 
To: Colin Perkins , Mirja Kuehlewind 
Cc: rfced-future@iab.org, Adrian Farrel ,
 Eric Rescorla , Peter Saint-Andre 
Message-ID: <1c1fea4a-ff85-3f41-ef82-b54fcf49ea58@lear.ch>
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
References: 
 
 <128201d76cea$a9326c00$fb974400$@olddog.co.uk>
 <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com>
 <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>
 
 
 <02390CF3-6221-436E-A1B2-C455D79A1C7B@csperkins.org>
In-Reply-To: <02390CF3-6221-436E-A1B2-C455D79A1C7B@csperkins.org>

--rrcCLZUjA31ABsS5tmtnbDLCtaboz8abm
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US


On 14.07.21 20:13, Colin Perkins wrote:
> I tend to agree =E2=80=93 it doesn=E2=80=99t seem unreasonable for the =
IRTF chair to have the option of delegating to an IRSG member.

What would it mean to hold that person accountable?=C2=A0 Who gets to do =
that?

Eliot



--rrcCLZUjA31ABsS5tmtnbDLCtaboz8abm--

--uxRjuida8PoLyqGfL5mETnL9g5XgACagY
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDvOU8FAwAAAAAACgkQh7ZrRtnSejNN
0ggAil/zwKijo4RYkGPKnZx32NJhFC6axnflY8xLLh9acchkWtfXBYii1+nhiJMYNTtYM6Yjnvp7
a20V9RIOwxPCGCN96S0o7j4LUnY64E5xyKtoITNjLA5URBtIviq/dYXRei/cTykD+ZNOshFsFesS
6xHM+X0jmZ3YfrxbP7BB36vLkK8Bx8s85N04MG+z6Swv17bS0CxwtHWcSlgpRvI9Eqz7fAoqUVpw
KzmokBdw0hUgep1+KpGzYf/QvLIUomQDbxuftuDo6jR07ltjt3U4RBpQElUKZ06UFcj+Vtc9m+cb
puwMB3TXqesAmUFNk0W+TQs8zWI1aD/5tgLqi/fwow==
=PGf4
-----END PGP SIGNATURE-----

--uxRjuida8PoLyqGfL5mETnL9g5XgACagY--


From nobody Wed Jul 14 12:27:11 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB263A15ED for ; Wed, 14 Jul 2021 12:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level: 
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK9--eklJHaJ for ; Wed, 14 Jul 2021 12:27:05 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 2458F3A15E7 for ; Wed, 14 Jul 2021 12:27:04 -0700 (PDT)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16EJR2xh011758; Wed, 14 Jul 2021 20:27:02 +0100
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 54A8C4604A; Wed, 14 Jul 2021 20:27:02 +0100 (BST)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4867746043; Wed, 14 Jul 2021 20:27:02 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs4.iomartmail.com (Postfix) with ESMTPS; Wed, 14 Jul 2021 20:27:02 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.103.107]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16EJR1Zo001726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Jul 2021 20:27:01 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Eliot Lear'" 
Cc: 
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com> <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>   <02390CF3-6221-436E-A1B2-C455D79A1C7B@csperkins.org> <1c1fea4a-ff85-3f41-ef82-b54fcf49ea58@lear.ch>
In-Reply-To: <1c1fea4a-ff85-3f41-ef82-b54fcf49ea58@lear.ch>
Date: Wed, 14 Jul 2021 20:27:01 +0100
Organization: Old Dog Consulting
Message-ID: <030e01d778e6$38f43a60$aadcaf20$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJYLqiQ/XeTdq1mmedVrtykX7nyGwI9AqC2AbAelv8BWB++mAGhkz6xAYlQOM8CCCG87QF9q4AbAd/r7LGp0r/NkA==
Content-Language: en-gb
X-Originating-IP: 84.93.103.107
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26282.002
X-TM-AS-Result: No--8.908-10.0-31-10
X-imss-scan-details: No--8.908-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26282.002
X-TMASE-Result: 10--8.907800-10.000000
X-TMASE-MatchedRID: QW5G6BKkLTrkQwDXuLnCoXFPUrVDm6jt2B5g90ltSFYAIXlMppp3Xw6o IgaTSt0hPxzwqhA06uoTSksbtQxXYcYvmrk7lvM2CLNfGU4dffircyxAHgzswkZCAhWuYEvkO1n WiFniw6Q2IuMHbBVXapfucML7iAp6u9QzWW8MxDqXmVAzMqYX0kwZMwX4tEtql+pKh2q+JP33bJ LecgMhhrHTZj+uL2tkj1sd/ENaiJuyppFEAX65HtbgzPjrV+wc4wHGXjSYGPc2PlicnJ0Gg7RMD KJfrGJCn9SenJq/hy1q8/xv2Um1avoLR4+zsDTthUfR2rvBju6tJ1nOHxyXTnY6bIOz27Rx+SJi 5crLlrzpjOvBgnNiBltME7mh27IfwL6SxPpr1/I=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 19:27:11 -0000

I'm close to wondering what the point of contributing to this =
conversation is.

You hold a delegate responsible by calling on the person who delegated =
to act, and when they fail you remove the person who delegated.

This is what it means to delegate.

A

-----Original Message-----
From: Eliot Lear =20
Sent: 14 July 2021 20:22
To: Colin Perkins ; Mirja Kuehlewind =

Cc: rfced-future@iab.org; Adrian Farrel ; Eric =
Rescorla ; Peter Saint-Andre 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members


On 14.07.21 20:13, Colin Perkins wrote:
> I tend to agree =E2=80=93 it doesn=E2=80=99t seem unreasonable for the =
IRTF chair to have the option of delegating to an IRSG member.

What would it mean to hold that person accountable?  Who gets to do =
that?

Eliot




From nobody Wed Jul 14 12:34:50 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB1C3A1622 for ; Wed, 14 Jul 2021 12:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvDa6bvRRAAw for ; Wed, 14 Jul 2021 12:34:44 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD793A161F for ; Wed, 14 Jul 2021 12:34:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=uvxVH1AwwNmPwnj38YRbAXEtf+7JCQlnqhCaMn6d8/w=; b=R0VeIKXoGC0B/x3z2ROb1Ij5yF mcHc/y/OQzzFz1UgG11jRNqFWIPw+ZzDtvlXCTR5vH2YcZwhDKtITIDd5LkbewvhMPMZl8v7Sh4v5 mmPzxFLxiWnNn4BwuBq79vgdOAZqhxkOYTpApAqI2EkrxHitrSaRAn419N3LYiiqJMIz3sW6JQYXV 4iRV3F45LuOtpdEJtvL5ffECx8XDtSYrq+iiW/SXIpBbhMFzw5dgUQvMouO9t2fGiHIqE45AXkJc8 O5ow6QUmwh0d2XYWxudNCzJihKGP0ZxXEsmMKMcEx0pPTIrH3bhFbPQHqw4NzZ8JjrBhcO5dtXnmY tsAlhxTA==;
Received: from [81.187.2.149] (port=48226 helo=[192.168.0.83]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1m3keX-0001H2-6f; Wed, 14 Jul 2021 20:34:41 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Colin Perkins 
In-Reply-To: <030e01d778e6$38f43a60$aadcaf20$@olddog.co.uk>
Date: Wed, 14 Jul 2021 20:34:37 +0100
Cc: Eliot Lear , rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9ADF27F5-5547-489E-ADD0-5EB754179300@csperkins.org>
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com> <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>   <02390CF3-6221-436E-A1B2-C455D79A1C7B@csperkins.org> <1c1fea4a-ff85-3f41-ef82-b54fcf49ea58@lear.ch> <030e01d778e6$38f43a60$aadcaf20$@olddog.co.uk>
To: Adrian Farrel 
X-Mailer: Apple Mail (2.3445.104.21)
X-BlackCat-Spam-Score: 4
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 19:34:50 -0000

Exactly.
Colin


> On 14 Jul 2021, at 20:27, Adrian Farrel  wrote:
>=20
> I'm close to wondering what the point of contributing to this =
conversation is.
>=20
> You hold a delegate responsible by calling on the person who delegated =
to act, and when they fail you remove the person who delegated.
>=20
> This is what it means to delegate.
>=20
> A
>=20
> -----Original Message-----
> From: Eliot Lear =20
> Sent: 14 July 2021 20:22
> To: Colin Perkins ; Mirja Kuehlewind =

> Cc: rfced-future@iab.org; Adrian Farrel ; Eric =
Rescorla ; Peter Saint-Andre 
> Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
>=20
>=20
> On 14.07.21 20:13, Colin Perkins wrote:
>> I tend to agree =E2=80=93 it doesn=E2=80=99t seem unreasonable for =
the IRTF chair to have the option of delegating to an IRSG member.
>=20
> What would it mean to hold that person accountable?  Who gets to do =
that?
>=20
> Eliot
>=20
>=20
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future



--=20
Colin Perkins
https://csperkins.org/





From nobody Wed Jul 14 12:54:16 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4D3A171C for ; Wed, 14 Jul 2021 12:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=iecc.com header.b=JkDGCpV4; dkim=pass (2048-bit key) header.d=taugh.com header.b=POTxhRyP
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QveJ8LGm0Tmf for ; Wed, 14 Jul 2021 12:53:58 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 5DE823A1782 for ; Wed, 14 Jul 2021 12:53:53 -0700 (PDT)
Received: (qmail 3216 invoked from network); 14 Jul 2021 19:53:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c88.60ef40ce.k2107; bh=575hlNRfh4YkhM5tLP2G/DxTroij6HOUsjZqg9/K8Qk=; b=JkDGCpV45K/BKCpKQzCP/NIp8Tyrc8Jbd9Flsi7/51Bvn6eF1cDfFNFYMDIrgQ7hwtl+VX+/rD7xkqk+Dw2Zq7PYalCtZLuZQ//wnArd1nsidPytGZPDCPxDwKNeqvtvQtAlZLsDMUYmZ+B9sexBCjdxf+9e01ETBE7BR0Iptm9Zz3BgaimvHf+4BvBc4xY3a0jtIsT6jSf5PF355wUiFt6ModnAUWxmNY21OEhL3eUZbhYogk1atVGgm/vC3JIYM/3dMInD5sXTDMuqwnIJuBNNtBO2EjgIjjjqMZlBgA38QBd2nExCsZdT1MPEWf8PR4iNiBpJQPGx75AFaNGuTw==
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c88.60ef40ce.k2107; bh=575hlNRfh4YkhM5tLP2G/DxTroij6HOUsjZqg9/K8Qk=; b=POTxhRyPM7veLSjTeiS5vS9+bKMRKJA3wWVPeOEQSSdhwAR4VNSVRDLQJsq8DGbpJkWB7O7UOf3WX98aMP3b+191IOXM1QZ8YQJ3RVYdV3NRT2YQXhVwmnTnpgpOSsZ/E8cgCMR/cH1y91qEB5VCI71FUuk6cJDWnpuOwm0hS3RrFf6qY7vTvQuCDNVgbG8nJlt75K3JtmyPcLvOLz/lsEfODF/MRvFuoDaeadL7IiU+xlJ7A80IZNQ40OwM2+JvWebEC/i/1BmEwMK9vH1OOqqzjg7JNP8j+m/+YKvOP63ltn92ssSG7LeA1drNQJp8lnAlv5mSh4lrNzvcstBWdQ==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Jul 2021 19:53:50 -0000
Received: by ary.qy (Postfix, from userid 501) id 017EF2271267; Wed, 14 Jul 2021 15:46:57 -0400 (EDT)
Date: 14 Jul 2021 15:46:57 -0400
Message-Id: <20210714195350.017EF2271267@ary.qy>
From: "John Levine" 
To: rfced-future@iab.org
Cc: adam@nostrum.com
In-Reply-To: <8f01fe5d-bbe6-a3f9-adda-74bf98c4e661@nostrum.com>
Organization: Taughannock Networks
X-Headerized: yes
Cleverness: minimal
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 19:54:14 -0000

It appears that Adam Roach   said:
>On 7/13/2021 3:05 PM, Eliot Lear wrote:
>> I didn't realize RFC#s are a thing, but I imagine that is a pretty 
>> easy thing to sort.
>
>
>I don't know how much involvement the RSE recently had in this 
>particular detail.

None that I am aware of.  The RPC assigns the numbers.  I have asked a few times
whether they'd reserve an interesting number like 8888 but it's their call.

The numbers are mostly assigned as the documents go into the editing process
with some flexibility to keep related docs togther, or to assign numbers with
the same trailing digits as earlier versions.

R's,
John


From nobody Wed Jul 14 13:04:07 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C6F3A1770 for ; Wed, 14 Jul 2021 13:04:06 -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 UP0j1cyF0jXK for ; Wed, 14 Jul 2021 13:04:01 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 2148A3A145C for ; Wed, 14 Jul 2021 13:04:01 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id o8so2812890ilf.4 for ; Wed, 14 Jul 2021 13:04:01 -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=fcDFyOADaLFFp7VkGNfXJDTzrfUEE2arptePsbOhZ+Q=; b=o7KZxro10I4R/MXKIk54O07XOEADz6k7xRMOR0wBcsxi6WNtomsN4VAjAwrnXNn55e zaZowF4a5XamQE75QE5RKPrkbihxeHgE9Q21LlhF5REen+F5jokHBc7gSEpEjdmB7FbI OPdxX86HGoG2Xuh43znVF98oUxDQ8o8/R4Jz/izate1/WcT4FSTsKPba+xDxd8tyomwM CEnKdc0C55nZvi81ybvek4tY/U2P/1c3xnXVMxE+0FeBXgryrLqj5/tqQ1DvVZKU9Y/W PyAha3fzMDpgVdAbNUcPTgxsPZczONkYt0+cE+/1MZRSzgjakGO8ByPQ0QI13Yt4LR2U DICw==
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=fcDFyOADaLFFp7VkGNfXJDTzrfUEE2arptePsbOhZ+Q=; b=aa8BjyvqMl7fSiNFf29Hl9g51a050NJ/JA86FKd6JvPeH9oT2xzDWUTPFpbDb9bI+3 IqX4EQhnIWv6YaxbIKjvIjx0IEFk9dCcjb6PkdoviP71wF9ZWtQWfzCXhY43eLBAfepy GuEp4MWnL4601WlD4bV573vimfVW2JYfRazwhaB6U9v6Er51mQGw6A3cx8MNDsv2lz8r 7Kd7SOriQ9q9BdXI7p93S961E+jVhJJBS4zBUBlYJvtULb7BBaJLWxJcrBhu7Fk/NDVp Gt2FnLMg0H66Uo5R31OrKbx5+nalluZJfR9naDPcOllIpHGjzr7aAB3EERV6IygBUgHC H0aw==
X-Gm-Message-State: AOAM53081242auM8TshRUVHcNdJfpp2MQ2MfInZlMJMrJ+UaE5spfeBe +96/xe/Aezmm53nJNCmnSOmaflT+UcEhx040LyIQsA==
X-Google-Smtp-Source: ABdhPJzEURXx02K41Jq/6LbvW3LHDfj1zNnAQbQ7xxush2l5Y3s5AT36pJVEVRyasi2riKqYid2YBFw0H7bQziPbTiM=
X-Received: by 2002:a05:6e02:1aae:: with SMTP id l14mr5509271ilv.35.1626293038893;  Wed, 14 Jul 2021 13:03:58 -0700 (PDT)
MIME-Version: 1.0
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com> <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>   <02390CF3-6221-436E-A1B2-C455D79A1C7B@csperkins.org> <1c1fea4a-ff85-3f41-ef82-b54fcf49ea58@lear.ch> <030e01d778e6$38f43a60$aadcaf20$@olddog.co.uk> <9ADF27F5-5547-489E-ADD0-5EB754179300@csperkins.org>
In-Reply-To: <9ADF27F5-5547-489E-ADD0-5EB754179300@csperkins.org>
From: Eric Rescorla 
Date: Wed, 14 Jul 2021 13:03:22 -0700
Message-ID: 
To: Colin Perkins 
Cc: Adrian Farrel , rfced-future@iab.org, Eliot Lear 
Content-Type: multipart/alternative; boundary="000000000000e2686305c71adab0"
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 20:04:06 -0000

--000000000000e2686305c71adab0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This matches my expectation as well.

-Ekr


On Wed, Jul 14, 2021 at 12:34 PM Colin Perkins  wrote:

> Exactly.
> Colin
>
>
> > On 14 Jul 2021, at 20:27, Adrian Farrel  wrote:
> >
> > I'm close to wondering what the point of contributing to this
> conversation is.
> >
> > You hold a delegate responsible by calling on the person who delegated
> to act, and when they fail you remove the person who delegated.
> >
> > This is what it means to delegate.
> >
> > A
> >
> > -----Original Message-----
> > From: Eliot Lear 
> > Sent: 14 July 2021 20:22
> > To: Colin Perkins ; Mirja Kuehlewind <
> ietf@kuehlewind.net>
> > Cc: rfced-future@iab.org; Adrian Farrel ; Eric
> Rescorla ; Peter Saint-Andre 
> > Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
> >
> >
> > On 14.07.21 20:13, Colin Perkins wrote:
> >> I tend to agree =E2=80=93 it doesn=E2=80=99t seem unreasonable for the=
 IRTF chair to
> have the option of delegating to an IRSG member.
> >
> > What would it mean to hold that person accountable?  Who gets to do tha=
t?
> >
> > Eliot
> >
> >
> >
> > --
> > Rfced-future mailing list
> > Rfced-future@iab.org
> > https://www.iab.org/mailman/listinfo/rfced-future
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--000000000000e2686305c71adab0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This matches my expectation as well.

-Ekr


On Wed, Jul 14, 2021 at 12:34 PM Colin Perkin=
s <csp@csperkins.org> wrote:=

Exactly.

Colin





> On 14 Jul 2021, at 20:27, Adrian Farrel <adrian@olddog.co.uk> wrote:

> 

> I'm close to wondering what the point of contributing to this conv=
ersation is.

> 

> You hold a delegate responsible by calling on the person who delegated=
 to act, and when they fail you remove the person who delegated.

> 

> This is what it means to delegate.

> 

> A

> 

> -----Original Message-----

> From: Eliot Lear <lear@lear.ch> 

> Sent: 14 July 2021 20:22

> To: Colin Perkins <csp@csperkins.org>; Mirja Kuehlewind <ietf@kuehlewind.net>

> Cc: rfced-fu=
ture@iab.org; Adrian Farrel <adrian@olddog.co.uk>; Eric Rescorla <ekr@rtfm.com>; Peter Saint-A=
ndre <stpeter@m=
ozilla.com>

> Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members

> 

> 

> On 14.07.21 20:13, Colin Perkins wrote:

>> I tend to agree =E2=80=93 it doesn=E2=80=99t seem unreasonable for=
 the IRTF chair to have the option of delegating to an IRSG member.

> 

> What would it mean to hold that person accountable?=C2=A0 Who gets to =
do that?

> 

> Eliot

> 

> 

> 

> -- 

> Rfced-future mailing list

> Rfced-future=
@iab.org

> https://www.iab.org/mailman/listinfo/rfced-fut=
ure







-- 

Colin Perkins

htt=
ps://csperkins.org/









-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future




--000000000000e2686305c71adab0--


From nobody Wed Jul 14 13:59:40 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1AE3A093C for ; Wed, 14 Jul 2021 13:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8BD526tEsyP for ; Wed, 14 Jul 2021 13:59:32 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 9FD853A093B for ; Wed, 14 Jul 2021 13:59:32 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id j3so2075767plx.7 for ; Wed, 14 Jul 2021 13:59:32 -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=zaPckto7umqPLIsR9Q5HgcfhpoltqhwV+6qYLcsNFNQ=; b=i6n1ZiTxTGe5va4TKVDaxzlL+t3rFYdhmoiwRWLK6xauTFsqvc7AbWr6hCoenpPWRx ZMaEbRzULbPy5+hn7J2eQVcODnsigQIPd2j46uOpcVxaRMIoTi7iu8dwxUPA+T5H1J3s O5rtUTwEUqhH/wJe03L3cbaHBoktz5Kbopq3+f1lrVAsg/ITuBMSIR8Ht5b3Sc3FtOia 3Z7ifQHS3/6Plwh16qYHtbttYWjLhC8n1A0jN7QJAGWK0Q/15hC5v500JluZVDNUTsC8 Kr9Cdvq4lGE7/bVqRq1F9aXlE+4MW+qlYIvaak2YJHbGK6FpNvRumG1jI5m2uVNE3kAx 3nzQ==
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=zaPckto7umqPLIsR9Q5HgcfhpoltqhwV+6qYLcsNFNQ=; b=Wiu6Zx+CugMXg1bg3lmKpT59aeIe/+5tPRCuDb+lEPaEdbSlvFp0ngCsQObAKml5Cl imDIx6DlcFVYGZeiMjxErf41ij0AEZtwZh1/Um+aSbnqyAD1I5sXXHyzdWsAwzuvK5+T Q7PqAw1Nv0N6aTZL/vYJNnbThITEbiumMYzfmRzAAyv4xkItPJDPw4VCSorZbjC69bsK KIRK8sya7ki1Vi8dC5i4OkXnIhk5qLpu5RFqUmpERt0LrlSmMqVTUy1SZoAQ1nHBFr91 ysvtkpYRIlEKzhYlo0GndiGdrA6Cwg3VSBh9IG2u0ZzxTIqtvwPOi2ycpl8QeSw/X6+Y atXA==
X-Gm-Message-State: AOAM5302RTt4Sr1v5yURKNQ9mCdmye/qkuon0exH9wTe1Dz/YQe1o7zl Bs7YZnvrU+iy517zJTD3UPEzZLN5DWy+7A==
X-Google-Smtp-Source: ABdhPJyxhTd5ehDlHQLtRYGPyWX1k5wYjTFvomzn+6mrdWGk81Pa+kkXe5ibXeKqk2P2ywuIFAxUoQ==
X-Received: by 2002:a17:90a:5204:: with SMTP id v4mr5506786pjh.147.1626296371063;  Wed, 14 Jul 2021 13:59:31 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id y6sm3122555pjr.48.2021.07.14.13.59.29 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jul 2021 13:59:30 -0700 (PDT)
To: rfced-future@iab.org
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com> <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>   <02390CF3-6221-436E-A1B2-C455D79A1C7B@csperkins.org> <1c1fea4a-ff85-3f41-ef82-b54fcf49ea58@lear.ch> <030e01d778e6$38f43a60$aadcaf20$@olddog.co.uk> <9ADF27F5-5547-489E-ADD0-5EB754179300@csperkins.org>
From: Brian E Carpenter 
Message-ID: 
Date: Thu, 15 Jul 2021 08:59:26 +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: <9ADF27F5-5547-489E-ADD0-5EB754179300@csperkins.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Jul 2021 20:59:38 -0000

Also we have various precedents for (e.g.) the IAB appointing someone to =
an external committee (e.g. the gazillion committees that ICANN seems to =
have), by a process of the IAB's own choosing. So why don't we just say t=
hat (apart from fixed maximum terms) it's for the appointing body to dete=
rmine its own appointment process, including delegation?

Regards
   Brian

On 15-Jul-21 07:34, Colin Perkins wrote:
> Exactly.
> Colin
>=20
>=20
>> On 14 Jul 2021, at 20:27, Adrian Farrel  wrote:
>>
>> I'm close to wondering what the point of contributing to this conversa=
tion is.
>>
>> You hold a delegate responsible by calling on the person who delegated=20
to act, and when they fail you remove the person who delegated.
>>
>> This is what it means to delegate.
>>
>> A
>>
>> -----Original Message-----
>> From: Eliot Lear =20
>> Sent: 14 July 2021 20:22
>> To: Colin Perkins ; Mirja Kuehlewind 
>> Cc: rfced-future@iab.org; Adrian Farrel ; Eric Re=
scorla ; Peter Saint-Andre 
>> Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
>>
>>
>> On 14.07.21 20:13, Colin Perkins wrote:
>>> I tend to agree =E2=80=93 it doesn=E2=80=99t seem unreasonable for th=
e IRTF chair to have the option of delegating to an IRSG member.
>>
>> What would it mean to hold that person accountable?  Who gets to do th=
at?
>>
>> Eliot
>>
>>
>>
>> --=20
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>=20
>=20
>=20


From nobody Wed Jul 14 17:15:48 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BFD3A1010 for ; Wed, 14 Jul 2021 17:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level: 
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=u3Ozz+7s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Wu6/caO7
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oelibAU7DySw for ; Wed, 14 Jul 2021 17:15:42 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BDA3A100F for ; Wed, 14 Jul 2021 17:15:42 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id E97B05C010E for ; Wed, 14 Jul 2021 20:15:40 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Wed, 14 Jul 2021 20:15:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=3KmGnBftNQvF8LR6Rwi33dBhfFXwEqL 0lj6mU1pbQ70=; b=u3Ozz+7swVxKImlMmpUg893BBNAOOScfXSH4MxIq6QHT6dN 0NJT8cePDp8cZqmKML3BMgFb+z2JPNzQdcDQP/aI9GeESbLtBt6j6aPWMmL20IGM ZFVuENpCHkeQ3Eo7RyFKpolm7jJ1fGfGLP+ZfZDVClAhrF2F0RjsmgDDozZDlFQ5 GwIMbql5iXdkqs9XDoxJPG1sDuJnuXukKB0y/IyQrQx55Yn8M/YZJUQbqdYEHGoV cKPi+L+GLdxqe+0Ww56iSX3Ia3i8bR8mSIW8KXfie1X4byZxdFMvBIRAi0RvNOCT YDuw1OaZILttmDuRBqOgtd0VBCTGr7c2U8RVzsg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=3KmGnB ftNQvF8LR6Rwi33dBhfFXwEqL0lj6mU1pbQ70=; b=Wu6/caO7/GLPIXkHktmQ2+ Ph2Aa+kSx2R0UWGcDcoVImiaZ1XpKxM/KDaMkgufUTWDx93DXE0wml2SQ+PQUTsD gFzstbnzjze0qB2ljBuIEoJGRAk0iNF4pKNJf408od7PiBKrwI2IseiHSz7w8i8t zpjYEP2xedHpze64KNu8sKgi7BYqMrtsTEqSz7rLoh3UutkfQuWNwV63zfSzyTRJ xZ63XekHGVcZC50sTyhod1IXYgWNb0G4ZJlnXPVyIFTGAAeH11VesDlraOaBxUHX n/tPBvkk3GsrpZqgsfrD95bFDVVTH979GHHB6CRavwlD3ZSfLsv9ZYlfiNZkfD/g ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudelgdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepheefteduudduhedtkefhvd fhteelffdujeegjeffheffveekudeigfeuveekfeelnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9023B3C0B75; Wed, 14 Jul 2021 20:15:40 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>
Date: Thu, 15 Jul 2021 10:15:18 +1000
From: "Martin Thomson" 
To: rfced-future@iab.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [Rfced-future]  =?utf-8?q?Issue_=2373_Who_is_responsible_for_crea?= =?utf-8?q?ting_new_streams=3F?=
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jul 2021 00:15:47 -0000

On Wed, Jul 14, 2021, at 16:34, Mark Nottingham wrote:
> I'm leaning towards saying that we should explicitly NOT give the 
> ability to create streams to any single body, or define a process. If a 
> situation comes up where we want to do this (for some value of 'we'), 
> the expectation should be that there's buy-in from all concerned -- 
> RSAB/WG, IETF, LLC, ISOC, etc. We can figure out a process then.

Adding to the growing chorus of +1 here for saying nothing.  I don't even want to commit to a de facto status of the IAB deciding.  A change to the stream structure is a big enough deal that I'm happy to have that be a high energy event that -- if managed properly -- will garner support from all stakeholders.

It's been good to have the discussion, but it has confirmed for me that dictating a process could only make things worse and would be unlikely to improve the situation. 


From nobody Thu Jul 15 07:11:07 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C203A0EBD for ; Thu, 15 Jul 2021 07:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt9h0r1KZk-8 for ; Thu, 15 Jul 2021 07:10:52 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037A73A0E48 for ; Thu, 15 Jul 2021 07:10:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 50674300BDA for ; Thu, 15 Jul 2021 10:10:49 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KJaHT7xD6Iim for ; Thu, 15 Jul 2021 10:10:48 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id BA7FE300AC4; Thu, 15 Jul 2021 10:10:47 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley 
In-Reply-To: 
Date: Thu, 15 Jul 2021 10:10:46 -0400
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net> 
To: Martin Thomson 
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jul 2021 14:11:06 -0000

> On Jul 14, 2021, at 8:15 PM, Martin Thomson  wrote:
>=20
> On Wed, Jul 14, 2021, at 16:34, Mark Nottingham wrote:
>> I'm leaning towards saying that we should explicitly NOT give the=20
>> ability to create streams to any single body, or define a process. If =
a=20
>> situation comes up where we want to do this (for some value of 'we'),=20=

>> the expectation should be that there's buy-in from all concerned --=20=

>> RSAB/WG, IETF, LLC, ISOC, etc. We can figure out a process then.
>=20
> Adding to the growing chorus of +1 here for saying nothing.  I don't =
even want to commit to a de facto status of the IAB deciding.  A change =
to the stream structure is a big enough deal that I'm happy to have that =
be a high energy event that -- if managed properly -- will garner =
support from all stakeholders.
>=20
> It's been good to have the discussion, but it has confirmed for me =
that dictating a process could only make things worse and would be =
unlikely to improve the situation.=20

Maybe we want to require consensus among the existing stream managers to =
create a new stream.  That is the actual stream managers without =
delegation.

Russ


From nobody Thu Jul 15 11:21:09 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC9B3A1881 for ; Thu, 15 Jul 2021 11:21:07 -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 YHm0S2nqZA1r for ; Thu, 15 Jul 2021 11:21:00 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 B10CC3A187F for ; Thu, 15 Jul 2021 11:21:00 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id z11so7635561iow.0 for ; Thu, 15 Jul 2021 11:21:00 -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=qp+kkZn2re3PdJULBW/zqc2RZsjhnrk/PXWM+AissSM=; b=kVX6xH++4qERQjqAKZZJ8d7ZnyhHNiGHd3mZBygUeIx2bNGF98kT4RtY8zaVYzHR6p bzyHyHNe+oqqVW0CpJjbIMYRwopiCesnaDAxLpa0+U6k2XjoLq42b2rDt+lo1pds5mgn LFSokPcHivvSPzAibC7Bgg6HdwfdgxjE0zylCJq+pFYfPE0vq1KT9wCVEPzV5Ho63QWo FGTiIaaNZAnmQWV4V5TUTGirKumzpCosQqI63jdCTkJVDvxDjYIR4VLv4ZXlXrgOQz/v sl2i38MdiVnbiOCUINFbfAlYI/iTc++RR9IwUUnXKuMvvHB2Yc5EEINwq18k8tv8YfCH vJRw==
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=qp+kkZn2re3PdJULBW/zqc2RZsjhnrk/PXWM+AissSM=; b=KM0BtwZ/nDqkERqrhpnhRmF3Mb3d64WIpFMq5oMOKClVOHtEJ7I9IfoAedqYa+bSrN 8H2u56BmMEVHLGxT72uV21YRjg8djtvA0+9Kkoir/s0+NYo+c3SU67V8Ty7VtLU3hbPD 5jX/H7zcLyAiPm3k7o53c3tm8tI+ThDKq3yhm/3tOvJ8eOM4roxzDUoFEHqsyF5aFJaG 2MGxJkCaXruQe9DRxOm/WqpKBHSjNq77eSjk7kigXq7g+yYravzNT0LP73HK4jTHW0+d OwXyH9QC7uv1cM9XZFLf04U4JGq2UsDgc4ymMsGhOIjxUYJAkCsvyKl8x26Kns/vW51U 5qHQ==
X-Gm-Message-State: AOAM530+x9UAyOYe3RydkMW6Vf/muNsw8KgWaxor8in+uxaaGOQ0HAyT f6SWqcNJh+CnIVrlA37jdwr1XpWXO3aLEwvSveykYA==
X-Google-Smtp-Source: ABdhPJyNBuyqgkdt9RhCN5lOADPufN9b9JEyggWMHKNsuLftm0tNO+y1UWimT2qwxJICIZjVXg2pPnw7qeS8dVwrnYw=
X-Received: by 2002:a5d:8511:: with SMTP id q17mr4298729ion.98.1626373258909;  Thu, 15 Jul 2021 11:20:58 -0700 (PDT)
MIME-Version: 1.0
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>  <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>
In-Reply-To: <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>
From: Eric Rescorla 
Date: Thu, 15 Jul 2021 11:20:22 -0700
Message-ID: 
To: Russ Housley 
Cc: Martin Thomson , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000005eb17e05c72d88ff"
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jul 2021 18:21:08 -0000

--0000000000005eb17e05c72d88ff
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 15, 2021 at 7:11 AM Russ Housley  wrote:

>
>
> > On Jul 14, 2021, at 8:15 PM, Martin Thomson  wrote:
> >
> > On Wed, Jul 14, 2021, at 16:34, Mark Nottingham wrote:
> >> I'm leaning towards saying that we should explicitly NOT give the
> >> ability to create streams to any single body, or define a process. If a
> >> situation comes up where we want to do this (for some value of 'we'),
> >> the expectation should be that there's buy-in from all concerned --
> >> RSAB/WG, IETF, LLC, ISOC, etc. We can figure out a process then.
> >
> > Adding to the growing chorus of +1 here for saying nothing.  I don't
> even want to commit to a de facto status of the IAB deciding.  A change to
> the stream structure is a big enough deal that I'm happy to have that be a
> high energy event that -- if managed properly -- will garner support from
> all stakeholders.
> >
> > It's been good to have the discussion, but it has confirmed for me that
> dictating a process could only make things worse and would be unlikely to
> improve the situation.
>
> Maybe we want to require consensus among the existing stream managers to
> create a new stream.  That is the actual stream managers without delegation.
>

Can you say more about the reason for that?

Suppose, for instance, I found a new SDO, the EKR Engineering Task Force
(EETF) and I wish to publish my documents in the RFC series. What interest
does the IRTF (for example) have in whether I do so or not, as long as it
doesn't impact their operations?

-Ekr


> Russ
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--0000000000005eb17e05c72d88ff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Jul 15, 2021 at 7:11 AM Russ =
Housley <housley@vigilsec.com> wrote:



> On Jul 14, 2021, at 8:15 PM, Martin Thomson <mt@lowentropy.net> wrote:

> 

> On Wed, Jul 14, 2021, at 16:34, Mark Nottingham wrote:

>> I'm leaning towards saying that we should explicitly NOT give =
the 

>> ability to create streams to any single body, or define a process.=
 If a 

>> situation comes up where we want to do this (for some value of =
9;we'), 

>> the expectation should be that there's buy-in from all concern=
ed -- 

>> RSAB/WG, IETF, LLC, ISOC, etc. We can figure out a process then.
> 

> Adding to the growing chorus of +1 here for saying nothing.=C2=A0 I do=
n't even want to commit to a de facto status of the IAB deciding.=C2=A0=
 A change to the stream structure is a big enough deal that I'm happy t=
o have that be a high energy event that -- if managed properly -- will garn=
er support from all stakeholders.

> 

> It's been good to have the discussion, but it has confirmed for me=
 that dictating a process could only make things worse and would be unlikel=
y to improve the situation. 



Maybe we want to require consensus among the existing stream managers to cr=
eate a new stream.=C2=A0 That is the actual stream managers without delegat=
ion.

Can you say more about the reason =
for that?

Suppose, for instance, I found a new SDO=
, the EKR Engineering Task Force (EETF) and I wish to publish my documents =
in the RFC series. What interest does the IRTF (for example) have in whethe=
r I do so or not, as long as it doesn't impact their operations?

-Ekr




Russ



-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future




--0000000000005eb17e05c72d88ff--


From nobody Thu Jul 15 12:12:13 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB8A3A117B for ; Thu, 15 Jul 2021 12:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htkv51L3IzB6 for ; Thu, 15 Jul 2021 12:12:06 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2097.outbound.protection.outlook.com [40.107.20.97]) (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 C4CC53A1179 for ; Thu, 15 Jul 2021 12:12:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UT5+/svL+WPwXI2Ekhr2r+dOKxpUyDToIbH1lSAvUFwWMNsTkX5sV+8QWygAbiaLrHp4aX8p6Lb2+Od9LSLHnoqqCRVJYXpb1yDFfCMzZd74Pbyfl9pecNaAAhb4rzXNPKyW2dbdGkZzTWh7XmQMOGS0S14YNPSZmXCYqVgXo0yhKy1iXoZ/RX6g3GjTXEAazWIBbnWKss5Tg1Jvq6o5Bu8+ls3teXclSbdoMrixSSCVcF4f0wmSz+tjLmW+kDxk6daIWsJFZHui0D4chTp3wKQSRvHBgAUPB7p25ETFcLllnWW0h9nzG87Ed0ImYXtv/aRgfyVITuHH2NslXc7DXA==
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=RPSp0wE4ZX+HMMRTt1ekCS3VojwiatX3lOMChZHtoic=; b=MbJqhky/KyzAKHk3Vvzgw5TRcgkUdOXIPmXdh+OmpGjWFdRfeucvVCHIuiPkTrXuhgdfWt650Vpr/1WAYYl5e1m/OrIwWPDvYDikUsLeOEwjnIcB6FoExNgrq2ubcAEXT8X9P3Gz9ulRbQj7OsO4u2ie09acF98WKrDk6oE0AFHRs7dNM43iUzfD1/MctQzJfH+vmCUXkd0ACs+4A5WUl900QuCpKGt7HervL3E9Czc+WLGezK0iKp0y1euJZqnW3/i8Ic9IFxIgWRcS1WM19Ge7lLwgPmstypQGVr/0nl8CsFWF7klwWUAXSv221LKxA2SmJP1hWTS0KaCFJfP9uQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RPSp0wE4ZX+HMMRTt1ekCS3VojwiatX3lOMChZHtoic=; b=TUO5YzoywdUYpb4WY2OG3rPcUEQ1V7Ak3X+ifX17qqjcY3V9O4M2oazxqwA6Wu182mYMZLQBw7cqShi+J1f3IvYKdkv/v/jW3uU5itk8AEpUeqSHMQFChQeqPBQFIHGRl+btzmaVsM6QFNBVuppLbzfcAovjGRlC5LhY0lp/COP2Y5D/zv6gy5U71SrNbQzyo48zBKQuYp8aLTLpo0cHV5BLJ4serjzD9VLoiIzVL2F77jhfqIhJp9sXHcU9VGLTquTTIBQs9VMJ2FHigtaY9TkHDTh9v6e5Vv5p8frYlFBmp3hhDu+gaKIuFH79pDyxBOrWS7olmm3G/gN5Nb9CMA==
Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=cs.tcd.ie;
Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB9PR02MB7433.eurprd02.prod.outlook.com (2603:10a6:10:243::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.23; Thu, 15 Jul 2021 19:11:57 +0000
Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::4198:a9d1:7246:8272]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::4198:a9d1:7246:8272%3]) with mapi id 15.20.4331.024; Thu, 15 Jul 2021 19:11:57 +0000
To: Russ Housley , Martin Thomson 
Cc: rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>  <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>
From: Stephen Farrell 
Message-ID: <4bed79c8-d820-9d94-5cc9-254535b5afa7@cs.tcd.ie>
Date: Thu, 15 Jul 2021 20:11:54 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
In-Reply-To: <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nz4uRBzScyt0sFVLkKkcfJNvGzcl2ob87"
X-ClientProxiedBy: DB9PR01CA0023.eurprd01.prod.exchangelabs.com (2603:10a6:10:1d8::28) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [IPv6:2001:bb6:5e5e:b458:7296:13c:55ea:76d5] (2001:bb6:5e5e:b458:7296:13c:55ea:76d5) by DB9PR01CA0023.eurprd01.prod.exchangelabs.com (2603:10a6:10:1d8::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.22 via Frontend Transport; Thu, 15 Jul 2021 19:11:56 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: aac7b4d2-2096-4be1-29b8-08d947c46a2f
X-MS-TrafficTypeDiagnostic: DB9PR02MB7433:
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-Microsoft-Antispam-PRVS: 
X-TCD-Routed-via-EOP: Routed via EOP
X-TCD-ROUTED: Passed-Transport-Routing-Rules
X-MS-Oob-TLC-OOBClassifiers: OLM:1850;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: qBg1kPlrK3WK3fmvbFgAvI7ZWcLy2ECtsr4+pEqj4Uu5qEL6VAxub/OPjNxujlXky6turbgv9sqkTRLwiZEW2oAAV3tV0mEJh/+CabpJQ6w8tZCNSLMCSEWlKrdCpgTjRJIXIY4DP6/YPXTt1ci60ud4cXWQOOqr8dd8CLLZkqcEJ0y3dZiZQVHSVJ+qPUj0hDiLouF/goS4ewlkma0gbRxkmmIJKLeVNiKVZkutAKm/lnbQxvHBR1HPqVUSiGyTAlYt/HiHLSHIPtSq4COfhqOFiswFjbITmYVm9fh+fv27sSQh7ln12gcrGSX6g2uxq6mwkGiCTBc4TDXUt90ycOJUA8q5hr2KJEybuz/kY9xU/fgDM6gVuHnWJzsd09gj3e+GGNO5Ig803PhaM5fQWwtpZe7C51nPo4BiWxYRl7ulYgu5vGvBmYT4Oja5xIWSlgi5lnVZUCawLpTxHz+cjKftjHDRYCBQojZAU0hknEQsDDsxwfS6u1WiXUipSXPWtln4Ko0SNXP5SsvNEnlsnQKa61T2qEMTVJbabBKA+3qzKP0Yur1YJhWokHwEq9ZM+hAf2kqxTjIDjrSq6g5ONDYMHr2fW+Ovy1HbDmz5Yn5MoVa2tgGCdXSYG5gduKmWLLO+gj43JWh/EqXRe9w6p+vZFlA1Jp6jRbUYrAtAvBgOp0G35HbPWjzEKhGW8GoE3YPCjxkxRn3lh6X1hMWhgA==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(346002)(136003)(396003)(39850400004)(376002)(366004)(31686004)(6486002)(36756003)(31696002)(478600001)(86362001)(83380400001)(316002)(786003)(44832011)(21480400003)(33964004)(110136005)(2616005)(4326008)(66556008)(66476007)(66946007)(66616009)(8676002)(235185007)(53546011)(8936002)(2906002)(186003)(38100700002)(5660300002)(43740500002); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SjdRQzh4Yk9nWllDNzJWOExBcHhjdG1pQnM1c0N2TFVFcEN5RG1TUGNnZGdZ?= =?utf-8?B?MmhEOXM4UXJaUHNzVWpiTlNtN2UyaFpoQjF4blhYeW4rSXVZaEFud1hIZ1cr?= =?utf-8?B?L0U5dTNwcnZmbWJRcUxnNUZKeUxVTzRzTHE4VXVEMUtCQWplc0FXREUxME8v?= =?utf-8?B?Y1FwQnBGWUtwTm5KazR4cVp3VVBhSFFkdXNCNk1hd0Q2QXFWUGFGSkYxWHVr?= =?utf-8?B?dGJGdmorbmphb0cvUUM1THFRSjVjNWV0TjkvT2ZCRWgzNHREL3hIYVZKbmlD?= =?utf-8?B?R0ZWaysyZ2tzb0t3YWlwYlJWRU5yVFNCc2JvS25xREVxVTZmRU9LNVpoVlVS?= =?utf-8?B?TFlreGRVQkZ1dWc4M2dFbXFkOWkwaXVBTHpuQmU2VDA4ZGNiSVpzeWtJL3lX?= =?utf-8?B?VTR0THBKYzNsZmhrTVprcHZPNjBIRXFzN2tNeFM1K3JKWjBYSDlNV3hVc2hG?= =?utf-8?B?ZU5NRzdiOHRCNkt4MUUwMWJoNzUyY3MwZnBPVGdZcEs4Qy80MmdoWnU1OWFQ?= =?utf-8?B?VHNVSlp2QTRRb2piOW8zc2NWSXB3YXdTUUtkMUh1V05Iemdma0MwVWNBZTE5?= =?utf-8?B?L3N2K2FGek16MFlsdXVDcUlmQ1hUUSs1ZVdZVGRTcTVIWHI2OXA4TUpWeGpN?= =?utf-8?B?b29EYldNekR4NnAwVGtJeC9KcVhJYnlzRVRLYllXcWpTdFh6eDg0VjZSRXFZ?= =?utf-8?B?QjZhTG1nWkRBOUdXOGFhUzUzaytiQXFHckJrSlprNW8vWVM2WFNOOFpxSVVj?= =?utf-8?B?TXg3Smt1YU9sOHNuU2ZtVjFGdmR4c1RPK3IxZ0xJcGVmZXVCSUxqSTN5bG9s?= =?utf-8?B?VXN0Y0lxb3BmKzJDZUVoc1FYVDJnUlJOU05EalJjMlZZaXhrSS96M2Y0YkRE?= =?utf-8?B?ZDhJaGl0SzBicGRRb2h5UGdFcjc3WWNwa2FIek9YUUhpSzdqRnRHdmZXTlE4?= =?utf-8?B?QW14cDNFeDdWWG5neDNCUzh6KzIzN2tib1NvWlRxUklKVDNkQjZ6eWk0M3ow?= =?utf-8?B?ZmhHQUFNVFFyVWxkeFR0WVJKZWI4dmdLUUZKUUJ5azBmSStqZHAway82ckFZ?= =?utf-8?B?SWJtd1J4OE84Z2M2bWVwMTI0K2ZFblNsQzBaMy9vb2MrVXUySlplMVZvYitO?= =?utf-8?B?MjFIVGhLVUlDZmh1QUpIU3Z6VUwyeEY3aVQvdEpaUkQ0TXcyc2hKeEtQZG4y?= =?utf-8?B?M09GRjFDb0pWTzRRc0hZQVNkVzRUVVFpekR1QlZXbDBsNHJqdXpZMCtJTGxs?= =?utf-8?B?dTl6eGsyN2Vqak1ndlpVR1I4Y25HZ1lNYjBUczNlckN0RS9XRklKaVh0OWVw?= =?utf-8?B?SVQ3a1FhKzBVWGpFZmhzS0dGVU9UWWVNeC9BcjRvZHlBcnphNUxYbm9ORWlX?= =?utf-8?B?dzVucWlZNm1jTy9YNm05QUxwZ0FTRlhtVXhYRkE3TGFNMDA5YlYyaElSdkhR?= =?utf-8?B?TVkrZmRpK0xaQ243VEJRWWpPTmV1UmJlVlN0WDdSbVhFUVB3OU9MZGFMRmlG?= =?utf-8?B?K2F2ek04MFNzM2I0cFJaTE1qYWdKd05iMDFXc0szTXh0WDl1R3BHK05aODhI?= =?utf-8?B?aElOV0tlWWFRQk9HQkFtYXVUUzFiaks2K01sOTVCZC9ZNWZKaWFmejQ1WlE0?= =?utf-8?B?TkxCQlk5VGloRzNucjVwbE9CZ2crcXJHbDRmM2ZiM0RHRXBZdmF1aHhXeHFG?= =?utf-8?B?L1M0RktEempseFg1Y042VEFxUVlPVGdqYmpQSFcwd3dGSk5Md3JCbUt2YmpW?= =?utf-8?B?TkJzakVTUnNLZ2lXeVM4T0gvZGtlZm15UkVIbWUwU25VQXJhcklvaXBBL2Zm?= =?utf-8?B?Q2JISTYzNWJZVFFCNXhtbkt3U0lsNW9iQTEwNzBXWCtvRlFpc2lSUXV3a2Jk?= =?utf-8?Q?us4EJyjTdNp7Z?=
X-OriginatorOrg: cs.tcd.ie
X-MS-Exchange-CrossTenant-Network-Message-Id: aac7b4d2-2096-4be1-29b8-08d947c46a2f
X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2021 19:11:57.2232 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: lc7K+bvWkwHONl4r0FDNYo3Z7PcAIZEI60ZlQjQTJm6BKdHyGhxzmAy3D9oMtcTW
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR02MB7433
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jul 2021 19:12:12 -0000

--nz4uRBzScyt0sFVLkKkcfJNvGzcl2ob87
Content-Type: multipart/mixed; boundary="rozoNysxbbzON48XLDaerrirsMBNuJ3PG";
 protected-headers="v1"
From: Stephen Farrell 
To: Russ Housley , Martin Thomson 
Cc: rfced-future@iab.org
Message-ID: <4bed79c8-d820-9d94-5cc9-254535b5afa7@cs.tcd.ie>
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new
 streams?
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch>
 <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>
 
 <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>
In-Reply-To: <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>

--rozoNysxbbzON48XLDaerrirsMBNuJ3PG
Content-Type: multipart/mixed;
 boundary="------------36730FC6C992B68E073FDE7E"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------36730FC6C992B68E073FDE7E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable


Hiya,

On 15/07/2021 15:10, Russ Housley wrote:
> Maybe we want to require consensus among the existing stream managers
> to create a new stream.  That is the actual stream managers without
> delegation.
I'd not be for making such a statement. Adding such a
requirement could easily be interpreted as being the
only requirement, which'd be a bad outcome IMO. If/when
we make a new stream I think all the communities we can
reach ought be ok with that and not only a handful of
people.

Cheers,
S.


--------------36730FC6C992B68E073FDE7E
Content-Type: application/pgp-keys;
 name="OpenPGP_0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Description: OpenPGP public key
Content-Disposition: attachment;
 filename="OpenPGP_0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5=
Cg8
gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq=
978
CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu=
D/Q
9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4=
tNn
cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB=
wV+
4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir=
1GC
YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav=
ACY
Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D=
VQu
8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER=
8la
5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE=
wEI
ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC=
xAA
pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX=
Az9
+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL=
F+X
+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4=
g1U
QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre=
k3U
P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2=
niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL=
4Nw
tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m=
6vt
ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7=
+8A
CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ=
LvC
wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8=
rpK
o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr=
qJs
CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa=
W/r
KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG=
gMW
rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u=
rqR
1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/=
0A9
J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc=
JBD
EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4=
vrp
2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA=
xvK
dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK=
xlf
tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg=
Uky
o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO=
aHv
X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp=
yyz
JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ=
uLE
FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w=
sDc
BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer=
3UM
TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP=
jt5
uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK=
171
RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR=
Lpg
RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov=
wza
tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0=
zG3
6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ=
eah
r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ=
GNz
LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o=
3cC
GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo=
w5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h=
Rcs
RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC=
Y98
iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd=
h2k
4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4=
EIk
CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ=
DIJ
pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4=
tvy
a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4=
ul3
qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc=
G9g
ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt=
w/r
1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ=
Jaf
3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1=
4Q0
7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf=
qtu
Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C=
gHw
26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC=
wIE
FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL=
rfb
e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF=
etu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8=
v39
+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr=
1oD
3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr=
m2D
Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby=
y/A
UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO=
jao
P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz=
leL
Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC=
2X4
pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g=
1MS
BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34=
YT0
auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb=
edD
Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3=
1qG
/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV=
YW6
R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg=
4Im
VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm=
qyH
eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx=
qnk
SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ=
Esc
YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n=
2Hw
xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F=
eIY
jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E=
AuF
CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4=
2AY
R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH=
X5v
aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q=
Csw
Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq=
yA4
3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m=
Eer
0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI=
Dxz
dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC=
QgH
AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ=
i0B
igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn=
i9g
OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy=
sIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n=
66v
xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/=
3r2
BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM=
YtU
N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr=
5iW
XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/=
zek
ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b=
a0H
Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP=
Ic2
gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6=
XE6
i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1=
16u
/HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J=
G9a
SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW=
OMq
N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz=
0YO
K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4=
vYl
zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx=
nNb
KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+=
5HN
HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq=
4hn
l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn=
Zbg
JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d=
nJj
j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8=
WLI
aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc=
dPC
Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX=
o4+
Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO=
Tyk
rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9=
hZM
0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5=
P3f
WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp=
cL2
lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk=
etP
GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3=
zRq
k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0=
20q
pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U=
DIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x=
/nL
PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE=
hOV
fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D=
VI9
DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT=
uW/
eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD=
aWT
3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6=
1df
mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8=
MAv
2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA=
HZR
5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo=
qj1
gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6=
Mas
qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi=
RkM
dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB=
++/
KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX=
xMD
rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf=
ZtA
ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN=
2OE
0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT=
zcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7=
IKP
3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW=
Iys
s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3D40Nd
-----END PGP PUBLIC KEY BLOCK-----

--------------36730FC6C992B68E073FDE7E--

--rozoNysxbbzON48XLDaerrirsMBNuJ3PG--

--nz4uRBzScyt0sFVLkKkcfJNvGzcl2ob87
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmDwiHoFAwAAAAAACgkQWrL68XsXK+oi
5hAAjXmtPgi2EQ49FPEL48trAuZ2Zzfq7OVyIPVqj5xkbe2ffyghqVIEhZfXPpQIzl5SOdObWdyF
wphFiuSgQx+OZA8qVFiVERsWRp1uDqfA0i44kB5zF9EvgTRST6QThj5IWcoCwrij/v2vQHn4ofxi
8VssigU8jfeqjb0zkUVJmYbt25ghg0pfaHKdIhujAiImUVpQZAL3lxCSiqqyAUQ4TULbzVo6+DzC
fTc8G+0R/LmJ9fwgNTVrSJOA7DLtv5FNI1Z6Gp4OuL4vrwQFGUz1IeCGOtlnPwRiBrJVu9HFzDkI
L+3zNlhGDCmqt4Johv1qStClE9mZEyM3VP1P548JMt+Sv3TLa5FC6mtsCuSIb+BmnP/PTQtDS4eb
p7DOWOk70TCutla48KHxl51cJmH+j66a95v2CJmAB3pdU9Mb44xoFYVGHv+pi7nXClPFxBLyQbKZ
U5okGk6i2rHVOAWB1uiMRRDS/3VvRZlpdaC/L1o/CAP+QXq1RTZS8oudl6HYkyCsRoX8rdgY9zbR
1K/EmvrbEPbwLs1rs69wyIG2v9+SOVjQ7YLFfuRxeyZg9496AUo0J6HPtyVlP9yiy0u+dYS2l2md
bMPgSeEj8+5kBdR0ulIyw0h9GmL4bVStYKGnm+Do31ezbTLIRsaNTwjq9Ci5u2HhQbqhLJcb5ziN
t/g=
=1prj
-----END PGP SIGNATURE-----

--nz4uRBzScyt0sFVLkKkcfJNvGzcl2ob87--


From nobody Thu Jul 15 12:22:49 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE863A05AC for ; Thu, 15 Jul 2021 12:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg-qQldvu743 for ; Thu, 15 Jul 2021 12:22:43 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AD03A059F for ; Thu, 15 Jul 2021 12:22:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8F3FD300BE2 for ; Thu, 15 Jul 2021 15:22:42 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2Hq5o0E975sj for ; Thu, 15 Jul 2021 15:22:40 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 1D82C300AC4; Thu, 15 Jul 2021 15:22:40 -0400 (EDT)
From: Russ Housley 
Message-Id: <82AA409C-402A-4110-941A-69D7FC4E7731@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A3A2B500-B0F7-495E-8BBF-F7718EEDC39E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Thu, 15 Jul 2021 15:22:39 -0400
In-Reply-To: 
Cc: rfced-future@iab.org, Martin Thomson 
To: Eric Rescorla 
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>  <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com> 
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jul 2021 19:22:48 -0000

--Apple-Mail=_A3A2B500-B0F7-495E-8BBF-F7718EEDC39E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

EKR:

>=20
> > On Jul 14, 2021, at 8:15 PM, Martin Thomson > wrote:
> >=20
> > On Wed, Jul 14, 2021, at 16:34, Mark Nottingham wrote:
> >> I'm leaning towards saying that we should explicitly NOT give the=20=

> >> ability to create streams to any single body, or define a process. =
If a=20
> >> situation comes up where we want to do this (for some value of =
'we'),=20
> >> the expectation should be that there's buy-in from all concerned --=20=

> >> RSAB/WG, IETF, LLC, ISOC, etc. We can figure out a process then.
> >=20
> > Adding to the growing chorus of +1 here for saying nothing.  I don't =
even want to commit to a de facto status of the IAB deciding.  A change =
to the stream structure is a big enough deal that I'm happy to have that =
be a high energy event that -- if managed properly -- will garner =
support from all stakeholders.
> >=20
> > It's been good to have the discussion, but it has confirmed for me =
that dictating a process could only make things worse and would be =
unlikely to improve the situation.=20
>=20
> Maybe we want to require consensus among the existing stream managers =
to create a new stream.  That is the actual stream managers without =
delegation.
>=20
> Can you say more about the reason for that?
>=20
> Suppose, for instance, I found a new SDO, the EKR Engineering Task =
Force (EETF) and I wish to publish my documents in the RFC series. What =
interest does the IRTF (for example) have in whether I do so or not, as =
long as it doesn't impact their operations?

I think that the existing stream managers need to agree that the =
additional stream adds value to the RFC series.  So in your example, the =
EETF would needs to write documents to define the stream if the existing =
stream managers agree that the addition is a win-win outcome.  The end =
result would be a new stream (that includes the agreed phrase for the =
upper left corner of the title page), a new stream manager, and a new =
seat on the RSAB.

Russ


--Apple-Mail=_A3A2B500-B0F7-495E-8BBF-F7718EEDC39E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

EKR:


> On Jul 14, 2021, =
at 8:15 PM, Martin Thomson <mt@lowentropy.net> wrote:

> 

> On Wed, Jul 14, 2021, at 16:34, Mark Nottingham wrote:
=

>> I'm leaning towards saying that we should explicitly NOT give =
the 

>> ability to create streams to any single body, or define a =
process. If a 

>> situation comes up where we want to do this (for some value of =
'we'), 

>> the expectation should be that there's buy-in from all =
concerned -- 

>> RSAB/WG, IETF, LLC, ISOC, etc. We can figure out a process =
then.

> 

> Adding to the growing chorus of +1 here for saying nothing.  I =
don't even want to commit to a de facto status of the IAB =
deciding.  A change to the stream structure is a big enough deal =
that I'm happy to have that be a high energy event that -- if managed =
properly -- will garner support from all stakeholders.

> 

> It's been good to have the discussion, but it has confirmed for me =
that dictating a process could only make things worse and would be =
unlikely to improve the situation. 



Maybe we want to require consensus among the existing stream managers to =
create a new stream.  That is the actual stream managers without =
delegation.

Can you say more about the reason for =
that?

Suppose, =
for instance, I found a new SDO, the EKR Engineering Task Force (EETF) =
and I wish to publish my documents in the RFC series. What interest does =
the IRTF (for example) have in whether I do so or not, as long as it =
doesn't impact their operations?

I =
think that the existing stream managers need to agree that the =
additional stream adds value to the RFC series.  So in your =
example, the EETF would needs to write documents to define the stream if =
the existing stream managers agree that the addition is a win-win =
outcome.  The end result would be a new stream (that includes the =
agreed phrase for the upper left corner of the title page), a new stream =
manager, and a new seat on the RSAB.

Russ

=

--Apple-Mail=_A3A2B500-B0F7-495E-8BBF-F7718EEDC39E--


From nobody Thu Jul 15 14:08:10 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE87F3A0D49 for ; Thu, 15 Jul 2021 14:08:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZspXUal2chP for ; Thu, 15 Jul 2021 14:08:04 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 4B4F83A0D47 for ; Thu, 15 Jul 2021 14:07:59 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id v14so4081506plg.9 for ; Thu, 15 Jul 2021 14:07:59 -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=ac6KBlyfjPYSn3ahLJoo8i/NIiH/YjnjBpk5fDAd6gI=; b=UlFNISFuuasfKKgE4l7iWaiDEzEcr9iSSjx7UNr2zXTv+kuJqVZ7/aNqiJgdYlyxEf aOUyq1iMRqtvxFjz0P9dWwYGx5mvIdaFmuqIaME1rwsRJgXwZFYehU16GjRIPiMZx/qN VGz6/4jsr2IaSYeYq4UJdn6wLIfF91p7hp1en50oYDLyPnQs7f48N/9dhkutaEKSnOn1 s3rlYRJvuv6rTIp9ObZEWPbfWjXfDqddFKBLlTtXXNmjKvlDLuwLlvobowjs+nN6fvDQ HbTQ87rmr9Iz4WBwnSfzQf2yXn3PMXwVTw3sV4a5LoxUR6jsdwxMvjxynRc9oV+/4F2H 6Dpg==
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=ac6KBlyfjPYSn3ahLJoo8i/NIiH/YjnjBpk5fDAd6gI=; b=MV1SWfW406VZfV7H6aJMNshJpgZ5b3yyjYmH6l1tDwbfxjGw4YHz/CWITij1O5WcVt 1quo0xb8sdhk22Cvlr9OeSPV/a30s8JHQHGrAUAf2vYV4F/vjwJFIbF4K3WwAEAAaObd bQ4UKP49Cf0YSL/hqASEJnvOldRLwiu3xuAZ7Jyb69p9c1hFJPUijNOyXe8k+MzeRq5G I2Y2+pTBBeFtr+HLweCYSu8dYEJgHzabqcYOzzItpNy4lidgDID/z71nFquYAipDCnIe v7naHIMpExr940kLxi/jGAWxi6oPfAxqPt9DgGBO7/DumfmdaWO7mQR00IiZ2wMXmSUB YhfQ==
X-Gm-Message-State: AOAM530OB9fwg8iYXMD40/e9LL3/D+IMvLI2JJ+wsM9m+iWwtdWtQeVr weHN25heeGaMTIrEVYCNe3fA6EYuei19TA==
X-Google-Smtp-Source: ABdhPJwqliBiJxrM45ro+/ZLdpkq+VUoM6q/bj99vJOciCfbWbC4Nk3KpEF6zxRB9D1OYGBns4IUNA==
X-Received: by 2002:a17:90a:e409:: with SMTP id hv9mr6191471pjb.123.1626383278196;  Thu, 15 Jul 2021 14:07:58 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id z15sm8307344pgu.71.2021.07.15.14.07.56 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jul 2021 14:07:57 -0700 (PDT)
To: rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>  <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>  <82AA409C-402A-4110-941A-69D7FC4E7731@vigilsec.com>
From: Brian E Carpenter 
Message-ID: 
Date: Fri, 16 Jul 2021 09:07:53 +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: <82AA409C-402A-4110-941A-69D7FC4E7731@vigilsec.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jul 2021 21:08:10 -0000

On 16-Jul-21 07:22, Russ Housley wrote:
> EKR:
>=20
>>
>>     > On Jul 14, 2021, at 8:15 PM, Martin Thomson > wrote:
>>     >
>>     > On Wed, Jul 14, 2021, at 16:34, Mark Nottingham wrote:
>>     >> I'm leaning towards saying that we should explicitly NOT give t=
he
>>     >> ability to create streams to any single body, or define a proce=
ss. If a
>>     >> situation comes up where we want to do this (for some value of =
'we'),
>>     >> the expectation should be that there's buy-in from all concerne=
d --
>>     >> RSAB/WG, IETF, LLC, ISOC, etc. We can figure out a process then=
=2E
>>     >
>>     > Adding to the growing chorus of +1 here for saying nothing.=C2=A0=20
I don't even want to commit to a de facto status of the IAB deciding.=C2=A0=20
A change to the stream structure is a big enough deal that I'm happy to h=
ave that be a high energy event that -- if managed properly -- will garne=
r support from all stakeholders.
>>     >
>>     > It's been good to have the discussion, but it has confirmed for =
me that dictating a process could only make things worse and would be unl=
ikely to improve the situation.
>>
>>     Maybe we want to require consensus among the existing stream manag=
ers to create a new stream.=C2=A0 That is the actual stream managers with=
out delegation.
>>
>>
>> Can you say more about the reason for that?
>>
>> Suppose, for instance, I found a new SDO, the EKR Engineering Task For=
ce (EETF) and I wish to publish my documents in the RFC series. What inte=
rest does the IRTF (for example) have in whether I do so or not, as long =
as it doesn't impact their operations?
>=20
> I think that the existing stream managers need to agree that the additi=
onal stream adds value to the RFC series. =C2=A0So in your example, the E=
ETF would needs to write documents to define the stream if the existing s=
tream managers agree that the addition is a win-win outcome. =C2=A0The en=
d result would be a new stream (that includes the agreed phrase for the u=
pper left corner of the title page), a new stream manager, and a new seat=20
on the RSAB.

Yes, it's quite normal for the members of a club to choose who may join t=
he club. That's why it seems to me that *all* we need to say on this topi=
c is that new streams would need approval by RSWG/RSAB/IAB and must have =
a funding model acceptable to the LLC.

   Brian


From nobody Thu Jul 15 17:37:06 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8B53A1CB6 for ; Thu, 15 Jul 2021 17:37:04 -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, 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=mnot.net header.b=TyqLSKa1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qmHh4R4/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNGslYfTqPNc for ; Thu, 15 Jul 2021 17:36:59 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9379C3A1CB5 for ; Thu, 15 Jul 2021 17:36:59 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 440493200908; Thu, 15 Jul 2021 20:36:58 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 15 Jul 2021 20:36:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=y PUfup94Jk8uamDOSGuoOxh6Cx6FKsulrW8dQ95UhKI=; b=TyqLSKa1WzvjoUk+a JEwwj4dzwnpDs+0DP/skkCyDZdDh5G/osst8HahsL7cOJFxv2569hM3X1JQ2erIX eRTVY6XpUPCBqcYFjGz0QxB5HImNW12bCHAJ4Vix+7tcq6ImwIBRhb/Ta+uaPZ1/ vzFIY9fJdmE901zzIgAStJ/NZ5COGMrSQyV4e40Ds3gRxnIKhquxMOfiud5SBBrc p0gzBmR3xw93aCZF5o0+zxQkz/wlgkQwZEBFjteYs3P5+9vdP/U10ayuMDAPo1so cFfpYGAaRGaefVe5V4wfF+uiaxKkP9+Y5bQFVLkYgp0zRUfpzbqbGA0lHNVDXoI3 XO3pQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=yPUfup94Jk8uamDOSGuoOxh6Cx6FKsulrW8dQ95Uh KI=; b=qmHh4R4/y+G8dfSqzFoNubR4ZRabBxtRC8M76L3OTdgzQlsFZZTUZWj5/ mSpaK3+txolJ47FFQDU6ix8qKQhzW/DuYcXYB7plsSnRSPCokUNW3a8+0jRqu6Vl wABMN0AgDigZvetPw5jK1oc8iTy+UEz5kL0jbB/u7j1CWLqbFMeSd3cZMVni6aok 8X5cuIVdtj5MwKzDfLvuJm1xz72Naa5UXTd7VKNcI3HxOy6pZdLgTSXlNyKMtq9G QQ765W6BOvGorOGJRKnvrI9soVb5MlALBjdR7nsWOwbW8rStZm3kfg/qdyTRU9Mz RwvjeuD+TFxl/ZfqN8snakF+it0aQ==
X-ME-Sender:  
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvgdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 15 Jul 2021 20:36:53 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Nottingham 
In-Reply-To: 
Date: Fri, 16 Jul 2021 10:36:51 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <83C4211C-1BB0-4C8F-ABC6-14253C067B74@mnot.net>
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>  <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>  <82AA409C-402A-4110-941A-69D7FC4E7731@vigilsec.com> 
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jul 2021 00:37:04 -0000

> On 16 Jul 2021, at 7:07 am, Brian E Carpenter =
 wrote:
>=20
> Yes, it's quite normal for the members of a club to choose who may =
join the club. That's why it seems to me that *all* we need to say on =
this topic is that new streams would need approval by RSWG/RSAB/IAB and =
must have a funding model acceptable to the LLC.


I think saying even that is dangerous -- it implies that these bodies =
can do so without community consultation or other considerations -- it =
effectively defines a process, and its brevity works against it.

I'd prefer a statement in the negative -- e.g., 'The bodies defined in =
this document cannot, on their own, introduce a new stream.' That's =
in-scope for this effort, makes the concerns expressed clear, and =
doesn't give any unwarranted permission.=20

Cheers,

--
Mark Nottingham   https://www.mnot.net/


From nobody Thu Jul 15 17:51:21 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B89F3A1D39 for ; Thu, 15 Jul 2021 17:51:19 -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 DLz6zLqY3eRB for ; Thu, 15 Jul 2021 17:51:14 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 89DF03A1D34 for ; Thu, 15 Jul 2021 17:51:14 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id d9-20020a17090ae289b0290172f971883bso7836440pjz.1 for ; Thu, 15 Jul 2021 17:51:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lpyCoLaPCJcl1KP6yVudXdlFLbFfy7zBaiEsy8CLxis=; b=FYvC6i8z2q2DGwha7MFvT0tNPCEWCHsMtrh8aH+Wg3n1H07ncIfrDFMQO/aMFKKXIa 5vR5iclZWnorh6c1xaiZlf+INOVp8xNI7hLo7i/sWYViNIZ257paE4PhBCzCmOD82BLI aYgrWWn9VDnXOeuNHC2E/8SWJ1jnAewNejICvYdeOC2w6hOxMJYZ1wH6NEE1tEGfscfI QI6Fvbc4XiVyhh+yWhLtVt2qE6hxS8ZTu2t9FgzZISwOO412LAn3Izr6GZCRi3ToYmT2 ZV7YgqBuNKWY9O/e6mPtuLO6KeLkE65B7rlKtL7kKro5hIc/5JcDzlP+BVVcXeKimoV6 TPqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lpyCoLaPCJcl1KP6yVudXdlFLbFfy7zBaiEsy8CLxis=; b=nLcaJrEh/7QKa03mcaZHk+W7on1WpZNQdI1/4ziZ034Q8vP2a3h7MDIGX+fuqZ/+hY o0plz4tCeVsc+7cQIQq5nPV2gd08SnpsiAj7mxppB0PJdNWnZ05tRWzdSkfv5wyCMmJd HzlZTc7OD7JeV2KeLOXWZwe6Q1djjzbgNM2BELFQzdb4SW/XkEFdaDZB043G/kehlXT9 AncO2q8KnZm9/h347WmX9kK9TfuRK0ADsy6dezONgkvV81ByOoS0xwIviCxVrRQEVtf3 7JIoxlMVazRrQTwFeSL7s50yxmf4ovzKppCWi6heAKi15CzdnpFGdlEdP+uCWeAurC1y bmUw==
X-Gm-Message-State: AOAM532BQYT3OBsKfMnDRr9eRuWUme6jpOORs/zDdERGYXEWHRxtp8EN xfPoc2Ucs8rtx2tPmnQ4VwltibyBbVtXPg==
X-Google-Smtp-Source: ABdhPJyTZpe5o1yxZ9EcMa46XavWFyVtqTztv5Xv+gzd+1BhIC5u4ePRLhwlWCYN1K0wXP+GTJyv5A==
X-Received: by 2002:a17:90a:fb51:: with SMTP id iq17mr12942292pjb.36.1626396673485;  Thu, 15 Jul 2021 17:51:13 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id t5sm9328830pgb.58.2021.07.15.17.51.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jul 2021 17:51:12 -0700 (PDT)
To: Mark Nottingham 
Cc: rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>  <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>  <82AA409C-402A-4110-941A-69D7FC4E7731@vigilsec.com>  <83C4211C-1BB0-4C8F-ABC6-14253C067B74@mnot.net>
From: Brian E Carpenter 
Message-ID: <1cf2c540-95fc-0041-1e8c-63e72b873135@gmail.com>
Date: Fri, 16 Jul 2021 12:51:09 +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: <83C4211C-1BB0-4C8F-ABC6-14253C067B74@mnot.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jul 2021 00:51:19 -0000

On 16-Jul-21 12:36, Mark Nottingham wrote:
>> On 16 Jul 2021, at 7:07 am, Brian E Carpenter  wrote:
>>
>> Yes, it's quite normal for the members of a club to choose who may join the club. That's why it seems to me that *all* we need to say on this topic is that new streams would need approval by RSWG/RSAB/IAB and must have a funding model acceptable to the LLC.
> 
> 
> I think saying even that is dangerous -- it implies that these bodies can do so without community consultation or other considerations -- it effectively defines a process, and its brevity works against it.

Hmm. RSWG *is* community consultation, so I don't really understand what else we could ever specify.

> I'd prefer a statement in the negative -- e.g., 'The bodies defined in this document cannot, on their own, introduce a new stream.' That's in-scope for this effort, makes the concerns expressed clear, and doesn't give any unwarranted permission.

But it leaves open the question of who else has a voice. If the RSWG is open to everybody, who else *is* there? I'd rather say exactly nothing than this.

   Brian


From nobody Thu Jul 15 17:52:57 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668C13A1D3E for ; Thu, 15 Jul 2021 17:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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=mnot.net header.b=RPRGj5v9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=H9z0B+4U
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESd0yo7jcK7C for ; Thu, 15 Jul 2021 17:52:49 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307343A1CFC for ; Thu, 15 Jul 2021 17:52:49 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7EEF93200922; Thu, 15 Jul 2021 20:52:46 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 15 Jul 2021 20:52:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=C RYaQ/LoelUH32UPrJsD1mUhYNlofaM33rJjXmfubwk=; b=RPRGj5v91fWd0GJiZ 4OvLc/aNalG7BIpJZlub/Ks9xIXPCXgxMKB8G0xmzLgj5UDLTs/dhnhjluyLxyHo HQUjUXoyUct5Ss1+M489xBnL0O69PD6wss4oZKXVkX7Ry6GCwxjVbb4YNLcs6xfg ALRcGYi04f6F8BRFOf1sIkLdMXsgMIjeQEb6r2MMPZ57fBuj0nA37gnS3VZKQXvq e7ZVYsqUc/u7m9MwYWRJAoOvvXpuSPePZ5dTV0gWVdzh34rSfhqdFjr2QRnXE2NL 7C3Z1AFvuTq8F26AzcrRJwSKCq4Dl9y6aGNZyaACOXMPX1U5xwK7T5NhACRKyWip 6wZgA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=CRYaQ/LoelUH32UPrJsD1mUhYNlofaM33rJjXmfub wk=; b=H9z0B+4Uh1OfJywpXU25rIs8AQBG5HwiXWzRVD+7BaP8MS5ArcNnI+rF4 3S8ru2yX+nvZokUYTKXIupWMHYvE5OiBqTAfpfYjdGZri9f6F6e0NLp3MUswbpA6 duPoiBWLZxXhSROazpoYkVgELVZ6V3WWahO9bWjjEQI+U59aHkxoUKxxhzlygpje PBMH9i2ilL9EXRcCnI+24teu8JsFxpwx8jG/cOuVanRRDn2LRXAPKiK+hb5UZf3e eMbkSjI19f/ZlVc8avPBmXu+lb9ThM5b+0OGAyMB63JR5EmWWjhqK8H0ax5BMMhq +AnJaFAghbJ+tWXExp2/B4ZBnUz1Q==
X-ME-Sender:  
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvgdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 15 Jul 2021 20:52:43 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Nottingham 
In-Reply-To: <1cf2c540-95fc-0041-1e8c-63e72b873135@gmail.com>
Date: Fri, 16 Jul 2021 10:52:41 +1000
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>  <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>  <82AA409C-402A-4110-941A-69D7FC4E7731@vigilsec.com>  <83C4211C-1BB0-4C8F-ABC6-14253C067B74@mnot.net> <1cf2c540-95fc-0041-1e8c-63e72b873135@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jul 2021 00:52:55 -0000

> On 16 Jul 2021, at 10:51 am, Brian E Carpenter =
 wrote:
>=20
>> I'd prefer a statement in the negative -- e.g., 'The bodies defined =
in this document cannot, on their own, introduce a new stream.' That's =
in-scope for this effort, makes the concerns expressed clear, and =
doesn't give any unwarranted permission.
>=20
> But it leaves open the question of who else has a voice. If the RSWG =
is open to everybody, who else *is* there? I'd rather say exactly =
nothing than this.

Would a reformulation like this help?

> Consensus within the RSWG and/or approval by the RSAB are not =
sufficient to define a new stream; the requirements and process for =
doing so are out of scope in this document.

Cheers,

--
Mark Nottingham   https://www.mnot.net/


From nobody Thu Jul 15 19:14:12 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E183A1FEC for ; Thu, 15 Jul 2021 19:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVVG4-ujK6rb for ; Thu, 15 Jul 2021 19:14:09 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB84C3A1FEB for ; Thu, 15 Jul 2021 19:14:08 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id 62so8549324pgf.1 for ; Thu, 15 Jul 2021 19:14:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6+hPUCtYzHNOeMdevX5vratb2igsYDe5a/FC7LPmn0Y=; b=f8OtfG2kkEuT8GT8efxianijnt7zLzrSHijt0SYsuSfBglcN6sB0MLBa++8sKSBbfq yM+9Rjl3Y2xtAOu+rLHj54sYiZxKuBjWklOSr77GKmgAgB+e1+c/3KOcwBsFN7B2XkAQ WWSVxYFv8M0iOYvbgwOK2T3cUEomSSbVv/F2MCTMvix91XLDmYq/0Hr12w1UFdgU03rt LCo5kj/R9OlThQJI/CEh/vj55B4/vixS7+2OT2JwPsr6PUgDvN5fpSnTwkAn0B8pgXnA J7NfPHUI2uUS+qTSlIZWJjFHBiJv5LaVmX/4A1ue0vK6W/w3FW1nbo/NQ4qk4v1OZjop oanA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6+hPUCtYzHNOeMdevX5vratb2igsYDe5a/FC7LPmn0Y=; b=NyRss+YavJDbfXNu/b+8GWUsp2Xb51cac3VQ7wucIK7obvIerer3vs99WyXde71qKr leS5LNr01jyZlMaP1mEhI+FXL7Y+Xisyot/jTnGvvmnodiVofaxnOHhmrkkqns0OE/oL WRtETyxT4PAlJtAupCWQHV+X/R4xG5Ns6+aE1otFnIwp7wAH85r8WPG7EgUY48ne+Jdk wArwNRBruFgZNhxn9eM3Bp1wz5DDuYoD/Z6qY+P4BwRptkgDtshMgYL6onzpTsrmH6y8 iAUVfT0nL3k/u2t/7e198+uDrU9webkktBH3AlBiKmhd6t3YQITQH34/vSli0urLJeHW ZEYQ==
X-Gm-Message-State: AOAM531WezTu97GV75R5uoc+Dwvtmj8esidskC3dfjeK78WzFx5zM8Fn Tpx8F/ceqv90ssAuaiS0qHYnJ071eRskHg==
X-Google-Smtp-Source: ABdhPJz/yHYaDG+4S6PWu8vOC/q/j7+S06hIj5asdl80FrMF/A8sJv+RVkbUBDGhKyITSi+Q5wYtkA==
X-Received: by 2002:a62:1bc7:0:b029:328:cbf5:b6b0 with SMTP id b190-20020a621bc70000b0290328cbf5b6b0mr7535847pfb.81.1626401647389;  Thu, 15 Jul 2021 19:14:07 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id q3sm7884375pfj.89.2021.07.15.19.14.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jul 2021 19:14:06 -0700 (PDT)
To: Mark Nottingham 
Cc: rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>  <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>  <82AA409C-402A-4110-941A-69D7FC4E7731@vigilsec.com>  <83C4211C-1BB0-4C8F-ABC6-14253C067B74@mnot.net> <1cf2c540-95fc-0041-1e8c-63e72b873135@gmail.com> 
From: Brian E Carpenter 
Message-ID: <89c63c8f-a096-3e92-7af5-c4160c16b82a@gmail.com>
Date: Fri, 16 Jul 2021 14:14:02 +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: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jul 2021 02:14:11 -0000

Hi Mark,
On 16-Jul-21 12:52, Mark Nottingham wrote:
> 
> 
>> On 16 Jul 2021, at 10:51 am, Brian E Carpenter  wrote:
>>
>>> I'd prefer a statement in the negative -- e.g., 'The bodies defined in this document cannot, on their own, introduce a new stream.' That's in-scope for this effort, makes the concerns expressed clear, and doesn't give any unwarranted permission.
>>
>> But it leaves open the question of who else has a voice. If the RSWG is open to everybody, who else *is* there? I'd rather say exactly nothing than this.
> 
> Would a reformulation like this help?
> 
>> Consensus within the RSWG and/or approval by the RSAB are not sufficient to define a new stream; the requirements and process for doing so are out of scope in this document.

Yes, I think that kicks the can down the road quite effectively ;-)

Thanks
   Brian


From nobody Fri Jul 16 03:04:57 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3BA3A30B2 for ; Fri, 16 Jul 2021 03:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level: 
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZs2FyqSjHfX for ; Fri, 16 Jul 2021 03:04:48 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 601E33A30B1 for ; Fri, 16 Jul 2021 03:04:48 -0700 (PDT)
Received: from Lear-Air.home (pool-173-54-226-148.nwrknj.fios.verizon.net [173.54.226.148]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16GA4WnP255232 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 16 Jul 2021 12:04:33 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626429874; bh=BpI3zXsSJmsmSSem43ky+qX4k9EFumwwH0Fj5JbU/tE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=uLaVaErF6AtSoyPhO63w+PzpzwM4qdlRNuz+t1L3urpvcTlL0x/NVAcrHyYS9fSLP DNb7hpWJIev+tOAx5DDFZGM2Em8+WHz6SNQBVQjndC06xJ8k6LqEdWHy5wmjllFynJ pFoGHLhQ67egU1x+OoEQUdfQGAMgzfgtMUKGH/EI=
To: Mark Nottingham , Brian E Carpenter 
Cc: rfced-future@iab.org
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>  <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>  <82AA409C-402A-4110-941A-69D7FC4E7731@vigilsec.com>  <83C4211C-1BB0-4C8F-ABC6-14253C067B74@mnot.net> <1cf2c540-95fc-0041-1e8c-63e72b873135@gmail.com> 
From: Eliot Lear 
Message-ID: <5f70f69b-df99-c8de-eb31-5b1cafec1646@lear.ch>
Date: Fri, 16 Jul 2021 06:04:32 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fSGGOpKRZ49KrUBra4Lii9uBWg8K0Tbdr"
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jul 2021 10:04:55 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--fSGGOpKRZ49KrUBra4Lii9uBWg8K0Tbdr
Content-Type: multipart/mixed; boundary="lITL7n6JpOyLDbxPDemiI5C6oovczuEHL";
 protected-headers="v1"
From: Eliot Lear 
To: Mark Nottingham ,
 Brian E Carpenter 
Cc: rfced-future@iab.org
Message-ID: <5f70f69b-df99-c8de-eb31-5b1cafec1646@lear.ch>
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new
 streams?
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch>
 <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>
 
 <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>
 
 <82AA409C-402A-4110-941A-69D7FC4E7731@vigilsec.com>
 
 <83C4211C-1BB0-4C8F-ABC6-14253C067B74@mnot.net>
 <1cf2c540-95fc-0041-1e8c-63e72b873135@gmail.com>
 
In-Reply-To: 

--lITL7n6JpOyLDbxPDemiI5C6oovczuEHL
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi

On 16.07.21 02:52, Mark Nottingham wrote:
>
>> Consensus within the RSWG and/or approval by the RSAB are not sufficie=
nt to define a new stream; the requirements and process for doing so are =
out of scope in this document.

The second phrase seems fine. If we're not going to deal with it, let's=20
not deal with it.=C2=A0 But let's not stick a toe in the water and start =
to=20
deal with it and then not deal with it.

Eliot





--lITL7n6JpOyLDbxPDemiI5C6oovczuEHL--

--fSGGOpKRZ49KrUBra4Lii9uBWg8K0Tbdr
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDxWbAFAwAAAAAACgkQh7ZrRtnSejOf
pwf9Eu5/Rk53yn647aNY8vx6jj4CnxjuqWFalrA5upx6km0o5GHNqI2agHtQKeDbMHu8kau9b3ej
BRXFFFF4TjuqSaEY6Bze4w8QHkhwreeid1/Bj4Zfs+F1o+va4KHAq1XybtD8ZmBaKYYCmonv9hP7
OY8qtGynqwycM4y4xyy0qry6TUmrJUHp+KdPmzORIs4U6/ci5wHFTtvtEm6/qMxtaSw5Y8S4CBjy
wkaR0QwFWDOza/DkBE1eqDHHkXcFiVvfxp9RCWNLT3kwQEakuKs5RTe6uQC7I+FjB+FoN3N8wN59
eWW98v0bTp4kbpyoJAel5iMVl9mKW2elWarDndOOhQ==
=6YE1
-----END PGP SIGNATURE-----

--fSGGOpKRZ49KrUBra4Lii9uBWg8K0Tbdr--


From nobody Fri Jul 16 08:16:16 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C2A3A3A9D for ; Fri, 16 Jul 2021 08:16:15 -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 qBk4WXJJTSa6 for ; Fri, 16 Jul 2021 08:16:10 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 9284B3A3A9C for ; Fri, 16 Jul 2021 08:16:10 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id u7so10957321ion.3 for ; Fri, 16 Jul 2021 08:16:10 -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=OPexDgDqEespGQrSm01/1EHEZyJBrH1V8SCnTC3/7iU=; b=iFUUh/Jzl/naLZS2QqgP9e7uR0tYR+yGrvX+xiWo2gvSPoJbB3Guw49ujqCjv0gYvb n7+Scd/bGt4xbd0mVSLe7hRhO1QZHu/CdRHfT+XL65dt47/xk3LDqzkxS+aI/EVoTbW0 l1i8PZWL/Dm5h7URk1pMRQ5g1T42OlBHaDNrZI0ehd1qvxXFTJsX1JZczvFZwyB9YeON pyJAigfJ5gtMneGDbKGN8F06NEcHLSYscMtk2IbZU+iQWA/BU9/2tapZ3GeO45vIs4me 4arJymQuLnBWiG/KuZqZSE/BIW0QrsHGnCz4/DoI6OlNLGXt2/KvEuN0fxQNHtqJ0ktZ 6l6A==
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=OPexDgDqEespGQrSm01/1EHEZyJBrH1V8SCnTC3/7iU=; b=t4pu+6Z++UfSyCkSy26Fa0ALyBZeVFIOGVexGpTcunMk+HLxBrjItemOYj4dUlHsQD rmSKi1buDdfH91uVv76JpF080yrp+M24cwumzkZb6OmBrA2qJccsq4xIWpR+k9M+7AUN aW82iPtgriKVqCrY4t0ICvie/hZ9nRXfgikCcD9OeZevXCiFbiXb3v+DLnkhGwO5/lOj tXx9IRX8lw5g44UXwvdTCstEZPn9LGwsJiyywl/BbpUhZGOi0C7odk4CYnpvYCnQsQi5 nkRPIxVcyp1wvPtO7CggK7PQRfbWjBTIkheuAvA4/dEmAkskQr/znZWJYJqwqkBuJPKq OySA==
X-Gm-Message-State: AOAM530ObjvYmZEn2C8F5VKGMSR11rODZ0hA7XUKDZ4pRwEcxAypxRS3 JnVVOwIAQHBqDiiTPtMpxLp90mqs9dcBkbGsgDuCwQ==
X-Google-Smtp-Source: ABdhPJxHYqHtC03EhaPDaJpWI/V/Ire0PfsR+H+upSH/DepzFqkGPIko17x+7nHYVqBLpVahXasRiOTFzjBFHUeudJ4=
X-Received: by 2002:a05:6638:24c3:: with SMTP id y3mr9422441jat.10.1626448569206;  Fri, 16 Jul 2021 08:16:09 -0700 (PDT)
MIME-Version: 1.0
References: <6125a073-3779-d32d-0252-28833a957d34@lear.ch> <75F4A467-4C40-4A00-84C3-6F1F1940F180@mnot.net>  <1EC23130-D203-4A0E-9C60-1C30F9363711@vigilsec.com>  <82AA409C-402A-4110-941A-69D7FC4E7731@vigilsec.com>  <83C4211C-1BB0-4C8F-ABC6-14253C067B74@mnot.net> <1cf2c540-95fc-0041-1e8c-63e72b873135@gmail.com>  <5f70f69b-df99-c8de-eb31-5b1cafec1646@lear.ch>
In-Reply-To: <5f70f69b-df99-c8de-eb31-5b1cafec1646@lear.ch>
From: Eric Rescorla 
Date: Fri, 16 Jul 2021 08:15:32 -0700
Message-ID: 
To: Eliot Lear 
Cc: Mark Nottingham , Brian E Carpenter , rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000369bb005c73f1139"
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jul 2021 15:16:15 -0000

--000000000000369bb005c73f1139
Content-Type: text/plain; charset="UTF-8"

Just to be nitpicky, we agree there needs to be *some* path to create new
streams, right? Would the path be to write a document with that process in
RSWG, get consensus, have RSAB approve, and then actually run the process
for the new stream? Like this text doesn't foreclose the possibility
entirely?

-Ekr


On Fri, Jul 16, 2021 at 3:05 AM Eliot Lear  wrote:

> Hi
>
> On 16.07.21 02:52, Mark Nottingham wrote:
> >
> >> Consensus within the RSWG and/or approval by the RSAB are not
> sufficient to define a new stream; the requirements and process for doing
> so are out of scope in this document.
>
> The second phrase seems fine. If we're not going to deal with it, let's
> not deal with it.  But let's not stick a toe in the water and start to
> deal with it and then not deal with it.
>
> Eliot
>
>
>
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--000000000000369bb005c73f1139
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Just to be nitpicky, we agree there needs to be *some=
* path to create new streams, right? Would the path be to write a document =
with that process in RSWG, get consensus, have RSAB approve, and then actua=
lly run the process for the new stream? Like this text doesn't foreclos=
e the possibility entirely?

-Ekr

On Fri, Jul 16, 2021 at 3:05 AM Eliot Lear <lear@lear.ch> wrote:
Hi



On 16.07.21 02:52, Mark Nottingham wrote:

>

>> Consensus within the RSWG and/or approval by the RSAB are not suff=
icient to define a new stream; the requirements and process for doing so ar=
e out of scope in this document.



The second phrase seems fine. If we're not going to deal with it, let&#=
39;s 

not deal with it.=C2=A0 But let's not stick a toe in the water and star=
t to 

deal with it and then not deal with it.



Eliot









-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future




--000000000000369bb005c73f1139--


From nobody Fri Jul 16 09:14:49 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C2B3A0C37 for ; Fri, 16 Jul 2021 09:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level: 
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0d6o7j757wzv for ; Fri, 16 Jul 2021 09:14:39 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 911EE3A3C19 for ; Fri, 16 Jul 2021 09:14:39 -0700 (PDT)
Received: from smtpclient.apple (pool-70-21-183-161.nwrk.east.verizon.net [70.21.183.161]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16GGEX19260296 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 16 Jul 2021 18:14:34 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626452075; bh=VaGCB1S+nfkIcYBRY/z74CtW+JEYtI8b2f+H9W8canQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ixpfuZUm8ieXeogN4sb+56iZvo/FED4U22DhDfnIhLCAqRPbth6Qf9O8HeNTqiWfu nW/EqF4Pw8ebeWnBqRD7+OOQK7Yj1Zu5rQag0aNY1uA+bEtaMsbgWiPq4d5uAS0yFZ XHd5M5DFDFe8TSrESkfwBysvu8VVtVEbWsd5Vn8w=
Content-Type: multipart/alternative; boundary=Apple-Mail-C2A50E75-74C0-4499-A873-0174809F4749
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Eliot Lear 
In-Reply-To: 
Date: Fri, 16 Jul 2021 12:14:32 -0400
Cc: rfced-future@iab.org, Mark Nottingham 
Message-Id: 
References: 
To: Eric Rescorla 
X-Mailer: iPhone Mail (18F72)
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jul 2021 16:14:47 -0000

--Apple-Mail-C2A50E75-74C0-4499-A873-0174809F4749
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

As I see it there are three choices (and maybe others can provide more):

1. we deal with the matter here;
2. it gets dealt with as part of the 2850 update;
3. It gets dealt with when the need arises

I am ok with any of the three.  As a chair my bias is twofold: to not take o=
n more; but if we take on the work, to properly do the job.  My bias on the f=
irst is easily overcome if that=E2=80=99s what people want.

Eliot

> On Jul 16, 2021, at 11:16, Eric Rescorla  wrote:
>=20
> =EF=BB=BF
> Just to be nitpicky, we agree there needs to be *some* path to create new s=
treams, right? Would the path be to write a document with that process in RS=
WG, get consensus, have RSAB approve, and then actually run the process for t=
he new stream? Like this text doesn't foreclose the possibility entirely?
>=20
> -Ekr
>=20
>=20
>> On Fri, Jul 16, 2021 at 3:05 AM Eliot Lear  wrote:
>> Hi
>>=20
>> On 16.07.21 02:52, Mark Nottingham wrote:
>> >
>> >> Consensus within the RSWG and/or approval by the RSAB are not sufficie=
nt to define a new stream; the requirements and process for doing so are out=
 of scope in this document.
>>=20
>> The second phrase seems fine. If we're not going to deal with it, let's=20=

>> not deal with it.  But let's not stick a toe in the water and start to=20=

>> deal with it and then not deal with it.
>>=20
>> Eliot
>>=20
>>=20
>>=20
>>=20
>> --=20
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--Apple-Mail-C2A50E75-74C0-4499-A873-0174809F4749
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

As I see it there are three choices (and ma=
ybe others can provide more):

1. we deal with the matter h=
ere;
2. it gets dealt with as part of the 2850 update;
3=
. It gets dealt with when the need arises

I am ok w=
ith any of the three.  As a chair my bias is twofold: to not take on mo=
re; but if we take on the work, to properly do the job.  My bias on the=
 first is easily overcome if that=E2=80=99s what people want.

Eliot

On Jul 16, 2021, at 11:16, Eric Rescorla <ekr@rtfm.com> wrote:
=

=EF=BB=BF<=
div dir=3D"ltr">
Just to be nitpicky, we agree there needs to be *some* p=
ath to create new streams, right? Would the path be to write a document with=
 that process in RSWG, get consensus, have RSAB approve, and then actually r=
un the process for the new stream? Like this text doesn't foreclose the poss=
ibility entirely?

-Ekr


On Fri=
, Jul 16, 2021 at 3:05 AM Eliot Lear <lea=
r@lear.ch> wrote:
Hi



On 16.07.21 02:52, Mark Nottingham wrote:

>

>> Consensus within the RSWG and/or approval by the RSAB are not suffi=
cient to define a new stream; the requirements and process for doing so are o=
ut of scope in this document.



The second phrase seems fine. If we're not going to deal with it, let's 
=

not deal with it.  But let's not stick a toe in the water and start to <=
br>
deal with it and then not deal with it.



Eliot









-- 

Rfced-future mailing list

Rfced-future@iab.o=
rg

https://www.iab.org/mailman/listinfo/rfced-future=




-- 
Rfced-future mailing list
Rfced-fu=
ture@iab.org
https://www.iab.org/mailman/listinfo/rfced-futu=
re
=

--Apple-Mail-C2A50E75-74C0-4499-A873-0174809F4749--


From nobody Fri Jul 16 09:35:53 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A883A3CDA for ; Fri, 16 Jul 2021 09:35:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 h65EdYxEGMvz for ; Fri, 16 Jul 2021 09:35:44 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17EA3A3CCA for ; Fri, 16 Jul 2021 09:35:44 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id s5so1807305ild.5 for ; Fri, 16 Jul 2021 09:35:44 -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=pUaRLgE1IgwWGmIyFnfOqG+YaDC2j+YtTqMB9Y4FDB4=; b=tjCHRTQMwwO0Fj59C0o1Z4yc8ne4f8i4xHUqXTxjv07F45nq2jEPk/z40SsT8T7qo1 jKPkP+bAKqey+cb2dZMOgRI9fjPuadI7rwJu8FeNSserLsA5WajsnLoDAwv8B8XMoKuX nhOfJ1AHacVBcpfA/2l3vrzL+QXHxctBBHDfKIShawMw1QXxk3SvRUIOaba2MxstZxQ2 QF05+TZDYTTD5otId2gOcZNY5+pjETzpAld5Azy2E+XzFVXiJPEiFu62NsFKbYpOiW5O +g6F7EwVe7xmegjEzbbHJDF9eFUa9meWySZiglBxqLyHEwk6f6rQud2u7jB2dBQb85W1 330Q==
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=pUaRLgE1IgwWGmIyFnfOqG+YaDC2j+YtTqMB9Y4FDB4=; b=JYf/pBcF5kKiCqLByZJTl251ZlKTz+mMd4XiNIb7TQtJvFYI6X2aKXAcKFMHB6lPRS t99ShAP2e6m2JJtwiiOKOTOfNg0pSuiZLOznldlXHyh+fz9pmQtpom6urVQ6nBN416Ff wYvaNRL9I5dcv7Ms5uJ4JK6nIButZDw5XUiMUhKsamTNl5NuMxmS5xDpHdBZT72sWjt4 WBMCzeeCP5GtivpfiQu+e50qV829pDmcGr20GgwvoJ729W0PjdSQIkNNr+fTova7FKDH XNZD9bhKum3LcGLsCSfqL1FOIQVWfWhyiO2i7mBggSZdYL+V2ygjeFMXYmYzveXb5Thr B+mQ==
X-Gm-Message-State: AOAM530BefnVwP+YRsB59SqcvzBNfp+BouVSe/erxSHBBHIkbGqtYsHM y8gR+jWlO5TH611joVTwO0NBcTNBmxfWYDpfzzULxw==
X-Google-Smtp-Source: ABdhPJwgxYYWlh5zrrRAyrCWNbvxwQm+LgJET/xHJ28kV/8j1U3lwyUEi3j4+dD7ZXg4F7+jwMvW2DmRk+6PoUEOSGc=
X-Received: by 2002:a05:6e02:1aae:: with SMTP id l14mr7257653ilv.35.1626453343632;  Fri, 16 Jul 2021 09:35:43 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Eric Rescorla 
Date: Fri, 16 Jul 2021 09:35:07 -0700
Message-ID: 
To: Eliot Lear 
Cc: rfced-future@iab.org, Mark Nottingham 
Content-Type: multipart/alternative; boundary="000000000000ca9f0805c7402d61"
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jul 2021 16:35:51 -0000

--000000000000ca9f0805c7402d61
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 16, 2021 at 9:14 AM Eliot Lear  wrote:

> As I see it there are three choices (and maybe others can provide more):
>
> 1. we deal with the matter here;
> 2. it gets dealt with as part of the 2850 update;
> 3. It gets dealt with when the need arises
>
> I am ok with any of the three.  As a chair my bias is twofold: to not tak=
e
> on more; but if we take on the work, to properly do the job.  My bias on
> the first is easily overcome if that=E2=80=99s what people want.
>

I don't have a strong opinion. I'm just trying to avoid something that
effectively says "There is no way to create new streams ever" and then in
five years wanting to and having it be like "actually, these documents
totally preclude that and there's no way to update them"

-Ekr


> Eliot
>
> On Jul 16, 2021, at 11:16, Eric Rescorla  wrote:
>
> =EF=BB=BF
> Just to be nitpicky, we agree there needs to be *some* path to create new
> streams, right? Would the path be to write a document with that process i=
n
> RSWG, get consensus, have RSAB approve, and then actually run the process
> for the new stream? Like this text doesn't foreclose the possibility
> entirely?
>
> -Ekr
>
>
> On Fri, Jul 16, 2021 at 3:05 AM Eliot Lear  wrote:
>
>> Hi
>>
>> On 16.07.21 02:52, Mark Nottingham wrote:
>> >
>> >> Consensus within the RSWG and/or approval by the RSAB are not
>> sufficient to define a new stream; the requirements and process for doin=
g
>> so are out of scope in this document.
>>
>> The second phrase seems fine. If we're not going to deal with it, let's
>> not deal with it.  But let's not stick a toe in the water and start to
>> deal with it and then not deal with it.
>>
>> Eliot
>>
>>
>>
>>
>> --
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>
>

--000000000000ca9f0805c7402d61
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Jul 16, 2021 at 9:14 AM Eliot=
 Lear <lear@lear.ch> wrote:
As =
I see it there are three choices (and maybe others can provide more):
<=
br>
1. we deal with the matter here;
2. it gets dealt w=
ith as part of the 2850 update;
3. It gets dealt with when the ne=
ed arises

I am ok with any of the three.=C2=A0 As =
a chair my bias is twofold: to not take on more; but if we take on the work=
, to properly do the job.=C2=A0 My bias on the first is easily overcome if =
that=E2=80=99s what people want.

I don't have a strong opinion. I'm just trying to avoid something=
 that effectively says "There is no way to create new streams ever&quo=
t; and then in five years wanting to and having it be like "actually, =
these documents totally preclude that and there's no way to update them=
"

-Ekr


Eliot

On Jul 1=
6, 2021, at 11:16, Eric Rescorla <ekr@rtfm.com> wrote:

=EF=BB=BF
Just to be=
 nitpicky, we agree there needs to be *some* path to create new streams, ri=
ght? Would the path be to write a document with that process in RSWG, get c=
onsensus, have RSAB approve, and then actually run the process for the new =
stream? Like this text doesn't foreclose the possibility entirely?
<=
/div>

-Ekr


On Fri, Jul 16, 2021 at 3=
:05 AM Eliot Lear <lea=
r@lear.ch> wrote:
Hi



On 16.07.21 02:52, Mark Nottingham wrote:

>

>> Consensus within the RSWG and/or approval by the RSAB are not suff=
icient to define a new stream; the requirements and process for doing so ar=
e out of scope in this document.



The second phrase seems fine. If we're not going to deal with it, let&#=
39;s 

not deal with it.=C2=A0 But let's not stick a toe in the water and star=
t to 

deal with it and then not deal with it.



Eliot









-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future



-- 
Rfced-future mailing list
Rfced-future@iab.org=

https://www.iab.org/mailman/listinfo/rfced-future=



--000000000000ca9f0805c7402d61--


From nobody Fri Jul 16 14:13:05 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E273A0A27 for ; Fri, 16 Jul 2021 14:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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 tsoFmvUAoFTt for ; Fri, 16 Jul 2021 14:12:57 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 A05C93A0A24 for ; Fri, 16 Jul 2021 14:12:57 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id 70so7821978pgh.2 for ; Fri, 16 Jul 2021 14:12:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UeFPp57jDgIFi6+/8FasEZIOVOvhsfd2a1HFZwl28EE=; b=IBTJijKXGTci2hoyTxZIMHdLvW+YY1TYAAXnpTJr5x9AAVBY9kXvEs3k7SWbBy0HVa foiD5D2Uy5mEGWzlBH07w5WypK5T8smPXL2GP/PgnZDjLzkMFG7QpTUXxuIPKmjmuUWN U5W7Cfeap4fXdicfEcDm5ryzTH24jFmoMNBl9+LDUpqLl4g0YP17d1CcOR+iqSzFhhpK eEPbqysnl9qC5pMdzsmnfH6iycI/RSF4ujtDj4BWowKopFAxOxJYe4Vb7MP9CWEnhz1q /JAFFuavO5avCX33kIRRd3QaNnvAFPIE1o29CYuGmTU6Rj1iR7ZbQuUugSuq/ghsFXla wWGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UeFPp57jDgIFi6+/8FasEZIOVOvhsfd2a1HFZwl28EE=; b=Uzwr0vY79XXifvbS8j+iY4uKwDvcv5O1QseHW+1HYkRaPF3loCgglDK73Bx5WMYsCW uI91WIoOp86u1M+zGa47TOmplC+vOpFoSGdDDJ/94TwWg0hAxawHmID1WVN0nIhZyfdu ZV4hOKfrDWs7K7E8u2eB4cNWeWky8JNARQwUYDhjuUsjELJCTRu8qq0qSSKDr7TLuDzM /gTJgrxTcYHjhwhZIvd/qNYFaTOdgC1S9giOWcBAtHB/nh4QASEkW5rY6l219KWHA8+W ScE4AxS3ZEgnMu1Yoyn/738sP/g/vEFbmWi42K612qY/qiz3k51Moj0DmxELXpNIQdI/ EN4A==
X-Gm-Message-State: AOAM532wpnnKLATEEuK5WKAe6Rua7gU/4SZZul5fodJ3u2Hxwn25DX0m A2mgqWfg498/X4daxYWGz8E=
X-Google-Smtp-Source: ABdhPJzg0AsU+02iL/mDASdY6hjOmJRULAfWAL/t3cu219B27Snnz0l4iK9AbTSFHUD0iJH4G6mLYw==
X-Received: by 2002:a62:e90f:0:b029:307:8154:9ff7 with SMTP id j15-20020a62e90f0000b029030781549ff7mr12296191pfh.79.1626469975880;  Fri, 16 Jul 2021 14:12:55 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id 10sm10539846pjc.41.2021.07.16.14.12.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Jul 2021 14:12:55 -0700 (PDT)
To: Eliot Lear , Eric Rescorla 
Cc: rfced-future@iab.org, Mark Nottingham 
References:  
From: Brian E Carpenter 
Message-ID: <36572803-573e-c6d5-d9a1-7120479cd741@gmail.com>
Date: Sat, 17 Jul 2021 09:12:51 +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: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Jul 2021 21:13:03 -0000

On balance, I think this would develop into an enormous and very tempting=20
rathole if we attempted to solve it now, so I'd prefer to simply declare =
it out of scope and move on.

"The requirements and process for creating any additional RFC streams are=20
out of scope in this document."

Regards
   Brian

On 17-Jul-21 04:14, Eliot Lear wrote:
> As I see it there are three choices (and maybe others can provide more)=
:
>=20
> 1. we deal with the matter here;
> 2. it gets dealt with as part of the 2850 update;
> 3. It gets dealt with when the need arises
>=20
> I am ok with any of the three. =C2=A0As a chair my bias is twofold: to =
not take on more; but if we take on the work, to properly do the job. =C2=
=A0My bias on the first is easily overcome if that=E2=80=99s what people =
want.
>=20
> Eliot
>=20
>> On Jul 16, 2021, at 11:16, Eric Rescorla  wrote:
>>
>> =EF=BB=BF
>> Just to be nitpicky, we agree there needs to be *some* path to create =
new streams, right? Would the path be to write a document with that proce=
ss in RSWG, get consensus, have RSAB approve, and then actually run the p=
rocess for the new stream? Like this text doesn't foreclose the possibili=
ty entirely?
>>
>> -Ekr
>>
>>
>> On Fri, Jul 16, 2021 at 3:05 AM Eliot Lear > wrote:
>>
>>     Hi
>>
>>     On 16.07.21 02:52, Mark Nottingham wrote:
>>     >
>>     >> Consensus within the RSWG and/or approval by the RSAB are not s=
ufficient to define a new stream; the requirements and process for doing =
so are out of scope in this document.
>>
>>     The second phrase seems fine. If we're not going to deal with it, =
let's
>>     not deal with it.=C2=A0 But let's not stick a toe in the water and=20
start to
>>     deal with it and then not deal with it.
>>
>>     Eliot
>>
>>
>>
>>
>>     --=20
>>     Rfced-future mailing list
>>     Rfced-future@iab.org 
>>     https://www.iab.org/mailman/listinfo/rfced-future 
>>
>> --=20
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>=20


From nobody Fri Jul 16 17:43:59 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7453A1186 for ; Fri, 16 Jul 2021 17:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=qvmB3WGI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Xdxc3ZYg
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsmJL0ZiFZkz for ; Fri, 16 Jul 2021 17:43:53 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E3E3A1184 for ; Fri, 16 Jul 2021 17:43:53 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id DDF9A5C010B; Fri, 16 Jul 2021 20:43:52 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 16 Jul 2021 20:43:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=R W9aUN/k9BRv3PQWTf6LRmqbBIY19s8kTgszpluB5hY=; b=qvmB3WGIoTz7E5xII D7YhuqEqwtUqgnzxTbQgCjqV/L1+8Cg3RFbPI7o9kxhFcIGpd0XawaPrAIW7iT85 rqbJkE7W4era0uuPTTHRCxPW2vJBm8/sk30llEtWnMfKY4+H3nfXnDZO0adK+2oo x5QGFi/dW97LYkmUR05645MT1XCfBggP6IZZIvc7NW4JXsUUZMibPIHzxw0JSYnL R+zzl67gxHeYE1sSY5LgnNonntLZQ9d33BySbNMsNvHISaJpSjxuUbT031Wgz80d vslp6XxJqO+W1p5/tucjvh+qeVDKS63kAtcDvvs4s1Slaa9RG7z67HFhoOkURRd5 pprvw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=RW9aUN/k9BRv3PQWTf6LRmqbBIY19s8kTgszpluB5 hY=; b=Xdxc3ZYgKvZCwq2iKZG2gje8ZyuB7KBYmtRqosTGH4BVqGM7kI/certCq O34Uav6i+RRXMQGQCHZJqG8QcIKMcMUZiRdm8Y8ZDw1R7YM7DIQwyQCJGAV0wq1u KaKpi145IC9C9VjOY7/nRe05l99v2tF5T0wJ5x6FBHs3G6L2NjggZWQgB8B0cqIC wcW21vqarbKDVlyZnSuwEaMMqwfeFs8tE8cA2uD7b1PnJHBKcU+v901SImzXk8Qf i3yi+VMDFCb4PgOQE+NQcKSlWeMW1kIrLarScSep+LdAcwExB+nxdPRvCQbxa9Nv Sv5pzl+Yob9BhBiMJI/EDECNDcxIA==
X-ME-Sender:  
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdeggddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepteeghfevjeefvdffjeeuieeuvdevvddvudejfedthffhvefhvdfhgfduieelffev necuffhomhgrihhnpehirggsrdhorhhgpdhmnhhothdrnhgvthenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 16 Jul 2021 20:43:49 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Nottingham 
In-Reply-To: <36572803-573e-c6d5-d9a1-7120479cd741@gmail.com>
Date: Sat, 17 Jul 2021 10:43:48 +1000
Cc: Eliot Lear , Eric Rescorla , rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <36572803-573e-c6d5-d9a1-7120479cd741@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Jul 2021 00:43:58 -0000

WFM

> On 17 Jul 2021, at 7:12 am, Brian E Carpenter =
 wrote:
>=20
> On balance, I think this would develop into an enormous and very =
tempting=20
> rathole if we attempted to solve it now, so I'd prefer to simply =
declare it out of scope and move on.
>=20
> "The requirements and process for creating any additional RFC streams =
are=20
> out of scope in this document."
>=20
> Regards
>   Brian
>=20
> On 17-Jul-21 04:14, Eliot Lear wrote:
>> As I see it there are three choices (and maybe others can provide =
more):
>>=20
>> 1. we deal with the matter here;
>> 2. it gets dealt with as part of the 2850 update;
>> 3. It gets dealt with when the need arises
>>=20
>> I am ok with any of the three.  As a chair my bias is twofold: to not =
take on more; but if we take on the work, to properly do the job.  My =
bias on the first is easily overcome if that=E2=80=99s what people want.
>>=20
>> Eliot
>>=20
>>> On Jul 16, 2021, at 11:16, Eric Rescorla  wrote:
>>>=20
>>> =EF=BB=BF
>>> Just to be nitpicky, we agree there needs to be *some* path to =
create new streams, right? Would the path be to write a document with =
that process in RSWG, get consensus, have RSAB approve, and then =
actually run the process for the new stream? Like this text doesn't =
foreclose the possibility entirely?
>>>=20
>>> -Ekr
>>>=20
>>>=20
>>> On Fri, Jul 16, 2021 at 3:05 AM Eliot Lear > wrote:
>>>=20
>>>    Hi
>>>=20
>>>    On 16.07.21 02:52, Mark Nottingham wrote:
>>>>=20
>>>>> Consensus within the RSWG and/or approval by the RSAB are not =
sufficient to define a new stream; the requirements and process for =
doing so are out of scope in this document.
>>>=20
>>>    The second phrase seems fine. If we're not going to deal with it, =
let's
>>>    not deal with it.  But let's not stick a toe in the water and=20
> start to
>>>    deal with it and then not deal with it.
>>>=20
>>>    Eliot
>>>=20
>>>=20
>>>=20
>>>=20
>>>    --=20
>>>    Rfced-future mailing list
>>>    Rfced-future@iab.org 
>>>    https://www.iab.org/mailman/listinfo/rfced-future =

>>>=20
>>> --=20
>>> Rfced-future mailing list
>>> Rfced-future@iab.org
>>> https://www.iab.org/mailman/listinfo/rfced-future
>>=20
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--
Mark Nottingham   https://www.mnot.net/


From nobody Sun Jul 18 14:04:33 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4EF3A0BFF for ; Sun, 18 Jul 2021 14:04:31 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ3CJ1wEijFP; Sun, 18 Jul 2021 14:04:26 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 8E5EA3A0BFE; Sun, 18 Jul 2021 14:04:25 -0700 (PDT)
From: Jay Daley 
Message-Id: <47FC948A-F5AE-4333-BA86-1CCF294CBB52@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A2120510-05D5-4748-894D-89435E8D0955"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Mon, 19 Jul 2021 09:04:21 +1200
In-Reply-To: <4b1a5bc7-a808-c122-5f7b-ca3c66d0ace0@nostrum.com>
Cc: Eliot Lear , Martin Thomson , rfced-future@iab.org
To: Adam Roach 
References:   <261f45c0-2b0c-5fa3-ab8d-cbdf1af8c01d@nostrum.com> <93E048D4-9F05-4AB3-A16F-FC24240B5E29@kuehlewind.net> <45F31C4D-6040-4354-B3C8-DCFC898074DC@brianrosen.net>    <6f0f7f6a-08fa-4c63-aba3-1e03baf95dd0@www.fastmail.com>  <4b1a5bc7-a808-c122-5f7b-ca3c66d0ace0@nostrum.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Issue 24: What is the name of the role?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Jul 2021 21:04:31 -0000

--Apple-Mail=_A2120510-05D5-4748-894D-89435E8D0955
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On 14/07/2021, at 5:59 PM, Adam Roach  wrote:
>=20
> On 7/14/2021 12:44 AM, Eliot Lear wrote:
>> Martin
>>=20
>> On 14.07.21 02:34, Martin Thomson wrote:
>>> This strongly motivates a name change for me.  I do somewhat like =
"consulting editor", but I don't want to be forced to pick a name at the =
same time as deciding that a name change is appropriate.  That sort of =
conflation of concerns can be a cynical political ploy employed by those =
who seek to protect status quo[*].
>>=20
>> We are long past the point where the status quo has been preserved, =
so let's not worry about that.=20
>=20
>=20
> I think Martin's diplomacy may have masked the point a bit, which =
makes it easy to miss (as you appear to have done).
>=20
> I'll try to expand on the concern a bit more bluntly. There's been a =
long conversation in this group about whether this role under discussion =
is an executive role or a consultative one, and there's a pretty clear =
consensus that appears to have emerged from that conversation. The =
*appearance* is that the folks who were in the rough on that point are =
attempting to relitigate it by arguing to retain a title that has, for =
the past 12 years or so, been clearly associated with an executive role.

The title proposed by Brian "RFC Series Consulting Editor" seems to =
capture both the senior expertise of this role and the advisory nature - =
in other words, adding "consulting" to the previous title shows that we =
want someone at that level but in an advisory role.

Jay

>=20
> Whether this is *actually* the motivation is unclear, and I am (like =
Martin) giving folks the benefit of the doubt that it's not, but that's =
Martin's point as I understand it.
>=20
> /a
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--=20
Jay Daley
IETF Executive Director
jay@ietf.org


--Apple-Mail=_A2120510-05D5-4748-894D-89435E8D0955
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On =
14/07/2021, at 5:59 PM, Adam Roach <adam@nostrum.com> wrote:

On =
7/14/2021 12:44 AM, Eliot Lear wrote:
Martin

On 14.07.21 =
02:34, Martin Thomson wrote:
This strongly motivates a name change for me.  I do =
somewhat like "consulting editor", but I don't want to be forced to pick =
a name at the same time as deciding that a name change is =
appropriate.  That sort of conflation of concerns can be a cynical =
political ploy employed by those who seek to protect status quo[*].

We are long past the point where =
the status quo has been preserved, so let's not worry about that. 


I think Martin's =
diplomacy may have masked the point a bit, which makes it easy to miss =
(as you appear to have done).

I'll try to =
expand on the concern a bit more bluntly. There's been a long =
conversation in this group about whether this role under discussion is =
an executive role or a consultative one, and there's a pretty clear =
consensus that appears to have emerged from that conversation. The =
*appearance* is that the folks who were in the rough on that point are =
attempting to relitigate it by arguing to retain a title that has, for =
the past 12 years or so, been clearly associated with an executive =
role.

The title proposed by Brian "RFC Series Consulting =
Editor" seems to capture both the senior expertise of this role and the =
advisory nature - in other words, adding "consulting" to the previous =
title shows that we want someone at that level but in an advisory =
role.

Jay


Whether this is *actually* the motivation is =
unclear, and I am (like Martin) giving folks the benefit of the doubt =
that it's not, but that's Martin's point as I understand it.

/a

-- 
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future



-- 
Jay Daley
IETF =
Executive Director
jay@ietf.org




=

--Apple-Mail=_A2120510-05D5-4748-894D-89435E8D0955--


From nobody Tue Jul 20 07:00:09 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E2A3A23D6 for ; Tue, 20 Jul 2021 07:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGSypiDEDfKV for ; Tue, 20 Jul 2021 07:00:02 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 0DEAA3A23D4 for ; Tue, 20 Jul 2021 07:00:01 -0700 (PDT)
Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 514E9600045 for ; Tue, 20 Jul 2021 16:59:51 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626789591; bh=rzjqoBSby0+p36XcmUmHNLUWWJXhSGAm5cT6Fj/EYjk=; h=From:Subject:Date:To; b=tEwUOLtZwSmu/184Up0jPQFKH7LqV+GeMMKeGvxreFDrT+w6gGXFl7sP1CKDrF6Jf 52qDLw3dodjmjFuFGkrOD4DcR1mc5rntO8DQ7yIG6IPipep4YQX/lMNwsO7XJEWteP ma+VKrlTjNSZtjjHsPwTGUv1g+6w58Zn2BgaqaK4=
From: Lars Eggert 
Content-Type: multipart/signed; boundary="Apple-Mail=_10395960-F7C6-4989-8263-5151432F2166"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Message-Id: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org>
Date: Tue, 20 Jul 2021 16:59:50 +0300
To: rfced-future@iab.org
X-MailScanner-ID: 514E9600045.A0EAC
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: 
Subject: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jul 2021 14:00:08 -0000

--Apple-Mail=_10395960-F7C6-4989-8263-5151432F2166
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

RFC8728 says in Section 2:

   The RFC Series Editor will exercise
   strategic leadership and management over the activities of the RFC
   Publisher and the RFC Production Center (both of which can be seen as
   back-office functions) and will be the entity that:
   (...)
   *  Is responsible for the content of the rfc-editor.org web site,
      which is operated and maintained by the RFC Publisher.

In other words, the content of the site is currently owned by the RSE, =
and the website operation and maintenance by the RPC (which is AMS, =
which also operates and maintains the IETF's other web presences.) The =
text above also lacks some clarity, for example, about who is =
responsible for the presentation/look&feel of the site (which has been =
the RSE IIRC).

I'm not aware that there has been a discussion in the program about how =
where these responsibilities would land in the future. (Apologies if I =
missed something.)

Given the changes to the role of what used to be the RSE, I think it =
makes sense to re-home the responsibilities for the high-level content =
of the site elsewhere. Personally, I think the RSAB would be a better =
home than the RSWG, but I could be convinced otherwise.

I think the operation and maintenance of the site should NOT remain with =
the RPC. It's a skillset that is completely separated from the rest of =
their function. Leaving it with the RPC would also fracture our we =
presence, if the RPC function at some future time would not be at AMS =
anymore. My suggestion would be to leave that responsibility with the =
LLC, which would likely contract it out together with operation and =
maintenance of our other web properties.

Thoughts?

Thanks,
Lars

--Apple-Mail=_10395960-F7C6-4989-8263-5151432F2166
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-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmD21tYACgkQVLXDCb9w
wVesew/7Bk3OeZ7CmMy2NAyszFO4bMa/hMLCGBHvKBiwIM4TJk3TpW4GJQYxTHdk
T7l8r093R8nQIrTBJcSrCnuzQcF3L29C9FKyt96qkBQtcKsZ2VAOo6TUMSf+ck3a
iAy12o5uMDxsVmrduAzai8YXuXqvFKvyzjjm9FRgGjpC0ryL6d9yIB9sTALorr9H
XG5jdAMvsiwT63A6h7BU/IUzISPVDZppIzPrfeQRmymCXPtM54EEqYCQkhuTCF/h
Z4giKjpuGe9WLrWXjus6BAwBAGUD520nl8bAQeFJjO1kzLMSiTjZ0JAhdLiaW0ab
GVjDQc1eIAbCp6i0ja650/Q2OiAM6qAldhCp49GpC/M90J3vJfZXg7ckPNLMhcQE
FE7WEjLKyNfUJJ79A2nRFHp/TTfx9NZz6fhUX9xRkwUt96owd04SMmQ/ag9o4+hJ
3C6PCkOx+1vye1Hb2xnZk7jjKjsLGXIAjfJjqIjeJtJNz4Vn8uOBgdeJoDSoCpvG
hwu/7HVdb1rsbDt3Qy+MaaobgCGZ4kQaPChw2z9NUdW0BPIlI6sJXMCzrt2wNs1H
fvbZ46HulBc3zaamXMTeWL5wAHzKUzwBEbns1bfbtDaILPqa8Udo/FdXbp59jn/J
tztxNMXc/AmbEwNj0LyR9DLgtZ93kmcQcgF1OVoryJIvj/ZqunY=
=WI2O
-----END PGP SIGNATURE-----

--Apple-Mail=_10395960-F7C6-4989-8263-5151432F2166--


From nobody Tue Jul 20 07:11:09 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E2E3A242F for ; Tue, 20 Jul 2021 07:11:07 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo_Eh6Tn-6kY for ; Tue, 20 Jul 2021 07:11:02 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248C43A2436 for ; Tue, 20 Jul 2021 07:11:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7B426300B96 for ; Tue, 20 Jul 2021 10:11:00 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 93L2G8yw50lH for ; Tue, 20 Jul 2021 10:10:58 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 990543005D7; Tue, 20 Jul 2021 10:10:58 -0400 (EDT)
From: Russ Housley 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_CF00214C-636A-4DBC-89ED-4B88A5C9F016"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Tue, 20 Jul 2021 10:10:57 -0400
In-Reply-To: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org>
Cc: rfced-future@iab.org
To: Lars Eggert 
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jul 2021 14:11:07 -0000

--Apple-Mail=_CF00214C-636A-4DBC-89ED-4B88A5C9F016
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Lars:

About a decade ago, I asked why the IETF was paying two different =
vendors to operate and maintain websites.  At the time the RFC Editor =
independently operated and maintained rfc-editor.org and the Secretariat =
operated and maintained the rest of the web sites.  Now, AMS operates =
and maintains all of the web sites, and I think that having one party do =
that is a good thing.  This has nothing to do with the look and feel of =
the sites.  For example, iab.org and ietf.org have very different look =
and feel, but they are operated and maintained by the same party.

Russ

> On Jul 20, 2021, at 9:59 AM, Lars Eggert  wrote:
>=20
> Signed PGP part
> Hi,
>=20
> RFC8728 says in Section 2:
>=20
>   The RFC Series Editor will exercise
>   strategic leadership and management over the activities of the RFC
>   Publisher and the RFC Production Center (both of which can be seen =
as
>   back-office functions) and will be the entity that:
>   (...)
>   *  Is responsible for the content of the rfc-editor.org web site,
>      which is operated and maintained by the RFC Publisher.
>=20
> In other words, the content of the site is currently owned by the RSE, =
and the website operation and maintenance by the RPC (which is AMS, =
which also operates and maintains the IETF's other web presences.) The =
text above also lacks some clarity, for example, about who is =
responsible for the presentation/look&feel of the site (which has been =
the RSE IIRC).
>=20
> I'm not aware that there has been a discussion in the program about =
how where these responsibilities would land in the future. (Apologies if =
I missed something.)
>=20
> Given the changes to the role of what used to be the RSE, I think it =
makes sense to re-home the responsibilities for the high-level content =
of the site elsewhere. Personally, I think the RSAB would be a better =
home than the RSWG, but I could be convinced otherwise.
>=20
> I think the operation and maintenance of the site should NOT remain =
with the RPC. It's a skillset that is completely separated from the rest =
of their function. Leaving it with the RPC would also fracture our we =
presence, if the RPC function at some future time would not be at AMS =
anymore. My suggestion would be to leave that responsibility with the =
LLC, which would likely contract it out together with operation and =
maintenance of our other web properties.
>=20
> Thoughts?
>=20
> Thanks,
> Lars
>=20
>=20


--Apple-Mail=_CF00214C-636A-4DBC-89ED-4B88A5C9F016
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEE3ZgmxD9TboJgMKMUcGKjIhkfjnwFAmD22XEACgkQcGKjIhkf
jnydIw/+KHPFFDNVR9aF1k1zH45K6VhmVhqQgRzQlVXhy5d3J3xtEkvBA7Nmey9p
x2ODEt7jKnLucLqAiBiLqHEin5rh9wW9z3785YiZr2OmzwVKieqI8D8LAi19ZQMC
4O+yN032DS9LaKRpTJ/c7yJfalbAEXbzGJdPvpgtH6DJd2/V8b/JTTGHP8yHi5sJ
VxNvkmnQ5+yY3OPawLmRRvUUfIRi6sb3sW4FB9XeWxVpirtP+l/EUpCyyL+2g0gX
olJkZYcp1t1c2rnY9YiOJqbtZzfMdCS6W5PspQHscz3tSFdK00p4vwDc9aTmF38S
qaZ9yuQYi9FnrV+JgCk4zTADMVAo6ahdBhF6skJySbFTG5AZqtSDvxvtNeL6V0sH
HkCVkFNgU5nFqUGpePt/FEZttc4dwCQXnlTrWkXpoRrXnOwbpsiHgTPiDkk0Pubp
ZAY5wOyiZ+eSDLMryg7nPyCoqHzIqWsDUdg+vHJR/t0Xe6IbRSz5avNQQA7qTMG8
aILXe2ZWL/MDPZ1fk0tQtkTt0cxsaC75LW8b87TqJ7XoM3+k+rkimcOhymLzLUT4
65wAoR2DDsVYLU7h0bfehQ70cr981OAGBcf9MItaXLbmEQYSD12cTursXpwwD7+8
g1rIXeUhaY76oXwVQK4UbRyQa+cqNPS4faE1UaLuqjmHxoaQ/SA=
=dR64
-----END PGP SIGNATURE-----

--Apple-Mail=_CF00214C-636A-4DBC-89ED-4B88A5C9F016--


From nobody Tue Jul 20 11:01:17 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169553A2CAF for ; Tue, 20 Jul 2021 11:01:15 -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 f-4zoqi8b2sc for ; Tue, 20 Jul 2021 11:01:09 -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 87DE13A2CB4 for ; Tue, 20 Jul 2021 11:01:09 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id k11so24988375ioa.5 for ; Tue, 20 Jul 2021 11:01:09 -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=tu1VoyvtG0PfC5Ke51kBolVQOawbRGr9NKG4Lj9VFWU=; b=M33SaLaIUpUYlBXbQ2R4nlsGivB99RLTgc38/7pZwqkCZD2grYhMs6Yln2FuobUczQ +RxKKF+xcmv5rGCDBUWYDJY2GxpctqYDfUVkTJ93iOShOt4UXHXADzGiqkdzKLHpVx7/ lxecAbjdjIUChEzfzIRq3hubZcsAhYJ4kSlwAzttTfCcZHE7ptxOXUuzRI8umMr5iaJL rCU8zwqOzAF4JEPiqXKVKw4Aug1BfkGD8wy9cTCaNpcym61WEDPdbMVMFfpPVtzXHTX7 5/psQcaaLaOT0sr5nkipJgkQQdUfhjv50rxapPFXCKNTy8Rw5Qvw8dz5XvmHxGckx63I Dl4g==
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=tu1VoyvtG0PfC5Ke51kBolVQOawbRGr9NKG4Lj9VFWU=; b=Q6Zajzk/ZtQEcqPksTwr4g34eZZCfcYK/6j5G07GNYCsA831MHDbSGbitd+g/Cx70g dBuhwH+RfcuLTOsgXBhLuIBH4TzdfAVQe/Z3bPHYpoAzU9dcdc+Lss2dbDMCFf4lAjrV w/Eo9+y5OJOrAHgieXwcDNFxXbFtM2COlL7GggFRKDF4W02iIrGyOAG9OyG0zoWKUP3K kBEeVTqBIPBhi2yZPgyVe9KDHQnubJVwGIOB/ZRGUFMqF9uBNJKVkgfQSy13pjKGO3IB BC1jF7L8HL+zRzBCGIkEiSvAQL+bEtLRu4m/5w5p4gbXefFz9KmFbk72XbqAUiymUcHj FPdA==
X-Gm-Message-State: AOAM533Cvy10AoniicbeZCrFdhzIcAraFdDvXw1T9pPD6DiW+tDJNlmt tXwh2dLunpNb2tVUHc8KMIDoNKEHTC+UQ2buqa7aqA==
X-Google-Smtp-Source: ABdhPJyyHrH8ifJZNq7lBP03C0sHHFXG6pd/1eAQt3w5fsnDhDtnR2XpqAN3Id9KRKyMvWORp56jzi4ZBCiGX8d8LLw=
X-Received: by 2002:a05:6638:39c2:: with SMTP id o2mr26990487jav.87.1626804068477;  Tue, 20 Jul 2021 11:01:08 -0700 (PDT)
MIME-Version: 1.0
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org>
In-Reply-To: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org>
From: Eric Rescorla 
Date: Tue, 20 Jul 2021 11:00:32 -0700
Message-ID: 
To: Lars Eggert 
Cc: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000009f068c05c791d61e"
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jul 2021 18:01:16 -0000

--0000000000009f068c05c791d61e
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 20, 2021 at 7:00 AM Lars Eggert  wrote:

> Hi,
>
> RFC8728 says in Section 2:
>
>    The RFC Series Editor will exercise
>    strategic leadership and management over the activities of the RFC
>    Publisher and the RFC Production Center (both of which can be seen as
>    back-office functions) and will be the entity that:
>    (...)
>    *  Is responsible for the content of the rfc-editor.org web site,
>       which is operated and maintained by the RFC Publisher.
>
> In other words, the content of the site is currently owned by the RSE, and
> the website operation and maintenance by the RPC (which is AMS, which also
> operates and maintains the IETF's other web presences.) The text above also
> lacks some clarity, for example, about who is responsible for the
> presentation/look&feel of the site (which has been the RSE IIRC).
>
> I'm not aware that there has been a discussion in the program about how
> where these responsibilities would land in the future. (Apologies if I
> missed something.)
>
> Given the changes to the role of what used to be the RSE, I think it makes
> sense to re-home the responsibilities for the high-level content of the
> site elsewhere. Personally, I think the RSAB would be a better home than
> the RSWG, but I could be convinced otherwise.
>

Yeah, this is probably right. I would hope that the RSWG would delegate
almost all of that to whoever operates it.

-Ekr



> I think the operation and maintenance of the site should NOT remain with
> the RPC. It's a skillset that is completely separated from the rest of
> their function. Leaving it with the RPC would also fracture our we
> presence, if the RPC function at some future time would not be at AMS
> anymore. My suggestion would be to leave that responsibility with the LLC,
> which would likely contract it out together with operation and maintenance
> of our other web properties.
>
> Thoughts?
>
> Thanks,
> Lars
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--0000000000009f068c05c791d61e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Jul 20, 2021 at 7:00 AM Lars =
Eggert <lars@eggert.org> wrote=
:
Hi,



RFC8728 says in Section 2:



=C2=A0 =C2=A0The RFC Series Editor will exercise

=C2=A0 =C2=A0strategic leadership and management over the activities of the=
 RFC

=C2=A0 =C2=A0Publisher and the RFC Production Center (both of which can be =
seen as

=C2=A0 =C2=A0back-office functions) and will be the entity that:

=C2=A0 =C2=A0(...)

=C2=A0 =C2=A0*=C2=A0 Is responsible for the content of the rfc-editor.org w=
eb site,

=C2=A0 =C2=A0 =C2=A0 which is operated and maintained by the RFC Publisher.=




In other words, the content of the site is currently owned by the RSE, and =
the website operation and maintenance by the RPC (which is AMS, which also =
operates and maintains the IETF's other web presences.) The text above =
also lacks some clarity, for example, about who is responsible for the pres=
entation/look&feel of the site (which has been the RSE IIRC).



I'm not aware that there has been a discussion in the program about how=
 where these responsibilities would land in the future. (Apologies if I mis=
sed something.)



Given the changes to the role of what used to be the RSE, I think it makes =
sense to re-home the responsibilities for the high-level content of the sit=
e elsewhere. Personally, I think the RSAB would be a better home than the R=
SWG, but I could be convinced otherwise.

Yeah, this is probably right. I would hope that the RSWG would delegate a=
lmost all of that to whoever operates it. 

-Ek=
r

 



I think the operation and maintenance of the site should NOT remain with th=
e RPC. It's a skillset that is completely separated from the rest of th=
eir function. Leaving it with the RPC would also fracture our we presence, =
if the RPC function at some future time would not be at AMS anymore. My sug=
gestion would be to leave that responsibility with the LLC, which would lik=
ely contract it out together with operation and maintenance of our other we=
b properties.



Thoughts?



Thanks,

Lars

-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future




--0000000000009f068c05c791d61e--


From nobody Tue Jul 20 11:06:38 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A5B3A2CE5 for ; Tue, 20 Jul 2021 11:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 uWx1udjUQxUC for ; Tue, 20 Jul 2021 11:06:31 -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 5FA913A2CE2 for ; Tue, 20 Jul 2021 11:06:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GTmqp5Ydpz1nsgF; Tue, 20 Jul 2021 11:06:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1626804390; bh=iWSijrUe8Z8pbbWyCKmOPH3y1Fi8eapB2StwzJSvHGU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MCi6eIz5cQbrLB5xHGl7pZFgKmLP2LwfUN3xinCh0vSr0s9164jQrV2Hvye3+H6yK s5BWSoB22vC9BXpJkKp5oLRl8BdwMUcD3WeFl/l5tg1uy8Lty/qQz/Qu0uuRJ5QqLI agFTo5kXao2eiA62YyDf8TPzAuEsrReakul8kIMg=
X-Quarantine-ID: <86NaEfy0D5l4>
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)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GTmqp0GTvz1nsGQ; Tue, 20 Jul 2021 11:06:29 -0700 (PDT)
To: Lars Eggert , rfced-future@iab.org
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org>
From: "Joel M. Halpern" 
Message-ID: <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com>
Date: Tue, 20 Jul 2021 14:06:29 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jul 2021 18:06:37 -0000

I would note that this goes back to the distinction (which I am not sure 
we bother with any more) between the RFC Production Center and the RFC 
Publication Facility.   I don't mind obliterating the distinction.  But 
the RFC Publication process has to have a close relationship with the 
web site maintenance.

This is separate from the responsibility for deciding the look, feel, 
and general behavior of the RFC Editor web site.  I could live with 
moving that to the RSAB.  It seems strange to move it to the RSWG.  And 
it seems even stranger to move it to the IETF LLC, who are one customer 
of the output, and the primary funder.  It seems to conflate relationships.

Yours,
Joel

On 7/20/2021 9:59 AM, Lars Eggert wrote:
> Hi,
> 
> RFC8728 says in Section 2:
> 
>     The RFC Series Editor will exercise
>     strategic leadership and management over the activities of the RFC
>     Publisher and the RFC Production Center (both of which can be seen as
>     back-office functions) and will be the entity that:
>     (...)
>     *  Is responsible for the content of the rfc-editor.org web site,
>        which is operated and maintained by the RFC Publisher.
> 
> In other words, the content of the site is currently owned by the RSE, and the website operation and maintenance by the RPC (which is AMS, which also operates and maintains the IETF's other web presences.) The text above also lacks some clarity, for example, about who is responsible for the presentation/look&feel of the site (which has been the RSE IIRC).
> 
> I'm not aware that there has been a discussion in the program about how where these responsibilities would land in the future. (Apologies if I missed something.)
> 
> Given the changes to the role of what used to be the RSE, I think it makes sense to re-home the responsibilities for the high-level content of the site elsewhere. Personally, I think the RSAB would be a better home than the RSWG, but I could be convinced otherwise.
> 
> I think the operation and maintenance of the site should NOT remain with the RPC. It's a skillset that is completely separated from the rest of their function. Leaving it with the RPC would also fracture our we presence, if the RPC function at some future time would not be at AMS anymore. My suggestion would be to leave that responsibility with the LLC, which would likely contract it out together with operation and maintenance of our other web properties.
> 
> Thoughts?
> 
> Thanks,
> Lars
> 
> 


From nobody Tue Jul 20 13:56:37 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9363A31DB for ; Tue, 20 Jul 2021 13:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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 O05wpRg7T8XL for ; Tue, 20 Jul 2021 13:56:30 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47843A31D9 for ; Tue, 20 Jul 2021 13:56:30 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id m83so612509pfd.0 for ; Tue, 20 Jul 2021 13:56:30 -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=fRlqqLN0gvPzBKjLssyGDESQmioYhe1mHUGEUrCAlV8=; b=CvB3N/aqwJ3VOkTLAPPWIEM/q2weqB9V3WslGXlJHkhIuzzFl5kJIz7M2fO2JUBzOM rd+eCDQKsBC26T4cyYPDCZqvKuDkOn3g/L35ecbud135cR1US72HN+L8lJodPKMu8HMH IUZNpHBroZT+hklWl2evakkF2ekBWDjHFp4vWNhf0Bl+xju5eYjcP3w/bB9kUQg/Y1QH Fc0QQYPphguPNL582ZyRagx6NC1PkKb4m1RL4pBSBj3NTvZABQKA7kSXRbG8E/0axh6h TxouRfwQNeTN6+EEO/zx+N7dpeyqXBkunJJqHN61Be2sWAf5fuhqGyImXz60XPzf+j4A JLIQ==
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=fRlqqLN0gvPzBKjLssyGDESQmioYhe1mHUGEUrCAlV8=; b=VnL0M4Bxr1EIFJmhQMRU+lYS1KvxyKk9oFVFO5cjxAx17wBtQhKGXHws6edHesHlZO RHaCCt7g0mogf2yEuiXyzOOv+ii0XfCzkIIk0YCxrPEEOmhujwfcVEOZgBboEctJYDPt 55hmv75Fhp/IZbIlf/qwBIPlfD6769m3fIJztI4WMK7LdLyeNGLahfYxWwqlo1AzGhms LngMcz0jVtVdQK/4byp53DUgsqn9ajyoMh4cBCqHyU2jezumXCH/LgOk5g0Hxuiek2ZD gXIAlEie/z/aBduBc/LKU5FQNQksh73l+n4XEIPa7ktJbACXT18FeBTl4C2M8DRgEGjC xTyQ==
X-Gm-Message-State: AOAM530Nvqpxm7Iqkgp4iDItfc8NO5Keu2kH5CVUHAHbMcjoUuwlU0n2 z0DTs5KKLxb6AXR8iBzds8pi1rLgOIjnjw==
X-Google-Smtp-Source: ABdhPJw0/cfyXhzGWZb7XXlxXIs+pnN5I3c9kWmXyJWgGIp5oU7hsp2mMyR2tK71pc5wg8izuDplpQ==
X-Received: by 2002:a05:6a00:91:b029:330:8ab3:d7d9 with SMTP id c17-20020a056a000091b02903308ab3d7d9mr33646425pfj.22.1626814589075;  Tue, 20 Jul 2021 13:56:29 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id i18sm25487087pfa.149.2021.07.20.13.56.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jul 2021 13:56:28 -0700 (PDT)
To: "Joel M. Halpern" , Lars Eggert , rfced-future@iab.org
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org> <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com>
From: Brian E Carpenter 
Message-ID: 
Date: Wed, 21 Jul 2021 08:56:24 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jul 2021 20:56:36 -0000

On 21-Jul-21 06:06, Joel M. Halpern wrote:
> I would note that this goes back to the distinction (which I am not sure 
> we bother with any more) between the RFC Production Center and the RFC 
> Publication Facility.   I don't mind obliterating the distinction.  But 
> the RFC Publication process has to have a close relationship with the 
> web site maintenance.

I think we need advice from the LLC side on this. As I understand it, 
it's a happy coincidence that the same company has both contracts today.
That isn't a given for the long term. To achieve what Lars suggests,
there might be a need for refactoring  the contracts. That seems a
bit out of scope for our draft.

> This is separate from the responsibility for deciding the look, feel, 
> and general behavior of the RFC Editor web site.  I could live with 
> moving that to the RSAB.  It seems strange to move it to the RSWG.  And 
> it seems even stranger to move it to the IETF LLC, who are one customer 
> of the output, and the primary funder.  It seems to conflate relationships.

Yes, but then it's a bit like the style guide. It would seem logical for
the RSWG/RSAB to document requirements & desires for the web site,
but until further notice (see above) the implementation & operation
are RPC/RPF jobs.

   Brian

> 
> Yours,
> Joel
> 
> On 7/20/2021 9:59 AM, Lars Eggert wrote:
>> Hi,
>>
>> RFC8728 says in Section 2:
>>
>>     The RFC Series Editor will exercise
>>     strategic leadership and management over the activities of the RFC
>>     Publisher and the RFC Production Center (both of which can be seen as
>>     back-office functions) and will be the entity that:
>>     (...)
>>     *  Is responsible for the content of the rfc-editor.org web site,
>>        which is operated and maintained by the RFC Publisher.
>>
>> In other words, the content of the site is currently owned by the RSE, and the website operation and maintenance by the RPC (which is AMS, which also operates and maintains the IETF's other web presences.) The text above also lacks some clarity, for example, about who is responsible for the presentation/look&feel of the site (which has been the RSE IIRC).
>>
>> I'm not aware that there has been a discussion in the program about how where these responsibilities would land in the future. (Apologies if I missed something.)
>>
>> Given the changes to the role of what used to be the RSE, I think it makes sense to re-home the responsibilities for the high-level content of the site elsewhere. Personally, I think the RSAB would be a better home than the RSWG, but I could be convinced otherwise.
>>
>> I think the operation and maintenance of the site should NOT remain with the RPC. It's a skillset that is completely separated from the rest of their function. Leaving it with the RPC would also fracture our we presence, if the RPC function at some future time would not be at AMS anymore. My suggestion would be to leave that responsibility with the LLC, which would likely contract it out together with operation and maintenance of our other web properties.
>>
>> Thoughts?
>>
>> Thanks,
>> Lars
>>
>>
> 


From nobody Tue Jul 20 14:02:11 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F09C3A3208 for ; Tue, 20 Jul 2021 14:02:10 -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, 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 V0p-IVAO43hF for ; Tue, 20 Jul 2021 14:02:05 -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 EB86D3A3207 for ; Tue, 20 Jul 2021 14:02:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GTrkH6N9Xz1nsLV; Tue, 20 Jul 2021 14:01:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1626814919; bh=IKAheStVNa+XbTPVSB2+ejflYl6/+mRg9pOD4GxZ3RQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=a2+LQdkiHkBUwKJpk+qhsEZogLKxHxi/sDHtAOlJ4CA7wvW76lkNFqOMlkXpu6XJL MbnD/8Ll3g/6UBqZvl+RQoGiNjg4VPDzOCl1PomIxF39zxXAWSuIopYC0hd9a/IEzA P3hG2tBqz+qrBYcyfv2JLG0wCcyhSBZjCWh1odUE=
X-Quarantine-ID: 
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)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GTrkH1tQnz1nsXm; Tue, 20 Jul 2021 14:01:59 -0700 (PDT)
To: Brian E Carpenter , Lars Eggert , rfced-future@iab.org
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org> <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com> 
From: "Joel M. Halpern" 
Message-ID: <99dcdc59-1c35-a54b-ecf6-98a463a70b5c@joelhalpern.com>
Date: Tue, 20 Jul 2021 17:01:58 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
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: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jul 2021 21:02:11 -0000

I can probably live with saying the RPC / RPF owns the job of selecting 
and maintaining the look, feel, and content of the web site. Presumably 
in consultation with the community (RSWB?) for large changes.

Maybe that means the RSWG owns the big picture, the RSAB owns the middle 
picture, and the RPC / RPF own the details?

Yours,
Joel

On 7/20/2021 4:56 PM, Brian E Carpenter wrote:
> On 21-Jul-21 06:06, Joel M. Halpern wrote:
>> I would note that this goes back to the distinction (which I am not sure
>> we bother with any more) between the RFC Production Center and the RFC
>> Publication Facility.   I don't mind obliterating the distinction.  But
>> the RFC Publication process has to have a close relationship with the
>> web site maintenance.
> 
> I think we need advice from the LLC side on this. As I understand it,
> it's a happy coincidence that the same company has both contracts today.
> That isn't a given for the long term. To achieve what Lars suggests,
> there might be a need for refactoring  the contracts. That seems a
> bit out of scope for our draft.
> 
>> This is separate from the responsibility for deciding the look, feel,
>> and general behavior of the RFC Editor web site.  I could live with
>> moving that to the RSAB.  It seems strange to move it to the RSWG.  And
>> it seems even stranger to move it to the IETF LLC, who are one customer
>> of the output, and the primary funder.  It seems to conflate relationships.
> 
> Yes, but then it's a bit like the style guide. It would seem logical for
> the RSWG/RSAB to document requirements & desires for the web site,
> but until further notice (see above) the implementation & operation
> are RPC/RPF jobs.
> 
>     Brian
> 
>>
>> Yours,
>> Joel
>>
>> On 7/20/2021 9:59 AM, Lars Eggert wrote:
>>> Hi,
>>>
>>> RFC8728 says in Section 2:
>>>
>>>      The RFC Series Editor will exercise
>>>      strategic leadership and management over the activities of the RFC
>>>      Publisher and the RFC Production Center (both of which can be seen as
>>>      back-office functions) and will be the entity that:
>>>      (...)
>>>      *  Is responsible for the content of the rfc-editor.org web site,
>>>         which is operated and maintained by the RFC Publisher.
>>>
>>> In other words, the content of the site is currently owned by the RSE, and the website operation and maintenance by the RPC (which is AMS, which also operates and maintains the IETF's other web presences.) The text above also lacks some clarity, for example, about who is responsible for the presentation/look&feel of the site (which has been the RSE IIRC).
>>>
>>> I'm not aware that there has been a discussion in the program about how where these responsibilities would land in the future. (Apologies if I missed something.)
>>>
>>> Given the changes to the role of what used to be the RSE, I think it makes sense to re-home the responsibilities for the high-level content of the site elsewhere. Personally, I think the RSAB would be a better home than the RSWG, but I could be convinced otherwise.
>>>
>>> I think the operation and maintenance of the site should NOT remain with the RPC. It's a skillset that is completely separated from the rest of their function. Leaving it with the RPC would also fracture our we presence, if the RPC function at some future time would not be at AMS anymore. My suggestion would be to leave that responsibility with the LLC, which would likely contract it out together with operation and maintenance of our other web properties.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Lars
>>>
>>>
>>
> 


From nobody Tue Jul 20 16:41:27 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7462B3A36CE for ; Tue, 20 Jul 2021 16:41:25 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdEo-kAo5fnZ; Tue, 20 Jul 2021 16:41:19 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 8D98D3A36CA; Tue, 20 Jul 2021 16:41:18 -0700 (PDT)
From: Jay Daley 
Message-Id: <169EF869-38B9-415C-A341-9C7354160DA1@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7A187BD1-3AA6-4AD8-9CA1-CF14D39FF877"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 21 Jul 2021 11:41:15 +1200
In-Reply-To: 
Cc: "Joel M. Halpern" , Lars Eggert , rfced-future@iab.org
To: Brian E Carpenter 
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org> <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com> 
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Jul 2021 23:41:26 -0000

--Apple-Mail=_7A187BD1-3AA6-4AD8-9CA1-CF14D39FF877
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

If we look at the main website, www.ietf.org  then =
we have the following levels/roles:

- At the strategic level, the site is owned by the IESG, which in =
practice is delegated to the IETF Chair.  The IETF Chair then has =
oversight of the levels below and is the escalation/checking point for =
the bigger strategic stuff and in particular is the one that decides on =
how the community is involved in the bigger changes. This is not =
documented and all a bit loose but works in practice. For example, =
there=E2=80=99s no RFC or IESG statement regarding the purpose and =
principles of the website, nor how it is managed.

-  At the operational level, the IETF LLC is responsible for managing =
the site, which includes the look and feel, SEO, accessibility, =
information architecture, voice and content.  The content comes from a =
variety of sources including extensive community contributions but the =
bulk of new/changed content is authored by the LLC/Secretariat. This is =
all within the role remit of Greg Wood as Director of Communications and =
Operations for the LLC who has has been working on the website for =
years.

- At the technical level, the CMS configuration and build is mostly =
outsourced to Springload via an RFP (some simple bits are done by the =
LLC) and is project based work. The hosting of the site is outsourced to =
AMS via an RFP and is generally low maintenance.


For the RFC Editor site there are a number of things to consider:

- While the RSWG can be a good place for setting the purpose and =
principles of the website it doesn=E2=80=99t ensure good coordination =
with the rest of the web presence and that matters to people who =
actually use our websites. =20

For example, there was a time when rfc-editor.org =
 was the canonical source of information for =
authors but over time this has spread and we currently have =
documentation for authors on www.ietf.org , =
tools.ietf.org  and rfc-editor.org =
 and regularly some get out of date or don=E2=80=99=
t align.  Coordination is required to ensure that authors, particularly =
new ones, can get the correct information easily and that=E2=80=99s more =
than just aligning content - it may mean putting all this into a new =
authors site, or having rfc-editor.org  only =
cover AUTH48 and the other sites not to cover that.

To be clear, this coordination isn=E2=80=99t working correctly so having =
the RSWG solely responsible wouldn=E2=80=99t break anything but it would =
fix anything either.  For example, we really need to decide in a =
coordinated fashion across all the web presences if we are going to use =
rel=3D"canonical" wherever we publish an RFC to point to the =
rfc-editor.org  site as the authoritative =
source.

I=E2=80=99m not sure what to suggest to fix this, but perhaps having the =
RSWG set the high level policy and the RSAB responsible for ensuring the =
coordination is better.

- While the RPC is an obvious source of content for the site, the rest =
of managing the site (look and feel, SEO, accessibility, information =
architecture, voice) is not within the contracted skill set and would =
sit much better with the LLC, which has the specialist skills.

- At the technical level, this site uses a much simple CMS and is all =
managed by AMS and nothing needs to change.


Jay


> On 21/07/2021, at 8:56 AM, Brian E Carpenter =
 wrote:
>=20
> On 21-Jul-21 06:06, Joel M. Halpern wrote:
>> I would note that this goes back to the distinction (which I am not =
sure=20
>> we bother with any more) between the RFC Production Center and the =
RFC=20
>> Publication Facility.   I don't mind obliterating the distinction.  =
But=20
>> the RFC Publication process has to have a close relationship with the=20=

>> web site maintenance.
>=20
> I think we need advice from the LLC side on this. As I understand it,=20=

> it's a happy coincidence that the same company has both contracts =
today.
> That isn't a given for the long term. To achieve what Lars suggests,
> there might be a need for refactoring  the contracts. That seems a
> bit out of scope for our draft.
>=20
>> This is separate from the responsibility for deciding the look, feel,=20=

>> and general behavior of the RFC Editor web site.  I could live with=20=

>> moving that to the RSAB.  It seems strange to move it to the RSWG.  =
And=20
>> it seems even stranger to move it to the IETF LLC, who are one =
customer=20
>> of the output, and the primary funder.  It seems to conflate =
relationships.
>=20
> Yes, but then it's a bit like the style guide. It would seem logical =
for
> the RSWG/RSAB to document requirements & desires for the web site,
> but until further notice (see above) the implementation & operation
> are RPC/RPF jobs.
>=20
>   Brian
>=20
>>=20
>> Yours,
>> Joel
>>=20
>> On 7/20/2021 9:59 AM, Lars Eggert wrote:
>>> Hi,
>>>=20
>>> RFC8728 says in Section 2:
>>>=20
>>>    The RFC Series Editor will exercise
>>>    strategic leadership and management over the activities of the =
RFC
>>>    Publisher and the RFC Production Center (both of which can be =
seen as
>>>    back-office functions) and will be the entity that:
>>>    (...)
>>>    *  Is responsible for the content of the rfc-editor.org web site,
>>>       which is operated and maintained by the RFC Publisher.
>>>=20
>>> In other words, the content of the site is currently owned by the =
RSE, and the website operation and maintenance by the RPC (which is AMS, =
which also operates and maintains the IETF's other web presences.) The =
text above also lacks some clarity, for example, about who is =
responsible for the presentation/look&feel of the site (which has been =
the RSE IIRC).
>>>=20
>>> I'm not aware that there has been a discussion in the program about =
how where these responsibilities would land in the future. (Apologies if =
I missed something.)
>>>=20
>>> Given the changes to the role of what used to be the RSE, I think it =
makes sense to re-home the responsibilities for the high-level content =
of the site elsewhere. Personally, I think the RSAB would be a better =
home than the RSWG, but I could be convinced otherwise.
>>>=20
>>> I think the operation and maintenance of the site should NOT remain =
with the RPC. It's a skillset that is completely separated from the rest =
of their function. Leaving it with the RPC would also fracture our we =
presence, if the RPC function at some future time would not be at AMS =
anymore. My suggestion would be to leave that responsibility with the =
LLC, which would likely contract it out together with operation and =
maintenance of our other web properties.
>>>=20
>>> Thoughts?
>>>=20
>>> Thanks,
>>> Lars
>>>=20
>>>=20
>>=20
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>=20

--=20
Jay Daley
IETF Executive Director
jay@ietf.org


--Apple-Mail=_7A187BD1-3AA6-4AD8-9CA1-CF14D39FF877
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


If we look at the main website, www.ietf.org then we have the following =
levels/roles:

- =
At the strategic level, the site is owned by the IESG, which in practice =
is delegated to the IETF Chair.  The IETF Chair then has oversight =
of the levels below and is the escalation/checking point for the bigger =
strategic stuff and in particular is the one that decides on how the =
community is involved in the bigger changes. This is not documented and =
all a bit loose but works in practice. For example, there=E2=80=99s no =
RFC or IESG statement regarding the purpose and principles of the =
website, nor how it is managed.

-  At the operational level, the =
IETF LLC is responsible for managing the site, which includes the look =
and feel, SEO, accessibility, information architecture, voice and =
content.  The content comes from a variety of sources including =
extensive community contributions but the bulk of new/changed content is =
authored by the LLC/Secretariat. This is all within the role remit of =
Greg Wood as Director of Communications and Operations for the LLC who =
has has been working on the website for years.

- At the technical level, the CMS =
configuration and build is mostly outsourced to Springload via an RFP =
(some simple bits are done by the LLC) and is project based work. The =
hosting of the site is outsourced to AMS via an RFP and is generally low =
maintenance.

For the RFC Editor site there are a =
number of things to consider:

- While the RSWG can be a good place =
for setting the purpose and principles of the website it doesn=E2=80=99t =
ensure good coordination with the rest of the web presence and that =
matters to people who actually use our websites.  

For example, there was a =
time when rfc-editor.org was the canonical source of =
information for authors but over time this has spread and we currently =
have documentation for authors on www.ietf.org, tools.ietf.org and rfc-editor.org and regularly some get out of date or =
don=E2=80=99t align.  Coordination is required to ensure that =
authors, particularly new ones, can get the correct information easily =
and that=E2=80=99s more than just aligning content - it may mean putting =
all this into a new authors site, or having rfc-editor.org only =
cover AUTH48 and the other sites not to cover that.

To be clear, this =
coordination isn=E2=80=99t working correctly so having the RSWG solely =
responsible wouldn=E2=80=99t break anything but it would fix anything =
either.  For example, we really need to decide in a coordinated =
fashion across all the web presences if we are going to use =
rel=3D"canonical" wherever we publish an RFC to point to the rfc-editor.org site =
as the authoritative source.

I=E2=80=99m not sure what to suggest to =
fix this, but perhaps having the RSWG set the high level policy and the =
RSAB responsible for ensuring the coordination is better.

- While the RPC is an =
obvious source of content for the site, the rest of managing the site =
(look and feel, SEO, accessibility, information architecture, voice) is =
not within the contracted skill set and would sit much better with the =
LLC, which has the specialist skills.

- At the technical level, this site =
uses a much simple CMS and is all managed by AMS and nothing needs to =
change.


Jay


On 21/07/2021, at 8:56 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On =
21-Jul-21 06:06, Joel M. Halpern wrote:
I would note that this goes back to the =
distinction (which I am not sure 
we bother with any more) =
between the RFC Production Center and the RFC 
Publication =
Facility.   I don't mind obliterating the distinction. =
 But 
the RFC Publication process has to have a close =
relationship with the 
web site maintenance.

I think we need advice from the =
LLC side on this. As I understand it, 
it's a happy =
coincidence that the same company has both contracts today.
That isn't a given for the long term. To achieve what Lars =
suggests,
there might be a need for refactoring  the =
contracts. That seems a
bit out of scope for our draft.

This is =
separate from the responsibility for deciding the look, feel, 
and general behavior of the RFC Editor web site.  I =
could live with 
moving that to the RSAB.  It seems =
strange to move it to the RSWG.  And 
it seems even =
stranger to move it to the IETF LLC, who are one customer 
of the output, and the primary funder.  It seems to =
conflate relationships.

Yes, =
but then it's a bit like the style guide. It would seem logical for
the RSWG/RSAB to document requirements & desires for the =
web site,
but until further notice (see above) the =
implementation & operation
are RPC/RPF jobs.

   Brian


Yours,
Joel

On 7/20/2021 9:59 AM, Lars =
Eggert wrote:
Hi,

RFC8728 says in Section 2:

    The RFC Series Editor will exercise
    strategic leadership and management over =
the activities of the RFC
    Publisher and =
the RFC Production Center (both of which can be seen as
 =
   back-office functions) and will be the entity that:
    (...)
    * =
 Is responsible for the content of the rfc-editor.org web =
site,
       which is =
operated and maintained by the RFC Publisher.

In other words, the content of the site is currently owned by =
the RSE, and the website operation and maintenance by the RPC (which is =
AMS, which also operates and maintains the IETF's other web presences.) =
The text above also lacks some clarity, for example, about who is =
responsible for the presentation/look&feel of the site (which has =
been the RSE IIRC).

I'm not aware that =
there has been a discussion in the program about how where these =
responsibilities would land in the future. (Apologies if I missed =
something.)

Given the changes to the role =
of what used to be the RSE, I think it makes sense to re-home the =
responsibilities for the high-level content of the site elsewhere. =
Personally, I think the RSAB would be a better home than the RSWG, but I =
could be convinced otherwise.

I think the =
operation and maintenance of the site should NOT remain with the RPC. =
It's a skillset that is completely separated from the rest of their =
function. Leaving it with the RPC would also fracture our we presence, =
if the RPC function at some future time would not be at AMS anymore. My =
suggestion would be to leave that responsibility with the LLC, which =
would likely contract it out together with operation and maintenance of =
our other web properties.

Thoughts?

Thanks,
Lars




-- 
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future




-- 
Jay Daley
IETF =
Executive Director
jay@ietf.org




=

--Apple-Mail=_7A187BD1-3AA6-4AD8-9CA1-CF14D39FF877--


From nobody Wed Jul 21 01:11:41 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9612A3A096E for ; Wed, 21 Jul 2021 01:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZdOaIKBg-GH for ; Wed, 21 Jul 2021 01:11:33 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 360933A096B for ; Wed, 21 Jul 2021 01:11:33 -0700 (PDT)
Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id DB8D760033B; Wed, 21 Jul 2021 11:11:24 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626855084; bh=1CpRi5cgGRTxk58NctvwKjJw0dZ0l6ux1a9HiEAywjE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=LeRKMHxCLiXLEg9RxSasAAb8HYdwX3sMn4iixPUNVwaYn532MaRrz3PNlXlwr6c3Q lly4ASJ/WFP0AHAvCHD+ArNgVMZkgsistNDBISSNmpiR6d+0wS7fnusYma9UPBF+W8 1J7X9EHzYe549+fDpJB4352ce1G+Al5zdgJgY9oE=
From: Lars Eggert 
Message-Id: <0445D839-1948-4FF1-8CFD-0A1779EA9299@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_9DE48D05-57C4-47CC-B1F1-F64F49F06F1A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 21 Jul 2021 11:11:24 +0300
In-Reply-To: <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com>
Cc: rfced-future@iab.org
To: "Joel M. Halpern" 
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org> <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com>
X-MailScanner-ID: DB8D760033B.A2270
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jul 2021 08:11:40 -0000

--Apple-Mail=_9DE48D05-57C4-47CC-B1F1-F64F49F06F1A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

On 2021-7-20, at 21:06, Joel M. Halpern  wrote:
> I would note that this goes back to the distinction (which I am not =
sure we bother with any more) between the RFC Production Center and the =
RFC Publication Facility.   I don't mind obliterating the distinction.  =
But the RFC Publication process has to have a close relationship with =
the web site maintenance.

thanks for pointing that out. I agree that much of the functionality I =
wrote about is per RFC8728 Section 2.3 homed at the RFC Publisher and =
not the RFC Production Center.

(And yes, because both functions are contracted to AMS and handled in a =
very integrated fashion, it's difficult to keep them separate in my =
mental model.)

I think it would be worthwhile to discuss if the role of the RFC =
Publisher is intended to stay unchanged going forward.

Thanks,
Lars



--Apple-Mail=_9DE48D05-57C4-47CC-B1F1-F64F49F06F1A
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-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmD31qwACgkQVLXDCb9w
wVeYfA//Zt7rG1XGUMT61CCOt8g8A3li48GvpxHcY61W1cW85XAmKa7BuOzD0+xT
mMdePAnI679vYabyB7ve3zhtBLOAtLslULGebjO3lf+8VyCim6sqIGsLBls9VZDu
3WyVRoigNM9DzkjW61qUPTvcJNs0RQqxoSQ/h6SU9PSfoIG3LPlSEu1axLnub046
J2sGrZc0cNT2d9COjF7U5mJ42no1XdhPjHXMCYCqDXPrRkP75XWAWq3Wr52a1tQF
3ZeGntYQeLv/1jrnqGbAEV7ZBSBVUIUokdXfHdvOi+LwQskfRDHm/q+WIzgTC7Vq
RRgXS2e5E2SoEC9salDWstG35+IGuwIXcxJ80Euqo59KRxvkQfELaYYtN5fhbe4n
d4I8yVk2m49fCh9qPD8ahKAFkgctlNuoCQ3wRDd4wpYtdjObHcMRQhNBhOSM+mNe
xRIxDUmDz94y3jtwdK4/LB/mFyGwrQ+sEpvUyB4+r3TzqKF5Xg5/uIpeo1IBoep/
RO4fkutZYMmPgupEDXZs8+hTMkgKUqubdfdNuQ2/e2Eq/xcQuJ170n0DKL1mUtu2
5ug8vu/r8SQYgw32GQ4ic/SH2vLVONW6msCTS5bbEMwJl+PMIactdd5vNxSwCYva
2LMKfYmICBU5PgoSvzeJu1Ksc0WFuTq8kfQuYAI/uLmbe5OnVwk=
=tBGd
-----END PGP SIGNATURE-----

--Apple-Mail=_9DE48D05-57C4-47CC-B1F1-F64F49F06F1A--


From nobody Wed Jul 21 09:13:26 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CFB3A1D81 for ; Wed, 21 Jul 2021 09:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 5caQ-tACPNDM for ; Wed, 21 Jul 2021 09:13:18 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 2CC6D3A1D7A for ; Wed, 21 Jul 2021 09:13:17 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id z17so2920600iog.12 for ; Wed, 21 Jul 2021 09:13:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aHgm6e2QUSV+PK/03/1oL0boExR43o6SZ+XtUgYA6Ls=; b=GYSn21cPlu2DvinJ91zQCjvZlfTHaee1/L45rDIFqqUQxzcuVlOEiZxBJbfHGMbwj5 ZEaOz4gYR3v4PvrYSDfSjMQrEploKifACjS1Rgv1KLQmgWZ/LhQ3xv/8zebYCRpzyJNF 4zn/0eO0Ew1yXEaZnzHAh892nBYYCdXMr4JK0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aHgm6e2QUSV+PK/03/1oL0boExR43o6SZ+XtUgYA6Ls=; b=gv9KS2oxmQjZ8QpLci2YjoSLj3Gfbt0SheNV5xFMqOcbeYOYfFdmUG0Xvam2N2QUJ0 BrNgfUOLp4Vy03ojxLecWQsM1SThgPYIem3ahPiL3BnPkM/GDLdu8IZVCwnobfhwz39w m7WeKgrSFgrI0BE1Z3zuTlC1H2k/VM3SX9oMSXmQawmehYrt4rdnw7KZpY5SchyYgqP4 03m6YmwRbVSyFY1wAxEKUaw6mTgTtl2OFlPj2nB5O5Pij982EKOGAad4b/ZaMbMoJNbq gTDJMPrXbEx4V/HWe9KQs28+I8w/PjTMBrEeENoN40G2iZg0KdND1YLiDvbUevlrTWLE GPPQ==
X-Gm-Message-State: AOAM5317x5vJnJ0/IDXnqvoHreLFNxgyA1uG9zOgGkBSae09mLOGRPRD GNozSzhOEQS67g8MjZvfF+N9QQ==
X-Google-Smtp-Source: ABdhPJwviiqeyTVx5CS1Jjzt8jWMuBr9ZycE1WhQHGQv4LVb+nowXTtHI/MSmC+nGFA3tErbmnk74g==
X-Received: by 2002:a02:cd0a:: with SMTP id g10mr31293825jaq.18.1626883996173;  Wed, 21 Jul 2021 09:13:16 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id z13sm4433375iop.18.2021.07.21.09.13.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jul 2021 09:13:15 -0700 (PDT)
To: Jay Daley 
Cc: rfced-future@iab.org
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org> <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com>  <169EF869-38B9-415C-A341-9C7354160DA1@ietf.org>
From: Peter Saint-Andre 
Message-ID: 
Date: Wed, 21 Jul 2021 10:13:14 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <169EF869-38B9-415C-A341-9C7354160DA1@ietf.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jul 2021 16:13:25 -0000

[ no hats ]

On 7/20/21 5:41 PM, Jay Daley wrote:
> 
> For the RFC Editor site there are a number of things to consider:
> 
> - While the RSWG can be a good place for setting the purpose and
> principles of the website 

To reiterate a concern I expressed in our June meeting, I remain leery
of micro-management by the RSWG. If we can clearly define what's policy
and what's not, then this might be workable.

Note that currently the rfc-editor.org web site provides only a few
basic functions:

https://www.rfc-editor.org/sitemap/

I could see a "policy" that the website needs to provide the canonical
location for RFCs along with information about the series, the
publication process, how to author RFCs, how to report issues and a tool
for doing so, how to retrieve RFCs, etc. But I doubt it would be a good
use of anyone's time for the policy-making entities (RSWG and even RSAB)
to specify details about look and feel, responsive web design, and the like.

Peter


From nobody Wed Jul 21 10:21:17 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E918A3A1FF9 for ; Wed, 21 Jul 2021 10:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDOuKWZnLmqw for ; Wed, 21 Jul 2021 10:21:10 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 B99F93A1FF3 for ; Wed, 21 Jul 2021 10:21:05 -0700 (PDT)
Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 2B94F60035D; Wed, 21 Jul 2021 20:20:59 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626888059; bh=QYRZpxRVjEnTI196VD9rdIU5/7rE8FupYLpocZxxKTU=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=rsLbQUO49nYLV4AOvrYN//lRWrlQBKTu3g8TOXaL1TnIdzIuIwNuRWNbCDPaANpNp YDIKRnBLMh3txS7pdE+0QVukUThdcW1zvaeYW+J94RhIZtANkivKjijsfMZ4+K6oSz nnu5M7pkS51DLasz33hSFUunZ2Imvu9m5Vi5h2DY=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Lars Eggert 
Mime-Version: 1.0 (1.0)
Date: Wed, 21 Jul 2021 20:20:58 +0300
Message-Id: <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org>
References: 
Cc: Jay Daley , rfced-future@iab.org
In-Reply-To: 
To: Peter Saint-Andre 
X-MailScanner-ID: 2B94F60035D.A34BE
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jul 2021 17:21:16 -0000

So who should in your opinion hold that responsibility going forward?

--=20
Sent from a mobile device; please excuse typos.

> On Jul 21, 2021, at 19:13, Peter Saint-Andre  wrote:
>=20
> =EF=BB=BF[ no hats ]
>=20
>> On 7/20/21 5:41 PM, Jay Daley wrote:
>>=20
>> For the RFC Editor site there are a number of things to consider:
>>=20
>> - While the RSWG can be a good place for setting the purpose and
>> principles of the website=20
>=20
> To reiterate a concern I expressed in our June meeting, I remain leery
> of micro-management by the RSWG. If we can clearly define what's policy
> and what's not, then this might be workable.
>=20
> Note that currently the rfc-editor.org web site provides only a few
> basic functions:
>=20
> https://www.rfc-editor.org/sitemap/
>=20
> I could see a "policy" that the website needs to provide the canonical
> location for RFCs along with information about the series, the
> publication process, how to author RFCs, how to report issues and a tool
> for doing so, how to retrieve RFCs, etc. But I doubt it would be a good
> use of anyone's time for the policy-making entities (RSWG and even RSAB)
> to specify details about look and feel, responsive web design, and the lik=
e.
>=20
> Peter
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future


From nobody Wed Jul 21 10:29:35 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1793A207A for ; Wed, 21 Jul 2021 10:29:34 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 fKI-5irHF4hH for ; Wed, 21 Jul 2021 10:29:28 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 7CE503A2077 for ; Wed, 21 Jul 2021 10:29:28 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id g22so3250728iom.1 for ; Wed, 21 Jul 2021 10:29:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=D8Povh3P9hBDizXtw8l+0yNiVbJF8tWUgBeMQdTm4ek=; b=JcU1iWtOqYTWmNbgCSWTL355bAQK0KyWpuR0+q9jNMhJXRZhYhzBtt6GkF5IEOnJiI xXtl8Wl4dt6Kp/XOoGf3CzzjJ1YNTjbTEzs9Kxy3Ln3IXXI8fILF2MBwffI8NaiFxzEw lbKrFzTBgd/3dIU7OMKFP2eVu1wZ2bThCDuS8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=D8Povh3P9hBDizXtw8l+0yNiVbJF8tWUgBeMQdTm4ek=; b=h/T3u5Og5X7AM201c9royuUCY0xPKTrDjFpq8A9AnrtVRSovwC9DDm29X25cYQVt++ asjjMseUVxWkTD7RW1KkVuRb62kFw5nFulR3afi/2OgW47QCQRk6Z8Fswnm4voyW3clX F5oS6OoQaZkI6V8MXu/NSWCbQBmReCfNt44NRYEVodUIrB7bb1qqi6i5UrNOs/Dtw6pG b+bwvvjc2XL8kzhCyivSfQVTJ8VsW58OrUTBNA7o+nz+VHb8mLu/cW1Zja8jUuYCZTzQ NWyad8ER2YMr/ljHtcGwtO0Cu2nPjiGWLZzRDhcA9veuWBUt7WoPWeK1p76jFa48Ob2k xy/w==
X-Gm-Message-State: AOAM53358dC3XiUxJ2YCWe8CkKqIenjaUEYYMp7qKfwIWz9TiQnQ1dTN io+8EuoM/hBUkcwTaQVR6CqJOw==
X-Google-Smtp-Source: ABdhPJx6EUtF5bTdc23MOu8B6OjflGXe299IDA3Ghi3M9AzzvKiFPzhv1+blkzjCK7fze1TYAypVJw==
X-Received: by 2002:a5d:9681:: with SMTP id m1mr27401025ion.113.1626888566416;  Wed, 21 Jul 2021 10:29:26 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id f7sm630026ils.42.2021.07.21.10.29.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jul 2021 10:29:25 -0700 (PDT)
To: Lars Eggert 
Cc: Jay Daley , rfced-future@iab.org
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org>
From: Peter Saint-Andre 
Message-ID: <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com>
Date: Wed, 21 Jul 2021 11:29:24 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jul 2021 17:29:34 -0000

On 7/21/21 11:20 AM, Lars Eggert wrote:
> So who should in your opinion hold that responsibility going forward?

I don't have an opinion and defer to those who are more directly
involved. What Jay outlined makes some sense to me.

Peter


From nobody Wed Jul 21 16:05:56 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381413A2DED for ; Wed, 21 Jul 2021 16:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elJuJGkAiqpF for ; Wed, 21 Jul 2021 16:05:49 -0700 (PDT)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 019213A2DEE for ; Wed, 21 Jul 2021 16:05:48 -0700 (PDT)
Received: by mail-pj1-x102e.google.com with SMTP id p9so3506338pjl.3 for ; Wed, 21 Jul 2021 16:05:48 -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=RMF8VcJypDWDfhfugxw+ULXEEh4TTE6HITjYW2Lxv6w=; b=reLp5V9SFLKQnlKRuT7ZtZzUKXNECM2+iC/dXQe4PQdjjIcIWiy7+JZIHt8P567N7c JZ4JkS8B/bPp3LZKhmJMUTPCi2/siIPzdbsgCnzNSekJiBsRI14O8HzdhvwS1g8epPmS Emj8QwlrijfgaK5nHIkhs/pLVH4uacsnbzx9ZMgM38pzDItduDlZgY6rRR/nPceZvDns GqOD1nwWfoBWshA+IC8CL8JGPqkTOCFYcaKPVaL40aSI+hjGEX1ziW3XxCRqjkJm4ax+ hcfmPc5SKEBTguKSRnjqvIrDH1TV39hyM9QB2wrSwpB5ykcVazVAZ3+NB3DVSE8IPQLP NUCA==
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=RMF8VcJypDWDfhfugxw+ULXEEh4TTE6HITjYW2Lxv6w=; b=HNXWBPihELBKUGQEFdN6Hj9t7MM4ht5CaokRuLyjq0tDJWBHEul2LQ3e9qS5kkABRo jYfwU4rTubE+dGoCmUAMyLVL9s6bDbAU+IPDDftwQOlzMtlKi1j41KmuFGQDx3gFZUhK +w4hzHGZwAggmMWbuY8kwSPL3nboTT2z1U410BocvwdO7Q1zNQikzidlWRYoywjK2RgL ZkT6AumYyYirV9LAELM9ktP8UQbXhWMXtZgbeZuUX0P9X2XJRFAO1fyOeNLGKLTWgms8 Z7bl/b9kRA0Jqd4DnIl8Cq1+ggzbeCe3APQMYAjyzjY8onts+So2BzCfWndBu4RCKTzE jijA==
X-Gm-Message-State: AOAM530TCKBP4qdfzGictuEVaTlLZt0aZCnX7mGlCm/lJJVB9bw5QeBp swtIXcmyeTHPYz4FvbgIpw5WgxvY4lvUfw==
X-Google-Smtp-Source: ABdhPJxJKak5AuL9MtC+1CnGAIj6FJjDvRAvuJM2goR24IcyyhXVaZ9Ch8S1aWs6tuIXzAn1HPpOUg==
X-Received: by 2002:a17:90b:4c12:: with SMTP id na18mr37702690pjb.157.1626908746937;  Wed, 21 Jul 2021 16:05:46 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:80b2:5c79:2266:e431? ([2001:df0:0:2006:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id j15sm27739763pfh.194.2021.07.21.16.05.44 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jul 2021 16:05:45 -0700 (PDT)
To: rfced-future@iab.org
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org> <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com>
From: Brian E Carpenter 
Message-ID: <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com>
Date: Thu, 22 Jul 2021 11:05:41 +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: <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jul 2021 23:05:54 -0000

On 22-Jul-21 05:29, Peter Saint-Andre wrote:
> On 7/21/21 11:20 AM, Lars Eggert wrote:
>> So who should in your opinion hold that responsibility going forward?
> 
> I don't have an opinion and defer to those who are more directly
> involved. What Jay outlined makes some sense to me.

I tend to agree, but there is a tendency for "professionally"
managed web sites to go all marketing and trendy rather than
being functional for geeks. Let's set things up so that cannot
happen to rfc-editor.org.

   bRIAN


From nobody Wed Jul 21 16:09:11 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0398E3A2E07 for ; Wed, 21 Jul 2021 16:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NY_Cz9rdburu for ; Wed, 21 Jul 2021 16:09:05 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 C83353A2E06 for ; Wed, 21 Jul 2021 16:09:05 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id nt18-20020a17090b2492b02901765d605e14so1891484pjb.5 for ; Wed, 21 Jul 2021 16:09:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=S9srFIJRpCUMmHypQ8sWyrwc7YoGZVZNnGCCucvgwtM=; b=NgmOM5Xp1qKfdppyq6nK95BxDh3+FGi8WkxiQBIXZsvS7N+nH4RZXU3GWXt41T5pvw bgDNA+2+jjgRQbLxsssnZFDp8FuX2y2prcsaoBPRxwwRc2UI6eR8swT9uHeSy0gVts4s 6jqcODbQ6U0Mfu/hTJ16Qaw2OozFT8vYeqbJn3yfdq4wMYix5EtiaPLsjvMyKQyKraNs Vr/m1jDPoBl/ilV52SJDpByjGR2IA9KG7EgbSWsOM9Nn0NoBNzyiGYNrqyRA42b5Ensn +ZTF0oGuPBJQfV0LnyIpUf+Jjfvoow+RINqJeT/BOrR9bpVw3Te7aCZUTVoCcp/Wc/am GBLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=S9srFIJRpCUMmHypQ8sWyrwc7YoGZVZNnGCCucvgwtM=; b=FW2AyV0dJk4XW4n6wLOvA3fBrZBBAxPh88NdK+c5s+q3gHfzzDMVftvJ/0hPELEQIe 4TnKiCex0ripHXDuHazyGul54gu7FfrvwdMrJRooOgQFbT0MePLLaKfTW7icoe8/TXP2 eZoci6BYXDeX8buMQC5E8jh+XqUcOoo3pOINtw3HuCIaWBOQRzL/tV1V8DkFn+bsqgY9 ARXIQ5LO0XE4YEZpx1pxr/fkUc2f4puBoz5xKGsB+JxKKZKF5USBS5VH3cLfoEfy9bN1 Pu9exuqbsVQ6Mp5ndTcMjzzccgHCqnmGJ1ovL8mHZawy1nUnMAcl7i8MG7UB84DAEEB0 yYxA==
X-Gm-Message-State: AOAM533KXt4oCNZEhSN82iuK/3DnvjcXndWcyZIWMR7hTJJyOMjhcn2l H52HUC/8iymR3pYEqEqf3zzaGzQnfpILaA==
X-Google-Smtp-Source: ABdhPJwyaIi/Q+mtxt6dfqUXfEZRTPYKAJlfNAMK1reRX2iXewWs59DMksSwKNM7+dQJxfG1qJsODg==
X-Received: by 2002:a17:90a:d254:: with SMTP id o20mr6097626pjw.136.1626908942688;  Wed, 21 Jul 2021 16:09:02 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:80b2:5c79:2266:e431? ([2001:df0:0:2006:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id v15sm12336451pff.105.2021.07.21.16.09.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jul 2021 16:09:02 -0700 (PDT)
To: Lars Eggert , "Joel M. Halpern" 
Cc: rfced-future@iab.org
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org> <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com> <0445D839-1948-4FF1-8CFD-0A1779EA9299@eggert.org>
From: Brian E Carpenter 
Message-ID: <7f22a5c9-810e-ce05-f135-8177410f0342@gmail.com>
Date: Thu, 22 Jul 2021 11:08:57 +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: <0445D839-1948-4FF1-8CFD-0A1779EA9299@eggert.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jul 2021 23:09:10 -0000

On 21-Jul-21 20:11, Lars Eggert wrote:
...
> I think it would be worthwhile to discuss if the role of the RFC Publisher is intended to stay unchanged going forward.

I've never seen any value in the production center/publisher split. Unless the LLC sees a real advantage, I would abolish it. That's distinct from potentially splitting off web site support.

   Brian


From nobody Wed Jul 21 16:17:06 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C723A2E38 for ; Wed, 21 Jul 2021 16:17:05 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 WzxXNiBx64q4 for ; Wed, 21 Jul 2021 16:17:00 -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 0958B3A2E34 for ; Wed, 21 Jul 2021 16:16:59 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id v26so4249599iom.11 for ; Wed, 21 Jul 2021 16:16:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=olwbSClua+4gwWTJTl7QvtM9Z2Wav7LS4zTG8u14LAg=; b=TkVc0I3qtKOmbWSRa9cE7CE853h1BHnmXPKO6kGWm5DNovBwQzDE+MCqx1tiPdNxi5 MSXX2X68YeVUX7kSH8hyKjZkp2cJEIgM3uxJl0QcWsdEDvOFFuTLGyP91xM3MmYAYWkD cxUi/M+9GsB18avFjAj1VRTHOTL57Mm190/aY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=olwbSClua+4gwWTJTl7QvtM9Z2Wav7LS4zTG8u14LAg=; b=j7hrHZQ9CHvr9CXLXh5lapyB2B2EKU1wkb6Qno+BTAUdHUXuxquS17/5To+1NYPwdn 9XBAVXqlpU8tyhITY2kbjBhvT5XfkutkDFo28Jc71tRxl4osec2Bn61yDL7CWlihJ/Ne yi9/i73cb2arAo64iNHWfWDtGS3vh90zZFgjeZHgEu4H5eiFWbKUUdGEfNOauazwmvS2 DfaX3jupaCzb9xPkESujbcDecFyaL7yuW4VkaOYT/BlHplRgdmHYzQfXUlZKqMT4xPKx pfyVZvzQS+A2SZkT18V3F9NhGDyCBGGKU/DaJLmDs++HWKWmF9iIIHK2tY+ZG1WnG3po w8oA==
X-Gm-Message-State: AOAM531VFYoaA941shfkM6FE93twwStB2KdEihaTwiEy6Sd3XS+dINtx csTwsGTMDVuG88En1FHPRMT0Gg==
X-Google-Smtp-Source: ABdhPJwDRnyFGjSmZ0K+Tyx0d/OOtG25gOQG1CZaGXYCi4SVom115QzuTvVyMpGJv6YxN/4fVB2dPw==
X-Received: by 2002:a02:6f1c:: with SMTP id x28mr32835680jab.95.1626909417813;  Wed, 21 Jul 2021 16:16:57 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id q1sm15669995ioi.42.2021.07.21.16.16.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jul 2021 16:16:57 -0700 (PDT)
To: Brian E Carpenter , Lars Eggert , "Joel M. Halpern" 
Cc: rfced-future@iab.org
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org> <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com> <0445D839-1948-4FF1-8CFD-0A1779EA9299@eggert.org> <7f22a5c9-810e-ce05-f135-8177410f0342@gmail.com>
From: Peter Saint-Andre 
Message-ID: <3e81526e-d716-9bd2-0a75-e68c22143acb@mozilla.com>
Date: Wed, 21 Jul 2021 17:16:54 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <7f22a5c9-810e-ce05-f135-8177410f0342@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jul 2021 23:17:06 -0000

On 7/21/21 5:08 PM, Brian E Carpenter wrote:
> On 21-Jul-21 20:11, Lars Eggert wrote:
> ...
>> I think it would be worthwhile to discuss if the role of the RFC Publisher is intended to stay unchanged going forward.
> 
> I've never seen any value in the production center/publisher split. Unless the LLC sees a real advantage, I would abolish it. That's distinct from potentially splitting off web site support.

Where is this split defined? In editing version 3 of the model I haven't
included it yet...

Peter


From nobody Wed Jul 21 16:21:32 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F303A2E5B for ; Wed, 21 Jul 2021 16:21:30 -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 9uDrJ06RTn4M for ; Wed, 21 Jul 2021 16:21:24 -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 2FB7B3A2E58 for ; Wed, 21 Jul 2021 16:21:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GVWmg4jgnz6G9SN; Wed, 21 Jul 2021 16:21:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1626909683; bh=139MIYSDVUUfYe+5WIVesjWWSP/Y7KgiHI9ggUjjvlo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZZl2zeuUYFXavgsH0NN5y2BTw5JLlKlEXHS7AJqTz1mSLudIxdtkMijFHfztO6bOs rKH+VEhVWhP+STOuvRStRfIJbzANvAMMouksX6vUCX7Za+WYjhqxA8M07Hf1+y5av/ bKgVjdpaNsb3AaRi3MVWK8aQwKXou5m2xGfJiR2s=
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)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4GVWmf5R8Dz6G7Yq; Wed, 21 Jul 2021 16:21:22 -0700 (PDT)
To: Peter Saint-Andre , Brian E Carpenter , Lars Eggert , "Joel M. Halpern" 
Cc: rfced-future@iab.org
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org> <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com> <0445D839-1948-4FF1-8CFD-0A1779EA9299@eggert.org> <7f22a5c9-810e-ce05-f135-8177410f0342@gmail.com> <3e81526e-d716-9bd2-0a75-e68c22143acb@mozilla.com>
From: "Joel M. Halpern" 
Message-ID: 
Date: Wed, 21 Jul 2021 19:21:20 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <3e81526e-d716-9bd2-0a75-e68c22143acb@mozilla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jul 2021 23:21:31 -0000

RFC 8728 and its predecessors defines at least as far back as version 1 
of the model calls out that distinction.

Yours,
Joel

On 7/21/2021 7:16 PM, Peter Saint-Andre wrote:
> On 7/21/21 5:08 PM, Brian E Carpenter wrote:
>> On 21-Jul-21 20:11, Lars Eggert wrote:
>> ...
>>> I think it would be worthwhile to discuss if the role of the RFC Publisher is intended to stay unchanged going forward.
>>
>> I've never seen any value in the production center/publisher split. Unless the LLC sees a real advantage, I would abolish it. That's distinct from potentially splitting off web site support.
> 
> Where is this split defined? In editing version 3 of the model I haven't
> included it yet...
> 
> Peter
> 


From nobody Wed Jul 21 21:09:14 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19DF3A36A1 for ; Wed, 21 Jul 2021 21:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=vxUMA/64; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XWJAniXG
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZitlAMbL511 for ; Wed, 21 Jul 2021 21:09:06 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CDE3A369E for ; Wed, 21 Jul 2021 21:09:06 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 37435320098B; Thu, 22 Jul 2021 00:09:04 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 22 Jul 2021 00:09:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=X UK0T4J9MMEt/QbujkWgqleZKt86nbhLm4r0jAaD7DE=; b=vxUMA/64Oui7Blf31 NwdrHDg+O/nnwcqABjeVqdQABxquwntuySBaprEWzq0F/edDWcfMEDsxUbPkEDYZ eLkhZ277v5s8/aEtyWtA0yivigbAdmr3DLkQ3Q1QwqtT1aHJqbnVm5OlFTqPdEW2 8r/p2pPQTQ8eWcyxVXPnUSO8oYbCaXMUzveuvt7mM6THqzrnpUI21HlZ/FuOU7BF t5HGrGF9/kIwKDBfOdodflqIGhHRnQJSWs3JRUe5HFia2sVZmhjyTO7v4Clnpsu9 Zi6biGweQo80WTohEE8On5oBZQb2jgcwYM6Lc696tz1iYyuUglqqI31JLqDLju7c 40iRQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=XUK0T4J9MMEt/QbujkWgqleZKt86nbhLm4r0jAaD7 DE=; b=XWJAniXGARpvqDH5++gF6q4LcqRTHiSzXmFLQDl6/wguW7ELgsQIShyGf /vLsSUI7MMegbjJB7GmJS7RFfP0iI/FLfxoGNnXdviOA70XuCVFUHAF0pgBK1XAa 3gnTXmkEy3PK9yZHKMBGy6fqmkCVL4XUEK2/baiMqLjEV0AZhTjeyyCGi+iQWiCR oZXs5Z3sZWnBy3kfPbH/4fDUvnVQZNM4lqeQ/yAsE9FYjbFME141LRWHJmmN1voE 68fgxlLfahkxXBr/dXN/70bC5uYixyS6n/i1Gxb3MmfAWXpPQ9kr4RbzbmEd9pVQ N2dsn+3bGlN1A6xNl31oejpxw1v9w==
X-ME-Sender:  
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfeehgdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepueekvdejgfevkeehheefteelfefhheeutdetieetgffhgeegfeegffeggfffgffh necuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrghdphhhtthhpfihgrdhorhhgpd hquhhitgifghdrohhrghdpihgrsgdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnh gvth
X-ME-Proxy:    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 22 Jul 2021 00:09:01 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Nottingham 
In-Reply-To: 
Date: Thu, 22 Jul 2021 14:08:58 +1000
Cc: Jay Daley , rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A65543A-2D80-4E50-86CF-8FFF2A62A1B9@mnot.net>
References: <51BB5D56-3476-4722-98C6-3FC7DC3F925E@eggert.org> <1325bb86-ff9f-bfaa-a3b7-263655ac144c@joelhalpern.com>  <169EF869-38B9-415C-A341-9C7354160DA1@ietf.org> 
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jul 2021 04:09:13 -0000

OTOH, the current rfc-editor.org web site is a mess -- it's extremely =
hard to find important resources, has a lot of historical information =
that doesn't help current authors (and isn't marked clearly as such), =
and is difficult to navigate. It omits many important details for =
authors and users of the series.

Requiring one person/group to maintain it both in terms of content, =
presentation and best practice for Web sites seems unrealistic. What I'd =
suggest is that the site be the responsibility of the RPC, but that =
they're required to keep the source for it open (e.g., in a repo =
somewhere) so that people can make suggestions for additional content, =
design improvements, or corrections with a low barrier to entry. That =
would require some kind of review/approval process, but I suspect that =
we could settle on that pretty easily; The RPC can take small / obvious =
improvements on their own initiative, contentious / invasive ones are =
bumped up to the RSWG/RSAB.

(An argument could be made that someone other than the RPC is more =
appropriate for that role; I'm not stuck on it).

This is how we maintain httpwg.org and quicwg.org, and it works =
reasonably well. Given that we want things to be transparent, open and =
community-led, I think it's reasonable to require this.

Cheers,


> On 22 Jul 2021, at 2:13 am, Peter Saint-Andre  =
wrote:
>=20
> [ no hats ]
>=20
> On 7/20/21 5:41 PM, Jay Daley wrote:
>>=20
>> For the RFC Editor site there are a number of things to consider:
>>=20
>> - While the RSWG can be a good place for setting the purpose and
>> principles of the website=20
>=20
> To reiterate a concern I expressed in our June meeting, I remain leery
> of micro-management by the RSWG. If we can clearly define what's =
policy
> and what's not, then this might be workable.
>=20
> Note that currently the rfc-editor.org web site provides only a few
> basic functions:
>=20
> https://www.rfc-editor.org/sitemap/
>=20
> I could see a "policy" that the website needs to provide the canonical
> location for RFCs along with information about the series, the
> publication process, how to author RFCs, how to report issues and a =
tool
> for doing so, how to retrieve RFCs, etc. But I doubt it would be a =
good
> use of anyone's time for the policy-making entities (RSWG and even =
RSAB)
> to specify details about look and feel, responsive web design, and the =
like.
>=20
> Peter
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--
Mark Nottingham   https://www.mnot.net/


From nobody Thu Jul 22 06:30:17 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09DD3A469B for ; Thu, 22 Jul 2021 06:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twTAy9vrKBMA for ; Thu, 22 Jul 2021 06:30:10 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2DC3A4697 for ; Thu, 22 Jul 2021 06:30:10 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 16MDNhck026398; Thu, 22 Jul 2021 14:30:08 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=7tijuElyKcGC1oLw1TtTnUZN2wI8ZwaDIEgLKkDTU7U=; b=YWPhXdAU5FAdkYfLax5tB6mRXtU+F2Y7oo6xyZpA3pJhcpbarZMblwzASGBY1oTOn9bn Eyv8lRBmzKDumm9rQFT00NdWKMHCJNE1s3CzkrD6emEQNDOvIpD0Ntvv17AQxINB4Ohz Zgz4qkL5TOeFoGzNZ/YHWxehkCoDNFK26a9sz0hgzPMv3ce4GPqQXTC4Jwv5F9arT3Wp AJMS84hbsy6oo4MUUeId4qCq7Wl0yCDCXL+8MueK083h6nuEfGqHX6kqYGowKoCtZWeP 5KKCdM1ff6qSV+wPLnnuwVvu279pn1AFshSF2jxSBw0zKC0eMefqXTBCkALtQGU+MnOE mg== 
Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 39y4ty87u3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Jul 2021 14:30:07 +0100
Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 16MDK986004279; Thu, 22 Jul 2021 09:30:02 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint7.akamai.com with ESMTP id 39y5eq9g0f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 22 Jul 2021 09:30:02 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 22 Jul 2021 08:30:01 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.018; Thu, 22 Jul 2021 08:30:01 -0500
From: "Salz, Rich" 
To: Brian E Carpenter , "rfced-future@iab.org" 
Thread-Topic: [Rfced-future] Responsibilities for the rfc-editor.org web site
Thread-Index: AQHXfW+SCitcI7EtuUWwJrDpgjPVM6tMfN+AgAAveQCAAC4PgIABFSkAgAAS7ACAAAJbAIAAXfWAgACucIA=
Date: Thu, 22 Jul 2021 13:30:01 +0000
Message-ID: <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com>
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org> <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com> <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com>
In-Reply-To: <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.50.21061301
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.40.26]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9495AF054660F0419D643855A7299BD4@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-22_07:2021-07-22, 2021-07-22 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=626 malwarescore=0 adultscore=0 bulkscore=0 suspectscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107220089
X-Proofpoint-GUID: kMEvfUEuac4riIGQuWYziHd9IJ9H6MWx
X-Proofpoint-ORIG-GUID: kMEvfUEuac4riIGQuWYziHd9IJ9H6MWx
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-22_07:2021-07-22, 2021-07-22 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=591 bulkscore=0 spamscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 suspectscore=0 adultscore=0 impostorscore=0 malwarescore=0 clxscore=1015 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107220090
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.33) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint7
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jul 2021 13:30:16 -0000

PiAgIEkgdGVuZCB0byBhZ3JlZSwgYnV0IHRoZXJlIGlzIGEgdGVuZGVuY3kgZm9yICJwcm9mZXNz
aW9uYWxseSINCiAgICBtYW5hZ2VkIHdlYiBzaXRlcyB0byBnbyBhbGwgbWFya2V0aW5nIGFuZCB0
cmVuZHkgcmF0aGVyIHRoYW4NCiAgICBiZWluZyBmdW5jdGlvbmFsIGZvciBnZWVrcy4gTGV0J3Mg
c2V0IHRoaW5ncyB1cCBzbyB0aGF0IGNhbm5vdA0KICAgIGhhcHBlbiB0byByZmMtZWRpdG9yLm9y
Zy4NCg0KVmlhIG91dC1vZi1iYW5kICJwbGVhc2UgZG9uJ3QgbWFrZSBpdCBhbGwgbWFya2V0eS1t
YXJrZXR5LiIgIFRoaXMga2luZCBvZiBzdHlsZSBkZWNpc2lvbiBkb2VzIG5vdCBiZWxvbmcgaW4g
dGhlIGZ1dHVyZSBSRkMuDQoNCg==


From nobody Thu Jul 22 08:11:25 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4A53A49B3 for ; Thu, 22 Jul 2021 08:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level: 
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bgQgqd2X1_i for ; Thu, 22 Jul 2021 08:11:19 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 C347B3A49AE for ; Thu, 22 Jul 2021 08:11:18 -0700 (PDT)
Received: from Lear-Air.home (pool-173-54-226-148.nwrknj.fios.verizon.net [173.54.226.148]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16MFBCqA375025 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 22 Jul 2021 17:11:12 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1626966673; bh=Q3e/1QekBQKRdEIaCfgfuRxE/ygOV1UkNwiajLMVCuc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HXmGldXYbqZJVlKtQtzODQxBgjitHe0xXcB9KQAhXXmJEteoAMLm5D96PcsRzNbNx kMESs7YUSGZ7iu1q3wMM2jKAxlBkidPQEDonUcsSHjo4cEFu0mLrIiUxt97vC+cY0P k0QKADlK9aqdI747A7qjJiuBhgiuunecsKSCx1H8=
To: "Salz, Rich" , Brian E Carpenter , "rfced-future@iab.org" 
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org> <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com> <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com> <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com>
From: Eliot Lear 
Message-ID: <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch>
Date: Thu, 22 Jul 2021 11:11:11 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AyKC0glLZFcG6QWrZvMpVHwudQ3KZDX8c"
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jul 2021 15:11:24 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--AyKC0glLZFcG6QWrZvMpVHwudQ3KZDX8c
Content-Type: multipart/mixed; boundary="I211NorO8ZmnjQCl7o0D534g3vAd5h5Yg";
 protected-headers="v1"
From: Eliot Lear 
To: "Salz, Rich" ,
 Brian E Carpenter ,
 "rfced-future@iab.org" 
Message-ID: <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch>
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
References: 
 <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org>
 <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com>
 <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com>
 <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com>
In-Reply-To: <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com>

--I211NorO8ZmnjQCl7o0D534g3vAd5h5Yg
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Thanks, Rich.=C2=A0 To Mark (and others) I would ask what needs to be in =
the=20
current doc so that The Right Thing can happen later (assuming you agree =

that we don't have to engineer web sites now ;-)

Eliot

On 22.07.21 09:30, Salz, Rich wrote:
>>    I tend to agree, but there is a tendency for "professionally"
>      managed web sites to go all marketing and trendy rather than
>      being functional for geeks. Let's set things up so that cannot
>      happen to rfc-editor.org.
>
> Via out-of-band "please don't make it all markety-markety."  This kind =
of style decision does not belong in the future RFC.
>


--I211NorO8ZmnjQCl7o0D534g3vAd5h5Yg--

--AyKC0glLZFcG6QWrZvMpVHwudQ3KZDX8c
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmD5io8FAwAAAAAACgkQh7ZrRtnSejPn
+Qf/QmF8uzYBjTRfHKjCJt9VGIzj6JPzHGGzckjrTtYVjDrcloaoAbzWJfjEYOgQiOhUGSwWU5Ic
MCl4yOUP6pyKjKizEWZjJCMfTWSre/jOxT/OxNGOG657FaeznzzyZNCl2r/gR53Y98v/SpdmjJ9M
g6XijbRqOYp6dpbjDMA9px5rz2sufMRFrnsWBZWIv8iPd8Zk4JhlzvBIHarmiEI/iXV258ISdpuA
U8jdWaHI1DOu2G0ZJO+vP4mVcjeJPHKg/BP/tJAUMwieT2OnmLFr3rJvRNhTaPfGPpR11vtwoe6p
Qpi4L/EwAH148q4+KLhuVJOHbSw1HX7LAQTFyAl9Gw==
=ja1q
-----END PGP SIGNATURE-----

--AyKC0glLZFcG6QWrZvMpVHwudQ3KZDX8c--


From nobody Thu Jul 22 14:11:03 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6E93A0B5B for ; Thu, 22 Jul 2021 14:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXyrnFpW_EcA for ; Thu, 22 Jul 2021 14:10:55 -0700 (PDT)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502C23A0B63 for ; Thu, 22 Jul 2021 14:10:50 -0700 (PDT)
Received: by mail-pj1-x1030.google.com with SMTP id g23-20020a17090a5797b02901765d605e14so974302pji.5 for ; Thu, 22 Jul 2021 14:10:50 -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=8NZ763cJcc9jpL6GYxXG0y8fbNy/KT8VZF4RO7hQuIA=; b=TqvE3Tl3DwsdbKIdGw6WmVRV6iH1Mh75EHyVrqHZX72B0fT7ERjy6NhScQD+bAcFMn 37I/tLkXKivlde5nHx+cnbHJRaH+bIshhOrNPLFw6mZOWkgcJJrIfgxlcB5J/RkWRVZk vTJQu5cwRqsdrScLkG/5i7k+C+vJfjuo13z9lJqVyojRSevtpL/2jQzABNpI4cRFFEsi xvqTMyCFKGynVpGFjqIcqTdffdN4Y4vRLPlXjxPoWc5kdEBdxrpHCb/xpXMz0SThmdrq jGLThOvdb4lNCMBOh2M16mGHMJRwlu6ggN/R74nX1O4QN1Ta7d8moas5h99c5qUk6vy9 pPGA==
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=8NZ763cJcc9jpL6GYxXG0y8fbNy/KT8VZF4RO7hQuIA=; b=HHgC4FapV062c89yfGI66/w2FP49XPKBmY1+vrdF939kU5NjX+rT2MRld/ry+8uQJc XnbRsFu5DteEOVDcD+6CwzECIWcJ01csrhBF7o88WB/qUvrmFvTE6aLYkM/ZbGVyUYdE o/c3Hl3Pn/O05JOGOZtNH9Gtuzt740IQZB4h351+l1fOcmDkwMfksh682RIrczhnQBv3 m/YxOF4tg5xP+Aj0S/fnUGgol/3ZWcVolnV3RF6qNX99XZywKt7A8cCRUtE0dSFlEg3w CfELbY7Av6rVB4j3llbTcE3Z9/2mLxxqjxhvvkm66pqZmoF4BGautX4H2rqfjkejc3Sy ES7w==
X-Gm-Message-State: AOAM530ysJrW6q3/HDcp8/Gf/C6tAVft7YtSKy/a8zK8+HSrsotfqx/j i6zn5eph2oBUNYkY5LPZwRHGtFA7qFW6xA==
X-Google-Smtp-Source: ABdhPJxclV342VRzjg1oKHIF6tuZWaIyU9SrrxvSfuHvxR7XA2q8jmlC8i8FnWfFsD+qPhsUGpYriw==
X-Received: by 2002:a17:90a:8404:: with SMTP id j4mr10789723pjn.66.1626988247428;  Thu, 22 Jul 2021 14:10:47 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id t10sm34930956pgv.52.2021.07.22.14.10.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jul 2021 14:10:46 -0700 (PDT)
To: Eliot Lear , "Salz, Rich" , "rfced-future@iab.org" 
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org> <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com> <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com> <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com> <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch>
From: Brian E Carpenter 
Message-ID: 
Date: Fri, 23 Jul 2021 09:10:42 +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: <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jul 2021 21:11:01 -0000

On 23-Jul-21 03:11, Eliot Lear wrote:
> Thanks, Rich.=C2=A0 To Mark (and others) I would ask what needs to be i=
n the=20
> current doc so that The Right Thing can happen later (assuming you agre=
e=20
> that we don't have to engineer web sites now ;-)

Pretty much nothing in the draft, I think. It's largely an operational
matter for RPC + LLC. But I would expect the look & feel and functionalit=
y
of the site to become a topic of interest for the RSWG sooner or later.

   Brian

>=20
> Eliot
>=20
> On 22.07.21 09:30, Salz, Rich wrote:
>>>    I tend to agree, but there is a tendency for "professionally"
>>      managed web sites to go all marketing and trendy rather than
>>      being functional for geeks. Let's set things up so that cannot
>>      happen to rfc-editor.org.
>>
>> Via out-of-band "please don't make it all markety-markety."  This kind=20
of style decision does not belong in the future RFC.
>>
>=20


From nobody Thu Jul 22 14:26:13 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0253A0BF6 for ; Thu, 22 Jul 2021 14:26:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 CbI7byUdJPk5 for ; Thu, 22 Jul 2021 14:26:07 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBF13A0BF3 for ; Thu, 22 Jul 2021 14:26:01 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id u13so10604058lfs.11 for ; Thu, 22 Jul 2021 14:26:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kzlLHVmX6seMsqnxq+7vfh6uMCS0VKX4PzO+7wMxgUk=; b=lATmKHLaXYcRZm3sW52Nny37MpZaDnaorXoO8yyyBKUvrto7PMRKK+xB8prAD6FOBu m93rZQkBXm1WEgHBaYaxml6huZv2vRXGJk+wZjaBEcNhDfee2RAPEqsKKAqWIbHnf6nB h/rIP6JDYU5zYNuCtUjKK8lf+By2BewEKkiWDntlq7gjBpA0U0qrED9FqYpj9JS0jS9Z ADAO2DJqLaZD4Va20MU2SbP5HGazQi+e0vzbPAK5kf4u2g7B5ojbxW1bAdhjII2Ffv6V mOd9flcZe66Wvb96IpjmC0SxeUbE9LvGaVGLgGDc+SDxZkz9bbICa06cVxvjA1hvQKPM fFEQ==
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=kzlLHVmX6seMsqnxq+7vfh6uMCS0VKX4PzO+7wMxgUk=; b=hMceThp00C8heNIizAlpe/gmzDOk4hkluq2gqop7hUZckKeTpCYq69QHVgs/OUuEn6 wZOnwq6WKK4t+4DCXA0v8Lc8Lkoit4zpNUje4lIrkFVNQb1qAauyBG9Enlz9oWId+uld z+4OdexmHKpCCyS7cvmJtb/02CjDGSlkLKO5Vfz1f8dWFvc+TY5ek5yamwDvy5R0wyDV 12gwVwftJ2IJCnu35uhDwT3uELxKlILBhugtenixO+vHvQ46Fd4y25/jLugRJbycke3T h50BEEU2aIjTG7CzyiGoxiCJkAxoiSBKQggsUxUHfV50J56GmKFWu1MZXihN0GayJF8o wTyw==
X-Gm-Message-State: AOAM533bERfGq9vxk8894cO/KenshEMrEH2Tr0rUlyCRdUzpJD1o7LPx bPCaNTiC8zAhdiiLPslYLwyGA/RN1/49fVkS548NFg==
X-Google-Smtp-Source: ABdhPJyRcjn5CYhsuD9DvcZzQ9weLWAAPEoum3KROLgZqA38l96fOhdrhDL2E0BNtjvvi5dKG2kVNOGqqBjsg/jo15Q=
X-Received: by 2002:ac2:52a8:: with SMTP id r8mr821323lfm.475.1626989158400; Thu, 22 Jul 2021 14:25:58 -0700 (PDT)
MIME-Version: 1.0
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org> <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com> <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com> <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com> <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch> 
In-Reply-To: 
From: "StJohns, Michael" 
Date: Thu, 22 Jul 2021 17:25:47 -0400
Message-ID: 
To: Brian E Carpenter 
Cc: Eliot Lear , "Salz, Rich" , "rfced-future@iab.org" 
Content-Type: multipart/alternative; boundary="000000000000d7278105c7bcee92"
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jul 2021 21:26:12 -0000

--000000000000d7278105c7bcee92
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I=E2=80=99m confused as to how the website look and feel and/or functionali=
ty is a
=E2=80=9Cstrategic=E2=80=9D issue.  The RSWG as a collective entity has onl=
y one path to
affect the RFC function - writing documents for approval of the RSAB.  I
would be shocked if the L&F and functionality specification would benefit
from being institutionalized as an RFC.


 I can see the LLC, RSAB, and RSCE(?) engaging with various members of the
RSWG, and with the community for input - but that doesn=E2=80=99t translate=
 to this
being within either the responsibility or authority of the RSWG.



On Thu, Jul 22, 2021 at 17:11 Brian E Carpenter 
wrote:

> On 23-Jul-21 03:11, Eliot Lear wrote:
> > Thanks, Rich.  To Mark (and others) I would ask what needs to be in the
> > current doc so that The Right Thing can happen later (assuming you agre=
e
> > that we don't have to engineer web sites now ;-)
>
> Pretty much nothing in the draft, I think. It's largely an operational
> matter for RPC + LLC. But I would expect the look & feel and functionalit=
y
> of the site to become a topic of interest for the RSWG sooner or later.
>
>    Brian
>
> >
> > Eliot
> >
> > On 22.07.21 09:30, Salz, Rich wrote:
> >>>    I tend to agree, but there is a tendency for "professionally"
> >>      managed web sites to go all marketing and trendy rather than
> >>      being functional for geeks. Let's set things up so that cannot
> >>      happen to rfc-editor.org.
> >>
> >> Via out-of-band "please don't make it all markety-markety."  This kind
> of style decision does not belong in the future RFC.
> >>
> >
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--000000000000d7278105c7bcee92
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I=E2=80=99m confused as to how the website look and feel =
and/or functionality is a =E2=80=9Cstrategic=E2=80=9D issue.=C2=A0 The RSWG=
 as a collective entity has only one path to affect the RFC function - writ=
ing documents for approval of the RSAB.=C2=A0 I would be shocked if the L&a=
mp;F and functionality specification would benefit from being institutional=
ized as an RFC. =C2=A0

<=
br>
=C2=A0I can see the LLC, RSAB, and RSCE(?) engag=
ing with various members of the RSWG, and with the community for input - bu=
t that doesn=E2=80=99t translate to this being within either the responsibi=
lity or authority of the RSWG. =C2=A0 =C2=A0=C2=A0
<=
br>


On Thu, Jul 22, 2021 at 17:11 Brian E C=
arpenter <brian.e.carpent=
er@gmail.com> wrote:
On 23-J=
ul-21 03:11, Eliot Lear wrote:

> Thanks, Rich.=C2=A0 To Mark (and others) I would ask what needs to be =
in the 

> current doc so that The Right Thing can happen later (assuming you agr=
ee 

> that we don't have to engineer web sites now ;-)



Pretty much nothing in the draft, I think. It's largely an operational<=
br>
matter for RPC + LLC. But I would expect the look & feel and functional=
ity

of the site to become a topic of interest for the RSWG sooner or later.



=C2=A0 =C2=A0Brian



> 

> Eliot

> 

> On 22.07.21 09:30, Salz, Rich wrote:

>>>=C2=A0 =C2=A0 I tend to agree, but there is a tendency for &quo=
t;professionally"

>>=C2=A0 =C2=A0 =C2=A0 managed web sites to go all marketing and tren=
dy rather than

>>=C2=A0 =C2=A0 =C2=A0 being functional for geeks. Let's set thin=
gs up so that cannot

>>=C2=A0 =C2=A0 =C2=A0 happen to rfc-editor.org.

>>

>> Via out-of-band "please don't make it all markety-markety=
."=C2=A0 This kind 

of style decision does not belong in the future RFC.

>>

> 



-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future




--000000000000d7278105c7bcee92--


From nobody Thu Jul 22 14:49:36 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1A73A0CD6 for ; Thu, 22 Jul 2021 14:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-IxpQ_yNJ61 for ; Thu, 22 Jul 2021 14:49:29 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 33D583A0CD5 for ; Thu, 22 Jul 2021 14:49:28 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id g23-20020a17090a5797b02901765d605e14so1090184pji.5 for ; Thu, 22 Jul 2021 14:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ejKPJjqV1V2ORJ7BBDz6NK0BbdyBuxIJLdj/Zpcv64Q=; b=ffe2+rkPkWz9mE/4pjJHD3iXdEeLRSzaqJYUQff0H6hr9IB3mmaxdUQBg4oDORkSTi eR/Q9YHx8UY8aOtuUD+78SAfnw7bv9DHr+UCq+zVxJYMgsAaHVhwaX5zm7bO0PPIj8pW FsGiXFkuw2CPD6YDDQEbZPJd80lWzMCrbkFvbhHKz5ZLOFLzAo+k6AUbCD/b5kh1elq2 LySAoo6CmM0jTZPxFjwkOmeufVM4rDJqXi8aYZCdbXOFPhPy1ZlkqqsZdUBXqoxiyf6l VkGGnLb2qeKoRSsA+kP23p1GKoELwxKX3yBSp9ChlgDMpgg5xkQGEzsvYwUOgExazf2K n6eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ejKPJjqV1V2ORJ7BBDz6NK0BbdyBuxIJLdj/Zpcv64Q=; b=o7xKwyGSNeQbBtm6KC5rahkVe6kh6Q0hU9o73b6jhjd1uf7U0NyilacC4GbCqdP481 Ls00LjnTfLKL1njFgbb2PHDh+SrFLf1zus8TYZhNax6OYZANZe66Lmc+p196vjqlWgLe oyh0Y6EYjN7ppJXBQ0HAku6EjYRoT3wtulP3paGCnJ8khMyc6JCo1LwHkQ3WIF85Hgit l9xkRpFw6tT2un47WlQdBRedqUV1pJROkfgCpoKnwpCDZkJJ0LT9oUbq+m7TqShKeN3Q j8VL7UGxcpnf2GKaHgYqi6e4DypWbIhzDdOESgoFXib908QKXg57Q8f1n8vMhPMuOBpI sozw==
X-Gm-Message-State: AOAM532RH9zWaMAgFploon4dG0SlOgbxeSboH+oxTNDf2xCNX7jd2IW9 e31YrOXeFYO07PI8ZM0xUEyxCWH3EQLz/A==
X-Google-Smtp-Source: ABdhPJw+FPuN2ixJyhrEpuMI/F+vv8WbG0C2WxUH7mOid9iw9OCuP0WmFjDz6nfv8MFHECMKuB76gw==
X-Received: by 2002:a62:3896:0:b029:33a:f41a:11a4 with SMTP id f144-20020a6238960000b029033af41a11a4mr1739160pfa.9.1626990567505;  Thu, 22 Jul 2021 14:49:27 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id h24sm32406070pfn.180.2021.07.22.14.49.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jul 2021 14:49:27 -0700 (PDT)
To: "StJohns, Michael" 
Cc: Eliot Lear , "Salz, Rich" , "rfced-future@iab.org" 
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org> <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com> <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com> <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com> <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch>  
From: Brian E Carpenter 
Message-ID: <9fdfcb91-ea8d-3b0a-6301-86a6585c01d6@gmail.com>
Date: Fri, 23 Jul 2021 09:49:22 +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: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jul 2021 21:49:34 -0000

On 23-Jul-21 09:25, StJohns, Michael wrote:
> I=E2=80=99m confused as to how the website look and feel and/or functio=
nality is a =E2=80=9Cstrategic=E2=80=9D issue.=C2=A0 The RSWG as a collec=
tive entity has only one path to affect the RFC function - writing docume=
nts for approval of the RSAB.=C2=A0 I would be shocked if the L&F and fun=
ctionality specification would benefit from being institutionalized as an=20
RFC.=20

Well, we'll see, won't we? If the community at some point decides that
this *is* a strategic issue, the RSWG will presumably take it up. I don't=

think we need to legislate about it today.

   Brian
=C2=A0
> =C2=A0I can see the LLC, RSAB, and RSCE(?) engaging with various member=
s of the RSWG, and with the community for input - but that doesn=E2=80=99=
t translate to this being within either the responsibility or authority o=
f the RSWG. =C2=A0 =C2=A0=C2=A0
>=20
>=20
>=20
> On Thu, Jul 22, 2021 at 17:11 Brian E Carpenter > wrote:
>=20
>     On 23-Jul-21 03:11, Eliot Lear wrote:
>     > Thanks, Rich.=C2=A0 To Mark (and others) I would ask what needs t=
o be in the
>     > current doc so that The Right Thing can happen later (assuming yo=
u agree
>     > that we don't have to engineer web sites now ;-)
>=20
>     Pretty much nothing in the draft, I think. It's largely an operatio=
nal
>     matter for RPC + LLC. But I would expect the look & feel and functi=
onality
>     of the site to become a topic of interest for the RSWG sooner or la=
ter.
>=20
>     =C2=A0 =C2=A0Brian
>=20
>     >
>     > Eliot
>     >
>     > On 22.07.21 09:30, Salz, Rich wrote:
>     >>>=C2=A0 =C2=A0 I tend to agree, but there is a tendency for "prof=
essionally"
>     >>=C2=A0 =C2=A0 =C2=A0 managed web sites to go all marketing and tr=
endy rather than
>     >>=C2=A0 =C2=A0 =C2=A0 being functional for geeks. Let's set things=20
up so that cannot
>     >>=C2=A0 =C2=A0 =C2=A0 happen to rfc-editor.org .
>     >>
>     >> Via out-of-band "please don't make it all markety-markety."=C2=A0=20
This kind
>     of style decision does not belong in the future RFC.
>     >>
>     >
>=20
>     --=20
>     Rfced-future mailing list
>     Rfced-future@iab.org 
>     https://www.iab.org/mailman/listinfo/rfced-future 
>=20


From nobody Thu Jul 22 16:16:24 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21EC3A118E for ; Thu, 22 Jul 2021 16:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=HoM2F+4G; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sZxhzoDl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4sfk36jUJ-8 for ; Thu, 22 Jul 2021 16:16:16 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36303A118B for ; Thu, 22 Jul 2021 16:16:16 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 94BD35C00BD; Thu, 22 Jul 2021 19:16:15 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 22 Jul 2021 19:16:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=6 k3n20c0NnP2tGJxuW/m91UDgXMQQKF0GPvl5KQWEGo=; b=HoM2F+4GmxdLnMfAk QsJqMeNT8P21XAbXU6aHEoRDF0PrjnqonBbOEUcFNAvsf9YSj+Y+E5VEMkO46o/J +Vl5/jy0oaOocaYfxSAffjVykx2wDKLPv5Cdk8KEu/53BqE4Lv4yS8VB8etJNY2z hku5awu2YMZZ7BW6EAoo0pGlpS50nnBAxtaWJvDE8g5CLmSUTQZSz3h4Cyzg9irR ZS7x88buK4e4OIdMSbFRUr1ik1ozlHFn+PHraJr9tSvdXp+VUBKEoe3F12v6vBfz LaZgr0rbzmBunB9TIqCkoIrebrhztagNb1mpJko/XfbQTeyaqLJteaJxFCOIIrHU 9Grxw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=6k3n20c0NnP2tGJxuW/m91UDgXMQQKF0GPvl5KQWE Go=; b=sZxhzoDloFA7UlXNgKQgOOgjMzlU4uwr5GL/bg7x1b4kmOXg07HD2PqUk 5Y66WR+7wwm3JI2UWArx8z40OEljVjdaNT7Mpwy4d/zLAuymIpBQXANqC1eQh7Et SRf7Kug96K/mIIyIRkWbWfEWSIQ7gjCesTIg4oIJHkd/Vi5MB7+ZBGcajwalSK8k LFZLN5XZLBqPgIjJy/3zfdfoYilA0GUc7Rbypfn+ujO9EUnyJC6MkZZFRrwCL5+C FN5LVPXpnGziJywWDm4tXVmERff1LkShFE1UTXoSlfJl/NCBUeLrMrauFHBYydcb QsaGemF9JthanRpitYBPm/7J0aHzg==
X-ME-Sender:  
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfeejgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepudekkeelffdtveffkefggfevkeefleegkeevveejjeeuudfghfeggeefgeevhfet necuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrghdpihgrsgdrohhrghdpmhhnoh htrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 22 Jul 2021 19:16:12 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Nottingham 
In-Reply-To: <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch>
Date: Fri, 23 Jul 2021 09:16:09 +1000
Cc: "Salz, Rich" , Brian E Carpenter , "rfced-future@iab.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <44B7496C-CEC0-4F5C-81C0-A68512D3B3B8@mnot.net>
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org> <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com> <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com> <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com> <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch>
To: Eliot Lear 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jul 2021 23:16:23 -0000

I think I agree that the process we've defined should be adequate - =
i.e., we'd have a discussion in the WG about what's important (e.g., =
major bits of content, processes for changing the site, etc.), we'd make =
sure to involve the appropriate people (the RPC, if they're running the =
site currently; the LLC; etc.) and then write down what we agree to, =
ship that as an RFC (after appropriate review/approval) and then execute =
upon it.

Does that make sense to everyone?


> On 23 Jul 2021, at 1:11 am, Eliot Lear  wrote:
>=20
> Thanks, Rich.  To Mark (and others) I would ask what needs to be in =
the current doc so that The Right Thing can happen later (assuming you =
agree that we don't have to engineer web sites now ;-)
>=20
> Eliot
>=20
> On 22.07.21 09:30, Salz, Rich wrote:
>>>   I tend to agree, but there is a tendency for "professionally"
>>     managed web sites to go all marketing and trendy rather than
>>     being functional for geeks. Let's set things up so that cannot
>>     happen to rfc-editor.org.
>>=20
>> Via out-of-band "please don't make it all markety-markety."  This =
kind of style decision does not belong in the future RFC.
>>=20
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--
Mark Nottingham   https://www.mnot.net/


From nobody Thu Jul 22 17:12:59 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803163A03F2; Thu, 22 Jul 2021 17:12:53 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-3X0qO6VSIZ; Thu, 22 Jul 2021 17:12:47 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 67C453A1379; Thu, 22 Jul 2021 17:12:46 -0700 (PDT)
From: Jay Daley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_2077F572-CCCD-400A-8D00-A0BF10200A57"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Fri, 23 Jul 2021 12:12:43 +1200
In-Reply-To: <44B7496C-CEC0-4F5C-81C0-A68512D3B3B8@mnot.net>
Cc: Eliot Lear , "rfced-future@iab.org" ,  "Salz, Rich" 
To: Mark Nottingham 
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org> <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com> <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com> <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com> <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch> <44B7496C-CEC0-4F5C-81C0-A68512D3B3B8@mnot.net>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jul 2021 00:12:54 -0000

--Apple-Mail=_2077F572-CCCD-400A-8D00-A0BF10200A57
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 23/07/2021, at 11:16 AM, Mark Nottingham  wrote:
>=20
> I think I agree that the process we've defined should be adequate - =
i.e., we'd have a discussion in the WG about what's important (e.g., =
major bits of content, processes for changing the site, etc.), we'd make =
sure to involve the appropriate people (the RPC, if they're running the =
site currently; the LLC; etc.) and then write down what we agree to, =
ship that as an RFC (after appropriate review/approval) and then execute =
upon it.
>=20
> Does that make sense to everyone?

Yes.  When it comes to that I=E2=80=99ll be inclined to Mike=E2=80=99s =
view that we don=E2=80=99t want to overdo it with RFCs at inappropriate =
levels of detail but the general ability for the RSWG to agree a =
controlling RFC is fine by me (it=E2=80=99s how almost everything else =
works after all).

Jay


>=20
>=20
>> On 23 Jul 2021, at 1:11 am, Eliot Lear  wrote:
>>=20
>> Thanks, Rich.  To Mark (and others) I would ask what needs to be in =
the current doc so that The Right Thing can happen later (assuming you =
agree that we don't have to engineer web sites now ;-)
>>=20
>> Eliot
>>=20
>> On 22.07.21 09:30, Salz, Rich wrote:
>>>>  I tend to agree, but there is a tendency for "professionally"
>>>    managed web sites to go all marketing and trendy rather than
>>>    being functional for geeks. Let's set things up so that cannot
>>>    happen to rfc-editor.org.
>>>=20
>>> Via out-of-band "please don't make it all markety-markety."  This =
kind of style decision does not belong in the future RFC.
>>>=20
>>=20
>> --=20
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>=20
> --
> Mark Nottingham   https://www.mnot.net/
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>=20

--=20
Jay Daley
IETF Executive Director
jay@ietf.org


--Apple-Mail=_2077F572-CCCD-400A-8D00-A0BF10200A57
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 23/07/2021, at 11:16 AM, Mark Nottingham <mnot@mnot.net> =
wrote:

I think I agree that the process we've defined should be =
adequate - i.e., we'd have a discussion in the WG about what's important =
(e.g., major bits of content, processes for changing the site, etc.), =
we'd make sure to involve the appropriate people (the RPC, if they're =
running the site currently; the LLC; etc.) and then write down what we =
agree to, ship that as an RFC (after appropriate review/approval) and =
then execute upon it.

Does that make sense =
to everyone?

Yes.  When it comes to that I=E2=80=99ll be =
inclined to Mike=E2=80=99s view that we don=E2=80=99t want to overdo it =
with RFCs at inappropriate levels of detail but the general ability for =
the RSWG to agree a controlling RFC is fine by me (it=E2=80=99s how =
almost everything else works after all).

Jay




On 23 Jul 2021, at 1:11 am, Eliot Lear <lear@lear.ch> wrote:

Thanks, Rich.  To Mark (and others) I =
would ask what needs to be in the current doc so that The Right Thing =
can happen later (assuming you agree that we don't have to engineer web =
sites now ;-)

Eliot

On 22.07.21 09:30, Salz, Rich wrote:
  I =
tend to agree, but there is a tendency for "professionally"
    managed web sites to go all =
marketing and trendy rather than
    being =
functional for geeks. Let's set things up so that cannot
 =
   happen to rfc-editor.org.

Via =
out-of-band "please don't make it all markety-markety."  This kind =
of style decision does not belong in the future RFC.


-- 
Rfced-future =
mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

--
Mark Nottingham =
  https://www.mnot.net/

-- 
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future




-- 
Jay Daley
IETF =
Executive Director
jay@ietf.org




=

--Apple-Mail=_2077F572-CCCD-400A-8D00-A0BF10200A57--


From nobody Thu Jul 22 23:56:19 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F9A3A03EC for ; Thu, 22 Jul 2021 23:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoFuJbDHud4Z for ; Thu, 22 Jul 2021 23:56:12 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 0DB813A033F for ; Thu, 22 Jul 2021 23:56:12 -0700 (PDT)
Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id A7A3A60035D; Fri, 23 Jul 2021 09:56:02 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1627023362; bh=EfgMXHYQtDjb/hyKWmNgErJL/HiG5fpJsYT6NOeZtUY=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=jAPqI1aTQg9VGx7nRKQIUzitgVEDd+fE9ipDQQREPIH0T58OlOwjtGaf+i3+m0HNe 0vkEiQpUrCK+8amHny2UAn2SFSE9d31dCltm3/mSBwND8woaNy6N46v1CCExb54edX j6NfN0hocmczcvIdaKjXRxJuccZ8OVCAHuHIzyTY=
From: Lars Eggert 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_F44798EC-0F50-47BE-90FE-9C718A8C1A78"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 23 Jul 2021 09:56:00 +0300
In-Reply-To: 
Cc: Mark Nottingham , "rfced-future@iab.org" , "Salz, Rich" , Eliot Lear 
To: Jay Daley 
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org> <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com> <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com> <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com> <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch> <44B7496C-CEC0-4F5C-81C0-A68512D3B3B8@mnot.net> 
X-MailScanner-ID: A7A3A60035D.A2417
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jul 2021 06:56:17 -0000

--Apple-Mail=_F44798EC-0F50-47BE-90FE-9C718A8C1A78
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

On 2021-7-23, at 3:12, Jay Daley  wrote:
> Yes.  When it comes to that I=E2=80=99ll be inclined to Mike=E2=80=99s =
view that we don=E2=80=99t want to overdo it with RFCs at inappropriate =
levels of detail but the general ability for the RSWG to agree a =
controlling RFC is fine by me (it=E2=80=99s how almost everything else =
works after all).

so would that mean that RFC8728 remains in effect, and the =
responsibilities for the website remain with the (now) RSCE and the RFC =
Publisher?

Or would we update that to (say) a model where the RSAB takes over the =
website responsibilities the RSE had under RFC8728, and the LLC may =
decide to take on the RFC Publisher responsibilities and likely manage =
them alongside our other web properties?

(I understand this is a minor point to many.)

Thanks,
Lars


--Apple-Mail=_F44798EC-0F50-47BE-90FE-9C718A8C1A78
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-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmD6aAEACgkQVLXDCb9w
wVeDow//a9BJigqJaDJhZV/kTv8TTVAZ7LsTcKkF6tj2f12HTiEIUifG3B/wSKi7
LI5EVa22l4xoPfEKREu8Pz1rJj/TynPJ4Ap/RKS+m+qFYZiwz8RpvZQb9iJrXY1t
6IUJdnNJ779Sbe0OD7X2TJ6CaG4+1mua5hhq9tboc0TjLoIGFcLKq8Hi/yjXH76a
McXyPSAlmtJ1v3dCsbOl91pTDB4NgX+6nqcciuXRblRZQMQmzfGN4w0/uGLvFlN0
8EpDnIOWcP7K4vKhQghn96lxu7W8PQnHNVw0tcG0JxvFaa6iBmbGogW8KnH93tup
oBuUT6NB+CnE5qQrOctEZQT8Adj8RrNmD7lbTLrpSLo1Z6b4xRyufnovC3vuI4jv
LHkbpqWmTBXVF/lpHlR3mkoKnRjzdHILBWAPD8235/wSyxiQtXqhey3MIYU04fHr
aXdGg/mc0wrpdxuENcLF2q4i6MUVc5Kn1naN0gsYWLxVyh0LYXgnkqUgaGsHuUKp
Pq8eA6ywiwAmfVAOSDJebaTBsG/MXi4Pygr4XsRV7ExpXw5qhOf2tsJln7tDaC2Z
k4gq5hSh6VATBJ3zJow2iOgzylyCqlNy69f5nelW1kZlXcP8i+MHIWKINC+nHU/U
QjW/jTDuDFD+3rUslgFPVgAZKMdPzbyrPoMV8F19/JbvbVw49ks=
=xIab
-----END PGP SIGNATURE-----

--Apple-Mail=_F44798EC-0F50-47BE-90FE-9C718A8C1A78--


From nobody Fri Jul 23 09:46:30 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDE63A0B4C for ; Fri, 23 Jul 2021 09:46:29 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 mELv6DqFe-WV for ; Fri, 23 Jul 2021 09:46:24 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 F0C303A0B3F for ; Fri, 23 Jul 2021 09:46:23 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id r18so3339012iot.4 for ; Fri, 23 Jul 2021 09:46:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=59XRoDy1aYuKO0qD5CJpRIzBy3aSgDCEXUeJL8MEx8I=; b=TotKEmWlCgW7s8sBXscYEMk6WxF81Tev5MnA2vfGwAeCtSQFp9UVC7PpPjBtM74b8Z iD1CFkh6jWadE46vLFpVmeL7p8w8chGVuRAbkBJjonnBn7KTOCsk2YEmw/ZZ7gHKdn50 DlXE/SNPo2gtuObQygchXU0P09ZL2x+oRJKPw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=59XRoDy1aYuKO0qD5CJpRIzBy3aSgDCEXUeJL8MEx8I=; b=olxDZbKdMR/YiaHRws7btUtsAH4DdpsjLzJINKvIAeUODzx3KMQUHF8A2J6fdoKfM0 s4FKQCLrZn8IcGdZEObO2btdyJc1SfALw0YRWUvT2VA6bGzmZRzYYggRt0aoenuakRe1 oiYkW4ygQ2MSsSiwmDCh7D5fn148GuhCDyqtvqSSt6BgOW60CFLghQqbxPr/7KAx3d8E tphHaOVQXDcIuJmp3kLZzHJECrA8qp1CdRS6M94EaYdBSOKE4B1zI/YnWZVDYSDJ1A6Q PpwUbWtHStHWnguwBok8c88wd7bPUWwaDU5nkrlegbCgbd0GvmM6Hsb602YqSinxXrf6 hXig==
X-Gm-Message-State: AOAM530+dvykpRPgkFNrfD3Yvv/JW/ABBoChVjTz0f3XKtSa68haXxD5 NUTHNczvV+grImCACLQp48yu1A==
X-Google-Smtp-Source: ABdhPJw2enRwUA4bzKFWTD3v2L3XkTeVzhtb5xBG2lSJM0cjOACPOkbctj2RJjPmoiMAR5W0m4LxWA==
X-Received: by 2002:a6b:7b44:: with SMTP id m4mr4614447iop.72.1627058781701; Fri, 23 Jul 2021 09:46:21 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id l11sm19077057ios.8.2021.07.23.09.46.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jul 2021 09:46:21 -0700 (PDT)
To: Lars Eggert 
Cc: "rfced-future@iab.org" 
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org> <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com> <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com> <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com> <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch> <44B7496C-CEC0-4F5C-81C0-A68512D3B3B8@mnot.net>  
From: Peter Saint-Andre 
Message-ID: <0cf65e47-419b-163b-acb8-2d72e3936f83@mozilla.com>
Date: Fri, 23 Jul 2021 10:46:19 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jul 2021 16:46:29 -0000

On 7/23/21 12:56 AM, Lars Eggert wrote:
> Hi,
> 
> On 2021-7-23, at 3:12, Jay Daley  wrote:
>> Yes.  When it comes to that I’ll be inclined to Mike’s view that we don’t want to overdo it with RFCs at inappropriate levels of detail but the general ability for the RSWG to agree a controlling RFC is fine by me (it’s how almost everything else works after all).
> 
> so would that mean that RFC8728 remains in effect, and the responsibilities for the website remain with the (now) RSCE and the RFC Publisher?

For what it's worth, the current program I-D does state:

   Matters on which the RSEA might be consulted could include proposed
   changes to the RFC style guide [RFC7322], RFC formatting in general,
   web presence, copyright matters, archiving policy, and dissemination
   and cataloguing of RFCs.

That, however, does not assign *responsibility* for the web site.

> Or would we update that to (say) a model where the RSAB takes over the website responsibilities the RSE had under RFC8728, and the LLC may decide to take on the RFC Publisher responsibilities and likely manage them alongside our other web properties?

That seems like a reasonable starting point.

Peter


From nobody Fri Jul 23 09:59:15 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCAA3A0BEF for ; Fri, 23 Jul 2021 09:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.091
X-Spam-Level: 
X-Spam-Status: No, score=-2.091 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, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 223VvYj5hpig for ; Fri, 23 Jul 2021 09:59:07 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 98DCA3A0C35 for ; Fri, 23 Jul 2021 09:59:07 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1003::759] ([IPv6:2001:420:c0c0:1003:0:0:0:759]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16NGwwsR406250 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 23 Jul 2021 18:58:59 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627059540; bh=AUMyE2UcwS1rKckZceuSoeW6KzBsDPetMRppXTOllmg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cpt18WsiNGRTv16zlDT8eQWB5vyy2aX5mMlvJZorehWxvSfyrivfCl+F4dpz+8rRR l7EdxbwsppHpccQ7CzAlWiPUvlQ5vgrBH3ZJk/m5MqgtWSd1SXqqNBx3DFECd6+3Ca PTpUfcR7Xp+S/Y4BmG2rAEANW1EqEMvSB6bRziOI=
To: "Joel M. Halpern" , Eric Rescorla 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>  <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com>
From: Eliot Lear 
Message-ID: <2b413a40-097a-da24-db94-08be3d216701@lear.ch>
Date: Fri, 23 Jul 2021 18:58:55 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fzBT7yAhMmLBcMrpAZUqdgikmKI4faXZT"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jul 2021 16:59:13 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--fzBT7yAhMmLBcMrpAZUqdgikmKI4faXZT
Content-Type: multipart/mixed; boundary="RoNh774MsfSDOPrFDHMOyoGT5xRSGv9wA";
 protected-headers="v1"
From: Eliot Lear 
To: "Joel M. Halpern" , Eric Rescorla 
Cc: rfced-future@iab.org
Message-ID: <2b413a40-097a-da24-db94-08be3d216701@lear.ch>
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch>
 <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk>
 <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch>
 <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>
 
 <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>
 
 
 <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>
 
 <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>
 
 
 <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com>
 <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>
 
 <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>
 
 <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com>
In-Reply-To: <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com>

--RoNh774MsfSDOPrFDHMOyoGT5xRSGv9wA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: base64
Content-Language: en-US

SGksCgpPbiAwNy4wNy4yMSAyMzozNSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOgo+IERvIHlv
dSB0aGluayB3ZSBuZWVkIHRvIGluY2x1ZGUgYSBzZW50ZW5jZSBvciB0d28gaW4gdGhlIGRv
Y3VtZW50IAo+IHNheWluZyB0aGF0IHRoZSBjaGFpcnMgYXJlIHJlcXVpcmVkIHRvIGZvbGxv
dyB0aGUgcm91Z2ggY29uc2Vuc3VzIG9mIAo+IHRoZSB3b3JraW5nIGdyb3VwP8KgwqAgQW5k
IGZ1cnRoZXIgdGhhdCBpbiBwcm9jZXNzIG1hdHRlcnMgdGhlIFJTQUIgaXMgCj4gcmVxdXJp
ZWQgdG8gcmVzcGVjdCB0aGUgcm91Z2ggY29uc2Vuc3VzIG9mIHRoZSB3b3JraW5nIGdyb3Vw
P8KgwqDCoCBJZiAKPiB0aGF0IHdpbGwgaGVscCBnZXQgdGhpcyBpc3N1ZSB1bnN0dWNrLCBJ
IGFtIGFsbCBmb3IgaXQuCgoKSSB0aGluayB0aGUgYWJvdmUgdGV4dCBpcyB3aGF0IG5lZWRz
IHRvIGdldCB0dXJuZWQgaW50byBJLUQgdGV4dCBhdCB0aGlzIApwb2ludCwgYnV0IGl0IHNl
ZW1zIHRoaXMgaXMgd2hhdCBwZW9wbGUgd2FudC4KCkVsaW90CgoKPgo+IFlvdXJzLAo+IEpv
ZWwKPgo+IE9uIDcvNy8yMDIxIDQ6MjggUE0sIEVyaWMgUmVzY29ybGEgd3JvdGU6Cj4+Cj4+
Cj4+IE9uIFdlZCwgSnVsIDcsIDIwMjEgYXQgMTE6MzQgQU0gSm9lbCBNLiBIYWxwZXJuIDxq
bWhAam9lbGhhbHBlcm4uY29tIAo+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3
cm90ZToKPj4KPj4gwqDCoMKgIEkgdGhpbmsgSSBhbSBtaXNzaW5nIHNvbWV0aGluZyBpbiB5
b3VyIHJlYXNvbmluZyBFS1IuCj4+Cj4+IMKgwqDCoCBXZSBhcmUgZGlzY3Vzc2luZyB0aGUg
Y2FzZSB3aGVyZSB0aGUgUlNXRyBjaGFpcnMgYXJlIG5vdCBhZHZhbmNpbmcKPj4gwqDCoMKg
IHNvbWV0aGluZyBpbiB0aGUgcHJlc2VuY2Ugb2YgYSBjbGFpbWVkIHJvdWdoIGNvbnNlbnN1
cyBpbiBzdXBwb3J0IG9mCj4+IMKgwqDCoCB0aGF0IHRoaW5nLgo+Pgo+PiDCoMKgwqAgQW5k
IHlvdSBhcmUgb2JqZWN0aW5nIHRvIHRoZSBSU0FCIGJlaW5nIGFibGUgdG8gImZvcmNlIHRo
ZSBXRyB0bwo+PiDCoMKgwqAgYWR2YW5jZQo+PiDCoMKgwqAgaWRlYXMgaXQgdGhpbmtzIGFy
ZSBnb29kIGV2ZW4gaWYgdGhlIFJTV0cgZG9lcyBub3QuIgo+Pgo+PiDCoMKgwqAgaWYgdGhl
cmUgaXMgcm91Z2ggY29uc2Vuc3VzIGZvciB0aGUgaWRlYSwgdGhlbiB0aGUgUlNXRyB0aGlu
a3MgCj4+IHRoZSBpZGVhCj4+IMKgwqDCoCBpcyBnb29kLCBldmVuIGlmIHRoZSBjaGFpcnMg
ZG8gbm90LsKgIEkgYmVsaWV2ZSB0aGUgY2hhaXJzIHNob3VsZCAKPj4gbG9zZQo+PiDCoMKg
wqAgdGhhdCBmaWdodC4KPj4KPj4KPj4gSSdtIGdlbmVyYWxseSBmYWlybHkgc3ltcGF0aGV0
aWMgdG8gdGhpcyBwb3NpdGlvbiwgdGhvdWdoIEkgd291bGQgCj4+IG5vdGUgdGhhdCBpbgo+
PiB0aGUgSUVURiB0aGUgQ2hhaXIncyByb2xlIHNlZW1zIGEgYml0IG11ZGRsZWQgaGVyZS4g
U2VlIGVzcGVjaWFsbHkgCj4+IFJGQyA0ODU4IFMgMy4xLAo+PiB3aGljaCBJIHRoaW5rIGlt
cGxpZXMgdGhhdCB0aGUgY2hhaXJzIGRvIGhhdmUgc29tZSBzdWJzdGFudGl2ZSAKPj4gcmVz
cG9uc2liaWxpdHkgZm9yCj4+IGRvY3VtZW50IHF1YWxpdHksIG5vdCBqdXN0IHByb2NlZHVy
YWwgcmVzcG9uc2liaWxpdGllcy4KPj4KPj4KPj4gwqDCoMKgIFRoZSBvdGhlciBhbHRlcm5h
dGl2ZSBpcyB0aGF0IHRoZXJlIGlzIG5vdCByb3VnaCBjb25zZW5zdXMgZm9yIHRoZQo+PiDC
oMKgwqAgaWRlYSwKPj4gwqDCoMKgIGJ1dCB0aGUgUlNBQiBjbGFpbXMgdGhlcmUgaXMuwqAg
VGhhdCB3b3VsZCBzZWVtIHRvIGJlIHN1YmplY3QgdG8gdGhlCj4+IMKgwqDCoCBhbHJlYWR5
IGFncmVlZCBydWxlcyBmb3IgYXBwZWFsaW5nIFJTQUIgYWN0aW9ucy7CoCBCZWNhdXNlIGlu
IHRoYXQKPj4gwqDCoMKgIHNpdHVhdGlvbiB0aGUgUlNBQiB3b3VsZCBub3QgYmUgZm9sbG93
aW5nIHRoZSBwcm9jZXNzLgo+Pgo+Pgo+PiDCoMKgwqAgV2h5IGlzIHRoYXQgbm90IHN1ZmZp
Y2llbnQ/Cj4+Cj4+Cj4+IFdlbGwsIGl0J3MgYWN0dWFsbHkgbm90IGNsZWFyIHRvIG1lIHRo
YXQgdGhpcyAqd291bGQqIHZpb2xhdGUgdGhlIAo+PiBwcm9jZXNzLCBidXQgcGVyaGFwcwo+
PiBhbGwgdGhhdCdzIG5lZWRlZCBpcyBzb21lIHNoYXJwZW5pbmcgb2YgdGhlIHRleHQsIGFz
IEVsaW90IHN1Z2dlc3RzLgo+Pgo+PiAtRWtyCj4+Cj4+IMKgwqDCoCBZb3VycywKPj4gwqDC
oMKgIEpvZWwKPj4KPj4gwqDCoMKgIE9uIDcvNy8yMDIxIDE6MjggUE0sIEVyaWMgUmVzY29y
bGEgd3JvdGU6Cj4+IMKgwqDCoMKgID4KPj4gwqDCoMKgwqAgPgo+PiDCoMKgwqDCoCA+IE9u
IFR1ZSwgSnVsIDYsIDIwMjEgYXQgOTo1OSBQTSBNaWNoYWVsIFN0Sm9obnMKPj4gwqDCoMKg
IDxtc2pAbnRocGVybXV0YXRpb24uY29tIDxtYWlsdG86bXNqQG50aHBlcm11dGF0aW9uLmNv
bT4KPj4gwqDCoMKgwqAgPiA8bWFpbHRvOm1zakBudGhwZXJtdXRhdGlvbi5jb20gPG1haWx0
bzptc2pAbnRocGVybXV0YXRpb24uY29tPj4+Cj4+IMKgwqDCoCB3cm90ZToKPj4gwqDCoMKg
wqAgPgo+PiDCoMKgwqDCoCA+wqAgwqAgwqBPbiA3LzcvMjAyMSAxMjoyNCBBTSwgQnJpYW4g
RSBDYXJwZW50ZXIgd3JvdGU6Cj4+IMKgwqDCoMKgID4+PsKgIMKgIMKgPGptaD5IbW1tLsKg
IFJlYWxseT/CoCBUaGUgSUVTRyBvciB0aGUgSUFCIGdldHRpbmcgaW50bwo+PiDCoMKgwqAg
Z2l2aW5nIGFkdmljZSBhbmQKPj4gwqDCoMKgwqAgPj4+wqAgwqAgwqBvcGluaW9ucyBvbiBo
b3cgdGhlIFJTV0cgd29ya3Mgc2VlbXMgdG8gYmUgYW4gaW52b2x2ZW1lbnQKPj4gwqDCoMKg
IHdlIGhhdmUgYmVlbgo+PiDCoMKgwqDCoCA+Pj7CoCDCoCDCoGF2b2lkaW5nLsKgIDwvam1o
Pgo+PiDCoMKgwqDCoCA+PsKgIMKgIMKgVHJ1ZS4gQnV0IGluIGFueSBjYXNlLCBmaXJpbmcg
dGhlbSBpcyB0aGUgdWx0aW1hdGUgc2FuY3Rpb24KPj4gwqDCoMKgIChqdXN0IGFzIGEKPj4g
wqDCoMKgwqAgPj7CoCDCoCDCoHJlY2FsbCBpbiB0aGUgSUVURiBwcm9jZXNzIGlzIHRoZSB1
bHRpbWF0ZSBzYW5jdGlvbikuIEFzCj4+IMKgwqDCoCBsb25nIGFzIHdlIGhhdmUKPj4gwqDC
oMKgwqAgPj7CoCDCoCDCoGZpcmluZyBhcyBhbiBvcHRpb24sICJhZHZpc2UsIGFkbW9uaXNo
LCBleHByZXNzIHNlcmlvdXMKPj4gwqDCoMKgIGNvbmNlcm5zIiB3aWxsCj4+IMKgwqDCoMKg
ID4+wqAgwqAgwqBoYXBwZW4gYW55d2F5LCBiZWhpbmQgdGhlIHNjZW5lcyBpZiBub3QgaW4g
cHVibGljLiBJIGRvbid0Cj4+IMKgwqDCoCB0aGluayB3ZSBuZWVkCj4+IMKgwqDCoMKgID4+
wqAgwqAgwqB0byB3cml0ZSB0aGF0IGRvd24sIGJlY2F1c2UgaXQgd291bGQganVzdCBoYXBw
ZW4gaWYgdGhpbmdzCj4+IMKgwqDCoCB3ZW50IHdyb25nLgo+PiDCoMKgwqDCoCA+Pgo+PiDC
oMKgwqDCoCA+PsKgIMKgIMKgIMKgIMKgQnJpYW4KPj4gwqDCoMKgwqAgPj4KPj4gwqDCoMKg
wqAgPgo+PiDCoMKgwqDCoCA+wqAgwqAgwqBUaGUgcXVlc3Rpb24gdG8gd2hpY2ggSSBrZWVw
IHJldHVybmluZzrCoMKgIFRvIHdob20gaXMgdGhlIFJTV0cKPj4gwqDCoMKgwqAgPsKgIMKg
IMKgYWNjb3VudGFibGUgdG9vIGlmIG5vdCB0aGUgUlNBQj/CoMKgwqAgSXQncyBjZXJ0YWlu
bHkgbm90Cj4+IMKgwqDCoCBhY2NvdW50YWJsZQo+PiDCoMKgwqDCoCA+wqAgwqAgwqB0byB0
aGUgY29tbXVuaXR5LCBldmVuIHRob3VnaCBpdCdzIG1hZGUgdXAgb2YgdmFyaW91cwo+PiDC
oMKgwqAgcGVybXV0YXRpb25zCj4+IMKgwqDCoMKgID7CoCDCoCDCoChvdmVyIHRpbWUpIG9m
IHRoZSBtZW1iZXJzIG9mIHRoZSBjb21tdW5pdHkuIEFib3V0IGFsbCB0aGUKPj4gwqDCoMKg
wqAgPsKgIMKgIMKgY29tbXVuaXR5IGNvdWxkIGRvIHdpdGggYSBicm9rZW4gV0cgaXMgdG8g
cmVydW4gdGhlIAo+PiBwcm9jZXNzIHdlJ3JlCj4+IMKgwqDCoMKgID7CoCDCoCDCoGN1cnJl
bnRseSBkb2luZyBhbmQgcmVzdHJ1Y3R1cmUgeWV0IGFnYWluLsKgIFRoYXQgc2VlbXMgCj4+
IGJvdGggbGlrZQo+PiDCoMKgwqDCoCA+wqAgwqAgwqBvdmVya2lsbCBhbmQgYSBiYWQgbW9k
ZWwuCj4+IMKgwqDCoMKgID4KPj4gwqDCoMKgwqAgPiBXZWxsLCBJIGRvIHRoaW5rIHRoYXQg
aXQncyAqYWNjb3VudGFibGUqIHRvIHRoZSBjb21tdW5pdHkgYnV0Cj4+IMKgwqDCoCBuZWVk
cyB0aGUKPj4gwqDCoMKgwqAgPiBjb25zZW50IG9mIHRoZSBSU0FCLgo+PiDCoMKgwqDCoCA+
Cj4+IMKgwqDCoMKgID7CoCDCoCDCoFRoZSBXRyBjaGFpcnMgY2FuIGJlIHJlcGxhY2VkLCBi
dXQgdGhlcmUgaXMgbm8gZXF1aXZhbGVudAo+PiDCoMKgwqAgcmVjb3Vyc2UKPj4gwqDCoMKg
wqAgPsKgIMKgIMKgZm9yIHBhcnRpY2lwYW50cyBwcm9wb3NpbmcgYW5kIGFwcHJvdmluZyBo
YXJtZnVsIHByb3Bvc2FscyAKPj4gb3IgZm9yCj4+IMKgwqDCoMKgID7CoCDCoCDCoHRoYXQg
bWF0dGVyIHNpdHRpbmcgb24gdGhlaXIgaGFuZHMgYW5kIG5vdCBwcm9wb3NpbmcgYW5kIAo+
PiBjcmVhdGluZwo+PiDCoMKgwqDCoCA+wqAgwqAgwqBuZWNlc3NhcnkgZG9jdW1lbnRzLsKg
wqAgQW5kIG5vdyBpdCBzb3VuZHMgbGlrZSBFS1IgZXQgYWwgCj4+IChzb3JyeSB0bwo+PiDC
oMKgwqDCoCA+wqAgwqAgwqBzaW5nbGUgeW91IG91dCwgYnV0IHlvdXJzIGlzIHRoZSBtb3N0
IHJlY2VudCBwdXNoIGFnYWluc3QgCj4+IFJTQUIKPj4gwqDCoMKgwqAgPsKgIMKgIMKgY2hl
Y2tzIGFuZCBiYWxhbmNlcykgYXJlIGxvb2tpbmcgZm9yIGEgbW9kZWwgd2hlcmUgdGhlIFJT
QUIKPj4gwqDCoMKgIGNhbiBvbmx5Cj4+IMKgwqDCoMKgID7CoCDCoCDCoHB1c2ggYmFjayBv
biBwcm9jZXNzZXMgYW5kIG5vdCBiYWQgZG9jdW1lbnRzIG9yIGlkZWFzLiBPciBub3QKPj4g
wqDCoMKgIGV2ZW4KPj4gwqDCoMKgwqAgPsKgIMKgIMKgdGhhdCB3aXRoIHRoZSBwcm9wb3Nh
bCB0byBlbGltaW5hdGUgYXBwZWFscyBmcm9tIFJTV0cgCj4+IGFjdGlvbnMuCj4+IMKgwqDC
oMKgID4KPj4gwqDCoMKgwqAgPiBJIGp1c3Qgd2FudCB0byBjbGFyaWZ5IHRoYXQgSSBhbSBu
b3QgYXJndWluZyB0aGF0IHRoYXQgdGhlIFJTQUIKPj4gwqDCoMKgIHNob3VsZAo+PiDCoMKg
wqDCoCA+IG5vdCBiZSBhYmxlIHRvIHB1c2ggYmFjayBvbiBiYWQgZG9jdW1lbnRzIG9yIGlk
ZWFzLiBXaGF0IEknbQo+PiDCoMKgwqAgc2F5aW5nIGlzCj4+IMKgwqDCoMKgID4gdGhhdCB0
aGUgUlNBQiBzaG91bGQgbm90IGJlIGFibGUgdG8gZm9yY2UgdGhlIFdHIHRvIGFkdmFuY2Ug
Cj4+IGlkZWFzIGl0Cj4+IMKgwqDCoMKgID4gdGhpbmtzIGFyZSBnb29kIGV2ZW4gaWYgdGhl
IFJTV0cgZG9lcyBub3QuCj4+IMKgwqDCoMKgID4KPj4gwqDCoMKgwqAgPiAtRWtyCj4+IMKg
wqDCoMKgID4KPj4gwqDCoMKgwqAgPgo+PiDCoMKgwqDCoCA+wqAgwqAgwqBJIGtub3cgd2hv
IGFsbCBvZiB0aGUgUlNBQiBtZW1iZXJzIHdpbGwgYmUgLSBub3QgdGhlIAo+PiBpbmRpdmlk
dWFscywKPj4gwqDCoMKgwqAgPsKgIMKgIMKgYnV0IHRoZWlyIGNoYWlucyBvZiBhdXRob3Jp
dHkgYW5kIHJlc3BvbnNpYmlsaXR5IHN0ZW1taW5nCj4+IMKgwqDCoCBmcm9tIHRoZWlyCj4+
IMKgwqDCoMKgID7CoCDCoCDCoHBvc2l0aW9ucyBhbmQgZnJvbSB0aGVpciBvcmdhbml6YXRp
b25zLsKgIEknbSBsZXNzIHN1cmUgb2YgdGhlCj4+IMKgwqDCoCBSU1dHCj4+IMKgwqDCoMKg
ID7CoCDCoCDCoGNoYWlycy7CoMKgIFRoZSByZXN0IG9mIHRoZSBjcm93ZCBoYXMgbm8gYWdy
ZWVkIHVwb24gaW5kaXZpZHVhbAo+PiDCoMKgwqDCoCA+wqAgwqAgwqByZXNwb25zaWJpbGl0
aWVzLCBidXQgZ2V0cyB1bHRpbWF0ZSBhdXRob3JpdHk/IFRoaXMgbW9kZWwKPj4gwqDCoMKg
IHNlZW1zIHRvCj4+IMKgwqDCoMKgID7CoCDCoCDCoGJlIG1vdmluZyB0byBsZXNzIGFuZCBs
ZXNzIG9mIGEgZ29vZCBiYWxhbmNlIG9mIGF1dGhvcml0eSBhbmQKPj4gwqDCoMKgwqAgPsKg
IMKgIMKgcmVzcG9uc2liaWxpdHkgdGhlIGZ1cnRoZXIgd2UgZ28uCj4+IMKgwqDCoMKgID4K
Pj4gwqDCoMKgwqAgPsKgIMKgIMKgTGF0ZXIsIE1pa2UKPj4gwqDCoMKgwqAgPgo+PiDCoMKg
wqDCoCA+Cj4+IMKgwqDCoMKgID4KPj4gwqDCoMKgwqAgPsKgIMKgIMKgLS0KPj4gwqDCoMKg
wqAgPsKgIMKgIMKgUmZjZWQtZnV0dXJlIG1haWxpbmcgbGlzdAo+PiDCoMKgwqDCoCA+IFJm
Y2VkLWZ1dHVyZUBpYWIub3JnIDxtYWlsdG86UmZjZWQtZnV0dXJlQGlhYi5vcmc+Cj4+IMKg
wqDCoCA8bWFpbHRvOlJmY2VkLWZ1dHVyZUBpYWIub3JnIDxtYWlsdG86UmZjZWQtZnV0dXJl
QGlhYi5vcmc+Pgo+PiDCoMKgwqDCoCA+IGh0dHBzOi8vd3d3LmlhYi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9yZmNlZC1mdXR1cmUKPj4gwqDCoMKgIDxodHRwczovL3d3dy5pYWIub3JnL21h
aWxtYW4vbGlzdGluZm8vcmZjZWQtZnV0dXJlPgo+PiDCoMKgwqDCoCA+IMKgPGh0dHBzOi8v
d3d3LmlhYi5vcmcvbWFpbG1hbi9saXN0aW5mby9yZmNlZC1mdXR1cmUKPj4gPGh0dHBzOi8v
d3d3LmlhYi5vcmcvbWFpbG1hbi9saXN0aW5mby9yZmNlZC1mdXR1cmU+Pgo+PiDCoMKgwqDC
oCA+Cj4+IMKgwqDCoMKgID4KPj4KPgo=

--RoNh774MsfSDOPrFDHMOyoGT5xRSGv9wA--

--fzBT7yAhMmLBcMrpAZUqdgikmKI4faXZT
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmD69U8FAwAAAAAACgkQh7ZrRtnSejO8
qwgA2JuQmtLEzpzAnie3HNawQwrgPwoLyy/tuBKd+9wXF24BuR3dMufZUaMWjp5xyMdT1Ef3bosY
wuHax19h1MsJhpOCNaW9dVErEpztOH7UBTbCWq6ahUPoDTFlxjFTETMb5gSUzlumtB7wee6etkE2
Tl8pGl4PXCtFsTsPNYKsS4v/tKMJijRl4Px5X27dh6dwlVgN6hCiWg1iw4EYnuSdNRqh4+8SpRNW
Uv9ddceCfAfwE2vUf2VJxmfaEuyqUpHc0CGpKiR7sv3Fy9b2PRo2xXifcqRQGNpveJNfxOOSyO9k
JcdMpu7d6d/PcsqUR4GD9QAShlRHrwLZFTBIeMo0NQ==
=w4tB
-----END PGP SIGNATURE-----

--fzBT7yAhMmLBcMrpAZUqdgikmKI4faXZT--


From nobody Fri Jul 23 11:38:33 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D083A124A for ; Fri, 23 Jul 2021 11:38:25 -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_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=mozilla.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 GO0QoG0qf4jL for ; Fri, 23 Jul 2021 11:38:20 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 9B9B13A1262 for ; Fri, 23 Jul 2021 11:38:20 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id k3so2447481ilu.2 for ; Fri, 23 Jul 2021 11:38:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=E+CUuZE/3rCIvQD4sVhLuWHaMZsZaIQGFOL/u54/dk4=; b=MZyJga4jfKZK2CIvX2lT9QZm/Ct1z7qVccsZ0tHjwrLl9lluCd7+tscLXMboyo2v8r Ogsvpn5T5+vsh143OW2/nZ/1ydfDwVLTx5hLhnQqM/vxysmk6OCLSJ1pLga2WDQ+JvG2 FwxrFlyrcEs/OSJ9JUhj7pBBpoOaySGjwEKZs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=E+CUuZE/3rCIvQD4sVhLuWHaMZsZaIQGFOL/u54/dk4=; b=GJzF7CQQ6iEAZB9pIC5l4yULOZlD8ZDLEwPDKbKoNITSY4ihF+dLR6BUMkc+nake8L TP5JHR+iEHEhg+VDOcZTaBXhDYyOKAZGef4zLLIdnvBm1X6Bf7irUreQmUU5ib/2jEmC QF1Kxr9EfDmv6Axvh3q/q1P4oU7i600MVoQYMunWkjZz4GAtorCWjZbDdp/FZZA1E4tF JU9YCecW8MnYEQCaQyFC71DxfSpYPL5+Akf4AAHysBX1iw5sj/6r8JQxIR6NzT1C5jDg QBu9G5YXeuM3lmdxkSPFXEcUZatqY0Yp3z6+bCIMN6+TabvYazdOjJ9IdHRIJj2/rx+l PqFQ==
X-Gm-Message-State: AOAM533m2IMh0tl0uVy/9cz/72ODQ1P3uxWn/lnVjWxiIfIOUW2SICYk CGuHHnSjk1V8h7tbP1J/f70zZw==
X-Google-Smtp-Source: ABdhPJxM5ZSZPA8rMWC0nAvNVK/npAfg+hyMqMQgrg8MWPQZgIixINl4Gex40ojGFE+dfdYQ+2XDrA==
X-Received: by 2002:a92:d943:: with SMTP id l3mr4286207ilq.37.1627065499318; Fri, 23 Jul 2021 11:38:19 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id p21sm18932155iog.37.2021.07.23.11.38.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jul 2021 11:38:18 -0700 (PDT)
To: Eliot Lear , "Joel M. Halpern" , Eric Rescorla 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>  <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com> <2b413a40-097a-da24-db94-08be3d216701@lear.ch>
From: Peter Saint-Andre 
Message-ID: <7352fb2f-7ef5-e8b7-8ca2-29c79ffc4133@mozilla.com>
Date: Fri, 23 Jul 2021 12:38:17 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <2b413a40-097a-da24-db94-08be3d216701@lear.ch>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jul 2021 18:38:32 -0000

On 7/23/21 10:58 AM, Eliot Lear wrote:
> Hi,
> 
> On 07.07.21 23:35, Joel M. Halpern wrote:
>> Do you think we need to include a sentence or two in the document
>> saying that the chairs are required to follow the rough consensus of
>> the working group?   And further that in process matters the RSAB is
>> requried to respect the rough consensus of the working group?    If
>> that will help get this issue unstuck, I am all for it.
> 
> 
> I think the above text is what needs to get turned into I-D text at this
> point, but it seems this is what people want.

Our I-D currently states:

   It is the responsibility of the chairs to encourage rough consensus
   within the RSWG and to follow that consensus in their decision
   making, for instance regarding advancement of proposals to the RSAB.

and

   The RFC Series Approval Board (RSAB) shall act as the approving body
   for proposals generated within the RSWG.  The sole function of RSAB
   is to review policy proposals generated by the RSWG; it shall have no
   independent authority to formulate policy on its own.  It is expected
   that the RSAB will respect the rough consensus of the RSWG wherever
   possible, without ceding its review function.

Does that address the issue?

Peter


From nobody Fri Jul 23 12:48:53 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE583A154B for ; Fri, 23 Jul 2021 12:48:43 -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 RY3IVPTfF3lH for ; Fri, 23 Jul 2021 12:48:39 -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 8DCC23A1565 for ; Fri, 23 Jul 2021 12:48:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GWfyH1BTZz1nsZD; Fri, 23 Jul 2021 12:48:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1627069719; bh=HgXl4BAxfuasSTg+ZxmDcYh+7KJptFBQF5Hq7/JyI7k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=S9FawueQBzvhSKdfF9yEQTegRcPv1v1LcSOVVKd48qDxUaT8MUSmiQfOBh5yxIEGw 07wGBDJbEG2irwOCWxtxOO+3mMGPj+/7gkvNhrO2kwzzaGtgRslksOagYLZud7MAfO clyfvtPpeI+WvHBJjM8R8lOF6sBqqnyxxS+N8C2A=
X-Quarantine-ID: 
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 4GWfyF5xbYz1nsb3; Fri, 23 Jul 2021 12:48:37 -0700 (PDT)
To: Peter Saint-Andre , Eliot Lear , Eric Rescorla 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>  <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com> <2b413a40-097a-da24-db94-08be3d216701@lear.ch> <7352fb2f-7ef5-e8b7-8ca2-29c79ffc4133@mozilla.com>
From: "Joel M. Halpern" 
Message-ID: 
Date: Fri, 23 Jul 2021 15:48:37 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <7352fb2f-7ef5-e8b7-8ca2-29c79ffc4133@mozilla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jul 2021 19:48:52 -0000

that seems sufficient to me.  In the earlier discussion, some folks had 
seemed to think those restrictions were not sufficiently clear.  So it 
is really up to them to speak up now if that is insufficient.

Yours,
Joel

On 7/23/2021 2:38 PM, Peter Saint-Andre wrote:
> On 7/23/21 10:58 AM, Eliot Lear wrote:
>> Hi,
>>
>> On 07.07.21 23:35, Joel M. Halpern wrote:
>>> Do you think we need to include a sentence or two in the document
>>> saying that the chairs are required to follow the rough consensus of
>>> the working group?   And further that in process matters the RSAB is
>>> requried to respect the rough consensus of the working group?    If
>>> that will help get this issue unstuck, I am all for it.
>>
>>
>> I think the above text is what needs to get turned into I-D text at this
>> point, but it seems this is what people want.
> 
> Our I-D currently states:
> 
>     It is the responsibility of the chairs to encourage rough consensus
>     within the RSWG and to follow that consensus in their decision
>     making, for instance regarding advancement of proposals to the RSAB.
> 
> and
> 
>     The RFC Series Approval Board (RSAB) shall act as the approving body
>     for proposals generated within the RSWG.  The sole function of RSAB
>     is to review policy proposals generated by the RSWG; it shall have no
>     independent authority to formulate policy on its own.  It is expected
>     that the RSAB will respect the rough consensus of the RSWG wherever
>     possible, without ceding its review function.
> 
> Does that address the issue?
> 
> Peter
> 


From nobody Fri Jul 23 14:04:34 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057713A195B for ; Fri, 23 Jul 2021 14:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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 HE8B76ra7wSf for ; Fri, 23 Jul 2021 14:04:28 -0700 (PDT)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 4AD853A195C for ; Fri, 23 Jul 2021 14:04:28 -0700 (PDT)
Received: by mail-pj1-x1031.google.com with SMTP id p5-20020a17090a8685b029015d1a9a6f1aso7210614pjn.1 for ; Fri, 23 Jul 2021 14:04:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=N9JGZlxg0m3g17mRF8uE6jzp7R5nQ0MN84V07jnTjxM=; b=MFW61MRp4S5eNYBYIL3fFF1OfnAbBtpE29Z/pAxX41mwWbP682q7JWvsMx3OAf+X/X s1iXsDa9GiRTaLpZaGyuobMGwWqkyLnB3nJcONZjpY1O62wFObGh4qvtRp3gQMiNcASq 2yldRMYriWH/0lbFgLJD1yl/vQBExQbekPJp7dKXAogwrk1lqJoTbWDLvRIev3l4BTgX JC6sgNWmuGf2JExvyB5jtJxCFjKMvmPGWSyeQUAIY1U0a0DZdEtqFv8gJKWU2I22gdm4 sBJmo+HKQV133pzBMZ3vksJLQRADMj0TsInWEhyMQrABY34nrnD31X49mGCltVHRe/ww UZOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=N9JGZlxg0m3g17mRF8uE6jzp7R5nQ0MN84V07jnTjxM=; b=pvn5DnyatdFFmDoQttpqBY5OxgkvEpsrPAAev8ys9Op7RMCtKKhJ1dtTl3RCFpY02X SSCylihJlUH/dAfaz+JcN4gnTXjoa6g/whz1E3/TRDOf/4woeUhyW7Ds3jUzhQlVZvom MwCK8juF0HMD9/9JDbhg9k1TTR6undz1QDOSokSvFY8z/fJ48/sv59kvGYDvA7J7HJTZ HPqo6L6TpQyG1QcwWn49xcCe+jqdDdJnZiwNMv2q0QYEYyaWl9+siUGM0gRcUjhYkkpP DXZAh+h9yC5/p/J/lFQEMOR+YR1B3+HyyJ1JS+tMQwMmJJj2L+4qSZf48pje/jvtvqX3 2Wmw==
X-Gm-Message-State: AOAM532PoHYo5tKWMZBHKloKmOamPlG6RvbaS/CpeN8P60SCbtV3O9Zg 7IXYwQrYVjcmpukZGWumcMgfrO3nigeLHA==
X-Google-Smtp-Source: ABdhPJyn6eu1EaxDn0/0gm//kDEoi08XiDHhMqbAJwhzkur6uGa4jA5nBHqIQHWRPYFKCKI98EW6Ig==
X-Received: by 2002:a63:5652:: with SMTP id g18mr6573421pgm.178.1627074267036;  Fri, 23 Jul 2021 14:04:27 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id pj3sm28244837pjb.35.2021.07.23.14.04.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jul 2021 14:04:26 -0700 (PDT)
To: Peter Saint-Andre , Lars Eggert 
Cc: "rfced-future@iab.org" 
References:  <50112B7E-0C1F-4F47-B4AA-F6A217592EBA@eggert.org> <959d8df0-c16a-2d0b-e424-1b4083784631@mozilla.com> <7d2c3ff2-ffba-7696-e486-774547519419@gmail.com> <1DA0FDC7-35F1-4594-B7C6-0670DCC53C85@akamai.com> <12dfdb23-6c06-029b-8d57-ad0e938ecf4b@lear.ch> <44B7496C-CEC0-4F5C-81C0-A68512D3B3B8@mnot.net>   <0cf65e47-419b-163b-acb8-2d72e3936f83@mozilla.com>
From: Brian E Carpenter 
Message-ID: <37de633e-6706-d516-5774-740e47c123a2@gmail.com>
Date: Sat, 24 Jul 2021 09:04:22 +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: <0cf65e47-419b-163b-acb8-2d72e3936f83@mozilla.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Responsibilities for the rfc-editor.org web site
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jul 2021 21:04:33 -0000

On 24-Jul-21 04:46, Peter Saint-Andre wrote:
> On 7/23/21 12:56 AM, Lars Eggert wrote:
>> Hi,
>>
>> On 2021-7-23, at 3:12, Jay Daley  wrote:
>>> Yes.  When it comes to that I=E2=80=99ll be inclined to Mike=E2=80=99=
s view that we don=E2=80=99t want to overdo it with RFCs at inappropriate=20
levels of detail but the general ability for the RSWG to agree a controll=
ing RFC is fine by me (it=E2=80=99s how almost everything else works afte=
r all).
>>
>> so would that mean that RFC8728 remains in effect, and the responsibil=
ities for the website remain with the (now) RSCE and the RFC Publisher?
>=20
> For what it's worth, the current program I-D does state:
>=20
>    Matters on which the RSEA might be consulted could include proposed
>    changes to the RFC style guide [RFC7322], RFC formatting in general,=

>    web presence, copyright matters, archiving policy, and dissemination=

>    and cataloguing of RFCs.
>=20
> That, however, does not assign *responsibility* for the web site.
>=20
>> Or would we update that to (say) a model where the RSAB takes over the=20
website responsibilities the RSE had under RFC8728, and the LLC may decid=
e to take on the RFC Publisher responsibilities and likely manage them al=
ongside our other web properties?
>=20
> That seems like a reasonable starting point.

I disagree. The specific text in 8728 is that the RFC Series Editor "Is r=
esponsible for the content of the rfc-editor.org web site..." and I think=20
it would be unreasonable to pass that responsibility to a committee. I wo=
uld certainly expect the RSWG and the RSAB to take a strong interest in t=
he web site and even to make recommendations, but responsibility for the =
content is an executive job, not a committee job. I think it has to lie w=
ith the RPC.

   Brian


From nobody Sat Jul 24 05:37:26 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12653A3974 for ; Sat, 24 Jul 2021 05:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level: 
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLaoxclarYOZ for ; Sat, 24 Jul 2021 05:37:19 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 3D1BC3A396F for ; Sat, 24 Jul 2021 05:37:18 -0700 (PDT)
Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:94ed:db84:a751:2784]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16OCbCV1003435 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 24 Jul 2021 14:37:13 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627130235; bh=QkDhxf9COoRh0YXR8khkPv81V+DDx42z2UwkzliK5P4=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=bkfYjTeMyAI3ml/STDjACXQrUUimKxZ4AG2tCKtgcmKCrog+2+WXmF8VeJ72ccaC8 R81nSo7WlD6bz+QU1J7zZhaDIH1g38vgLZluRFVO1Yqlkw7wokewyRD/c9iI3AxViN 8qb/l6r3t967ryRbb6asSq5/7qnC1ol22JZ011ys=
To: Peter Saint-Andre , "Joel M. Halpern" , Eric Rescorla 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>  <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com> <2b413a40-097a-da24-db94-08be3d216701@lear.ch> <7352fb2f-7ef5-e8b7-8ca2-29c79ffc4133@mozilla.com>
From: Eliot Lear 
Message-ID: <9fea92ab-f1af-5864-899a-f37391ed162a@lear.ch>
Date: Sat, 24 Jul 2021 14:37:11 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <7352fb2f-7ef5-e8b7-8ca2-29c79ffc4133@mozilla.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XxDqAkHTRcfHyZFsqW2JAmIOcf1XZTFyh"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jul 2021 12:37:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--XxDqAkHTRcfHyZFsqW2JAmIOcf1XZTFyh
Content-Type: multipart/mixed; boundary="sI9Dl2drR0TVG5cKkVD9ZrUZb81tPhRPQ";
 protected-headers="v1"
From: Eliot Lear 
To: Peter Saint-Andre ,
 "Joel M. Halpern" , Eric Rescorla 
Cc: rfced-future@iab.org
Message-ID: <9fea92ab-f1af-5864-899a-f37391ed162a@lear.ch>
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch>
 
 <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>
 
 
 <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>
 
 <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>
 
 
 <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com>
 <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>
 
 <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>
 
 <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com>
 <2b413a40-097a-da24-db94-08be3d216701@lear.ch>
 <7352fb2f-7ef5-e8b7-8ca2-29c79ffc4133@mozilla.com>
In-Reply-To: <7352fb2f-7ef5-e8b7-8ca2-29c79ffc4133@mozilla.com>

--sI9Dl2drR0TVG5cKkVD9ZrUZb81tPhRPQ
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Peter,

On 23.07.21 14:38, Peter Saint-Andre wrote:
>
> Our I-D currently states:
>
>     It is the responsibility of the chairs to encourage rough consensus=

>     within the RSWG and to follow that consensus in their decision
>     making, for instance regarding advancement of proposals to the RSAB=
=2E
>
> and
>
>     The RFC Series Approval Board (RSAB) shall act as the approving bod=
y
>     for proposals generated within the RSWG.  The sole function of RSAB=

>     is to review policy proposals generated by the RSWG; it shall have =
no
>     independent authority to formulate policy on its own.  It is expect=
ed
>     that the RSAB will respect the rough consensus of the RSWG wherever=

>     possible, without ceding its review function.
>
> Does that address the issue?

I'll ask others to consider this as well.=C2=A0 We have to be careful not=
 to=20
over-legislate.=C2=A0 I would slightly amend the above text by taking out=
 the=20
words "It is expected that".=C2=A0 If we're stating it in the draft, it i=
s=20
indeed already expected ;-)

Eliot



--sI9Dl2drR0TVG5cKkVD9ZrUZb81tPhRPQ--

--XxDqAkHTRcfHyZFsqW2JAmIOcf1XZTFyh
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmD8CXcFAwAAAAAACgkQh7ZrRtnSejPE
Rgf/ekUQSZ/iG+4f0X82lwo6pwAFp14tsvQupAPQVz9MbwnFTxkg6Sn3gj6DXQ1BU25i0RSc4RCU
ZPM7O9/ALcvnwYOhUzBDI9ZIZIXJ+ejmd+mepd8evg18Du3PD24A6q1TRnmv0ovvWhFyKt/y7nki
X1B/srSROybbjS7L+druFCt2mjFfuxnwkO0n1T6cIjwkgfIQykihNtPxh9QRD86l20em67W+yHhh
W165KMQ8LdzlmEWuwlL9NJsy1aK/KkGYON8qGTf4kEVXULpCAUvF7yrUZ8GxOiQGb/Tl3Bny8EUd
RNVJeUYeXC1kuGGf00Ae/STLxaJ+6qoEv2SdamQjfw==
=RomV
-----END PGP SIGNATURE-----

--XxDqAkHTRcfHyZFsqW2JAmIOcf1XZTFyh--


From nobody Sat Jul 24 14:00:06 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1A23A0BB6 for ; Sat, 24 Jul 2021 14:00:05 -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 DXZ6AiaC8NuM for ; Sat, 24 Jul 2021 14:00:02 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 2B9EE3A0BB3 for ; Sat, 24 Jul 2021 14:00:02 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id u8so7317068plr.1 for ; Sat, 24 Jul 2021 14:00:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KdDPOzo6dLOZHDY4nOGCtiVWBpTa/QoTEVjR/Y6Dbp0=; b=oVxbA+ZqZ6E7Nz7WCT9Nenm2qdcVROgulngT67OGdomWNutG3ClSM8DbkhA7hRGFe+ /2UdLtQOQfUq8epdIjb5eNQ3wm6wRU40yyk+yaf2X8/MQqTOCUe3lkmuyKIuwkprS/qT Ii/Mt81KMPgwKMKZd71xRPexsnBMW9rcpykk+6dM44mVSH+KRgNw3kwDGgf9c9u28M+N NcoTlRt2ewYY4KzszlQqn5L2bEWf0UkY8cTOunXk4DCd3Wj7sOA33BvDopeDHrgwo7+h kBtGBJl4m0tDYJyU2YW9zc4D4Ol8bca0dE7AgsCh+InwXH3qzyfsE9S0cDmwCdRBIMZL TgTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KdDPOzo6dLOZHDY4nOGCtiVWBpTa/QoTEVjR/Y6Dbp0=; b=cL5E046n3Mme1gXJIACfnjxqItGHefSf/cuPZ/etXDNDeBZzYdrTnjeDUqbCPmQfhT QIa1UB+CCALkXqAlRcp48+j/yOWKlFzhZUK+WYr0kpS5jK5m0skJ43FRv9NEkbnjxHNO yC7ACrI3F5RFlhlPyH1tSgOWwek4/aX/WJvmLXnwKTnkKBEXZ+PqC85U9ojrQuO7A12X F2gnF4Y59E99Zh2h0uqiDeXyzWMyMjqaiYCbHWdfDSsMhQvNd6b90v0lugCSVOEzoX6/ n0SOXcKBvMLPnOQiyLF+0yQelI/j7Zw2xAUxzt5nB9HpbUrnpxhjKnScdKKd8o3VnQmI gdag==
X-Gm-Message-State: AOAM532Et8iMfCT6GtkSknhjtXfv8wf14UARmhKPGJITidus1EzmHQ65 Mifwo398HGqIv/dJr6h5R7Acc+Pmc5L0bA==
X-Google-Smtp-Source: ABdhPJzJrKPbpBCSjJxsgQ3yBbTyWQAYGqiGyfoOSvaDzFwJH78nU3tMdM5A+/hUHcJdTVu+W/7EkQ==
X-Received: by 2002:a17:902:e752:b029:12b:8ae3:e9e9 with SMTP id p18-20020a170902e752b029012b8ae3e9e9mr8528718plf.33.1627160400451;  Sat, 24 Jul 2021 14:00:00 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id 201sm17767953pgd.37.2021.07.24.13.59.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jul 2021 13:59:59 -0700 (PDT)
To: Eliot Lear , Peter Saint-Andre , "Joel M. Halpern" , Eric Rescorla 
Cc: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch>   <1f8bdacb-c6e1-ed04-4826-76e35524658f@joelhalpern.com>  <191d5d1d-095a-0b60-6f63-af08bd35569d@joelhalpern.com>   <2e207a59-dcbc-c5c9-a89b-031a00fc6980@gmail.com> <14f80a3e-706b-e1ad-17ff-ba4ffcc4d55a@nthpermutation.com>  <2571b6a5-3fa1-1be2-a4ad-ee644c6a9ed1@joelhalpern.com>  <0891825a-7ef3-ba2d-36e1-77aa6f8c7eb5@joelhalpern.com> <2b413a40-097a-da24-db94-08be3d216701@lear.ch> <7352fb2f-7ef5-e8b7-8ca2-29c79ffc4133@mozilla.com> <9fea92ab-f1af-5864-899a-f37391ed162a@lear.ch>
From: Brian E Carpenter 
Message-ID: <15a7a857-790b-66d8-25ec-d327b62cf94e@gmail.com>
Date: Sun, 25 Jul 2021 08:59:55 +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: <9fea92ab-f1af-5864-899a-f37391ed162a@lear.ch>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jul 2021 21:00:05 -0000

On 25-Jul-21 00:37, Eliot Lear wrote:
> Hi Peter,
>=20
> On 23.07.21 14:38, Peter Saint-Andre wrote:
>>
>> Our I-D currently states:
>>
>>     It is the responsibility of the chairs to encourage rough consensu=
s
>>     within the RSWG and to follow that consensus in their decision
>>     making, for instance regarding advancement of proposals to the RSA=
B.
>>
>> and
>>
>>     The RFC Series Approval Board (RSAB) shall act as the approving bo=
dy
>>     for proposals generated within the RSWG.  The sole function of RSA=
B
>>     is to review policy proposals generated by the RSWG; it shall have=20
no
>>     independent authority to formulate policy on its own.  It is expec=
ted
>>     that the RSAB will respect the rough consensus of the RSWG whereve=
r
>>     possible, without ceding its review function.
>>
>> Does that address the issue?
>=20
> I'll ask others to consider this as well.=C2=A0 We have to be careful n=
ot to=20
> over-legislate.=C2=A0 I would slightly amend the above text by taking o=
ut the=20
> words "It is expected that".=C2=A0 If we're stating it in the draft, it=20
is=20
> indeed already expected ;-)

I support the text, with or without Eliot's tweak. It makes it clear that=

the RSAB is not an executive body.

    Brian


From nobody Sat Jul 24 14:10:47 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9023A0C5B for ; Sat, 24 Jul 2021 14:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 4a28aWGo7nDB for ; Sat, 24 Jul 2021 14:10:40 -0700 (PDT)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 8629B3A0C59 for ; Sat, 24 Jul 2021 14:10:40 -0700 (PDT)
Received: by mail-pj1-x1034.google.com with SMTP id q17-20020a17090a2e11b02901757deaf2c8so8832239pjd.0 for ; Sat, 24 Jul 2021 14:10:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=T/AT/VCMsaedCOTyJqZ/Zxm56PVWj2jPGROeZNwaLhA=; b=qbIH+bk/rv737gJhkWu9cUU0rHPaYLW9+0NnOyMleduVTp6gfCGpS/M19xl3XsH2lD GX3VKQDU1orjh9tkePJxjgBPCoBdKUBJv8rGcM3XHiuyC7tw+QC2EjDSS8im7hgQNgI6 2yTO7PVVOyUTq6w5HXOju8nJZ2cWelLKMOze2nZCiNi+Lq4GQnxcuaw0kb+MDmofo6SP RNkxGdNBS8n+j93XaxdLEhaPeqHJlDgfNA8qbbYRHFqWL/KZPGioLKsaDftrFJYFESXn rr5x2AXBletOaInXuw79TOn6beOmUVK6OMGemnlVR9xrj1EDAsuSjv+Z6Acs/dHpJFZy bOAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=T/AT/VCMsaedCOTyJqZ/Zxm56PVWj2jPGROeZNwaLhA=; b=hGECfSzMYSaBdZlNDg+C500Rc58b0ZmR/8VfGNc1TctoySQg+MKK6yEmougIPnpUEj GFjC2HddeSUSSxV2JOLTQ9Vu50aXrlkncQQH6XjJF3jRMmslhxHq2YrLxbpt4twB5mxU DH/LOMXGEU37hugXL5QUFZusQGl2V2+Me4yY/8G6koagmYbUEM4whxMwjYiOnDaWHV+t 8Yt30AdLVLcwQSn0f0G0MQ3lik3oxUitSA9i2p3tEY7b3Eie0eAqUYA+KJB0kY5B4X1s It7AHAU3H04ee4k1r80buX8BVtITt7o12Ruojo75ZE2A4lMV/o0+BPi/loi/LaI2t8S0 VCvQ==
X-Gm-Message-State: AOAM530+I3/ZqouTYxKpT33RZjXTmklSlYerOwk9rEo7fx9sG7JaPFvn mYWRZEEcMAvPOYIodaxLl4tuJEnp3vHnMw==
X-Google-Smtp-Source: ABdhPJwH0aHhSNujSlEj2DUV2bewBqJCglc9+/1y30P7DtxMpB84ZWf+YcAdBfJ7J+SzsFpHvR/HXw==
X-Received: by 2002:a05:6a00:10cd:b029:30a:ea3a:4acf with SMTP id d13-20020a056a0010cdb029030aea3a4acfmr11029246pfu.51.1627161039449;  Sat, 24 Jul 2021 14:10:39 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id c204sm23919122pfb.90.2021.07.24.14.10.37 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jul 2021 14:10:38 -0700 (PDT)
To: rfced-future@iab.org
From: Brian E Carpenter 
Message-ID: 
Date: Sun, 25 Jul 2021 09:10:35 +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
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Rfced-future] Possible new issue: community review of performance
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jul 2021 21:10:45 -0000

At the moment, draft-iab-rfcefdp-rfced-model-00, section 5.1 "Roles and Processes", says:

   Community members who have concerns about the performance of the RPC
   can request that the IETF LLC look into the matter.  Even if the IETF
   LLC opts to delegate this activity, concerns should be raised with
   the IETF LLC.  The IETF LLC is ultimately responsible to the
   community via the mechanisms outlined in its charter.

Should we tweak that to say something about the RSWG/RSAB acting for the community in this respect? Should we even require a periodic review of RPC performance by the RSWG/RSAB on behalf of the community? I don't mean to undercut the LLC's normal role of overseeing execution, but the customer is always right. 

Regards
   Brian Carpenter


From nobody Sat Jul 24 14:37:33 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2023A0D9B for ; Sat, 24 Jul 2021 14:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyAiftunbu-F for ; Sat, 24 Jul 2021 14:37:30 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B68B3A0D9A for ; Sat, 24 Jul 2021 14:37:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E7198300B96 for ; Sat, 24 Jul 2021 17:37:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RqEo4_42xpEZ for ; Sat, 24 Jul 2021 17:37:28 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id A31803004A7; Sat, 24 Jul 2021 17:37:28 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley 
In-Reply-To: 
Date: Sat, 24 Jul 2021 17:37:27 -0400
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <208E811B-2EF1-4927-B6B6-2E34704D0540@vigilsec.com>
References: 
To: Brian Carpenter 
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: 
Subject: Re: [Rfced-future] Possible new issue: community review of performance
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jul 2021 21:37:33 -0000

> At the moment, draft-iab-rfcefdp-rfced-model-00, section 5.1 "Roles =
and Processes", says:
>=20
>   Community members who have concerns about the performance of the RPC
>   can request that the IETF LLC look into the matter.  Even if the =
IETF
>   LLC opts to delegate this activity, concerns should be raised with
>   the IETF LLC.  The IETF LLC is ultimately responsible to the
>   community via the mechanisms outlined in its charter.
>=20
> Should we tweak that to say something about the RSWG/RSAB acting for =
the community in this respect? Should we even require a periodic review =
of RPC performance by the RSWG/RSAB on behalf of the community? I don't =
mean to undercut the LLC's normal role of overseeing execution, but the =
customer is always right.=20

At the same time, the IETF LLC is clearly responsible for the contract =
and the budget, so they cannot be omitted from the process.

Russ


From nobody Sat Jul 24 19:17:52 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E300C3A0E83 for ; Sat, 24 Jul 2021 19:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPT4DiYcq8Vc for ; Sat, 24 Jul 2021 19:17:48 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 67F6C3A0E82 for ; Sat, 24 Jul 2021 19:17:48 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id d17so7560930plh.10 for ; Sat, 24 Jul 2021 19:17:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=K+H6A0Zn0IRG0I+iKKnQBt1OUbzRotLervqrrEhbN2c=; b=A9mDfD7vHEF988EOcszNalg64zSVt+BV+G2NeS/KSoE08/pibHRy/EkFAgOgp8vROc raiF0FTWdpJK81+LXEdOdA5FmVfa3IhexRO//BalOFEEYj2zIX6Xy3JwkY4GxKqQSk+U jBo+dxa9e6wCMkm7+Njx0HF+Y6Vw4oBrjXr1JWvEqDDLIsWT/IPGU1Y+124SCzttFnf0 9u/pgAfZVZA8H0uMNaURRwBR+q/GRTFBKtyMue+D+IIF50xv+I3i2bcmIouAD3G9C2Ll UPWf+rwmQiXtLFr7sa9AGw6kg2qizzkDIswUuT8woIYVaPRSDk92KMKZ1jWGclFo3Faq 1jQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=K+H6A0Zn0IRG0I+iKKnQBt1OUbzRotLervqrrEhbN2c=; b=rAr3tkv3Yut8duR/1H/317kKOa4gLdOzzuavPCZOP53mxrf/ecGNzjgG2LatnIgjbK YDPpKspTGokWS1gY6Z0jWE1lnuJlKbvG7pCZIKi8xhE+FbPapv4gW00XpFKnzk27ddjP UBbVn+YXEgkAVs9A+Omcun7+JqlsCN+joFLNzVuRWWCTPd0DqeBc86UQ12vW0KIIN2XF FpKAQZqnZy0viAZF9qjcRvZ/DmmILlA4KVawLWO5HeEmH5MYqIddMUW+haweM5MpRZCF HvGkEoa+XUGo9EX/kBWpQIl2RA1TCedOZRHpKJtZoEAXHgwyYEuJrjzXzbliTVR+u162 JpyA==
X-Gm-Message-State: AOAM531v2ZcTqE7gcnG/kDS7RwuUqzH9kMmhR4H7TQLT16qboGmIP++j WP95l8x8ySv9R4BL9rnLwiCrIqfYNl1+GA==
X-Google-Smtp-Source: ABdhPJyLZRKTjxqDDVc7TQx2RA437x/5zVyZFfcgkRBrowhH3u4pNKubNF2ntX3MdM3SHqEEedYJRw==
X-Received: by 2002:aa7:85cc:0:b029:359:7d78:bc4c with SMTP id z12-20020aa785cc0000b02903597d78bc4cmr11545404pfn.6.1627179467140;  Sat, 24 Jul 2021 19:17:47 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id c2sm43301738pgh.82.2021.07.24.19.17.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jul 2021 19:17:46 -0700 (PDT)
To: Russ Housley 
Cc: rfced-future@iab.org
References:  <208E811B-2EF1-4927-B6B6-2E34704D0540@vigilsec.com>
From: Brian E Carpenter 
Message-ID: <9e87842b-249c-9670-1202-d7063b766200@gmail.com>
Date: Sun, 25 Jul 2021 14:17:44 +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: <208E811B-2EF1-4927-B6B6-2E34704D0540@vigilsec.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Possible new issue: community review of performance
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jul 2021 02:17:50 -0000

On 25-Jul-21 09:37, Russ Housley wrote:
> 
>> At the moment, draft-iab-rfcefdp-rfced-model-00, section 5.1 "Roles and Processes", says:
>>
>>   Community members who have concerns about the performance of the RPC
>>   can request that the IETF LLC look into the matter.  Even if the IETF
>>   LLC opts to delegate this activity, concerns should be raised with
>>   the IETF LLC.  The IETF LLC is ultimately responsible to the
>>   community via the mechanisms outlined in its charter.
>>
>> Should we tweak that to say something about the RSWG/RSAB acting for the community in this respect? Should we even require a periodic review of RPC performance by the RSWG/RSAB on behalf of the community? I don't mean to undercut the LLC's normal role of overseeing execution, but the customer is always right. 
> 
> At the same time, the IETF LLC is clearly responsible for the contract and the budget, so they cannot be omitted from the process.

I completely agree.

   Brian


From nobody Sat Jul 24 21:44:03 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CB03A149D for ; Sat, 24 Jul 2021 21:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 Umj8ipkN2uV4 for ; Sat, 24 Jul 2021 21:43:58 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE6E3A149B for ; Sat, 24 Jul 2021 21:43:58 -0700 (PDT)
Received: from xse296.mail2web.com ([66.113.197.42] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1m7VzW-000ej7-De for rfced-future@iab.org; Sun, 25 Jul 2021 06:43:56 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4GXVnL14pLzx3m for ; Sat, 24 Jul 2021 21:43:50 -0700 (PDT)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1m7VzS-0006u5-0l for rfced-future@iab.org; Sat, 24 Jul 2021 21:43:50 -0700
Received: (qmail 28397 invoked from network); 25 Jul 2021 04:43:49 -0000
Received: from unknown (HELO [172.20.1.225]) (Authenticated-user:_huitema@huitema.net@[63.64.30.197]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Jul 2021 04:43:48 -0000
To: Brian E Carpenter , rfced-future@iab.org
References: 
From: Christian Huitema 
Message-ID: 
Date: Sat, 24 Jul 2021 21:43:46 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: 66.113.197.42
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/KhO6 GkmYzwPjca0u1wzomRGrAP5R/Cae/ZemygD++WnmSxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLV0XgtlP1veEWDxFjeo42e2HGFd932lfz+R/06O3Iy4akhy/LP m2rFgOGYwKKX1POmkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkMemT4rxn nByU11Ftkqf3f/PF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7Iiihnln5nLwsYugixy853dgjI4WE+pjPnfrWRF8b8VMfm 7BGJCK0BLjCRITLsnakub3UQT3xbkHqpqmyCe4PiKVv0wNAmy0z4NCWU5AbBg6tDVPQ6fMev1BMP vQ9qu4cW0z6bhalFEM/pjPCQA+BAlswsG1avZtxeejugO7z5zwW3h1ESmlc3/lS5x7qxkdlaMrpL rN5LWyhZGgsjQ9bS2KoTXhO3LaL8Ezgy5rSGUYhRXxKF5tPxTxfD0dMN+t5Z6y4Lb2l01k9i+izv QyQq1voPFZIShBSdpVJW5HbjQTCUIzbw71BPKv8cPtVshTSLr6YHJu91A3avrF49rf9JcoEpejCA XczArXyV+OFXiMtbLPp9n350Mbemie5JWWm/MpxAyl4q1x5O0+PBD/gPmWjXVA9S7TnWXDlmMpVd cwCFwrnT0GQK/7labXRdXAB+MS+4ayUpOtEhdxekWDmK9g==
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: 
Subject: Re: [Rfced-future] Possible new issue: community review of performance
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jul 2021 04:44:01 -0000

On 7/24/2021 2:10 PM, Brian E Carpenter wrote:
> At the moment, draft-iab-rfcefdp-rfced-model-00, section 5.1 "Roles and Processes", says:
>
>     Community members who have concerns about the performance of the RPC
>     can request that the IETF LLC look into the matter.  Even if the IETF
>     LLC opts to delegate this activity, concerns should be raised with
>     the IETF LLC.  The IETF LLC is ultimately responsible to the
>     community via the mechanisms outlined in its charter.
>
> Should we tweak that to say something about the RSWG/RSAB acting for the community in this respect? Should we even require a periodic review of RPC performance by the RSWG/RSAB on behalf of the community? I don't mean to undercut the LLC's normal role of overseeing execution, but the customer is always right.

I think that would be a bad idea. It would just ceate confusion, by 
hinting that the RSAB/RSWG might be responsible of checking the RPC 
performance, instead of keeping that responsibility squarely with the LLC.

-- Christian Huitema


From nobody Sat Jul 24 22:15:10 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4E93A15C3 for ; Sat, 24 Jul 2021 22:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWIhVErTdRsb for ; Sat, 24 Jul 2021 22:15:01 -0700 (PDT)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 C355D3A15C2 for ; Sat, 24 Jul 2021 22:15:01 -0700 (PDT)
Received: by mail-pl1-x62c.google.com with SMTP id a20so8078894plm.0 for ; Sat, 24 Jul 2021 22:15:01 -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=OdubR67y9NeSX3C/C7CRVHiVGcyyvMWvHP7QhUpn+74=; b=gHtl6Kg8Ulxthg275hlG8DHlMjwEBANF4JYMOpU2cImAaQy6CRuqTURDB9+BGuxh84 sSMrBGv4RUuj4Wl9ia3EJhr6G0wNd6Gw3BqwtZeyScJ82VAE3pD0yvxTXqgiflyI8U5e X68DOYh3ET1YDOOQEVq1vUdFlw8qx73MHsRkLVVhUmhX6n2oFSpbLqchzzgCyJxqBxBK W6VmncI4FsDZBBIASeNtrWqQCKI9G3vrXmygyaWFfpRyY2H9xNBOO1XVNirqblYHDfXZ v8oMHZFMH2ixWJNABOQXJg0UdOVGaPkZ9KDEjEv+EEAZ+vAWDOMYiB15XLXch/4Hwh4s KTng==
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=OdubR67y9NeSX3C/C7CRVHiVGcyyvMWvHP7QhUpn+74=; b=omDUw3Um+zqSb6pBQ+RtDU9xOLGGE3pv4V4b+/0rogX30bOzL9vmVDwku1tC/TvB+P TIrdO3Z1i3gTODUzWUIznZA71Fd7TLwCHmEhWZtnDLhlLGLRwQSwP2L19QcI3lGqe4ly RWmtt9a0NUtk1u85jUdc3pceVpDUKndoq0N7uZuld/PGoy3TFzgt7yvqEXcC7c/3gRDE TtFO3/6EJX1bHjsAIeBXCixE7HdXWPlUpTj6XRpujTWUfIulONuQPjZeOcanu9DInHpw vbjyV5IdMDDhUE8HVMw6nhqV93CmySDMvbQ3Uqmxfm5ZCFONC+VQyOXkm908phpYyH94 OYIg==
X-Gm-Message-State: AOAM5315Bxs+XaV1Hx2pRnYOE9SgZGOp0cwDN6WCA00MEIB7mxd+rl5j Y9pqzMqdpdXgN+wKo2t1ZWaiNpLIU7dAyQ==
X-Google-Smtp-Source: ABdhPJwu2m6sMWE9A/COpgoWc9gMu1CPgtfSguTqzCFZe8YZGVTp6h5gP9kTdmPWd++8hejlLYOBhg==
X-Received: by 2002:a63:fc06:: with SMTP id j6mr12166360pgi.193.1627190100130;  Sat, 24 Jul 2021 22:15:00 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id k198sm40679764pfd.148.2021.07.24.22.14.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jul 2021 22:14:59 -0700 (PDT)
To: Christian Huitema , rfced-future@iab.org
References:  
From: Brian E Carpenter 
Message-ID: 
Date: Sun, 25 Jul 2021 17:14:56 +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: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Possible new issue: community review of performance
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jul 2021 05:15:08 -0000

On 25-Jul-21 16:43, Christian Huitema wrote:
> 
> On 7/24/2021 2:10 PM, Brian E Carpenter wrote:
>> At the moment, draft-iab-rfcefdp-rfced-model-00, section 5.1 "Roles and Processes", says:
>>
>>     Community members who have concerns about the performance of the RPC
>>     can request that the IETF LLC look into the matter.  Even if the IETF
>>     LLC opts to delegate this activity, concerns should be raised with
>>     the IETF LLC.  The IETF LLC is ultimately responsible to the
>>     community via the mechanisms outlined in its charter.
>>
>> Should we tweak that to say something about the RSWG/RSAB acting for the community in this respect? Should we even require a periodic review of RPC performance by the RSWG/RSAB on behalf of the community? I don't mean to undercut the LLC's normal role of overseeing execution, but the customer is always right.
> 
> I think that would be a bad idea. It would just ceate confusion, by 
> hinting that the RSAB/RSWG might be responsible of checking the RPC 
> performance, instead of keeping that responsibility squarely with the LLC.
I wouldn't attempt to dilute that responsibility. It just seems strange
to me that we have words about "community members" raising concerns
and yet we don't include the RSWG/RSAB which is our proxy for
the community.

Let me wordsmith:

If community members, including the RSWG and RSAB, have concerns about the performance of the RPC, they can request that the IETF LLC look into the matter.

   Brian
 


From nobody Sun Jul 25 18:11:08 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F613A1229 for ; Sun, 25 Jul 2021 18:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level: 
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=z6r1CUHV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oy20ssfP
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR1GHhBYUxmF for ; Sun, 25 Jul 2021 18:11:02 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2F73A1223 for ; Sun, 25 Jul 2021 18:11:02 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 45ED8320024A for ; Sun, 25 Jul 2021 21:11:01 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Sun, 25 Jul 2021 21:11:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=oa2gve8SXlVahhlqWUdXhicDYYufSwn 1WXLE6Wac3PY=; b=z6r1CUHVvh8SLFWJ+NsFGCVEbk5xWFu2UDdMeIStKuLOdm3 F4vvnr3iwpA2C0Sf+PR+9SGjRu0EoE5QAXDzEIJ4NSy3Nb5RdrRsng3Qc5rxDoQA XmaJ+MjH9FqOdKbI7xQC5XAljZ1wk9zyKVcogWnsTujRX5VoW0HV0cdgI07c0ed/ kDyKdX1E4fj6PMykcDckOxgYri2gvkM+zIxz3COgTXMnYuYMGjrJxPI2SEZTnP2c akVwW8+jX7EbbgTbxWJKCeS12lU5xkzt4VW2/wA42dI0tkHtJQWgLiwbWv7eOtcl 634M4cacDanVrQe4WvfLe8d6CrROZwc41YyBIXA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=oa2gve 8SXlVahhlqWUdXhicDYYufSwn1WXLE6Wac3PY=; b=oy20ssfPIAtYogAzzQ/4jP +Vds6sDaBT5R7wBrHHmi9RVoc236hsqXlDJ/JGg3RlZSs7aN+IPHAU6+VlEMaw4N Emy+pKGx63s9qAHmmsfoMA+pGsxf9g/HA8s8K+9XGe/gkLqycbA7oITGORoIzB2L Xdfdx82/0lWy2DuEVeh1vZsOB7RysF5NrIe1y4b8lqMr9s++nYS7x36LhMy2ZP8y aI69bxTKGcnhhGGm7kgtM/vIVWqzky3szFlc6p1XYK6AcxNDORszOa/mOT4h5cGW RGYx4Anv2Rpd5ZUmZxv7A9WHURJI+xWCZ9VsfQAVqB8+xD48xgLAwtH/ub9BVHMw ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeeggdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepheefteduudduhedtkefhvd fhteelffdujeegjeffheffveekudeigfeuveekfeelnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 88B163C0471; Sun, 25 Jul 2021 21:11:00 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-540-g21c5be8f1e-fm-20210722.001-g21c5be8f
Mime-Version: 1.0
Message-Id: <5e9559ea-13c4-4ba2-93b8-65ef7e20c54a@www.fastmail.com>
In-Reply-To: 
References:   
Date: Mon, 26 Jul 2021 11:10:41 +1000
From: "Martin Thomson" 
To: rfced-future@iab.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [Rfced-future]  =?utf-8?q?Possible_new_issue=3A_community_review_?= =?utf-8?q?of_performance?=
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jul 2021 01:11:07 -0000

On Sun, Jul 25, 2021, at 15:14, Brian E Carpenter wrote:
> If community members, including the RSWG and RSAB, have concerns about 
> the performance of the RPC, they can request that the IETF LLC look 
> into the matter.

I have no strong objection to the sentiment, but isn't this a non-statement?  Or is your intent to make it clear that RSxx are absolutely not authoritative in this regard?  (Just trying to avoid over-specification.)


From nobody Sun Jul 25 19:09:54 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7CA3A145D for ; Sun, 25 Jul 2021 19:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F16iAF7nSL2p for ; Sun, 25 Jul 2021 19:09:51 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD293A145C for ; Sun, 25 Jul 2021 19:09:50 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id i10so6711354pla.3 for ; Sun, 25 Jul 2021 19:09:50 -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=rHN2XLaUjo/TZJKlyKegtpozkR3Zl4BCuxDve/JAxj0=; b=KCUhvNp72EK2IqfO8sJVjWtZB1ta++X/7ZIovCojp8he6xW57l+MsX8xPEeKqHfRt2 bHkfNyuv6Myokf+mOxhRGbuWE1Un9RNHS54Ryq3XynptRhYgSJvlSFldfRwkVw3u1F49 9YcGVmq+3xTlb7qwDIpvsTPyVCUUMOJYhFNFpAsRpRbjOPlImvGlI/WMqUQ3LMVx2Gey OQlyyUhwSWO+TiUe9wFbkDCSfboTT5eBGTtY7kW2kx0Wo2E17xiswaLzs8UW0BJ4hsmI /5nX8Tg72J+SW+NuKKTT+jse8yZk+bXEVGayT6crdWi0yo2r3zUuz7u7dSbx7M5CBWe1 GAjg==
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=rHN2XLaUjo/TZJKlyKegtpozkR3Zl4BCuxDve/JAxj0=; b=JS6RkMFYeo1OLyED0k8EIMy0ln4IivHP6pFbaMtJ1PdHWWT+oswjZE0SmKhLSxMHnr unvkB4RBnUA+tzwWg9OiW9Xk1h4ChMEx2U2KLMYqZ0Vhuy2OY8JoaoOjHwhchIQLwdeC ZIEJnjSlzXwCI0dvv2Wtxxa7acn6rcwHn5GTCnp/TgIta0JQzpGQr6+FZtryAzA8PYrZ Rx+cbFDm4ovYeLZoxwdhYoMVJl6jRTsnPZAn+fIcP3hfNXnJXCix+HYSashBd+AJBS4D jPEum3GWgQ7/kiUhUKYejS1wQ7RdeqwLOm8qxn9AHLU5IHaaCl5f0/Gxy2kK8feIllVQ iMlw==
X-Gm-Message-State: AOAM533Ku/+mQi1faMP7ltM0AmBvjW61seN6lmQKGsOrMUZUO2SqAM2y sqWFc+Uc4wPcxduuossg7ZN5JSuwyJtuPw==
X-Google-Smtp-Source: ABdhPJySjuvtFzfcZfuVlcUicTgLNGOpI7Tb/9+8Joz+uSJXEVoFfADc+Zvz26lCq7x6AmWsSVQfbA==
X-Received: by 2002:a17:902:b084:b029:12b:6caa:7d9e with SMTP id p4-20020a170902b084b029012b6caa7d9emr12410594plr.57.1627265389532;  Sun, 25 Jul 2021 19:09:49 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:80b2:5c79:2266:e431? ([2001:df0:0:2006:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id x6sm12048206pjr.5.2021.07.25.19.09.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Jul 2021 19:09:48 -0700 (PDT)
To: Martin Thomson , rfced-future@iab.org
References:    <5e9559ea-13c4-4ba2-93b8-65ef7e20c54a@www.fastmail.com>
From: Brian E Carpenter 
Message-ID: 
Date: Mon, 26 Jul 2021 14:09:45 +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: <5e9559ea-13c4-4ba2-93b8-65ef7e20c54a@www.fastmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Possible new issue: community review of performance
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jul 2021 02:09:52 -0000

On 26-Jul-21 13:10, Martin Thomson wrote:
> On Sun, Jul 25, 2021, at 15:14, Brian E Carpenter wrote:
>> If community members, including the RSWG and RSAB, have concerns about 
>> the performance of the RPC, they can request that the IETF LLC look 
>> into the matter.
> 
> I have no strong objection to the sentiment, but isn't this a non-statement?  Or is your intent to make it clear that RSxx are absolutely not authoritative in this regard?  (Just trying to avoid over-specification.)

It's more of a hint than a specification. It doesn't allow anything new or create a new duty; it just makes it clear that performance issues don't necessarily come from individuals.

   Brian


From nobody Tue Jul 27 15:48:16 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2443A0D23 for ; Tue, 27 Jul 2021 15:48:14 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aR98SGbHDRK; Tue, 27 Jul 2021 15:48:12 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 22B153A0D1F; Tue, 27 Jul 2021 15:48:11 -0700 (PDT)
From: Jay Daley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_93A2F2A3-052B-4C05-8A40-352035836768"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 28 Jul 2021 10:48:08 +1200
In-Reply-To: 
Cc: Peter Saint-Andre , Eliot Lear 
To: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>    <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com>   
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jul 2021 22:48:14 -0000

--Apple-Mail=_93A2F2A3-052B-4C05-8A40-352035836768
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Eliot asked me to propose some additional text to close off issues #56, =
#57, #61, #62 which I=E2=80=99ve done below.  It doesn=E2=80=99t have =
the elegance of Peter=E2=80=99s prose so may require some work to align =
with that.

Much of this is already covered in the latest draft at:

	=
https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab=
-rfcefdp-rfced-model.md#roles-and-processes =


My suggested additions are in red and my suggested text moves are in =
blue. =20

Jay

=E2=80=94=E2=80=94=20

## Role of the RPC

Publication of RFCs shall be continue to be handled by the RFC =
Production Center (RPC) function in accordance with high-level policies =
currently in force or yet to be defined following the processes =
specified in the foregoing sections of this document.

### RPC work program

The RPC follows a work program based on requirements it has gathered =
from a variety of sources, including policies that have been through the =
RSWG/RSAB process, and from direct discussions with the RSEA, stream =
managers, IETF LLC, authors and other IETF participants.  In developing =
this work program, the RPC makes some key decisions which impact the =
IETF community:

1.  For each requirement that is gathered, can it be directly =
incorporated into the work program or must it first be subject to =
community consultation.

2.  Setting the relative priorities for the various requirements within =
the work program.

3.  Determining if all the important requirements have been gathered.

It is likely that the RPC will require advice during the drafting of its =
work program, which it should seek from at least the RSAB and if =
required, the chairs of the RSWG.

In order to ensure community oversight of the RPC work program:

* The RPC must present a draft work program for community feedback at =
least annually and then publish a final work program incorporating any =
agreed feedback.

* The RPC shall report regularly to the RSAB, RSWG, and broader =
community regarding the contents and progress of its work program and =
any key risks or issues affecting it.

In the event that the RPC is required to make a decision without =
consultation that would normally deserve consultation, or makes a =
decision against the advice of the RSAB, then it must notify the RSAB.

All matters of budget, timetable and impact on its performance targets, =
are between the RPC and IETF LLC.

### Relationship between the RPC and the IETF LLC

This document does not specify the exact relationship between the IETF =
LLC and the RPC function; for example, the RPC function could be =
provided by a separate corporate entity under contract to the IETF LLC, =
it could be performed by employees of the IETF LLC, or the IETF LLC =
could work with independent contractors for some or all aspects of the =
RPC function. The exact relationship is a matter for the IETF LLC and =
the IETF Executive Director to determine.

The IETF LLC has authority over negotiating performance targets for the =
RPC and also has responsibility for ensuring that those targets are =
adhered to. The IETF LLC is empowered to appoint a manager or to convene =
a committee to complete these activities.

Community members who have concerns about the performance of the RPC can =
request that the IETF LLC look into the matter. Even if the IETF LLC =
opts to delegate this activity, concerns should be raised with the IETF =
LLC. The IETF LLC is ultimately responsible to the community via the =
mechanisms outlined in its charter.

=E2=80=94=E2=80=94=20

--=20
Jay Daley
IETF Executive Director
jay@ietf.org


--Apple-Mail=_93A2F2A3-052B-4C05-8A40-352035836768
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Eliot asked me to propose some additional text to close off =
issues #56, #57, #61, #62 which I=E2=80=99ve done below.  It =
doesn=E2=80=99t have the elegance of Peter=E2=80=99s prose so may =
require some work to align with that.

Much of this is already covered in the =
latest draft at:

	=
https://github.com/intarchboard/program-rfced-future/blob/maste=
r/draft-iab-rfcefdp-rfced-model.md#roles-and-processes

My suggested additions =
are in red and my =
suggested text moves are in blue.  

Jay

=E2=80=94=E2=80=94 

## Role of the RPC

Publication of RFCs shall be continue to be handled by the =
RFC Production Center (RPC) function in accordance with high-level =
policies currently in force or yet to be defined following the =
processes specified in the foregoing sections of this document.

### RPC =
work program

The RPC follows a work program based on requirements it has =
gathered from a variety of sources, including policies that have been =
through the RSWG/RSAB process, and from direct discussions with the =
RSEA, stream managers, IETF LLC, authors and other IETF participants. =
 In developing this work program, the RPC makes some key decisions =
which impact the IETF community:

1. =
 For each requirement that is gathered, can it be directly =
incorporated into the work program or must it first be subject to =
community consultation.

2.  Setting =
the relative priorities for the various requirements within the work =
program.

3.  Determining if all the =
important requirements have been gathered.

It =
is likely that the RPC will require advice during the drafting of its =
work program, which it should seek from at least the RSAB and if =
required, the chairs of the RSWG.

In order to ensure community oversight of =
the RPC work program:

* The RPC must present a draft work program =
for community feedback at least annually and then publish a final work =
program incorporating any agreed feedback.

* The RPC shall report regularly to the RSAB, =
RSWG, and broader community regarding the contents and progress of its =
work program and any key risks or issues affecting it.

In the event that the RPC is required to make =
a decision without consultation that would normally deserve =
consultation, or makes a decision against the advice of the RSAB, =
then it must notify the RSAB.

All matters of budget, timetable and impact =
on its performance targets, are between the RPC and IETF LLC.

### Relationship between the RPC and the IETF =
LLC

This document does not specify the =
exact relationship between the IETF LLC and the RPC function; for =
example, the RPC function could be provided by a separate corporate =
entity under contract to the IETF LLC, it could be performed by =
employees of the IETF LLC, or the IETF LLC could work with =
independent contractors for some or all aspects of the RPC function. The =
exact relationship is a matter for the IETF LLC and the IETF =
Executive Director to determine.

The IETF =
LLC has authority over negotiating performance targets for the RPC and =
also has responsibility for ensuring that those targets are adhered =
to. The IETF LLC is empowered to appoint a manager or to convene a =
committee to complete these activities.

Community members who have concerns about the performance of =
the RPC can request that the IETF LLC look into the matter. Even if =
the IETF LLC opts to delegate this activity, concerns should be =
raised with the IETF LLC. The IETF LLC is ultimately responsible to =
the community via the mechanisms outlined in its charter.

=E2=80=94=E2=80=94 


-- 
Jay Daley
IETF =
Executive Director
jay@ietf.org




=

--Apple-Mail=_93A2F2A3-052B-4C05-8A40-352035836768--


From nobody Tue Jul 27 15:50:35 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27A33A0D47 for ; Tue, 27 Jul 2021 15:50:33 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SlMXDGwIhPX; Tue, 27 Jul 2021 15:50:29 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 6EFA63A0D45; Tue, 27 Jul 2021 15:50:28 -0700 (PDT)
From: Jay Daley 
Message-Id: <9BA6FF7B-68A7-427A-87E2-70CCBFC2B3BB@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_63B7CAEC-6D0D-4167-887C-00057D51C679"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 28 Jul 2021 10:50:25 +1200
In-Reply-To: 
Cc: Eliot Lear , Peter Saint-Andre 
To: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>    <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com>    
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jul 2021 22:50:34 -0000

--Apple-Mail=_63B7CAEC-6D0D-4167-887C-00057D51C679
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The heading ### Relationship between the RPC and the IETF LLC is also an =
addition.

> On 28/07/2021, at 10:48 AM, Jay Daley  wrote:
>=20
> Eliot asked me to propose some additional text to close off issues =
#56, #57, #61, #62 which I=E2=80=99ve done below.  It doesn=E2=80=99t =
have the elegance of Peter=E2=80=99s prose so may require some work to =
align with that.
>=20
> Much of this is already covered in the latest draft at:
>=20
> 	=
https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab=
-rfcefdp-rfced-model.md#roles-and-processes =

>=20
> My suggested additions are in red and my suggested text moves are in =
blue. =20
>=20
> Jay
>=20
> =E2=80=94=E2=80=94=20
>=20
> ## Role of the RPC
>=20
> Publication of RFCs shall be continue to be handled by the RFC =
Production Center (RPC) function in accordance with high-level policies =
currently in force or yet to be defined following the processes =
specified in the foregoing sections of this document.
>=20
> ### RPC work program
>=20
> The RPC follows a work program based on requirements it has gathered =
from a variety of sources, including policies that have been through the =
RSWG/RSAB process, and from direct discussions with the RSEA, stream =
managers, IETF LLC, authors and other IETF participants.  In developing =
this work program, the RPC makes some key decisions which impact the =
IETF community:
>=20
> 1.  For each requirement that is gathered, can it be directly =
incorporated into the work program or must it first be subject to =
community consultation.
>=20
> 2.  Setting the relative priorities for the various requirements =
within the work program.
>=20
> 3.  Determining if all the important requirements have been gathered.
>=20
> It is likely that the RPC will require advice during the drafting of =
its work program, which it should seek from at least the RSAB and if =
required, the chairs of the RSWG.
>=20
> In order to ensure community oversight of the RPC work program:
>=20
> * The RPC must present a draft work program for community feedback at =
least annually and then publish a final work program incorporating any =
agreed feedback.
>=20
> * The RPC shall report regularly to the RSAB, RSWG, and broader =
community regarding the contents and progress of its work program and =
any key risks or issues affecting it.
>=20
> In the event that the RPC is required to make a decision without =
consultation that would normally deserve consultation, or makes a =
decision against the advice of the RSAB, then it must notify the RSAB.
>=20
> All matters of budget, timetable and impact on its performance =
targets, are between the RPC and IETF LLC.
>=20
> ### Relationship between the RPC and the IETF LLC
>=20
> This document does not specify the exact relationship between the IETF =
LLC and the RPC function; for example, the RPC function could be =
provided by a separate corporate entity under contract to the IETF LLC, =
it could be performed by employees of the IETF LLC, or the IETF LLC =
could work with independent contractors for some or all aspects of the =
RPC function. The exact relationship is a matter for the IETF LLC and =
the IETF Executive Director to determine.
>=20
> The IETF LLC has authority over negotiating performance targets for =
the RPC and also has responsibility for ensuring that those targets are =
adhered to. The IETF LLC is empowered to appoint a manager or to convene =
a committee to complete these activities.
>=20
> Community members who have concerns about the performance of the RPC =
can request that the IETF LLC look into the matter. Even if the IETF LLC =
opts to delegate this activity, concerns should be raised with the IETF =
LLC. The IETF LLC is ultimately responsible to the community via the =
mechanisms outlined in its charter.
>=20
> =E2=80=94=E2=80=94=20
>=20
> --=20
> Jay Daley
> IETF Executive Director
> jay@ietf.org 
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--=20
Jay Daley
IETF Executive Director
jay@ietf.org


--Apple-Mail=_63B7CAEC-6D0D-4167-887C-00057D51C679
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The =
heading ### Relationship between the =
RPC and the IETF LLC is also an addition.

On =
28/07/2021, at 10:48 AM, Jay Daley <jay@ietf.org> wrote:

Eliot =
asked me to propose some additional text to close off issues #56, #57, =
#61, #62 which I=E2=80=99ve done below.  It doesn=E2=80=99t have =
the elegance of Peter=E2=80=99s prose so may require some work to align =
with that.

Much =
of this is already covered in the latest draft at:

	https://github.com/intarchboard/program-rfced-future/blob/maste=
r/draft-iab-rfcefdp-rfced-model.md#roles-and-processes

My suggested additions =
are in red and my =
suggested text moves are in blue.  

Jay

=E2=80=94=E2=80=94 

## Role of the RPC

Publication of RFCs shall be continue to be handled by the =
RFC Production Center (RPC) function in accordance with high-level =
policies currently in force or yet to be defined following the =
processes specified in the foregoing sections of this document.

### RPC =
work program

The RPC follows a work program based on requirements it has =
gathered from a variety of sources, including policies that have been =
through the RSWG/RSAB process, and from direct discussions with the =
RSEA, stream managers, IETF LLC, authors and other IETF participants. =
 In developing this work program, the RPC makes some key decisions =
which impact the IETF community:

1. =
 For each requirement that is gathered, can it be directly =
incorporated into the work program or must it first be subject to =
community consultation.

2.  Setting =
the relative priorities for the various requirements within the work =
program.

3.  Determining if all the =
important requirements have been gathered.

It =
is likely that the RPC will require advice during the drafting of its =
work program, which it should seek from at least the RSAB and if =
required, the chairs of the RSWG.

In order to ensure community oversight of =
the RPC work program:

* The RPC must present a draft work program =
for community feedback at least annually and then publish a final work =
program incorporating any agreed feedback.

* The RPC shall report regularly to the RSAB, =
RSWG, and broader community regarding the contents and progress of its =
work program and any key risks or issues affecting it.

In the event that the RPC is required to make =
a decision without consultation that would normally deserve =
consultation, or makes a decision against the advice of the RSAB, =
then it must notify the RSAB.

All matters of budget, timetable and impact =
on its performance targets, are between the RPC and IETF LLC.

### Relationship between the RPC and the IETF =
LLC

This document does not specify the =
exact relationship between the IETF LLC and the RPC function; for =
example, the RPC function could be provided by a separate corporate =
entity under contract to the IETF LLC, it could be performed by =
employees of the IETF LLC, or the IETF LLC could work with =
independent contractors for some or all aspects of the RPC function. The =
exact relationship is a matter for the IETF LLC and the IETF =
Executive Director to determine.

The IETF =
LLC has authority over negotiating performance targets for the RPC and =
also has responsibility for ensuring that those targets are adhered =
to. The IETF LLC is empowered to appoint a manager or to convene a =
committee to complete these activities.

Community members who have concerns about the performance of =
the RPC can request that the IETF LLC look into the matter. Even if =
the IETF LLC opts to delegate this activity, concerns should be =
raised with the IETF LLC. The IETF LLC is ultimately responsible to =
the community via the mechanisms outlined in its charter.

=E2=80=94=E2=80=94 


-- 
Jay Daley
IETF Executive Director
jay@ietf.org




-- 
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future



-- 
Jay Daley
IETF =
Executive Director
jay@ietf.org




=

--Apple-Mail=_63B7CAEC-6D0D-4167-887C-00057D51C679--


From nobody Wed Jul 28 01:51:30 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D000F3A23C5 for ; Wed, 28 Jul 2021 01:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=itaoyama.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 h1xhuZm2Q9o3 for ; Wed, 28 Jul 2021 01:51:26 -0700 (PDT)
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400103.outbound.protection.outlook.com [40.107.140.103]) (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 C20A33A23C0 for ; Wed, 28 Jul 2021 01:51:25 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UvQAN3aKp6ox9HesRvQKSoNUGzOtg17CwbC0DfsAFyidYELADa/ceiqvFLiQDrz8bapvE9g2vsWuSaBTcYpXiwlaj7Op/geVhEg/8Sq4goLY9JbBoL6+lj4ocP2C22hoWKHEKePXYFYgJTSADUI+Kw2W7bAk66jjT3AK5k5MPp3kaVh+yfMA6hH6TnWWOS/tihvf8VvNhWU5usL3s2nyuTEc8QaGpMaKFI99CnJoVj2dszIE9ZKVWOjYEzUgVY3ETAcBQ756lhN8N//AQNCF6rdBQzzlSHgjNx7n/W89DVammhmruRH/dP8nbevrOb8d5tiR7rtX069V5+sopL+W1w==
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=P/+6QIqQdGL0KqgF+t2hEZ9TJIGtfPylbbEvW0u4geo=; b=eErJmvd5xSr8yS+8v8NCc+ZzJFZPtxm4lg4d+mnb/SPp/abO5Ftsz9FZ/lBRDlv5mBqo2+NFs0HIRRU9+iSCIm65I8ynMPqLp4orM8OtblQfK2JtgCJt71IGm7iBEsw8WPHpyNfMjRTyv2YRdX5sPPo7coSVbJVGOB/jUjEpQHwc/HkGWmShibVOicQDrCy94RJlYC5Sl9sbV3rlwcrCx4Nkx1dbvbllbkka4r9j1yg0q5H+BvKuDFG6bWvsD6XU2SpLNq/0ew2n0UCTb2CMdEdu1Yh48mpLP18iJ0iqRGP66ygJehpPDl+m1ORVVRShDZCTKwdc5qoYM6+9a2XCQQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P/+6QIqQdGL0KqgF+t2hEZ9TJIGtfPylbbEvW0u4geo=; b=ciYH80rWsSLCG5amxdp1wmIB0Cr2dkjVcXMS0LpnSrWKZlOjFyNCm7nLQh756wnANSVchNM/XgsgNYo1hRZ+GMPLp0nMDb9v9V9W8QFSivhKOcvMC9sGneWA6pYmPVSoAIv5ReMcIZczHN19QzfYKlpLt2jfiDV5PqHhd5TGZMc=
Authentication-Results: mozilla.com; dkim=none (message not signed) header.d=none;mozilla.com; dmarc=none action=none header.from=it.aoyama.ac.jp;
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYYPR01MB6603.jpnprd01.prod.outlook.com (2603:1096:400:e0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.25; Wed, 28 Jul 2021 08:51:22 +0000
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b%6]) with mapi id 15.20.4352.032; Wed, 28 Jul 2021 08:51:22 +0000
To: Jay Daley , rfced-future@iab.org
Cc: Eliot Lear , Peter Saint-Andre 
References:  <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>    <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com>    
From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: <6140c31e-3f8a-a1f0-8c4b-39be146bb82a@it.aoyama.ac.jp>
Date: Wed, 28 Jul 2021 17:51:19 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: TYCPR01CA0104.jpnprd01.prod.outlook.com (2603:1096:405:4::20) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [133.2.210.39] (133.2.210.39) by TYCPR01CA0104.jpnprd01.prod.outlook.com (2603:1096:405:4::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18 via Frontend Transport; Wed, 28 Jul 2021 08:51:21 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ab66f111-0030-459f-649c-08d951a4df59
X-MS-TrafficTypeDiagnostic: TYYPR01MB6603:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: SiRHn8eES8uSQhKGk6LTMnhOMFzFlSmoB2zc3O7ineaXFmQAuHEGA4nb72AIsE9y1e1vbF+Vbw9pzmF+GwhP8sC9hppemJPXnPX1jRsEQfm1txPyYcBFFSG7hKyubgA+c1IDlwG8MvsXL5kL7dOqUvmq8vuRu2wt3nfLtaQyheyjGOCXWmjocITZTbDtCe2dJEiUvIzoQQoX+6uvDBBHN/nT5kAnnCUyCHGBziQSb0g7PmeY1soLx113scWjuzjECUjJMP//L3Zc9B7MUsNuz9LHA+vL1psRGy28nXH9Oq0YrAaZ01ptBwpGLLb3iaiePeIyN/CZabv+cO4txcjznKomh2jU0A+NZprRQ1t9nU6pyxCqv7dw5LDcWDLpZCUi3b46AeeHBgql0hPI9yEcnj6PMzl0BDgHGLtwxavgTwzC5xugGn4QKbp4P7TbwcJzCbAG/q/IGYZQmfeejUFYn0x7DDTkDiiI0aNYPDdXJoAA/PEK24BfqD2PwfISQ2eBV/+VsSkPZFCySxMYsZWUAsXrG2n5dXwAwQqyJwKk9ZdBKxhUBvDP0fp6aFujI3jlGrgwzy9Sde46tTFH2kjr3aF+1RhzuXO4Xio6mplTrWO58cvX0IkE24QPtuV1yEy3f0DHa8FVh5WV5mlHbjJ3T413QY48G4YlowPgpfRC4B2ApGGhG4iPklNkDjrqrx1b1+qg+S64t3FF8us/NFvt+Ec7/DrcrfbHdVm+vf0/cjNFZ1pXqHspmiHPM5EOt+jKlRweubYVcVikE/HjaL6XqfjLwNFH1eV33Q/+e/E4MWW1F5PvLUenjIVTX43DZ8A4hmwQBHCf6hiwtmC/n9bpkBM4K1IIq+y8MUkI6MsQ2nwNlFpspeT+BoleUPAt13Bi
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE;  SFS:(366004)(39830400003)(346002)(396003)(136003)(376002)(8936002)(86362001)(966005)(6706004)(16576012)(316002)(38350700002)(956004)(786003)(5660300002)(26005)(83380400001)(38100700002)(31696002)(66946007)(66476007)(186003)(53546011)(478600001)(31686004)(2616005)(54906003)(66556008)(52116002)(36916002)(6486002)(4326008)(8676002)(2906002)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OHVhL3VicE1WL2ZabzJhb2Njak1seEY3ckx0R0tiR2hlc1prdkhUZnN1SzJr?= =?utf-8?B?aS9mOVlhcWdJTW1TS0dKMytvUWFFNDJack84R2xRWkxUMGdzZldHWnd1d0l0?= =?utf-8?B?ODhGSkt3Zm5GT2pGYWFKeHZmekJBejM0aVpzQmFITWFyemhqWFNRK3lZMis1?= =?utf-8?B?dzRHbU0vYjBwTTFyZ2VUVGZxb1NQVXJIakRLTmwvbmlBcWFXOUpNNVlaQm96?= =?utf-8?B?ZlZEM3NmWTBwK0hTSjlEekxLY2IxV1RiejVpejJ3NThaUzMrVG1rZVdjbW15?= =?utf-8?B?b0w0QU5BaUs1RjVySEZ0SVJQY1dEdDZMaTR2N0N4T2xrWEc5cndmTk44enlk?= =?utf-8?B?azZKK041SHA4Smx6OUcvTVA2MDJudGdqOWQxUEd6K0Rra2hhMTlIdEtIOG5O?= =?utf-8?B?NkNSejllMTN4TWJwWmR4SGRRR3FYSWtpbG5CMm4yelNrMW1DQVpBU09PY3N4?= =?utf-8?B?VHNFSnZIblNuT1hOaGpXbUREcnZSY3BsZlVIaHlPRGtLcUlURWdmT3F6TXda?= =?utf-8?B?OTRDdktHeVZHMkM5VGFEaUI2OWhDSnZieldwYm9DOGhUU01mcm92MW1PVFRl?= =?utf-8?B?VVcxNzlTdVB0bjVJMEZoRmJpMTJ0T1NzcmhHWEdOSUxQcVpEcUNOUTRGUkQy?= =?utf-8?B?TGNrZDRRK0RwcTBncFZVOURPKy92b2Q5NjRZVHV4VkJMQU5pUFRxdGIrYVRH?= =?utf-8?B?USs0Tlo0M2E4Ti95UHl5YndQNnZ6L0ptRnlBNlkzVnA5OVJHK0lQQmVkTU93?= =?utf-8?B?S21XQ2NSQlF2N0dvMU1GaWhNcnVsTlpZT0ZpWFFUUEFmcEZzZ1F0aG9nRGZw?= =?utf-8?B?b0dQcEh0ZGRlNUlIQXdSakpkMUVWOXNQclh6dk1LNFV0R0dxaDgyRTM4NWdt?= =?utf-8?B?blR4ZE1TeHlqUGtPOTFWNElsVmt3R0ZSSXlMeHZKUSt4d3ZuemJkNjF2bEJV?= =?utf-8?B?V3d4TG0rTENYRU8rdXBacDlWWXlLUXJuM2RVSUxrUWJ3TGJnbUJhNEs5UXo4?= =?utf-8?B?dFFsbnUvd291Mjk0L3ZGRU9wOEhOQ2FNL0hOL2VSVHE2UzFlTHd2RVNkYmZF?= =?utf-8?B?VUpCclQyT3ZvYVZCTGl5SG80WEx4RjdQbkFZVVdJQm9pTDU0dGtQSzFhclNl?= =?utf-8?B?OUZKVDRaNm83c3loZmo4eEh4Nkw0VGhBQ1FWTTZTWlg4SDJvdUNhMlYrb2xO?= =?utf-8?B?YStoR0o1Z2J3L0w4azhCUytKUHRna0pCS0VhNGNDKzlxTWJMS2g3aUxUR2pS?= =?utf-8?B?ZklCNm1zWmlVUENpc2JmUkx5MXF0ZWdlSEtweWxvRUJPMFFJaldhck9vSW53?= =?utf-8?B?WnpHMmFJTWtXSmN4VEZxZGk1STdtUktVZlo1aU9WbkNEajJDRFFlQzNBdmM0?= =?utf-8?B?b0RocWlFczcrN0ZueGllNUhzUTdpOS8wM3VaU3pKZ3pkVktlYlhsUXVFdmpH?= =?utf-8?B?cUlCUnlqYVVsYTlUMkNQTE9lVmZsRW9xb3hLbGhLMUloUVRSUzBzK2hWNzUx?= =?utf-8?B?MjczbEdWNVNVL2NmckNsWVhGajEvUi9kUjh3TGU4cFRHcmlRRDNsYXdBZ05s?= =?utf-8?B?VU50L050Rm1Za2FMVzI0QVNMYkp3OGhzVlRzS1JrOVR3QzI0KzFVdUFLeVRN?= =?utf-8?B?QUl0ejVtWmltbWh4WkFxWjcva3hNZ1NHeWNxZzAxWTlGTkMzVG1JQ2pvMHZR?= =?utf-8?B?clBFNmxqUkZRTUF5Z1lINHQ1VjhCdVpEb2RFdFZBYmxTWkdQRGU4Y2tOVmF0?= =?utf-8?Q?OFilMNjPQLj7Nlu6as6yHZ+m3EFhixtKHVDPXd8?=
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: ab66f111-0030-459f-649c-08d951a4df59
X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2021 08:51:21.9442 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: xX9fGW1znCEWODbJgTiDQQQnZuoDIs7ixGHZavXFUQ48ZEahumekopSttYyMAHHB67ueGjLwLcdrTyPbJofOFw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYPR01MB6603
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jul 2021 08:51:29 -0000

Hello Jay, others,

On 2021-07-28 07:48, Jay Daley wrote:
> Eliot asked me to propose some additional text to close off issues #56, #57, #61, #62 which I’ve done below.  It doesn’t have the elegance of Peter’s prose so may require some work to align with that.
> 
> Much of this is already covered in the latest draft at:
> 
> 	https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab-rfcefdp-rfced-model.md#roles-and-processes 
> 
> My suggested additions are in red and my suggested text moves are in blue.

Sorry, but please avoid using colors for such distinctions. I usually 
view all my mail as plain text, and I think there are quite a few others 
on this list who do so, too. I switched to HTML view just for this mail, 
but I'd prefer to avoid this.

> Jay
> 
> ——
> 
> ## Role of the RPC
> 
> Publication of RFCs shall be continue to be handled by the RFC Production Center (RPC) function in accordance with high-level policies currently in force or yet to be defined following the processes specified in the foregoing sections of this document.
> 
> ### RPC work program
> 
> The RPC follows a work program based on requirements it has gathered from a variety of sources, including policies that have been through the RSWG/RSAB process, and from direct discussions with the RSEA, stream managers, IETF LLC, authors and other IETF participants.  In developing this work program, the RPC makes some key decisions which impact the IETF community:
> 
> 1.  For each requirement that is gathered, can it be directly incorporated into the work program or must it first be subject to community consultation.
> 
> 2.  Setting the relative priorities for the various requirements within the work program.
> 
> 3.  Determining if all the important requirements have been gathered.
> 
> It is likely that the RPC will require advice during the drafting of its work program, which it should seek from at least the RSAB and if required, the chairs of the RSWG.
> 
> In order to ensure community oversight of the RPC work program:
> 
> * The RPC must present a draft work program for community feedback at least annually and then publish a final work program incorporating any agreed feedback.
> 
> * The RPC shall report regularly to the RSAB, RSWG, and broader community regarding the contents and progress of its work program and any key risks or issues affecting it.
> 
> In the event that the RPC is required to make a decision without consultation that would normally deserve consultation, or makes a decision against the advice of the RSAB, then it must notify the RSAB.
> 
> All matters of budget, timetable and impact on its performance targets, are between the RPC and IETF LLC.

I have difficulties to see how "work program" and "performance targets" 
are related. The above description lets them look quite independent, but 
if that's the case, things won't work out very well. The work program 
may look very nice, but because it's not part of the performance 
targets, it may get ignored. If the work program is just a matter 
between RSAB/RSWG and RPC, without involving the LLC, it may be dead on 
arrival.

Also, the terms "work program" and "performance targets" suggest 
different stuff. Under "work program", I could imagine stuff similar to 
past items such as introducing DOIs and ISSNs; under "performance 
targets", I'd imagine "number of RFCs published", "number of RFC pages 
published", "average delay between some defined states in the editing 
pipeline", and so on.

Also, all this "work program" stuff seems to somehow be at odds with the 
process that we are currently working on. To take a past example, let's 
say the RSWG creates a document that says that RFCs should have DOIs. 
That document is approved by the RSWG (and published as an RFC), and 
thus supposed to represent community consensus. But if we follow the 
above points, it looks like everything might have to be rehashed or 
regurgitated for the "work program".

So I think we need to clarify the relationship between RSWG consensus 
documents, LLC performance targets, and RPC work program.

Regards,   Martin.


> ### Relationship between the RPC and the IETF LLC
> 
> This document does not specify the exact relationship between the IETF LLC and the RPC function; for example, the RPC function could be provided by a separate corporate entity under contract to the IETF LLC, it could be performed by employees of the IETF LLC, or the IETF LLC could work with independent contractors for some or all aspects of the RPC function. The exact relationship is a matter for the IETF LLC and the IETF Executive Director to determine.
> 
> The IETF LLC has authority over negotiating performance targets for the RPC and also has responsibility for ensuring that those targets are adhered to. The IETF LLC is empowered to appoint a manager or to convene a committee to complete these activities.
> 
> Community members who have concerns about the performance of the RPC can request that the IETF LLC look into the matter. Even if the IETF LLC opts to delegate this activity, concerns should be raised with the IETF LLC. The IETF LLC is ultimately responsible to the community via the mechanisms outlined in its charter.
> 



From nobody Wed Jul 28 12:52:39 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9DC3A1DE0 for ; Wed, 28 Jul 2021 12:52:31 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xSUMEflCznJ; Wed, 28 Jul 2021 12:52:26 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 293053A1DA5; Wed, 28 Jul 2021 12:52:24 -0700 (PDT)
From: Jay Daley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_EC684EE5-27A3-4640-9703-CFD935A03950"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Thu, 29 Jul 2021 07:52:22 +1200
In-Reply-To: <6140c31e-3f8a-a1f0-8c4b-39be146bb82a@it.aoyama.ac.jp>
Cc: rfced-future@iab.org, Eliot Lear , Peter Saint-Andre 
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
References:  <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>    <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com>     <6140c31e-3f8a-a1f0-8c4b-39be146bb82a@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jul 2021 19:52:37 -0000

--Apple-Mail=_EC684EE5-27A3-4640-9703-CFD935A03950
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Mrtin

> On 28/07/2021, at 8:51 PM, Martin J. D=C3=BCrst =
 wrote:
>=20
> Hello Jay, others,
>=20
> On 2021-07-28 07:48, Jay Daley wrote:
>> Eliot asked me to propose some additional text to close off issues =
#56, #57, #61, #62 which I=E2=80=99ve done below.  It doesn=E2=80=99t =
have the elegance of Peter=E2=80=99s prose so may require some work to =
align with that.
>> Much of this is already covered in the latest draft at:
>> 	=
https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab=
-rfcefdp-rfced-model.md#roles-and-processes =

>> My suggested additions are in red and my suggested text moves are in =
blue.
>=20
> Sorry, but please avoid using colors for such distinctions. I usually =
view all my mail as plain text, and I think there are quite a few others =
on this list who do so, too. I switched to HTML view just for this mail, =
but I'd prefer to avoid this.
>=20
>> Jay
>> =E2=80=94=E2=80=94
>> ## Role of the RPC
>> Publication of RFCs shall be continue to be handled by the RFC =
Production Center (RPC) function in accordance with high-level policies =
currently in force or yet to be defined following the processes =
specified in the foregoing sections of this document.
>> ### RPC work program
>> The RPC follows a work program based on requirements it has gathered =
from a variety of sources, including policies that have been through the =
RSWG/RSAB process, and from direct discussions with the RSEA, stream =
managers, IETF LLC, authors and other IETF participants.  In developing =
this work program, the RPC makes some key decisions which impact the =
IETF community:
>> 1.  For each requirement that is gathered, can it be directly =
incorporated into the work program or must it first be subject to =
community consultation.
>> 2.  Setting the relative priorities for the various requirements =
within the work program.
>> 3.  Determining if all the important requirements have been gathered.
>> It is likely that the RPC will require advice during the drafting of =
its work program, which it should seek from at least the RSAB and if =
required, the chairs of the RSWG.
>> In order to ensure community oversight of the RPC work program:
>> * The RPC must present a draft work program for community feedback at =
least annually and then publish a final work program incorporating any =
agreed feedback.
>> * The RPC shall report regularly to the RSAB, RSWG, and broader =
community regarding the contents and progress of its work program and =
any key risks or issues affecting it.
>> In the event that the RPC is required to make a decision without =
consultation that would normally deserve consultation, or makes a =
decision against the advice of the RSAB, then it must notify the RSAB.
>> All matters of budget, timetable and impact on its performance =
targets, are between the RPC and IETF LLC.
>=20
> I have difficulties to see how "work program" and "performance =
targets" are related. The above description lets them look quite =
independent, but if that's the case, things won't work out very well. =
The work program may look very nice, but because it's not part of the =
performance targets, it may get ignored. If the work program is just a =
matter between RSAB/RSWG and RPC, without involving the LLC, it may be =
dead on arrival.

By definition, the role of the RPC is to follow the RFCs that define the =
role of the RPC and so if there is an RFC that says they must have a =
work program and consult on it then that is part of their role.  The LLC =
is responsible for ensuring that the RPC follows its defined role and =
so, again by definition, the LLC will ensure that the RPC has a work =
program and follows it.  I don=E2=80=99t think we need to say anything =
about this explicitly but I would not object to in principle to any text =
that makes that explicit.

>=20
> Also, the terms "work program" and "performance targets" suggest =
different stuff. Under "work program", I could imagine stuff similar to =
past items such as introducing DOIs and ISSNs; under "performance =
targets", I'd imagine "number of RFCs published", "number of RFC pages =
published", "average delay between some defined states in the editing =
pipeline", and so on.

That=E2=80=99s spot on.

The RPC needs to balance what resources it puts into the work program =
and what it puts into day-to-day work to ensure that its performance =
targets are met.  As per the text, that balance and the key factors that =
affect it - budget, timetable and impact on performance - are between =
the RPC and LLC.

>=20
> Also, all this "work program" stuff seems to somehow be at odds with =
the process that we are currently working on. To take a past example, =
let's say the RSWG creates a document that says that RFCs should have =
DOIs. That document is approved by the RSWG (and published as an RFC), =
and thus supposed to represent community consensus. But if we follow the =
above points, it looks like everything might have to be rehashed or =
regurgitated for the "work program".

In that scenario the document simply becomes an action on the work plan =
and the only decision for the RPC is how to prioritise it.  There=E2=80=99=
s no text that gives the RPC any leeway to rehash or regurgitate.  Again =
I don=E2=80=99t see a need to say anything about this explicitly but I =
would not object to in principle to any text that makes that explicit.

Jay

>=20
> So I think we need to clarify the relationship between RSWG consensus =
documents, LLC performance targets, and RPC work program.
>=20
> Regards,   Martin.
>=20
>=20
>> ### Relationship between the RPC and the IETF LLC
>> This document does not specify the exact relationship between the =
IETF LLC and the RPC function; for example, the RPC function could be =
provided by a separate corporate entity under contract to the IETF LLC, =
it could be performed by employees of the IETF LLC, or the IETF LLC =
could work with independent contractors for some or all aspects of the =
RPC function. The exact relationship is a matter for the IETF LLC and =
the IETF Executive Director to determine.
>> The IETF LLC has authority over negotiating performance targets for =
the RPC and also has responsibility for ensuring that those targets are =
adhered to. The IETF LLC is empowered to appoint a manager or to convene =
a committee to complete these activities.
>> Community members who have concerns about the performance of the RPC =
can request that the IETF LLC look into the matter. Even if the IETF LLC =
opts to delegate this activity, concerns should be raised with the IETF =
LLC. The IETF LLC is ultimately responsible to the community via the =
mechanisms outlined in its charter.
>=20
>=20

--=20
Jay Daley
IETF Executive Director
jay@ietf.org


--Apple-Mail=_EC684EE5-27A3-4640-9703-CFD935A03950
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Mrtin

On 28/07/2021, at 8:51 PM, =
Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote:

Hello =
Jay, others,

On 2021-07-28 07:48, Jay Daley =
wrote:
Eliot asked me =
to propose some additional text to close off issues #56, #57, #61, #62 =
which I=E2=80=99ve done below.  It doesn=E2=80=99t have the =
elegance of Peter=E2=80=99s prose so may require some work to align with =
that.
Much of this is already covered in the latest draft =
at:
	https://github.com/intarchboard/program-rfced-future/blob/maste=
r/draft-iab-rfcefdp-rfced-model.md#roles-and-processes <https://github.com/intarchboard/program-rfced-future/blob/maste=
r/draft-iab-rfcefdp-rfced-model.md#roles-and-processes>
My suggested additions are in red and my suggested text moves =
are in blue.

Sorry, but please =
avoid using colors for such distinctions. I usually view all my mail as =
plain text, and I think there are quite a few others on this list who do =
so, too. I switched to HTML view just for this mail, but I'd prefer to =
avoid this.

Jay
=E2=80=94=E2=80=94
## Role of =
the RPC
Publication of RFCs shall be continue to be =
handled by the RFC Production Center (RPC) function in accordance with =
high-level policies currently in force or yet to be defined following =
the processes specified in the foregoing sections of this document.
### RPC work program
The RPC follows a work =
program based on requirements it has gathered from a variety of sources, =
including policies that have been through the RSWG/RSAB process, and =
from direct discussions with the RSEA, stream managers, IETF LLC, =
authors and other IETF participants.  In developing this work =
program, the RPC makes some key decisions which impact the IETF =
community:
1.  For each requirement that is gathered, =
can it be directly incorporated into the work program or must it first =
be subject to community consultation.
2.  Setting the =
relative priorities for the various requirements within the work =
program.
3.  Determining if all the important =
requirements have been gathered.
It is likely that the RPC =
will require advice during the drafting of its work program, which it =
should seek from at least the RSAB and if required, the chairs of the =
RSWG.
In order to ensure community oversight of the RPC =
work program:
* The RPC must present a draft work program =
for community feedback at least annually and then publish a final work =
program incorporating any agreed feedback.
* The RPC shall =
report regularly to the RSAB, RSWG, and broader community regarding the =
contents and progress of its work program and any key risks or issues =
affecting it.
In the event that the RPC is required to =
make a decision without consultation that would normally deserve =
consultation, or makes a decision against the advice of the RSAB, then =
it must notify the RSAB.
All matters of budget, timetable =
and impact on its performance targets, are between the RPC and IETF =
LLC.

I have difficulties to =
see how "work program" and "performance targets" are related. The above =
description lets them look quite independent, but if that's the case, =
things won't work out very well. The work program may look very nice, =
but because it's not part of the performance targets, it may get =
ignored. If the work program is just a matter between RSAB/RSWG and RPC, =
without involving the LLC, it may be dead on arrival.

By =
definition, the role of the RPC is to follow the RFCs that define the =
role of the RPC and so if there is an RFC that says they must have a =
work program and consult on it then that is part of their role. =
 The LLC is responsible for ensuring that the RPC follows its =
defined role and so, again by definition, the LLC will ensure that the =
RPC has a work program and follows it.  I don=E2=80=99t think we =
need to say anything about this explicitly but I would not object to in =
principle to any text that makes that explicit.


Also, the terms "work program" and =
"performance targets" suggest different stuff. Under "work program", I =
could imagine stuff similar to past items such as introducing DOIs and =
ISSNs; under "performance targets", I'd imagine "number of RFCs =
published", "number of RFC pages published", "average delay between some =
defined states in the editing pipeline", and so on.

That=E2=80=99s spot on.

The RPC needs to balance what resources it puts =
into the work program and what it puts into day-to-day work to ensure =
that its performance targets are met.  As per the text, that =
balance and the key factors that affect it - budget, timetable and =
impact on performance - are between the RPC and LLC.


Also, all this "work program" stuff seems to =
somehow be at odds with the process that we are currently working on. To =
take a past example, let's say the RSWG creates a document that says =
that RFCs should have DOIs. That document is approved by the RSWG (and =
published as an RFC), and thus supposed to represent community =
consensus. But if we follow the above points, it looks like everything =
might have to be rehashed or regurgitated for the "work program".

In =
that scenario the document simply becomes an action on the work plan and =
the only decision for the RPC is how to prioritise it.  There=E2=80=99=
s no text that gives the RPC any leeway to rehash or regurgitate. =
 Again I don=E2=80=99t see a need to say anything about this =
explicitly but I would not object to in principle to any text that makes =
that explicit.

Jay


So I think we need to clarify the relationship =
between RSWG consensus documents, LLC performance targets, and RPC work =
program.

Regards,   Martin.


### Relationship between the RPC and the IETF LLC
This document does not specify the exact relationship between =
the IETF LLC and the RPC function; for example, the RPC function could =
be provided by a separate corporate entity under contract to the IETF =
LLC, it could be performed by employees of the IETF LLC, or the IETF LLC =
could work with independent contractors for some or all aspects of the =
RPC function. The exact relationship is a matter for the IETF LLC and =
the IETF Executive Director to determine.
The IETF LLC has =
authority over negotiating performance targets for the RPC and also has =
responsibility for ensuring that those targets are adhered to. The IETF =
LLC is empowered to appoint a manager or to convene a committee to =
complete these activities.
Community members who have =
concerns about the performance of the RPC can request that the IETF LLC =
look into the matter. Even if the IETF LLC opts to delegate this =
activity, concerns should be raised with the IETF LLC. The IETF LLC is =
ultimately responsible to the community via the mechanisms outlined in =
its charter.





-- 
Jay Daley
IETF =
Executive Director
jay@ietf.org




=

--Apple-Mail=_EC684EE5-27A3-4640-9703-CFD935A03950--


From nobody Wed Jul 28 13:21:18 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BBC3A0FC4 for ; Wed, 28 Jul 2021 13:21:08 -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, 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 (1024-bit key) header.d=mozilla.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 iAr-oduG2MyL for ; Wed, 28 Jul 2021 13:21:05 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 36B213A0D0E for ; Wed, 28 Jul 2021 13:21:04 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id h18so3606978ilc.5 for ; Wed, 28 Jul 2021 13:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=nf7vzKQsjsRznxgRdhHdlVowF2xtb6ydntyx7HAJ3U8=; b=GmHFd08YTxuwha3DJQRjIwuOnxyISk0cbL4+4b3ilo7k03IjXCkQYlHpPFm7UNw3j7 nsE1mhGqflV6RxuskPGJ7IGKhYeYNjAw1jtkRLRfDVNWwLQkaj6x4tCt2KMJrF8zmZ14 iQuvCrZANJbRCqrHjLxb9eCyU7vRwmcQZKCaY=
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=nf7vzKQsjsRznxgRdhHdlVowF2xtb6ydntyx7HAJ3U8=; b=kDMkFi8xh7fA/4tmDwBNEyYv72Y4Y35EvsTh6b+L431QCGFX5PrTxFQoI3myaT7iji fS/JGhRRlpVXudq3J7JvsHdEFjmEVYDb3umYqUUebfKi1x0zCyqD7t4OoCnerecL8muZ EQKnjz8I57TRHgxc2cdnKxPLBQ89YML1SxzLWNJAHmvbLpgccd++Z0gDtpplv3A1IJiU OKcGflZ1vlLxZyNaY75IJOXLrVZ8oEO1G4ii3zocq5lmAL4bhYUpRP96abrk4jd1rFYL 90SpndO54QPaGBg+wtwQE3DPwmg8Z7IJp97IuCckuQNU6HRtqOcOKHYiy7z8kB517hCO /l1g==
X-Gm-Message-State: AOAM5337a7cCjbCH9BOfLMzuKVmz1zpmkynZArBEJRs/joX4Y0t/HDfP jOn2kN1hGLa+5sJXJS/f6PC3uA==
X-Google-Smtp-Source: ABdhPJx2Lye6tKF2iumabpNXVksoWWQlcv3X/BOxVqTK7E44arI7UCdejfyzH6JD8hz8HSDznpDqXQ==
X-Received: by 2002:a05:6e02:1a46:: with SMTP id u6mr1038090ilv.135.1627503663909;  Wed, 28 Jul 2021 13:21:03 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id f3sm699371iob.30.2021.07.28.13.21.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jul 2021 13:21:03 -0700 (PDT)
To: Brian E Carpenter , rfced-future@iab.org
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com> <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>   <02390CF3-6221-436E-A1B2-C455D79A1C7B@csperkins.org> <1c1fea4a-ff85-3f41-ef82-b54fcf49ea58@lear.ch> <030e01d778e6$38f43a60$aadcaf20$@olddog.co.uk> <9ADF27F5-5547-489E-ADD0-5EB754179300@csperkins.org> 
From: Peter Saint-Andre 
Message-ID: <75686766-49f2-1846-f068-ed7a4f16ad64@mozilla.com>
Date: Wed, 28 Jul 2021 14:21:01 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jul 2021 20:21:10 -0000

On 7/14/21 2:59 PM, Brian E Carpenter wrote:
> Also we have various precedents for (e.g.) the IAB appointing someone to an external committee (e.g. the gazillion committees that ICANN seems to have), by a process of the IAB's own choosing. So why don't we just say that (apart from fixed maximum terms) it's for the appointing body to determine its own appointment process, including delegation?

Without my editor hat on, that seems reasonable. If someone has a
concern with process followed by the appointing body, they can take it
up there.

Peter


From nobody Wed Jul 28 13:29:57 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A894C3A1EED for ; Wed, 28 Jul 2021 13:29:54 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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=mozilla.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 P3dA5jZ543Da for ; Wed, 28 Jul 2021 13:29:53 -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 15B163A1EEC for ; Wed, 28 Jul 2021 13:29:52 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id f11so4312665ioj.3 for ; Wed, 28 Jul 2021 13:29:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=N6WK011Aem/9IYDx6VGx2bRJYw3Fa/eqsykUgn5SxTw=; b=P4E/7R8ypRQ1H3/9qZoht7lZxdhaMiykE6v377qm0LxTKhAyKRmN4jyAy/mTDG1/il /LPUrMe/KOM2NIeg5y53SqZGQK9U22Rg0AC8n+bADDUvH91CBtqWSRBawpshxHemBtiG cJspZeQ042jwG5EHoX/ZvqxISUSm2YxRTwxjc=
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=N6WK011Aem/9IYDx6VGx2bRJYw3Fa/eqsykUgn5SxTw=; b=X/kIZWljkpQYKxYWErrKjyQavxd5hMfcNNLuUgMgmIgoZd91yNnQD3oe5Of5dPJlix 5IvuBQ1VaTAWDzxI31D5UIrA5KjG6vJT1FD0DRgcriUnPQdot/g1PJ1e0UcnkcGhCaHQ 7KSeoxo/0RWPVyf5WFd8zj5IppUV0Q9CpWDCkzmHxDmBRR31cBm31KPXXV3QKy9nRrP/ 9cb9exusPx2hwR7x6dZp0VIH3BdwmfHM55TtuE8QqOPj7heZUcETAIC6LotORb7KB/9a IkXW/saYqRptQ4v/CUFlL3/9fPOp/ox5hIAtk5qK3NnXNXT5luu2O8k+jdS+rDWM8Nuc QDQg==
X-Gm-Message-State: AOAM530fFQa+FlLdtCUI7dDGjU5bd20LLyO69uzYyEeBTdOMtiLgRrRn xyCFJyn5I6F+O4OxAI4zyU4KVg==
X-Google-Smtp-Source: ABdhPJxcSfsMlkrTnlrF8VVsAd7UcGy/B0GJ6VMM+yz7uLQP/5vdX/Kd8iRQyXcXnuW+y58kqCYL7A==
X-Received: by 2002:a5e:c311:: with SMTP id a17mr1050445iok.22.1627504191666;  Wed, 28 Jul 2021 13:29:51 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id x2sm723123iob.45.2021.07.28.13.29.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jul 2021 13:29:50 -0700 (PDT)
To: Brian E Carpenter , Martin Thomson , rfced-future@iab.org
References:    <5e9559ea-13c4-4ba2-93b8-65ef7e20c54a@www.fastmail.com> 
From: Peter Saint-Andre 
Message-ID: <5c8a1eba-5eea-ff20-34b0-f6bd40258c4e@mozilla.com>
Date: Wed, 28 Jul 2021 14:29:49 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Possible new issue: community review of performance
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jul 2021 20:29:55 -0000

no hats

On 7/25/21 8:09 PM, Brian E Carpenter wrote:
> On 26-Jul-21 13:10, Martin Thomson wrote:
>> On Sun, Jul 25, 2021, at 15:14, Brian E Carpenter wrote:
>>> If community members, including the RSWG and RSAB, have concerns about 
>>> the performance of the RPC, they can request that the IETF LLC look 
>>> into the matter.
>>
>> I have no strong objection to the sentiment, but isn't this a non-statement?  Or is your intent to make it clear that RSxx are absolutely not authoritative in this regard?  (Just trying to avoid over-specification.)
> 
> It's more of a hint than a specification. It doesn't allow anything new or create a new duty; it just makes it clear that performance issues don't necessarily come from individuals.

True, but then we could mention IESG, IAB, IRTF, and various other
bodies (e.g., can a company that references RFCs in its procurement
process raise concerns as an organization?). I feel like we might be
opening a can of worms...

Peter


From nobody Wed Jul 28 13:32:39 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D80D3A1F09 for ; Wed, 28 Jul 2021 13:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLt_ClXP9kAF for ; Wed, 28 Jul 2021 13:32:33 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 0C8A03A1F07 for ; Wed, 28 Jul 2021 13:32:32 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16SKWPX6001637; Wed, 28 Jul 2021 21:32:25 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DCC384604B; Wed, 28 Jul 2021 21:32:24 +0100 (BST)
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D0F5D4603D; Wed, 28 Jul 2021 21:32:24 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS; Wed, 28 Jul 2021 21:32:24 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.101.57]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 16SKWOcP027689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Jul 2021 21:32:24 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Peter Saint-Andre'" , "'Brian E Carpenter'" , 
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk> <032d14d3-74c2-6f49-8329-e85ae53f8f95@mozilla.com> <001c01d77658$f20f5650$d62e02f0$@olddog.co.uk>   <02390CF3-6221-436E-A1B2-C455D79A1C7B@csperkins.org> <1c1fea4a-ff85-3f41-ef82-b54fcf49ea58@lear.ch> <030e01d778e6$38f43a60$aadcaf20$@olddog.co.uk> <9ADF27F5-5547-489E-ADD0-5EB754179300@csperkins.org>  <75686766-49f2-1846-f068-ed7a4f16ad64@mozilla.com>
In-Reply-To: <75686766-49f2-1846-f068-ed7a4f16ad64@mozilla.com>
Date: Wed, 28 Jul 2021 21:32:22 +0100
Organization: Old Dog Consulting
Message-ID: <0c9601d783ef$abd4c770$037e5650$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJYLqiQ/XeTdq1mmedVrtykX7nyGwI9AqC2AbAelv8BWB++mAGhkz6xAYlQOM8CCCG87QF9q4AbAd/r7LEB6/Ca7QL/QP1pAatKnZsBfiYoS6moLbPQ
Content-Language: en-gb
X-Originating-IP: 84.93.101.57
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1018-26312.002
X-TM-AS-Result: No--6.946-10.0-31-10
X-imss-scan-details: No--6.946-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26312.002
X-TMASE-Result: 10--6.945900-10.000000
X-TMASE-MatchedRID: u7Yf2n7Ca/3kQwDXuLnCoXFPUrVDm6jtiRPU6vvejXJQKAQSutQYXPN5 fDkElfl7J0WYkEHcjVpYKJTez2dVwzeiGq2NlS7Fl5lQMzKmF9JMGTMF+LRLapfqSodqviT9Ek/ 8sJ2+/X8hWM5Ah1+TEVxwaswi32NxIgXwp4ASkATx5KZMlKYS/bh76O2wqfIqR+619nJBqrXF7r ipbWakCJulnxBQQcT6CqdTw5/yfAP1lam9TVHytgl6hIu1Dkfzma4CUKWJNLMzLmb0l2kucOMbu VzdyYYaBha/rZwVYuKlugrXm5IKcNIiC8HTcYSSx/Stmah0FpZ9LQinZ4QefNlsnjDZdeMWsOzO ncrmCoOOhzOa6g8Krcv+9r1u3R69XFmPtYXLmc91G6mkA7/VVJk/kSLzR2tpYcg4KK1u46lDDKa 3G4nrLQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jul 2021 20:32:38 -0000

Hi,

I'm pleased to see the direction this thread is possibly headed. It is
consistent with my understanding of what delegation should mean.

A

-----Original Message-----
From: Rfced-future  On Behalf Of Peter
Saint-Andre
Sent: 28 July 2021 21:21
To: Brian E Carpenter ; rfced-future@iab.org
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members

On 7/14/21 2:59 PM, Brian E Carpenter wrote:
> Also we have various precedents for (e.g.) the IAB appointing someone to
an external committee (e.g. the gazillion committees that ICANN seems to
have), by a process of the IAB's own choosing. So why don't we just say that
(apart from fixed maximum terms) it's for the appointing body to determine
its own appointment process, including delegation?

Without my editor hat on, that seems reasonable. If someone has a
concern with process followed by the appointing body, they can take it
up there.

Peter

-- 
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future


From nobody Wed Jul 28 13:36:18 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AA03A1F1B for ; Wed, 28 Jul 2021 13:36:16 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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=mozilla.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 haOmqOKJxhbr for ; Wed, 28 Jul 2021 13:36:12 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 08FFC3A1F1E for ; Wed, 28 Jul 2021 13:36:03 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id l18so4290356ioh.11 for ; Wed, 28 Jul 2021 13:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sDIUSLgBL59Y5fovqYNecIRioUQuHfIMQ+UZKUYBH/o=; b=enLZ5GUGTmdBM4ux1vWPAROppA2IVLb/s36JfO70FeDnJV2nC9G8Otj3BXz3p6Cb7s zoudj8T2l2Ln0FMbjVNE2CAia1O6DuYKKgckZniey9XI3hAD/hZM273JoI/Sy8pwa0Qz NuUL+nE4MhfF8SMm7KhqrqyO1Is3lbhvblj40=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sDIUSLgBL59Y5fovqYNecIRioUQuHfIMQ+UZKUYBH/o=; b=G40YzENPoGWXMYLE23UvTdkroqyGuAl1MDFDyKf2r+K087b6Mntkft4jNjFfaqYZqM 3OSw26CeLbMAtjONDzzsfS+JxpgEgb1mKMD+v2mPr2ujrSenmHtsTWHKFuP2jQuyClO+ L9z0bcP2Z8epwjCX1C45wbc9969uUeOIOlJUrih4oa1iu2Y2vtUg2oRxFfZtazq5Pv3P mGgAqxn2KZiWzNBU5BG3+5zCd2yt8nuCsP8pQwxBOf64lcUUYN9w8u42cxLKGUym8PTt zIauhd2IBSHdWyPdnKMKSviRGm28NzipdALn4UkQATv9SvvDThYXjvPFApnkdjF4M0XA A/Gw==
X-Gm-Message-State: AOAM533B39zWVxMiWYo9WMVnJDpNJsmtBieku58W6FI7HQ4vKlBbrpUp 2mWj6F5NwipllqCFU/in2OEGew==
X-Google-Smtp-Source: ABdhPJxUDG0H+2PU5mxKeteGcibr5efoQHt2iOcw8k/gatmjxL4VWl3AFwUFUfzuykMJTIFPwtJHHw==
X-Received: by 2002:a6b:f704:: with SMTP id k4mr1019002iog.191.1627504560082;  Wed, 28 Jul 2021 13:36:00 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id b15sm541493ilq.85.2021.07.28.13.35.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jul 2021 13:35:59 -0700 (PDT)
To: Brian E Carpenter 
Cc: rfced-future@iab.org
References:   <36572803-573e-c6d5-d9a1-7120479cd741@gmail.com>
From: Peter Saint-Andre 
Message-ID: <6ebc5ada-7d84-0987-9547-daf21ca8327e@mozilla.com>
Date: Wed, 28 Jul 2021 14:35:57 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <36572803-573e-c6d5-d9a1-7120479cd741@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Issue #73 Who is responsible for creating new streams?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jul 2021 20:36:17 -0000

On 7/16/21 3:12 PM, Brian E Carpenter wrote:
> On balance, I think this would develop into an enormous and very tempting 
> rathole if we attempted to solve it now, so I'd prefer to simply declare it out of scope and move on.
> 
> "The requirements and process for creating any additional RFC streams are 
> out of scope in this document."

Yes, this seems like the most sensible text to include.

Peter



From nobody Wed Jul 28 13:36:49 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF3F3A1F21 for ; Wed, 28 Jul 2021 13:36:47 -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 seS9-oxhHLUO for ; Wed, 28 Jul 2021 13:36:45 -0700 (PDT)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 515BA3A1F1E for ; Wed, 28 Jul 2021 13:36:45 -0700 (PDT)
Received: by mail-pj1-x102a.google.com with SMTP id j1so6964605pjv.3 for ; Wed, 28 Jul 2021 13:36:45 -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=B8GmhBUFnNI06MTf9oKNda2dTwfyOnBumZ9VC9KZwOw=; b=IsrSUB1zjWXn9C8tdC6pyRK4LFWXJ9bbwqS23J5+GpT5JoFKLQN4skOQZ9dmvneZdH di6tYnyKI5XrOcJxSRiRTGqdCbUs+AZ3C9mYH+q92NtcDH0h0oISGft6bsXS1WB0VHCH MqVuzAHMUSihThMuI7ZWtvBJqOAj6k56p1pdleNoZoxN4s9SKKAgrXrU9Ljrs4SyXvpL 6wCR0t3dd2ZB81Fcyyuif4fTQM34vmlyW64m9B+fmBkQF5WyEo4PCr5MF5LLHGX9wNhw enB++H2Mx9IMNszmYzVFG7/w3YqBudeTEWC7GhnLztsLhNJM+rcKrU8vk5kHmron7cg0 uLvw==
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=B8GmhBUFnNI06MTf9oKNda2dTwfyOnBumZ9VC9KZwOw=; b=RZEkrLOtY2LrKgO8tH2RwbdO6yLr61JPVw3pjJIDsO1w8E/SO0up2Ic68UwfA2WyRt 06BFfHjEcOg2XuoYAz3eN/ws9bPDZIe8OlCBzt9L2E4qep9KnIYUAOVP9ikMvj+pYhEL naZNxkOCpcTG6AY21RAoJhPZ7Kc0odjuFpE8BEbujolZtbNth8MVeGUhkm5XOlG13bte PFI5tlgy0VEpNCXiZ0NS7BQ+2b7Ft5+uFME5Da8nVYSZTIxVtXiGbjfY2sfSRWpqr9xV UZMHJa/zRKjVxoPREddrOMbF+kBwj+XXL88tH8rhPb7uRsrTkXR+XD0360BAtdCjkCKg iFnw==
X-Gm-Message-State: AOAM5330LoGyD7LOFxRD5WxPSH5l30GjuR/E3eJEjPBUHqQgzSvyl5Gv 1sgb88N0OYLP7hmAlhFe4F97N6+cMS9hfA==
X-Google-Smtp-Source: ABdhPJy3ji0mgh7WWgLadVNBN/uyQL7jxK/FI1V30ikKATom7i1cti2RVQkSwEHFu2WxwvsuJaCLcg==
X-Received: by 2002:a65:5a8f:: with SMTP id c15mr642424pgt.143.1627504604273;  Wed, 28 Jul 2021 13:36:44 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id d31sm823903pgd.33.2021.07.28.13.36.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jul 2021 13:36:43 -0700 (PDT)
To: Peter Saint-Andre , Martin Thomson , rfced-future@iab.org
References:    <5e9559ea-13c4-4ba2-93b8-65ef7e20c54a@www.fastmail.com>  <5c8a1eba-5eea-ff20-34b0-f6bd40258c4e@mozilla.com>
From: Brian E Carpenter 
Message-ID: <0a061486-efe5-6d14-79a5-3850f46cb7a9@gmail.com>
Date: Thu, 29 Jul 2021 08:36:38 +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: <5c8a1eba-5eea-ff20-34b0-f6bd40258c4e@mozilla.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Possible new issue: community review of performance
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jul 2021 20:36:48 -0000

On 29-Jul-21 08:29, Peter Saint-Andre wrote:
> no hats
> 
> On 7/25/21 8:09 PM, Brian E Carpenter wrote:
>> On 26-Jul-21 13:10, Martin Thomson wrote:
>>> On Sun, Jul 25, 2021, at 15:14, Brian E Carpenter wrote:
>>>> If community members, including the RSWG and RSAB, have concerns about 
>>>> the performance of the RPC, they can request that the IETF LLC look 
>>>> into the matter.
>>>
>>> I have no strong objection to the sentiment, but isn't this a non-statement?  Or is your intent to make it clear that RSxx are absolutely not authoritative in this regard?  (Just trying to avoid over-specification.)
>>
>> It's more of a hint than a specification. It doesn't allow anything new or create a new duty; it just makes it clear that performance issues don't necessarily come from individuals.
> 
> True, but then we could mention IESG, IAB, IRTF, and various other
> bodies (e.g., can a company that references RFCs in its procurement
> process raise concerns as an organization?). I feel like we might be
> opening a can of worms...

If so, it's a can of worms that already exists in reality. OK, try:

If community members or community groups have concerns about 
the performance of the RPC, they can request that the IETF LLC look 
into the matter.

I just want to remove the implication that only individuals would raise concerns.

   Brian


From nobody Wed Jul 28 13:40:35 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB523A1F3F for ; Wed, 28 Jul 2021 13:40:33 -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, 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 (1024-bit key) header.d=mozilla.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 8pa_m_eg0zIi for ; Wed, 28 Jul 2021 13:40:30 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 5B9853A1F3D for ; Wed, 28 Jul 2021 13:40:30 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id r6so4329883ioj.8 for ; Wed, 28 Jul 2021 13:40:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=WaknR69CiQDDoFIdTvAn3lZIgNUJe2yMnEZyyWOW6qg=; b=EGOVZ6b8qx2u8cg5AFzeBn/m5uERJyJZq4GmV3LraKxeE/rgIh08cwbYBEs8su5Xd4 bfSuxB5q/G7C/2C4xhN2RHSzfGTxC/0sQW7c/YSjaDLGbUbLD5pdgqizGGdqBIRoiy5L CvfYzWv8xpTaJdBVXEiVHVQeCVWkGXHE8O33M=
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=WaknR69CiQDDoFIdTvAn3lZIgNUJe2yMnEZyyWOW6qg=; b=f+HHpOB6sb6J5dIC8i3OtWn5gDykNbnKAHnORfWdoZWlT286ZFEMLlkWIiXfxja5vU 2pjQ06RhgD0YaNL2A4LHGjTc/BIY2x67CyAWZrA8ONrqVdJKxujPl3LCGUqXtH5d5aQz p55UYAAwVVsT5eBelMiVZc2gpoo9K7XKoVmfsb0uWgDyQfEjmPLUqQxDTgd+aCYlGqY6 D+QsBxeBmhbc60G5hvKo6GKQJu6MQp6TG/or5jbtvBbifgTseKo4sBtCOKVx9RIzRiqu EOsM/Wkb2b1UVSnrw1f5H7qkzRufs0ljGiQQ5XLz4LnlFjTvZtngVPz1j2dKILSBj/7+ vnEQ==
X-Gm-Message-State: AOAM531BIresApAWZCt/TdJb4VfTgv+TiWCjZrd7gvQCPI/N8t6+1hxg xvs7CwMlS82Ah1BPZvHr9W5Wdg==
X-Google-Smtp-Source: ABdhPJwZfGlI3Efz8q06Fv7PvCNuwDTdJ+VpTeV6yNqc83t06jE+Xmm6LNtk1kl5T7L7Fy597wt3eQ==
X-Received: by 2002:a6b:8d0d:: with SMTP id p13mr1085500iod.8.1627504828043; Wed, 28 Jul 2021 13:40:28 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id t15sm596050iln.36.2021.07.28.13.40.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jul 2021 13:40:27 -0700 (PDT)
To: Brian E Carpenter , Martin Thomson , rfced-future@iab.org
References:    <5e9559ea-13c4-4ba2-93b8-65ef7e20c54a@www.fastmail.com>  <5c8a1eba-5eea-ff20-34b0-f6bd40258c4e@mozilla.com> <0a061486-efe5-6d14-79a5-3850f46cb7a9@gmail.com>
From: Peter Saint-Andre 
Message-ID: <72c96405-fab0-f70b-53d5-3be6d753cce3@mozilla.com>
Date: Wed, 28 Jul 2021 14:40:26 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <0a061486-efe5-6d14-79a5-3850f46cb7a9@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Possible new issue: community review of performance
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jul 2021 20:40:34 -0000

On 7/28/21 2:36 PM, Brian E Carpenter wrote:
> On 29-Jul-21 08:29, Peter Saint-Andre wrote:
>> no hats
>>
>> On 7/25/21 8:09 PM, Brian E Carpenter wrote:
>>> On 26-Jul-21 13:10, Martin Thomson wrote:
>>>> On Sun, Jul 25, 2021, at 15:14, Brian E Carpenter wrote:
>>>>> If community members, including the RSWG and RSAB, have concerns about 
>>>>> the performance of the RPC, they can request that the IETF LLC look 
>>>>> into the matter.
>>>>
>>>> I have no strong objection to the sentiment, but isn't this a non-statement?  Or is your intent to make it clear that RSxx are absolutely not authoritative in this regard?  (Just trying to avoid over-specification.)
>>>
>>> It's more of a hint than a specification. It doesn't allow anything new or create a new duty; it just makes it clear that performance issues don't necessarily come from individuals.
>>
>> True, but then we could mention IESG, IAB, IRTF, and various other
>> bodies (e.g., can a company that references RFCs in its procurement
>> process raise concerns as an organization?). I feel like we might be
>> opening a can of worms...
> 
> If so, it's a can of worms that already exists in reality. OK, try:
> 
> If community members or community groups have concerns about 
> the performance of the RPC, they can request that the IETF LLC look 
> into the matter.
> 
> I just want to remove the implication that only individuals would raise concerns.

Understood. I suggest the following small edit so that we avoid
confusion about "community groups" (which are a thing in other SDOs):

  If individuals or groups within the community have concerns about
  the performance of the RPC, they can request that the IETF LLC look
  into the matter.

Peter


From nobody Wed Jul 28 13:54:13 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DBA3A1FBB for ; Wed, 28 Jul 2021 13:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVmJhqhbDw8P for ; Wed, 28 Jul 2021 13:54:09 -0700 (PDT)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 33F9E3A1FBF for ; Wed, 28 Jul 2021 13:54:09 -0700 (PDT)
Received: by mail-pj1-x1031.google.com with SMTP id u9-20020a17090a1f09b029017554809f35so12001835pja.5 for ; Wed, 28 Jul 2021 13:54:09 -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=yYp+VBZWO7alP9tRzsT8HO0KuquJICIawx15G6X3Ha0=; b=o20vzJYQTD1P00YE0/0UuYBtfxZn+wDAIdN43mwxFmdQ36WaSD99PvqksUcxtEGx6P XeKTp1Ac140fZMforLkkYRLKVk/wuFHi2amjQFDgZK8ja9KMiyuhl386PgNY7pmqTarD LJkknYidAgTWMFCjahIyLqIQJYwQCVtBy2M6yweN0rVW/U1fnGCM789lrURn5ObMF5o0 MRjacvMF3CqmcaG3e/eou7V4rRNQJM4C3zZ8DNHuS8y546E2Q5Z/yp8NdVnHakKmTK6R L5nZt45CjQsJacPWVWLLKMNHk+1+j3mhdQfMuwhM44/eFrxXXcl8rYlsP+fIU2iFOzDW ey8w==
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=yYp+VBZWO7alP9tRzsT8HO0KuquJICIawx15G6X3Ha0=; b=oohHM30jtAucd/9Uy47blrMvrfJcdXw5R0rsanVERxfE4tk3rsLfB6u2yandAHIpbp tF8Rr1zKTBb4mBZiHFtRyAUoz47xLNer1BSWPfhUFTxiZXQgG+rD9uaMX5YQrjtUOK5V 6o9nL1d1X0hY0DtWmOEr4I/vVAf+x6V8c3j8J9DjlRbWbF2934ZzSPSnQ55QxdVvxIXE og2l8iusbdtjHf1urTD5PX5ohvcVV9/MNyCRviQfc+fClWeM56E4uwVKH8eThoRlFB1a Tzs4h2BYwe6+rqQkFHZALkDSM2m/diemupGhUMLj4F69PCTAlzSZ955nV/bNfDGBbUdu PXkA==
X-Gm-Message-State: AOAM531Rh047hWY4UJaPZ5xdFXKbEIyNem6jlhLSDdr95N+FU1Svf6Gl sFsBte9p5opg3VyUeDHyNBNfW2111Vx5ig==
X-Google-Smtp-Source: ABdhPJx+UFaINl+S3cFJfdt1N0TOHvCaSKmiePVyvimXovyJ3nzGQIN8F0FhYk5onrM2p2SZDjclYQ==
X-Received: by 2002:a17:90b:4b08:: with SMTP id lx8mr1646500pjb.66.1627505647648;  Wed, 28 Jul 2021 13:54:07 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id w15sm615599pjc.45.2021.07.28.13.54.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jul 2021 13:54:07 -0700 (PDT)
To: Peter Saint-Andre , Martin Thomson , rfced-future@iab.org
References:    <5e9559ea-13c4-4ba2-93b8-65ef7e20c54a@www.fastmail.com>  <5c8a1eba-5eea-ff20-34b0-f6bd40258c4e@mozilla.com> <0a061486-efe5-6d14-79a5-3850f46cb7a9@gmail.com> <72c96405-fab0-f70b-53d5-3be6d753cce3@mozilla.com>
From: Brian E Carpenter 
Message-ID: 
Date: Thu, 29 Jul 2021 08:54:02 +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: <72c96405-fab0-f70b-53d5-3be6d753cce3@mozilla.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Possible new issue: community review of performance
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jul 2021 20:54:11 -0000

On 29-Jul-21 08:40, Peter Saint-Andre wrote:
> On 7/28/21 2:36 PM, Brian E Carpenter wrote:
>> On 29-Jul-21 08:29, Peter Saint-Andre wrote:
>>> no hats
>>>
>>> On 7/25/21 8:09 PM, Brian E Carpenter wrote:
>>>> On 26-Jul-21 13:10, Martin Thomson wrote:
>>>>> On Sun, Jul 25, 2021, at 15:14, Brian E Carpenter wrote:
>>>>>> If community members, including the RSWG and RSAB, have concerns about 
>>>>>> the performance of the RPC, they can request that the IETF LLC look 
>>>>>> into the matter.
>>>>>
>>>>> I have no strong objection to the sentiment, but isn't this a non-statement?  Or is your intent to make it clear that RSxx are absolutely not authoritative in this regard?  (Just trying to avoid over-specification.)
>>>>
>>>> It's more of a hint than a specification. It doesn't allow anything new or create a new duty; it just makes it clear that performance issues don't necessarily come from individuals.
>>>
>>> True, but then we could mention IESG, IAB, IRTF, and various other
>>> bodies (e.g., can a company that references RFCs in its procurement
>>> process raise concerns as an organization?). I feel like we might be
>>> opening a can of worms...
>>
>> If so, it's a can of worms that already exists in reality. OK, try:
>>
>> If community members or community groups have concerns about 
>> the performance of the RPC, they can request that the IETF LLC look 
>> into the matter.
>>
>> I just want to remove the implication that only individuals would raise concerns.
> 
> Understood. I suggest the following small edit so that we avoid
> confusion about "community groups" (which are a thing in other SDOs):
> 
>   If individuals or groups within the community have concerns about
>   the performance of the RPC, they can request that the IETF LLC look
>   into the matter.

Yes!

Thanks
   Brian

> 
> Peter
> 


From nobody Wed Jul 28 13:56:53 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24B3A1FEF for ; Wed, 28 Jul 2021 13:56:52 -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, 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 (1024-bit key) header.d=mozilla.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 9sL98XZ1s9Lk for ; Wed, 28 Jul 2021 13:56:49 -0700 (PDT)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 14EAB3A1FE6 for ; Wed, 28 Jul 2021 13:56:48 -0700 (PDT)
Received: by mail-il1-x131.google.com with SMTP id r1so3670411iln.6 for ; Wed, 28 Jul 2021 13:56:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QGgahphTEI1lMOiH+bU14T9BF2E5kjbloDsYLtr3Ob0=; b=f5elieg8OnsEV5RwO3SYhUA3X9DOCtkYgEey4+2PAQMwnEkA3dS0M751Ozeze+3V5I TwXvgPK91rQ4SKrKwjV8JlwbYvRhyrz2Vv0Np/eCxj1RU4iTkxtEbvNffaJfF/pIdllj IFuvOVv+nS97PCwr5VKnv/neQqcwshrEC3BmI=
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=QGgahphTEI1lMOiH+bU14T9BF2E5kjbloDsYLtr3Ob0=; b=XSBC0JaM1k95+0gasfMPJF2KwwdUCtNzu8mAqZvNHwwf0pZXsIfWyMX56dpLfhLTfk CIassYtD+S4Fgat6lAtnJykT4LJUXb9wqPZyeUGKDqGh+cO25mkx4fCxSEXrzy1FdVnb hxJXiZKfvGELNZfzJjABrPlEerBfLLsPIc3PYN7k0dA4vmEFDuXr//lZOZRPYmrsTrfj K/xFE2qVQp/sBbSm95qhKYf0AnbdEXXgzGdlCadem23xr+C9/jlGtLp6vxJOkUJhLCVr U3FeZ//9nFMb8N+hnOrmEDqlY+1flqmDBn48EOO86UiR8BfzPrLL+czx/ITydvz9raXT m2+Q==
X-Gm-Message-State: AOAM530q8IrRVlhwE/beWQb51mQtV1nydL+XbqIS6uPo4FYB9F7CieBG DMg9WMiy6x666LYix2hSuMp/8A==
X-Google-Smtp-Source: ABdhPJyCJU/GRYcs2i7vxr8LFkR0EKwjx8JiXWTHmTC5stTKCPjkauF4nqcc4SKSgdY5Za2Foyxr2Q==
X-Received: by 2002:a92:d3d1:: with SMTP id c17mr1129556ilh.86.1627505807182;  Wed, 28 Jul 2021 13:56:47 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id u10sm824873iop.15.2021.07.28.13.56.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jul 2021 13:56:46 -0700 (PDT)
To: Jay Daley , rfced-future@iab.org
References:  <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>    <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com> <086c5844-ef49-4221-94f2-67408182c6a6@it.aoyama.ac.jp> <3b86de0d-6823-c740-7928-4258a420d990@gmail.com>    
From: Peter Saint-Andre 
Message-ID: <90a718cd-0b75-86e2-3c31-2ba66a37457f@mozilla.com>
Date: Wed, 28 Jul 2021 14:56:45 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jul 2021 20:56:52 -0000

[ no hats ]

Overall this looks good. One question below.

On 7/27/21 4:48 PM, Jay Daley wrote:
> Eliot asked me to propose some additional text to close off issues #56,
> #57, #61, #62 which I’ve done below.  It doesn’t have the elegance of
> Peter’s prose so may require some work to align with that.
> 
> Much of this is already covered in the latest draft at:
> 
> https://github.com/intarchboard/program-rfced-future/blob/master/draft-iab-rfcefdp-rfced-model.md#roles-and-processes
> 
> 
> My suggested additions are in red and my suggested text moves are in blue.  
> 
> Jay
> 
> —— 
> 
> ## Role of the RPC
> 
> Publication of RFCs shall be continue to be handled by the RFC
> Production Center (RPC) function in accordance with high-level
> policies currently in force or yet to be defined following the processes
> specified in the foregoing sections of this document.
> 
> ### RPC work program
> 
> The RPC follows a work program based on requirements it has gathered
> from a variety of sources, including policies that have been through the
> RSWG/RSAB process, and from direct discussions with the RSEA, stream
> managers, IETF LLC, authors and other IETF participants.  In developing
> this work program, the RPC makes some key decisions which impact the
> IETF community:
> 
> 1.  For each requirement that is gathered, can it be directly
> incorporated into the work program or must it first be subject to
> community consultation.
> 
> 2.  Setting the relative priorities for the various requirements within
> the work program.
> 
> 3.  Determining if all the important requirements have been gathered.
> 
> It is likely that the RPC will require advice during the drafting of its
> work program, which it should seek from at least the RSAB and if
> required, the chairs of the RSWG.
> 
> In order to ensure community oversight of the RPC work program:
> 
> * The RPC must present a draft work program for community feedback at
> least annually and then publish a final work program incorporating any
> agreed feedback.

One could envision challenges here along several dimensions:

1. Timeline. When does the RPC publish its proposed work program? How
long is the comment period? How long does the RPC take to consider the
feedback and publish a final work program?

2. Feedback. Does the RPC need to merely take feedback under advisement
or are they under any obligation to address it? What is "agreed
feedback"? If a community member feels that they're being ignored, would
they raise concerns with the LLC?

Peter


From nobody Thu Jul 29 16:03:48 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E45B3A0D9B for ; Thu, 29 Jul 2021 16:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.348
X-Spam-Level: 
X-Spam-Status: No, score=-12.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DNWJGaVC; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=CIespZbQ
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Y9LsjnByWQC for ; Thu, 29 Jul 2021 16:03:38 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFD73A0D96 for ; Thu, 29 Jul 2021 16:03:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1392; q=dns/txt; s=iport; t=1627599818; x=1628809418; h=from:to:subject:date:message-id:mime-version; bh=7prgw39ty6GGq9+dvIho5iKeSJ7nqeO3P6s2o8a6vYc=; b=DNWJGaVClqCAlMM9mdVtXNIoXK5PM3a8CV7a/mfU6HuERpVP35YRvnJe pu7bN2XeJgPYinVwKwbzBivu+B9h4VtgrDfu2wxJNRAeLnLf9DhA3CHrp qvmehhEUwZjB7XzdqtxMNAQaAANflKdAFBAKnYJcYFHTII4ApdYhI1RDZ I=;
X-Files: signature.asc : 488
IronPort-PHdr: =?us-ascii?q?A9a23=3AJAg5oBTNEEqtuETaPRjnGhyf4Npso6XLVj580?= =?us-ascii?q?XJvo7NHeOKk5ZuxdEDc5PA4iljPUM2b7v9fkOPZvujmXnBI+peOtn0OMfkuH?= =?us-ascii?q?x8IgMkbhUosVciCD0CoLffgKSsgE5cKWFps5XruN09TFY73bEHTpXvn6zkUF?= =?us-ascii?q?13/OAN5K/6zFJTVipG81vu5/NvYZAAb7Ac=3D?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AV3sAbqOdrYV6xMBcT3f155DYdb4zR+YMi2?= =?us-ascii?q?TDiHoRdfUFSKKlfp6V88jzjSWE8gr5K0tQ5OxoWZPwDk80kKQU3WB/B8bbYO?= =?us-ascii?q?CLghrMEGgA1/qt/9SDIVyEygc1784JGMISZKySfDpHZK3BkW6F+qMbsaC6Gd?= =?us-ascii?q?eT9IHjJhlWPGVXQpAlyz08JheQE0VwSgUDL4E+DoCg6s1OoCflUWgLb+ygb0?= =?us-ascii?q?N1HtTrlpnurtbLcBQGDxko5E2lljWz8oP3FBCew1M3Ty5P+7E/6mLI+jaJpp?= =?us-ascii?q?lL8svLiSM05VWjqqi+q+GRjuerw/b8zfT9Hw+cyDpAor4RHYFq8gpF+d1Ho2?= =?us-ascii?q?xa7OUk6y1QQPibrUmhJl1cZXDWqlPdOPFE0Q649bbQuwqTneXpAD09EMZPno?= =?us-ascii?q?Rfb1/Q7Fchpsh11OZR03uerIc/N2KKoMxsj+K4KS2Cu3DE6EbKq9Rjx0C3kL?= =?us-ascii?q?FuHYN5vMga5gdYAZ0AFCX15MQuF/RvFtjV4LJTfUmBZ37Us2FzyJj0N05DUy?= =?us-ascii?q?uuUwwHoIiYwjJWlHd2ww8Rw9EehG4J8NY4R4Nf7+rJP6x0nPVFT9MQb6h6GO?= =?us-ascii?q?AdKPHHQFDlUFbJKiafMF7nHKYINzbErIP2+qw84KWwdJkB3PIJ6eL8uZNjxB?= =?us-ascii?q?kPkmfVeIGzNbFwg2PwqVSGLEDQI5tlluhEU5XHNcjWDRE=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CREgB3MwNh/5hdJa1agQmBWYFTUQe?= =?us-ascii?q?BUTcxiA8DhTmaMgOIX4JTA1QEBwEBAQoDAQFBBAEBh1kCJTcGDgECBAEBARI?= =?us-ascii?q?BAQUBAQECAQYEgREThWgBDIZbLgEBOBEBgQAnBCEUgk8BglUDLwGdfAGBOgK?= =?us-ascii?q?KH3iBM4EBggcBAQYEBIJRgkgYgi0HCYE6gVOBKYZSJYQiHIFJRIEVJxyDIIg?= =?us-ascii?q?Rgi6DIYFZAkShIZ1tCoMmBYEthAmDBpV/BSaDUQERi1+XIZYLoHEBhBwCBAI?= =?us-ascii?q?EBQIOAQEGgXYlgVlwFTsqAYI+PhIZDpIQil5zOAIGCwEBAwmKUAEB?=
X-IronPort-AV: E=Sophos;i="5.84,280,1620691200";  d="asc'?scan'208";a="916781623"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jul 2021 23:03:16 +0000
Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 16TN3G9u015496 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 29 Jul 2021 23:03:16 GMT
Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 29 Jul 2021 18:03:16 -0500
Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 29 Jul 2021 18:03:15 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 29 Jul 2021 18:03:15 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l6JNw4R4D8bynj81kHeHHDr/iNg4BlrhC6fRgE189eAyb+3eQaGITkoGp7GJr6/FzBbtGqW5SI4RJrUCYAC4sx/+RyVLDPNZAIiBv0gjSq+YR0+sBCyNgqHiWDWxEg0nmUMruzBBbTneEMqIpyYnQ1MpF4dvyw2roThnAFtnMMRDmvtq/KqPESKxtaPyKygGBGm9bmKpucN9rgX3sJGTJqlhe3fAR/ZhEHNk4ONJ6Ui/RAf8lJDUBcEU0T4cj5AM7PB8Wp9BBLf39DB9Aqe+FiuyP4OhZFd7zg8Vken9CuK2r1R5JMs4u5D1RIklNrZVqDneslULEXI0FP5rvQ36kA==
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=HYd9rN7NUx0LWCDYBY3RiBE1MCQRJHKpITFjjgpwGI0=; b=NEUkg8VLhHLscLn2j6BBRqBeISYZGpKmhlMrxv88AQi+Eqzlj2knbiJJ3H8fPDsNMnBYYSHAfzE8Nu4T6T996LnVKgdd3bpgd6Y+qCnhKAr90Hq0wRrsCha7cj2u5cF/n5pMZTp3h3bjz7oMQMJfwrNE93bVsDvz2znQODi29jRheduOMyUXkYimdstPCgvrG/ZR/4VUVK7hPbI5pgDlg1gJ8qKtFOaTvjhRrKMFGN3UUSWKSVcKcCQ2U9fBLx0aMZo3UItA7aX/G/tRp6tK4QEJYBvVnjkygsr6dcEirlSW6Al0PYMlxBvyzip4zgX/co+gENxvVh0YxiBqef1AMw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HYd9rN7NUx0LWCDYBY3RiBE1MCQRJHKpITFjjgpwGI0=; b=CIespZbQiPSgZhO1pD0NTCIlomXf/pmFpg/kx94AWd4o6eMzih3rBYb2zAxHawD6XJTq6m1BbpcSw2d9DdQQpv0mAqsUabwnKYGpf5gGpj8UyDMV3nlsLJmCmEsjDFwR6V3qwcibYxr/53OfX7X5eXOJzMzgCOqfTiT3OBJOtuA=
Received: from DM4PR11MB5247.namprd11.prod.outlook.com (2603:10b6:5:38a::20) by DM6PR11MB3641.namprd11.prod.outlook.com (2603:10b6:5:13b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18; Thu, 29 Jul 2021 23:03:09 +0000
Received: from DM4PR11MB5247.namprd11.prod.outlook.com ([fe80::2c18:ec30:b24a:ce1e]) by DM4PR11MB5247.namprd11.prod.outlook.com ([fe80::2c18:ec30:b24a:ce1e%7]) with mapi id 15.20.4373.022; Thu, 29 Jul 2021 23:03:09 +0000
From: "Eliot Lear (elear)" 
To: "rfced-future@iab.org" 
Thread-Topic: Consensus check: issue 38: RSAB appointees 
Thread-Index: AQHXhM3mj+gOhH9h10Sz9Oi75w4qeA==
Date: Thu, 29 Jul 2021 23:03:09 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3654.120.0.1.13)
authentication-results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 797f64cc-2a3a-4737-bc8e-08d952e508b2
x-ms-traffictypediagnostic: DM6PR11MB3641:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1Z10UORqXxFvQ21kC+JOyQQ8vMpvu5hxNedFgbBjAq0Y/LyhFwJwTq18CT7RAr3FIHIEuxBJVh0kMlTw30cfEZV0GTBs5bk6IwGMcIOumhoCPlVhfi5tCdDBxEgFdDsg4wScGC6jxcy9XRpnOLyjSB0OmniIetmqFQrg9ev55AUb8+sjT/sbFTKGO2KeTpICrucxLk/qcA3htPoNKC5hYpOcB+Dyv5uilDJG2AVbbBtn27sokn0Ke2Tzu5M94jp2cyeOEawACizP7Q1sAySI3HUTwNlpKXoRovE6810tma04FnGl//XtDhday0CArDmMuFgHKa09kjgQdictmdPFMCCrc7tpzmWtzxiv8PA4uPuTLGoh1Wy0Zrft+9JETNXSFfitnyGEt7SsG4YS2liBw4MjLd2pgT+9F8YVCup4CaXfMrwF3MYjSRJlDvFLni5NwmOFbqHMgWo2c0Lj1H/sfDKevSvZPHWoCihi6/BQLKK7XG3/vRgiDZi4z49hSHZIHFu4bbU8DV2N8w24lOQ90uiDZltbOWeMMcmGfxMnJtwBAb579+nHALyqc9HtP/350UKZDZYF6RaYjtg3SfMt+Pp/4H3F6DiCo4v0OlFDUxdRqhUKt3UTTXAOMDlbV5DGJ4muSGbq71qKnCjy9xr+HoyK2MYzWvzDSOl4kVKfR1vRKHFkh0gmJZXZewgO6x7HbcW2RBJN7s+BOL8uR3TDvAYH7rW1GupaBRId0na9DhW1xiAYq1j+p7WshXyWJvS6
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM4PR11MB5247.namprd11.prod.outlook.com; PTR:; CAT:NONE;  SFS:(396003)(366004)(376002)(136003)(39860400002)(346002)(122000001)(6512007)(8676002)(478600001)(38070700005)(316002)(86362001)(38100700002)(4744005)(8936002)(5660300002)(33656002)(2906002)(71200400001)(186003)(36756003)(76116006)(6506007)(91956017)(99936003)(66556008)(66476007)(66446008)(64756008)(66946007)(4743002)(2616005)(6916009)(66616009)(6486002)(45980500001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ItO5OXWGVdxki2tcHxP3VAs9v3H5wqz6+Zli8TZRlcB+iNXPsD6BUZ7JEWkW?= =?us-ascii?Q?Ih0W05bqFWVCXmOGE4igY8/zEJedpGost3jMTfaem7T1dWmFVBC1ByciU8Cl?= =?us-ascii?Q?sGA2LyzjepFBIqSj3+534imAlTmwrASGU4xAFscKy9ICbNwCzbTU1CV1zljH?= =?us-ascii?Q?Y3eGbPr7+SmkjFLV7b35EtgAcWn+aQnoizydw5ufwkKR/0urt8vD6gwxy/Li?= =?us-ascii?Q?0qGKuHD+0dV3fKv6dWW/bQIdafAZ4R1kKFJ2zP7lEsrOYwR6ecMRAHXpmOui?= =?us-ascii?Q?NzTIMrilipW0yIUcUdHLvt24ZDMA0O40PJo8SQQS8u1SKZitaeS1yQV+AIQL?= =?us-ascii?Q?xCxqXYg0n/WwsMwxA4O3tkLUdzMwrogMnnCACxlqLpcuH4ZYnBochrbsDkQU?= =?us-ascii?Q?O4oyCnxVCXOgZkdHcU5fgG2orr1B5cxm5oHxyoG/3utefcsy5iCId/0tDsgf?= =?us-ascii?Q?NTIyPn7Y2J3U2WHVDgUqPeFhvuWO4s61AWGWNvfLEJuAVoV44eomS3UGAzKf?= =?us-ascii?Q?N5M3weGe/jXHWs6kN2nBKd2K+0Gx6jl1p+E+IeCImIPXEseSlQXg1jL096bk?= =?us-ascii?Q?6wPS3kBonQxgQJvB5N7vyRCLKpoNGcuxPaAYNMAco6ykVlrxyIafrn+hPxBV?= =?us-ascii?Q?HKuQzyRxIkI/5SdZI965qik/QByN3VQah5ewvOLF83GBRTMiNRPNhPJOdSXz?= =?us-ascii?Q?tZhwD1zg53d8NsgO2wU2ila8VidRF3ZFMR39hIrlvdMLltqFbdiOfgmZWixs?= =?us-ascii?Q?j68KwAbme8M2145T1oFIoSHjiCWsUDWKA2qVPvThiJ0yHB8T/t+pZfrQ7o6C?= =?us-ascii?Q?KBOUiD40Ik0lS7A4w2SqUgk0YAX6nx/OoTz9hKPfBSxxlv54sADAd4AVwA/K?= =?us-ascii?Q?ZmYBN5KQRtnbx3TQP/4+DM57JGRJXXRq3rCkmhqFiPeCK0gmoARa0dwma3Dl?= =?us-ascii?Q?YzyxbOhZZhUXuYns1Uehuox6BS6ZRDTFkqt8JckodTeR3K2hzKu1Bn5kTjqQ?= =?us-ascii?Q?l4ZYr/G4OFaMjkJ7+wqMKdKS/n1/k/65AuLVM+AjCXdsBTQV6AoDBHtjFV+o?= =?us-ascii?Q?c1qeXmlwH9BZVVEZ9AGQBgRmQBgjvpdtsOe+uvvi0h7mF3e9QQU8gvpDy/6C?= =?us-ascii?Q?S+XOYPQ+wlkviHAQOklclbQyrIn6lB9Di8Y0kJ5d3jn+gLyJCzji893CFf91?= =?us-ascii?Q?+MeD9rlnaWtGZuS2XJvk8IN9lQCdrz5OLKS7BhkvphvQMvM+pJ5ZzXeepefN?= =?us-ascii?Q?IcXgamBSF7F40gROgdj8zhBEZyI9OHvQBP5YxIBoVvXd9dz+THXfyBNCY+y4?= =?us-ascii?Q?zsq0s+YfeluopZ+DFmqEAHqJDn+Z1M4gSVCiIywOp1fRL+8wuouX2B/VSz1N?= =?us-ascii?Q?+PSIPkM8LrP46MiKp/yConbGxjUVSHOUi1HjeUcsIm+8sAfCVQ=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary="Apple-Mail=_E79BFC4E-2DDD-4591-ADB6-DA7546598AD2"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5247.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 797f64cc-2a3a-4737-bc8e-08d952e508b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2021 23:03:09.4723 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AeNeusKE+vjXgzDjzZUvsXnPD1PGT5RLeEk4G0PWukMknE2pehdPuMWQRO/Dprv7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3641
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: 
Subject: [Rfced-future] Consensus check: issue 38: RSAB appointees
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jul 2021 23:03:45 -0000

--Apple-Mail=_E79BFC4E-2DDD-4591-ADB6-DA7546598AD2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This is the first of several emails on consensus checks for the issues =
we discussed and have what we think is at least rough consensus.

On this issue 38, based on discussion on list and in the meeting, we =
think we have consensus that the appointing bodies should establish =
their own policies as to how their representatives are appointed.

If you disagree, please could you comment by the 13th of August?

Eliot


--Apple-Mail=_E79BFC4E-2DDD-4591-ADB6-DA7546598AD2
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-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEDM6wACgkQh7ZrRtnS
ejPEmQf/UMV7wekmlvK/FmjRfQSr8oebt5FyCgM2tmWYiLC72uAkYq8IeYgaPonS
jw1uuxtu1Q6YL4JnCAuMR+U/f7uQEY41TcSB1z34YYyxNH/2Wis94o6onrXb/O1r
7B8CyDUGgpz3oej91PxCSRlGl+uPVQ9CisiK2WA6EPYWarTqZYyRAOpIGe1aPebc
vWgg3Fq1EavD+PV6uaQQhwLBUnV4ONtt/NhQo7rtPtrBYGSnnMRxIi+8Xi51J13g
66gUOtLpaX//mDodgiCN8bt/wRDUKMLdn4FwD44C7GZdrlUxcJct0MJ67dOLAMaT
e1tuUL747GySeUrwJj+X/rSoW6M2Hw==
=7qzE
-----END PGP SIGNATURE-----

--Apple-Mail=_E79BFC4E-2DDD-4591-ADB6-DA7546598AD2--


From nobody Thu Jul 29 16:07:55 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D38C3A0DE7 for ; Thu, 29 Jul 2021 16:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGPON6yUqufn for ; Thu, 29 Jul 2021 16:07:51 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 B48273A0DE0 for ; Thu, 29 Jul 2021 16:07:50 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16TN7h1o096727 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 30 Jul 2021 01:07:43 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627600063; bh=L7aYmwa5Mqf9fZd/cgiW9whuv/qAKKQD1r1jcljZ4iQ=; h=To:From:Subject:Date:From; b=kvdc2YPNj52+8iXlL9T+h7RO5reTYH67xuFntfJOmAs8h90RbsWaCT9YXCCXCB1Ol Jdc93ZdjL7YOsnK63WwQKEXF4s86s0ng1mpAVc82ukgiQF2IxbnbtKbLqFo5p1W5lT glChQOtTSLALmtgElKqgltBOIv56h+px9LaAr5Kk=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: 
Date: Fri, 30 Jul 2021 01:07:41 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qbQoNGs2jpnBYusUNTWKAa7HtDSwthrpN"
Archived-At: 
Subject: [Rfced-future] Consensus check: Issue 55 Suggestions for ongoing evaluation of RS[EA]
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jul 2021 23:07:54 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--qbQoNGs2jpnBYusUNTWKAa7HtDSwthrpN
Content-Type: multipart/mixed; boundary="fmhQlkpaEN06L0qS7jbm3FKZ3cE3X7qK2";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: 
Subject: Consensus check: Issue 55 Suggestions for ongoing evaluation of
 RS[EA]

--fmhQlkpaEN06L0qS7jbm3FKZ3cE3X7qK2
Content-Type: multipart/alternative;
 boundary="------------4A1666A397D06770C5F1E924"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------4A1666A397D06770C5F1E924
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

In today's call, Jay indicated that he wanted to have some sort of=20
confidential review of community feedback relating to the RSEA=20
performance.=C2=A0 What the group came up with on the call was the follow=
ing=20
process:

 1. Community feedback to the LLC
 2. LLC produces a draft performance evaluation for the RSAB (excluding
    the RSEA)
 3. RSAB (excluding RSEA) provides feedback back to the LLC on that
    evaluation.

If you disagree with this approach, could you comment by the 13th of Augu=
st?

Eliot


--------------4A1666A397D06770C5F1E924
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  

    
  
  
    
In today's call, Jay indicated that he wanted to have some sort
      of confidential review of community feedback relating to the RSEA
      performance.=C2=A0 What the group came up with on the call was the
      following process:

    
    
      
  1. Community feedback to the LLC
    2. 
      
  2. LLC produces a draft performance evaluation for the RSAB
        (excluding the RSEA)
    3. 
      
  3. RSAB (excluding RSEA) provides feedback back to the LLC on
        that evaluation.
    4. 
    

    
If you disagree with this approach, could you comment by the 13th
      of August?

    
Eliot

    

  


--------------4A1666A397D06770C5F1E924--

--fmhQlkpaEN06L0qS7jbm3FKZ3cE3X7qK2--

--qbQoNGs2jpnBYusUNTWKAa7HtDSwthrpN
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEDNL0FAwAAAAAACgkQh7ZrRtnSejPx
LwgAqDOL2rLRhZFdMUcmHA5NnSKooXrP+/m2XndzyqjyHYWffaS57VzV7Vuf5vI+8biccbhCdAL0
LOffFhucKxLfd+nhjTwMuCNm5SzS8csltMHZTchR9/LwyVfekrVkDxwpKrpcxu6whS602KmsuVCk
CkT96jombgttfcij/MS2wDXddGoL6lKtJW1ErUHpfLwuSaMlk7clO4nj7h55ZaBZ8DiVcfCIHUMk
6FPwUSuADAum694nxFF5o9x7BEiU1hbhsXV7hBAlPr15ztMKMgXaF33VTPshLZCGhpul4Gfa6V6c
n7u/3W7MSlXCaCE+BpwxDzkSTIR3YWNMpFOtjLL/fw==
=mLF1
-----END PGP SIGNATURE-----

--qbQoNGs2jpnBYusUNTWKAa7HtDSwthrpN--


From nobody Thu Jul 29 16:11:20 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BAC3A0E37 for ; Thu, 29 Jul 2021 16:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8upBZp_W5ZC for ; Thu, 29 Jul 2021 16:11:16 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 475AB3A0E32 for ; Thu, 29 Jul 2021 16:11:16 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16TNB8WT096835 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 30 Jul 2021 01:11:09 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627600269; bh=WNyoyWE35wQdpSmLrTzryRI9r11yOyAqqemLLMJjIlU=; h=To:From:Subject:Date:From; b=QzvZTJtO8JLxmPbuLLxxm0DqnZPx885keEx2IAnRL4sggCJuAWkoQHYf4VUE7fq4j 1nteS2cdiQvzfmTzw67fgVFd2qHWjDGPHoxvN89lncVaaOv3Nms37CbptJiuVUG1/K fDok1CFNnwriOfrCLoLaBAgcyJhE2zbVqoV8UqYo=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: 
Date: Fri, 30 Jul 2021 01:11:08 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wAma42HoVNZbyj2nCfdefpKHvvIWjsHLo"
Archived-At: 
Subject: [Rfced-future] Consensus check: Issue 25 Who writes the SOW?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jul 2021 23:11:19 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--wAma42HoVNZbyj2nCfdefpKHvvIWjsHLo
Content-Type: multipart/mixed; boundary="AgC5Lq0jxUJD4rSGbSoQw7mMNYi1rh2A6";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: 
Subject: Consensus check: Issue 25 Who writes the SOW?

--AgC5Lq0jxUJD4rSGbSoQw7mMNYi1rh2A6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

During today's meeting we discussed who would write the SOW.=C2=A0 Jay=20
indicated that he is comfortable with the LLC doing so.

If you disagree with this, could you please comment by August 13th?

Thanks,

Eliot



--AgC5Lq0jxUJD4rSGbSoQw7mMNYi1rh2A6--

--wAma42HoVNZbyj2nCfdefpKHvvIWjsHLo
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEDNYwFAwAAAAAACgkQh7ZrRtnSejMh
Bgf+NAvXRE3FyHfi/ZBx3ATaJwILM1JzC4sWVBTzV9V+GilmR0LsSxRNogsitefB7Z3NlZBKvkje
tj7uoz0tQdKB+vpDrZhvyu3Ug0nE1xeMXo4QHe2xiWZVe85xygOyOrLpQ9diiv3LkYf8PiogaE+e
4nxyDba9yPGsIWFN4B5LWkX8d1U6hoKahvU+fBfPDBWp86QT7is/SKo2W66AGa0maSkQSXMlVpUz
aGeg+bfrmgDjqaYYGcrxl3Eec0Ht2qr/r+xRLYASRlLG/fpbjLMXegqt656bHMd/Ielx/ALR0k4P
KefqhfEqhW6ZmXZ3jtFroME46AYuT84B7BTuwVSqPg==
=WjhR
-----END PGP SIGNATURE-----

--wAma42HoVNZbyj2nCfdefpKHvvIWjsHLo--


From nobody Thu Jul 29 16:15:31 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5823A0E88 for ; Thu, 29 Jul 2021 16:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 854mNiv1HaLU for ; Thu, 29 Jul 2021 16:15:26 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 4CC813A0E89 for ; Thu, 29 Jul 2021 16:15:22 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16TNFEaA096857 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 30 Jul 2021 01:15:15 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627600515; bh=MMs0XPq/5LMS1aWBS/jODwqqQgOQIiJuMIRyvh+uxJM=; h=To:From:Subject:Date:From; b=AcN3fZZX8gcquVS4KZC74KXydcw+2Unt52YuU5XHeI/v6YHiEsSRpxzd+lNamE4XH 4vnGsypjcqvcIyp/MgsZ7mgeB17WyTBs55OWtQwoweP7OJbOD5NaOEpQL8tONlD0ov lUtLa0Aj262CFmRacPG1rDErOIYSYx9XihACU20k=
To: "rfced-future@iab.org" 
From: Eliot Lear 
Message-ID: <43bb84c8-6d1d-6455-dd7a-0a67eab47a16@lear.ch>
Date: Fri, 30 Jul 2021 01:15:14 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RshcUVBw7zznxfBgV7KnDZsWI8rTfuTGh"
Archived-At: 
Subject: [Rfced-future] Consensus Check: Issue 40: RSEA selection committee
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jul 2021 23:15:30 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--RshcUVBw7zznxfBgV7KnDZsWI8rTfuTGh
Content-Type: multipart/mixed; boundary="OwfFVCF0f0h0OC9n1atJc4BnSx5R8CD42";
 protected-headers="v1"
From: Eliot Lear 
To: "rfced-future@iab.org" 
Message-ID: <43bb84c8-6d1d-6455-dd7a-0a67eab47a16@lear.ch>
Subject: Consensus Check: Issue 40: RSEA selection committee

--OwfFVCF0f0h0OC9n1atJc4BnSx5R8CD42
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

During today's meeting, the following text was proposed for Section 4.1:

> The LLC will form a selection committee, including members from the=20
> community, that will be responsible for making a recommendation to the =

> LLC for the RSEA. The selection committee will take into account the=20
> role definition [CITE] and any other information that the community=20
> deems necessary or helpful in making its recommendation. The LLC is=20
> responsible for contracting or employment of the RSEA.

If you disagree with this approach, please could you comment by the 13th =

of August?

Thanks,

Eliot



--OwfFVCF0f0h0OC9n1atJc4BnSx5R8CD42--

--RshcUVBw7zznxfBgV7KnDZsWI8rTfuTGh
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEDNoIFAwAAAAAACgkQh7ZrRtnSejMU
rQgAnbbanCVjbVcq03BmCzKaBiWFAIlT3jRcovDaboccbxJ90iZE1ZEbZSRdcTXlREyIBsimQmfk
3AG/6s7cc7t4meONW+nRGkhvGVJS3eE4xV2Z9GcE06iEVHxUWSXMYJ6OHEKLMVFwPVoSqneefYsL
Rigfonr6XOHoosmrmuKPPa4r/rzOoqp5QSYdbR60lTI6q9Q0hIeq0C9XsHHdieu2f7tPtTfCCvVX
U8RAbM1oSPMpPKy0RUF8QO/EPfwRBKxiaZQ8rDdKfwNeXhrJobvXJH108WZYVC54ElWIS2wjFB/6
kxdbOOy1d+9T85n+H79HC93svlAyKKzlDNfCcyLqlA==
=nfi2
-----END PGP SIGNATURE-----

--RshcUVBw7zznxfBgV7KnDZsWI8rTfuTGh--


From nobody Thu Jul 29 16:33:04 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5143A0FD4 for ; Thu, 29 Jul 2021 16:33:02 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=taWi8j6n; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Mbbhw31e
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7e11P_QuANg for ; Thu, 29 Jul 2021 16:32:58 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF073A0FCE for ; Thu, 29 Jul 2021 16:32:58 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 5725F3200920; Thu, 29 Jul 2021 19:32:56 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 29 Jul 2021 19:32:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=C ibPAI6JPh2jTxC3aeAi9ZDbMBLXNZknua7VjB6nIEw=; b=taWi8j6ndEKe1o6g8 O4JVSSmFRD5drf9mdmKpNDIyJqZHUwurDIfsJz1KZAXXK6JhD3yp7pJ0NC3tVokE gbRMIgp8MNRjwR2u+t+HQJA1hy5pbNuC513Mce+w/Y+/C4+NW/humEWwwzLCInRl Hx8/LvDy/rQaheJ7Kyu6LReUU85tGPWBxiNdj3uxhfdVF8KXiK9O3qUld037mnrE ot/aHrlCHoMwr9CyYF3rJ1Y2HXIxOvbormHFOd1gUC+iHrZNp0Yw8YMLlyis7vqC 9Lwl+gpat2PPSdW8VI1t4ts0NLLNok37R6ooZI/g9ZTQSPpyjtHjj4rWZczgQeba h7zPg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=CibPAI6JPh2jTxC3aeAi9ZDbMBLXNZknua7VjB6nI Ew=; b=Mbbhw31ezZz533qRk5EeLoPBzEopb8phGr+WS4JZPLCnhacXiEt1R3uuD 1pV6f0DWsy0J8dra8KNwnldqnJgvH/EtGtqOdRplfqSri6PA24MKdb4aR9XvOvpu qm/REXXnXtqx2Wo0RdXnNhZb/f+fe1rlZGuXAg8xpvi6E9UjpBwyo2y5jqe/UmEJ CKAD/WwMdiLLM96RfMEVOGR5udfB1k43jZQi9h5+oi9NtVUdOgL4Pq5yxKNG37yA /ZIknUslxsS8Ytzq9S/ljOw7BQroEjuvurSnWCVtqvC535mgU94VmZYeZBxpDZxI OUM2eGU/yjdpMahDKQQAQTjrIzPIg==
X-ME-Sender:  
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheeggddthecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepuedtkefhtdfggfejjeegkeevheefhffguefgheefgfegkefhiedtgeduvedufeei necuffhomhgrihhnpehirggsrdhorhhgpdhmnhhothdrnhgvthenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Jul 2021 19:32:52 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Nottingham 
In-Reply-To: 
Date: Fri, 30 Jul 2021 09:32:50 +1000
Cc: "rfced-future@iab.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A71A535-9AEE-4A9A-B8DC-34A02E95AB24@mnot.net>
References: 
To: "Eliot Lear (elear)" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: issue 38: RSAB appointees
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jul 2021 23:33:02 -0000

Eliot -=20

Does that include the length of their appointment, etc.?


> On 30 Jul 2021, at 9:03 am, Eliot Lear (elear) =
 wrote:
>=20
> This is the first of several emails on consensus checks for the issues =
we discussed and have what we think is at least rough consensus.
>=20
> On this issue 38, based on discussion on list and in the meeting, we =
think we have consensus that the appointing bodies should establish =
their own policies as to how their representatives are appointed.
>=20
> If you disagree, please could you comment by the 13th of August?
>=20
> Eliot
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--
Mark Nottingham   https://www.mnot.net/


From nobody Thu Jul 29 16:37:29 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19AF3A0FEA; Thu, 29 Jul 2021 16:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level: 
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgGKHnuE0qds; Thu, 29 Jul 2021 16:37:22 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 763EF3A0FE6; Thu, 29 Jul 2021 16:37:22 -0700 (PDT)
Received: from [IPv6:2a02:aa15:4101:2a80:2951:2495:143a:1c26] ([IPv6:2a02:aa15:4101:2a80:2951:2495:143a:1c26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16TNbJCM097011 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 30 Jul 2021 01:37:19 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627601839; bh=dOHVsDHdj0ATAIw3AFhSimSeQsqmgtoqbpwwYIhmAt4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=w02LtxIrv68MNgFL7qG+7bLHFJZ4Xcz8PuBkdUrqlx115h2Y/8Mx+lNTlKwCVQhDQ o2HOJeR8ABgfVz0x0huTUUVAIrKik6IItA4JzjMtW1EIW8cJVKDKOCnT1+cTqGup6d hE8IoyR7S/SVYWtXUXnF1WBl0pSMvdrglQ9G/m3o=
To: Mark Nottingham , "Eliot Lear (elear)" 
Cc: "rfced-future@iab.org" 
References:  <0A71A535-9AEE-4A9A-B8DC-34A02E95AB24@mnot.net>
From: Eliot Lear 
Message-ID: <5fd893d0-c534-caab-41c8-e588526e44fe@lear.ch>
Date: Fri, 30 Jul 2021 01:37:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <0A71A535-9AEE-4A9A-B8DC-34A02E95AB24@mnot.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bFYBq78GaU5OTIFL13qMYjx1QtXjmwWtD"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: issue 38: RSAB appointees
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jul 2021 23:37:27 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--bFYBq78GaU5OTIFL13qMYjx1QtXjmwWtD
Content-Type: multipart/mixed; boundary="n1Pmu1GC0UP8wptAMNEU90kfDF46XrFOa";
 protected-headers="v1"
From: Eliot Lear 
To: Mark Nottingham ,
 "Eliot Lear (elear)" 
Cc: "rfced-future@iab.org" 
Message-ID: <5fd893d0-c534-caab-41c8-e588526e44fe@lear.ch>
Subject: Re: [Rfced-future] Consensus check: issue 38: RSAB appointees
References: 
 <0A71A535-9AEE-4A9A-B8DC-34A02E95AB24@mnot.net>
In-Reply-To: <0A71A535-9AEE-4A9A-B8DC-34A02E95AB24@mnot.net>

--n1Pmu1GC0UP8wptAMNEU90kfDF46XrFOa
Content-Type: multipart/alternative;
 boundary="------------6C22BD139F905F75FEA22CB2"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------6C22BD139F905F75FEA22CB2
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Mark,

> On 30 Jul 2021, at 01:32, Mark Nottingham  wrote:
>
> Eliot -
>
> Does that include the length of their appointment, etc.?

My interpretation is =E2=80=9Cyes=E2=80=9D. =C2=A0The discussion ran, =E2=
=80=9Cif the bodies don=E2=80=99t=20
handle this well, the community will yell at them, and then we can=20
create more process.=E2=80=9D

Others can comment.

Eliot


--------------6C22BD139F905F75FEA22CB2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    Hi Mark,

    

    
On 30 Jul
      2021, at 01:32, Mark Nottingham <mnot@mnot.net> wrote:

      

      Eliot -=C2=A0

      

      Does that include the length of their appointment, etc.?

    

    

    My interpretation is =E2=80=9Cyes=E2=
=80=9D. =C2=A0The
      discussion ran, =E2=80=9Cif the bodies don=E2=80=99t handle this we=
ll, the
      community will yell at them, and then we can create more process.=E2=
=80=9D
      =C2=A0

    

    Others can comment.

    

    Eliot

    

  


--------------6C22BD139F905F75FEA22CB2--

--n1Pmu1GC0UP8wptAMNEU90kfDF46XrFOa--

--bFYBq78GaU5OTIFL13qMYjx1QtXjmwWtD
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEDO64FAwAAAAAACgkQh7ZrRtnSejNi
UQf9HRhH+fVIvasUFd2j1sUA9socorD3vMdPookzOx+baEOh5gJXzumw5fYuEiIuWR0IRsTtkE0B
gqbEH02qWPzrUqc3uBhGvL8vZ9QpAWttlE/qVBj67z1gQztjCT+CfJ4R7G4zv9mjzsf4zBNdI4Ty
fpsg8HepqL36TLw+fqiFbI5M9NrsNeSvfKbN/pgk4+9gCO4VXLKwv0+t/ZnjzfE5TAymZWyKMCoE
GNxD4fyuD9+fGEf8COM1R2HeORzj3dcxzGOP/zssBa5PXqkcSGehbmroGM1+OZl1n4JopneVa98u
j9idPmmqzYLbieQ0uqiMwlWheTcJIQPUgLX5n+p8mQ==
=HJOC
-----END PGP SIGNATURE-----

--bFYBq78GaU5OTIFL13qMYjx1QtXjmwWtD--


From nobody Thu Jul 29 17:00:08 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B207E3A10C0 for ; Thu, 29 Jul 2021 17:00:07 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 BHtV0QAAd_A5 for ; Thu, 29 Jul 2021 17:00:03 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC3663A10BD for ; Thu, 29 Jul 2021 17:00:02 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id c18so7769404qke.2 for ; Thu, 29 Jul 2021 17:00:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=AS6M66qRq4Dl8d8MgovSF1dLBSHJDX/VQhGyiFZrboI=; b=Antr97LB+Jhas/S1y/nqqBwe0RnWqjTYLjqqt2CA+2IQ2LrEpwMXghFavxp8tcIUnH HnoQfNZqHr6NjXRqSE6GOWKmJBdInWcyPjKixPDRXx6VFv7fdKRkomqkklq1nm7p6FQ4 l/emGNu6rVEMOwDq+wNbLkf17rh859WJMPfK7674E6rpUtLZ768AiQLPlKGKkGm7m2Gd NXrZq1Y18rGyRrTbZwMM7aQ8r0Wg3lse7PxiOQsupCNcjfjJtylK/f/8Q0cw8k6xte14 lqU/RMI9r3Lpgh2Y4snEobHyiskW6zjDtluhdAfrQvLwgd4jb9EoJpsekxiE4DZMZt1n S/Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=AS6M66qRq4Dl8d8MgovSF1dLBSHJDX/VQhGyiFZrboI=; b=dKyoV7ghpiH90JlZjkPy4n+qV7qvDlES2ClfYEAyi0LZlzibz2hrZLpspFWKpmRSes QDW1a/lI2As6HAUkK+RjJWNFo6sfo78fhfPQlgBD3jVxQihV4ChJ1ImbXiovKKs/PzgC 5hPq+QBE24PDYrFYZrbSK61NGJWDHNRnKW4bRZ4LEWeZqy1RzAz22MHodpcR1noXS4Z7 fst06VqE4Q6jWzmxno8Xa0S5Wu352bA9pRtLQ0tjvXcbswtOU/sh2t6LI49FwGY0e/Cv LlYgDCHFL6+fVpKIQKEGEYTrg0LS+MZ9U5OwRzaWHY1SP4Pl8j/AKCJs5eX6Y871QZTP /fwA==
X-Gm-Message-State: AOAM531Tv0te+4rw1MZUEwt2byA2FGnTVRKDH4HcMH6OddOcEKBEu+FW Kd4rWy5ZFpYAkQ0liB2koxuBLve8GZaQ6oiL
X-Google-Smtp-Source: ABdhPJznPBnXbZWAUrNTo7SpiuKvW71K/DlRI7dfZNBrchO/NRw9bfZxzf4sXJ9xcM4gy6yyb3v+nQ==
X-Received: by 2002:a37:78f:: with SMTP id 137mr7966209qkh.4.1627603199748; Thu, 29 Jul 2021 16:59:59 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id q3sm2588173qkn.14.2021.07.29.16.59.59 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jul 2021 16:59:59 -0700 (PDT)
To: rfced-future@iab.org
From: Michael StJohns 
Message-ID: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com>
Date: Thu, 29 Jul 2021 19:59:58 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [Rfced-future] Replacement text for Section 4.2
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jul 2021 00:00:08 -0000

Replacement for section 4.2:

         <<< Set a schedule - could be omitted, but this is a promise to 
the community

                as well as a schedule for the IED/RSEA >>>
    No more often than semi-annually nor less often than bi-yearly, the
    IETF Executive Director will send out to the community a call for
    input on the performance of the RSEA.

     <<< Separate the IED's recommendation from the feedback process -

      there may not actually be an action that needs an immediate 
recommendation >>>

    <<<< the IED acts as the confidentiality mediator, anonymous and 
confidential

             comments get tagged in the document that goes to the LLC - 
this provides

             needed context. >>>>
    The IETF Executive Director and the stream managers will review the
    received feedback and produce a draft summary (a paraphrase)
    including both positive and derogatory information.  Any feedback
    provided anonymously shall be tagged as such in the summary. Any
    feedback provided with a request for confidentiality shall likewise
    be tagged in the summary and the IETF Executive Director MAY
    comment on the weight that may be appropriate to apply to the
    comment based on their knowledge of the submitter.  The stream
    managers should ensure that any of their concerns are added to the
    document at this point and MAY also provide any commentary on the
    externally provided feedback that they feel appropriate.

    <<< Make sure that the LLC hears both sides of the coin >>>
    That draft feedback, redacted with respect to any names associated
    with confidential comments and with respect to the IED's weight
    evaluations, shall be provided to the RSEA with for comment or
    rebuttal, and such comments shall be incorporated as an appendix to
    the final feedback document provided to the IETF LLC Board.

    << The previous text had this being a recommendation being sent to
       the LLC, but instead this is a set of feedback, as no decision may be
       pending by the LLCin the near future.  The IED will provide a 
recommendation
       upon request from the LLC based on their own knowledge and any 
previous
       feedback documents... >>>
    The LLC may take into account any recent feedback, along with any
    recommendations of the IETF Executive Director in any of its
    decisions related to the RSEA and their contract(s) or tasking.

    Whether the RSEA role is structured as a contractual or employee
    relationship is a matter for the IETF LLC and the IETF Executive
    Director to determine.


From nobody Thu Jul 29 20:35:35 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429BE3A189F for ; Thu, 29 Jul 2021 20:35:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 jQq4xZ9hTwdU for ; Thu, 29 Jul 2021 20:35:28 -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 C0EC93A18A2 for ; Thu, 29 Jul 2021 20:35:28 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id l18so9726239ioh.11 for ; Thu, 29 Jul 2021 20:35:28 -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=TD9rJjedkjwLj8F7J5oG1zgetm5+/Nxk4VtcQ/E9ub4=; b=Z5sdg0+U2j2T8TJtyylGcdjXU3bz/ktvmO746+nR9e0cJF3vi7xQAdcOTgAuueTopV 6SEQ0MU2IcdT0j+CXOEg7yC+JEGYVAojHDRPR2lCHwzRtlDgNJ4nXkXJ3TrNTbZK3+Ma CeaKj3Fb4bdYziRRcqkIofTtmjxNeB934/r97Py2RJXd55lS2hy1tTVKcSRAgkXn4gWs Ca0lGV/4p6/kAGZOk4TmX2Mk/wwLsux9mfb3JH3ZFMS8HF8Mb9NStkAv6Wt57wajDwhH /40IjoaQKHJAjyWnm6GRT15CubnHQqPzuIgNOSvrRORN2PgxZL5Vfx71VQpLQswT8qYE 20BQ==
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=TD9rJjedkjwLj8F7J5oG1zgetm5+/Nxk4VtcQ/E9ub4=; b=pHKNkjXqKHePZdRG1MR7xs796eLkgzEa9T2VzkhzfciRDJNqNehIGVpRxlxWgAtizU XpitppqWdNJrpEDznVoyq1pkRSL95wKEeVRkGt/xFoMBCWmM8d9g0X41LkHLYbqQtUYB b9v3WpyUAogKaTO4NsN0UUEpWoI+LjcggdwnnscGxXLMDOxvM3QyQOHETbK6Wg/+ky3N OiJ9sN8ghb+T9+j5YNMvGzIGfPRg6oZrjcyVkZzZKcLLVyCSwcx0lv9SLV2liAarHdPQ s998ZbavmsofwNsqcHdpioyy8B0h5nu5ve22rpFlX47y4rStJEQrYbzHXX/GlA2h4lQH Ag3Q==
X-Gm-Message-State: AOAM533fVHYGKwwFRW0Km+L3OVB+MryNatyoIDHEsD7MDmyBOTOtvgCx HEk8ewkjuFkG/T+3cFtmIry7MsDCnTGiDp9iINXtxw==
X-Google-Smtp-Source: ABdhPJwnFytCudeU8MljVZod/CY3Vo9QydOTUGgsqba3pzJwoNWrk19kShri9gVgAhY6mlR5Y960deWfGfbOpjqsdog=
X-Received: by 2002:a05:6638:24c3:: with SMTP id y3mr409452jat.10.1627616127473;  Thu, 29 Jul 2021 20:35:27 -0700 (PDT)
MIME-Version: 1.0
References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com>
In-Reply-To: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com>
From: Eric Rescorla 
Date: Thu, 29 Jul 2021 20:34:50 -0700
Message-ID: 
To: Michael StJohns 
Cc: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000001bf48405c84ee97b"
Archived-At: 
Subject: Re: [Rfced-future] Replacement text for Section 4.2
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jul 2021 03:35:33 -0000

--0000000000001bf48405c84ee97b
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns 
wrote:

> Replacement for section 4.2:
>
>          <<< Set a schedule - could be omitted, but this is a promise to
> the community
>
>                 as well as a schedule for the IED/RSEA >>>
>     No more often than semi-annually nor less often than bi-yearly, the
>     IETF Executive Director will send out to the community a call for
>     input on the performance of the RSEA.
>
>      <<< Separate the IED's recommendation from the feedback process -
>
>       there may not actually be an action that needs an immediate
> recommendation >>>
>
>     <<<< the IED acts as the confidentiality mediator, anonymous and
> confidential
>
>              comments get tagged in the document that goes to the LLC -
> this provides
>
>              needed context. >>>>
>     The IETF Executive Director and the stream managers will review the
>     received feedback and produce a draft summary (a paraphrase)
>     including both positive and derogatory information.  Any feedback
>     provided anonymously shall be tagged as such in the summary. Any
>     feedback provided with a request for confidentiality shall likewise
>     be tagged in the summary and the IETF Executive Director MAY
>     comment on the weight that may be appropriate to apply to the
>     comment based on their knowledge of the submitter.  The stream
>     managers should ensure that any of their concerns are added to the
>     document at this point and MAY also provide any commentary on the
>     externally provided feedback that they feel appropriate.
>
>     <<< Make sure that the LLC hears both sides of the coin >>>
>     That draft feedback, redacted with respect to any names associated
>     with confidential comments and with respect to the IED's weight
>     evaluations, shall be provided to the RSEA with for comment or
>     rebuttal, and such comments shall be incorporated as an appendix to
>     the final feedback document provided to the IETF LLC Board.
>

This doesn't seem appropriate to me.

If people want to provide confidential comments, then they shouldn't be
supplied to the RSEA,
nor should the IED's weights. This is not a legal proceeding, it's a
performance review, and
there's no generic reason that the RSEA should get to hear all the feedback
that the LLC is
receiving.

-Ekr

--0000000000001bf48405c84ee97b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Jul 29, 2021 at 5:00 PM Micha=
el StJohns <msj@nthpermutation=
.com> wrote:
Replacement for section 4.2:



=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 <<< Set a schedule - c=
ould be omitted, but this is a promise to 

the community



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 as well as a schedule for the IED/RSEA >>>

=C2=A0=C2=A0=C2=A0 No more often than semi-annually nor less often than bi-=
yearly, the

=C2=A0=C2=A0=C2=A0 IETF Executive Director will send out to the community a=
 call for

=C2=A0=C2=A0=C2=A0 input on the performance of the RSEA.



=C2=A0=C2=A0=C2=A0=C2=A0 <<< Separate the IED's recommendation=
 from the feedback process -



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 there may not actually be an action that nee=
ds an immediate 

recommendation >>>



=C2=A0=C2=A0=C2=A0 <<<< the IED acts as the confidentiality med=
iator, anonymous and 

confidential



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 co=
mments get tagged in the document that goes to the LLC - 

this provides



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ne=
eded context. >>>>

=C2=A0=C2=A0=C2=A0 The IETF Executive Director and the stream managers will=
 review the

=C2=A0=C2=A0=C2=A0 received feedback and produce a draft summary (a paraphr=
ase)

=C2=A0=C2=A0=C2=A0 including both positive and derogatory information.=C2=
=A0 Any feedback

=C2=A0=C2=A0=C2=A0 provided anonymously shall be tagged as such in the summ=
ary. Any

=C2=A0=C2=A0=C2=A0 feedback provided with a request for confidentiality sha=
ll likewise

=C2=A0=C2=A0=C2=A0 be tagged in the summary and the IETF Executive Director=
 MAY

=C2=A0=C2=A0=C2=A0 comment on the weight that may be appropriate to apply t=
o the

=C2=A0=C2=A0=C2=A0 comment based on their knowledge of the submitter.=C2=A0=
 The stream

=C2=A0=C2=A0=C2=A0 managers should ensure that any of their concerns are ad=
ded to the

=C2=A0=C2=A0=C2=A0 document at this point and MAY also provide any commenta=
ry on the

=C2=A0=C2=A0=C2=A0 externally provided feedback that they feel appropriate.=




=C2=A0=C2=A0=C2=A0 <<< Make sure that the LLC hears both sides of =
the coin >>>

=C2=A0=C2=A0=C2=A0 That draft feedback, redacted with respect to any names =
associated

=C2=A0=C2=A0=C2=A0 with confidential comments and with respect to the IED&#=
39;s weight

=C2=A0=C2=A0=C2=A0 evaluations, shall be provided to the RSEA with for comm=
ent or

=C2=A0=C2=A0=C2=A0 rebuttal, and such comments shall be incorporated as an =
appendix to

=C2=A0=C2=A0=C2=A0 the final feedback document provided to the IETF LLC Boa=
rd.

This doesn't seem appropriate t=
o me. 

If people want to provide confidential =
comments, then they shouldn't be supplied to the RSEA,
nor sh=
ould the IED's weights. This is not a legal proceeding, it's a perf=
ormance review, and
there's no generic reason that the RSEA s=
hould get to hear all the feedback that the LLC is
receiving.
=


-Ekr



--0000000000001bf48405c84ee97b--


From nobody Thu Jul 29 20:49:18 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C5C3A1940 for ; Thu, 29 Jul 2021 20:49:16 -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, 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 trrkcUkLUiZw for ; Thu, 29 Jul 2021 20:49:12 -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 F28D33A193C for ; Thu, 29 Jul 2021 20:49:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GbYKz35Rmz1nwXL; Thu, 29 Jul 2021 20:49:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1627616951; bh=QLxXk/B2klIdSU+bp5fUHaGnIbeR1NZn29pgpKucc08=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lbUScuSYaPsNbr7mpNsc7uk7LP3EaYxowLSgYqAASGeM6bEyFTRxVQ2XWhuCrA3DZ vnX7IqOLrR8m7eCazgXUDQYiWP/HSlLg9cg6k9hLKgSEqRJrJsN9zztMaMFFVGNwA9 Uy7RrWI87YdalK95nHgRgT6Utztj/O4ZPyI3/710=
X-Quarantine-ID: 
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 4GbYKy5TCMz1nsyQ; Thu, 29 Jul 2021 20:49:10 -0700 (PDT)
To: Eric Rescorla , Michael StJohns 
Cc: rfced-future@iab.org
References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com> 
From: "Joel M. Halpern" 
Message-ID: <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com>
Date: Thu, 29 Jul 2021 23:49:07 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Rfced-future] Replacement text for Section 4.2
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jul 2021 03:49:17 -0000

I mostly agree with Ekr here.

The only edge case I see is one that I know has come up with nomcoms. 
If nomcoms see a pattern of reports of an issue, they have been known to 
say to a candidate "there have been issues raised about X.  Do you have 
any comment on that?"   This is not the same as showing the candidate 
the feedback, even sanitized.  It does reveal that information has been 
provided.  (And, even more importantly, ti does not give even a large 
portion of the feedback.)  The nomcoms where I know this came up 
concluded that the combination of seeing the candidates reaction and 
giving then a chance to respond was worth pushing that envelop.   Do we 
consider that the selection committee or LLC or someone has that right 
under this process already?  Do we want to say anything about it?

Yours,
Joel

On 7/29/2021 11:34 PM, Eric Rescorla wrote:
> 
> 
> On Thu, Jul 29, 2021 at 5:00 PM Michael StJohns  > wrote:
> 
>     Replacement for section 4.2:
> 
>               <<< Set a schedule - could be omitted, but this is a
>     promise to
>     the community
> 
>                      as well as a schedule for the IED/RSEA >>>
>          No more often than semi-annually nor less often than bi-yearly, the
>          IETF Executive Director will send out to the community a call for
>          input on the performance of the RSEA.
> 
>           <<< Separate the IED's recommendation from the feedback process -
> 
>            there may not actually be an action that needs an immediate
>     recommendation >>>
> 
>          <<<< the IED acts as the confidentiality mediator, anonymous and
>     confidential
> 
>                   comments get tagged in the document that goes to the
>     LLC -
>     this provides
> 
>                   needed context. >>>>
>          The IETF Executive Director and the stream managers will review the
>          received feedback and produce a draft summary (a paraphrase)
>          including both positive and derogatory information.  Any feedback
>          provided anonymously shall be tagged as such in the summary. Any
>          feedback provided with a request for confidentiality shall likewise
>          be tagged in the summary and the IETF Executive Director MAY
>          comment on the weight that may be appropriate to apply to the
>          comment based on their knowledge of the submitter.  The stream
>          managers should ensure that any of their concerns are added to the
>          document at this point and MAY also provide any commentary on the
>          externally provided feedback that they feel appropriate.
> 
>          <<< Make sure that the LLC hears both sides of the coin >>>
>          That draft feedback, redacted with respect to any names associated
>          with confidential comments and with respect to the IED's weight
>          evaluations, shall be provided to the RSEA with for comment or
>          rebuttal, and such comments shall be incorporated as an appendix to
>          the final feedback document provided to the IETF LLC Board.
> 
> 
> This doesn't seem appropriate to me.
> 
> If people want to provide confidential comments, then they shouldn't be 
> supplied to the RSEA,
> nor should the IED's weights. This is not a legal proceeding, it's a 
> performance review, and
> there's no generic reason that the RSEA should get to hear all the 
> feedback that the LLC is
> receiving.
> 
> -Ekr
> 
> 


From nobody Thu Jul 29 21:59:28 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684413A0A4A for ; Thu, 29 Jul 2021 21:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level: 
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=1tV7tW37; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UyH/7/sS
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpG0OaiWuzY6 for ; Thu, 29 Jul 2021 21:59:19 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70BB3A1B5D for ; Thu, 29 Jul 2021 21:59:19 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 47C815C005B for ; Fri, 30 Jul 2021 00:59:15 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Fri, 30 Jul 2021 00:59:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=MCpr0RGGXBbbHP2aKig85dki1Sm9D9D iBXBNg0BmTnI=; b=1tV7tW37bi2M4QYS3XF3NQszI2biLFX2giQFc5hMZLSRbS4 ZriNLa3CQS/OClUYOY/6Glbr5giO50DRQSI7UlWO0X4udO9y3OHCTG7b8leJvgKS WEs80YLVpBNb0+QLtQ2DL/vb4Yfv/p+UrpCZqGZF0U337J4d6pdLMNmphsYfsHrv eiQj/GutN3+o/DMSCGyM300VrKEU++qrNgeDEymdWavvfA/B81CQ9l7xvf5hU/iU /vv7RrdCIRo/84sUMLv3yPvWLj26LI9oEcZqj6qm3lpwJ6hUKi9kd4M7hEg4AM2I YCsRVmqUpnxrR9JyzWfAoEkTZR+crQ/whrNSDzg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=MCpr0R GGXBbbHP2aKig85dki1Sm9D9DiBXBNg0BmTnI=; b=UyH/7/sSri1Y2BVy9C31t1 n7F/3PkNcAk4JZTWAlsEIEaA5Bsc5Q+AMX83kvU7lNhtLefjo1JA/VaViFx4/oLk X6ORcScNatTE5R7TxrkOIxRZmZ2VSAw09ZvbMkAwINZX/8adRVmrZrfkdVUZSc6z SvkVxYTGE5xOPtGcD3+ssYj2XkvyNMQMEp2H3LU9DvpY2j4BsT2EDB+rftj9qMy1 OH7z+7IZD6PxWp7NDR2UUpXzO6S6ndnF6mayIsvR8i1HJS4rA5XkrztfD8W7wRTY V85TZHX7S32peq3aglKPmWx7XPSdhV8Ty/fpEtheAroLu8JL058GJqhh7uI9/SvA ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheeggdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 012913C0471; Fri, 30 Jul 2021 00:59:14 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-545-g7a4eea542e-fm-20210727.001-g7a4eea54
Mime-Version: 1.0
Message-Id: <9f000462-57c7-4257-b992-176a3a0ac0eb@www.fastmail.com>
In-Reply-To: <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com>
References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com>  <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com>
Date: Fri, 30 Jul 2021 14:59:02 +1000
From: "Martin Thomson" 
To: rfced-future@iab.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [Rfced-future] Replacement text for Section 4.2
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jul 2021 04:59:26 -0000

I agree with both Ekr and Joel here.

On Fri, Jul 30, 2021, at 13:49, Joel M. Halpern wrote:
> Do we consider that the selection committee or LLC or someone has that right 
> under this process already?  Do we want to say anything about it?

I think that letting someone know about notable trends is generally reasonable, both because that information can be relevant to their performance (and actionable) and because it relies on k-anonymity.

I don't think that there is a special need to document it though.  As with a lot of this process, we do rely to some extent on the people involved exercising good judgment, respect, and sensitivity (that is, after all, what respecting requests for confidentiality amount to anyway).


From nobody Thu Jul 29 22:50:20 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57703A1CDB for ; Thu, 29 Jul 2021 22:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6UbP1Ml89_1 for ; Thu, 29 Jul 2021 22:50:16 -0700 (PDT)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 BE4133A1C99 for ; Thu, 29 Jul 2021 22:50:16 -0700 (PDT)
Received: by mail-pj1-x1031.google.com with SMTP id g23-20020a17090a5797b02901765d605e14so12805697pji.5 for ; Thu, 29 Jul 2021 22:50:16 -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=wvQiBvXVAw+ScJdgu2hgZWW7vvT6A6CVGRzrUnc/OCU=; b=LjUMTm/hRdMQ8tH4mVg4EhmwLJqrH3R/x5wlEKDFY/lXmYPCqGASVDIKdNFN5b2uK+ rGDufjrijAXx++rlQOi8/1KBe4PE7DAxJTUr4uDBikDlq2I8SIVNXHMuLcNrwtU6xSoi vG9srBsAtVdcmLXLfdYJwYqcgYee+0sOsKlwdO7cwKHn1TYwwrUtvD036EtOon+4faY0 5ItH/tpOqk/9UYD5QMcyE8yeH+/ZWgpwbTppAE8kORerDBMcsfQYbZv56qopVyYHhcvy mFU9MKdJMqahPZ9xQqKhUp71XVdfe8DvrAe4qQXqo47ptKBLIN6oJS3pTQUYLflcyjRW J4JQ==
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=wvQiBvXVAw+ScJdgu2hgZWW7vvT6A6CVGRzrUnc/OCU=; b=gAsm5os8jD/6Tn4q6tmHx7gUVdTYmTWNsu7JqFbmXA5d5igOTqDHxkJd3a81HBU80o AHxLUADtKrVNUkRddHT/aZVsmwNwND3gIgKVFI6VIJIt/LlVVbaGCtoWmGlM53wuQ7QL 2BkuYckwY+Ar/ovDCpbI4PqQ91wNj8lRVipqy7V/BjSP0FuOXEM3HZenpA5fZ79JNH9g /1HS5+UOBDm+r1ZK3LgFsj99OZPqnIOZEeGQrrhTDT0QNPiPsOzcT1bCr65Mz6YQ6zlm SMGxyM5kPvqAaao63v6Qd3obzwOFK5rWpK7vPgBpCLVtg8gYP9uyhPlmAomMRB1P2oDm r/2w==
X-Gm-Message-State: AOAM533cmdxPtS8k4FX8jMrN5gfyPCLeMS705So/0WerXB4+6Qd3gCSW Te4Plbm/e0uF4s4SB31mNaVZCYivXoXaMw==
X-Google-Smtp-Source: ABdhPJxvYyIzZgmJc0m8endPiGD6V+0lmT9pRdgGdxxhlXogEjOWYl54Ef6bf7TuX6H0K7sF4nHahA==
X-Received: by 2002:a17:902:9f88:b029:12c:c06:2645 with SMTP id g8-20020a1709029f88b029012c0c062645mr902047plq.21.1627624214792;  Thu, 29 Jul 2021 22:50:14 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id j128sm827915pfd.38.2021.07.29.22.50.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jul 2021 22:50:14 -0700 (PDT)
To: Martin Thomson , rfced-future@iab.org
References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com>  <2739d8af-209a-6714-c21c-d723fbd941fd@joelhalpern.com> <9f000462-57c7-4257-b992-176a3a0ac0eb@www.fastmail.com>
From: Brian E Carpenter 
Message-ID: 
Date: Fri, 30 Jul 2021 17:50:11 +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: <9f000462-57c7-4257-b992-176a3a0ac0eb@www.fastmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Replacement text for Section 4.2
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jul 2021 05:50:19 -0000

On 30-Jul-21 16:59, Martin Thomson wrote:
> I agree with both Ekr and Joel here.

I concur. If an unwelcome behaviour pattern is noticed, it deserves attention. But that hardly needs writing down.

   Brian

> 
> On Fri, Jul 30, 2021, at 13:49, Joel M. Halpern wrote:
>> Do we consider that the selection committee or LLC or someone has that right 
>> under this process already?  Do we want to say anything about it?
> 
> I think that letting someone know about notable trends is generally reasonable, both because that information can be relevant to their performance (and actionable) and because it relies on k-anonymity.
> 
> I don't think that there is a special need to document it though.  As with a lot of this process, we do rely to some extent on the people involved exercising good judgment, respect, and sensitivity (that is, after all, what respecting requests for confidentiality amount to anyway).
> 


From nobody Fri Jul 30 03:00:45 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167123A2443 for ; Fri, 30 Jul 2021 03:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-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 (1024-bit key) header.d=itaoyama.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 vzbAzNbh2Wk1 for ; Fri, 30 Jul 2021 03:00:37 -0700 (PDT)
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410102.outbound.protection.outlook.com [40.107.141.102]) (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 90BBC3A2449 for ; Fri, 30 Jul 2021 03:00:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cm0Z2X8sWgFaw1hF+9582i/tz49HL5dHfB/D9q6pf1ykVw5NbxHyRM0Bm5V9p/qoGf75luQEXaIaCZViyX+UJ/pQ5c0Nhhr9D/9RNYBEUx8XVc+Fzh+7ZWlkSZvKvl2w8JgsykoT5dmDTszqAGmkh+rkV9ih7OBOZtmr0u18wtwvec2H0K95CTGObPuw574puOMijzRxe6w2vHk8gUkiqRCZqBkM0IfSUu5tRsQe4+hZLAv7SBjzFQbaubF4zVzzxQ8OoaTvXxxwUNUy3vd3WMAzBajR1pxFNbY2pK//I2gM3zN3SLe7F7c02S2pJwfsr4rXkRlbJ7rhDpLRhBXViw==
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=Zsfa2n8rTtj2gBE/P2+v1OYGuvPdG11wKAkxRQFsOvc=; b=G/Immivtiev5zlDVDBtPqubyJaQpEkCdbYZGfvqelVlXP0CdCxfMLI20muBbULWNlhkeg8mxfmAyTyMZY/ubHxvPiKx+wEE8KSz/+G/ZFvHuFVxuC0yEzAE6l9t1wi68cqLxavLbLuavQIUFEG5gf4iTyUaU740jRvzXHUC4F88qzJEHUUPPV0VBLM4p11moOkC/JdviV/DMG2flM8Gz0jBYgYvckUBuEiZx4R48Obn+TQKIbWepPSiUjSyezss1TCR7/YxEMYKEJ8o5pyMxf4KM5JA6XD2KzRM/SJnWPk3KQvGFyJC5pVk4QATlT1xBL2t/PumA9fbm5YrTWNXJTw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zsfa2n8rTtj2gBE/P2+v1OYGuvPdG11wKAkxRQFsOvc=; b=HBeFGDmeCe+1WaX7WVmbT6LOYHA06S77W0YPt3GLjj0ylHpQJ1k1hdZOcBBnq//DbHkZu8I1la3lYl5fbcKj7sIrSFmuqfFd21grkhXgsvDSkl2RE7M0vbrew9lpVhPR2h141R0OMYHLLMQIqe7UD+/3Xl28imfgSxyrQfEh7SA=
Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp;
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYXPR01MB1470.jpnprd01.prod.outlook.com (2603:1096:403:c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.22; Fri, 30 Jul 2021 10:00:32 +0000
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b%6]) with mapi id 15.20.4373.025; Fri, 30 Jul 2021 10:00:31 +0000
To: Michael StJohns , rfced-future@iab.org
References: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com>
From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: 
Date: Fri, 30 Jul 2021 19:00:29 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
In-Reply-To: <6b5f89e8-2d79-016b-65bb-39704c438e96@nthpermutation.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: TYAPR01CA0046.jpnprd01.prod.outlook.com (2603:1096:404:28::34) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [133.2.210.39] (133.2.210.39) by TYAPR01CA0046.jpnprd01.prod.outlook.com (2603:1096:404:28::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18 via Frontend Transport; Fri, 30 Jul 2021 10:00:31 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 3a4e1520-5a36-4234-c0fc-08d95340ddf9
X-MS-TrafficTypeDiagnostic: TYXPR01MB1470:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: ELQUO8G10LeKud2sGl6Lwvt6aDbxfFO6tZSP+6gQ+z+D8UHx+NTvvVlL16WLoNKgs6eKFooTmCKYn6EgXsBzxL0laFyhWbyoOGpVDbP+APyyeZcwlznXEQ31eWCkqeLif3fBXr5o0arg+wwSXvNR/iFUVNACOPdpr/MdLTYu472keDsN7DX4Iv5SvCR829tZiRQgRqxHTsA0r/wisgpAJCEPozTweqz+Zd6n7ZWAhjTh0i7exIJKaLq8tiDAGtvcw1d1tt0OOK+4WOHq3wnbVEiJ7PFmsoaWRNPqI8zi+xFb9olKz2Zd+Ize3pWIX4PdmSjuEfP3yusYy5qpzUKBfbadn2gEQPEuSH+pel2G+vi3Qsuy10V0x6BmeDbz+4pKiNegm0RpF4NhYN6xH5Zwjpg1p0r+3E6d7OzxgQStTnWQG2c4jPeqe8Jtpf2pdbareW38fSsoEzQaFZ4bEXXmxZdecuyT/4fz4qlk1c5wef1+/vWwEWb4zZZ9ZJ4Ky7dgvLcPYY6182eyWaMmK8eN1SG/5BCdI1tGFt+B4imqIAY+HR0whcrsBOYERv9JZSQlRvCtBpLkPT6cDJP+BVhHHCIssyogmS36XL/c4XxgpDFflUs8u6b57i4x5K67kdBvL0f0a6406Sbd80QU+vkwKHxkkzMqezjKEcE/pvmLAz8qKxVj218GCCDZEE0UAMx5rBclx3g0qu8H32f4KphTHmoM6lxN6O3QV41P+pdC3GqOzoIFvWaxAn7KUMfu3uMA9G44V8ZfUnSjZltxk5+rtCg9QnfnF93M5wXjmRt/b0M=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE;  SFS:(346002)(39840400004)(396003)(366004)(376002)(136003)(6706004)(186003)(38350700002)(8936002)(26005)(316002)(2906002)(5660300002)(8676002)(786003)(31686004)(31696002)(66574015)(86362001)(38100700002)(66946007)(66556008)(956004)(66476007)(83380400001)(6486002)(2616005)(36916002)(16576012)(53546011)(52116002)(478600001)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?STJrOFVHaE5veHZMN211L2txcXF1VUE3M3FnZEhTbUJFMlNBUzJSQXA2ZkJX?= =?utf-8?B?L0JleUZUSzVWTGlHUC9NM3hOcXdPNWQyVVFzQmhpRjlweGRiNTZReDZlOENK?= =?utf-8?B?cHJqMTFad0hXRDNYcEV5YmQ4NnZndG54WWZoeUE3RDArelgyZVhkSmFoWWlP?= =?utf-8?B?R0xEMXhaeStzT245ZTRuSEthS1BKejZzZnEwRUFsaEdiOG1CTXlVSFlUblF1?= =?utf-8?B?elV2RWlKNXpCZ1VCcWlZbU1NM3FvZVgvNG05UEhEVk1mSlptcmQwcTZscnJX?= =?utf-8?B?dXZzeXdpMzV6Z2FnZy91d0RvaU11aUJzUWxpZXVkN0tGRVhTcGdkNy9rVVUw?= =?utf-8?B?NXlSeTNTazhOQzZsSGI5ZHEvbU52dlYyRVhHczNXWHdERlJKaFB5RlUxSWhX?= =?utf-8?B?T0J6ajFOc0VKYTk0c2cyUWorTVdQNTJWMU9Ea0JEQ3lLVDQ5THFzcHhMWmZj?= =?utf-8?B?SzMxdDFZL1ErbldvRkU5ck11MXh1dllKaTdXT0JZeFkzc25FcHM4d2dSSW1v?= =?utf-8?B?ZkxNS1ZIcFlhSjhhVnpqQkNkdnJyS1RrdnlTWVpndEcwcEdGMTgzTCtpSlQ3?= =?utf-8?B?UkNZNVFyVHkvTmdiUzVLay9uRStoamJPWG5rOU1jRHRlRnVvOXlsN0hRNno0?= =?utf-8?B?M0RZWk9IL2owMFhPcm5Sbi9LcUJobXVnSXRyZ2c2cHBGYW15ZFhhZlRlOERV?= =?utf-8?B?KzNnRk5TVURwcjV2OGY2M2Q4VVQ5dzZnNHZFOTh2OFdzSU5LaldsbjcwK2Rp?= =?utf-8?B?NkxhK3Q1aU9sQW1Dd2daUGxhRlhBelNYbWlGaEVqMFlzVTVpVzBaTWJkTHVh?= =?utf-8?B?cDlpQllhejlPSUIxV3dObU1HUm5WVDN3N2hwWkJ0ci9HeHRtd09xN2E2RVpK?= =?utf-8?B?VytaamVlRmFxbHJRNjlDM0lSZTkvVStwdEt2R05tOEg2U0p5VXZCSmFzd1VV?= =?utf-8?B?VGhjTzhVU3pJR2U1MGZOU2JDS2oxMGNkb2Q1aTJQTnlGS0dRQ1R6R3A1ZHhO?= =?utf-8?B?SU9zNkpyWEdDRVY4ODB4RVlNaG5VYURURzAxeS9zMjBRcGo5NUtXQjN4QmpK?= =?utf-8?B?aXIvZFhvbUc1Z3B5Nm1WSUcyZkdkU2FBVmJkb3gvTCtpR2RxQkF5bjQvdHVv?= =?utf-8?B?a1ZGaERIM3dZQnFLMDliRjRzUmdJSW0xTFJtNURNeVhicSs1cjY3TWpYN1pJ?= =?utf-8?B?eWxvVmU5NjV4RU5FNlY2REdIcnpGWXI2UmFsNmRPOTNTYWRTaElRazM5VGJv?= =?utf-8?B?WW0vRU5mR0dvZUx5MFlXekZYYnkzZ0NJTUlqdVlNMTZwT3VHeW85Q2loeEpu?= =?utf-8?B?TW9GS1NXMmhKVnA3VXk2WDliWGcvNnl4N3NiZEtyZEx2c3duYlZ2N2YyQXNV?= =?utf-8?B?OXdpcFZoOXJDbnhqNllQLzZvZEtXczMxOGwvcXlIbVZjcno0OXo2eDhxRDdy?= =?utf-8?B?Q2dUZmNmdzFrT0tlZjhUQ0liL1FONDhqbURWblg5QUNuYmxtdGtVNGJFcXl6?= =?utf-8?B?SDAramttNlpDQmZRd0Q1VnRRK25tSGdmNHdQRW9IMGdRb0FwV29qOWM5YmlF?= =?utf-8?B?QU91Y0xNczhUaVRIU3BqS0gxWGpnL0dDQ2VucEVvRVYwM0dHMHNGQTN1ckR4?= =?utf-8?B?c3p0RVAvbGdUUkl1bGUybHFwa1RmaDBLbVZoTEtKNVRKUTcrWTk2RFVZNE5N?= =?utf-8?B?K0hQczhUTnBQMVBuWHZGR1pCM2czYm9zMitKMDRNTlV5WFJqY29XbElSUFdz?= =?utf-8?Q?7VKIcKONv9sp4mR0VaWTSSuwpX0EzrKHZiAPMAT?=
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a4e1520-5a36-4234-c0fc-08d95340ddf9
X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2021 10:00:31.9110 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Hum1RI/TiuOz5HRiPfXgH9k/y2wN5kcFwso31d6fPE8lltqprCgSCHXMJbeal0EvePSYqV9PRQkC2D/yoDWDGA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB1470
Archived-At: 
Subject: Re: [Rfced-future] Replacement text for Section 4.2
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jul 2021 10:00:43 -0000

Hello everybody,

On this topic, I generally agree with others (Brian, Martin, and those 
before them). Just in case, on comment below.

On 2021-07-30 08:59, Michael StJohns wrote:
> Replacement for section 4.2:
> 
>          <<< Set a schedule - could be omitted, but this is a promise to 
> the community
> 
>                 as well as a schedule for the IED/RSEA >>>
>     No more often than semi-annually nor less often than bi-yearly, the
>     IETF Executive Director will send out to the community a call for
>     input on the performance of the RSEA.
> 
>      <<< Separate the IED's recommendation from the feedback process -
> 
>       there may not actually be an action that needs an immediate 
> recommendation >>>
> 
>     <<<< the IED acts as the confidentiality mediator, anonymous and 
> confidential
> 
>              comments get tagged in the document that goes to the LLC - 
> this provides
> 
>              needed context. >>>>
>     The IETF Executive Director and the stream managers will review the
>     received feedback and produce a draft summary (a paraphrase)
>     including both positive and derogatory information.

If this text every gets used, please change "derogatory" to "negative".
I hope it's obvious why.

Regards,   Martin.

>     Any feedback
>     provided anonymously shall be tagged as such in the summary. Any
>     feedback provided with a request for confidentiality shall likewise
>     be tagged in the summary and the IETF Executive Director MAY
>     comment on the weight that may be appropriate to apply to the
>     comment based on their knowledge of the submitter.  The stream
>     managers should ensure that any of their concerns are added to the
>     document at this point and MAY also provide any commentary on the
>     externally provided feedback that they feel appropriate.
> 
>     <<< Make sure that the LLC hears both sides of the coin >>>
>     That draft feedback, redacted with respect to any names associated
>     with confidential comments and with respect to the IED's weight
>     evaluations, shall be provided to the RSEA with for comment or
>     rebuttal, and such comments shall be incorporated as an appendix to
>     the final feedback document provided to the IETF LLC Board.
> 
>     << The previous text had this being a recommendation being sent to
>        the LLC, but instead this is a set of feedback, as no decision 
> may be
>        pending by the LLCin the near future.  The IED will provide a 
> recommendation
>        upon request from the LLC based on their own knowledge and any 
> previous
>        feedback documents... >>>
>     The LLC may take into account any recent feedback, along with any
>     recommendations of the IETF Executive Director in any of its
>     decisions related to the RSEA and their contract(s) or tasking.
> 
>     Whether the RSEA role is structured as a contractual or employee
>     relationship is a matter for the IETF LLC and the IETF Executive
>     Director to determine.
> 

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan


From nobody Fri Jul 30 09:06:38 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DB83A2EB0 for ; Fri, 30 Jul 2021 09:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV9BgiHbsfh7 for ; Fri, 30 Jul 2021 09:06:31 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7FE3A2EAC for ; Fri, 30 Jul 2021 09:06:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 89604300C56 for ; Fri, 30 Jul 2021 12:06:30 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xIEm8iFoyVVD for ; Fri, 30 Jul 2021 12:06:29 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 5DD453004A7 for ; Fri, 30 Jul 2021 12:06:29 -0400 (EDT)
From: Russ Housley 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Fri, 30 Jul 2021 12:06:28 -0400
References: <43bb84c8-6d1d-6455-dd7a-0a67eab47a16@lear.ch>
To: "rfced-future@iab.org" 
In-Reply-To: <43bb84c8-6d1d-6455-dd7a-0a67eab47a16@lear.ch>
Message-Id: 
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: 
Subject: Re: [Rfced-future] Consensus Check: Issue 40: RSEA selection committee
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jul 2021 16:06:37 -0000

If the LLC is unable to come to terms with the person selected by the =
selection committee, what happens?  I hope the selection committee gets =
a high-level summary of the problem and then they make another =
recommendation.  I would not want the LLC to choose an alternate without =
futher input from the selection committee.

Russ

> On Jul 29, 2021, at 7:15 PM, Eliot Lear  wrote:
>=20
> During today's meeting, the following text was proposed for Section =
4.1:
>=20
>> The LLC will form a selection committee, including members from the =
community, that will be responsible for making a recommendation to the =
LLC for the RSEA. The selection committee will take into account the =
role definition [CITE] and any other information that the community =
deems necessary or helpful in making its recommendation. The LLC is =
responsible for contracting or employment of the RSEA.
>=20
> If you disagree with this approach, please could you comment by the =
13th of August?
>=20
> Thanks,
>=20
> Eliot


From nobody Fri Jul 30 14:06:54 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C935C3A10B7 for ; Fri, 30 Jul 2021 14:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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 QaS_yPZn4NgT for ; Fri, 30 Jul 2021 14:06:48 -0700 (PDT)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 3FE203A10B3 for ; Fri, 30 Jul 2021 14:06:48 -0700 (PDT)
Received: by mail-pj1-x1036.google.com with SMTP id ds11-20020a17090b08cbb0290172f971883bso22628524pjb.1 for ; Fri, 30 Jul 2021 14:06:48 -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=P92EMBIq422mBXnIx67Gs5/346D6SMBqDEz5DdbVjSE=; b=jmM48Iq8RaUMfiuKHMlcYc83JceFQ0oFWLy8yLGIaC4T3sWBUvhHy4DGAjJ1nsjveK z5/qzFqw5nRJcF2T5vkAoY1mFNVI3ruG+IN04BsVffgRHC/qIzb3qk75ppFEUGFzA5CK XNFs/e4UZ7ADv5PZGdDfn/SpOarAu88l76KGUEX5DG5pTzsnkTril5pPqiobQeNWHtA6 g1EZp/ga6zzfADL7LVBKnXFzoj43GRjKQ1DLVCs8KO74XTZaYxSMFg10/sSu0XXOS10c W05vaTYQyH64hGTkP4Xxvb+DDFi5oeJhBZ7frW4hqDgJxUbXXbAp4juX9sIRHPFRfUWv CZXA==
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=P92EMBIq422mBXnIx67Gs5/346D6SMBqDEz5DdbVjSE=; b=SYEQzVs04AoN19Q5WN5IPtbsacarkHsiLaxZ8FZTi3Vax/Rm0zbpho42o2BJErhEgD 4YwUXTWbUi4UJ+X3rdVF6kydtWc+gy7A5dFfiBvnsgJvY61uTEudkaGVMWC5FWHVjB1o cXjjAYb/f9RNfDcD2S6rqgxBKe02/pzjTt9AT2eYDRZiFZD3JUdcArwsKocNFAf8T/05 OXZzQPLRClh6LPbgXo8HMQ+tBKR4nZiZyVlHzwCUXnDSvM/+LKo5heTuRkSN/EqNxIiG DbblLXY69NKZrKb8PjW41mdHXR5vOxJVcKo6EqibvrtqBrzVUKmy+hjJ7nXmz4G/MDb6 U/6A==
X-Gm-Message-State: AOAM531pRVRkSs2j43M4IeZeQArM5hxz4cTAg2gwqdmKK5BpyDJQONtt f+0E72q89B743t5ld0zno9i/zvDWwlfgIA==
X-Google-Smtp-Source: ABdhPJxv0r72rW3Nmrw7QulhhMmveSC+tzqzgu+4vcbr+cVEvSnc8Rq4KyXHRGX58FyAOUe3s1mI2A==
X-Received: by 2002:aa7:9ec3:0:b029:32b:4eb5:4bad with SMTP id r3-20020aa79ec30000b029032b4eb54badmr4648853pfq.6.1627679206603;  Fri, 30 Jul 2021 14:06:46 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id i6sm3369593pfa.44.2021.07.30.14.06.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jul 2021 14:06:46 -0700 (PDT)
To: Russ Housley , "rfced-future@iab.org" 
References: <43bb84c8-6d1d-6455-dd7a-0a67eab47a16@lear.ch> 
From: Brian E Carpenter 
Message-ID: 
Date: Sat, 31 Jul 2021 09:06:43 +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: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus Check: Issue 40: RSEA selection committee
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jul 2021 21:06:53 -0000

On 31-Jul-21 04:06, Russ Housley wrote:
> If the LLC is unable to come to terms with the person selected by the selection committee, what happens?  I hope the selection committee gets a high-level summary of the problem and then they make another recommendation.  I would not want the LLC to choose an alternate without futher input from the selection committee.

I agree with that, but a typical scenario might be that the committee ends up with a list of two or three good candidates, but it's the LLC that has to negotiate terms and conditions, and can only reach agreement with the 2nd or 3rd candidate. The text should not over-specify the details of that.

   Brian

> 
> Russ
> 
>> On Jul 29, 2021, at 7:15 PM, Eliot Lear  wrote:
>>
>> During today's meeting, the following text was proposed for Section 4.1:
>>
>>> The LLC will form a selection committee, including members from the community, that will be responsible for making a recommendation to the LLC for the RSEA. The selection committee will take into account the role definition [CITE] and any other information that the community deems necessary or helpful in making its recommendation. The LLC is responsible for contracting or employment of the RSEA.
>>
>> If you disagree with this approach, please could you comment by the 13th of August?
>>
>> Thanks,
>>
>> Eliot
> 


From nobody Fri Jul 30 15:34:37 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C863A1407 for ; Fri, 30 Jul 2021 15:34:33 -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, 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 (1024-bit key) header.d=mozilla.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 a4SUHBcS_V5r for ; Fri, 30 Jul 2021 15:34:28 -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 6472D3A0408 for ; Fri, 30 Jul 2021 15:34:28 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id f6so7421321ioc.6 for ; Fri, 30 Jul 2021 15:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=O8ug9zSITqAeedzxwZ/5JMQwCvqbE0/d4tnNr8yFnWg=; b=V5JXknJR7SOHfDwmhqmDa5FOm9uo24pjNSUaSkBjt/9iegKyUPB1+6fFBlzxkG84QL h0325oGInkQr9ZLfZMNuQ3owzPWjj9uCmXYxyKM3KmKZIj7lpgIQBL/bOxJFosU1xZvt Yvm1UoMPa7rKp5YZTMPbGsdOu/uXuZcSOB9aQ=
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=O8ug9zSITqAeedzxwZ/5JMQwCvqbE0/d4tnNr8yFnWg=; b=Gd2HysPKDVsPErQBBjR8Pl+FYS9e3a80vZRBERbww0dfx/xQ5SZ1ol2dHYv6pVFnuj wly82tRaeRSFzoUboTSf3tHplZN5RhMnkvyw+Z7MK7oX/z5u9BkIyY//XfxxfX04KGIC EFFy4QsoYFlsCB0Jh0OTBAL2dNXIXgz482Q88bxGaW2SmM+G17gD68xqeFst4XCs++NH W3wnACeDftopmQkju9AI0gS4exbRgDS6qUBE5lkXb8rnTF9GXnsrp7ZQqW585iH7g1Ne eWDaFkNbHjEVJ5lCGEhk5NiZS06AHxvvSUyFzESU5ceuLdZowR5jHSZC/zMoAL69os0z Hr8A==
X-Gm-Message-State: AOAM531UzuitF28bAQ9/QwYI6sceTmHteTP2kTBQz6QlWv2vtWvHWBQL FtXMST85dqw8NG2QGUFtKtS9yw==
X-Google-Smtp-Source: ABdhPJwJgpUtlgEVeuzEIxdD0i+Ng8C97Y5EM4eL7dO0gUupjxi4hb3LbSiONh9j07rIFot6F/8CUw==
X-Received: by 2002:a5d:8484:: with SMTP id t4mr2071867iom.126.1627684466294;  Fri, 30 Jul 2021 15:34:26 -0700 (PDT)
Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id d8sm1463990ilq.88.2021.07.30.15.34.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jul 2021 15:34:25 -0700 (PDT)
To: Brian E Carpenter , Russ Housley , "rfced-future@iab.org" 
References: <43bb84c8-6d1d-6455-dd7a-0a67eab47a16@lear.ch>  
From: Peter Saint-Andre 
Message-ID: <23a89180-a7eb-766a-7f9b-ba3626efe0dd@mozilla.com>
Date: Fri, 30 Jul 2021 16:34:24 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus Check: Issue 40: RSEA selection committee
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jul 2021 22:34:36 -0000

On 7/30/21 3:06 PM, Brian E Carpenter wrote:
> On 31-Jul-21 04:06, Russ Housley wrote:
>> If the LLC is unable to come to terms with the person selected by the selection committee, what happens?  I hope the selection committee gets a high-level summary of the problem and then they make another recommendation.  I would not want the LLC to choose an alternate without futher input from the selection committee.
> 
> I agree with that, but a typical scenario might be that the committee ends up with a list of two or three good candidates, but it's the LLC that has to negotiate terms and conditions, and can only reach agreement with the 2nd or 3rd candidate. The text should not over-specify the details of that.

Agreed.

Peter