From nobody Sun Jul 1 10:59:40 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A40130DD2 for ; Sun, 1 Jul 2018 10:59:37 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opendkim.org header.b=avAN+i8p; dkim=pass (1024-bit key) header.d=elandsys.com header.b=B4G7Nc/8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOsLZWVj86by for ; Sun, 1 Jul 2018 10:59:36 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 145B8130DD5 for ; Sun, 1 Jul 2018 10:59:36 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.23.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id w61HxONv023093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Jul 2018 10:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1530467975; x=1530554375; bh=EYsBQHE9hc0LjAdP3G70/NQiEcVwFXUg2p9CMF8yRYQ=; h=Date:To:From:Subject; b=avAN+i8p7hJqS3AONn03M0L7tVX/i9e6oPCZdexDgoVbyb2j/V5LGnhVokpMudAgG zC8gm4Jy3aL+3HN2LGQl37/ZcLUiVkZIWL4nwADVeO+bCM3zEchrmCRACFkOqLnHzk FDn5RIpVrq7okBabFpmYBxEeS5Hh3c3hoJS4vdSw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1530467975; x=1530554375; i=@elandsys.com; bh=EYsBQHE9hc0LjAdP3G70/NQiEcVwFXUg2p9CMF8yRYQ=; h=Date:To:From:Subject; b=B4G7Nc/8Zef26FDVhdAWqP0SaBTvt//pa+EOy7d5Bx0/Xrl135zOTXF12KzAxpi7E owOng5rbS/bckK14WGyyyhmqyVgTpN+CNYA+j2IyqeKmoEBfmDeMDu35OjbHHchxi6 1iYYxPg7D8qmAWXlR/qUWLDSYJyNxc0VFbDg3hyc= Message-Id: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 01 Jul 2018 10:57:58 -0700 To: rfcplusplus@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 17:59:38 -0000 Hello, I searched for information about the RFC++ BoF and came across the "About" information for this mailing list. Who are the BoF proponents? The proposed experiment reminded me of RFC 6393. Nobody within the IETF was enthusiastic to do the "clean up" after that experiment. If I understood correctly, the purpose of the proposed RFC experiment is to correct the misconception that all RFCs are standards by reserving "RFC" for standards-related documents. What is the meaning of "standards-related"? Does it mean documents in the IETF Stream? Does it include the "Informational" and "Experimental" documents in the IETF Stream? Regards, S. Moonesamy From nobody Sun Jul 1 11:19:39 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D783912F295 for ; Sun, 1 Jul 2018 11:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB5zg6-z8L4P for ; Sun, 1 Jul 2018 11:19:36 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2767E124BE5 for ; Sun, 1 Jul 2018 11:19:36 -0700 (PDT) X-AuditID: 1209190c-5cdff70000003dbd-5a-5b391b3655fd Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 2D.B4.15805.63B193B5; Sun, 1 Jul 2018 14:19:35 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w61IJXLB007903; Sun, 1 Jul 2018 14:19:34 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w61IJTNN016075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 1 Jul 2018 14:19:33 -0400 Date: Sun, 1 Jul 2018 13:19:29 -0500 From: Benjamin Kaduk To: S Moonesamy Cc: rfcplusplus@ietf.org Message-ID: <20180701181929.GB22125@kduck.kaduk.org> References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixG6nomsubRltcKiHxeLl9jqLV/03WR2Y PO69+cjksWTJT6YApigum5TUnMyy1CJ9uwSujI0T5zMXzOKouPTmOXMD4wm2LkZODgkBE4kT 3+YC2VwcQgKLmSSOTrjHBOFsYJSY+uUCK4RzhUni2IWLjCAtLAIqEi9mHGUFsdmA7Ibuy8xd jBwcIgJqEvtmpoOEmQUkJJZu/cYCYgsLGEo8XLwNbBsv0LZ9W/YwgdhCArYSrT3TmCDighIn Zz5hgejVkrjx7yUTyEhmAWmJ5f84QMKcAnYSZz69ZwexRQWUJfb2HWKfwCgwC0n3LCTdsxC6 FzAyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI11MvNLNFLTSndxAgKUU5Jnh2MZ954HWIU4GBU 4uFdIGYZLcSaWFZcmXuIUZKDSUmU97CYWbQQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV7Rj+bR QrwpiZVVqUX5MClpDhYlcd7sRYzRQgLpiSWp2ampBalFMFkZDg4lCV4VKaA9gkWp6akVaZk5 JQhpJg5OkOE8QMNZJIFqeIsLEnOLM9Mh8qcYdTn+vJ86iVmIJS8/L1VKnFcdZJAASFFGaR7c HFBqkcjeX/OKURzoLWGIdTzAtAQ36RXQEiagJdXHTUGWlCQipKQaGCeoG4ncmsrxPG7Cpbsf lr3awCh7j5PpwmId/zOHbnpsXLPbyKBt5s8Nwr+sPl3f9EvAmy92nkXbb6vI9KtRCsfc3tRw ct3JjjBr/SNzWf3nwR/np9l+8bOMrzfgLjy3zloh9PichZbq6at4a4V2XTgbZ+2m2pftc97M xuV54wq9Fy7H69KfLlJiKc5INNRiLipOBACVe+TWCAMAAA== Archived-At: Subject: Re: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 18:19:38 -0000 On Sun, Jul 01, 2018 at 10:57:58AM -0700, S Moonesamy wrote: > Hello, > > I searched for information about the RFC++ BoF and came across the > "About" information for this mailing list. Who are the BoF proponents? https://trac.tools.ietf.org/bof/trac/wiki/WikiStart is pretty clear about this. (Martin Thomson and Melinda Shore) > The proposed experiment reminded me of RFC 6393. Nobody within the > IETF was enthusiastic to do the "clean up" after that experiment. If Sorry, I don't know what you intend to mean when you say the "clean up" for that experiment. > I understood correctly, the purpose of the proposed RFC experiment is > to correct the misconception that all RFCs are standards by reserving > "RFC" for standards-related documents. What is the meaning of > "standards-related"? Does it mean documents in the IETF > Stream? Does it include the "Informational" and "Experimental" > documents in the IETF Stream? This is covered in RFC 7841. (BCP, proposed standard, internet standard) -Ben From nobody Sun Jul 1 11:44:24 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83444130E7B for ; Sun, 1 Jul 2018 11:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=nJaiLUvL; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=2Vl3pGpW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4p7FRB1Y2_M for ; Sun, 1 Jul 2018 11:44:20 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D87C130E78 for ; Sun, 1 Jul 2018 11:44:20 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.23.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id w61Ii8U4008476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jul 2018 11:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1530470659; x=1530557059; bh=+apFvyh8+wN5Z27CVQ9ZgAEI05UHe29YdZ8lNIPgTB0=; h=Date:To:From:Subject:In-Reply-To:References; b=nJaiLUvL2W9QuyLW4u0wrxR2D+xZurGD1cqax2Re7sHCO7GUSKXt2K/7GRI1ISVhE Y1FNY1MW9mTcBkHMNFNrcjG753VOEB0w0VhqgHRoH5gsnxeriCTJ+qllKPFhvikmCc Qt1x8XUL2lG1MTSriwi5xelTEJ5IHoqCcegKZYjw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1530470659; x=1530557059; i=@elandsys.com; bh=+apFvyh8+wN5Z27CVQ9ZgAEI05UHe29YdZ8lNIPgTB0=; h=Date:To:From:Subject:In-Reply-To:References; b=2Vl3pGpWgmrCPxjvoJgNbs5KHqJFVLiWqdOLC8rKJkDr1texpf0+w0IL8TCzsmkay Z5WdkOpgbHttECzNTt9S/pB8i4Z/UQ/o4fFxE31k/+3W3ll5H9f3cSAiYnQUymzwmz 0q6IVaeL8ut8TTxAJqf2uW9TlPseyY/bXUKeplrg= Message-Id: <6.2.5.6.2.20180701112143.0b3247a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 01 Jul 2018 11:42:38 -0700 To: Benjamin Kaduk , rfcplusplus@ietf.org From: S Moonesamy In-Reply-To: <20180701181929.GB22125@kduck.kaduk.org> References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> <20180701181929.GB22125@kduck.kaduk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 18:44:22 -0000 Hi Ben, At 11:19 AM 01-07-2018, Benjamin Kaduk wrote: >https://trac.tools.ietf.org/bof/trac/wiki/WikiStart is pretty clear about >this. (Martin Thomson and Melinda Shore) Thank you for the link. >Sorry, I don't know what you intend to mean when you say the "clean up" for >that experiment. The "clean up" would entail having an I-D, a Last Call and IESG review. It was not viewed as worth the effort in 2011. >This is covered in RFC 7841. (BCP, proposed standard, internet standard) Ok. Regards, S. Moonesamy From nobody Sun Jul 1 12:03:24 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B2D130DC9 for ; Sun, 1 Jul 2018 12:03:22 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 SOxyUFo6g6mh for ; Sun, 1 Jul 2018 12:03:20 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451AD130E97 for ; Sun, 1 Jul 2018 12:03:20 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fZhd0-0005R9-L3; Sun, 01 Jul 2018 15:03:18 -0400 Date: Sun, 01 Jul 2018 15:03:11 -0400 From: John C Klensin To: S Moonesamy cc: rfcplusplus@ietf.org Message-ID: <14134BFED03190159F304C91@PSB> In-Reply-To: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 19:03:22 -0000 --On Sunday, July 1, 2018 10:57 -0700 S Moonesamy wrote: > Hello, > > I searched for information about the RFC++ BoF and came across > the "About" information for this mailing list. Who are the > BoF proponents? The BOF proposal page (https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#TimeframeIETF102Montr%C3%A9al) shows Martin Thomson and Melinda Shore, I presume on behalf of the IAB, and Alissa Cooper as the Responsible AD. I note that, while the BOF proposal identifies RFC 1786 as identifying a problem that has not been solved, 1796 (which I would encourage people to read before the BOF) actually explains the reasons for a single archival series. It also suggests that documents that are actually standards be referred to by their STD numbers for clarity (i.e., not by their RFC numbers). The problem with that approach is become quite obvious in the subsequent 23 years -- despite several efforts to adjust things, the Internet continues to run on Proposed Standards and Proposed Standards do not have STD numbers. A simple and obvious solution to that part of the problem has been proposed, in different forms, several times: assign STD numbers to all Standards Track specifications from Proposed forward (or retire "STD" and assign a new set of numbers to all standards track documents), but the IESG has repeatedly declined to consider those proposals. Because there is no agenda posted yet and there seems to be a strong case that assigning numbers instead of RFC numbers (rather than in addition to them, which would be the solution derived from 1786) is not an experiment at all because there would be no going back, I'd going to repost the most recent of those STD proposals in the hope that the BOF can consider it as an alternative. > The proposed experiment reminded me of RFC 6393. Nobody > within the IETF was enthusiastic to do the "clean up" after > that experiment. If I understood correctly, the purpose of > the proposed RFC experiment is to correct the misconception > that all RFCs are standards by reserving "RFC" for > standards-related documents. What is the meaning of > "standards-related"? Does it mean documents in the IETF > Stream? Does it include the "Informational" and > "Experimental" documents in the IETF Stream? The BOF proposal says that one purpose of the BOF is to sort out that issue. Of course, the two categories of BCP documents (actual current practice documents related to protocols specs and IETF procedural documents) are another set of questions. Given that the proposal appears to be not allocate new RFC numbers to non-standards, should new BCP documents not be assigned RFC numbers either? john From nobody Sun Jul 1 12:56:44 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D82130E13 for ; Sun, 1 Jul 2018 12:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=F6YkZsxe; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=R4f3fYk/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YOrleSkyQuu for ; Sun, 1 Jul 2018 12:56:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B399D130E82 for ; Sun, 1 Jul 2018 12:56:40 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.23.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id w61JuSN3022589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jul 2018 12:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1530474999; x=1530561399; bh=oM7BsA0onFF0MV0VLgeEDaZ1WjxhdisJ4c772CRwTbc=; h=Date:To:From:Subject:In-Reply-To:References; b=F6YkZsxeDyfLuFoJOAj3yyI5Wi69k5VjtVCaw/OB3OVAm04ZCDJzc/NdrKUAzi96a QpTnsbwuD7cIX+FoTqvwlH5FZDEzrdPGb0gkbs3ZZGsQy0XyldUrJ69J6B76nIS3kY mHb1vd1R5kmnaifUmjh7Xa3DatPmtnuPwf0zzg+k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1530474999; x=1530561399; i=@elandsys.com; bh=oM7BsA0onFF0MV0VLgeEDaZ1WjxhdisJ4c772CRwTbc=; h=Date:To:From:Subject:In-Reply-To:References; b=R4f3fYk/mESWQqO0Ym1q4i+K+nvN5u33/kyXf8tZDacg3lS3BoxpMkppWjcmwhT4z dAc0lDud7kDZ3uViFTarL9CZW8nWKDoOW4mzFbfQQfjNtIsiXDGr2iu3rLGPgaje7q KF4lU9DJCgxoHOIXojnhXDCeM9fypYi95aUNqllE= Message-Id: <6.2.5.6.2.20180701122714.0df37fc0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 01 Jul 2018 12:56:17 -0700 To: John C Klensin , rfcplusplus@ietf.org From: S Moonesamy In-Reply-To: <14134BFED03190159F304C91@PSB> References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> <14134BFED03190159F304C91@PSB> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 19:56:43 -0000 Hi John, At 12:03 PM 01-07-2018, John C Klensin wrote: >The BOF proposal page >(https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#TimeframeIETF102Montr%C3%A9al) >shows Martin Thomson and Melinda Shore, I presume on behalf of >the IAB, and Alissa Cooper as the Responsible AD. Thanks, I missed that when I previously searched for information. >I note that, while the BOF proposal identifies RFC 1786 as >identifying a problem that has not been solved, 1796 (which I >would encourage people to read before the BOF) actually explains >the reasons for a single archival series. It also suggests that >documents that are actually standards be referred to by their >STD numbers for clarity (i.e., not by their RFC numbers). The >problem with that approach is become quite obvious in the >subsequent 23 years -- despite several efforts to adjust things, >the Internet continues to run on Proposed Standards and Proposed >Standards do not have STD numbers. A simple and obvious >solution to that part of the problem has been proposed, in >different forms, several times: assign STD numbers to all >Standards Track specifications from Proposed forward (or retire >"STD" and assign a new set of numbers to all standards track >documents), but the IESG has repeatedly declined to consider >those proposals. The BoF is based on a RFC from "Legacy". I found it odd that the discussion is about RFC number for standards while there is already a (STD) number for that. Several years ago, there was the discussion about the categorization of "proposed standard". The proposed experiment may end up creating another legacy. If the IETF was confident about its brand, it would use another label instead of relying on "RFC". >The BOF proposal says that one purpose of the BOF is to sort out >that issue. Of course, the two categories of BCP documents >(actual current practice documents related to protocols specs >and IETF procedural documents) are another set of questions. >Given that the proposal appears to be not allocate new RFC >numbers to non-standards, should new BCP documents not be >assigned RFC numbers either? If I were to follow the "distinguishability" argument, I would say that the procedural documents should be separated as well. Regards, S. Moonesamy From nobody Sun Jul 1 15:24:37 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2620130E07 for ; Sun, 1 Jul 2018 15:24:35 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 LEnI0SNg4lzZ for ; Sun, 1 Jul 2018 15:24:34 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 37A69124D68 for ; Sun, 1 Jul 2018 15:24:33 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id h20-v6so4627445pfn.4 for ; Sun, 01 Jul 2018 15:24:33 -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=gjfp3uc0i2CaUy5pI7hYdpvDJmw6AMfEBwObdr2wpHI=; b=s0caRJZ6PdKzSdyHzDhHfiX9gImf9vtaAZzL7V7stQxWb6KvgPGQxLpnTnoNmHoofO 08/KJpCPUk/wIoCjXNfhInd3xsPyUat7crFqVW9ymIyAFgVpwFn8mGYlDHg83H8TV7ZA M5r5YESZbbNR0UlCIOnv9icRzALCTehqpuXdCDSfEnNrblBNtkGMt4fqSloBYl4bgJ3B oy3z1ZwyeOWnS0luJy9QBtOX+qIIMctrn36R8tAdvpfpv/Omv23NNVo7KoZ0FI/5jrGs V7cNfwcN7hLCzdULwmeNI74njDzfyyr1pOYTfotZRhiqSB1vuwlZ9IcPDofSVxYfXp9T brnw== 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=gjfp3uc0i2CaUy5pI7hYdpvDJmw6AMfEBwObdr2wpHI=; b=be2ivKBPRnLjrPb4M7crsaKEdrmGNT5n9Rj5hAnaKxdO7tXGuEUFHo63wk7JMbYSp+ 2PWVv+V+GubDQEj/GP9cBclPzcEx6af49flSss62lSVUXK8G+p8F0nYTpNqlNOHaxGv2 PBNwBATLVnvxCdysRovnweBJ1EvPvYkDHLJ94uuNXuMGhmFb5aEV2PrxDUi8oTsl8DeA JflpPds+9Aq4euzyoy1E9ZvTBsioKHxJSkBK9KEgMiRitsgjhxBxagpKRt7yuxbXkj6F skTxp7AdUJ9Tumyqyy/pXpT9H9YkKq/yxTHNO17Yxo3xoyOzDUQ66OvhSyXO1LOd3fI/ A2oQ== X-Gm-Message-State: APt69E12H5asFD0lLVgoBys80x4pYb1JiAbnBiX2FLMI7QtkCemd1Tte YFGROj/ZVWItC/AEcj2QrTRcCw== X-Google-Smtp-Source: AAOMgpdwY29WNdpMiqfQd9N5kHYdMl2CUspIqhH2k2RPwsDobKa+639P0Tw8rShf5OOG9vGsmbOuZQ== X-Received: by 2002:a62:3f44:: with SMTP id m65-v6mr15318192pfa.98.1530483873035; Sun, 01 Jul 2018 15:24:33 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id m10-v6sm22359593pgq.89.2018.07.01.15.24.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Jul 2018 15:24:32 -0700 (PDT) To: Benjamin Kaduk , S Moonesamy Cc: rfcplusplus@ietf.org References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> <20180701181929.GB22125@kduck.kaduk.org> From: Brian E Carpenter Message-ID: <5e4bc5f6-d5f8-3077-1302-26c48bef5e32@gmail.com> Date: Mon, 2 Jul 2018 10:24:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180701181929.GB22125@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 22:24:36 -0000 On 02/07/2018 06:19, Benjamin Kaduk wrote: > On Sun, Jul 01, 2018 at 10:57:58AM -0700, S Moonesamy wrote: >> Hello, >> >> I searched for information about the RFC++ BoF and came across the >> "About" information for this mailing list. Who are the BoF proponents? > > https://trac.tools.ietf.org/bof/trac/wiki/WikiStart is pretty clear about > this. (Martin Thomson and Melinda Shore) > >> The proposed experiment reminded me of RFC 6393. Nobody within the >> IETF was enthusiastic to do the "clean up" after that experiment. If > > Sorry, I don't know what you intend to mean when you say the "clean up" for > that experiment. The clean-up is well described at https://www.ietf.org/old/2009/u/iesgcontent/ions.html Actually I think the IESG did a fairly good job of the clean-up in that case, because the experiment was structured non-destructively, i.e. it *added* a new document series that could be abolished quite harmlessly. That is not true of the so-called experiment proposed in the BOF description. >> I understood correctly, the purpose of the proposed RFC experiment is >> to correct the misconception that all RFCs are standards by reserving >> "RFC" for standards-related documents. What is the meaning of >> "standards-related"? Does it mean documents in the IETF >> Stream? Does it include the "Informational" and "Experimental" >> documents in the IETF Stream? > > This is covered in RFC 7841. (BCP, proposed standard, internet standard) The alleged problem and the proposed experiment are not described in a draft, unless I've missed something. The suggested reading doesn't include even the recent drafts that seem relevant (still less older ones): https://tools.ietf.org/html/draft-klensin-std-numbers https://tools.ietf.org/html/draft-carpenter-request-for-comments https://tools.ietf.org/html/rfc5434#section-3 seems relevant Brian From nobody Sun Jul 1 15:41:32 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040F2130DCB for ; Sun, 1 Jul 2018 15:41:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 gR-sECYvU5Xi for ; Sun, 1 Jul 2018 15:41:29 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC96124D68 for ; Sun, 1 Jul 2018 15:41:29 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id t6-v6so6983064plo.7 for ; Sun, 01 Jul 2018 15:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=TxsT4zwCAHY7jRkHCCzJyVVrA/2uWf8ha0RnmPwtmOI=; b=YCmbz6phBsnXJQtWe93poibxhQhjDCaPh2zx2co6sfocBz2EdgQmepAtXFeVXTTWUB 1obNT1WRf0oyQa7nfDWD7eDp+Lb4Kxo6L/3p2hLSBR0Cn9R2HE+2fO9O41COjHXE/nWK 0YfSw8tfXOMYPuzuKSTdQxln4YphwffYXb+GDqCIUUTnBDQ0k3MRJeL0pDiq4kLK3zlW 1iLjkdbaRAnisUWmmA2FciHqyQxnSM8XYg1Dpa/l97J2N1kNIIiPSXYN17uXbLcSVa9f dNae6K//fJhIFleruCFHFPJFQXPGZBXsVT0OEiVgN5TNJY4JbeybehGVTSMbvegElSO4 j4ag== 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:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=TxsT4zwCAHY7jRkHCCzJyVVrA/2uWf8ha0RnmPwtmOI=; b=GwJoI/dwP1zfHH2LNdsL9JvBCiVLX8TupJHe6+TZlauu4Jt4NCPuAOAiH2Blf3SrYS oN54ftel+s7ImG7ak82UEZxHwY3jaglq1J9+c2dMHtm7q6t/FcmZo8LrKBMAUHZsvfSn /ZJ42xFahog3eH3YqO51cl3kvqKuBLZta4xpu9vLFtOgnLV9MxG/VmTH9pGcTYhNboK8 418OBYgHHe8MRtwZkf7TTCw2SCXyOyOYnu86pvY3UsXt+0u+4h+5G6wzzyXaSmxljSXc TIQHWrGq0z4md+qXHHZXYrY+kEIhQzgfyf5YWL+LYSD9MWUvab0h0WHi4cN78WeTkWDv 0Rww== X-Gm-Message-State: APt69E3XCc0mvNRyExovqvHGUhqqVGglO/ffUZWKYrucYfGvDIkdBFgx a3XKfSCkKetkN1aYhU6I3lFIhA== X-Google-Smtp-Source: ADUXVKLSBoMIFr5fwGuv3owf0/xKYFBV9vCEWdCVyfe75Vqjeoh349Ua5vPJ2Lvg5xJYhlFWdkxhlQ== X-Received: by 2002:a17:902:bf43:: with SMTP id u3-v6mr23423958pls.322.1530484888499; Sun, 01 Jul 2018 15:41:28 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id m25-v6sm27764417pfg.61.2018.07.01.15.41.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Jul 2018 15:41:27 -0700 (PDT) To: rfcplusplus@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 2 Jul 2018 10:41:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfcplusplus] About prioritising problems X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 22:41:31 -0000 I have a tendency to solve easy problems first, as many of us do, but I would like to fundamentally question the effort going into the stated problem here (failure to read RFC boilerplate and notice the status, if I have that right) when we have a reasonably large number of more fundamental unsolved process-related problems. Many of them are more than a decade old and we've been letting them slide: https://tools.ietf.org/html/draft-carpenter-rfc2026-critique-03 Brian From nobody Sun Jul 1 16:31:37 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A18D130E12 for ; Sun, 1 Jul 2018 16:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=dFDNHSg4; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=u1qm6p/t Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84w9TLmcUIUf for ; Sun, 1 Jul 2018 16:31:34 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE1D1292F1 for ; Sun, 1 Jul 2018 16:31:34 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.23.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id w61NVId5004505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jul 2018 16:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1530487890; x=1530574290; bh=lHcMheBBopVxEL21a6ZKEn0SVuswtveGpGt1Zs4TGdk=; h=Date:To:From:Subject:In-Reply-To:References; b=dFDNHSg4CXiDRcWs1xT+z1XxXceoYEc7Jbe1nMNJ7k9L7ZYD5Wq0yhpV5Wcsheitu jWC+tp/PP+ufe5ydX1GQyLXu1jwm9ioIOXi2Go2P2U7GFI1JzjOXxrqMvRau8UtlmR 7CcsHpVDertJwC/R1M5JxcD4REalHe1a/1k0DBJQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1530487890; x=1530574290; i=@elandsys.com; bh=lHcMheBBopVxEL21a6ZKEn0SVuswtveGpGt1Zs4TGdk=; h=Date:To:From:Subject:In-Reply-To:References; b=u1qm6p/t5WdjUouRMQyksVEu1EAHhn6YtrH5NN2yVdFGaiCfik3n2d2F4TVuCc28/ Yq+l2p2GgOpMz1qdWiDQPGRYgjKG5C1g6h2TKigeh5BsDbrJ9P3hHWiQqy96QgI0P6 qKri0y/9DrjHo9jNCO6H8Zav2EuF5GOnPNSrWPFE= Message-Id: <6.2.5.6.2.20180701153030.0df344d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 01 Jul 2018 16:30:02 -0700 To: Brian E Carpenter , rfcplusplus@ietf.org From: S Moonesamy In-Reply-To: <5e4bc5f6-d5f8-3077-1302-26c48bef5e32@gmail.com> References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> <20180701181929.GB22125@kduck.kaduk.org> <5e4bc5f6-d5f8-3077-1302-26c48bef5e32@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 23:31:36 -0000 Hi Brian, At 03:24 PM 01-07-2018, Brian E Carpenter wrote: >The clean-up is well described at >https://www.ietf.org/old/2009/u/iesgcontent/ions.html > >Actually I think the IESG did a fairly good job of the clean-up in >that case, because the experiment was structured non-destructively, >i.e. it *added* a new document series that could be abolished quite >harmlessly. That is not true of the so-called experiment proposed >in the BOF description. The opinion depends on whether one is looking at the matter from an IETF perspective or a non-IETF perspective. >The alleged problem and the proposed experiment are not described in a >draft, unless I've missed something. The suggested reading doesn't include >even the recent drafts that seem relevant (still less older ones): >https://tools.ietf.org/html/draft-klensin-std-numbers >https://tools.ietf.org/html/draft-carpenter-request-for-comments > >https://tools.ietf.org/html/rfc5434#section-3 seems relevant I read the two drafts. If I am not mistaken, the first attempt at numbering occurred in 1971. Your draft mentions that one of the issues was about finding the latest version of the standard. As an anecdote, I came across a regulation which references an I-D as a standard. I'll leave it to the BoF to figure out the answer to "who owns the RFC Series?" I suggest taking into consideration that the community who will be at the BoF is usually a subset of the wider audience who uses RFCs. I like what you wrote at the end of Section 4 about "standard organisations". The RFC which you cited is an IETF classic [1]. Is the issue about standardization? Is it about people out there misrepresenting non-Standards Track RFCs as standards? Regards, S. Moonesamy 1. The questions are to the group. From nobody Mon Jul 2 11:23:34 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E3F130DD6 for ; Mon, 2 Jul 2018 11:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 Zj6g2I7JXtKM for ; Mon, 2 Jul 2018 11:23:29 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB2213130B for ; Mon, 2 Jul 2018 11:23:20 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id r16-v6so17660520oie.3 for ; Mon, 02 Jul 2018 11:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U9nxDs4pp+0nQxjUmmUuHbWzrYSWbjk82YUBIbPnDqI=; b=CQXmHYx82uwisr3L573iF75ca92gJgyMqelGjc9s560nN8S0uIEKiVZoRXGZflPwzn gXSWT/9RJ+VaRv6/zCXsV2nWAzth5d/We9CPetKfF6eHGpeRVoWNtGdB516smr10E0ma oZineYdIcsNo2qvpUWRS8a+QUb3ZqCtl8AJuCQSECeCk8DcTkZj2sQfmUa3rtvb2x5c2 thnXL/lCJ/qOeGxUO0hwFi+0vnx52ojFDMCrp5bszZ7RQCcyA2N/aeG14V7a1pmn6eY9 XY+fdntGvhdmyPTu/WiUP6chj2BL1R7UZgLttu11+9jyKdp3F6Qn44nmKG+vUWrNewOr 7a3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U9nxDs4pp+0nQxjUmmUuHbWzrYSWbjk82YUBIbPnDqI=; b=dZjuDezIMa6DjIFXwclWgcTOF8Mv/cRhJchYLDEuUwgZp2KwcMjMRECbG+xztuarDb Q0GfOOR0IdxMgBzcbpiubvszbDwlm1+VgGrrh2JzqZgmGDwWKFugAXMFvD9DF2FBur4B wuVcS2Aua4YtAtyJu5M7irgM1eY6qEcSYQvVcLjyeTgpJBeQoDd3jwpD+RPj6uzeUG0z Wb5UpuyIBb03HKc0S3rlFkBSfB2HlW+o5oY7l6FBRoNnHx2wIChnRyY7pev7bynzIvJk MDFErK9Iqz8Dy0awi0M2Vnre0+Hcyh6e8/2577mZj12XjCMTRHAZsVakURaophR2ieug 09Uw== X-Gm-Message-State: APt69E3+GGLFYxc6UB5+PJrZV1oSKo2yfpx+xEwu9dI+9u+A6cyuX9hr D2t39S62T5uHqUQY1fJ6DKs01O5xeiInez1yXkQ= X-Google-Smtp-Source: AAOMgpecRIhUmekRHoZsVMtmNKkKQlLSRqeqA27VkcBjHo7KfQv5Yp94PvZOmu4vPEjx8RYQ1VpxIBVT1gCYXOY+kbQ= X-Received: by 2002:aca:e450:: with SMTP id b77-v6mr7756312oih.0.1530555799410; Mon, 02 Jul 2018 11:23:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 11:22:48 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20180701153030.0df344d0@elandnews.com> References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> <20180701181929.GB22125@kduck.kaduk.org> <5e4bc5f6-d5f8-3077-1302-26c48bef5e32@gmail.com> <6.2.5.6.2.20180701153030.0df344d0@elandnews.com> From: Ted Hardie Date: Mon, 2 Jul 2018 11:22:48 -0700 Message-ID: To: S Moonesamy Cc: Brian E Carpenter , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000bb9c510570084a1f" Archived-At: Subject: Re: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 18:23:32 -0000 --000000000000bb9c510570084a1f Content-Type: text/plain; charset="UTF-8" On Sun, Jul 1, 2018 at 4:30 PM, S Moonesamy wrote: > > I'll leave it to the BoF to figure out the answer to "who owns the RFC > Series?" I suggest taking into consideration that the community who will > be at the BoF is usually a subset of the wider audience who uses RFCs. > > Speaking personally, I do not believe this is a topic of the BoF. The current system has multiple streams, each with a stream manager. Presumably, those stream managers could make a request to the RSE to mint a new identifier (either as an addition or a replacement for RFC numbers) for their stream. Having a public discussion of whether that is a good idea, and whether to run an experiment using that method, is a part of this BoF. "ownership" is not, at least as I see it. Again, my personal view, Ted --000000000000bb9c510570084a1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Jul 1, 2018 at 4:30= PM, S Moonesamy <sm+ietf@elandsys.com> wrote:

I'll leave it to the BoF to figure out the answer to "who owns the= RFC Series?"=C2=A0 =C2=A0I suggest taking into consideration that the= community who will be at the BoF is usually a subset of the wider audience= who uses RFCs.

Speaking personally, I do not believe this is a topic= of the BoF.=C2=A0 The current system has multiple streams, each with a str= eam manager.=C2=A0 Presumably, those stream managers could make a request t= o the RSE to mint a new identifier (either as an addition or a replacement = for RFC numbers) for their stream.

Having a pu= blic discussion of whether that is a good idea, and whether to run an exper= iment using that method, is a part of this BoF.=C2=A0 "ownership"= is not, at least as I see it.

Again, my personal = view,

Ted

--000000000000bb9c510570084a1f-- From nobody Mon Jul 2 11:37:37 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B42F130EC1 for ; Mon, 2 Jul 2018 11:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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=cooperw.in header.b=taEK8snW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FF9DyTI3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRJBiNjotaQp for ; Mon, 2 Jul 2018 11:37:32 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D629130DFB for ; Mon, 2 Jul 2018 11:37:32 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C550221AC8; Mon, 2 Jul 2018 14:37:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 02 Jul 2018 14:37:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=y4KipUz0ut5hEDGgYvCYeDAeEHRrZ N2V/qi2UA5N3NM=; b=taEK8snWCArl3f8iIBGehYzNQz4DIvj1fhj3ymCGNuijL MEWAnnJSkdbV0/Yph6PwNf7uvvO7+JBLePKShhYLnr1QN/uFOMZVHiaK3r3DIr2J hLiZnuJwMLrKQZBNINzsjHFhvcgHLgHknkivOfFy8WY+61JPiWkHBu/75gHkPA+O 344hjlYhYdsiAQQP0aY6OFax3Jzke6nPqNn9u53ZMYziHW8UgFFMqAiWKm3uBK7l IUFul3GZ2oMt26mLEmI0vkZfm6RpkcHRStZIg7B1MomAQdlWZpR4yP0MLgLvylVF 6S/JF1K4aiGA06In3o57n4EwAYUtOmJ2PIwTc5WEQ== 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=y4KipU z0ut5hEDGgYvCYeDAeEHRrZN2V/qi2UA5N3NM=; b=FF9DyTI3evBkr8IkQo1JA5 KK6v+2p62V0NrQTSEFgjSrkIuT9WQLdnsuTqk8PTN0f66mRv5B11rloWtAZvg002 7uerDHImBONPcWocLvoyRN3hmQ5vf8i5dG7cbs4YwWkUTCR0ySeK4F22u5VgknOi /oWpL0iLxEBsIrd/Ez0nx7M7JGa/RayUF6tXRrLOMs7eUrPRs7ZZ/7uMfLVZ2K7A nsJCQnX087LZYfBThIdHK+8ThDBtHD4rmoZ48sXVl/0S94t+LAEG06FFEaeTkAgO dnGuyR8nDpeBfQGRZdYfUVX7Ws48vjI0zTVkppuytiT0m22OrzmF7dSugkVv66Hw == X-ME-Proxy: X-ME-Sender: Received: from alcoop-m-mx19.fios-router.home (pool-108-18-47-61.washdc.fios.verizon.net [108.18.47.61]) by mail.messagingengine.com (Postfix) with ESMTPA id BB7FBE4534; Mon, 2 Jul 2018 14:37:30 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Alissa Cooper In-Reply-To: <14134BFED03190159F304C91@PSB> Date: Mon, 2 Jul 2018 14:37:28 -0400 Cc: S Moonesamy , rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> <14134BFED03190159F304C91@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 18:37:35 -0000 > On Jul 1, 2018, at 3:03 PM, John C Klensin wrote: >=20 >=20 >=20 > --On Sunday, July 1, 2018 10:57 -0700 S Moonesamy > wrote: >=20 >> Hello, >>=20 >> I searched for information about the RFC++ BoF and came across >> the "About" information for this mailing list. Who are the >> BoF proponents? >=20 > The BOF proposal page > = (https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#TimeframeIETF102Montr= %C3%A9al) > shows Martin Thomson and Melinda Shore, I presume on behalf of > the IAB, I wouldn=E2=80=99t presume that the BOF proponents are acting on = anyone=E2=80=99s behalf, just the same as any other BOF. Alissa= From nobody Mon Jul 2 12:30:41 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D6C130DE1 for ; Mon, 2 Jul 2018 12:30: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qL9eFxg-DPUO for ; Mon, 2 Jul 2018 12:30:36 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDC613113B for ; Mon, 2 Jul 2018 12:30:36 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fa4Wu-0009VN-Ma; Mon, 02 Jul 2018 15:30:32 -0400 Date: Mon, 02 Jul 2018 15:30:27 -0400 From: John C Klensin To: Alissa Cooper cc: S Moonesamy , rfcplusplus@ietf.org Message-ID: <11243C49063C7F3B0B80875B@PSB> In-Reply-To: References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> <14134BFED03190159F304C91@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 19:30:39 -0000 --On Monday, July 2, 2018 14:37 -0400 Alissa Cooper wrote: >> The BOF proposal page >> (https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Timefram >> eIETF102Montr%C3%A9al) shows Martin Thomson and Melinda >> Shore, I presume on behalf of the IAB, > > I wouldn't presume that the BOF proponents are acting on > anyone's behalf, just the same as any other BOF. My apologies. I have seen or heard rumors of enough other discussions to have assumed that the IAB (and maybe the IESG) had discussed this plan (and possibly some related ones) to have assumed some general support for examining changes of this type (even if not this particular change) and without any idea of what "this type" might be beyond involving the RFC Series and its audience(s). If that was the case, I didn't want to, or to encourage others to, blame individuals for a broader decision. Conversely and borrowing from Brian's comment about priorities, if this is just a bright idea that two individuals came up with and have not reviewed with others beyond putting together and submitting the BOF proposal, I have trouble understanding why we are spending BOF time on it (although I will defend the IESG's authority to make that decision). In any event, if my presumption was either incorrect or upsetting to anyone, my apologies. john From nobody Mon Jul 2 12:38:45 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D47513113B for ; Mon, 2 Jul 2018 12:38:43 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 x314mAj01cXy for ; Mon, 2 Jul 2018 12:38:42 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F28130DFD for ; Mon, 2 Jul 2018 12:38:41 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id bi1-v6so8397974plb.12 for ; Mon, 02 Jul 2018 12:38:41 -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=p6sXVKvpzzR4mmHTvd7STkSm6oi6pW3Hb/JiiM69qd4=; b=ViOSP5UT18o/p56k6YPGC6yteM0LGD+XrhHx85O+EXsi4A86LkFzSTJ0ZpwuhrTfzB wjl5BXaW40WmPnLs9N+OrWU6IVeSN5lD8Jq3NNLZZGtq6CXr4F7zq3FMTrUeoduhZrBs dQ8I7LW6eUBdPdvkHxhoyOMyv883n35HZl4PkNO55c0vu4Fmw1RioBaMtCtXKxs1CIDt 0tINDbrZXkSxJL4VsRnUm/+vRSW3xNNE2E/a9P4k49m1UQSLa3ci9BNZeQeZy7fFvgWv /U7wpNF/GoXHBGtjHqlM82jEq3425S6Ck/2yKvCzx4/y4so+GzucM8fzGi+y3E2boQD7 yEow== 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=p6sXVKvpzzR4mmHTvd7STkSm6oi6pW3Hb/JiiM69qd4=; b=FR+D7dsbhlDCfXh2XkAkfL8zcO6yxjA0N2TXhjeojJ8uExPLfmiH3jpXl9Q4dJQ+z7 FRuFFoODXYDTfArChtmBA8yezVjiDy0BWxhQaPjxzoP2Qulbwb4JWLz4q9KkYjp+toS5 n+YfFVbOweG+Ol6x5rZdOE0yI0n77HPgOpMIsfGNER3Pd6oYOFaFdZbWUTlZnZfRp2OM oAcDg+zdDTK8aO+6zXxv71N7Yza13jLdbEOu47GtO5dNYT9ImZxVrEHsskZbebBvoJZq mxU+CDOuEY9zRNDS0PpCTmeqyr2wTiBqHCBGrLniVPi4LKzjogMj5dokhM8U+SjN9Trf movg== X-Gm-Message-State: APt69E1W3ba2zoQJdOH+MV+2tdoWLETvFts8ATYszltfJNc0dfw/ZnQS yrVsT1rNfE056OYDczP6cvB9Iw== X-Google-Smtp-Source: ADUXVKJd+4WYwh8rMxDGKTte5MHS1if0ivFSgyQPKt+JGVaafJO10yiVFMLcjYQZcxrCnn6w/ltoAA== X-Received: by 2002:a17:902:15a8:: with SMTP id m37-v6mr27250878pla.219.1530560321029; Mon, 02 Jul 2018 12:38:41 -0700 (PDT) Received: from aspen.local (63-140-89-164-radius.dynamic.acsalaska.net. [63.140.89.164]) by smtp.gmail.com with ESMTPSA id v30-v6sm2814030pgn.80.2018.07.02.12.38.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jul 2018 12:38:40 -0700 (PDT) To: rfcplusplus@ietf.org References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> <14134BFED03190159F304C91@PSB> <11243C49063C7F3B0B80875B@PSB> From: Melinda Shore Message-ID: <74f27b84-9ee2-84e0-4343-cf2b8ce3718a@gmail.com> Date: Mon, 2 Jul 2018 11:38:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <11243C49063C7F3B0B80875B@PSB> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 19:38:44 -0000 On 7/2/18 11:30 AM, John C Klensin wrote: > Conversely and borrowing from Brian's comment about priorities, > if this is just a bright idea that two individuals came up with > and have not reviewed with others beyond putting together and > submitting the BOF proposal, I have trouble understanding why we > are spending BOF time on it [ ... ] To be clear, I'm not a fan of the proposed experiment and it wasn't my proposal. I do think, however this is the right time to have this discussion, assuming that it's not driven off the rails, turns into a bikeshedding exercise, or otherwise loses its focus. Lack of clarity about RFC streams isn't limited to people who write RFPs - we see it among IETF participants as well, and if there's a way to improve signaling about distinctions between document types, we should talk about it. Melinda From nobody Mon Jul 2 13:21:18 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5051A131317 for ; Mon, 2 Jul 2018 13:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 50IrjB1vEQNz for ; Mon, 2 Jul 2018 13:21:02 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2DCE13129E for ; Mon, 2 Jul 2018 13:20:46 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id i12-v6so14386221oik.2 for ; Mon, 02 Jul 2018 13:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lkKMb/oUx6XWg9BAudk2qfDTVTUfXoOcK8b76cNOrg4=; b=ABa6xGnRmDk/sw1Pk4mxIdEIp0ciCvsqjuzTTakEjSieMrHaWy4hcnnwH0ky0jKUQ7 h+lsqH1GLzd7tBUXJ8aJ5U5fIiUGjLtTeiWs5dCM9l74nPvZAEBWpwPwQs329jEPyhn+ +eLiVl1mQj5RdYT+aoLo7GkdBL1MGH/FI90k9qhnfZ2ic0rhgpHXeUHUOWJgQrmvG8KY CzCSHkBuNEo+RneQXW5Ba2DmX/h17Mwq9uH2ky1cmijejBn7pieImLpWMWLXRV20wKuq pjSo3sDXKHouEm1irdb782KmF+XQ1whNRcHTWt94Kvi4xch8Gm91sHPrwxL7UzzLOp0+ Nuhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lkKMb/oUx6XWg9BAudk2qfDTVTUfXoOcK8b76cNOrg4=; b=l8PcliWDa1gtXtvWPRWmon7Vuh2WrmDwqz+eBbIqj7qceKc9+ZawLEztZBFsdcNUsY k+pan9Ys2Auj+x/pJbJdopH09WRYC8fF2qAxjhN8nLt8AE8L0W15vu9XaK9MILYVnesh TDVfzRgGTlL690zZx2AvJxyKLtRCNHsbkgUhTTElpavmvLqgk0iAanqqAdb2rhRe3Rpl V6TQdLe2l3cqh0k8c/WGX4BaznkW8Pzjmcz/DJjsYo5mne6EEhCuEe/aF+xxsGZvrXww RnDqXdQvcmlHXjib/MsE6BEwpAgkocvlsDo5lPlDJ7KECGFsbWIUWzO1r06HmNMmcPMx xRbQ== X-Gm-Message-State: APt69E1ZUXU8OX9QmIryOQpQSyUTduDSFdEbJF3WXUQsy7RH/f7xsVfj pxoZKdHAAqUzTm5yV76o8oK35F3UwA8L2//7cpc= X-Google-Smtp-Source: AAOMgpfsEa5gQp87rY6tPbtJWuP+uqXG3aWj7CeLRo61JIZmKbsxZD/gpyuZhyFYUH4P+A4l/x/pceJ75WP2v38XdjQ= X-Received: by 2002:aca:5f06:: with SMTP id t6-v6mr18358852oib.103.1530562846119; Mon, 02 Jul 2018 13:20:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 13:20:15 -0700 (PDT) In-Reply-To: <11243C49063C7F3B0B80875B@PSB> References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> <14134BFED03190159F304C91@PSB> <11243C49063C7F3B0B80875B@PSB> From: Ted Hardie Date: Mon, 2 Jul 2018 13:20:15 -0700 Message-ID: To: John C Klensin Cc: Alissa Cooper , S Moonesamy , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000bfdf98057009ee28" Archived-At: Subject: Re: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 20:21:15 -0000 --000000000000bfdf98057009ee28 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 2, 2018 at 12:30 PM, John C Klensin wrote: > > > --On Monday, July 2, 2018 14:37 -0400 Alissa Cooper > wrote: > > >> The BOF proposal page > >> (https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Timefram > >> eIETF102Montr%C3%A9al) shows Martin Thomson and Melinda > >> Shore, I presume on behalf of the IAB, > > > > I wouldn't presume that the BOF proponents are acting on > > anyone's behalf, just the same as any other BOF. > > My apologies. I have seen or heard rumors of enough other > discussions to have assumed that the IAB (and maybe the IESG) > had discussed this plan (and possibly some related ones) to have > assumed some general support for examining changes of this type > (even if not this particular change) and without any idea of > what "this type" might be beyond involving the RFC Series and > its audience(s). > The IAB has discussed related issues many times. As an example, the IAB and the IRTF Chair have discussed whether the current stream-based system is understood sufficiently well by the academic community that the work in the IRTF is getting credit for its participants in proportion to the quality of the work. Speaking as IAB Chair, I believe that the IAB has consensus that a public discussion of these issues is the right step to take at this time. That does not mean that the framing of this in terms of this experiment has (or needs) IAB consensus. As a BoF in the general area, it needs proponents, and I am grateful to Martin and Melinda for taking that on. Speaking personally, I'm glad to have a concrete suggestion in front of the community. The question of what data is needed seems to be getting a different sort of attention with that in front of the community than a more nebulous discussion might have, and I hope that the BoF is productive as a result. regards, Ted --000000000000bfdf98057009ee28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 2, 2018 at 12:30 PM, John C Klensin <john-ie= tf@jck.com> wrote:


--On Monday, July 2, 2018 14:37 -0400 Alissa Cooper
<alissa@cooperw.in= > wrote:

>> The BOF proposal page
>> (https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Timefram
>> eIETF102Montr%C3%A9al) shows Martin Thomson and Melinda
>> Shore, I presume on behalf of the IAB,
>
> I wouldn't presume that the BOF proponents are acting on
> anyone's behalf, just the same as any other BOF.

My apologies.=C2=A0 =C2=A0I have seen or heard rumors of enough othe= r
discussions to have assumed that the IAB (and maybe the IESG)
had discussed this plan (and possibly some related ones) to have
assumed some general support for examining changes of this type
(even if not this particular change) and without any idea of
what "this type" might be beyond involving the RFC Series and
its audience(s).

The IAB has discussed= related issues many times.=C2=A0 As an example, the IAB and the IRTF Chair= have discussed whether the current stream-based system is understood suffi= ciently well by the academic community that the work in the IRTF is getting= credit for its participants in proportion to the quality of the work.

Speaking as IAB Chair, I believe that the IAB has cons= ensus that a public discussion of these issues is the right step to take at= this time.=C2=A0 That does not mean that the framing of this in terms of t= his experiment has (or needs) IAB consensus.=C2=A0 As a BoF in the general = area, it needs proponents, and I am grateful to Martin and Melinda for taki= ng that on.=C2=A0

Speaking personally, I'= m glad to have a concrete suggestion in front of the community.=C2=A0 The q= uestion of what data is needed seems to be getting a different sort of atte= ntion with that in front of the community than a more nebulous discussion m= ight have, and I hope that the BoF is productive as a result.=C2=A0

regards,

Ted
=C2= =A0


=C2=A0

--000000000000bfdf98057009ee28-- From nobody Mon Jul 2 17:09:11 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55F3130EDD for ; Mon, 2 Jul 2018 17:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 e3GvFxzsAPcj for ; Mon, 2 Jul 2018 17:09:07 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13AA130E1D for ; Mon, 2 Jul 2018 17:09:06 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id c10-v6so81871pgu.9 for ; Mon, 02 Jul 2018 17:09:06 -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=cRVWNM3yEEAGs/c4SO/RJIAoDSSVSSjfY2/8zZ/Lbg0=; b=GDCRD6FB16uWEAgpiwG3fmqIvvqeTljoiaxaNNdHopHxKCJVVvAiy2rQmQ47uNTqWD 88u8OOXDmUMBDsjJJ8Zba8wzZj9xe3TvYdKkmujRHNiriDirtNVK7EUj0sP4u8v0q9PG KZmhAoi4PE3Z0/MOvHWvSK+TKevgeMf8NctDgFPTRTzP970w/MBJQkQ/y340m1Dy4OYB Yj3IwTjDpPe24Yl1LZff7x5orT7LHLU85gKsQjdP08kHdZQPzOHreT/bS9zuih1JQac/ CDoYcPLbchwTiF0MMuTY8y1cViKrFcMb+bxpmFj41Keqk54KiEs2l3+QZYwl1omkttPD DjwA== 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=cRVWNM3yEEAGs/c4SO/RJIAoDSSVSSjfY2/8zZ/Lbg0=; b=eBjpwnUs0wFyiEB1kJGV0azgJk9TNtUvJtvuLkou93q0oto4VKXrx0P2f4VIOe/zLw eeG9MGYs2DyfY9boxPBZIrshU00QF6I2+degxn0iCvtGMd1yNYNY3Jhilkh1fUVAk3vf O4Fmlxq4wLpBdaxcqQzoxNMbnqZRlHyjHFBiOHsiU7ND7CH3J7I8VELNmdRLu/Pb4WXr ayZPQHHoFJ0vEZBBkd9wqt6rrL9zQb4K1MCB5n4lAR7d91JyQ4hP9ATytW4hpR2BuGQd ivLWihnoK7HZeDuBT2gjTAUrXL3TOFF/5ExqJvX5n5zdM/Cc4hYV3F7wWfai8gbo2diP XKfg== X-Gm-Message-State: APt69E2goSNYAwgC+IKm8hlJEzFbvC7IkbrBEPqJqXQbiOQLLTYpqHvJ ORIKH0l3xvV7+EPogc+UVa92dA== X-Google-Smtp-Source: AAOMgpexyslKJ1/F72awBNKAVJBGtrfEdcWMLs8M9+KcHwc578W3R1cNUWzQFqcfx/YEZoZ/OZkHpg== X-Received: by 2002:a63:4a07:: with SMTP id x7-v6mr4484886pga.34.1530576546173; Mon, 02 Jul 2018 17:09:06 -0700 (PDT) Received: from [130.216.38.164] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.164]) by smtp.gmail.com with ESMTPSA id b66-v6sm18031085pfe.49.2018.07.02.17.09.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jul 2018 17:09:05 -0700 (PDT) To: Ted Hardie , S Moonesamy Cc: rfcplusplus@ietf.org References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> <20180701181929.GB22125@kduck.kaduk.org> <5e4bc5f6-d5f8-3077-1302-26c48bef5e32@gmail.com> <6.2.5.6.2.20180701153030.0df344d0@elandnews.com> From: Brian E Carpenter Message-ID: <680dc005-796c-c6d8-a312-4026275cc185@gmail.com> Date: Tue, 3 Jul 2018 12:09:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] Another RFC experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 00:09:09 -0000 Ted, On 03/07/2018 06:22, Ted Hardie wrote: > On Sun, Jul 1, 2018 at 4:30 PM, S Moonesamy wrote: > >> >> I'll leave it to the BoF to figure out the answer to "who owns the RFC >> Series?" I suggest taking into consideration that the community who will >> be at the BoF is usually a subset of the wider audience who uses RFCs. >> > Speaking personally, I do not believe this is a topic of the BoF. The > current system has multiple streams, each with a stream manager. > Presumably, those stream managers could make a request to the RSE to mint a > new identifier (either as an addition or a replacement for RFC numbers) for > their stream. It seems to me that 'addition' and 'replacement' are fundamentally different. 'Addition' is clarification and I doubt if anyone would be against it. 'Replacement' raises all kinds of questions about what the RFC series is for and who can decide about it. > Having a public discussion of whether that is a good idea, and whether to > run an experiment using that method, is a part of this BoF. "ownership" is > not, at least as I see it. That depends on the nature of the changes proposed. > Again, my personal view, Understood, and ditto, of course. Brian From nobody Mon Jul 2 23:45:57 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B280130DF9; Mon, 2 Jul 2018 23:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 XCgCUlu1jzpc; Mon, 2 Jul 2018 23:45:51 -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 03FAA126DBF; Mon, 2 Jul 2018 23:45:47 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id w636jijP029484; Tue, 3 Jul 2018 07:45:44 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 91B072203D; Tue, 3 Jul 2018 07:45:43 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 7CDEE2203A; Tue, 3 Jul 2018 07:45:43 +0100 (BST) Received: from 950129200 ([141.85.216.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w636jgbo027910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2018 07:45:43 +0100 Reply-To: From: "Adrian Farrel" To: Cc: Date: Tue, 3 Jul 2018 07:45:39 +0100 Message-ID: <02bd01d41299$75677e00$60367a00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdQSl2S1YtLz521GSR24VYEK4Zo0cg== Content-Language: en-gb X-Originating-IP: 141.85.216.4 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23944.005 X-TM-AS-Result: No--19.998-10.0-31-10 X-imss-scan-details: No--19.998-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23944.005 X-TMASE-Result: 10--19.998100-10.000000 X-TMASE-MatchedRID: LC0ZKcJf5DhCl9DEsHnSbTNKWYiz0CE6PshkPXnCJ+3kMnUVL5d0E/c9 xP3r3nD5FnhDNImcSZPrvl6n6RRl/kWqePY/0ttHKWuiyZLRI4AZYA38gj3BxPQSLfvlzdlJY7h CWgdYh4Kp1kXZjeMY/X0GFT5KU5MDb4ixR8bvk/aiI3xhOar5y279evoIpeI3ehnlgrviZRDC5q eIz1BfLbnpxPHixvVUd5/tL2t7Ho/51WNA1rE6t7iMC5wdwKqdUXlp1FHYSPXZ0/3KlJ7599D1S FVeE0DsJ0EKysukzfbG51dUjKce0BHYera7K0OLgYt6Kq7XJMobTlrvbfDnJ58azCU/fTuQSvbg LcfUMI901tRTcMEYtg5gsVv7cmyxDyszNV8ahX2puD25aEtgtwVyeo9hM9SHg0MI3jJm6ECGOZx UAZ8FopjVnkPgy3RQkZOl7WKIImq0P2qkGU0XysC4UUZr4lSF+gD2vYtOFhgqtq5d3cxkNQwWxr 7XDKH8mPcoLQAsz8Vh9pfPpHCAEeNJUkZVOLzMJRzgnsnlDIBQGbCu5XP8gA== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Rfcplusplus] draft-thomson-rfcplusplus-label-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 06:45:56 -0000 Martin, Thanks for writing this up: it is really important to help us understand the motivation, scope, and impact of the proposals. I am interested in your views about how the experiment might be unpicked if it is judged to have failed (section 4.3). Let's assume for the sake of discussion that all documents produced under the experiment are formatted exactly as RFCs, and differ only in the names applied. Thus RFC 9001, FOO 9002, and BAR 9003. That makes posting them later as RFC 9001, RFC 9002, and RFC 9003 easy. But what about references to FOO 9002 and BAR 9003? How would you propose that these are handled after the failure of the experiment when the references are made from stable published document? Cheers, Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 03 July 2018 00:12 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-thomson-rfcplusplus-label-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The Label "RFC" > Author : Martin Thomson > Filename : draft-thomson-rfcplusplus-label-00.txt > Pages : 9 > Date : 2018-07-02 > > Abstract > The perception and reality of the RFC series have long been separate. > More than 20 years of attempts to correct perception, starting with > RFC 1796, have been unsuccessful. This document proposes an > experiment to see if changing the labels on document will have any > effect on fixing that problem. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-thomson-rfcplusplus-label/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-thomson-rfcplusplus-label-00 > https://datatracker.ietf.org/doc/html/draft-thomson-rfcplusplus-label-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jul 2 23:51:18 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EF8126DBF; Mon, 2 Jul 2018 23:51:13 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 EVjkNIr3Oxkh; Mon, 2 Jul 2018 23:50:58 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0BF130E73; Mon, 2 Jul 2018 23:50:58 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id i12-v6so1696104oik.2; Mon, 02 Jul 2018 23:50:58 -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=1rPs5GcKNiA2ZnNzyfilvC7vqCnUjSY9+vQ+xpnIqWc=; b=qFdgEMIV5JkQANVI4/+ypLwaIr3GxXAe/VmHxB1Gx1/eAMlZpJ8EN9UCyxnVWcm5i/ HieHMxoLSgJNwBbH1sDyksBz0bT23S5fLoQwGYpxP4053TwifXtCIk4femYwTMP8vs89 901/U+Y4ulspx43Oua2rzz0bAJT0BAHQHpP786eLu8S4lqOGdXjXEVzI+l4MMaWLAJuf Xf9XJtJVILq8tXNLFrZayKE+RZoNrzHR48JKplPQpXRRimagJhIqKz7br/9X0qE1j3jx 2Zmjqi+Lk1TCp5eRCS76c5F15yiOuKfxHT8KPaVKQqw/L/qMlSYdHp81ibdbBs9jv/FP 7PgA== 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=1rPs5GcKNiA2ZnNzyfilvC7vqCnUjSY9+vQ+xpnIqWc=; b=QocQP8rMvmBDF6Ty3kQ2r359685d2Lgq/TpKUMs3NU5vz4+igK4v5fxzjQpGUCGJCB +w2LSXXy7l8YKAS7DZs/WTFoDdcVI+7j6r+lf02vJ9tozBiSFYdffpk/srvV6nX0OUei pTe3szpk8GbENWUJKFj2xwuj1uJ+EnfwTskZe7zs5VOLegyPX/W/AAIIzpZRUw/mImcs YwBQ01l9oz3OPKUhqaRt/hoMn/a8BRO1KYrBgfnjZbS2hyWKChGW/AjdXoL66yrUtyhp XCXCygWdJ/N+9m3qn7HeKaO4ZW0ijbXOqok/TEUODxwgQsCvG0VDMRMh96/kvBd44Xrx CZlA== X-Gm-Message-State: APt69E3GddyLK8syN5z6WpGon4uJw1Xf3Mn3F829y7PMHwqcm1QxTb5f DYooeXCeU75tyffRZhp7GZHNoKtS7Z1t3GCRc2PjyQ== X-Google-Smtp-Source: AAOMgpd2HUqQyz+2lAkvY0TfWe/ORMtVpbIGJZDoBSKX4UOV3j0HB2X1sr+CKoIphcr+5Jtxzbon8sRJjljOeNl3KoU= X-Received: by 2002:aca:3d43:: with SMTP id k64-v6mr18271214oia.166.1530600657170; Mon, 02 Jul 2018 23:50:57 -0700 (PDT) MIME-Version: 1.0 References: <02bd01d41299$75677e00$60367a00$@olddog.co.uk> In-Reply-To: <02bd01d41299$75677e00$60367a00$@olddog.co.uk> From: Martin Thomson Date: Tue, 3 Jul 2018 16:50:46 +1000 Message-ID: To: adrian@olddog.co.uk Cc: rfcplusplus@ietf.org, draft-thomson-rfcplusplus-label@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 06:51:15 -0000 On Tue, Jul 3, 2018 at 4:45 PM Adrian Farrel wrote: > Let's assume for the sake of discussion that all documents produced under the > experiment are formatted exactly as RFCs, and differ only in the names applied. > Thus RFC 9001, FOO 9002, and BAR 9003. > That makes posting them later as RFC 9001, RFC 9002, and RFC 9003 easy. Yeah, that's the easy part :) > But what about references to FOO 9002 and BAR 9003? How would you propose that > these are handled after the failure of the experiment when the references are > made from stable published document? The numbers and labels will need to remain valid. One of the bigger issues in this giant ball of string - one that I hope we don't get into - is immutability, and we can't stop the immutable RFC 9001 from referencing BAR 9003. As a practical matter that probably means keeping URLs live and any indices working, but not a whole lot more. BAR 9003 might just point to RFC 9003 though. I should add a note about that. From nobody Tue Jul 3 00:32:56 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D422F126DBF for ; Tue, 3 Jul 2018 00:32:53 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 swwKwWl3uWIs for ; Tue, 3 Jul 2018 00:32:51 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 85B3E130E23 for ; Tue, 3 Jul 2018 00:32:51 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id 13-v6so1893790ois.1 for ; Tue, 03 Jul 2018 00:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XpRyjV36h0JHr6zJF3LiN2F6u6yPyjUKlDDXyLOYVmE=; b=umOgHaLxFQxH6ftGbCXCqLXVE8R2HhWHyt3Q3WlRDWX075ge+87zvsRW/qbUzYydTi usKK1qPEro3it5MKBIU9yf7128ZDEZ5Y1oi6ugRhZCBQ98cKX60DGzecZ53c5lc0fiLC 6wXTlTLEdClEA3f9AjcKyYn8knEBLuC2VAl9Wuuy0IJ+xBr1dHj/A60yrNrrkdOCofXD SU1zV9nmc9KeCFyx/SShNk1SGGo4v4QMHVpjo69Q24b/Iu6BAOWTdgin5CpLzKZ0eyCZ Dxdmo5kxLjSO3H3sXTf/rZUIWeoUZdiQYsLjHfl6FSBdlW0H77ryY9rSVbvaK5Swtx3L SLDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XpRyjV36h0JHr6zJF3LiN2F6u6yPyjUKlDDXyLOYVmE=; b=gT6XhgJEMnWWBysgONbzYoyM4I6NpgQV2f+LmGBzNCdzhxJmXm4+eZHT/nO/0JaviA 8HuI+HIjdoJNfYrTGZaqWk9jndKcid52sGJzHywyjv2/yQMwfrCWwyHl2ztYg/+0oG9o wGvd3SPHWHiarUmTzdC8LlrH6pPNanX6pcVOX9Wr0z/mv7ax25X1BxJhhY9oxMwMeT/t fPUnaM/3SuSNV92Cnbn9cA0JhcrjMQ9Ih3K8rrF+RM4QR+e7W/O2ZAhZXBIfLcn6dvg3 nVnxr40kJ2UsTLJOc4vdGu1bdl5iRAuVMbONtzVdgm6P/iUXj5f0CdjqrE+28MhUULt6 KF8g== X-Gm-Message-State: APt69E1gXPWoNokYEN6T448+r9DAnmkL2HQo7fn5uaPA2qZFJVeJq9FY 0xl13Jmf4QzquuLkchLbLy54slCvLuNK1sbJlH4OGWtf X-Google-Smtp-Source: AAOMgpcZFzKa00lhgjH0M4zEVhS3oacxpTn3WfX3S5g7x9zNSholObEZllR7h1ZheT6UO9ou+hvIDk8U8su12MwzSas= X-Received: by 2002:aca:120e:: with SMTP id 14-v6mr18535909ois.144.1530603170595; Tue, 03 Jul 2018 00:32:50 -0700 (PDT) MIME-Version: 1.0 From: Martin Thomson Date: Tue, 3 Jul 2018 17:32:39 +1000 Message-ID: To: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Rfcplusplus] Outlining the experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 07:32:54 -0000 It's been good to see the level of engagement on this list. I've been reading with some interest. I've submitted a draft that attempts to summarize the proposed experiment: https://datatracker.ietf.org/doc/draft-thomson-rfcplusplus-label/ [0] I had hoped to get this out sooner, but the urgency of other tasks meant that I barely met the draft submission deadline, and it's very rough still. Hopefully that draft clarifies some of the questions people had about the scope of the proposed experiment. Obviously, this is just my view, and I don't think that everything in there is correct (Adrian already found one hole). As Ted said, the IAB are generally of the view that this is a topic worth discussing, but as a group we don't agree on a particular solution. This is, more than anything else, a convenient strawman. However, based on the feedback thus far, it seems like it might be good to examine some of the more fundamental issues: 1. What is the problem? I think that the problem is well understood. The common perception of "RFC" encompasses a far simpler notion than the reality. The debate seems to be centred more on the question of whether this - of the multitude of problems that we might tackle - is the one that is worth addressing. Several people have suggested that the broader issues might be tackled more comprehensively. I'm personally not opposed to that, though the thought was to keep the focus narrow. Brian cites the ISD proposal [1], which is much more ambitious, but it's been a few years since anything like this has been attempted, maybe there is enough pent-up demand for change that we could find a more comprehensive set of changes. 2. Why this problem? It's a relatively small problem, with a (proposed) small solution. There are some potential advantages that might be later realized from a looser coupling between different sources. There are certain uniform expectations about publication as RFC that mean that certain streams tend to affect the outcome of others, sometimes in ways that are less than ideal. For instance, we see that all RFCs tend to have a security considerations section, even if the notion is a little ridiculous (BCP 78 says as much). Security considerations make sense for standards, but less so for other types of document. Besides, I think that they exist solely for the comfort of SEC ADs now, we've a pretty strongly enculturated understanding of the importance of security in our designs [2]. Similarly, one of the ideas floated early in this process was that this might allow the RFC 5742 conflict review process to be removed. That was intended to allow documents to proceed with fewer explicit controls. Feedback from the ISE and ISEB indicated that they found this process extremely valuable and the IESG don't see it as a burden, so that's unlikely to be something that comes out of this, but I mention it to illustrate the potential. 3. Why now? Why not? I don't really have a good answer for this, other than the fact that there seemed to be sufficient interest in doing something and that this was a reasonable candidate. 4. This is so unscientific! Yeah. That's the nature of the problem. Alissa articulated this neatly in her email, it's a human problem. We should definitely explore deeper, because this is small, but it isn't simple. My personal view though is that if this gets to the point where we're employing market research companies, something has gone seriously wrong. Going that deep, or dragging in a laundry list of other unsolved problems, might be a good way to ensure continuation of the status quo. 5. Why not erect a bigger sign? The current boilerplate in RFCs could be improved, but - as the draft says - that doesn't really get to the crux of the issue. Even if there was a huge banner on every RFC that wasn't standards track that said "DON'T IMPLEMENT OR DEPLOY THIS PROTOCOL. IMPLEMENTING THIS PROTOCOL WILL HURT THE INTERNET", it won't stop someone from receiving conflicting advice. At the risk of being the first to invoke what will eventually be verboten under the terms of Godwin's Law, RFC 7974 is the best example I have of this. It bears a warning nearly that strong and yet I have received or witnessed strong endorsements of its virtues on several occasions. [0] You can find a more readable and updated version here: https://martinthomson.github.io/is-the-future/draft-thomson-rfcplusplus-label.html [1] https://tools.ietf.org/html/draft-ietf-newtrk-sample-isd-00 [2] This is as it should be, alongside all the other things we might consider as constraints on designs: privacy, deployment, operations, usability, internationalization, human rights, economic effects, intellectual property, etc... From nobody Tue Jul 3 01:14:34 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2C6130E17 for ; Tue, 3 Jul 2018 01:14:32 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 L463aK5fkKdY for ; Tue, 3 Jul 2018 01:14:29 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0051612426A for ; Tue, 3 Jul 2018 01:14:28 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id a7-v6so656569plp.3 for ; Tue, 03 Jul 2018 01:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:organization:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=8QLjGR3m5jURLdCpCJIFZ9S1B1ycq5cqgkVfMdJOyOY=; b=ecl9BE+Ai5x+lCeyTQpj8YCSTjoQrwGDDB+3AFaP96rAl5Lz4JtUSyXC++NegrdxqD MTxygrggroJ6pOAmItynuWKNNWnusgisN8TbcfNgnO/AWKjnQr6kNrVEdunELIs848gN HAkHdgK9ng58NYsCEJAVrgzm1dLegi5HN9u6fEfnypGM/w7mxjK32AFrUSMQBszL7k0Y gTeRGSQ9+bbQISgE9noOGE9IfvlUeMWvKae+5Q8fdtxVihrdNNwepFQegJtFL+JAcG5L qc8nNEH/lIYXp5vrtsUPYoMjrSm8ypw9lTyZVz4ZtstPzGQ0ur4N06E7OICUVd4LQ3fR nP/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:organization:to:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=8QLjGR3m5jURLdCpCJIFZ9S1B1ycq5cqgkVfMdJOyOY=; b=ZeDqANw8254+f5fR7X0tSF0ktb6U8hdhK6h/67rlbepNyKxfW/sPgjLOcjiMMqjEqg 3wT0JlkT1LULiPLkxIHo6ieqmU5L7VKFZTrhSTWFMFLFwmErWfokaqZP2uKNnu7gxt6C AAyxlgKZCZLU58pJ3Ix4kvN1DMCVuGhF8O5BuybMl8aYIXJNCmMots0oJaK1GEkzPARY SyQnC3Dx4DsmrpwzU72l9CpP5kLBfPYSVsjo3W22z59MP5yMum01U5tOh6tQ1pUD3Brn +hi3o5woWvoGHYfo42wrY2Xc3U4IDMFn6/82NsYSdDL+td+FK3iL/Vcd+5vQ+Xsame0e xnSQ== X-Gm-Message-State: APt69E0oTliD0hGJqAZNdfrdIQ9LhYXG4g9VHZ66XniIJz/qsXHzGqGL m9d2QR0wmGDdzw2PDBBKdzdfdA== X-Google-Smtp-Source: AAOMgpcezPg1B/pTDjCTLMCPHKv+/uHZvJTfj/vTXxg2Ecvlk2yrLHEtDo+af2U/5SAiLZg+AFXJNw== X-Received: by 2002:a17:902:9693:: with SMTP id n19-v6mr7755plp.212.1530605667780; Tue, 03 Jul 2018 01:14:27 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id h2-v6sm2484750pfb.108.2018.07.03.01.14.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 01:14:26 -0700 (PDT) From: Brian E Carpenter Organization: University of Auckland To: rfcplusplus@ietf.org Message-ID: Date: Tue, 3 Jul 2018 20:14:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 08:14:33 -0000 Hi, My main comment on this draft is that it proposes an experiment without first explaining properly what the problem is and why the proposed experiment might fix it. It isn't sufficient to say there is misunderstanding of the various RFC types and statuses. It isn't sufficient to give a couple of examples of non-IETF-standard RFCs that might be implemented and deployed in parallel with IETF standards. Where is the damage to users, where are the numbers, how do we assess the seriousness of the damage? Isn't it sometimes better to have multiple solutions? Isn't it *always* better to document something which is deployed, whether it's good or bad? Isn't the IETF solution sometimes wrong? How much of the perceived problem is just a matter of damaged pride? How does this problem compare with others that have been known about for just as long? Why is this one worth solving (disruptively) when the others aren't? Right now I just don't see a problem statement that answers those questions. I'm tempted to stop there, but here are some more detailed comments: > RFC 1796 [RFCS] was published in April of 1995. At that time, it was > clear that there was an "regrettably well spread misconception" that > the label "RFC" implied "some level of recognition". True. Also at that time (in fact a few months before, since the RFC Editor had already reacted), the RFC boilerplate was modified to avoid misconception for anyone who bothered to read it. > Not a lot has > changed in the 23 years since that statement. Evidence, please. I'd say that the evidence is that people don't take much notice of the label and the boilerplate; they go straight to the text. (OK, insert the obligatory anecdote of Avian Carriers being cited in an RFP, but one swallow doesn't make a summer.) > The common perception of the significance of the "RFC" label is > simple. That may be so, but since the draft doesn't state what that perception is, the reader cannot guess what is intended. For example, my perception of the significance is that an RFC is a request for comments. Then I look for its status. Then I look for its contents. Isn't that what we should assume serious engineers & product managers do? > This document suggests that this view to some degree underestimates > the value of a label (or "brand"). Or, equally plausibly, it overestimates the value of the label. My belief is that, the occasional dishonest salesman apart, it's the content that people value. If they know anything, they know that *all* RFCs have had genuine peer review. (Unlike many academic papers, see "Some science journals that claim to peer review papers do not do so", The Economist, June 23, 2018.) > This document proposes an > experiment that limits the use of the "RFC" label to the product of > that process. I have to re-iterate that this is not a choice the IETF can make, since the IETF and its committees do not own the RFC series. The IETF can't kick the other streams out. > Capturing the nuance required to properly understand a protocol is > difficult, and a large number of documents fail to properly convey > that status. Correct. However, this is a hard problem that the IETF has essentially refused to solve, because the solution is hard work, both for WGs and for the IESG. draft-klensin-std-numbers and draft-ietf-newtrk-sample-isd were both put in the "too hard" bucket by previous IESGs, for example. > ZRTP [RFC6189] was published as an informational RFC on > the IETF stream after the IETF reached consensus to develop DTLS-SRTP > [RFC5764] for the same use case. The document makes no claim to be a standard and it gives some explanation of how it differs from RFC5764. It isn't clear to me what is unclear to the reader. > HTTP Live Streaming (HLS) [RFC8216] was published on the > Independent Submissions Stream in defiance of a standardized > protocol, MPEG-DASH [DASH] The word "defiance" seems quite inappropriate. Firstly, the RFC doesn't mention MPEG-DASH at all. Secondly, the document makes no claim whatever to be a standard. > Both describe de-facto standards, each of which are implemented in > more than one product and deployed. Right. It has long been considered a good idea to document stuff that is widely deployed, for everybody's benefit. > Each captures a range of design decisions that differ from the > commonly-accepted view. How often in the history of engineering has "the commonly-accepted view" turned out to be wrong? How often in the history of the Internet has something unexpected turned out to be a winner? > If nothing else, the deployment of these protocols > could adversely affect interoperability relative to implementations > of their more widely accepted alternatives. That's true, of course, but the Internet has always worked by survival of the fittest. I'm not seeing a tragedy here. > Information about the status of the document is contained entirely in > the "Status of this Note" section. For instance, ZRTP is published > with IETF consensus, so the significance of it not being an "Internet > Standards Track specification" is easily lost. Easily if you don't read the words, yes. > That it also limits > its mention of DTLS-SRTP to comparative criticisms makes it possible > to interpret the document as it represents itself: a newer, superior > technique. Yes, the authors believe that their way is better. That's hardly a surprise. > There are numerous examples of RFCs that make an honest > representation of their status in more than just the boilerplate. Indeed. And this is an aspect that peer reviewers should look out for. > So why is the publication of an RFC so keenly sought, when the > document doesn't capture the output of the Internet Standards > Process? I don't know. Did you try asking the authors? Speculation doesn't help us much. For my own independent submissions, it's because it's the appropriate way to reach the Internet technical community in general (not just the IETF as you suggest), and another motivation is to get constructive review (as opposed to the essentially random or sometimes bogus review you get from academic journals and conferences). Most of the Internet technical community doesn't read academic journals, by the way: apart from anything else they're too expensive, and most of the articles are too... academic. > This documents proposes reserving the "RFC" label for those documents > that are the product of the Internet Standards Process [RFC2026]. And again, in case anybody missed it: the IETF can't do that because it doesn't own the RFC Series. What the IETF can do is change the requirements for its own stream of RFCs, or stop calling its documents RFCs at all. The second one is a terrible idea, for reasons I gave at https://tools.ietf.org/html/draft-carpenter-request-for-comments-00#section-4 The first one is absolutely reasonable, and a good first step is at https://tools.ietf.org/html/draft-klensin-std-numbers-02 With the right typography in the new RFC format, this could be very effective. > 4.1. New Labels for Other Documents This section is ambiguous. But most of it is out of IETF scope anyway, because the other users of the RFC series will label their RFCs as they wish. I wouldn't be against the header lines being more explicit. > The "STD" label hasn't been especially effective in distinguishing > those documents that attain the rare status of Full Internet > Standard. The BCP subseries has been more effective, perhaps because > of the greater familiarity of its primary audience with its meaning. Exactly why we should apply the STD series label to *all* standards track documents, as proposed many years ago and more than once since then. (Also why I'm a fan of https://tools.ietf.org/html/draft-loughney-newtrk-one-size-fits-all-01 ) > However, the choice of rendering is not > part of the canonical XML document. Alternative renderings could > legitimately erase that information. They could drop special choices of font & font size, true, but they couldn't drop the actual status etc. if it's part of the document text. In any case, most people will use and refer to the primary HTML rendering, which the RFC Editor will generate. > That leads to the conclusion that clearer marking for status, while > possibly helpful, would not be sufficiently effective in addressing > the problem. That may in fact be true, since the fundamental problem is that humans see what they want to see, and readily skip boring stuff like document labels and status. This leads to the conclusion that adjusting the labels won't address the perceived problem: if people have a good reason to ignore today's labels, they will ignore tomorrow's as well. > A term of 3 years is proposed as being long enough to provide enough > evidence to assess the effect of a change of labels. I question whether that's long enough. Some product cycles are faster, but many are slower than that. How many cases per year do we have of RFC-label-confusion causing significant problems to users? Unless that's a large number, and we can use those cases to assess the time lag between RFC publication and the occurrence of problems for users, I really don't know how long a test would be needed. (The proposed metrics about publication rates are pretty useless except perhaps for a sociologist, because they don't seem to be relevant to the alleged problem. And in any case, as noted, the datasets will be tiny and most of what we'll see will be statistical noise.) > 6. Security and Privacy Considerations > > It is believed that there are none. Given how many of the Independent Series RFCs are about crypto algorithms and the like, potentially interfering with that publication channel seems to pose a risk. Regards Brian Carpenter From nobody Tue Jul 3 01:30:13 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB6413119F; Tue, 3 Jul 2018 01:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBhYhPlTwVwQ; Tue, 3 Jul 2018 01:30:09 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376F5130E4D; Tue, 3 Jul 2018 01:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5748; q=dns/txt; s=iport; t=1530606609; x=1531816209; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=p2YhFMp32H/EFmSHpHrJmzss8f4BM1UmsyXHhV/s61c=; b=XYvORD+m94qAJ+YMnTrtMnfiXxZ0HCKAVeOM7FiBoOd1o2ER+TyuCQml 6O/vZ/HWrA56W916oVaxS0fXaCijMRsuMdgUtH6dcx/AaAaHf8IJB8Zr6 eiMn9/xVmWV0DHA4Iz+npHtEvsrZFrZjg0sOK5idf5Wn79piSDur4SPai k=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQAFMztb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUYEoQhiGONaJAahQ2BeggDhGwCg2U2FgECAQECAQECbSi?= =?us-ascii?q?FNwEFI1YQCwQUKgICVwYBDAgBAYMcAYF/qF+CHB+IMoErD4sCgTaCaId7glU?= =?us-ascii?q?Ch1iGH4tPCYNagViJZQaIEoVEkgeBSAsmgVIzGggbFYMlkFM9kRQBAQ?= X-IronPort-AV: E=Sophos;i="5.51,302,1526342400"; d="asc'?scan'208,217";a="4879374" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2018 08:30:07 +0000 Received: from [10.61.224.78] ([10.61.224.78]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w638U4wa004987; Tue, 3 Jul 2018 08:30:05 GMT To: Martin Thomson , adrian@olddog.co.uk Cc: rfcplusplus@ietf.org, draft-thomson-rfcplusplus-label@ietf.org References: <02bd01d41299$75677e00$60367a00$@olddog.co.uk> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Tue, 3 Jul 2018 10:30:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KgE6GejKJEYB7MlA083AeQIGU7WCaIGa3" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 08:30:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KgE6GejKJEYB7MlA083AeQIGU7WCaIGa3 Content-Type: multipart/mixed; boundary="m9bqKZLBgjtt6rub3U3vWjbJVh5Cq1hvj"; protected-headers="v1" From: Eliot Lear To: Martin Thomson , adrian@olddog.co.uk Cc: rfcplusplus@ietf.org, draft-thomson-rfcplusplus-label@ietf.org Message-ID: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00.txt References: <02bd01d41299$75677e00$60367a00$@olddog.co.uk> In-Reply-To: --m9bqKZLBgjtt6rub3U3vWjbJVh5Cq1hvj Content-Type: multipart/alternative; boundary="------------5535AABA2DD49B5D3282232D" Content-Language: en-US This is a multi-part message in MIME format. --------------5535AABA2DD49B5D3282232D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03.07.18 08:50, Martin Thomson wrote: > > The numbers and labels will need to remain valid. One of the bigger > issues in this giant ball of string - one that I hope we don't get > into - is immutability, and we can't stop the immutable RFC 9001 from > referencing BAR 9003. As a practical matter that probably means > keeping URLs live and any indices working, but not a whole lot more. > BAR 9003 might just point to RFC 9003 though. > I think that's the right approach.=C2=A0 I don't believe it has cost the = RFC Editor a whole lot to maintain the FYI series, for instance, the last of which was issued in 2001.=C2=A0 Thus three points: 1. You may wish to add discussion of FYI, and why *it* failed, the simple answer being that there was no need to create an FYI when the RFC labels remained available.=C2=A0 Arguably IENs fell by the waysid= e for the very same reasons. 2. Section 4.4 is entitled "A New Label is Necessary".=C2=A0 I believe t= his is overly assertive for an experiment.=C2=A0 If a new label is necess= ary, and the experiment "fails", what then?=C2=A0 More to the point, isn't= that the point of the experiment: to determine whether a new label is necessary or valuable? 3. Is the experiment considered a success if people refuse to publish with the new labels?=C2=A0 Does that, for instance, indicate the end = of the ISE?=C2=A0 I realize that is a question for the IAB, but it would= good to have some understanding of the thinking, going into this. Eliot --------------5535AABA2DD49B5D3282232D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 03.07.18 08:50, Martin Thomson wrote:

The numbers and labels will need to remain valid.  O=
ne of the bigger
issues in this giant ball of string - one that I hope we don't get
into - is immutability, and we can't stop the immutable RFC 9001 from
referencing BAR 9003.  As a practical matter that probably means
keeping URLs live and any indices working, but not a whole lot more.
BAR 9003 might just point to RFC 9003 though.

I think that's the right approach.=C2=A0 I don't believe it has cost = the RFC Editor a whole lot to maintain the FYI series, for instance, the last of which was issued in 2001.=C2=A0 Thus three points:
  1. You may wish to add discussion of FYI, and why *it* failed, the simple answer being that there was no need to create an FYI when the RFC labels remained available.=C2=A0 Arguably IENs fell = by the wayside for the very same reasons.
  2. Section 4.4 is entitled "A New Label is Necessary".=C2=A0 I bel= ieve this is overly assertive for an experiment.=C2=A0 If a new label = is necessary, and the experiment "fails", what then?=C2=A0 More to t= he point, isn't that the point of the experiment: to determine whether a new label is necessary or valuable?
  3. Is the experiment considered a success if people refuse to publish with the new labels?=C2=A0 Does that, for instance, indic= ate the end of the ISE?=C2=A0 I realize that is a question for the IA= B, but it would good to have some understanding of the thinking, going into this.

Eliot


--------------5535AABA2DD49B5D3282232D-- --m9bqKZLBgjtt6rub3U3vWjbJVh5Cq1hvj-- --KgE6GejKJEYB7MlA083AeQIGU7WCaIGa3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAls7NAsACgkQh7ZrRtnS ejOjfgf+OXC/S8rW+2wQURBjkh0ZwquLyYt0StGC02ubycg7DTt5BLjXGGQZilKa F267bo9J+dBSjcv+uwD3zB+zbhG+PJcYun4hVtjkez8dPX1OrwRBCImn8DMQK0Yd Pm7JeR2i4Mi8mI6U7Cq7RSvAR3ZpJVf0M3pY1JXOD9m8Uxcl8Ve1N2DJnv/6SoZj Js5hgPKnlgsCAdv/V87QSa2GGbGqOxuXGyQuQ9rlroAItMaE2XU81qMgmeSre6Hl hdPpVwMBwzDLQGoYHjHhtwKrx5Na6gmPnMC5/Rwb6jHCX5vHH2Hzwbmhesazpjda qBCTYZiRy4TWLY7ZUvb96sM7Z73lZg== =qIYM -----END PGP SIGNATURE----- --KgE6GejKJEYB7MlA083AeQIGU7WCaIGa3-- From nobody Tue Jul 3 05:46:15 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6473C130EAB for ; Tue, 3 Jul 2018 05:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ZYpbROzsJbUz for ; Tue, 3 Jul 2018 05:46:09 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (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 497D8130E59 for ; Tue, 3 Jul 2018 05:46:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 38154D40352; Tue, 3 Jul 2018 05:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1530621969; bh=u+c5PlAIbZtFhG2EbpPprr3DpfYuuDAt6hQjsSzvAzk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=S+lSgQrLZqCb2HroZCp5NAZLv3ONAE90Q5QRE9bEM/dNY1etJgGxlUWfVSqNqYwFc j+0qYpvWfx2CB904x0XmQ42SN4LOu1iGwbThTV2KIsGp6xj3J16ftECu0w3Z84PoXq ON8GWwAtU2QWdbzS6QpWUj4GsitB6iFE54OmX3a0= X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id A6ACAD40307; Tue, 3 Jul 2018 05:46:08 -0700 (PDT) To: Martin Thomson , rfcplusplus@ietf.org References: From: "Joel M. Halpern" Message-ID: <0fe47da2-c411-ad6b-f616-2c22c98648e1@joelhalpern.com> Date: Tue, 3 Jul 2018 08:46:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] Outlining the experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 12:46:13 -0000 I have several concerns with the draft as presented. 1) The draft seems to imply that confusion about status is principally or significantly a matter of labels, and a matter of Standards Track vs Information or Experimental RFCs. This is grounded in anecdotal evidence, since that is all we have. There is at least as much anecdotal evidence that suggests that labels are not an effectie solution at all. We have seen press, buyer, and vendor confusion treating Internet-Drafts (whcih clearly have a very different label) as if they were standards. This suggests at least to me that we have the wrong end of the stick. 2) The description of measuring the experiment seems very odd in several different ways. First, it states some measurements without stating whether increase or decrease in those measurements would constitute success. Second, one of the measures is the amount of standards track documents produced, which seems very odd. Third, 3 years is a long time for an experiment, but a very short time in the life cycle of produce useful documents at the IETF. (I know folks don't like that fact, but it is a fact.) Most importantly, there does not seem to be any measurement that relates the experiment to the problem it aims to solve. I understand that measuring that is VERY difficult. Heck, I have no clue how to measure it. But it seems very odd to measure an experiment by things which have nothing to do with the goal of the experiment. 3) I did not see any discussion of the issue of downrefs. If I were constructing a strawman to pretend that informational and experimental publication diluted the clairty of standards, the first thing I would point to as a cause of confusion is our practice of allowing downrefs to such documents. I actually think such downrefs are a good idea. In the absence of comment, I assume that the intention is to allow such normative downrefs when appropriate, as we currently do. That seems to weaken the very dstinction of labeling that the 'experiment" is attempting to perform." 4) As a relatively minor matter, the description of the BPC documents is wrong. The description in the document says that they are for IETF process documents. While BCP is used, with good reason, for IETF process documents, it is also used for other things. Inf act, there is significant ambiguity about what it should be used for, and it has been used for a range of protocol behavioral descriptions and operational practice descriptions. Yours, Joel On 7/3/18 3:32 AM, Martin Thomson wrote: > It's been good to see the level of engagement on this list. I've been > reading with some interest. > > I've submitted a draft that attempts to summarize the proposed > experiment: https://datatracker.ietf.org/doc/draft-thomson-rfcplusplus-label/ > [0] > > I had hoped to get this out sooner, but the urgency of other tasks > meant that I barely met the draft submission deadline, and it's very > rough still. Hopefully that draft clarifies some of the questions > people had about the scope of the proposed experiment. > > Obviously, this is just my view, and I don't think that everything in > there is correct (Adrian already found one hole). As Ted said, the > IAB are generally of the view that this is a topic worth discussing, > but as a group we don't agree on a particular solution. This is, more > than anything else, a convenient strawman. > > However, based on the feedback thus far, it seems like it might be > good to examine some of the more fundamental issues: > > 1. What is the problem? > > I think that the problem is well understood. The common perception of > "RFC" encompasses a far simpler notion than the reality. > > The debate seems to be centred more on the question of whether this - > of the multitude of problems that we might tackle - is the one that is > worth addressing. Several people have suggested that the broader > issues might be tackled more comprehensively. I'm personally not > opposed to that, though the thought was to keep the focus narrow. > > Brian cites the ISD proposal [1], which is much more ambitious, but > it's been a few years since anything like this has been attempted, > maybe there is enough pent-up demand for change that we could find a > more comprehensive set of changes. > > 2. Why this problem? > > It's a relatively small problem, with a (proposed) small solution. > > There are some potential advantages that might be later realized from > a looser coupling between different sources. There are certain > uniform expectations about publication as RFC that mean that certain > streams tend to affect the outcome of others, sometimes in ways that > are less than ideal. > > For instance, we see that all RFCs tend to have a security > considerations section, even if the notion is a little ridiculous (BCP > 78 says as much). Security considerations make sense for standards, > but less so for other types of document. Besides, I think that they > exist solely for the comfort of SEC ADs now, we've a pretty strongly > enculturated understanding of the importance of security in our > designs [2]. > > Similarly, one of the ideas floated early in this process was that > this might allow the RFC 5742 conflict review process to be removed. > That was intended to allow documents to proceed with fewer explicit > controls. Feedback from the ISE and ISEB indicated that they found > this process extremely valuable and the IESG don't see it as a burden, > so that's unlikely to be something that comes out of this, but I > mention it to illustrate the potential. > > 3. Why now? > > Why not? I don't really have a good answer for this, other than the > fact that there seemed to be sufficient interest in doing something > and that this was a reasonable candidate. > > 4. This is so unscientific! > > Yeah. That's the nature of the problem. Alissa articulated this > neatly in her email, it's a human problem. > > We should definitely explore deeper, because this is small, but it > isn't simple. My personal view though is that if this gets to the > point where we're employing market research companies, something has > gone seriously wrong. Going that deep, or dragging in a laundry list > of other unsolved problems, might be a good way to ensure continuation > of the status quo. > > 5. Why not erect a bigger sign? > > The current boilerplate in RFCs could be improved, but - as the draft > says - that doesn't really get to the crux of the issue. > > Even if there was a huge banner on every RFC that wasn't standards > track that said "DON'T IMPLEMENT OR DEPLOY THIS PROTOCOL. > IMPLEMENTING THIS PROTOCOL WILL HURT THE INTERNET", it won't stop > someone from receiving conflicting advice. > > At the risk of being the first to invoke what will eventually be > verboten under the terms of Godwin's Law, RFC 7974 is the best example > I have of this. It bears a warning nearly that strong and yet I have > received or witnessed strong endorsements of its virtues on several > occasions. > > > [0] You can find a more readable and updated version here: > https://martinthomson.github.io/is-the-future/draft-thomson-rfcplusplus-label.html > [1] https://tools.ietf.org/html/draft-ietf-newtrk-sample-isd-00 > [2] This is as it should be, alongside all the other things we might > consider as constraints on designs: privacy, deployment, operations, > usability, internationalization, human rights, economic effects, > intellectual property, etc... > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > From nobody Tue Jul 3 06:01:09 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781D7130EB9 for ; Tue, 3 Jul 2018 06:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymyQOU9Elnqr for ; Tue, 3 Jul 2018 06:01:03 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48834130E59 for ; Tue, 3 Jul 2018 06:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2799; q=dns/txt; s=iport; t=1530622863; x=1531832463; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=aPHOT67r4RlgSAWEp1R5SM16FKkQqvh25aXD+NgA958=; b=Du2tYXg6rcNFOiPr+KXCCwQf7Wm1BXHJvLH30P1Iy03xzl1UFAGMH0o9 GvU0/44jYANiQ1PAl/TJlIyHE/1j1CTUZkdxbZhVlyNjNzlK1kZAtwUjA iyOdBnIPchqoGd2UZ2hAKEEzM+HNGc8Zy+G5Tg98AA3QgYHVk/drb38kM k=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQApcztb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUYEoQhiGONaJciCAOEbAKCODgUAQIBAQIBAQJtKIU3AQU?= =?us-ascii?q?jZgsYKgICVwYBDAgBAYMcAYF/qEOCHIhPgSsPiwKBNoJoh3uCVQKZSwmDWoF?= =?us-ascii?q?YiWcGiBKFRZIJgVghgVIzGggbFYMlgiMXjhk9kHYBAQ?= X-IronPort-AV: E=Sophos; i="5.51,303,1526342400"; d="asc'?scan'208"; a="4885895" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2018 13:01:01 +0000 Received: from [10.61.96.59] (dhcp-10-61-96-59.cisco.com [10.61.96.59]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w63D10f1028211; Tue, 3 Jul 2018 13:01:01 GMT To: "Joel M. Halpern" , Martin Thomson , rfcplusplus@ietf.org References: <0fe47da2-c411-ad6b-f616-2c22c98648e1@joelhalpern.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Tue, 3 Jul 2018 15:01:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <0fe47da2-c411-ad6b-f616-2c22c98648e1@joelhalpern.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iBCQcIDRnaXsvy1dLmEfbQ0ll99iKBChR" Archived-At: Subject: Re: [Rfcplusplus] Outlining the experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 13:01:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iBCQcIDRnaXsvy1dLmEfbQ0ll99iKBChR Content-Type: multipart/mixed; boundary="TLbdjJMuDIdJ1y0fTYOpmsWH4yS7bkmN4"; protected-headers="v1" From: Eliot Lear To: "Joel M. Halpern" , Martin Thomson , rfcplusplus@ietf.org Message-ID: Subject: Re: [Rfcplusplus] Outlining the experiment References: <0fe47da2-c411-ad6b-f616-2c22c98648e1@joelhalpern.com> In-Reply-To: <0fe47da2-c411-ad6b-f616-2c22c98648e1@joelhalpern.com> --TLbdjJMuDIdJ1y0fTYOpmsWH4yS7bkmN4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Joel, On 03.07.18 14:46, Joel M. Halpern wrote: > 3) I did not see any discussion of the issue of downrefs.=C2=A0 If I we= re > constructing a strawman to pretend that informational and experimental > publication diluted the clairty of standards, the first thing I would > point to as a cause of confusion is our practice of allowing downrefs > to such documents.=C2=A0 I actually think such downrefs are a good idea= =2E=C2=A0 > In the absence of comment, I assume that the intention is to allow > such normative downrefs when appropriate, as we currently do.=C2=A0 Tha= t > seems to weaken the very dstinction of labeling that the 'experiment" > is attempting to perform." To recapitulate part of an earlier conversation, to me, downrefs and in particular approved downrefs to what are now RFCs are really standards unto themselves.=C2=A0 One approach, using what I think Martin and Adrian= were suggesting earlier would be to republish downrefs as RFCs.=C2=A0 Thi= s violates Brian's principle of attributes versus names, to be fair, but holds true to the intent of the experiment (I think). Again, I am neutral on the experiment itself. Eliot --TLbdjJMuDIdJ1y0fTYOpmsWH4yS7bkmN4-- --iBCQcIDRnaXsvy1dLmEfbQ0ll99iKBChR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAls7c4wACgkQh7ZrRtnS ejO53AgAsWRfKa02Br+UpqfgTJ3Wk+0KDwZ0b65v1qLMTuJmooFRsliyqJDPEESc t72GNT0tmd54ia5X8a9lro7X5jqnFXdg5GiNVEuStLIYJ7q2gDZqDXwAnBkpDWrD vxUxJF+XXwbXqycay/IsralTlBsI0rToHSFvwPwagZpxftk/i0GXI5eGlnFTRqfw v4GVuBlci4tELA9mIHOSLyLxEY5rELv7dsfRNqvFPRsa836+r/+J4p53bku+Plq1 CXNuEzUzAwZ06jCER4TKPpqGlZ7MYOyDnQHYbx1ccd4OwR5sNdUCRui3sYGO/gC6 d01GAN18+fGcYHN155KAPBJd5blyiQ== =tZFF -----END PGP SIGNATURE----- --iBCQcIDRnaXsvy1dLmEfbQ0ll99iKBChR-- From nobody Tue Jul 3 07:06:54 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3D51294D7 for ; Tue, 3 Jul 2018 07:06:52 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 h3KlbRGS6jS6 for ; Tue, 3 Jul 2018 07:06:49 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64A8128BAC for ; Tue, 3 Jul 2018 07:06:48 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id y20-v6so1633253qto.8 for ; Tue, 03 Jul 2018 07:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1VnBaPxvH93P1PhCw/uA/xYhkQBBe/33np+FG8p6knY=; b=T9plTt1sv4NkV4jdSj8PdjQ6OiKOGY+7gz8cEzmkA0e9j0rmuAujrRueEUjRsN2+O9 gGn2OUPHfcwiFyJhYjIbBN6eg4zGCWYTojcVGHd6/UktImWSPHhwEO4fgb9x4yLKPigI YX6VGnTptJ2jAx9OOb7rpifXTm7pLSypY7nCTPMoeG/aR4M2eje0OAoCLBbMn09xfK5p ZO7QOlMQd03utLenmngPrh2OvlRvFi1LZ/AuVkqIPOjzZoEUmGfLrPO8Nln0J1LI/jvn wl2t1OVw08ssdq35hkE12cWmc9L2PwjNmSlCPJeclqs8sEatzb/z+F2B8hge22vhh7sa FjIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1VnBaPxvH93P1PhCw/uA/xYhkQBBe/33np+FG8p6knY=; b=PG8YtMdlOKicSo1jtVuLEuD5JxIpDLDdcz/qvlygEEIXeuBFnRP+1eQ156gk9lQ+5g GCGFug2PidRn+PqKPJybrqfX8PL7o7Xet8l/+G/9MdGt3Ezism9DMCi7V34BG1Jp2vk1 s1xkpKpCDGJJVaOGcOhHJChajbEN7TlVDntNMqyPFKUigcSbfCEQk08yE7olBvWkLTtv 2PUF3EXOjGRhy5bEkdyB10WRIWBjzApyi+0c1ytCteLmjqquVXVybe80JjLDSn6LBp87 UjmO0HcfxvtgZy8Uvc9doM/n3GpzO1mA4dqOek8BbseKYmHlzlWgYNvAa6K+4OqxelZE 2IIg== X-Gm-Message-State: APt69E3W965vY1UhHtKxg/977Yaokok40/7pGfuz1FDz2tQN5+IKLxry obkhDnOmVRgIUBpCIYghML8= X-Google-Smtp-Source: AAOMgpfxqa51eTBk6ljr0B0boK26GE67gFXUcRdsipuUtGGac2SAierHZDC3SrybWfA4l4uIy3voEA== X-Received: by 2002:ac8:3961:: with SMTP id t30-v6mr27564732qtb.56.1530626807797; Tue, 03 Jul 2018 07:06:47 -0700 (PDT) Received: from [10.209.57.127] (23-25-221-77-static.hfc.comcastbusiness.net. [23.25.221.77]) by smtp.gmail.com with ESMTPSA id j128-v6sm61453qkc.50.2018.07.03.07.06.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 07:06:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Tue, 3 Jul 2018 10:06:45 -0400 Cc: rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8BAFCBB9-CFB9-4A29-A81C-9F67D142BA1E@gmail.com> References: To: Brian E Carpenter Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 14:06:53 -0000 Hi, Sent from my mobile device > On Jul 3, 2018, at 4:14 AM, Brian E Carpenter wrote: >=20 > Hi, >=20 > My main comment on this draft is that it proposes an experiment > without first explaining properly what the problem is and why the > proposed experiment might fix it. >=20 > It isn't sufficient to say there is misunderstanding of the > various RFC types and statuses. It isn't sufficient to give a > couple of examples of non-IETF-standard RFCs that might be > implemented and deployed in parallel with IETF standards. > Where is the damage to users, where are the numbers, how do > we assess the seriousness of the damage? Isn't it sometimes > better to have multiple solutions? Isn't it *always* better > to document something which is deployed, whether it's good > or bad? Isn't the IETF solution sometimes wrong? How much of > the perceived problem is just a matter of damaged pride? How > does this problem compare with others that have been known about > for just as long? Why is this one worth solving (disruptively) > when the others aren't? >=20 > Right now I just don't see a problem statement that answers those > questions. >=20 > I'm tempted to stop there, but here are some more detailed > comments: >=20 >> RFC 1796 [RFCS] was published in April of 1995. At that time, it was >> clear that there was an "regrettably well spread misconception" that >> the label "RFC" implied "some level of recognition". >=20 > True. Also at that time (in fact a few months before, since the > RFC Editor had already reacted), the RFC boilerplate was modified > to avoid misconception for anyone who bothered to read it. >=20 >> Not a lot has >> changed in the 23 years since that statement. >=20 > Evidence, please. >=20 > I'd say that the evidence is that people don't take much notice > of the label and the boilerplate; they go straight to the text. > (OK, insert the obligatory anecdote of Avian Carriers being cited > in an RFP, but one swallow doesn't make a summer.) >=20 >> The common perception of the significance of the "RFC" label is >> simple. >=20 > That may be so, but since the draft doesn't state what that=20 > perception is, the reader cannot guess what is intended. >=20 > For example, my perception of the significance is that an RFC > is a request for comments. Then I look for its status. Then > I look for its contents. Isn't that what we should assume serious > engineers & product managers do? >=20 >> This document suggests that this view to some degree underestimates >> the value of a label (or "brand"). >=20 > Or, equally plausibly, it overestimates the value of the label. > My belief is that, the occasional dishonest salesman apart, it's > the content that people value. If they know anything, they know > that *all* RFCs have had genuine peer review. (Unlike many > academic papers, see "Some science journals that claim to peer > review papers do not do so", The Economist, June 23, 2018.) >=20 >> This document proposes an >> experiment that limits the use of the "RFC" label to the product of >> that process. >=20 > I have to re-iterate that this is not a choice the IETF can make, > since the IETF and its committees do not own the RFC series. The > IETF can't kick the other streams out. >=20 >> Capturing the nuance required to properly understand a protocol is >> difficult, and a large number of documents fail to properly convey >> that status. >=20 > Correct. However, this is a hard problem that the IETF has > essentially refused to solve, because the solution is hard > work, both for WGs and for the IESG. > draft-klensin-std-numbers and draft-ietf-newtrk-sample-isd > were both put in the "too hard" bucket by previous IESGs, > for example. >=20 >> ZRTP [RFC6189] was published as an informational RFC on >> the IETF stream after the IETF reached consensus to develop DTLS-SRTP >> [RFC5764] for the same use case. >=20 > The document makes no claim to be a standard and it gives some > explanation of how it differs from RFC5764. It isn't clear > to me what is unclear to the reader. >=20 >> HTTP Live Streaming (HLS) [RFC8216] was published on the >> Independent Submissions Stream in defiance of a standardized >> protocol, MPEG-DASH [DASH] >=20 > The word "defiance" seems quite inappropriate. Firstly, the RFC > doesn't mention MPEG-DASH at all. Secondly, the document makes > no claim whatever to be a standard. >=20 >> Both describe de-facto standards, each of which are implemented in >> more than one product and deployed. >=20 > Right. It has long been considered a good idea to document stuff that > is widely deployed, for everybody's benefit. >=20 >> Each captures a range of design decisions that differ from the >> commonly-accepted view. >=20 > How often in the history of engineering has "the commonly-accepted > view" turned out to be wrong? How often in the history of the > Internet has something unexpected turned out to be a winner? >=20 >> If nothing else, the deployment of these protocols >> could adversely affect interoperability relative to implementations >> of their more widely accepted alternatives. >=20 > That's true, of course, but the Internet has always worked by > survival of the fittest. I'm not seeing a tragedy here. >=20 >> Information about the status of the document is contained entirely in >> the "Status of this Note" section. For instance, ZRTP is published >> with IETF consensus, so the significance of it not being an "Internet >> Standards Track specification" is easily lost. >=20 > Easily if you don't read the words, yes. >=20 >> That it also limits >> its mention of DTLS-SRTP to comparative criticisms makes it possible >> to interpret the document as it represents itself: a newer, superior >> technique. >=20 > Yes, the authors believe that their way is better. That's > hardly a surprise. >=20 >> There are numerous examples of RFCs that make an honest >> representation of their status in more than just the boilerplate. >=20 > Indeed. And this is an aspect that peer reviewers should look > out for. >=20 >> So why is the publication of an RFC so keenly sought, when the >> document doesn't capture the output of the Internet Standards >> Process? >=20 > I don't know. Did you try asking the authors? Speculation > doesn't help us much. For my own independent submissions, > it's because it's the appropriate way to reach the Internet > technical community in general (not just the IETF as you > suggest), and another motivation is to get constructive review > (as opposed to the essentially random or sometimes bogus review > you get from academic journals and conferences). Most of the > Internet technical community doesn't read academic journals, by > the way: apart from anything else they're too expensive, and > most of the articles are too... academic. >=20 >> This documents proposes reserving the "RFC" label for those documents >> that are the product of the Internet Standards Process [RFC2026]. >=20 > And again, in case anybody missed it: the IETF can't do > that because it doesn't own the RFC Series. >=20 > What the IETF can do is change the requirements for its own > stream of RFCs, or stop calling its documents RFCs at all. >=20 > The second one is a terrible idea, for reasons I gave at > https://tools.ietf.org/html/draft-carpenter-request-for-comments-00#sectio= n-4 >=20 > The first one is absolutely reasonable, and a good > first step is at > https://tools.ietf.org/html/draft-klensin-std-numbers-02 > With the right typography in the new RFC format, this > could be very effective. >=20 >> 4.1. New Labels for Other Documents >=20 > This section is ambiguous. But most of it is out of IETF > scope anyway, because the other users of the RFC series > will label their RFCs as they wish. I wouldn't be against > the header lines being more explicit. >=20 >> The "STD" label hasn't been especially effective in distinguishing >> those documents that attain the rare status of Full Internet >> Standard. The BCP subseries has been more effective, perhaps because >> of the greater familiarity of its primary audience with its meaning. >=20 > Exactly why we should apply the STD series label to *all* standards > track documents, as proposed many years ago and more than once since then.= > (Also why I'm a fan of > https://tools.ietf.org/html/draft-loughney-newtrk-one-size-fits-all-01 ) I agree that we haven=E2=80=99t done a good job of promoting standards and t= his could solve the issue at hand. If we are more consistent and then use t= he references for STD, this could result in reducing the confusion. It=E2=80= =99s a matter of discipline and willingness to do the work to assign the num= bers and use them. Perhaps this should be the first step. >=20 >> However, the choice of rendering is not >> part of the canonical XML document. Alternative renderings could >> legitimately erase that information. >=20 > They could drop special choices of font & font size, true, but they > couldn't drop the actual status etc. if it's part of the document > text. In any case, most people will use and refer to the primary > HTML rendering, which the RFC Editor will generate. >=20 >> That leads to the conclusion that clearer marking for status, while >> possibly helpful, would not be sufficiently effective in addressing >> the problem. >=20 > That may in fact be true, since the fundamental problem is that humans > see what they want to see, and readily skip boring stuff like document > labels and status. This leads to the conclusion that adjusting the labels > won't address the perceived problem: if people have a good reason to > ignore today's labels, they will ignore tomorrow's as well. >=20 +1 >> A term of 3 years is proposed as being long enough to provide enough >> evidence to assess the effect of a change of labels. >=20 > I question whether that's long enough. Some product cycles are faster, > but many are slower than that. How many cases per year do we have > of RFC-label-confusion causing significant problems to users? Unless > that's a large number, and we can use those cases to assess the time lag > between RFC publication and the occurrence of problems for users, > I really don't know how long a test would be needed. >=20 > (The proposed metrics about publication rates are pretty useless > except perhaps for a sociologist, because they don't seem to > be relevant to the alleged problem. And in any case, as noted, > the datasets will be tiny and most of what we'll see will be > statistical noise.) >=20 >> 6. Security and Privacy Considerations >>=20 >> It is believed that there are none. >=20 > Given how many of the Independent Series RFCs are about > crypto algorithms and the like, potentially interfering with > that publication channel seems to pose a risk. >=20 Agreed. There are numerous drafts published for crypto where the independen= t stream is absolutely the right choice. If it=E2=80=99s specific to a regi= on, there=E2=80=99s no need for (and is likely inappropriate) IETF review an= d publication via AD sponsorship or a WG process. Regards, Kathleen=20 > Regards > Brian Carpenter >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Tue Jul 3 08:16:43 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1223130E6D; Tue, 3 Jul 2018 08:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 WxHPD8nioIHV; Tue, 3 Jul 2018 08:16:34 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5992E130DCC; Tue, 3 Jul 2018 08:16:31 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id s198-v6so4500579oih.11; Tue, 03 Jul 2018 08:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7rG82hA/spd8hnFJ5m1qRtQ35A9H+JKPadldTMNSiqg=; b=B2eBlwNdeJRzsslTgUfTIsoMdjmKJTanueJXMd2K9byj0RKOZzEFJuKNw3N2OipJus oPOj4Ucblzl0eNZzTabFuCUxQXtvH8kK4AFmHy8BMlhgXpuWoolJDVn+VneJX+pv5QV6 Ia82ru//eS1/sW/xFDEAq/rojNRV09HhSROOTEV1+mxJ8P7ax9qDstgS4syNJJ5j/Yxe RZFduFcwmwp43oSBNFnlVxGLjagZ+ZRv2xlFhRD6NJx23a5Ih0F7yKT3wthbx5eeKEeB nSTVWE3JRhXUjWHCABeK4Ne5rV59tIUTEUlDZ4+ac9dGTxa89nHkB3KkkJzIin1QCYwV UUcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7rG82hA/spd8hnFJ5m1qRtQ35A9H+JKPadldTMNSiqg=; b=l/TjdnerNwiZns85CWPtdV3Az0J/gtlNyr7zDRUqXb0cVpT7ZtMiY/GyuUyi6cLaeu rfUWk2KuqYx8LGJYoPxJLsyBHgAvl7M5IpRycbIfnQbfEqHwCjl+nIp3Bawzc7XHMkY+ RV27fCqGwCs73/0OwVwjT6hipUL6f4i9IGMU9NuUuabWAW413LGnKDPNiEAPe4BvjJjw SCkRpqitUCja5uJguBksHgsbybqx2jmfrfNWjalp2MK2McqrkCOYezThhoIxeySiQPrk jP5q2loIff2IbvCQFzvcRMA083KiuFFh+rbiLfBf+MZ+K9ya4/swbM7I4cFjEzWK6zFN nDOw== X-Gm-Message-State: APt69E0CZTTRnhb2Wr1elA+ogNoRlJFzfVA9GCDKhEkqkVsV78S6AfZ3 TwckibMMjDUhHrqJ8NhiKWeQkc8kTxtfaaxpjzc= X-Google-Smtp-Source: AAOMgpdd3417mVWXQkEioKZ817YRU1WxVbiJdTlU6IQU4KGTMmUmTSHOxRnJU1Sqyuq5yYy90AveeufY+SqOE2VspcY= X-Received: by 2002:aca:e450:: with SMTP id b77-v6mr12183485oih.0.1530630990459; Tue, 03 Jul 2018 08:16:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 08:15:59 -0700 (PDT) In-Reply-To: References: <02bd01d41299$75677e00$60367a00$@olddog.co.uk> From: Ted Hardie Date: Tue, 3 Jul 2018 08:15:59 -0700 Message-ID: To: Eliot Lear Cc: Martin Thomson , Adrian Farrel , rfcplusplus@ietf.org, draft-thomson-rfcplusplus-label@ietf.org Content-Type: multipart/alternative; boundary="00000000000077f6c7057019cc31" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 15:16:37 -0000 --00000000000077f6c7057019cc31 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 1:30 AM, Eliot Lear wrote: > > > 1. You may wish to add discussion of FYI, and why *it* failed, the > simple answer being that there was no need to create an FYI when the RFC > labels remained available. > > This is not really my memory of either the creation or conclusion of the FYI series. From my perspective, the FYI series was a function of the User Services area (this is noted in RFC 1150, section 9 and confirmed in RFC 6360). That area was built to educate new users of the Internet and the FYI series was part of that effort. Why we concluded that effort may be describe succinctly as it being overcome by events: the rate and variety of new users joining the network overtook the efforts that had made sense in a smaller, more homogeneous network. While Joyce is no longer with us, you might discuss this with April Marine, now at Akamai, for more detail. regards, Ted --00000000000077f6c7057019cc31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 3, 2018 at 1:30 AM, Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:

  1. You may wish to add discussion of FYI, and why *it* failed, the simple answer being that there was no need to create an FYI when the RFC labels remained available.=C2=A0

This is not really my memory of either the crea= tion or conclusion of the FYI series.=C2=A0 From my perspective, the FYI se= ries was a function of the User Services area (this is noted in RFC 1150, s= ection 9 and confirmed in RFC 6360).=C2=A0 That area was built to educate n= ew users of the Internet and the FYI series was part of that effort.=C2=A0 = Why we concluded that effort may be describe succinctly as it being overcom= e by events:=C2=A0 the rate and variety of new users joining the network ov= ertook the efforts that had made sense in a smaller, more homogeneous netwo= rk.

While Joyce is no longer with us, you might di= scuss this with April Marine, now at Akamai, for more detail.
regards,

Ted

--00000000000077f6c7057019cc31-- From nobody Tue Jul 3 09:04:36 2018 Return-Path: X-Original-To: rfcplusplus@ietf.org Delivered-To: rfcplusplus@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 230DA13101F; Tue, 3 Jul 2018 09:00:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: alissa@cooperw.in, rfcplusplus@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063361913.4893.14070331816195720640.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:19 -0700 Archived-At: Subject: [Rfcplusplus] rfcplusplus - Requested session has been scheduled for IETF 102 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:31 -0000 Dear Liz Flynn, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rfcplusplus Session 1 (1:30 requested) Monday, 16 July 2018, Afternoon Session III 1810-1940 Room Name: Laurier size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/rfcplusplus.ics Request Information: --------------------------------------------------------- Working Group Name: The label "RFC" Area Name: General Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: iasa2 irtfopen People who must be present: Gonzalo Camarillo Alissa Cooper Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jul 3 09:18:38 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E435130F33 for ; Tue, 3 Jul 2018 09:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bKUb7JsoP83I for ; Tue, 3 Jul 2018 09:18:21 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 EAB3D131024 for ; Tue, 3 Jul 2018 09:14:33 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id d189-v6so4925303oib.6 for ; Tue, 03 Jul 2018 09:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tjYpu0yqQyGYXeu8ktAJtTmQBB5mQK4J35np9LlzmxQ=; b=l8Y7Q2KeOPSG531bwWqHpZBthFQIgTWHk2QL4rnHFnUVlE/Vbb5uZgJVyG6FfATS/M dggy02RUpGur7x8P54KJ9n4MR7SCg8BRgJkwdcJ0nHB4Q4uTZAP/4NF7oBwJMwDXxy3w YELRp/uTCiUkAsNx6K0e15Tx34QEceMURPnLw3xUp0WqzhKhWhrLVjX0cPgnJ2pDtBbs nyIdeebsDOVLHOasIZM/OS+03YXLhJ3crHvzLenwx5ae6o8BQNu58dN3sPdfJmt9sY2U tq/r935JnSFgv3EAlLI5DANKIPQQD1PJzdEwfeeC0TUVyLs/zg1dr2AbZxNUmjXGvTmz giRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tjYpu0yqQyGYXeu8ktAJtTmQBB5mQK4J35np9LlzmxQ=; b=tJmR10uHXzJ0MC5DS+DruXMebSluzdmhoVISPgk4/KjOH0X361qUy1ckA9RYltFHWZ jqqEF1GoXY+ekmMdA9OwdRS+6q5OOrYeL1dRvBOz0llRghUP7eavXy61BDoAXLmppKRD My6px27TZ33b2czVP684zORGGQ4IWZvi4Hb9a6upHFt2Zhac2kzdTTasildZvnwSWhWu bGiTh9WxUc6ni/KTIgQy70FTfroGFQ8H8x2doNUqtAFfKxAOVQA4l+rrUvsmCqfQ+sl1 ExfP67Bsm7uLY5DxiBtVwB7kQb5qhPvmrZQrUNso31sHgQfe9TQhWCDp8GXGt1z0IIMa iTxw== X-Gm-Message-State: APt69E2iHxgk8J9vSMcNQxWBECG2nKi5aLOF6xnbi/4i+S/LcMNdNkV2 XGDPc7jNrVpsggsnIOOOzJim2nTZo/5WiApRUmZtZg== X-Google-Smtp-Source: AAOMgpdi6TGKokXAWGK8HL9THlMkWPlYkl1G6EQkdvpcMWPPxAQhl5sXb9KfRxRS7rCswMZvF2DjZpVwECQU8C+od+E= X-Received: by 2002:aca:c692:: with SMTP id w140-v6mr20438939oif.284.1530634473021; Tue, 03 Jul 2018 09:14:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 09:14:02 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Tue, 3 Jul 2018 09:14:02 -0700 Message-ID: To: Brian E Carpenter Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000000ba4db05701a9c91" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:18:36 -0000 --0000000000000ba4db05701a9c91 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 1:14 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Isn't it *always* better to document something which is deployed, whether > it's good > or bad? > I believe that a number of your questions are ill-formed, and that the one I highlight above illustrates this problem best. The question is not "should X, which is deployed, be documented?", but "Should the RFC Series contain the documentation for X, which is deployed?". If X was specified by the IETF, then the answer is yes, it should be contained in the IETF stream of the RFC Series. In the small number of cases where it was specified by the IRTF, then it should be contained by the IRTF stream of the RFC Series. The IAB stream could also theoretically produce an protocol specification that was deployed (though current practice is to bring any work of that type back into the IETF). Those streams are, in other words, set aside as publication outlets for specific bodies. The Independent stream is very different, in that the ISE is meant to exercise editorial discretion for publication and clearly could not publish documentation of everything deployed even if it were made available to the stream for publication. To illustrate that impossibility, note that there are approximately 2 million apps in the Apple app store, according to published reports; just documenting which ones used what variants of HTTPS *alone* would dwarf the output of the ISE (240 pages in 2017 outside of April 1st RFCs, according to email from Adrian). Eliot's pointer earlier today to the FYI series is instructive--the FYIs reused the RFC series in part because the distribution mechanism was well understood and well developed: There are several reasons why the FYIs are part of the larger RFC series of notes. The formost reason is that the distribution mechanisms for RFCs are tried and true. Anyone who can get an RFC, can automatically get an FYI. More importantly, anyone who knows of the RFC series, can easily find out about the FYIs. Given that there are many other distribution mechanisms available today, we do not have to treat the RFC series as the only place where such documentation can take place. regards, Ted --0000000000000ba4db05701a9c91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 3, 2018 at 1:14 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Isn'= t it *always* better to document something which is deployed, whether it= 9;s good
or bad?

I believe that a number of your questions are ill-= formed, and that the one I highlight above illustrates this problem best.= =C2=A0 The question is not "should X, which is deployed, be documented= ?", but "Should the RFC Series contain the documentation for X, w= hich is deployed?".

If X was specified by the IETF, then the answer is yes, = it should be contained in the IETF stream of the RFC Series.=C2=A0 In the s= mall number of cases where it was specified by the IRTF, then it should be = contained by the IRTF stream of the RFC Series.=C2=A0 The IAB stream could = also theoretically produce an protocol specification that was deployed (tho= ugh current practice is to bring any work of that type back into the IETF).= =C2=A0 Those streams are, in other words, set aside as publication outlets = for specific bodies.

The Independent stream is very different, in that the ISE = is meant to exercise editorial discretion for publication and clearly could= not publish documentation of everything deployed even if it were made avai= lable to the stream for publication.=C2=A0 To illustrate that impossibility= , note that there are approximately 2 million apps in the Apple app store, = according to published reports; just documenting which ones used what varia= nts of HTTPS *alone* would dwarf the output of the ISE (240 pages in 2017 o= utside of April 1st RFCs, according to email from Adrian).

Eliot's pointer e= arlier today to the FYI series is instructive--the FYIs reused the RFC seri= es in part because the distribution mechanism was well understood and well = developed:
   There are several reason=
s why the FYIs are part of the larger RFC
   series of notes.  The formost reason is that the distribution
   mechanisms for RFCs are tried and true.  Anyone who can get an RFC,
   can automatically get an FYI.  More importantly, anyone who knows of
   the RFC series, can easily find out about the FYIs.

Given that there are=
 many other distribution mechanisms available today, we do not have to trea=
t the RFC series as 
the only place where such documentation can take pl=
ace.  
regards,
Ted
--0000000000000ba4db05701a9c91-- From nobody Tue Jul 3 09:31:25 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461B612F1AB; Tue, 3 Jul 2018 09:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgVR7XOp4E7T; Tue, 3 Jul 2018 09:31:16 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C3D130E82; Tue, 3 Jul 2018 09:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6492; q=dns/txt; s=iport; t=1530635025; x=1531844625; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=57+UEB3cY7Z/qSzSbTnKD7cQwnnd5F8gAqQPdnFjIeI=; b=ToRMXStcLtFVmiowYu9PrX6RWLNbykkpH8hH0+9HmaPEqPdTICJ7095R 7v5oJ+gzqZnlA36mYzlcuXe/9QmJjYWQGG6aHQmdzN8KeBajGY133pEf2 zJ8h6FWi9YxstD4/gmGXiZOv1qc7LoK4FM+YWNlFjM7CSOSpVF/rI0ySo 8=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAQCSojtb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUYEiiDeYhjjT0qkBqHCAgDhGwCgjo4FAECAQECAQECbSi?= =?us-ascii?q?FNwEFI1YQCwQUJwMCAkYRBg0GAgEBgxwBgX+of4IcH4gugSsPiwKBNoJogxg?= =?us-ascii?q?EhF+CVQKHWYYii1AJg1qBWIlnBogShUWSCYFYIYFSMxoIGxWDJJBUPTABkHg?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.51,304,1526342400"; d="asc'?scan'208,217";a="4947022" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2018 16:23:43 +0000 Received: from [10.61.96.59] (dhcp-10-61-96-59.cisco.com [10.61.96.59]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w63GNgCY020721; Tue, 3 Jul 2018 16:23:42 GMT To: Ted Hardie Cc: Martin Thomson , Adrian Farrel , rfcplusplus@ietf.org, draft-thomson-rfcplusplus-label@ietf.org References: <02bd01d41299$75677e00$60367a00$@olddog.co.uk> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Tue, 3 Jul 2018 18:23:41 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LYjYKxrKZGXeNsPwNBG1BpJZM8WBMgCpO" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:31:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LYjYKxrKZGXeNsPwNBG1BpJZM8WBMgCpO Content-Type: multipart/mixed; boundary="dwJ8LaVCSg6z1Eh7iirEJcFQPcStx4lft"; protected-headers="v1" From: Eliot Lear To: Ted Hardie Cc: Martin Thomson , Adrian Farrel , rfcplusplus@ietf.org, draft-thomson-rfcplusplus-label@ietf.org Message-ID: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00.txt References: <02bd01d41299$75677e00$60367a00$@olddog.co.uk> In-Reply-To: --dwJ8LaVCSg6z1Eh7iirEJcFQPcStx4lft Content-Type: multipart/alternative; boundary="------------E488376254DC13F0A42581E2" Content-Language: en-US This is a multi-part message in MIME format. --------------E488376254DC13F0A42581E2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry Ted you're right.=C2=A0 But the IEN series is probably a better exa= mple to study. On 03.07.18 17:15, Ted Hardie wrote: > On Tue, Jul 3, 2018 at 1:30 AM, Eliot Lear > > wrote: > > > 1. You may wish to add discussion of FYI, and why *it* failed, > the simple answer being that there was no need to create an > FYI when the RFC labels remained available.=C2=A0 > > > This is not really my memory of either the creation or conclusion of > the FYI series.=C2=A0 From my perspective, the FYI series was a functio= n of > the User Services area (this is noted in RFC 1150, section 9 and > confirmed in RFC 6360).=C2=A0 That area was built to educate new users = of > the Internet and the FYI series was part of that effort.=C2=A0 Why we > concluded that effort may be describe succinctly as it being overcome > by events:=C2=A0 the rate and variety of new users joining the network > overtook the efforts that had made sense in a smaller, more > homogeneous network. > > While Joyce is no longer with us, you might discuss this with April > Marine, now at Akamai, for more detail. > > regards, > > Ted > --------------E488376254DC13F0A42581E2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sorry Ted you're right.=C2=A0 But the IEN series is probably a bet= ter example to study.


On 03.07.18 17:15, Ted Hardie wrote:
On Tue, Jul 3, 2018 at 1:30 AM, Eliot Lear <lear=3D40cisco.com= @dmarc.ietf.org> wrote:

=
  1. You may wish to add discussion of FYI, and why *it* failed, the simple answer being that there was no need to create an FYI when the RFC labels remained available.=C2=A0

This is not really my memory of either the creation or conclusion of the FYI series.=C2=A0 From my perspective, th= e FYI series was a function of the User Services area (this is noted in RFC 1150, section 9 and confirmed in RFC 6360).=C2=A0 That area was built to educate new users of th= e Internet and the FYI series was part of that effort.=C2=A0 = Why we concluded that effort may be describe succinctly as it being overcome by events:=C2=A0 the rate and variety of new= users joining the network overtook the efforts that had made sense in a smaller, more homogeneous network.

While Joyce is no longer with us, you might discuss this with April Marine, now at Akamai, for more detail.

regards,

Ted


--------------E488376254DC13F0A42581E2-- --dwJ8LaVCSg6z1Eh7iirEJcFQPcStx4lft-- --LYjYKxrKZGXeNsPwNBG1BpJZM8WBMgCpO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAls7ow0ACgkQh7ZrRtnS ejMWjgf/RkeV/oQq0Qju9vwgpSn91KGA+tLTUlLbLbLzpkEu48Rq0dgugAbc0lSe M7JHtO5CEF06hw0rgUizmj0PDmExHY2TNoQEuy42E8K3YAKAjQOoHvzCiRfn6EQW IctYfMNDoILjFzuL4JPvaZR33hwMDj2HnaU8acj4r1YhfMiHnx6UCLCsbgthzvAr WH43ihKCZv/aQcUyw8j17bVBNe9oBXpIgFs5/++8UV6A5ioAyQMZzuJO90Y6zalB SrWrCByIUqCBVCqz53DxxVWBDT154OP1WS0JoAB810sDpVqptQ9me5tq6H3kuCbY ZhFgKVgQYxtwiK7cDoW1UG8wMpmYeA== =XS0T -----END PGP SIGNATURE----- --LYjYKxrKZGXeNsPwNBG1BpJZM8WBMgCpO-- From nobody Tue Jul 3 09:37:38 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C8B12F1AB for ; Tue, 3 Jul 2018 09:37:35 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 qfm4QCYk1XFx for ; Tue, 3 Jul 2018 09:37:31 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DF2130E30 for ; Tue, 3 Jul 2018 09:37:31 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1faOIy-000EpC-Oo; Tue, 03 Jul 2018 12:37:28 -0400 Date: Tue, 03 Jul 2018 12:37:22 -0400 From: John C Klensin To: Melinda Shore , Martin Thomson cc: rfcplusplus@ietf.org Message-ID: In-Reply-To: <74f27b84-9ee2-84e0-4343-cf2b8ce3718a@gmail.com> References: <6.2.5.6.2.20180701101957.0b324b80@elandnews.com> <14134BFED03190159F304C91@PSB> <11243C49063C7F3B0B80875B@PSB> <74f27b84-9ee2-84e0-4343-cf2b8ce3718a@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Outlining the experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:37:36 -0000 (Apologies in advance for the length of this -- I think this note addresses a critical issue affecting whether the BOF will be useful (or is even worth holding). I cannot explain it in sufficient detail to make the issue clear without some background and in a few short sentences. If we were not past the deadline, I might have considered posting this as an I-D, but we are.) --On Monday, July 2, 2018 11:38 -0800 Melinda Shore wrote (with Subject Re: [Rfcplusplus] Another RFC experiment): > To be clear, I'm not a fan of the proposed experiment and > it wasn't my proposal. I do think, however this is the right > time to have this discussion, assuming that it's not driven > off the rails, turns into a bikeshedding exercise, or > otherwise loses its focus. Lack of clarity about RFC streams > isn't limited to people who write RFPs - we see it among IETF > participants as well, and if there's a way to improve > signaling about distinctions between document types, we should > talk about it. I think this is fair (although I still have concerns as to whether this is our most important issue to address), but want to focus, at least temporarily, on the the BOF description and part of Martin's note and I-D... --On Tuesday, July 3, 2018 17:32 +1000 Martin Thomson wrote: >... > However, based on the feedback thus far, it seems like it > might be good to examine some of the more fundamental issues: > > 1. What is the problem? > > I think that the problem is well understood. The common > perception of "RFC" encompasses a far simpler notion than the > reality. >... Sure. But, for example, the common perception of "IETF" is also far simpler than the reality. One could, for example, ask whether "IETF" includes the IAB or not and, if not, just what the relationship is and what authority the IAB actually has because those topics are part of the answer about the IETF. In the early 1990s the relationships seemed clear but what could be seen as a disagreement between the IAB and what is loosely called "the IETF community" (which may or may not be the same as "the IETF") led to what we call the Kobe meltdown and the POISED process. That ultimately ended in a re-sorting of responsibilities but left a number of loose ends dangling, with the main definitional documents being "charters" for the IESG and IAB that were written by those bodies to describe their perceptions of their roles with how much those definitions represent community consensus, especially informed community consensus, as an open set of questions. FWIW, the role and authority of the RFC Editor function was, and is, another of those loose ends. It can be argued that set of questions leads directly to the bike shed. Alternately and with equal force one could argue they they are the critical issues. If they are, then questions of how one identifies documents published by the RFC Editor Function or on behalf of a broad definition of this community is the real triviality. But let's look at the RFC question. Your explanation of "the problem" above appears to be consistent with the abstract in the posted version of your I-D but less so with parts of the body of that document and quite different from the explanation in the BOF description. Having recently been taken to task by the IESG for writing a BOF proposal that seemed to suggest an open-ended discussion rather than something more focused, it would, IMO, be consistent and helpful to be more clear about your view of the problem. In addition, the observation that perceptions differ is not inherently a problem that needs to be solved or that is solvable. The comments about the definition of the IETF above is an example of that -- we have twitches, and occasionally those are important, but we've managed reasonably well for more than 20 years without stopping to really nail those issues down. As a more trivial example, my neighbors probably have a general sort of agreement about whether or not "it is really hot outside" is a correct statement, but, if one tries to pin down the details of the individual perceptions and the boundaries associated with them, one would almost certainly find that perceptions differ widely, probably very widely (and even more widely if one compared answers in Anchorage, Oyster Bay, Boston, or Phoenix). However, this differences are rarely a problem in need of solution. However, the BOF proposal and the Introduction to your I-D appear to be talking about a more concrete problem, the one described in RFC 1796 and often discussed in terms of lack of clarity about the sources of RFCs causing confusion about what is and not a Standard or, more specifically, an IETF one (given that we have republished, with permission, the standards of other bodies in the series). I want to challenge that problem view and, with it, the assertion in the draft that "Not a lot has changed in the 23 years since that statement" because, if that assertion is false, then there is no problem here worth solving unless, contrary to Melinda's note, we really want to take extensive tours of some convenient bike shed or collection of them. At least in my perception as someone who has been around and sometimes very close to these issues since well before 1796 saw the light of day, a number of things have changed, and changed significantly, in the relevant 23 years. In terms of the content of RFC Series documents, at least the following changes have occurred, motivated in part by the recommendations of 1796 but, at least in the first case, showing significant further evolution: (1) The "Status of this Memo" text has changed, from "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. ..." (with different, but similar, text for BCP and Standards-track documents) but with no distinction among document sources, to today's far more elaborate and detailed versions. (2) The implicit assumptions about the STD numbers in RFC 1796 (and in RFC 1311, which established that numbering system) was that standards-track specifications that were actually worth implementing and deploying would rapidly progress to Internet Standard and, incidentally, that Proposed Standards might be little more than bright ideas with little evidence of implementability or utility. It is probably relevant that the provision for "automatic review for viability" after 24 months of Proposed and Draft Standards survived into RFC 2026 and later (even though it was ignored for years before we got around to formally eliminating it). That, too, has changed, but in the direction of raising the bar for publication as Proposed Standard and recognizing that many important specifications will never advance past that level. The divergence from that assumption about standardization means that the (experiment?) proposed for STD in RFC 1796 (using STD numbers to exhibit distinction, which appears to me to be slightly different from RFC 1311 which seems to be more about grouping) has never really been carried out. We generally think badly of starting one experiment that builds on another without first completing and evaluating the earlier one. Performing what I think of (and your I-D implies) as the experiment with STD requires some measure, such as that proposed in 2011 and earlier as draft-klensin-std-numbers-02 to be sure that identifier is really on most of all standards-track documents at any maturity level. Until we do that, we really have no idea about the effectiveness of overlay labels in making the distinctions that the I-D seems to call for. We also haven't carried out the actions and implicit experiment proposed in RFC 1796 until the RFC Editor (and appropriate tooling) insist on "[STDnnnn]" citation anchors and references rather than "[RFCnnnn]" ones except in the specific cases in which a specific document, rather than a standard, is being cited. So, again, if RFC 1796 is a relevant authority, we haven't implemented and examined its recommendations sufficiently to know that they were inadequate. Probably more important (and with apologies for some overlap with Joel's recent comments), I believe we have no evidence at all about the effectiveness (or lack thereof) of the post-1796 header information and status boilerplate in clearing up the types of confusion that appear to have motivated RFC 1796. It seems to me to be worthwhile to try to understand that before branching out in other directions, even experimentally (even assuming a non-destructive, reversible, experiment can be specified), particularly given an (equally unproven) hypothesis about what has changed in the last decade: At the time RFC 1796 was published, there was some evidence that even well-intentioned people who were willing to try to understand distinctions were being confused: the status statements were not focused enough and no distinction was made about origins or what we now call streams. With the understanding that the evidence I've seen is completely anecdotal, I'm seeing a lot less of that type of confusion in recent years than I saw decades ago. Instead, most of the confusion I see appears to be the result of intentional actions on the part of those associated with documents or standing to benefit from incorrect perceptions of their documents. As Joel mentioned, we've not only seen Independent Stream Informational RFC mischaracterized as standards or "IETF documents", we've seen many Internet Drafts characterized that way. In particular, if a document that is attempting to mislead includes a reference that looks like, e.g., Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", IETF, April 1990, https://www.rfc-editor.org/rfc/rfc1149.txt Only a quite astute and knowledgeable observer will be able to deduce that this is an RFC rather than an I-D. To figure that out, is necessary to parse the URL. It is not clear that re-identifying it to, e.g., HaHa1149, also detectable only by parsing the URL, would improve the distinction between it and a standard either. Whether "IETF" in that reference is a lie gets back to the "what does IETF mean" topic that I mentioned earlier in this note, but someone who is trying to deceive is unlikely to look deeply into that distinction. IMO, that makes a precise problem statement very important. If the issue is to correct, reduce, or eliminate confusion in which everyone involved is well-intentioned, there is little evidence that there is a significant problem left to solve (there might be, but there is little evidence and you certainly cannot rely on RFC 1796). If it is to eliminate or significantly reduce confusion that is introduced, more or less deliberately, for marketing or other purposes, we do have evidence that the problem may not be worth solving unless the solutoin somehow addresses the I-D issue as well. best, john From nobody Tue Jul 3 09:58:55 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB21B130934 for ; Tue, 3 Jul 2018 09:58:52 -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] 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 8p9XBuusd-ts for ; Tue, 3 Jul 2018 09:58:51 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 E840112D949 for ; Tue, 3 Jul 2018 09:58:50 -0700 (PDT) Received: from [10.32.60.80] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w63GwebK038271 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 3 Jul 2018 09:58:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.80] From: "Paul Hoffman" To: rfcplusplus@ietf.org Date: Tue, 03 Jul 2018 09:58:46 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: <4A738031-61DC-42B9-ACB4-6785035EBF29@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Rfcplusplus] Outlining the experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:58:53 -0000 On 3 Jul 2018, at 0:32, Martin Thomson wrote: > 1. What is the problem? > > I think that the problem is well understood. The common perception of > "RFC" encompasses a far simpler notion than the reality. > > The debate seems to be centred more on the question of whether this - > of the multitude of problems that we might tackle - is the one that is > worth addressing. The accompanying question that many of us keep asking is: what are the negative effects of this problem? Are they even worth addressing if the cost of the experiment is high? So far, we've heard the main place where the problem appears is with customer requirements of vendors for things that are in RFCs that are not standards. 1) Vendor A might be losing sales to Vendor B because the latter includes support for things in RFCs that are not standards. 2) Vendor A's influential customer is demanding that they add support for something in an RFC that is not on standards track. Neither of these should be that important to the IETF or the RFC Series. Vendor A has a responsibility to educate its potential customers about its products and the features in them. That education inherently involves explaining things about RFCs beyond just "is it a standard", particularly about which SHOULD-level requirements were not implemented, and how interoperability with other vendors who also implement that RFC has been tested. Unless someone can show that the negative effects of the mis-perceptions that we have been handling just fine for 25 years are significant, there is no reason to try any experiment that might have negative effects if the experiment fails. As other folks discussing this draft have pointed out, there are plenty of long-term negative effects of backing out of this experiment. --Paul Hoffman From nobody Tue Jul 3 11:14:49 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A166130DC7 for ; Tue, 3 Jul 2018 11:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 9rzeW0eE3mcM for ; Tue, 3 Jul 2018 11:14:43 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 D4F2212E039 for ; Tue, 3 Jul 2018 11:14:42 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id r16-v6so5708709oie.3 for ; Tue, 03 Jul 2018 11:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fTbfQ8cbONS69hJh5gyCewYiPk/gCHyIzuyuNkjIkjU=; b=lVoLvz6hh/r+WCq5L4IXQqxjeX0/gwfNS59de6d1gP84+JH0GcTudPmrCYe5ocqC5A q3A/Wqsos3GtTA4iAbMqq/2xUSsKVgZzvCczyYRCjxYqZlmzqZdp1J+Pz0AfI1rxQoDf Zsg6bRMvZGjZB57eteCllarxgwG1vfvzjaYAHJMhfx6dm2RxmPQqQyPLhHTy+BZyyYMG Mb3ZvdUyMZ8SULxzQhKkXRto/X4JvnuAaAjh2RjuGgOHpU+N5ZmD/BpXTAi9HavPay53 NZOTIGubhrtezaqFEbI/M2sVge0gs7tv55/24hiHjq+Fnp9PfbYELFUZ2raaOLX3CrQS CrBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fTbfQ8cbONS69hJh5gyCewYiPk/gCHyIzuyuNkjIkjU=; b=EFHbCT7TDZLdf5ZwQ4l7IuH9H/OAidQ1h6MUIAVVAQOqxSonRnx72M94SZ5wIYO4n2 M36pXGOrtqT2yewAci6uUg1rWxd+hi4rjjnjFurx6hY6Wai1MqUEc15wz34YClSq3pp+ gt/bvQInpmxx/gVr6/Iy78NCASkXjZnD7DknXxbJGZFZtIU26ipVhIVicOlN0qTsy+xs t3N12GkzZ2zztGkGjYUPH/MZEq3jp8wKkb91GBXIv453r3cy1uP6zP1bn4nNtxAHa2m2 9SdlD5s3Sqg5MSzII88JZhCqti6x2XcV5cS/LtaJj09onR9iAkEvW0o/77vRSSKfFzde Q5kg== X-Gm-Message-State: APt69E3+CTWu5Hn2s8i91iGUBuMB8bXrRga6dcxG1tFeVKCDexlp18EE gPxdNmklrCfgWsSaqN1MrIppilbq0hRA18qDtjM= X-Google-Smtp-Source: AAOMgpevklwnekpSEjAYKCluafaw/ou4LZpG40Ebw/CQiyEd1MbIs0Q+37Shln4URmcasQkzunbytjDzNkqFBGYIJcA= X-Received: by 2002:aca:dec6:: with SMTP id v189-v6mr582544oig.98.1530641682128; Tue, 03 Jul 2018 11:14:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c2:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 11:14:21 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 3 Jul 2018 14:14:21 -0400 Message-ID: To: Brian E Carpenter Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000bde42605701c49f1" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 18:14:47 -0000 --000000000000bde42605701c49f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not only am I in complete agreement with everything that Brian has said here, but I would like to add that section 5 makes this draft one of the most cynical documents I have read in a very long time. It makes the inference that one of the primary reasons people publish non-standards-track RFCs is to DELIBERATELY TAKE ADVANTAGE of any confusion in the reader=E2=80=99s mind regarding the status of RFCs. By measuring =E2= =80=9Csuccess=E2=80=9D as a reduction in the rate of non-standards-track documents once they=E2=80= =99re no longer labelled =E2=80=9CRFC=E2=80=9Ds, the draft implies that the current = rate of non-standards-track RFCs is ONLY because they are being published as =E2=80=9CRFC"s. I find this cynical in the extreme, and insulting to curren= t and past non-standards-track RFC authors, and would object to any such =E2=80=9Cexperiment=E2=80=9D just on those grounds. Cheers, Andy On Tue, Jul 3, 2018 at 4:14 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > My main comment on this draft is that it proposes an experiment > without first explaining properly what the problem is and why the > proposed experiment might fix it. > > It isn't sufficient to say there is misunderstanding of the > various RFC types and statuses. It isn't sufficient to give a > couple of examples of non-IETF-standard RFCs that might be > implemented and deployed in parallel with IETF standards. > Where is the damage to users, where are the numbers, how do > we assess the seriousness of the damage? Isn't it sometimes > better to have multiple solutions? Isn't it *always* better > to document something which is deployed, whether it's good > or bad? Isn't the IETF solution sometimes wrong? How much of > the perceived problem is just a matter of damaged pride? How > does this problem compare with others that have been known about > for just as long? Why is this one worth solving (disruptively) > when the others aren't? > > Right now I just don't see a problem statement that answers those > questions. > > I'm tempted to stop there, but here are some more detailed > comments: > > > RFC 1796 [RFCS] was published in April of 1995. At that time, it was > > clear that there was an "regrettably well spread misconception" that > > the label "RFC" implied "some level of recognition". > > True. Also at that time (in fact a few months before, since the > RFC Editor had already reacted), the RFC boilerplate was modified > to avoid misconception for anyone who bothered to read it. > > > Not a lot has > > changed in the 23 years since that statement. > > Evidence, please. > > I'd say that the evidence is that people don't take much notice > of the label and the boilerplate; they go straight to the text. > (OK, insert the obligatory anecdote of Avian Carriers being cited > in an RFP, but one swallow doesn't make a summer.) > > > The common perception of the significance of the "RFC" label is > > simple. > > That may be so, but since the draft doesn't state what that > perception is, the reader cannot guess what is intended. > > For example, my perception of the significance is that an RFC > is a request for comments. Then I look for its status. Then > I look for its contents. Isn't that what we should assume serious > engineers & product managers do? > > > This document suggests that this view to some degree underestimates > > the value of a label (or "brand"). > > Or, equally plausibly, it overestimates the value of the label. > My belief is that, the occasional dishonest salesman apart, it's > the content that people value. If they know anything, they know > that *all* RFCs have had genuine peer review. (Unlike many > academic papers, see "Some science journals that claim to peer > review papers do not do so", The Economist, June 23, 2018.) > > > This document proposes an > > experiment that limits the use of the "RFC" label to the product of > > that process. > > I have to re-iterate that this is not a choice the IETF can make, > since the IETF and its committees do not own the RFC series. The > IETF can't kick the other streams out. > > > Capturing the nuance required to properly understand a protocol is > > difficult, and a large number of documents fail to properly convey > > that status. > > Correct. However, this is a hard problem that the IETF has > essentially refused to solve, because the solution is hard > work, both for WGs and for the IESG. > draft-klensin-std-numbers and draft-ietf-newtrk-sample-isd > were both put in the "too hard" bucket by previous IESGs, > for example. > > > ZRTP [RFC6189] was published as an informational RFC on > > the IETF stream after the IETF reached consensus to develop DTLS-SRTP > > [RFC5764] for the same use case. > > The document makes no claim to be a standard and it gives some > explanation of how it differs from RFC5764. It isn't clear > to me what is unclear to the reader. > > > HTTP Live Streaming (HLS) [RFC8216] was published on the > > Independent Submissions Stream in defiance of a standardized > > protocol, MPEG-DASH [DASH] > > The word "defiance" seems quite inappropriate. Firstly, the RFC > doesn't mention MPEG-DASH at all. Secondly, the document makes > no claim whatever to be a standard. > > > Both describe de-facto standards, each of which are implemented in > > more than one product and deployed. > > Right. It has long been considered a good idea to document stuff that > is widely deployed, for everybody's benefit. > > > Each captures a range of design decisions that differ from the > > commonly-accepted view. > > How often in the history of engineering has "the commonly-accepted > view" turned out to be wrong? How often in the history of the > Internet has something unexpected turned out to be a winner? > > > If nothing else, the deployment of these protocols > > could adversely affect interoperability relative to implementations > > of their more widely accepted alternatives. > > That's true, of course, but the Internet has always worked by > survival of the fittest. I'm not seeing a tragedy here. > > > Information about the status of the document is contained entirely in > > the "Status of this Note" section. For instance, ZRTP is published > > with IETF consensus, so the significance of it not being an "Internet > > Standards Track specification" is easily lost. > > Easily if you don't read the words, yes. > > > That it also limits > > its mention of DTLS-SRTP to comparative criticisms makes it possible > > to interpret the document as it represents itself: a newer, superior > > technique. > > Yes, the authors believe that their way is better. That's > hardly a surprise. > > > There are numerous examples of RFCs that make an honest > > representation of their status in more than just the boilerplate. > > Indeed. And this is an aspect that peer reviewers should look > out for. > > > So why is the publication of an RFC so keenly sought, when the > > document doesn't capture the output of the Internet Standards > > Process? > > I don't know. Did you try asking the authors? Speculation > doesn't help us much. For my own independent submissions, > it's because it's the appropriate way to reach the Internet > technical community in general (not just the IETF as you > suggest), and another motivation is to get constructive review > (as opposed to the essentially random or sometimes bogus review > you get from academic journals and conferences). Most of the > Internet technical community doesn't read academic journals, by > the way: apart from anything else they're too expensive, and > most of the articles are too... academic. > > > This documents proposes reserving the "RFC" label for those documents > > that are the product of the Internet Standards Process [RFC2026]. > > And again, in case anybody missed it: the IETF can't do > that because it doesn't own the RFC Series. > > What the IETF can do is change the requirements for its own > stream of RFCs, or stop calling its documents RFCs at all. > > The second one is a terrible idea, for reasons I gave at > https://tools.ietf.org/html/draft-carpenter-request-for- > comments-00#section-4 > > The first one is absolutely reasonable, and a good > first step is at > https://tools.ietf.org/html/draft-klensin-std-numbers-02 > With the right typography in the new RFC format, this > could be very effective. > > > 4.1. New Labels for Other Documents > > This section is ambiguous. But most of it is out of IETF > scope anyway, because the other users of the RFC series > will label their RFCs as they wish. I wouldn't be against > the header lines being more explicit. > > > The "STD" label hasn't been especially effective in distinguishing > > those documents that attain the rare status of Full Internet > > Standard. The BCP subseries has been more effective, perhaps because > > of the greater familiarity of its primary audience with its meaning. > > Exactly why we should apply the STD series label to *all* standards > track documents, as proposed many years ago and more than once since then= . > (Also why I'm a fan of > https://tools.ietf.org/html/draft-loughney-newtrk-one-size-fits-all-01 ) > > > However, the choice of rendering is not > > part of the canonical XML document. Alternative renderings could > > legitimately erase that information. > > They could drop special choices of font & font size, true, but they > couldn't drop the actual status etc. if it's part of the document > text. In any case, most people will use and refer to the primary > HTML rendering, which the RFC Editor will generate. > > > That leads to the conclusion that clearer marking for status, while > > possibly helpful, would not be sufficiently effective in addressing > > the problem. > > That may in fact be true, since the fundamental problem is that humans > see what they want to see, and readily skip boring stuff like document > labels and status. This leads to the conclusion that adjusting the labels > won't address the perceived problem: if people have a good reason to > ignore today's labels, they will ignore tomorrow's as well. > > > A term of 3 years is proposed as being long enough to provide enough > > evidence to assess the effect of a change of labels. > > I question whether that's long enough. Some product cycles are faster, > but many are slower than that. How many cases per year do we have > of RFC-label-confusion causing significant problems to users? Unless > that's a large number, and we can use those cases to assess the time lag > between RFC publication and the occurrence of problems for users, > I really don't know how long a test would be needed. > > (The proposed metrics about publication rates are pretty useless > except perhaps for a sociologist, because they don't seem to > be relevant to the alleged problem. And in any case, as noted, > the datasets will be tiny and most of what we'll see will be > statistical noise.) > > > 6. Security and Privacy Considerations > > > > It is believed that there are none. > > Given how many of the Independent Series RFCs are about > crypto algorithms and the like, potentially interfering with > that publication channel seems to pose a risk. > > Regards > Brian Carpenter > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --000000000000bde42605701c49f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not only am I in complete agreement with everything that B= rian has said here, but I would like to add that section 5 makes this draft= one of the most cynical documents I have read in a very long time. It make= s the inference that one of the primary reasons people publish non-standard= s-track RFCs is to DELIBERATELY TAKE ADVANTAGE of any confusion in the read= er=E2=80=99s mind regarding the status of RFCs. By measuring =E2=80=9Csucce= ss=E2=80=9D as a reduction in the rate of non-standards-track documents onc= e they=E2=80=99re no longer labelled =E2=80=9CRFC=E2=80=9Ds, the draft impl= ies that the current rate of non-standards-track RFCs is ONLY because they = are being published as =E2=80=9CRFC"s. I find this cynical in the extr= eme, and insulting to current and past non-standards-track RFC authors, and= would object to any such =E2=80=9Cexperiment=E2=80=9D just on those ground= s.

Cheers,
Andy


On Tue, Jul 3, 2018 a= t 4:14 AM, Brian E Carpenter <brian.e.carpenter@gmail.com>= ; wrote:
Hi,

My main comment on this draft is that it proposes an experiment
without first explaining properly what the problem is and why the
proposed experiment might fix it.

It isn't sufficient to say there is misunderstanding of the
various RFC types and statuses. It isn't sufficient to give a
couple of examples of non-IETF-standard RFCs that might be
implemented and deployed in parallel with IETF standards.
Where is the damage to users, where are the numbers, how do
we assess the seriousness of the damage? Isn't it sometimes
better to have multiple solutions? Isn't it *always* better
to document something which is deployed, whether it's good
or bad? Isn't the IETF solution sometimes wrong? How much of
the perceived problem is just a matter of damaged pride? How
does this problem compare with others that have been known about
for just as long? Why is this one worth solving (disruptively)
when the others aren't?

Right now I just don't see a problem statement that answers those
questions.

I'm tempted to stop there, but here are some more detailed
comments:

> RFC 1796 [RFCS] was published in April of 1995.=C2=A0 At that time, it= was
> clear that there was an "regrettably well spread misconception&qu= ot; that
> the label "RFC" implied "some level of recognition"= ;.

True. Also at that time (in fact a few months before, since the
RFC Editor had already reacted), the RFC boilerplate was modified
to avoid misconception for anyone who bothered to read it.

> Not a lot has
> changed in the 23 years since that statement.

Evidence, please.

I'd say that the evidence is that people don't take much notice
of the label and the boilerplate; they go straight to the text.
(OK, insert the obligatory anecdote of Avian Carriers being cited
in an RFP, but one swallow doesn't make a summer.)

> The common perception of the significance of the "RFC" label= is
> simple.

That may be so, but since the draft doesn't state what that
perception is, the reader cannot guess what is intended.

For example, my perception of the significance is that an RFC
is a request for comments. Then I look for its status. Then
I look for its contents. Isn't that what we should assume serious
engineers & product managers do?

> This document suggests that this view to some degree underestimates > the value of a label (or "brand").

Or, equally plausibly, it overestimates the value of the label.
My belief is that, the occasional dishonest salesman apart, it's
the content that people value. If they know anything, they know
that *all* RFCs have had genuine peer review. (Unlike many
academic papers, see "Some science journals that claim to peer
review papers do not do so", The Economist, June 23, 2018.)

> This document proposes an
> experiment that limits the use of the "RFC" label to the pro= duct of
> that process.

I have to re-iterate that this is not a choice the IETF can make,
since the IETF and its committees do not own the RFC series. The
IETF can't kick the other streams out.

> Capturing the nuance required to properly understand a protocol is
> difficult, and a large number of documents fail to properly convey
> that status.

Correct. However, this is a hard problem that the IETF has
essentially refused to solve, because the solution is hard
work, both for WGs and for the IESG.
draft-klensin-std-numbers and draft-ietf-newtrk-sample-isd
were both put in the "too hard" bucket by previous IESGs,
for example.

> ZRTP [RFC6189] was published as an informational RFC on
> the IETF stream after the IETF reached consensus to develop DTLS-SRTP<= br> > [RFC5764] for the same use case.

The document makes no claim to be a standard and it gives some
explanation of how it differs from RFC5764. It isn't clear
to me what is unclear to the reader.

> HTTP Live Streaming (HLS) [RFC8216] was published on the
> Independent Submissions Stream in defiance of a standardized
> protocol, MPEG-DASH [DASH]

The word "defiance" seems quite inappropriate. Firstly, the RFC doesn't mention MPEG-DASH at all.=C2=A0 Secondly, the document makes no claim whatever to be a standard.

> Both describe de-facto standards, each of which are implemented in
> more than one product and deployed.

Right. It has long been considered a good idea to document stuff that
is widely deployed, for everybody's benefit.

> Each captures a range of design decisions that differ from the
> commonly-accepted view.

How often in the history of engineering has "the commonly-accepted
view" turned out to be wrong? How often in the history of the
Internet has something unexpected turned out to be a winner?

> If nothing else, the deployment of these protocols
> could adversely affect interoperability relative to implementations > of their more widely accepted alternatives.

That's true, of course, but the Internet has always worked by
survival of the fittest. I'm not seeing a tragedy here.

> Information about the status of the document is contained entirely in<= br> > the "Status of this Note" section.=C2=A0 For instance, ZRTP = is published
> with IETF consensus, so the significance of it not being an "Inte= rnet
> Standards Track specification" is easily lost.

Easily if you don't read the words, yes.

> That it also limits
> its mention of DTLS-SRTP to comparative criticisms makes it possible > to interpret the document as it represents itself: a newer, superior > technique.

Yes, the authors believe that their way is better. That's
hardly a surprise.

> There are numerous examples of RFCs that make an honest
> representation of their status in more than just the boilerplate.

Indeed. And this is an aspect that peer reviewers should look
out for.

> So why is the publication of an RFC so keenly sought, when the
> document doesn't capture the output of the Internet Standards
> Process?

I don't know. Did you try asking the authors? Speculation
doesn't help us much. For my own independent submissions,
it's because it's the appropriate way to reach the Internet
technical community in general (not just the IETF as you
suggest), and another motivation is to get constructive review
(as opposed to the essentially random or sometimes bogus review
you get from academic journals and conferences). Most of the
Internet technical community doesn't read academic journals, by
the way: apart from anything else they're too expensive, and
most of the articles are too... academic.

> This documents proposes reserving the "RFC" label for those = documents
> that are the product of the Internet Standards Process [RFC2026].

And again, in case anybody missed it: the IETF can't do
that because it doesn't own the RFC Series.

What the IETF can do is change the requirements for its own
stream of RFCs, or stop calling its documents RFCs at all.

The second one is a terrible idea, for reasons I gave at
https://tools.ietf.org/= html/draft-carpenter-request-for-comments-00#section-4

The first one is absolutely reasonable, and a good
first step is at
https://tools.ietf.org/html/draft-klens= in-std-numbers-02
With the right typography in the new RFC format, this
could be very effective.

> 4.1.=C2=A0 New Labels for Other Documents

This section is ambiguous. But most of it is out of IETF
scope anyway, because the other users of the RFC series
will label their RFCs as they wish. I wouldn't be against
the header lines being more explicit.

> The "STD" label hasn't been especially effective in dist= inguishing
> those documents that attain the rare status of Full Internet
> Standard.=C2=A0 The BCP subseries has been more effective, perhaps bec= ause
> of the greater familiarity of its primary audience with its meaning.
Exactly why we should apply the STD series label to *all* standards
track documents, as proposed many years ago and more than once since then.<= br> (Also why I'm a fan of
https://tools.ietf.org/html/draft-loughney-newtrk-one-size-fits-all-01 )

> However, the choice of rendering is not
> part of the canonical XML document.=C2=A0 Alternative renderings could=
> legitimately erase that information.

They could drop special choices of font & font size, true, but they
couldn't drop the actual status etc. if it's part of the document text. In any case, most people will use and refer to the primary
HTML rendering, which the RFC Editor will generate.

> That leads to the conclusion that clearer marking for status, while > possibly helpful, would not be sufficiently effective in addressing > the problem.

That may in fact be true, since the fundamental problem is that humans
see what they want to see, and readily skip boring stuff like document
labels and status. This leads to the conclusion that adjusting the labels won't address the perceived problem: if people have a good reason to ignore today's labels, they will ignore tomorrow's as well.

> A term of 3 years is proposed as being long enough to provide enough > evidence to assess the effect of a change of labels.

I question whether that's long enough. Some product cycles are faster,<= br> but many are slower than that. How many cases per year do we have
of RFC-label-confusion causing significant problems to users? Unless
that's a large number, and we can use those cases to assess the time la= g
between RFC publication and the occurrence of problems for users,
I really don't know how long a test would be needed.

(The proposed metrics about publication rates are pretty useless
except perhaps for a sociologist, because they don't seem to
be relevant to the alleged problem. And in any case, as noted,
the datasets will be tiny and most of what we'll see will be
statistical noise.)

> 6.=C2=A0 Security and Privacy Considerations
>
>=C2=A0 =C2=A0 It is believed that there are none.

Given how many of the Independent Series RFCs are about
crypto algorithms and the like, potentially interfering with
that publication channel seems to pose a risk.

Regards
=C2=A0 =C2=A0Brian Carpenter


_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus

--000000000000bde42605701c49f1-- From nobody Tue Jul 3 11:29:33 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFF6130DC3 for ; Tue, 3 Jul 2018 11:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 uGZhFks0qpqp for ; Tue, 3 Jul 2018 11:29:28 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A938012E039 for ; Tue, 3 Jul 2018 11:29:28 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id w126-v6so5769020oie.7 for ; Tue, 03 Jul 2018 11:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eadSZR3OO36cl/FrYaJdASw8nayc5CoiftHjaV38pKo=; b=jUAm5JAxCaDQl9rtyZDNo3lCluAPMCQzCR806Bhg3XFPc9PASkCQOfuSNxgH3lSZjI 0AJG/dvs8bmyYHtYCLXAMv4OymYa+0wTLpN8pULtWvMCx8vK350rSCCRavAKGe6djbpL LbGGguGItafFAv0byrfTRRkJLBmUrs4nz76BVr/Ggsg+Ez6p11Ltmwl2TI82/dor0cWf B6lYHI2z3u4/3dlPBp0UE8Q5drHUzuVVCf7diXnlbJn8UWJQoMvuwpsfrDYl+UJkc6kq 03JX1JY8G5m3UVd/R8BxHpnyDFwQeR8jq7DR2Y46HISput1JvhOWTogfHuP+5sEwTRo4 FiMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eadSZR3OO36cl/FrYaJdASw8nayc5CoiftHjaV38pKo=; b=IHYzOtv5lBkSOYV+wCL4g8zYzJOsWHGrztn0wqz8v8GwN0QO2WxQUHiQ1vUcaA5/JX iACqVBk0OjTCrVIj09umRjOHKpdgFcdbZZbky2IksLsqizqN/M2oKyJ3IcXyz0ZIyc1D ijkg6q3wNozSEh/8wyXMP6aftBzKqc4sVvr6lvQbpdZ3hKLZfGJeBP2ZxSLGxS8+mYEO wh3H6FW2HR0rGOmP4iZeDQ61N3BePRtkZIW2ggzNKAM/hXglpDg9qJxAdiz2b2dzFp6q OOgXbQ92bHZezHnIa5pqsYlkw66/t+BW+sIQ0eu5Y4l1X9bLOvmXyYfSgb6i7g7ibJ79 lmUQ== X-Gm-Message-State: APt69E2L7QNt/DxibtZU5hVi5uZPzOeYy5PvmdFDzb9X162qyPSz3JAo KfeTPM2CGxGl0TDfxR5xWUU63My7QUfs5dj1Jfce/Q== X-Google-Smtp-Source: AAOMgpeNc+bHBmi1qpS0nul8buaro5BkV0kiIQRKjrXkFARyyH00gQRknpSJQza7xQstLynh9aqopEfFs4Yr+XMx0lQ= X-Received: by 2002:aca:190d:: with SMTP id l13-v6mr1196181oii.216.1530642567847; Tue, 03 Jul 2018 11:29:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 11:28:57 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Tue, 3 Jul 2018 11:28:57 -0700 Message-ID: To: "Andrew G. Malis" Cc: Brian E Carpenter , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000088e1f505701c7e32" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 18:29:32 -0000 --00000000000088e1f505701c7e32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2018 at 11:14 AM, Andrew G. Malis wrote: > Not only am I in complete agreement with everything that Brian has said > here, but I would like to add that section 5 makes this draft one of the > most cynical documents I have read in a very long time. It makes the > inference that one of the primary reasons people publish > non-standards-track RFCs is to DELIBERATELY TAKE ADVANTAGE of any confusi= on > in the reader=E2=80=99s mind regarding the status of RFCs. > That's not quite what the document says. Here's the text: One hypothesis this experiment proposes to test is the degree to which the "RFC" label motivates authors seeking publication. Though numbers are unlikely to provide a clear answer when so much of the problem is subjective, measuring the rate of submission and publication for affected documents could provide some insight. There are a variety of reasons that could go into that motivation; in some companies, as an example, publishing an RFC is rewarded financially in a way that an internal technical report is not. Joel has written on some of the difficulties in working out what to measure here, and I appreciate any consideration you can give to that; it's not an easy problem, but if there is no data to work from forward motion on the basis of anything other than impressionistic anecdotes will be difficult. regards, Ted --00000000000088e1f505701c7e32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 3, 2018 at 11:14 AM, Andrew G. Malis <agmalis= @gmail.com> wrote:
Not only a= m I in complete agreement with everything that Brian has said here, but I w= ould like to add that section 5 makes this draft one of the most cynical do= cuments I have read in a very long time. It makes the inference that one of= the primary reasons people publish non-standards-track RFCs is to DELIBERA= TELY TAKE ADVANTAGE of any confusion in the reader=E2=80=99s mind regarding= the status of RFCs.

That's not = quite what the document says.=C2=A0 Here's the text:
One hypothesis this experiment proposes to test is the degree to which the "RFC" label motivates authors seeking publication. = Though numbers are unlikely to provide a clear answer when so much of the problem is subjective, measuring the rate of submission and publication for affected documents could provide some insight. There are a variety of reasons that could go into that motivation; in= some companies, as an example, publishing an RFC is rewarded financially i= n a way that an internal technical report is not.=C2=A0

Joel has writt= en on some of the difficulties in working out what to measure here, and I a= ppreciate any consideration you can give to that; it's not an easy prob= lem, but if there is no data to work from forward motion on the basis of an= ything other than impressionistic anecdotes will be difficult.

regards,

Ted
--00000000000088e1f505701c7e32-- From nobody Tue Jul 3 11:46:49 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17474130F9F for ; Tue, 3 Jul 2018 11:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 EXOCs72P85nm for ; Tue, 3 Jul 2018 11:46:36 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E407130FB2 for ; Tue, 3 Jul 2018 11:46:36 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id m2-v6so5846635oim.12 for ; Tue, 03 Jul 2018 11:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wqCs23YaM3/FDZ7MxDWenvPt2X29B3ysk8BiyzcvxYs=; b=lXyXpBefiWnt6Yk14/pa3eajZ+07gA3kGMab5zctCAka+XnbwYHeNglntYlG2APeMo bTt0mQ4mqVKSXIFbyzbQWHqWRXzedDxGpJb3fwdUMFGxcpYQzFHFYG1HgzFfTYiCIDRj DAthu6NrPS2QpFvfKpcrmOctCU9zJSOvKWNQhEUcH9mJQUe/k+Cx0nRrshY2/wmNyZra LiI2xCooiVxGwVClw7JOwkU9rnUrXB+5LDIanEt6C/U1uKxSvf2T5AZfZS+RGHRXMQUZ YvCjx2wvyVxsdixYrVu4C9Zm7giyJVA0Jo/EEoq75ZsvxxHszauKomukXRfsCCTPBXho tCSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wqCs23YaM3/FDZ7MxDWenvPt2X29B3ysk8BiyzcvxYs=; b=mrkojB+OTRo7KTLWnDsuhoXYpij2HeubeD6vz2KwJcBoEb6VxWvJJWZyGRJ2+DfI2c EQDWwERtG1rSpryMrjYWs4Tp4auviiHpeYEK1v3gnMTy9pBGvtawhFoOvNfRLEawUlwb wc5VYgWz09PRq/aQg73ZNkIHYBS4c0EOkeQ4yiVpWVPXkUHXFyzEYGLFbPvRSZXBaFKi iTQILFSGonvyKgULKnECN7gArG7gM7ZW5RvawibUbaHJhoL4ly5VxoKqhytqGbxKHSIu U2Lja31W9CCJfqKPdoVBYR+5BVCajRAQb6q/gPZvaWP3LtIHVFTa0EuWt0Z97iBZXd2U 51Ug== X-Gm-Message-State: APt69E1mvp9yeTGKtAcMflRSig+JyHSZ1mCaikA3+MiOoBGSfsIC4qZH SuhgUiMdRAjy6GHG3Q+DAyiQ1u2CyVI3bd4JhSU= X-Google-Smtp-Source: AAOMgpdwHPzJeckvIK3XbBw2xe+WAzqnInq8o+/rHKizkPF+iiUh1x3EZc9QYPHur4dT08QpiigxM2HD1boY326c34Q= X-Received: by 2002:aca:f409:: with SMTP id s9-v6mr23437247oih.102.1530643595884; Tue, 03 Jul 2018 11:46:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c2:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 11:46:15 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 3 Jul 2018 14:46:15 -0400 Message-ID: To: Ted Hardie Cc: Brian E Carpenter , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000cf7ef405701cbb1d" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 18:46:47 -0000 --000000000000cf7ef405701cbb1d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ted, That is true, but the rest of the draft talks about the "common perception of the significance of the "RFC=E2=80=9D label=E2=80=9D, how =E2=80=9Cmisco= nceptions about the significance of publication as an RFC is [sic] commonplace.=E2=80=9D, and h= ow =E2=80=9Cthere are numerous examples of RFCs that make an honest representa= tion of their status=E2=80=9D, meaning there are some that do not. There is also "F= or the examples given, a principled reason for publication is well justified.=E2= =80=9D, again implying that there are unprincipled reasons for publication as well. I just just adding 1+1 to make 2. Regarding your example of authors being financially rewarded for RFC publication, I=E2=80=99m sure that would extend to any IETF publication typ= e if the IETF were to run this experiment, thus this particular publication motivation would be unaffected by the proposed experiment. Cheers, Andy On Tue, Jul 3, 2018 at 2:28 PM, Ted Hardie wrote: > On Tue, Jul 3, 2018 at 11:14 AM, Andrew G. Malis > wrote: > >> Not only am I in complete agreement with everything that Brian has said >> here, but I would like to add that section 5 makes this draft one of the >> most cynical documents I have read in a very long time. It makes the >> inference that one of the primary reasons people publish >> non-standards-track RFCs is to DELIBERATELY TAKE ADVANTAGE of any confus= ion >> in the reader=E2=80=99s mind regarding the status of RFCs. >> > > That's not quite what the document says. Here's the text: > > One hypothesis this experiment proposes to test is the degree to > which the "RFC" label motivates authors seeking publication. Though > numbers are unlikely to provide a clear answer when so much of the > problem is subjective, measuring the rate of submission and > publication for affected documents could provide some insight. > > There are a variety of reasons that could go into that motivation; in som= e > companies, as an example, publishing an RFC is rewarded financially in a > way that an internal technical report is not. > > Joel has written on some of the difficulties in working out what to > measure here, and I appreciate any consideration you can give to that; it= 's > not an easy problem, but if there is no data to work from forward motion = on > the basis of anything other than impressionistic anecdotes will be > difficult. > > regards, > > Ted > > --000000000000cf7ef405701cbb1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ted,

That is true, but the rest of the = draft talks about the "common perception of the significance of the &q= uot;RFC=E2=80=9D label=E2=80=9D, how =E2=80=9Cmisconceptions about the sign= ificance of publication as an RFC is [sic] commonplace.=E2=80=9D, and how = =E2=80=9Cthere are numerous examples of RFCs that make an honest representa= tion of their status=E2=80=9D, meaning there are some that do not. There is= also "For the examples given, a principled reason for publication is = well justified.=E2=80=9D, again implying that there are unprincipled reason= s for publication as well.

I just just adding 1+1 = to make 2.

Regarding your example of authors being= financially rewarded for RFC publication, I=E2=80=99m sure that would exte= nd to any IETF publication type if the IETF were to run this experiment, th= us this particular publication motivation would be unaffected by the propos= ed experiment.

Cheers,
Andy

On = Tue, Jul 3, 2018 at 2:28 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Tue, Jul 3, 2018 at 11:14 AM, Andrew G. Malis <agmalis@gmail.com&= gt; wrote:
Not= only am I in complete agreement with everything that Brian has said here, = but I would like to add that section 5 makes this draft one of the most cyn= ical documents I have read in a very long time. It makes the inference that= one of the primary reasons people publish non-standards-track RFCs is to D= ELIBERATELY TAKE ADVANTAGE of any confusion in the reader=E2=80=99s mind re= garding the status of RFCs.

T= hat's not quite what the document says.=C2=A0 Here's the text:
<= /div>
   One hypothesis this experiment proposes to test is the de=
gree to
   which the "RFC" label motivates authors seeking publication.  =
Though
   numbers are unlikely to provide a clear answer when so much of the
   problem is subjective, measuring the rate of submission and
   publication for affected documents could provide some insight.
There are a variety of reasons that could go into that motivation; in= some companies, as an example, publishing an RFC is rewarded financially i= n a way that an internal technical report is not.=C2=A0

Joel has writt= en on some of the difficulties in working out what to measure here, and I a= ppreciate any consideration you can give to that; it's not an easy prob= lem, but if there is no data to work from forward motion on the basis of an= ything other than impressionistic anecdotes will be difficult.

regards,

Ted

--000000000000cf7ef405701cbb1d-- From nobody Tue Jul 3 11:51:24 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C14F130DE8 for ; Tue, 3 Jul 2018 11:51:21 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 2N2eVhWOU8ZR for ; Tue, 3 Jul 2018 11:51:17 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 CBE36130DE7 for ; Tue, 3 Jul 2018 11:51:17 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id w126-v6so5892504oie.7 for ; Tue, 03 Jul 2018 11:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uZA8C/Rd7kIexLIT8oczVXGd6af9jaO/BDzbaqglZHI=; b=a3ih6xxW5qqUbWKqwczYCOPH6i0UfWfXO160jrkz42rIaNXCMHyyfiY6G/tpkdGTMX 8aR+QcU3IHbZOatxtl5SFUkAG7fOEa1ZN5fJeiMQXcX1t5BfU/pptinwlRRogmYbChNy U/h5C5i6rFXuryASmznPZt2zVoWOAR6fccnSFgK9hA35AAu3uc+VY5+RsreTqwhCXtMd tZCyzmbh4Jh038X1e5JQMf7isxtZGaSAcfkb7uuOAqPRZEWEhnMhYRibc5GwL9CMP4/C xc5KMpD4HQHp8Ff4CKl7OJ8Lf57ywvAbtV4bSfmYrlW/+CJb/cEJWJwcPGypeT/w+74U H0Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uZA8C/Rd7kIexLIT8oczVXGd6af9jaO/BDzbaqglZHI=; b=tz8vWNvuXXGEjNIsh5oxEOcVtP6iu5I+dYjH9JUiDnZJFLuZZWJBft0gbtu1+Y/5M6 A4MlEbyBq/Cz4fsTHalYTG3NkYMKoTGRH76B7YCwiw56hQUycLLIk9AJ/X8VaeNatY8i uSsFWcB35sioiIBOBnypLDerEBY3CPD9l5wrvjfthGuciBSWLWv6uUT9i6y/lhe9FphL W/Y8Y3jGBi2Y+3BervYCnhXiMqcK6jEQn4mF1a66TnMy9GnmPDGHhObD2jel798x+fgX YFJns2Lo2nQQy35l2ARU0IpJ7ygX/8P+GkZX2OY072ANDU3HSKlEo4C+E4AVi8+AMXfD +C1w== X-Gm-Message-State: APt69E0GO7HGp3yQnfWGp8CzCs6x/1oDh4wtmmqPbQOyNKQbjZYlV3A5 OW8r/cg033I4Yzys8W/TkO0AIZCC5c4/2uxa5mY= X-Google-Smtp-Source: AAOMgpe8IJeQv50M2mvM/6WKqsDGilgOpjbnOvbnzNXAHl/SUmpoA24xYdIl1h/IFn1ELUVfPbimTwMkCroxyGCeL7E= X-Received: by 2002:aca:a806:: with SMTP id r6-v6mr23017193oie.213.1530643877252; Tue, 03 Jul 2018 11:51:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:7ad0:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 11:50:36 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Tue, 3 Jul 2018 14:50:36 -0400 Message-ID: To: Ted Hardie Cc: "Andrew G. Malis" , rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 18:51:22 -0000 On Tue, Jul 3, 2018 at 2:28 PM, Ted Hardie wrote: > On Tue, Jul 3, 2018 at 11:14 AM, Andrew G. Malis wrot= e: >> >> Not only am I in complete agreement with everything that Brian has said >> here, but I would like to add that section 5 makes this draft one of the >> most cynical documents I have read in a very long time. It makes the >> inference that one of the primary reasons people publish non-standards-t= rack >> RFCs is to DELIBERATELY TAKE ADVANTAGE of any confusion in the reader=E2= =80=99s mind >> regarding the status of RFCs. > > > That's not quite what the document says. Here's the text: > > One hypothesis this experiment proposes to test is the degree to > which the "RFC" label motivates authors seeking publication. Though > numbers are unlikely to provide a clear answer when so much of the > problem is subjective, measuring the rate of submission and > publication for affected documents could provide some insight. Section 4 talks about the meaning of RFC, but this is written as the meaning to the author of this draft perhaps? Here's the text and the rest of the section follows suit with the authors idea of what RFC means without stating it: Reserving the RFC Series for the publication of products of the Internet Standards Process would ensure clarity about what "RFC" means. RFC expands to Request For Comments. I don't see why we wouldn't want to receive comments on experimental or informational drafts as well as for ISE, IRTF, and IAB stream documents. Comments on ISE or IRTF RFCs could lead to additional work that may generalize work for broader applicability (vendor specific, narrow use case supported, crypto algorithms, applications of research to develop supporting protocols, etc.). The author seems to take RFC to mean blessed standard. That's an argument for using STD in addition to RFC and making that work to solve the problem. The idea behind RFCs is important to collaborative work and the work style of the IETF. STD hasn't been effective as many don't bother to take the time to change the status on documents. Put a concerted effort around that with a design team and I think we'd have a valuable experiment. Additionally, why don't we make it easier to publish documents as STD from the start? That's a key difference with BCP, there is no separate step to get this designation. If there are 2 interoperable implementations at time of publication, why not have an STD assigned? Errata can still be verified. Right now, it runs through the publication process again and errata is included, this adds extra work that may be part of the reason this is not used more. People have also pushed back on doing this forklift to help with perception. It seems it could have the desired impact to meet the stated goals in this draft. Responding here as I also agree there is bias in the document. In section 5, why is the number of documents published important to this experiment if the objective is about clarity on streams? These seem to be different objectives. Best regards, Kathleen > > There are a variety of reasons that could go into that motivation; in som= e > companies, as an example, publishing an RFC is rewarded financially in a = way > that an internal technical report is not. > > Joel has written on some of the difficulties in working out what to measu= re > here, and I appreciate any consideration you can give to that; it's not a= n > easy problem, but if there is no data to work from forward motion on the > basis of anything other than impressionistic anecdotes will be difficult. > > regards, > > Ted > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --=20 Best regards, Kathleen From nobody Tue Jul 3 12:06:18 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9602C130DC0 for ; Tue, 3 Jul 2018 12:06:16 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 9FUcfqhgimRD for ; Tue, 3 Jul 2018 12:06:14 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CEF1271FF for ; Tue, 3 Jul 2018 12:06:14 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id s12-v6so3436386wmc.1 for ; Tue, 03 Jul 2018 12:06:14 -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=vorLjb/yl5G4J61EOCPCh8dTmvmPycHkXqUaQNXiTtg=; b=pOPnSWbzW7mBlP3mTspxHS1qH5xwNRn6oj9wwR9NnM6SVXgi6Ik4qCD0H4IN+PjMf8 gbda5AiNotkK4jR+w0MXcJliBGIeAUZUbP3NCsd3TLl3zYk3iegEj7CLz+5AaxrXhihB Gyb7Js/eZosvTCCR1kYq2JIgVO2F9FpY7B6/KyytDKtJcX2LfdfStswJE4ZMuKloHv6I jfN6qYDTwtMpi4vcLh2ktEG/9NHFIZRlBzSccj8soBkZWZRHhQac3SYaoLwJ14elnH/2 KconYxG1zJjEsD+KGtiCg+s2+CqyTWUNQU3pMGCNt1gZpQE5D3rIYCMLwdqEQPw+wTni 1R+A== 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=vorLjb/yl5G4J61EOCPCh8dTmvmPycHkXqUaQNXiTtg=; b=PmbRKFVm0svAC4KzXjDaBlbqIjPfrLbBBlY/BK5w2xF6r0YcK8eTEodnH1NOUnqNj2 tVsTPhU6jSWdbOY5uS/RtAu6rSzy4DuIReDzvuMzo7aEU8ep2NsTXnwB/R/WMdNDaqcr AZAp0kGgMuexN4Ta+BZJhEV8isrYWEgu8DtXg1rfF3ihNEHnnCCJe9uHWztb8gPq3f8S 0vZblu2EF7y/oHN5QAg1PZjSDfw6xRwsiGYijwoBd2gXQfZxauJYbV1G7PwgIEOEREHI oT0QM2n4W1SazY/H5Tyz2GO8URk4j3FvjbfY/rRE2UDhvcGKwE6bkvidLSIQg6ZfBo7r QaOA== X-Gm-Message-State: APt69E03pacn/IgUF9T68JVq2iI+gEcSWl0rvAIR4a/5AuQams4pvP7+ g6L0yCAE7WnONFEzLkfnvWwgT8Ug X-Google-Smtp-Source: AAOMgpe7s2mUAQB9HFGjUX2l6hUQPMf8KBFriSVZQ7v+WULTfVx2pYJHL1kpsoROYHdvrKCO5YRLDQ== X-Received: by 2002:a1c:7d58:: with SMTP id y85-v6mr11483443wmc.91.1530644772847; Tue, 03 Jul 2018 12:06:12 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id f133-v6sm2959654wme.42.2018.07.03.12.06.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 12:06:11 -0700 (PDT) From: Bob Hinden Message-Id: <775E9251-EDB7-4D13-87D4-B6018CC0BC20@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0C24E956-C9BD-4705-90BD-3C2205343436"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 3 Jul 2018 12:06:03 -0700 In-Reply-To: Cc: Bob Hinden , Brian Carpenter , rfcplusplus@ietf.org To: Ted Hardie References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 19:06:17 -0000 --Apple-Mail=_0C24E956-C9BD-4705-90BD-3C2205343436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ted, > On Jul 3, 2018, at 9:14 AM, Ted Hardie wrote: >=20 > On Tue, Jul 3, 2018 at 1:14 AM, Brian E Carpenter = wrote: > Isn't it *always* better to document something which is deployed, = whether it's good > or bad? >=20 > I believe that a number of your questions are ill-formed, and that the = one I highlight above illustrates this problem best. The question is = not "should X, which is deployed, be documented?", but "Should the RFC = Series contain the documentation for X, which is deployed?=E2=80=9D. My answer to this question is emphatically YES. It is useful the = Internet to publish deployed protocols in the RFC series. I also note that in a number of cases publishing an RFC for a deployed = protocol has led to that work being brought into the IETF and a new IETF = standard version was produced. I suspect that if this proposal goes = forward, we will see less of that. No one will know what an FOOnnn = means. Isn=E2=80=99t our real goal of our work to foster = Interoperability? Or do we only care about interoperability of = protocols on the IETF stream? What are we trying to do here? Are we trying to make the =E2=80=9Ctent=E2= =80=9D smaller, or make our =E2=80=9Ctent=E2=80=9D as big as possible? = This effort seems like the former. I had thought we were also trying = (via IASA 2.0) to make it easier to get more support for the IETF. = Moving work to other series that the larger community has never seen = before, will have exactly the opposite effect. Bob >=20 > If X was specified by the IETF, then the answer is yes, it should be = contained in the IETF stream of the RFC Series. In the small number of = cases where it was specified by the IRTF, then it should be contained by = the IRTF stream of the RFC Series. The IAB stream could also = theoretically produce an protocol specification that was deployed = (though current practice is to bring any work of that type back into the = IETF). Those streams are, in other words, set aside as publication = outlets for specific bodies. >=20 > The Independent stream is very different, in that the ISE is meant to = exercise editorial discretion for publication and clearly could not = publish documentation of everything deployed even if it were made = available to the stream for publication. To illustrate that = impossibility, note that there are approximately 2 million apps in the = Apple app store, according to published reports; just documenting which = ones used what variants of HTTPS *alone* would dwarf the output of the = ISE (240 pages in 2017 outside of April 1st RFCs, according to email = from Adrian). >=20 > Eliot's pointer earlier today to the FYI series is instructive--the = FYIs reused the RFC series in part because the distribution mechanism = was well understood and well developed: > There are several reasons why the FYIs are part of the larger RFC > series of notes. The formost reason is that the distribution > mechanisms for RFCs are tried and true. Anyone who can get an RFC, > can automatically get an FYI. More importantly, anyone who knows = of > the RFC series, can easily find out about the FYIs. >=20 >=20 > Given that there are many other distribution mechanisms available = today, we do not have to treat the RFC series as > the only place where such documentation can take place. > regards, > Ted > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --Apple-Mail=_0C24E956-C9BD-4705-90BD-3C2205343436 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAls7yRsACgkQrut0EXfn u6hYfggAn4zuTP2CDSpF74id3z1Le57VXqIN8bm8KfS05dV+tAHqKieXssDr0f+J fp4p2WBsxTrcPreu0R4//DrY27LyAUnGL/P5LryMA3Ny8fBl/qKwFt1AFv7UnEhE daGzTWvHCeWvkk+N1dMOaPR2LxPADdCjzWjhXaDJFVVafHuXeBi0+gG1olG5ZdCg pfSJ4xCZH4gwTwsB3zexM2jvT9yk9t4c22ICSsVgo8IGXSpzAm5rkD27SJFNjso3 SuYKbkVo5ozPZ0a7d+f8nWJX7mucx6v9X6YR6yTG1OUOBRh5DGZzeMzCeQMm0cIr naLOC7JzQdP3zBFvxO+fmgGbi6yypw== =OkwH -----END PGP SIGNATURE----- --Apple-Mail=_0C24E956-C9BD-4705-90BD-3C2205343436-- From nobody Tue Jul 3 12:48:53 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6F3130DFB for ; Tue, 3 Jul 2018 12:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 f_7PSKTshmjt for ; Tue, 3 Jul 2018 12:48:49 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 0FDE2130DF6 for ; Tue, 3 Jul 2018 12:48:49 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id w126-v6so6211839oie.7 for ; Tue, 03 Jul 2018 12:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C/FCBC8GxLMmySpffDDXT8D3Jo8TZlKe3UJclxopGFQ=; b=GA8Xx8GAK+2STc89hPcrNjJrnwOXD2PuaLZX3Ns36OajqrcOmcPgqu/xaY+JWrn1SV eDuCHpzB55xKhRh4rATf2qAJGgRkJNCH9no4Nwf8Eh0Js1/iL7JcLkvktRAio4yhlfbz 5FKTW+mEHXCbjVMDuq1ggSg59nmZUmEibf54ALCwcsjwV5nKCp34ISQslMnbL7G1yfAB DeyeCh1UT4lFaLePFE1hD7GeMdsmRA7AwcJ2I+hzxDGgHGzBhPhupmnT+1YaxsCoAG9Q /pKDxVRvHXbBdL1Trd2fkR3+QUsVL1zp5l47uqnnWySsf3Re1xVuehnZ44xw184op3Nd SnbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C/FCBC8GxLMmySpffDDXT8D3Jo8TZlKe3UJclxopGFQ=; b=NYCDMmw0N7B+uHgVF2qkP5YD9KrXIBUjYBiVxupM8souZghcU/6PCTSUo96wbap4s5 rvgRs7MJWFcFplqNSaMEmMqZHAaZY8ugaChayoP8X7rGaAMr1S2emVFQ85mAEeS9zGVL iGFc/mrQSi1DYOuk7xey+rGBzmkIsaZ5otkgDejBI/Emznp7+d2hbAOAbaUxP65xYs5a 1HUu+kYRnMx1W067dQRxITrFq/ywFmuNu69UhUck8yzI4MS7UkSrTvtwlwz7eAsJZIhW lDxrjE2PD/6ivd3DcZ3B/Sh9BBDRAwpinNYFVOpk+UWBed76siLDGAw7jElo/9VndOBS 57dA== X-Gm-Message-State: APt69E31blYXgL9Jr5zOlq9AFV70etNDGMTjimHBaijttFEtERnHiIAh XSMNQv6TlunogYPC+9xSxCpsnP7rEhqbf29y7U4= X-Google-Smtp-Source: AAOMgpcdIBHAv/swuUILBNdDHcUVlHRQVPtfXlkeGsHH+ROoMwlwmME7RdO9VtG6nw9oY0fKDQ8hwpkFy3SZJjjPHmc= X-Received: by 2002:aca:5f06:: with SMTP id t6-v6mr23389788oib.103.1530647328290; Tue, 03 Jul 2018 12:48:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 12:48:17 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Tue, 3 Jul 2018 12:48:17 -0700 Message-ID: To: "Andrew G. Malis" Cc: Brian E Carpenter , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000477cc805701d9a48" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 19:48:52 -0000 --000000000000477cc805701d9a48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2018 at 11:46 AM, Andrew G. Malis wrote: > Ted, > > That is true, but the rest of the draft talks about the "common perceptio= n > of the significance of the "RFC=E2=80=9D label=E2=80=9D, how =E2=80=9Cmis= conceptions about the > significance of publication as an RFC is [sic] commonplace.=E2=80=9D, and= how > =E2=80=9Cthere are numerous examples of RFCs that make an honest represen= tation of > their status=E2=80=9D, meaning there are some that do not. There is also = "For the > examples given, a principled reason for publication is well justified.=E2= =80=9D, > again implying that there are unprincipled reasons for publication as wel= l. > > I just just adding 1+1 to make 2. > > Regarding your example of authors being financially rewarded for RFC > publication, I=E2=80=99m sure that would extend to any IETF publication t= ype if the > IETF were to run this experiment, > Do you believe it would also be true for IRTF publications if the experiment were run? ISE publications? regards, Ted > thus this particular publication motivation would be unaffected by the > proposed experiment. > > Cheers, > Andy > > > On Tue, Jul 3, 2018 at 2:28 PM, Ted Hardie wrote: > >> On Tue, Jul 3, 2018 at 11:14 AM, Andrew G. Malis >> wrote: >> >>> Not only am I in complete agreement with everything that Brian has said >>> here, but I would like to add that section 5 makes this draft one of th= e >>> most cynical documents I have read in a very long time. It makes the >>> inference that one of the primary reasons people publish >>> non-standards-track RFCs is to DELIBERATELY TAKE ADVANTAGE of any confu= sion >>> in the reader=E2=80=99s mind regarding the status of RFCs. >>> >> >> That's not quite what the document says. Here's the text: >> >> One hypothesis this experiment proposes to test is the degree to >> which the "RFC" label motivates authors seeking publication. Though >> numbers are unlikely to provide a clear answer when so much of the >> problem is subjective, measuring the rate of submission and >> publication for affected documents could provide some insight. >> >> There are a variety of reasons that could go into that motivation; in >> some companies, as an example, publishing an RFC is rewarded financially= in >> a way that an internal technical report is not. >> >> Joel has written on some of the difficulties in working out what to >> measure here, and I appreciate any consideration you can give to that; i= t's >> not an easy problem, but if there is no data to work from forward motion= on >> the basis of anything other than impressionistic anecdotes will be >> difficult. >> >> regards, >> >> Ted >> >> > --000000000000477cc805701d9a48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 3, 2018 at 11:46 AM, Andrew G. Malis <agmalis= @gmail.com> wrote:
Ted,
<= br>
That is true, but the rest of the draft talks about the "= ;common perception of the significance of the "RFC=E2=80=9D label=E2= =80=9D, how =E2=80=9Cmisconceptions about the significance of publication a= s an RFC is [sic] commonplace.=E2=80=9D, and how =E2=80=9Cthere are numerou= s examples of RFCs that make an honest representation of their status=E2=80= =9D, meaning there are some that do not. There is also "For the exampl= es given, a principled reason for publication is well justified.=E2=80=9D, = again implying that there are unprincipled reasons for publication as well.=

I just just adding 1+1 to make 2.

<= /div>
Regarding your example of authors being financially rewarded for = RFC publication, I=E2=80=99m sure that would extend to any IETF publication= type if the IETF were to run this experiment,

Do you believe it would also be true for IRTF publications= if the experiment were run?=C2=A0 ISE publications?

regards,

Ted
=C2=A0
thus this particular publicati= on motivation would be unaffected by the proposed experiment.
Cheers,
Andy


On Tue, Jul 3, 2018 at 2:28 PM, Ted Hardie <<= a href=3D"mailto:ted.ietf@gmail.com" target=3D"_blank">ted.ietf@gmail.com> wrote:
On Tue, Jul 3, 2018 at 11:14 AM, Andrew G. Malis <<= a href=3D"mailto:agmalis@gmail.com" target=3D"_blank">agmalis@gmail.com= > wrote:
Not only am I= in complete agreement with everything that Brian has said here, but I woul= d like to add that section 5 makes this draft one of the most cynical docum= ents I have read in a very long time. It makes the inference that one of th= e primary reasons people publish non-standards-track RFCs is to DELIBERATEL= Y TAKE ADVANTAGE of any confusion in the reader=E2=80=99s mind regarding th= e status of RFCs.

That's = not quite what the document says.=C2=A0 Here's the text:
= 
   One hypothesis this experiment proposes to test is the degree to
   which the "RFC" label motivates authors seeking publication.  =
Though
   numbers are unlikely to provide a clear answer when so much of the
   problem is subjective, measuring the rate of submission and
   publication for affected documents could provide some insight.
There are a variety of reasons that could go into that motivation; in= some companies, as an example, publishing an RFC is rewarded financially i= n a way that an internal technical report is not.=C2=A0

Joel has writt= en on some of the difficulties in working out what to measure here, and I a= ppreciate any consideration you can give to that; it's not an easy prob= lem, but if there is no data to work from forward motion on the basis of an= ything other than impressionistic anecdotes will be difficult.

regards,

Ted


--000000000000477cc805701d9a48-- From nobody Tue Jul 3 13:08:58 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22416130E14 for ; Tue, 3 Jul 2018 13:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 6dcRzdhvOBCf for ; Tue, 3 Jul 2018 13:08:54 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 E5429130DFB for ; Tue, 3 Jul 2018 13:08:53 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id w126-v6so6317391oie.7 for ; Tue, 03 Jul 2018 13:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kek1ITT/Ai7zgJIB1ejPM7dgW7ZYXPuxE0ceLLbEB8E=; b=SW5RCtk4yy5D7NYlzdHq0MQs0PRpQRmZl7JZ7m1v9GCB7gILc9lFqYxdz/vuCP92ZR tq3+KHZ7lP1py9Rbd4/w2TiwjIkXUKdM4uakFW6OGMogrNvNRN+I5flxHl2NsS1NvRV0 RNGegOtL5DXkqw1PXLT4JzTtMBaquKKihetvBROkTz3Wx7xOi0RkFDb3r/KIvSYYxl03 nFRDwhgxJetc7mbSY4zPOdUNKkPhTqVotRNVOANVM8w7fgh+XmFT4vIJ1mtlV2DghSJf L+tBTLzddPp/97UqLwp79Jl22w0F0wO1zjNq7pFWRG9yMsDs82rqxTHEpxaqtwyOy7B1 5fqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kek1ITT/Ai7zgJIB1ejPM7dgW7ZYXPuxE0ceLLbEB8E=; b=dewfcX8iZKuO9SRCabFqu+Wx0ZJNq62FIW5meMKWFemVAqEue+ooWsQKD0sZhxaGHw B8WMK59yhLRAhKXo8IUziOU96PrPsaxYo/INACD5IWrybVU5FMbvhx4Vx0B4b3a/8+it 4Qop858/QE4p39Jm7LneemLiM+AWW+KO/mrKwf4ghFU07ej+41Ou6SltswiUWN0TGjur i6o8b602nOscgVk4ewRQJmlmbUzdJLua7GoBXEWrYS6y4zEgxau+ydzaAEqcS23juQU/ T0FlQj5N+Tuh9paAIMLFsXoZ9uJvMS3lEEkztPepFPkmz67EOn9UN40Lr6oxYuRS0Ohl Cy3Q== X-Gm-Message-State: APt69E0YeMdkMBIBtQmEgGFVoSp+RKSUUEDoBbeiup14iMZRWfjBbK1S IhLQqk2aoWnWWw1q8/UlaY4+PuUcntn+L0y2aCM= X-Google-Smtp-Source: AAOMgpcKR9hMdW4zmEErqUrgsm0TolGwDTLtDUh5S0HC0JyfmwYb2pvVAIPYeICcwLIHxFfgD+tLXvAbt2DOTgeb4KY= X-Received: by 2002:aca:d015:: with SMTP id h21-v6mr23118921oig.142.1530648532876; Tue, 03 Jul 2018 13:08:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 13:08:22 -0700 (PDT) In-Reply-To: <775E9251-EDB7-4D13-87D4-B6018CC0BC20@gmail.com> References: <775E9251-EDB7-4D13-87D4-B6018CC0BC20@gmail.com> From: Ted Hardie Date: Tue, 3 Jul 2018 13:08:22 -0700 Message-ID: To: Bob Hinden Cc: Brian Carpenter , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000014028f05701de230" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 20:08:57 -0000 --00000000000014028f05701de230 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bob, On Tue, Jul 3, 2018 at 12:06 PM, Bob Hinden wrote: > Ted, > > > On Jul 3, 2018, at 9:14 AM, Ted Hardie wrote: > > > > On Tue, Jul 3, 2018 at 1:14 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > Isn't it *always* better to document something which is deployed, > whether it's good > > or bad? > > > > I believe that a number of your questions are ill-formed, and that the > one I highlight above illustrates this problem best. The question is not > "should X, which is deployed, be documented?", but "Should the RFC Series > contain the documentation for X, which is deployed?=E2=80=9D. > > My answer to this question is emphatically YES. It is useful the Interne= t > to publish deployed protocols in the RFC series. > > As I pointed out in my answer to Brian, that task is likely beyond our means. There are about double the number of apps in the collected Android app stores as the number I cited for the Apple app store; documenting what they use (even if it is shared for apps which appear in both) at a level sufficient to create an interoperable implementation would require an effort beyond than can work with the RFC Series' methods. We current cite documents from multiple SDOs and certainly use documents from a wide variety of sources. The correct question for us, then, isn't really: "is the world a better place if this is documented", but "is the world a better place if this is a documented as an RFC (as distinct from somewhere else)?" I think having an ISE who curates the independent series represents our current answer that the number of times it should be documented as an RFC is limited. I think the question before this BoF, though, is different. It's about whether calling all the streams' outputs "RFCs" is serving us well. As I pointed out before, one question leading up to this was whether the IRTF output being called RFCs is serving the academic community well. That same might be asked for the IAB stream. Martin's draft puts a stake in the ground about which one would still be called "RFC" if we ran the experiment of using other identifiers for the streams. We could certainly discuss what would happen if the IETF stream output was called "Internet Standards" instead of his proposal, but that didn't get documented in time for this BoF. regards, Ted --00000000000014028f05701de230 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,

On Tue, Jul 3, 2018 at 12:06 PM, Bob Hinden &l= t;bob.hinden@gmai= l.com> wrote:
Ted,

> On Jul 3, 2018, at 9:14 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> On Tue, Jul 3, 2018 at 1:14 AM, Brian E Carpenter <brian.e.carpenter@gmail.co= m> wrote:
> Isn't it *always* better to document something which is deployed, = whether it's good
> or bad?
>
> I believe that a number of your questions are ill-formed, and that the= one I highlight above illustrates this problem best.=C2=A0 The question is= not "should X, which is deployed, be documented?", but "Sho= uld the RFC Series contain the documentation for X, which is deployed?=E2= =80=9D.

My answer to this question is emphatically YES.=C2=A0 It is useful t= he Internet to publish deployed protocols in the RFC series.

As I pointed out in my answer to Brian, that task is = likely beyond our means.=C2=A0 There are about double the number of apps in= the collected Android app stores as the number I cited for the Apple app s= tore; documenting what they use (even if it is shared for apps which appear= in both) at a level sufficient to create an interoperable implementation w= ould require an effort beyond than can work with the RFC Series' method= s.=C2=A0

We current cite documents from multi= ple SDOs and certainly use documents from a wide variety of sources.=C2=A0 = The correct question for us, then, isn't really:=C2=A0 "is the wor= ld a better place if this is documented", but "is the world a bet= ter place if this is a documented as an RFC (as distinct from somewhere els= e)?"=C2=A0 I think having an ISE who curates the independent series re= presents our current answer that the number of times it should be documente= d as an RFC is limited.

I think the question befor= e this BoF, though, is different.=C2=A0 It's about whether calling all = the streams' outputs "RFCs" is serving us well.=C2=A0 As I po= inted out before, one question leading up to this was whether the IRTF outp= ut being called RFCs is serving the academic community well.=C2=A0 That sam= e might be asked for the IAB stream.

Martin= 9;s draft puts a stake in the ground about which one would still be called = "RFC" if we ran the experiment of using other identifiers for the= streams.=C2=A0 We could certainly discuss what would happen if the IETF st= ream output was called "Internet Standards" instead of his propos= al, but that didn't get documented in time for this BoF.

=
regards,

Ted
--00000000000014028f05701de230-- From nobody Tue Jul 3 13:43:23 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241B3130DF5 for ; Tue, 3 Jul 2018 13:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 xxuWJ5OngJLt for ; Tue, 3 Jul 2018 13:43:19 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 430E1130DE2 for ; Tue, 3 Jul 2018 13:43:19 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id j68-v6so1179578ywg.1 for ; Tue, 03 Jul 2018 13:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XKD4wOl3d8HjpbB+165BKDfTkkMbZoTSZc5mkoCU6rs=; b=N1zfiptJ2+DenSd/dlr6wMth8fd/6zkvBEvVfkzLctWHJeTEOTmvsmEaYGAf09IaHz t3pAu1NoZFjvScBIQB39hZAmn64JmilxGiYbjGYIDzUrhAJJq14hA8vdo+Ja6l935sHw MTUPI5LSy7tQ/Fv20FmZ3vmyUzoEWBeoj4QC2d+OFsaLUcQjXRP3V7JvFYTzIRLmH6/x 547vh6pdb7+ohNYqX6jknSIcYZDt0Mi06czq2cygMUOP+U4RaEQkV9BSymGdWYq6t6ty yA+0W8KQ5EbR1ZLvDhmdvTL+GW1rTGrFYRO3K0A/i5uf0dCzfaCwMwdYoBP2Kj4ewAql Cx4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XKD4wOl3d8HjpbB+165BKDfTkkMbZoTSZc5mkoCU6rs=; b=eJ3OOJbVr4XO7IBiaZduZMgtFWAV77yQk8eHrBJBeuF4x7hV/+yZPTrtG42vSyN/qt gG+L9/Vadn9KyddaV0QgVDhoGSlYz3W4lfvE5AybYjTZZdNdKup8yOLucjre4c0GeB6n RZh5BVCe0SoiwfkaLzl1B97Jms+mzdkwY0LwJ9bPJwQdcNAcdDCh4EKp3buQTHUcZeMl OhQs+OJ6pxz1LDxRB5UxaaKoqG9ye8KNm1FVvNuqZ9/0p/GbH5PB7lcZz9mMD5m+DwBf uZqtmDr/w9vRqVY5J7ipSs8cIDJHnITJKttITuHQh1arY1a8LyEgUzO2ET4VTJSY6u57 ZjgQ== X-Gm-Message-State: APt69E0O8L4/4PK6yCRQX+QXQCKeqsV1ZMBiy3FBDQsc+COunqpzbLuq OZqAyJWPywZLVUbbWRL3/9vFAH6j6UmJUia9ytNZHQ== X-Google-Smtp-Source: AAOMgpeR2JmfmCKpf+CTIIQKQDDFY8N7U9oLOr/dX6fpQfOSodWslOxWKFCZjQRaZ+hciUlUn7O4JarSVqhyuy5vhwI= X-Received: by 2002:a81:3e02:: with SMTP id l2-v6mr9641868ywa.381.1530650598413; Tue, 03 Jul 2018 13:43:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 13:42:37 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 3 Jul 2018 13:42:37 -0700 Message-ID: To: Brian E Carpenter Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000031ad5c05701e5db0" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 20:43:22 -0000 --00000000000031ad5c05701e5db0 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 1:14 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > 6. Security and Privacy Considerations > > > > It is believed that there are none. > > Given how many of the Independent Series RFCs are about > crypto algorithms and the like, potentially interfering with > that publication channel seems to pose a risk. > Hi Brian, I agree that many of the IS documents are security-related, but I don't think that failing to publish them in as RFCs would have a significant negative impact on security. Looking back on the past 5 years or so of IS RFCs, the following seem to be "crypto algorithms and the like" [0] RFC 7076: P6R's Secure Shell Public Key Subsystem RFC 7091: GOST R 34.10-2012: Digital Signature Algorithm RFC 7906: NSA's Cryptographic Message Syntax (CMS) Key Management Attributes RFC 8235: Schnorr Non-interactive Zero-Knowledge Proof RFC 8236: J-PAKE: Password-Authenticated Key Exchange by Juggling RFC 7076 and 7906 look to me to document protocols which are in use by some organization but which are not in wide use. This is one of the 4846-defined uses of the Stream (Informational publication of vendor-specific protocols) but I don't think that the security of the Internet would be materially harmed if they had not been published. Neither is cited by any I-D or RFC. RFCs 7906, 8235, and 8236 document algorithms that the IETF has not shown significant interest in using. - 7091 is a national signature algorithm, and the IETF has instead converged on ECDSA and EdDSA. - 8235 is a ZK-proof system which isn't employed by any IETF protocol (there is one Informative reference in an individual I-D, but it's just an example). - 8236 is a PAKE system, but not one that the CFRG is converging on, and again not used by any IETF protocol (cited as an example by the same I-D). In my opinion, it would not be a material loss to the security of the Internet if these technologies had not been published as RFCs. I was actually a bit surprised at how few algorithm drafts had been published recently. Going back a further, it seems to me that the algorithm drafts fall into two main categories: - Documenting algorithms which are in wide use but just didn't have a formal specification (e.g., SHA-1, Base-64). - Documenting algorithms which the IETF didn't have much interest in and haven't seen much adoption (GOST, Brainpool, Rabbit, ARIA). In the former case, I think we now have ample mechanisms for publishing those documents without the ISE. Specifically, we now use the CFRG both to review and to publish those documents (cf. X25519 and ChaCha/Poly1305). Amusingly, I wasn't even aware that there *was* a SHA-1 RFC; TLS, for instance, cites the FIPS rather than this RFC. In the latter case, I don't think that having these documents published in the RFC series significantly improves security over some other stable reference, at least in part because the IETF would to some extent prefer that they not be implemented in IETF protocols (as opposed to the algorithms we do recommend). Arguably, taking these algorithms out of the RFC Series makes matters somewhat better because it reduces some pressure to implement them in libraries. I guess that might be a useful thing to say? -Ekr [0] Ignoring stuff like DMARC which seems to me to be in a different category. --00000000000031ad5c05701e5db0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 3, 2018 at 1:14 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 6.=C2=A0 Security and Privacy Considerations
>
>=C2=A0 =C2=A0 It is believed that there are none.

Given how many of the Independent Series RFCs are about
crypto algorithms and the like, potentially interfering with
that publication channel seems to pose a risk.

Hi Brian,

I agree that many of the IS documents are security= -related, but I
don't think that failing to publish them in as RFCs = would have a
significant negative impact on security.

Looking bac= k on the past 5 years or so of IS RFCs, the following
seem to be "c= rypto algorithms and the like" [0]

=C2=A0 RFC 7076: P6R's S= ecure Shell Public Key Subsystem
=C2=A0 RFC 7091: GOST R 34.10-2012: Dig= ital Signature Algorithm
=C2=A0 RFC 7906: NSA's Cryptographic Messag= e Syntax (CMS) Key Management Attributes
=C2=A0 RFC 8235: Schnorr Non-in= teractive Zero-Knowledge Proof
=C2=A0 RFC 8236: J-PAKE: Password-Authent= icated Key Exchange by Juggling

RFC 7076 and 7906 look to me to docu= ment protocols which are in use by
some organization but which are not i= n wide use.=C2=A0 This is one of the
4846-defined uses of the Stream (In= formational publication of
vendor-specific protocols) but I don't th= ink that the security of the
Internet would be materially harmed if they= had not been published.
Neither is cited by any I-D or RFC.

RFCs= 7906, 8235, and 8236 document algorithms that the IETF has not
shown si= gnificant interest in using.

- 7091 is a national signature algorith= m, and the IETF has instead
=C2=A0 converged on ECDSA and EdDSA.
- 82= 35 is a ZK-proof system which isn't employed by any IETF
=C2=A0 prot= ocol (there is one Informative reference in an individual
=C2=A0 I-D, bu= t it's just an example).
- 8236 is a PAKE system, but not one that t= he CFRG is converging
=C2=A0 on, and again not used by any IETF protocol= (cited as an
=C2=A0 example by the same I-D).

In my opinion, it = would not be a material loss to the security of the
Internet if these te= chnologies had not been published as RFCs.


I was actually a bit = surprised at how few algorithm drafts had been
published recently. Going= back a further, it seems to me that the
algorithm drafts fall into two = main categories:

- Documenting algorithms which are in wide use but = just didn't
=C2=A0 have a formal specification (e.g., SHA-1, Base-64= ).
- Documenting algorithms which the IETF didn't have much interest=
=C2=A0 in and haven't seen much adoption (GOST, Brainpool, Rabbit,<= br>=C2=A0 ARIA).

In the former case, I think we now have ample mecha= nisms for
publishing those documents without the ISE. Specifically, we n= ow use
the CFRG both to review and to publish those documents (cf. X2551= 9 and
ChaCha/Poly1305). Amusingly, I wasn't even aware that there *w= as* a
SHA-1 RFC; TLS, for instance, cites the FIPS rather than this RFC.=

In the latter case, I don't think that having these documentspublished in the RFC series significantly improves security over some
= other stable reference, at least in part because the IETF would to
some = extent prefer that they not be implemented in IETF protocols (as
opposed= to the algorithms we do recommend).

Arguably, taking these algorith= ms out of the RFC Series makes matters
somewhat better=C2=A0 because it = reduces some pressure to implement them in
libraries. I guess that might= be a useful thing to say?

-Ekr



[0] Ignoring stuff li= ke DMARC which seems to me to be in a different
category.



--00000000000031ad5c05701e5db0-- From nobody Tue Jul 3 14:20:46 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE9A130E54 for ; Tue, 3 Jul 2018 14:20:44 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 8vahoAhPgrdO for ; Tue, 3 Jul 2018 14:20:42 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC407130E0F for ; Tue, 3 Jul 2018 14:20:42 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id b1-v6so526498pgu.5 for ; Tue, 03 Jul 2018 14:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=ND3wmdY6x+0x1Xkeh4TkHO62RzoHO0+0bJAhzyCNAYM=; b=qz34QGrCgZfrea2bOfTCghEsZ3F20jEDnS9PTznzFY3Tn1jZXdK+b8fCxOV7okZMbl JQkrB3qt2X54vFkvCq5AtOyWVQWpcdol+Gnth6UUlkJ2azQ+eZ/rUl2h0yWDV2mrepRH 0pl6J8lnrGcIlC+LpfkTY8A5T1bA3+jNWbi64doCEe1eAZxDFgTjnxK6X8+K1abdu207 wMwgeyYyJV+2qf3vBEEDmH/OI9aZ8z5kDbFjT+dBj9s+YNbWJDEY0ggeRm5QkRV0O2xD 8JXuL8hmcoYCWjTgAjm27XCjkUOnnvwkLfSGSHBPbnbuIetANE7QhwpopbqN4gdeRRaG BZoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=ND3wmdY6x+0x1Xkeh4TkHO62RzoHO0+0bJAhzyCNAYM=; b=GmJWSstkAFlbwId0R7p+E2SMAh+c3crg8ogzRiSm/Wk/Bcwi7cOL9GagEsiytOXaZ1 bd2uXwNxpvzYB48LZVpGZst9UZfIczCZyR9bPFAN23TMScw8+diFAwfp0Y/8Avoh8+P0 jNe9TiiNDDSzMPoA0esbw1HRnQQ69slp7go8DG1syTsgwtLQtEbwKBDNus8FVejKv9U5 zEjpSCNLyGU4+dMjCUZesY/ggN3WRJaXGa5MDu2achi5xLK51XPcf0rBjDWe+T4BBQQ8 gf7aVsW4PitGSg2+p35+ny4aDAT3OC7iZ0cyz0s+8na6MLh8+JWjHpkCFemsxMnb1JnI 734w== X-Gm-Message-State: APt69E2ciuNTf99envmOOl9QhJLuOGCkzo5IPmuB6fUhq7CLsxerBpcO CtT63DigH0FXn0mFkuwvDS6Ot9Ge X-Google-Smtp-Source: AAOMgpdBOIDZNIq23wxZzaP73pLlaBC+6Ocw0W286q6AKo9q+vGxm2i3e0fdLZncny7PH2l5HZeOjg== X-Received: by 2002:a65:665a:: with SMTP id z26-v6mr25926348pgv.193.1530652842144; Tue, 03 Jul 2018 14:20:42 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id c5-v6sm8808867pfe.169.2018.07.03.14.20.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 14:20:41 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_68BA8F2E-5E78-4286-8A2A-526B99A70FB4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 3 Jul 2018 14:20:40 -0700 Cc: Bob Hinden To: rfcplusplus@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Rfcplusplus] The RFC Brand X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 21:20:45 -0000 --Apple-Mail=_68BA8F2E-5E78-4286-8A2A-526B99A70FB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 When the IETF decided to publish it=E2=80=99s work in the RFC Series, it = did it because the RFC brand was well known in the technical community. = We thought this was better at the time even though we knew that there = were non-IETF produced documents in the RFC Series. The RFC Brand has been enormously successful. It is very well known in = the Internet technical community and the larger Internet community. We = built the infrastructure of the Internet on it. It=E2=80=99s been good = for the IETF and good for the Internet community as a whole. Many = people recognize the RFC Brand. The proposal before us would weaken the RFC Brand and I think the IETF = as a result. Brands are very hard to create in the first place. We = have one that has been in existence since 1969, almost 50 years. Changing a brand is very risky, and if we damage the RFC brand (which I = think a poorly considered set of changes will do) it will be very hard, = if not impossible, to recover. The IAB has indicated the proposal that = has spurred the BoF is just a starting point. I feel that it is a poor = place to start, and if handled in any way close to what is described = will absolutely damage the RFC brand. Bob --Apple-Mail=_68BA8F2E-5E78-4286-8A2A-526B99A70FB4 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAls76KgACgkQrut0EXfn u6hLqAgAtPnDRx3ZddmGrmxXAKmroX9ofoUn00AYKCx0qUoUvZn2gTKaqkIPAbpm uB/MVGQEiwwQoCnKt0/6lbVnZ9PYaNo2Dp47mCE6mN9nbfvqsWbZfbuVZWtrWECQ p8pLn0bxzjAGzy3RVDQxGSNSkDoJlAtRQ1wBD10+U4kJ67/BQ/9EvDyw+dP3a2yO hP2LE1HmuZAtVLQJp9hDaUatO82ncyOwHxWqAAe5fgLtgzSOPSNRvwo0cjxBjBnH Tp/ct09KBQfahfpL9la02+s9+3Nv27aal36TCuF3A8dA/zW2ZNd+8QbQl88tX/72 Oxd1SrFCwWp04tmEwToJ/4g0WZFFEA== =p/zE -----END PGP SIGNATURE----- --Apple-Mail=_68BA8F2E-5E78-4286-8A2A-526B99A70FB4-- From nobody Tue Jul 3 15:03:25 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598E1130E83 for ; Tue, 3 Jul 2018 15:02:57 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 9ZkGAMY0HgK3 for ; Tue, 3 Jul 2018 15:02:55 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 1BE8F130DE0 for ; Tue, 3 Jul 2018 15:02:55 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id c10-v6so1551125pgu.9 for ; Tue, 03 Jul 2018 15:02:55 -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=J9PBdhgCBVueZEql+rW3vXjznWpcO9LjazbfmFGbx8s=; b=lHGQ3GYUDeO5oLG0ECVKazYs1zl5TThp+7ReRnMxtqv6shJdCau1K38LPMaCApTKFY e3u1PY3GZTJnmzAc5qs6EZKkeCdOKLaUjiShNSvs52I+/fsoDJBQAruePcyg8Ek1sa3v Jmy+ZNnvjg2X5jlmll7xbBZZHFJZPjTCMOehdhCimkhEYCDdekhjOUwYQzQOj2Yl7OpZ x2FsCc+ioHfwRHQZTz51JoJ3Ieh2pCOC8pwUX3g7bLScmazg8bdfbgH6CTe25WjA6NeF fdxI8GRNziNtXPPLnAYFXvi1V2PWjW4RxozAJCuCV+UY+ipEjFxDgtbBDVUSQkyWHayl gj4Q== 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=J9PBdhgCBVueZEql+rW3vXjznWpcO9LjazbfmFGbx8s=; b=Qowdbqe617Xe6CdmVqK8hmAnlqyiSCzxlrfZU4lzGf5NBaYRLWQDRv1JMhBgQomM8W mVQ37jOhLtHeZkHdvXrOVgJ48+m30GAG0PLdz8xe9NPCqxeMqyhiKVClh1R96EzPo+gP ZmNa/Ud25SY0frbwanPAJeLgvnt1vP/ETlqdQVpnmSPpKHh2Uq3WVziweWqlJ0XhwfUV N/LvXuUMhG7N+6MH6xCG0EYz3YCH6z/0h6JZTXgC3ke5vQL9QKy2jqGGKdTkRoWxpcoC V8zhNzNw0tQ8wTzc3OF0100SAcMJuKd1JxlLCJqzbpRhLF4oVrbkP50kVpbKgNv0Z+ZR 8NDQ== X-Gm-Message-State: APt69E3XBQT0uer4r94KfXsj45IrfjZdSpZT/jX0dXFVqUyrPKjhyt1S ym2vlZgWFSCZfnWh3NCke70= X-Google-Smtp-Source: AAOMgpfJXbHLKEFdpYeYbAt/MPhu1K+Gh60xDCfxN97Ldhfelare12QD7yNnPDK2ue6S0w7w+ba02w== X-Received: by 2002:a62:a50e:: with SMTP id v14-v6mr31426178pfm.121.1530655374569; Tue, 03 Jul 2018 15:02:54 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id d17-v6sm3161993pgp.50.2018.07.03.15.02.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 15:02:53 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_35E10208-EF68-4177-9BB9-E1A157530A3B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 3 Jul 2018 15:02:52 -0700 In-Reply-To: Cc: Bob Hinden , Brian Carpenter , rfcplusplus@ietf.org To: Ted Hardie References: <775E9251-EDB7-4D13-87D4-B6018CC0BC20@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 22:02:58 -0000 --Apple-Mail=_35E10208-EF68-4177-9BB9-E1A157530A3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ted, > On Jul 3, 2018, at 1:08 PM, Ted Hardie wrote: >=20 > Hi Bob, >=20 > On Tue, Jul 3, 2018 at 12:06 PM, Bob Hinden = wrote: > Ted, >=20 > > On Jul 3, 2018, at 9:14 AM, Ted Hardie wrote: > > > > On Tue, Jul 3, 2018 at 1:14 AM, Brian E Carpenter = wrote: > > Isn't it *always* better to document something which is deployed, = whether it's good > > or bad? > > > > I believe that a number of your questions are ill-formed, and that = the one I highlight above illustrates this problem best. The question = is not "should X, which is deployed, be documented?", but "Should the = RFC Series contain the documentation for X, which is deployed?=E2=80=9D. >=20 > My answer to this question is emphatically YES. It is useful the = Internet to publish deployed protocols in the RFC series. >=20 > As I pointed out in my answer to Brian, that task is likely beyond our = means. There are about double the number of apps in the collected = Android app stores as the number I cited for the Apple app store; = documenting what they use (even if it is shared for apps which appear in = both) at a level sufficient to create an interoperable implementation = would require an effort beyond than can work with the RFC Series' = methods. I don=E2=80=99t see how we went from, for example, publishing the specs = for NFS, to publishing documents for all Android and Apple app store = applicaitons. That doesn=E2=80=99t seem like something that is likely = to happen. Did someone submit millions of docs to the IS Editor? >=20 > We current cite documents from multiple SDOs and certainly use = documents from a wide variety of sources. The correct question for us, = then, isn't really: "is the world a better place if this is = documented", but "is the world a better place if this is a documented as = an RFC (as distinct from somewhere else)?" I think having an ISE who = curates the independent series represents our current answer that the = number of times it should be documented as an RFC is limited. In some cases it does make the world a better place (e.g, NFS = protocols), and others it does not. Given the number of documents on = the IS stream, this doesn=E2=80=99t seem like a significant issue. The = ISE can easily reject documents that don=E2=80=99t fit into the series. >=20 > I think the question before this BoF, though, is different. It's = about whether calling all the streams' outputs "RFCs" is serving us = well. As I pointed out before, one question leading up to this was = whether the IRTF output being called RFCs is serving the academic = community well. That same might be asked for the IAB stream. I think is a more complicated question. It also should include if the = cost of fixing this perceived problem, is more or less the benefit = gained. >=20 > Martin's draft puts a stake in the ground about which one would still = be called "RFC" if we ran the experiment of using other identifiers for = the streams. We could certainly discuss what would happen if the IETF = stream output was called "Internet Standards" instead of his proposal, = but that didn't get documented in time for this BoF. I think the BOF would have been better structured, if it had been = limited to discussing to what the problem is, and if it is serious = enough to fix. Then we would be having a different discussion. I note that RFC 5434 goes to great length to have a BOF focus on the = problem, and not get into solutions. I continue to be surprised that = this was approved in it=E2=80=99s current form. Bob --Apple-Mail=_35E10208-EF68-4177-9BB9-E1A157530A3B 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAls78owACgkQrut0EXfn u6hLVwf/bBUYyLF8MFlifiHccFfHPRyGl7y7EUL19VUvU2Cv86dTPRxxd6fxpaN+ hQOTfpU4wERETrfwNTQgr92YIXO7P2FFWMAbd8agk8Lro6ejqrYUKW4AnJJby6cG 6xCFzpBcD7U7a5Qat3DwRdwPcHzb7WfcOTR3FC8mJOundEJJWZVC3HZR1g2t5C3M roh3Nr3o4VSj5cxa5XXaT6Y+8bPLOidtPUHOyiEdZnNNaml1qfPoMBKFrjYfTbC1 Fcb4comuRQ/pFRbDElYoDi3QTsU6NLc5a5/siz1BcM8zf784XknsJvAdqQ0jT64h ykeSbCrLNWVPO/kenKHR1eC5bV2QsA== =Nl4G -----END PGP SIGNATURE----- --Apple-Mail=_35E10208-EF68-4177-9BB9-E1A157530A3B-- From nobody Tue Jul 3 15:16:30 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4D9130DE0 for ; Tue, 3 Jul 2018 15:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 6qs0ynITuRFi for ; Tue, 3 Jul 2018 15:16:22 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E97130DDE for ; Tue, 3 Jul 2018 15:16:22 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id 139-v6so1244648ywg.12 for ; Tue, 03 Jul 2018 15:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Adxk0jzn4WFFeMyS43cEviQJ0EEkkJzRJ5XFWaSL4do=; b=gDQSJlfmnPyZwcBy9uUPPUwWctUOIwUL/57EOuoYRDPwB7ZcCYf8SsU4DyvnTiJMyM UnXNOi3aTRATL7tjDmqjb0e1JFqMWr3jBrMGBgkkCgsZ1g2e2gIhggzUyf81jPkqjp5z CX7BxjbAj/NdtkvpKx5+Gswo/2kbkA6NdDj7hfqI2Zxv74NJSImL6ZCKUadGMnIy9kjP rCauyj0mQcaizouKW7WPZNZaZ8RXajg/HeCXWRU2uS+aizTLtoGiK3hkKMD+wBv7NXia 1fvPLG5G/E/bUdQKIDpaLFD91T6yc/KpucJnnlZw/UvJksF0MPZQyWzbQ1KLqGev9iMY dsig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Adxk0jzn4WFFeMyS43cEviQJ0EEkkJzRJ5XFWaSL4do=; b=nrBGk0cO1GR9objntUlQh+luEDGH89vTLhxB6hQkTYjSFmvZ+9MzHyRyJPgUYEfZwB E6/DPc1nFywr+ZOZ4gBxs0ahhyZEhJGYO3R0rTXY4VbKLKr4UuWGQl6xJIGa5TspkFRh rmEhYa1IQjKnXwXWIE2aRLsasoxSo84f80q2eiD1knJWVqNTGYKnQnLPJiC/+8m4Lub1 gabl84fKtBnMwQW/Sl0BEBST0O16/Kn5hDMTJm8Y6In/01ExF+cpNK/+iuS19NIp6l1q 379D/ymHhbkVFMvYjJyzWL9kE+Nv2+tIcepMl1FusM9lfK/QweRRG+Rs3Cj7XZnmceHe OcQg== X-Gm-Message-State: APt69E0+BIg86ORfstmflfLsGV6pzQQILYUKAxuUHuposxK/eiz1PRqE 0B5I+T4lKJHZMnenzbyFYxBYuCVc/vm/MiEo++LM2w== X-Google-Smtp-Source: AAOMgpeFft08WLglCzVMKL4BAJD+mQmm9Te0f35UCJaTFpwPFUlNXDHMOMRLum3U02rCpY+3Vy0TI42LSC/JpIfrQXw= X-Received: by 2002:a0d:f286:: with SMTP id b128-v6mr15302351ywf.489.1530656180318; Tue, 03 Jul 2018 15:16:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 15:15:39 -0700 (PDT) In-Reply-To: References: <775E9251-EDB7-4D13-87D4-B6018CC0BC20@gmail.com> From: Eric Rescorla Date: Tue, 3 Jul 2018 15:15:39 -0700 Message-ID: To: Bob Hinden Cc: Ted Hardie , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000e6c8cc05701fa9a6" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 22:16:26 -0000 --000000000000e6c8cc05701fa9a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2018 at 3:02 PM, Bob Hinden wrote: > Hi Ted, > > > On Jul 3, 2018, at 1:08 PM, Ted Hardie wrote: > > I note that RFC 5434 goes to great length to have a BOF focus on the > problem, and not get into solutions. I continue to be surprised that th= is > was approved in it=E2=80=99s current form. > Hi Bob, RFC 5434 is an Informational document, not a BCP or a PS. So, while it may have valuable advice, it doesn't really bear on whether the IESG should have approved the BOF. Incidentally, I had to look up the RFC to see its status, which seems to illustrate how this is a source of confusion. -Ekr Bob > > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > > --000000000000e6c8cc05701fa9a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 3, 2018 at 3:02 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
Hi= Ted,

> On Jul 3, 2018, at 1:08 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
I note that RFC 5434 goes to great length to have a BOF focus on the proble= m, and not get into solutions.=C2=A0 =C2=A0I continue to be surprised that = this was approved in it=E2=80=99s current form.

Hi Bob,

RFC 5434 is an Informational document, not a BCP or= a PS. So, while it may have valuable advice, it doesn't really bear on= whether the IESG should have approved the BOF. Incidentally, I had to look= up the RFC to see its status, which seems to illustrate how this=C2=A0 is = a source of confusion.

-Ekr


Bob



_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus


--000000000000e6c8cc05701fa9a6-- From nobody Tue Jul 3 15:56:42 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC55130E62 for ; Tue, 3 Jul 2018 15:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=O4ZpZU93; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=KtFKYRoK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbm4L7SrN6ns for ; Tue, 3 Jul 2018 15:56:38 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D79130E25 for ; Tue, 3 Jul 2018 15:56:38 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.48.6]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id w63MuMHv025093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2018 15:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1530658595; x=1530744995; bh=6Cy4gsBNrtOhBiQFNw+o/NiP577AyqmdETwbXpjfX0w=; h=Date:To:From:Subject; b=O4ZpZU93rAgYU9zPTuEJuGjxcufG7IHHr5j97c/b18bknCivMSMae19jIRH/YkjEl Gtdt7RtEmYtYnbZI8nQ1HbFgbnqfBmvmSMIJD5lVv2AxIQR0ANV4dSoz0jL5vf8tK2 b4XQMsASK6T/5QXL+U8DGBmcAumUHWCsZNcOUaho= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1530658595; x=1530744995; i=@elandsys.com; bh=6Cy4gsBNrtOhBiQFNw+o/NiP577AyqmdETwbXpjfX0w=; h=Date:To:From:Subject; b=KtFKYRoKEVrjNBR73LbvE3WDWi96uZx9gKyqZx34i6nZGXSDcIpAkm3uYefWHMNW5 tBsb/NYfTJMB1uXGDBoutEkxsTbfGNH8kLVmfBxQB0zswAMxC77oACf+pmlKAQKpnY eJo0GZsa4g7d0zqEFt7joEXxuQjphHJ6z1BA1I+o= Message-Id: <6.2.5.6.2.20180703135941.0cf5ab78@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Jul 2018 15:51:21 -0700 To: Martin Thomson , rfcplusplus@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: [Rfcplusplus] Comments on draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 22:56:40 -0000 Hi Martin, First of all, thank you for submitting [1] a draft about the proposed label experiment. There is the following in Section 1: "The Internet Standards Process [RFC2026] describes a process that has consistently produced quality documents". An old ETSI document states that "the quality of [IETF] RFCs is variable. Some are well-constructed and easy to understand, others are less so;" There was an IAB report which mentioned that the discussions which led to the proposed BoF was also about "a long consideration of the role of that ISE-curated RFCs play in the ongoing confusion over RFCs as standards". I have done a few reviews for the ISEB over the years. I am somewhat surprised by the IAB's opinion about the Independent Submissions Stream as the previous discussion about that Stream was not related in any way to standards; it was about about an alternative publication option for authors of Internet-related material. Your draft touches on that in Section 2 (commonly-accepted view). The point made in Section 2 in respect to deployment is that the "non-standard" RFC could cause interoperability issues. Is the issue about the allocation of codepoints [3]? There are IPR disclosures on the two RFCs which you cited in Section 2. Why is the publication of RFC 8216 viewed [2] as a "defiance of a standardized protocol"? Section 2 of the draft also states that those two RFCs describe "in reality" standards. If I am not mistaken, the line of argument in the IETF used to be that it is deployment which "makes" a standard. There is an alternative to that, i.e. require an ITU-T A.5 justification. The financial reward of being a "RFC author" likely contributes to the "nuance in interpretation" of the label. About a week ago, I came across an 15-pages (IETF) draft which had 14 authors. I don't recall seeing that many authors for drafts in the Independent Submissions Stream. I doubt that the publication of a RFC is always about reaching an IETF audience (please see Section 3) as it should be obvious that the best place to reach that audience is within the IETF. Regards, S. Moonesamy 1. You might have read my comment about not finding much information about the RFC++ BoF. 2. The conflict review states that "this relationship does not prevent publishing". 3. From what I understand, that is usually requested through the IETF. From nobody Tue Jul 3 17:58:36 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38098130E1D for ; Tue, 3 Jul 2018 17:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 Np2m4V7ogUwf for ; Tue, 3 Jul 2018 17:58:33 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 C39541277C8 for ; Tue, 3 Jul 2018 17:58:33 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id c6-v6so7536473oiy.0 for ; Tue, 03 Jul 2018 17:58:33 -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=b3YPfub4/rQMt1CYCirYSCh5m9iM0Nw1hC1pX8Mf1Ww=; b=i9rLmVJBr81vi7a7887X7K66eKShL5wsg+Dp7qbtR3bQKY5mBJYV7SevCpwX4MDrcD 84QFBeturuEflR9omZVCsSLrxmYgJmFU0f34HAWy4RCGLwgI8f7qwHK5o66imnA2fbnr 4/v03nfQv5gieo0t+LgRDocWfEw5roY7r7KdEcV/KjIcIH8FwVq833BCCCBDVpVZjZYl XhTn8F4eF3kxF+5ue/5TRT6djI3tl1jiefdptIxyLUCITCWnkgEE+JqHj4PO+VzfElCV jXgMzBT9FH8T7flVOeRz8R+aXawJvwdiSeNipVpl0D2rNgmSvAE37jAARGI1a/16qTro c+Tw== 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=b3YPfub4/rQMt1CYCirYSCh5m9iM0Nw1hC1pX8Mf1Ww=; b=pHhVXtedoNDAaNEX2SVOMmya6+CUFEl5ii6rog2JzpEVY+/b6LtI6FU0GEq3AKh7bp zBIU4QEYAVnJY3jCpSdcwIejAQOZn9AMML/8zLweXlcPHryIPASWU4l1r9B7mb6X+CUi gjGSYnKd57cCB9CzOJLZJaVqNTnifA29I5pbk9scaeIRjgBy9FHOshqnNP9JVTht190E pxd6cwkGYUAegq3CVdXCUp4COmtB9cLDMFFQqUb/RlYeQYnxFkfzlk4t2FJfnB/1TUFf wkOGlXMNa4jWFHqbztKv/16Bf3xc4jZ5MzmJTnRlushffv1w/oHt19+VH2C9bGitg7vA ffQA== X-Gm-Message-State: APt69E2LipQZ48hD5gF5yZCgBicujyQhIUojv2c2453DTsECXtF9qUaV t8t+xyvE2okVB/YMPklFCPGqfTrjgHPWyEcoUyXJLw== X-Google-Smtp-Source: AAOMgpfiRaHsFZtxlsxpFUo/uus3In45pqxsfbwnHV9yfGGuLzb4nsgWmCXijEYzwRK86yjEP799B3XTC5x1r9ZS0u8= X-Received: by 2002:aca:3954:: with SMTP id g81-v6mr24840927oia.215.1530665913090; Tue, 03 Jul 2018 17:58:33 -0700 (PDT) MIME-Version: 1.0 References: <6.2.5.6.2.20180703135941.0cf5ab78@elandnews.com> In-Reply-To: <6.2.5.6.2.20180703135941.0cf5ab78@elandnews.com> From: Martin Thomson Date: Wed, 4 Jul 2018 10:58:21 +1000 Message-ID: To: S Moonesamy Cc: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] Comments on draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 00:58:36 -0000 On Wed, Jul 4, 2018 at 8:56 AM S Moonesamy wrote: > The point made in Section 2 in respect to deployment is that > the "non-standard" RFC could cause interoperability issues. Is the > issue about the allocation of codepoints [3]? Not so much. I don't believe that allocating codepoints should be use as a locus of control. We've seen some pretty awful consequences from that. Recently: three-way squatting on the same codepoint in TLS, for instance. The concern is simpler: the creation of non-interoperable deployments. > There are IPR disclosures on the two RFCs which you cited in Section > 2. Why is the publication of RFC 8216 viewed [2] as a "defiance of a > standardized protocol"? Bad choice of words maybe, because that's just my opinion. That is, I believe that DASH is perfectly adequate for the use case and that the publication of HLS as an RFC is entirely unnecessary. That the conflict review found no conflict is unsurprising, but that's a very narrow determination. From nobody Tue Jul 3 18:41:56 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D23C130D7A for ; Tue, 3 Jul 2018 18:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 FWg62mDmAstf for ; Tue, 3 Jul 2018 18:41:52 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30606127598 for ; Tue, 3 Jul 2018 18:41:52 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id b15-v6so7622869oib.10 for ; Tue, 03 Jul 2018 18:41:52 -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=1TJEbq4uQ+gVgLwhD7wGUZb5BsFKD09N2cmXUeIL448=; b=j4Ep7eeU9kDC7JuUnQb+26lDkhV4zkrfhpglBzyBFZueZX++e3/snqj7k6G+v31Hkz mtsVqT3d3ABZWKhkTgVEXtFG3wl7XbYIEbcfTpC5hUTwrNZWITU+S9T5hAshE2z1m+u0 bFeudN2Udr7Wre/pjD//jt4FoQ6hwrPkk5uce0LFuCzXajic2XPXPgh9p7ck5LJcpFPb CsAvXLIhg/tB6bhmxtMOxKsrS2nGMIODzCk+X/uWBVf4vEONDS5CXUi92xdMY7WjBSXq qFzeUTHrz/NohknjvzyfJEu43zKRTBEe08d17++PMyE4YLx+YJGZwpzJci+HcQf9fuIq vuUQ== 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=1TJEbq4uQ+gVgLwhD7wGUZb5BsFKD09N2cmXUeIL448=; b=C2OVsh0t2El7nIE+yGZQ8d15JTnlmeUKUI8NW9Q2iwxtOW8/4SYUdGAnJwSxCxULF7 ORkcufeF1drlTzS7B2T9RBFxu2cWxQey0J7JZf71rN8Y0NoHyoB+79I70Wzm6Z6f6b68 ka0riP5UiagUQRKQSH5P39cRiYZTXTxej0DEzhLsbk29f/Ju6Q1dhbiIZKHif0Jge9b5 NVMKpLJ6iezFitxF4Rb1IXl0PONZMM1lb/Nn5UBDuIZDj1i90qceV4ILa1cp7W0ApqqQ lDq8NmAA+ns9tG4/ziQcePGcYhzwlxVcdOP444i01Ypm2DiwnzQP/fy3sb6pKX7fB1sV e4RQ== X-Gm-Message-State: APt69E2+3vRtBd5J+PCtiXnIlHf8sfE5IhmS2jwV0aYY8/dKpTrDijT3 gT/gSsjuCr4H1Gz7neElmUJBtLvHE9IyUfZcOXnAJ23R X-Google-Smtp-Source: AAOMgpfZ48l0chwMLqVbOy/N8Z0A8kg9aB/3AAZULHY3BCTU2SPaxBmAQllLG1lv/AEx/0SyuLphzVxdXEXGOiot5LE= X-Received: by 2002:aca:100f:: with SMTP id 15-v6mr88599oiq.110.1530668511395; Tue, 03 Jul 2018 18:41:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Wed, 4 Jul 2018 11:41:39 +1000 Message-ID: To: Brian E Carpenter Cc: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 01:41:55 -0000 On Tue, Jul 3, 2018 at 6:14 PM Brian E Carpenter wrote: > My main comment on this draft is that it proposes an experiment > without first explaining properly what the problem is and why the > proposed experiment might fix it. I agree that it's a weak point, though we might have different expectations about the degree of evidence required. We seem to disagree on the magnitude of the change, which means that we consequently are unable to agree on evidence. Stepping back a little, it seems that we are all collectively comfortable with "document that describes protocol X" existing, no matter the venue. Indeed, that is generally of benefit. Where the disagreement arises is in the (sometimes emotional, judging by some of the feedback here) connection to the label and what that label has come to mean to different people. "RFC" clearly means different things to different people. We could say "just a document about the Internet", and ignore the association with the 50-year history of the series and the aspects of existing documents that define our understanding of its significance. Or we could attempt to define the meaning more clearly. The draft in question (somewhat ineptly) attempted to describe a narrower definition than in our current understanding. I personally think that it corresponds more closely with how the series is understood outside of the inner circle, but have no firm evidence of that. I also believe that greater clarity of purpose has benefits beyond simply addressing the potential for misconception, as I separately described, but I'm happy to engage further on the question of defining what the label means first. It's probably necessary to get past the misunderstanding that this isn't attempting to suppress publications of non-standard things. If publishing cryptographic algorithms is considered important[1], nothing would change other than the name. [1] I don't believe it is, for all of the reasons ekr described. Also, iacr.org is a superior venue in many ways. From nobody Tue Jul 3 18:56:31 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF53130EAC for ; Tue, 3 Jul 2018 18:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 DlxGDFwMZ8po for ; Tue, 3 Jul 2018 18:56:26 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBEF127598 for ; Tue, 3 Jul 2018 18:56:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4E547BA0378; Tue, 3 Jul 2018 18:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1530669386; bh=BM560HSfXH8WI127wlu9LUMtEW6HB+vOlkhmk1A7O9E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=k/AqkUQw6kjD/G2JMNPWKJc+jJhproC0FSTEK2yLg3jBPQ1kFH4ckIbo97oPGPzQO YGsk5DgexMsxqrj5fcNaC7aOq/3JdoWOQq0Chbh7T5trn4cac5+xSuUYLIY1TfrIJF yvLPgY3pi+6POvTPa0KI9phuy6FekrrwVw7z7o7Q= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C8CECBA01A7; Tue, 3 Jul 2018 18:56:24 -0700 (PDT) To: Martin Thomson Cc: rfcplusplus@ietf.org References: From: "Joel M. Halpern" Message-ID: Date: Tue, 3 Jul 2018 21:56:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 01:56:29 -0000 I understand that your suggestion (proposal? idea?) is not attempting to suppress publication in any broad sense. However, you are proposing making a change to existing practice. You are proposing making this change to address a perceived problem. You are proposing that the change is an experiment. It seems to me that the onus is therefore upon you to clearly spell out what the problem is and how the proposed experiment relates to the problem. You agree below that the problem is not well-described. And it seems clear that the proposed measurements of the experiment do not relate to the problem that you are attempting to solve. Arguing that "it is a small change, so we should do it anyway" does not seem to me to meet the minimum bar for making a change to IETF process. Even if we agreed that it was a small change. Yours, Joel PS: Your text indicating that you consider some of the responses to be "emotional" seems to me to be irrelevant and inappropriate. On 7/3/18 9:41 PM, Martin Thomson wrote: > On Tue, Jul 3, 2018 at 6:14 PM Brian E Carpenter > wrote: >> My main comment on this draft is that it proposes an experiment >> without first explaining properly what the problem is and why the >> proposed experiment might fix it. > > I agree that it's a weak point, though we might have different > expectations about the degree of evidence required. We seem to > disagree on the magnitude of the change, which means that we > consequently are unable to agree on evidence. > > Stepping back a little, it seems that we are all collectively > comfortable with "document that describes protocol X" existing, no > matter the venue. Indeed, that is generally of benefit. Where the > disagreement arises is in the (sometimes emotional, judging by some of > the feedback here) connection to the label and what that label has > come to mean to different people. > > "RFC" clearly means different things to different people. We could > say "just a document about the Internet", and ignore the association > with the 50-year history of the series and the aspects of existing > documents that define our understanding of its significance. Or we > could attempt to define the meaning more clearly. > > The draft in question (somewhat ineptly) attempted to describe a > narrower definition than in our current understanding. I personally > think that it corresponds more closely with how the series is > understood outside of the inner circle, but have no firm evidence of > that. I also believe that greater clarity of purpose has benefits > beyond simply addressing the potential for misconception, as I > separately described, but I'm happy to engage further on the question > of defining what the label means first. > > It's probably necessary to get past the misunderstanding that this > isn't attempting to suppress publications of non-standard things. If > publishing cryptographic algorithms is considered important[1], > nothing would change other than the name. > > [1] I don't believe it is, for all of the reasons ekr described. > Also, iacr.org is a superior venue in many ways. > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > From nobody Tue Jul 3 19:02:17 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD08130F5C for ; Tue, 3 Jul 2018 19:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBDaX2fSQODy for ; Tue, 3 Jul 2018 19:02:02 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 48880130EAC for ; Tue, 3 Jul 2018 19:02:02 -0700 (PDT) X-AuditID: 12074423-e93ff70000002cd1-9b-5b3c2a99cf1f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 0A.FD.11473.99A2C3B5; Tue, 3 Jul 2018 22:02:01 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w64220YL015806; Tue, 3 Jul 2018 22:02:00 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w6421tbk009129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jul 2018 22:01:58 -0400 Date: Tue, 3 Jul 2018 21:01:56 -0500 From: Benjamin Kaduk To: "Joel M. Halpern" Cc: Martin Thomson , rfcplusplus@ietf.org Message-ID: <20180704020155.GB60996@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IRYrdT0Z2pZRNt8LpF2OLjqTdMFtfO/GO0 eLm9zoHZY+esu+weS5b8ZPI4N+U7YwBzFJdNSmpOZllqkb5dAlfGtb5XTAW/2SvmbuhmbGDc zNbFyMkhIWAicWPRavYuRi4OIYHFTBJ/Zp1lg3A2MEp8Wf6bBcK5wiTRsegbK0gLi4CKxOzO rWDtbEB2Q/dlZhBbREBbYv+SD0wgNrOAs8TLy6fAaoQFbCU+rzgFFucFWnfz9CWodXsYJW6t XMEKkRCUODnzCQtEs5bEjX8vgRo4gGxpieX/OEDCnEAz71/eBTZHVEBZYm/fIfYJjAKzkHTP QtI9C6F7ASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0zvdzMEr3UlNJNjODQdVHewfiyz/sQ owAHoxIPL0OFdbQQa2JZcWXuIUZJDiYlUV75jUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrz3 fgHleFMSK6tSi/JhUtIcLErivDmLGKOFBNITS1KzU1MLUotgsjIcHEoSvLGaNtFCgkWp6akV aZk5JQhpJg5OkOE8QMMPqgPV8BYXJOYWZ6ZD5E8xGnOcujdlEjPHn/dTJzELseTl56VKifN2 awCVCoCUZpTmwU0DpR+J7P01rxjFgZ4T5q0GWcoDTF1w814BrWICWtWzzRJkVUkiQkqqgTGG S0TykW9F+JaTN7w9K/Ql9Kv5/3/3WtPS2vjje87nSZ9vzC9brZVitNKruu+2v3Nfk+CL97Oq uHJTX5q8UDrVPvc4o6Dlx5gcvWXLnnXeKUk2NQxJF+sL5MqveL010tHMf77xjMjs1m/iHHkZ P2U3Xn62z2xe1G6XhOzKANdI5r5Sr98+SizFGYmGWsxFxYkA/QcKXRoDAAA= Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 02:02:16 -0000 On Tue, Jul 03, 2018 at 09:56:23PM -0400, Joel M. Halpern wrote: > > PS: Your text indicating that you consider some of the responses to be > "emotional" seems to me to be irrelevant and inappropriate. Is it? If one party sees an other party as generating responses driven by emotion (and thus, one presumes, not by reason), that seems highly indicative of a failure to properly communicate, regardless of whether the responses are actually driven by emotion. We are unlikely to make progress if we are talking past each other or getting annoyed by the other party's "irrationality", and recognizing that there is a difference of perception is a good start to resuming effective communication. Given the above, I'm not sure what argument would support a claim of inappropriateness. Of course, I should probably disclaim that some of the responses on this thread did seem (to me) to be at least partially driven by emotion; I must acknowledge the possibility that I am also in error. -Ben From nobody Tue Jul 3 19:07:37 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB02130E9A for ; Tue, 3 Jul 2018 19:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 nHD8n8nXYGwh for ; Tue, 3 Jul 2018 19:07:33 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E16130E74 for ; Tue, 3 Jul 2018 19:07:33 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id o2-v6so2110159qkc.13 for ; Tue, 03 Jul 2018 19:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BJQmEii0ilH5lZHxHeX1TPou4LB28sW1KRHeX0Q07jc=; b=V0v2hIm/u7l0QvbNqXbd5VlhpLri/S+DjP2L9FuSvMYXxuCZUTdpumVsRSwfotbU6Q daZ+Ho5AbyLTZil+zEL3a4/PRUR7EppPMJDm9JnrSxUq6bePrxQThfRj50IZCweqJdb4 ktrnLcI2UFBo7YWqik90T/u/oQQ89foXp4MmJdfpWT3hxn2913STDeidLyhUYTNxwzsw YJe8/bmo96gjNDMofKT+gQLmULOMakTXILiNsj6y6+m8db2tpxCC/TjSaYt4+A8LQY6V 5usyhpPzZ+A510XWLW9xeiSequwrTPQbmZfRPbme2nVQIPosjOVwXH0l/YAPK6XsDl6u AzYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BJQmEii0ilH5lZHxHeX1TPou4LB28sW1KRHeX0Q07jc=; b=Y3R1cpemYXLQ5leri1zKOKtJj/hGRWHZuzZYyByVB4w4GuHLp9CypVGl4TAOlF2Max cvEhb1c9h/zrdDuxS5CWLJpVyrBTbUTbFewmRiQah14uOZRguDt2g5SnU9nk18FRI2iz itb6Cxp+u2EZkO0v9egPH8QcHES7bzhGyAfzSLioFJMlC2WusMHwcA7eN3rGqqek2Zjs SwmW+VFQoQXRxGS/geaP3MZGJ4T5MfNo9ddGcyVdw48rPi+XRAK0mQ9GquUH9FcYWtmn ILMvsMd/uWtQn+MDGpSziYOCD+Ze6J4mALFmH1JV307trO9TE2KzrwsFE48P9trKlNdY mQFg== X-Gm-Message-State: APt69E0Sg0BAvgI+oLfnkBAwr8cOSUhnY7VtmZroKtMF3aGvr2PqVYiF 5LDQ1hF0w/NfF+g0VrU7hQk= X-Google-Smtp-Source: AAOMgpfT9ogLWW6G0LShX+UCVIoAAFpOB1/ilmBj+Dv5DtQIyhcL3gUloossRNvC6ZFS77ru/FIKVA== X-Received: by 2002:a37:209:: with SMTP id 9-v6mr68007qkc.267.1530670052599; Tue, 03 Jul 2018 19:07:32 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id h10-v6sm41318qtm.48.2018.07.03.19.07.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 19:07:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: <20180704020155.GB60996@kduck.kaduk.org> Date: Tue, 3 Jul 2018 22:07:31 -0400 Cc: "Joel M. Halpern" , Martin Thomson , rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1AF20B16-3B29-4431-B469-B36A0D4AE823@gmail.com> References: <20180704020155.GB60996@kduck.kaduk.org> To: Benjamin Kaduk Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 02:07:36 -0000 Sent from my mobile device > On Jul 3, 2018, at 10:01 PM, Benjamin Kaduk wrote: >=20 >> On Tue, Jul 03, 2018 at 09:56:23PM -0400, Joel M. Halpern wrote: >>=20 >> PS: Your text indicating that you consider some of the responses to be=20= >> "emotional" seems to me to be irrelevant and inappropriate. >=20 > Is it? >=20 > If one party sees an other party as generating responses driven by emotion= > (and thus, one presumes, not by reason), that seems highly indicative of a= > failure to properly communicate, regardless of whether the responses are > actually driven by emotion. We are unlikely to make progress if we are > talking past each other or getting annoyed by the other party's > "irrationality", and recognizing that there is a difference of perception > is a good start to resuming effective communication. >=20 > Given the above, I'm not sure what argument would support a claim of > inappropriateness. >=20 When your starting point on a thread is a document written with bias, respon= ses are bound to be emotional. Having a clear problem statement seems to be a= very reasonable request for a starting point. Kathleen=20 > Of course, I should probably disclaim that some of the responses on this > thread did seem (to me) to be at least partially driven by emotion; I must= > acknowledge the possibility that I am also in error. >=20 > -Ben >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Tue Jul 3 19:19:05 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318B9130934 for ; Tue, 3 Jul 2018 19:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=mYNluTWA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=F0OjUqov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG9I-fp7OFAT for ; Tue, 3 Jul 2018 19:19:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682B8127598 for ; Tue, 3 Jul 2018 19:19:01 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id BFAC021D4E; Tue, 3 Jul 2018 22:19:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 03 Jul 2018 22:19:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=3IJboCCDfv6yj9wGojL0o+LTb5eenbdRKndq+UMB+Bs=; b=mYNluTWA n0nBwdRMpWuxn5hqfTYX8wUPvfuDEYeNgzSlrcHHyyZucQmy0zltXU/S/YbHIeYT 7EtgOP/eMtDtSCudS8PNKEfArQvQy2nWHGzs+TTxtzCoo48ECUIeBLlJsS/bD+Dr cx+sJdSpc6f0+PNyX2EATwOIKpvH+RX/DisnRpVhI/M5+yo/wwOgG9XHF1SYc3Ar fDzdImOR8svCMgTxDO3ua9PEZWadpQJ3NUaKflpTZWqF3CFAzT8AhritVMf/6nLQ sQNYVLYPhBy+/4DtD4BEDWgSOH5Y/ds2WjBgYQVCmjeI4ndEHGnwC92n31QAxju1 puWOWv1A7o9ong== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=3IJboCCDfv6yj9wGojL0o+LTb5een bdRKndq+UMB+Bs=; b=F0OjUqov3YEcdCfdNl7yVOEO2O++wy6RJVkpMVFECRJBK EtHspheWMJNihC8EUzKk7jV+J4A5gQxSSnayxDIKyOk+XIYVYgCwmtlnUMOq4ilL pBYX5DPzB/MAzaEIgVjDmKvDJmn35z60tc2cC6dgBcKR++wewuJjR+koIqV8kEWt Y4MTmCpjOy0W3BVrummbX/sNT+jD1ooad1qPRR6aw62EoH2kSirXna8Flxghy9ba 04SViVk/gZ8eSPc3J0k5IRi7+6QTEyUpD7nSewo+h+mzw/QmMfv5M27kgFFJ0QyI oAFv7aUfdApAC4/Q6gN3b3dw3lSvjcdDfAzTmS11Q== X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.88]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F4E9E462C; Tue, 3 Jul 2018 22:19:00 -0400 (EDT) From: Alissa Cooper Message-Id: <3044F577-E367-44D5-BCE0-DE1E29EE6C13@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_C0FE6C19-61AB-459F-82DF-883F32604847" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 3 Jul 2018 22:18:58 -0400 In-Reply-To: Cc: Ted Hardie , rfcplusplus@ietf.org To: "Andrew G. Malis" References: X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 02:19:04 -0000 --Apple-Mail=_C0FE6C19-61AB-459F-82DF-883F32604847 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Andy, > On Jul 3, 2018, at 2:46 PM, Andrew G. Malis wrote: >=20 > Regarding your example of authors being financially rewarded for RFC = publication, I=E2=80=99m sure that would extend to any IETF publication = type if the IETF were to run this experiment, Why are you sure? I=E2=80=99m curious because this aspect has come up in = the IESG=E2=80=99s discussions of the proposed experiment, namely the = notion that a document with the label =E2=80=9CRFC=E2=80=9D is or would = be considered more valuable than a document with a different label. = (FWIW, I agree with Bob=E2=80=99s view that =E2=80=9CRFC=E2=80=9D is a = very strong brand.) Thanks, Alissa > thus this particular publication motivation would be unaffected by the = proposed experiment. >=20 > Cheers, > Andy >=20 >=20 > On Tue, Jul 3, 2018 at 2:28 PM, Ted Hardie > wrote: > On Tue, Jul 3, 2018 at 11:14 AM, Andrew G. Malis > wrote: > Not only am I in complete agreement with everything that Brian has = said here, but I would like to add that section 5 makes this draft one = of the most cynical documents I have read in a very long time. It makes = the inference that one of the primary reasons people publish = non-standards-track RFCs is to DELIBERATELY TAKE ADVANTAGE of any = confusion in the reader=E2=80=99s mind regarding the status of RFCs. >=20 > That's not quite what the document says. Here's the text: > One hypothesis this experiment proposes to test is the degree to > which the "RFC" label motivates authors seeking publication. = Though > numbers are unlikely to provide a clear answer when so much of the > problem is subjective, measuring the rate of submission and > publication for affected documents could provide some insight. > There are a variety of reasons that could go into that motivation; in = some companies, as an example, publishing an RFC is rewarded financially = in a way that an internal technical report is not. =20 >=20 > Joel has written on some of the difficulties in working out what to = measure here, and I appreciate any consideration you can give to that; = it's not an easy problem, but if there is no data to work from forward = motion on the basis of anything other than impressionistic anecdotes = will be difficult. >=20 > regards, >=20 > Ted >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --Apple-Mail=_C0FE6C19-61AB-459F-82DF-883F32604847 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Andy,

On Jul 3, 2018, at 2:46 PM, Andrew G. Malis = <agmalis@gmail.com> wrote:

Regarding your example of authors being financially rewarded = for RFC publication, I=E2=80=99m sure that would extend to any IETF = publication type if the IETF were to run this experiment, =

Why are = you sure? I=E2=80=99m curious because this aspect has come up in the = IESG=E2=80=99s discussions of the proposed experiment, namely the notion = that a document with the label =E2=80=9CRFC=E2=80=9D is or would be = considered more valuable than a document with a different label. (FWIW, = I agree with Bob=E2=80=99s view that =E2=80=9CRFC=E2=80=9D is a very = strong brand.)

Thanks,
Alissa

thus this particular publication = motivation would be unaffected by the proposed experiment.

Cheers,
Andy


On Tue, = Jul 3, 2018 at 2:28 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Tue, Jul 3, 2018 at 11:14 AM, Andrew G. = Malis <agmalis@gmail.com> wrote:
Not only am I in = complete agreement with everything that Brian has said here, but I would = like to add that section 5 makes this draft one of the most cynical = documents I have read in a very long time. It makes the inference that = one of the primary reasons people publish non-standards-track RFCs is to = DELIBERATELY TAKE ADVANTAGE of any confusion in the reader=E2=80=99s = mind regarding the status of RFCs.

That's not quite what the = document says.  Here's the text:
   One hypothesis this experiment proposes to =
test is the degree to
   which the "RFC" label motivates authors seeking publication.  Though
   numbers are unlikely to provide a clear answer when so much of the
   problem is subjective, measuring the rate of submission and
   publication for affected documents could provide some insight.
There are a variety of reasons that could go into that motivation; = in some companies, as an example, publishing an RFC is rewarded = financially in a way that an internal technical report is not. 

Joel has written on some of = the difficulties in working out what to measure here, and I appreciate = any consideration you can give to that; it's not an easy problem, but if = there is no data to work from forward motion on the basis of anything = other than impressionistic anecdotes will be difficult.

regards,

Ted


_______________________________________________
Rfcplusplus = mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusplus

= --Apple-Mail=_C0FE6C19-61AB-459F-82DF-883F32604847-- From nobody Tue Jul 3 19:26:13 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B077130DD0 for ; Tue, 3 Jul 2018 19:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=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 WDZWjPKDCBIR for ; Tue, 3 Jul 2018 19:26:10 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 10171127598 for ; Tue, 3 Jul 2018 19:26:10 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id e9-v6so1504424ybq.1 for ; Tue, 03 Jul 2018 19:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V7arZKnQ2ccQj+uHFY2pKm+igeBhEdR8whOdlY+WCPI=; b=NIruO786iQZiqCi44vcUHU9oSxdSD5ZGAbj1IlwqDH3YBgS+YSq9J26jwxd8sjgJgJ Eo6nmeSQwce2g6UsfxFIETNyG6XG29y9YOSYvCgV4RLFY6lomVkkPDxzL4gEH+EW/FFP Mm/E63+7o9PKbIL14QdJjHZp0i5v2I6Fc8DNyRCydtqBgo9wIQRVth1i5nlRL22RH9Kz UzrZOoJX9Zp4DZ7R6NBv9mSF0WjQIZLLj4XTa1/NjYhBnCKETArppKx79m0vEy4Tr0dg UELtozc/F911c4ZJWeVdG9aUNqDRt59jrIxIQlEhX32Nsr9FjFZRHOtVQ4utVC304ysN wgxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V7arZKnQ2ccQj+uHFY2pKm+igeBhEdR8whOdlY+WCPI=; b=eH3ZyzzIZLrLHo6cYlli/5N2KdNCHvkejMhvLQx6mPTxEeYeMh2AeHl9J5E6n8wrzZ 07W+TqblCnz7177NvmZkRo8bhqBgxws7aT7uO+mIjxJt0VHA2lxzyLYt1O8TU3BEuShe g0NgFnYHnWnVmCgzRzR/EvsPdJvEXetfAkKwKibiOvfZg2mYIKPczCuC20soa0JEw8Pl +pS4tnlQe7+Dk/0EMtAi7xp6zQ+fwvSsIMdR88hULXf+vTApc6gApKmWXrPzRQtrOmH8 +BtcnBVjKWoTnwWTVRDtDZd/8x6H07PxfXls9VoPLLb7qFwxvVYAYyrFkdsmwb9AC82W /nIA== X-Gm-Message-State: APt69E0DPyicY5fKqPjCnIExIEBO3NlBbkpnrtV14DT/H4xj0HykcwZc lX+l8KBZ8gDKYizbGYGscCEvYwKVXL0eoefnsN7IgQ== X-Google-Smtp-Source: AAOMgpeMwW3Cj7SPLAxAY0v6heV/jtQaz+rRwFU35CpBQmQ62BYAG8kBzschsnZI2IwyUb9nfCjGv3eFLcdnOE2wbso= X-Received: by 2002:a25:3496:: with SMTP id b144-v6mr71551yba.275.1530671169330; Tue, 03 Jul 2018 19:26:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 19:25:28 -0700 (PDT) In-Reply-To: <1AF20B16-3B29-4431-B469-B36A0D4AE823@gmail.com> References: <20180704020155.GB60996@kduck.kaduk.org> <1AF20B16-3B29-4431-B469-B36A0D4AE823@gmail.com> From: Eric Rescorla Date: Tue, 3 Jul 2018 19:25:28 -0700 Message-ID: To: Kathleen Moriarty Cc: Benjamin Kaduk , "Joel M. Halpern" , Martin Thomson , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000050f27b05702327ec" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 02:26:13 -0000 --00000000000050f27b05702327ec Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 7:07 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > Sent from my mobile device > > > On Jul 3, 2018, at 10:01 PM, Benjamin Kaduk wrote: > > > >> On Tue, Jul 03, 2018 at 09:56:23PM -0400, Joel M. Halpern wrote: > >> > >> PS: Your text indicating that you consider some of the responses to be > >> "emotional" seems to me to be irrelevant and inappropriate. > > > > Is it? > > > > If one party sees an other party as generating responses driven by > emotion > > (and thus, one presumes, not by reason), that seems highly indicative of > a > > failure to properly communicate, regardless of whether the responses are > > actually driven by emotion. We are unlikely to make progress if we are > > talking past each other or getting annoyed by the other party's > > "irrationality", and recognizing that there is a difference of perception > > is a good start to resuming effective communication. > > > > Given the above, I'm not sure what argument would support a claim of > > inappropriateness. > > > When your starting point on a thread is a document written with bias, > responses are bound to be emotional. Having a clear problem statement seems > to be a very reasonable request for a starting point. > I'm a little puzzled by the use of the term "bias" here. I take Martin's document to be a piece of advocacy for something that ought to happen. I wouldn't expect it to represent a neutral point of view and I'm not sure why people would be upset that it didn't. -Ekr Kathleen > > > Of course, I should probably disclaim that some of the responses on this > > thread did seem (to me) to be at least partially driven by emotion; I > must > > acknowledge the possibility that I am also in error. > > > > -Ben > > > > _______________________________________________ > > Rfcplusplus mailing list > > Rfcplusplus@ietf.org > > https://www.ietf.org/mailman/listinfo/rfcplusplus > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --00000000000050f27b05702327ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 3, 2018 at 7:07 PM, Kathleen Moriarty <= ;kath= leen.moriarty.ietf@gmail.com> wrote:


Sent from my mobile device

> On Jul 3, 2018, at 10:01 PM, Benjamin Kaduk &l= t;kaduk@mit.edu> wrote:
>
>> On Tue, Jul 03, 2018 at 09:56:23PM -0400, Joel M. Halpern wrote: >>
>> PS: Your text indicating that you consider some of the responses t= o be
>> "emotional" seems to me to be irrelevant and inappropria= te.
>
> Is it?
>
> If one party sees an other party as generating responses driven by emo= tion
> (and thus, one presumes, not by reason), that seems highly indicative = of a
> failure to properly communicate, regardless of whether the responses a= re
> actually driven by emotion.=C2=A0 We are unlikely to make progress if = we are
> talking past each other or getting annoyed by the other party's > "irrationality", and recognizing that there is a difference = of perception
> is a good start to resuming effective communication.
>
> Given the above, I'm not sure what argument would support a claim = of
> inappropriateness.
>
When your starting point on a thread is a document written with bias= , responses are bound to be emotional. Having a clear problem statement see= ms to be a very reasonable request for a starting point.

<= div>I'm a little puzzled by the use of the term "bias" here.<= /div>

I take Martin's document to be a piece of advo= cacy for something that ought to happen. I wouldn't expect it to repres= ent a neutral point of view and I'm not sure why people would be upset = that it didn't.

-Ekr

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Kathleen

> Of course, I should probably disclaim that some of the responses on th= is
> thread did seem (to me) to be at least partially driven by emotion; I = must
> acknowledge the possibility that I am also in error.
>
> -Ben
>
> _______________________________________________
> Rfcplusplus mailing list
> Rfcplusplus@ietf.org
> https://www.ietf.org/mailman/listinfo/rfc= plusplus

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus

--00000000000050f27b05702327ec-- From nobody Tue Jul 3 19:34:54 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA5D130934 for ; Tue, 3 Jul 2018 19:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HQzo3JOTRP2G for ; Tue, 3 Jul 2018 19:34:49 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E113D130DD0 for ; Tue, 3 Jul 2018 19:34:48 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id b15-v6so3394679qtp.11 for ; Tue, 03 Jul 2018 19:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jTRxHG68OeZRCavHYEl8kNsyA8Slidj2cVFeQinkGKw=; b=npXfN6+XkZRJg4lU3acFqmpfvMqybghUlU4HK8SUd1OKuIEGeUHhm08/kRpDoKH7Rx 8gfCjfXDOXxX4dIZSlCrFlp7nzs4CGhR/XTYpRoOVrGWitxfJYkunfZ5Va6na/lgEQcf OL2q39p4afya0d6uZXM03KRlLB102Q3A+zowestnC6RUVSr+Lf19nvyMbo2p6WnbA5XD OVN72g8zlaPqYmrW8XM7FMj5iEy8kfyTI8FY7xTZBT9Epgfp7pLXDVxKGpRACxH6ouYq TRTV31C7+hEpLD3I/FE3/v5Glwdxp2dm8xc+GStfLSgu4Z0u/WLwdR6eKdT55/hAuEdn ysNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jTRxHG68OeZRCavHYEl8kNsyA8Slidj2cVFeQinkGKw=; b=TWqimtOB4j6PJo/e0sK0em9vQaLhae4MFWQ1ZIT2++kwZTKPC+ZT157bPOkuTduMUU Jipz1lCkJQ/DIvzI5uc/eBtP9XVyugUnfu/hcsnCaUp3abglTdPcwyzYcxQfi2ja9eGN H/92J14uL4w4Je8icfH9BtZM5vqTubq0dh3Sv4tZcbVMUY952cgJ7aZ5k3+D1qdzzuIb ulr979KF5yXa1Gu6z8Z4roG7k3oyrGuABntxZopPxciYzIkk+goMvVyI1isvUX9i7rQu RCC4TnBOlx/sDip/E/NePUmCrIQSUp9HPPmR5t7ZwZLv9h8qAMOnMYaDtTpqMd1x8O12 1QuQ== X-Gm-Message-State: APt69E2gtP7uUwyJd7pDf2Rt4oVnxuhIiylKjqJQF5ovYqgh+kg6gXdp BZz/nWxhhylmtLuymMDFzeM= X-Google-Smtp-Source: AAOMgpcAi08PNBIw7c+/VM70pnZGWX09mI2mqTUbF02Pdccsr7VidHV2TdZH2OnBL8G1zTMLuFsC6w== X-Received: by 2002:aed:3fd5:: with SMTP id w21-v6mr144789qth.226.1530671688008; Tue, 03 Jul 2018 19:34:48 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id i1-v6sm1696454qtj.65.2018.07.03.19.34.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 19:34:47 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-50C73DFF-DA90-4B95-8609-90A3E4135046 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Tue, 3 Jul 2018 22:34:46 -0400 Cc: Benjamin Kaduk , "Joel M. Halpern" , Martin Thomson , rfcplusplus@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <4D56C8AE-4A54-46E2-9AEF-A9757AE7634C@gmail.com> References: <20180704020155.GB60996@kduck.kaduk.org> <1AF20B16-3B29-4431-B469-B36A0D4AE823@gmail.com> To: Eric Rescorla Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 02:34:52 -0000 --Apple-Mail-50C73DFF-DA90-4B95-8609-90A3E4135046 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my mobile device > On Jul 3, 2018, at 10:25 PM, Eric Rescorla wrote: >=20 >=20 >=20 >> On Tue, Jul 3, 2018 at 7:07 PM, Kathleen Moriarty wrote: >>=20 >>=20 >> Sent from my mobile device >>=20 >> > On Jul 3, 2018, at 10:01 PM, Benjamin Kaduk wrote: >> >=20 >> >> On Tue, Jul 03, 2018 at 09:56:23PM -0400, Joel M. Halpern wrote: >> >>=20 >> >> PS: Your text indicating that you consider some of the responses to be= =20 >> >> "emotional" seems to me to be irrelevant and inappropriate. >> >=20 >> > Is it? >> >=20 >> > If one party sees an other party as generating responses driven by emot= ion >> > (and thus, one presumes, not by reason), that seems highly indicative o= f a >> > failure to properly communicate, regardless of whether the responses ar= e >> > actually driven by emotion. We are unlikely to make progress if we are= >> > talking past each other or getting annoyed by the other party's >> > "irrationality", and recognizing that there is a difference of percepti= on >> > is a good start to resuming effective communication. >> >=20 >> > Given the above, I'm not sure what argument would support a claim of >> > inappropriateness. >> >=20 >> When your starting point on a thread is a document written with bias, res= ponses are bound to be emotional. Having a clear problem statement seems to b= e a very reasonable request for a starting point. >=20 > I'm a little puzzled by the use of the term "bias" here. >=20 > I take Martin's document to be a piece of advocacy for something that ough= t to happen. I wouldn't expect it to represent a neutral point of view and I= 'm not sure why people would be upset that it didn't. >=20 I was responding to 3 people on the IESG complaining that responses from the= community were emotional with an explanation, nothing more. Kathleen=20 > -Ekr >=20 >> Kathleen=20 >>=20 >> > Of course, I should probably disclaim that some of the responses on thi= s >> > thread did seem (to me) to be at least partially driven by emotion; I m= ust >> > acknowledge the possibility that I am also in error. >> >=20 >> > -Ben >> >=20 >> > _______________________________________________ >> > Rfcplusplus mailing list >> > Rfcplusplus@ietf.org >> > https://www.ietf.org/mailman/listinfo/rfcplusplus >>=20 >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 --Apple-Mail-50C73DFF-DA90-4B95-8609-90A3E4135046 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent= from my mobile device

On Jul 3, 2018, at 10:25 PM, Eric Resco= rla <ekr@rtfm.com> wrote:

<= /div>


On Tue, Jul 3, 2018 at 7:07 PM, Kathl= een Moriarty <kathleen.moriarty.ietf@gmail.com>= wrote:


Sent from my mobile device

> On Jul 3, 2018, at 10:01 PM, Benjamin Kaduk <= ;kaduk@mit.edu> wrote:
>
>> On Tue, Jul 03, 2018 at 09:56:23PM -0400, Joel M. Halpern wrote: >>
>> PS: Your text indicating that you consider some of the responses to= be
>> "emotional" seems to me to be irrelevant and inappropriate.
>
> Is it?
>
> If one party sees an other party as generating responses driven by emot= ion
> (and thus, one presumes, not by reason), that seems highly indicative o= f a
> failure to properly communicate, regardless of whether the responses ar= e
> actually driven by emotion.  We are unlikely to make progress if w= e are
> talking past each other or getting annoyed by the other party's
> "irrationality", and recognizing that there is a difference of percepti= on
> is a good start to resuming effective communication.
>
> Given the above, I'm not sure what argument would support a claim of > inappropriateness.
>
When your starting point on a thread is a document written with bias,= responses are bound to be emotional. Having a clear problem statement seems= to be a very reasonable request for a starting point.

= I'm a little puzzled by the use of the term "bias" here.

I take Martin's document to be a piece of advocacy for something that o= ught to happen. I wouldn't expect it to represent a neutral point of view an= d I'm not sure why people would be upset that it didn't.

<= /div>
I was responding to 3 people on th= e IESG complaining that responses from the community were emotional with an e= xplanation, nothing more.

Kathleen 

-Ekr

Kathleen

> Of course, I should probably disclaim that some of the responses on thi= s
> thread did seem (to me) to be at least partially driven by emotion; I m= ust
> acknowledge the possibility that I am also in error.
>
> -Ben
>
> _______________________________________________
> Rfcplusplus mailing list
> Rfcplusplus@ietf.org
> https://www.ietf.org/mailman/listinfo/rfcpl= usplus

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusplu= s

= --Apple-Mail-50C73DFF-DA90-4B95-8609-90A3E4135046-- From nobody Tue Jul 3 20:04:20 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8349A130DD1 for ; Tue, 3 Jul 2018 20:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=rLCidVaU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=t8bOj0LY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At0mG93JFqqE for ; Tue, 3 Jul 2018 20:04:16 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F08130934 for ; Tue, 3 Jul 2018 20:04:15 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2F18E21C47 for ; Tue, 3 Jul 2018 23:04:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 03 Jul 2018 23:04:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=gv4WyR5XkV4mo84mr0IBy4aLeh9Dn7koUwCWWCHmIgo=; b=rLCidVaU VDJi78MudmSEnGDRzetgWWy7yqMGYMPKjqZyRHkOZ3vTCmutFqikXpR9AgwAe+VE TWQImVCKST+GlXMWs7HxfhZZn5bqKh6rRoxBvld3Sf+NVLC3byaM1QXt7iJkY+eU Jlvi05uriRKwhis7M4DUOWIZJHjZK4k/yQlrLarrXNMN2CTj9MZh7iUVt2/3cC4W VMe/jo17g+Pf9Ul9sSliXd9C7+wbpA7NDPfZWcBLH+20sSMSOmHESTeURFmmKPz2 zyKkbnaL+0S/Ff7kxBABvp8D63hJwxbQhUwAa8NeQGYoej0LDLD65Pw8SgcvSsKp h9kdS/KE7YHW+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=gv4WyR5XkV4mo84mr0IBy4aLeh9Dn 7koUwCWWCHmIgo=; b=t8bOj0LY+ll/jXcv0YEyMMsTaw7bqsbkox3M2mtctdYYp Mv0RaN2VBNbwrZPQlivAByQGkAbGzhI/MB2RSdjAqNtLD8UxJnBJ0pBm5NrCpMk+ ECWrxGHyU+iOmvQhtw2uzMPj0D52Z1weN+SSahZbaoE8Iz5o7NAL1XH9BjaKsWNP CkiSiGmFu07Fsp2mQ3Cd+4TwyF6WBeeA9gPsIEOMrm8XRi0BRC1nmt1o7kdbQtuz blgE/7G/jDZ8UhwC+L3jdMTmXT88piSBGvEftf/0vppQ+NBEXw35qlLB7EZlSG98 QUrov9f8RFbD2svna3gUdr+WneSYB7IrNECNr01xA== X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.88]) by mail.messagingengine.com (Postfix) with ESMTPA id B565210261 for ; Tue, 3 Jul 2018 23:04:14 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: Date: Tue, 3 Jul 2018 23:04:12 -0400 To: rfcplusplus@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Rfcplusplus] Problem statement and BOF scope X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 03:04:18 -0000 Our BOF chairs are taking some much-needed rest after a busy period on = the ISOC Board of Trustees, so I wanted to jump in with a few notes to = guide the discussion. Some people have asked for a (clearer) statement of the problem. The = first two paragraphs of the BOF proposal do provide a statement of the = problem, and I will admit that it seemed fairly clear to me when = approving the BOF, particularly with the grounding in RFC 1796. But some = people believe it is under-specified or disagree with it, both of which = are perfectly fine. There has been a good amount of discussion of = problem statement already and IMO it is fine for that to continue into = the BOF itself if necessary. While the BOF proposal describes a specific experiment, the discussion = on the list and at the BOF need not be limited to that specific = proposal. It need not be limited to experiments at all, and I=E2=80=99ve = been glad to see people proposing both experimental and non-experimental = alternatives. As I implied in a prior mail, if I put on my hat as the = stream manager for the IETF stream, I would personally be more = interested in making non-experimental changes because I don=E2=80=99t = think defining exit criteria for most of the proposals we=E2=80=99ve = seen is feasible. Lastly, I think it=E2=80=99s helpful to remember that people are = participating in this discussion because they care about making the = Internet work better. Few participants relish this sort of topic and yet = everyone, I believe, is acting in good faith. People may have wildly = differing notions of what =E2=80=9Cworking better=E2=80=9D looks like = =E2=80=94 in the IETF, I would expect nothing less! People=E2=80=99s = opinions may differ but I don=E2=80=99t believe their underlying = motivations do. I will keep that in mind and I hope everyone else does = too. Thanks, Alissa=20 From nobody Tue Jul 3 21:54:05 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175FE130DEF for ; Tue, 3 Jul 2018 21:54:04 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 zmTNcaRYdb-E for ; Tue, 3 Jul 2018 21:54:02 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 A1217130EA4 for ; Tue, 3 Jul 2018 21:53:59 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id b1-v6so957466pgu.5 for ; Tue, 03 Jul 2018 21:53:59 -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=38dUdEeB9lRIuVIxaZ3eXb5oZlfN2WU5uAvmKUw3RNA=; b=FgX2viGJ4QjW14TeyrXi7dnVWy0+1DRRM7W/sWVJQ2PDgzXa2G5/Ebxg1wgcLSulYQ Yaw0UU4vAGYm8cNzRJnyzGm+H5dp40Qu3c/3gyPe7migJWD5c6VQIKIQ13S1rQDlf9Fp U24KrqcK0c2DqTqI+hn7vWa51PkrjGjjMr+hSTfhznSh/PetT++jyCMSuK5RgsVySVuh qjDiW4DaxKwT6ArLyt6S+HY2IKao7M/Zo9FJrZ6G+W3qyjH4Y6XmcF2bsfkiDX5KYVBk O8VneVd7lcGhXicmvMCvQsHHZrSRswYAS14sMWabvSAoYI6ul11ZdEw4uj3/l2ZzlquI cjPA== 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=38dUdEeB9lRIuVIxaZ3eXb5oZlfN2WU5uAvmKUw3RNA=; b=nOgduLr/HPu5DQOmSB3QdrV0tbnpy7TUGYYLNfUglaQ+I7L4UJ1yTGI/XZuvlIqqqG PxuyA46X7Wu0yPF+IZtmyWWz3l/3MyHCkYPpJhh2SKIa7Ws+U3OHu73/IP3OwfPvNqz3 nIz8B0G5NvhiZl/NKNtbpIX7ZyTFvR+QOuNdwQq8h44ioH+VfgQBkrkvENiyS5qoT1kM s9vxYPdSlzk7vYRSw1ItisPUXEojhmIUMANwQ+cFo/O4P79PDlZPZlZJAx9bDGy3QJKU bpWLHKcAMjoYbCC7uXKGtIe/rxJe+0a9a9yLZU+9WIGOpqtR/VrdNizKntJd6gDSxdVw ZovQ== X-Gm-Message-State: APt69E0/0zOhjAErMnqQd2J5tKaMRdVRFmVSS60bpYN8qx0rm1s88JCR 5uPv5KT9+gVG3ryYI5zxHQUBmg== X-Google-Smtp-Source: AAOMgpeyPuRYjBf8+SqtnxR7/P3w7r2AVBRpjVN/RTIuV1KvArsQ1zDvX0XeH1Ttpzv5QJg1pycMbw== X-Received: by 2002:a65:4b0f:: with SMTP id r15-v6mr498285pgq.103.1530680039040; Tue, 03 Jul 2018 21:53:59 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id s22-v6sm4675979pgs.34.2018.07.03.21.53.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 21:53:58 -0700 (PDT) To: Ted Hardie Cc: rfcplusplus@ietf.org References: From: Brian E Carpenter Message-ID: Date: Wed, 4 Jul 2018 16:53:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] FYI series[was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 04:54:04 -0000 On 04/07/2018 04:14, Ted Hardie wrote: ... > Eliot's pointer earlier today to the FYI series is instructive--the FYIs > reused the RFC series in part because the distribution mechanism was well > understood and well developed: > > There are several reasons why the FYIs are part of the larger RFC > series of notes. The formost reason is that the distribution > mechanisms for RFCs are tried and true. Anyone who can get an RFC, > can automatically get an FYI. More importantly, anyone who knows of > the RFC series, can easily find out about the FYIs. > Given that there are many other distribution mechanisms available > today, we do not have to treat the RFC series as > the only place where such documentation can take place. That is true. This is why the ION series was kept separate from the RFC series - because distribution-by-web-page seemed necessary and sufficient for the purpose, at the time the ION series was invented. Web pages weren't an option when the FYI series started. However, I think it's rather orthogonal to the question of what types of document are suitable for inclusion in the RFC series. Brian From nobody Tue Jul 3 22:05:56 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCCD130E1A for ; Tue, 3 Jul 2018 22:05:53 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 hBZue4VZDq-H for ; Tue, 3 Jul 2018 22:05:52 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0437B130DEF for ; Tue, 3 Jul 2018 22:05:52 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id k1-v6so2090311plt.2 for ; Tue, 03 Jul 2018 22:05:52 -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=ipntcj+v4i02m9hTnW8yq9mE+6QaMJ17hKX9jzC4emE=; b=HU0IN6aNklSlqrynjB1P9achYIrOB2LC/33wmF4XqNSOghOOrb4kzlbsEpVExL8dCf 7kRH+Wl/6oEOSquC3rQM3fztUM5caX0cZukpxVg2TJpAt5hDd8cRFbgaOBDqVWJtq1VB ekZ9pXC98VN1dWeL9JPrVlY2s/MXTb5nVmuOEsWnio1Yall71agKbYyYCBS0HZoQUBwQ Ztxvl2880P/panWn3bvaJOrwi2aGBbmiLWUYmYPg17maSGvDPdpNVE61UFtIQ3OzvQvE DvzUE/yvUlBLD4KblLWxZHq7elea5zkJiS6yJm6XHDIxop+/GtwQH79nPTPmire/KvOE ak+A== 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=ipntcj+v4i02m9hTnW8yq9mE+6QaMJ17hKX9jzC4emE=; b=CKTznhzjm4uzsxIgUIJItZQw8GPFzIYkfRFkSsFNxN4woSzMlZGFsepvinlt1fEr6S DT4YRhsVkRoNbLNy2V8Ui1yLb1vD2DoGr9WDWZTZhKW2ldjIB0Fvs8+C/PCyNBOLTdVI 4M614yMNMj2DOJFfS70mnzCu1XPEs3FPOHFO4wA+MYUr/eqOZCpTw5VsGnmHl+oUHbp3 rht50Cy/FB4SpKXStTSnCt5aOz1/0Pc93dcMAei/f9G/O+ysi0xpILEz4+anpjlkOsx3 FTZSFvivs/DjMsK+QAh9qhLpN+zZv+YrKMah8rjyXAngkxTI3D7kyy674qc5qeC/CWvV gsnQ== X-Gm-Message-State: APt69E28UKcT5ZF60VanhW7actA62/6iAy55ANDKcjENogb+yX2/ychY VNyVWNYw54oOAAed5L9maddD2Q== X-Google-Smtp-Source: AAOMgpe3fz/Ooay+Ze3p/iujGa5OVTQ5WrePAJAmGH+l3Q1UVJH/Y3fLmBiRQqphRKj0b30LINYWIA== X-Received: by 2002:a17:902:e85:: with SMTP id 5-v6mr598713plx.318.1530680751206; Tue, 03 Jul 2018 22:05:51 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id o4-v6sm6624988pfa.128.2018.07.03.22.05.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 22:05:50 -0700 (PDT) To: Ted Hardie Cc: rfcplusplus@ietf.org References: From: Brian E Carpenter Message-ID: Date: Wed, 4 Jul 2018 17:05:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 05:05:54 -0000 On 04/07/2018 04:14, Ted Hardie wrote: > On Tue, Jul 3, 2018 at 1:14 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Isn't it *always* better to document something which is deployed, whether >> it's good >> or bad? >> > > I believe that a number of your questions are ill-formed, and that the one > I highlight above illustrates this problem best. The question is not > "should X, which is deployed, be documented?", but "Should the RFC Series > contain the documentation for X, which is deployed?". Of course that's the final question. But before that there's another question: what is the audience that we (for some value of "we" != "the IETF") are trying to reach? In my opinion it's the entire technical community, most of whom will never attend an IETF meeting or even join an IETF mailing list. Who needs to know about some widely deployed and totally obnoxious protocol that is different from the IETF standard? Everybody deploying or operating a network where this protocol might appear. In most cases, these people simply will not care about the document's formal status or who approved its publication. They will, however, be grateful for all such documents being in a similar format and obtainable from the same place. However, I full accept that my litany of questions was careless and probably incomplete. After all, my point is that we simply haven't done a problem analysis, and here we are asked to debate a point solution. > If X was specified by the IETF, then the answer is yes, it should be > contained in the IETF stream of the RFC Series. In the small number of > cases where it was specified by the IRTF, then it should be contained by > the IRTF stream of the RFC Series. The IAB stream could also theoretically > produce an protocol specification that was deployed (though current > practice is to bring any work of that type back into the IETF). Those > streams are, in other words, set aside as publication outlets for specific > bodies. > > The Independent stream is very different, in that the ISE is meant to > exercise editorial discretion for publication and clearly could not publish > documentation of everything deployed even if it were made available to the > stream for publication. Indeed. But I think that the universe of potential submitters to the Independent stream must do a lot of self-censorship, because the reality is that most drafts that show up for review (i.e. have got past the ISE's sniff test) are at least related to layers 2-4 or to an application protocol that's recognisably general in nature. Brian > To illustrate that impossibility, note that there > are approximately 2 million apps in the Apple app store, according to > published reports; just documenting which ones used what variants of HTTPS > *alone* would dwarf the output of the ISE (240 pages in 2017 outside of > April 1st RFCs, according to email from Adrian). > > Eliot's pointer earlier today to the FYI series is instructive--the FYIs > reused the RFC series in part because the distribution mechanism was well > understood and well developed: > > There are several reasons why the FYIs are part of the larger RFC > series of notes. The formost reason is that the distribution > mechanisms for RFCs are tried and true. Anyone who can get an RFC, > can automatically get an FYI. More importantly, anyone who knows of > the RFC series, can easily find out about the FYIs. > Given that there are many other distribution mechanisms available > today, we do not have to treat the RFC series as > the only place where such documentation can take place. > > regards, > > Ted > From nobody Tue Jul 3 22:17:59 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E780130DEF for ; Tue, 3 Jul 2018 22:17:57 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 7In8s5vsWrJM for ; Tue, 3 Jul 2018 22:17:55 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4B8130DEC for ; Tue, 3 Jul 2018 22:17:55 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id e11-v6so1977480pgq.0 for ; Tue, 03 Jul 2018 22:17:55 -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=tzPMxyc8jqejYmX5T9mATul91e+1zDr+XRhBCSClOls=; b=mYbIXflxF1QfGE92OvJMMtjXPwPeobGNQhOHTGe/azPXU8fbmYW8Kq/k0ln779lzDu Sq/170BuCfGdQsvWh7LiaHogii/JgGs+p2t9JSjkNgjou5EDRWeKAZPCNqx7N0l+Te8r Mhpqp1L/mqaVqaaH2AYq3fVZ5KZ0MZF/M178G8nS8qAD3YRdS6uvpenpkPCbDz+OeksB 3v9/grmfa0cXix+YITTKyfBnvGg8DDZ2zVKGHHvTROX2t0FRK9epw0J5JzpVbXyYXOG2 aDTGwy4ikLe56C8qpdypYNErfk6U2wBe716fbpby/VTuCmy6lj4ro/bJP4Wr+vNPoQFf RjSQ== 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=tzPMxyc8jqejYmX5T9mATul91e+1zDr+XRhBCSClOls=; b=Z3q19cTrgDqDk3w4+Sb30VePCwmFCQrbpjAKCs8Ps7QT0Jq4IojmnrI+fgsdgYagxN H4yBXDilphct+0PYyRWb/xXbw85Clhn638WNLOx+mI8jRt4vTN62GUelZQ4KzNe1ZDrv srIm1cJX99QP/69hi++dFZEihmmVhBjVIySnAzUgwCSQrIlpMUrcDa4UMxzsbPY0w6k0 uYewv+szPLQqvmVXtKvLUu+SCbs8EapHbwEbvKzGjaIml3FxjJelc2ku8a39eHlsw+Y2 R4dfE5Uu5aYLRz6Fdhsrd2bWYXJLW7sMKYXgGlvjocotZ/jrJxm/5q7y7cIwjNcedmTf WBGA== X-Gm-Message-State: APt69E0z6EYVx11pWtEFI24Y80mPekwOUoT84qi+j9xLBJ5G62D42sKC yjS+ID3Jl47N3+W8NzgIWomN8A== X-Google-Smtp-Source: AAOMgpcAH8dshHfBLG8mt624wBjr7NN4zDagKIaiUiCedRehqxd3ybtvYP1h3hK5eJC9KlpIoU8Pew== X-Received: by 2002:aa7:8591:: with SMTP id w17-v6mr632593pfn.77.1530681474707; Tue, 03 Jul 2018 22:17:54 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id i17-v6sm5190315pfj.95.2018.07.03.22.17.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 22:17:53 -0700 (PDT) To: Eric Rescorla Cc: rfcplusplus@ietf.org References: From: Brian E Carpenter Message-ID: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> Date: Wed, 4 Jul 2018 17:17:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 05:17:57 -0000 Eric, Thanks for that substantive answer. To be frank I'd rather leave the response to someone who understands more about crypto deployment than I do. It does seem to me that for national algorithms, they will be in the libraries anyway because they will be mandatory procurement requirements. For algorithms that are not in procurement requirements, it clearly doesn't matter in the same way. Regards Brian On 04/07/2018 08:42, Eric Rescorla wrote: > On Tue, Jul 3, 2018 at 1:14 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>> 6. Security and Privacy Considerations >>> >>> It is believed that there are none. >> >> Given how many of the Independent Series RFCs are about >> crypto algorithms and the like, potentially interfering with >> that publication channel seems to pose a risk. >> > > Hi Brian, > > I agree that many of the IS documents are security-related, but I > don't think that failing to publish them in as RFCs would have a > significant negative impact on security. > > Looking back on the past 5 years or so of IS RFCs, the following > seem to be "crypto algorithms and the like" [0] > > RFC 7076: P6R's Secure Shell Public Key Subsystem > RFC 7091: GOST R 34.10-2012: Digital Signature Algorithm > RFC 7906: NSA's Cryptographic Message Syntax (CMS) Key Management > Attributes > RFC 8235: Schnorr Non-interactive Zero-Knowledge Proof > RFC 8236: J-PAKE: Password-Authenticated Key Exchange by Juggling > > RFC 7076 and 7906 look to me to document protocols which are in use by > some organization but which are not in wide use. This is one of the > 4846-defined uses of the Stream (Informational publication of > vendor-specific protocols) but I don't think that the security of the > Internet would be materially harmed if they had not been published. > Neither is cited by any I-D or RFC. > > RFCs 7906, 8235, and 8236 document algorithms that the IETF has not > shown significant interest in using. > > - 7091 is a national signature algorithm, and the IETF has instead > converged on ECDSA and EdDSA. > - 8235 is a ZK-proof system which isn't employed by any IETF > protocol (there is one Informative reference in an individual > I-D, but it's just an example). > - 8236 is a PAKE system, but not one that the CFRG is converging > on, and again not used by any IETF protocol (cited as an > example by the same I-D). > > In my opinion, it would not be a material loss to the security of the > Internet if these technologies had not been published as RFCs. > > > I was actually a bit surprised at how few algorithm drafts had been > published recently. Going back a further, it seems to me that the > algorithm drafts fall into two main categories: > > - Documenting algorithms which are in wide use but just didn't > have a formal specification (e.g., SHA-1, Base-64). > - Documenting algorithms which the IETF didn't have much interest > in and haven't seen much adoption (GOST, Brainpool, Rabbit, > ARIA). > > In the former case, I think we now have ample mechanisms for > publishing those documents without the ISE. Specifically, we now use > the CFRG both to review and to publish those documents (cf. X25519 and > ChaCha/Poly1305). Amusingly, I wasn't even aware that there *was* a > SHA-1 RFC; TLS, for instance, cites the FIPS rather than this RFC. > > In the latter case, I don't think that having these documents > published in the RFC series significantly improves security over some > other stable reference, at least in part because the IETF would to > some extent prefer that they not be implemented in IETF protocols (as > opposed to the algorithms we do recommend). > > Arguably, taking these algorithms out of the RFC Series makes matters > somewhat better because it reduces some pressure to implement them in > libraries. I guess that might be a useful thing to say? > > -Ekr > > > > [0] Ignoring stuff like DMARC which seems to me to be in a different > category. > From nobody Tue Jul 3 22:21:38 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D58130E1A for ; Tue, 3 Jul 2018 22:21:35 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 N1gbPd2SgPG6 for ; Tue, 3 Jul 2018 22:21:33 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FBE130DEF for ; Tue, 3 Jul 2018 22:21:33 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id q7-v6so982610pff.2 for ; Tue, 03 Jul 2018 22:21:33 -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=QxgajPjbrzKy5YoCsMXpzx8Oh2XMHFE+Tc23VoRhbFQ=; b=rzoZvVaz+96nPMXabe0LS0zUdj3ASfbiuIbQ4+06oY+gsVm7qe0QZorfZGjnjPCNnH r3l3sxn3DuEfFX5OwRIMlMuZT2ZI6slyzJLpRf7CDEbgxdhkcCPDflx+R/kHEy9sS23x jbap9hLWgPIPgi/Z/zfc5tPC3xJB3zTEGo1LAKvBLw38RZZXQvZHyK3crTlWcGGgHagE tz557POStXLieHy0Q9PLtv1sFZt9IVmBMvz7/ECxDgZzgSAmHaIYv7Z1Wqa8P4iGObNt fuxrHO4lqh+yHObmQXQbm4uKp6MU6m+1VtPAQciJqy3bV+x6alfFoacnArwDsHGGsNxf 7MfA== 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=QxgajPjbrzKy5YoCsMXpzx8Oh2XMHFE+Tc23VoRhbFQ=; b=XJIJaiiX/xJ0jFxiIeSZfVnktern7K4Zrcjwv4y2sW/vKswpeAEj4XnLLDVoW8+IZG p/F6YEzxCIqmztdfbOWoO04s+G5GjoPQedIWPi4MZeifAujkl7q+KuB4vfZDAFPcf0Su xsoeCC8VmhDdu1tNLOUyNBNSDage33wC6pxbYZSWWQlimdZRAfAa2v1NmbO8IHwmL804 OUlwmHJlHncaWybzETpIsnZT3o8l3YrW9Dl1m9CB18U0bZoa0UqNrLeQu5sGctBDmnT6 BgVro/z2utzqcjm7uNmRSWafzFeZm9387bp/3sQUBeuuLz75AUn0gpwzpWO6LfeXAZkK 8+nQ== X-Gm-Message-State: APt69E2l990A+fFl/lu6ymsFyjbpglKjHpYb2dSLfM00EEAfyNVMlDMQ qctEwydrdlvC7lmKQ3i/U7Y42A== X-Google-Smtp-Source: AAOMgpcKhk2+SNmwpRkGP+XASGstps+qo/jpHeDeRDClmhh8Aw1MjX6b7Vr2n5wSdFQ0WeBsD+bT8w== X-Received: by 2002:a62:6147:: with SMTP id v68-v6mr640101pfb.115.1530681692789; Tue, 03 Jul 2018 22:21:32 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id k12-v6sm4359034pff.31.2018.07.03.22.21.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 22:21:31 -0700 (PDT) To: rfcplusplus@ietf.org References: <775E9251-EDB7-4D13-87D4-B6018CC0BC20@gmail.com> From: Brian E Carpenter Message-ID: <9b7b90f7-5c00-40eb-8586-f7920c92db80@gmail.com> Date: Wed, 4 Jul 2018 17:21:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 05:21:36 -0000 On 04/07/2018 10:15, Eric Rescorla wrote: > On Tue, Jul 3, 2018 at 3:02 PM, Bob Hinden wrote= : >=20 >> Hi Ted, >> >>> On Jul 3, 2018, at 1:08 PM, Ted Hardie wrote: >> >> I note that RFC 5434 goes to great length to have a BOF focus on the >> problem, and not get into solutions. I continue to be surprised that= this >> was approved in it=E2=80=99s current form. >> >=20 > Hi Bob, >=20 > RFC 5434 is an Informational document, not a BCP or a PS. So, while it = may > have valuable advice, it doesn't really bear on whether the IESG should= > have approved the BOF. Incidentally, I had to look up the RFC to see it= s > status, which seems to illustrate how this is a source of confusion. iirc 5434 was published as an RFC after an early life as a random web page, but not made a BCP because although it set community expectations it just didn't feel like it should become a set of rules. Of course the reason it was written was a history of too many noisy, unproductive BOFs, especially ones with solutions presented before people agreed on a problem. Brian From nobody Tue Jul 3 22:27:47 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5FE130ED4 for ; Tue, 3 Jul 2018 22:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKVxy6WFJx8e for ; Tue, 3 Jul 2018 22:27:32 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A233130EEB for ; Tue, 3 Jul 2018 22:27:32 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id bi1-v6so2100165plb.12 for ; Tue, 03 Jul 2018 22:27:32 -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=3cFnNBTiReap+NB9mFUR8MuvU4/VXrpqhgWIE4ORrq4=; b=B41FjSIMKmPetpdKvPvCjqKtNe0EQX+6lxJG4tVzFzHKvYQndnQGrRNO/BAA2okB6s /O/SQNM3LoXKakMeAMc1JeTq1yP/OSpiWIwo0UJtPK8GTraGWd1atTLWatB/oPv1dN6N U5PnqnoWdk1FEzEn4udtiiLg1RSQA9IrUKeDnnRCH49+b4FMeF1vt7sBEt9OMdk0LE+/ gxrg12KYe3AnTfSQc9873bsj45GXpJtoZnzhfRNrWborwJvAKuC5nSOjV2EjPEKMd2F3 RnqVjQXfL+V6Lpp2TV64xNv9KuR9wsA3Y7Suvujkga7PMV6NflMtruM+NTTxiGTpwkwa UBgw== 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=3cFnNBTiReap+NB9mFUR8MuvU4/VXrpqhgWIE4ORrq4=; b=W7oYDAwGov+nI7QytQcUUTXdAzp1WWwUNzGtngZJrzPcBD0M/M9dgBpa9FyITBRxgG TpRFtM8K878oHpqJLkqyTfrdhJVB9LC7iRSsl9QbTsofcSbV/YsJjszLlXhP9uMtckeo /cOAYMesJO/vMVVu8diAcnqFhImHdnaF4jNRBOy+HWUUrMCCaV4zC1eF7r1X1LcsC1f1 VlXGKYQZm+19ZCYrW2AlLP6r1QGyKinZB7ckPaD3wy8ayCUUUY4+7x7/IzDUycKxFeGs LPiUqlSgon7u4eRojnyZJ6Dg0kNKYY6sNa4T4hzjyJKxNL2FxvP3W3tr02jUbC2EQBtX 8PTQ== X-Gm-Message-State: APt69E33SpcWA/WLDAQ3tgbVgwLR2A5u7RuJVOsZyVjC86v4BQd71Q9Y sanf2R3jufXRF0obnrz2Z1ORjA== X-Google-Smtp-Source: AAOMgpce5025CYyE1dnjC1tcXuKBoumOHWFyFRfbAFtxXe5GNe8ZZXM2fzj7PcgVTAMhrBRV4TN2yg== X-Received: by 2002:a17:902:8601:: with SMTP id f1-v6mr654991plo.196.1530682051891; Tue, 03 Jul 2018 22:27:31 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id t192-v6sm5299191pgc.74.2018.07.03.22.27.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 22:27:31 -0700 (PDT) To: Alissa Cooper , "Andrew G. Malis" Cc: Ted Hardie , rfcplusplus@ietf.org References: <3044F577-E367-44D5-BCE0-DE1E29EE6C13@cooperw.in> From: Brian E Carpenter Message-ID: Date: Wed, 4 Jul 2018 17:27:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <3044F577-E367-44D5-BCE0-DE1E29EE6C13@cooperw.in> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 05:27:45 -0000 On 04/07/2018 14:18, Alissa Cooper wrote: > Hi Andy, >=20 >> On Jul 3, 2018, at 2:46 PM, Andrew G. Malis wrote:= >> >> Regarding your example of authors being financially rewarded for RFC p= ublication, I=E2=80=99m sure that would extend to any IETF publication ty= pe if the IETF were to run this experiment, >=20 > Why are you sure? I=E2=80=99m curious because this aspect has come up i= n the IESG=E2=80=99s discussions of the proposed experiment, namely the n= otion that a document with the label =E2=80=9CRFC=E2=80=9D is or would be= considered more valuable than a document with a different label. (FWIW, = I agree with Bob=E2=80=99s view that =E2=80=9CRFC=E2=80=9D is a very stro= ng brand.) Predicting how corporate management will react is always hard, but if I was still in the job I had at a 3-letter company, I could imagine writing= something like this to the bosses: 'By the way, the IETF has just decided to rename some of the documents in "RFC" series as "FOO" or "BAR" to reduce confusion about document status. There will be no changes in the document review processes. I suggest that for bonus calculations, we can ignore this administrative change.' But really, we can't predict. Brian >=20 > Thanks, > Alissa >=20 >> thus this particular publication motivation would be unaffected by the= proposed experiment. >> >> Cheers, >> Andy >> >> >> On Tue, Jul 3, 2018 at 2:28 PM, Ted Hardie > wrote: >> On Tue, Jul 3, 2018 at 11:14 AM, Andrew G. Malis > wrote: >> Not only am I in complete agreement with everything that Brian has sai= d here, but I would like to add that section 5 makes this draft one of th= e most cynical documents I have read in a very long time. It makes the in= ference that one of the primary reasons people publish non-standards-trac= k RFCs is to DELIBERATELY TAKE ADVANTAGE of any confusion in the reader=E2= =80=99s mind regarding the status of RFCs. >> >> That's not quite what the document says. Here's the text: >> One hypothesis this experiment proposes to test is the degree to >> which the "RFC" label motivates authors seeking publication. Thoug= h >> numbers are unlikely to provide a clear answer when so much of the >> problem is subjective, measuring the rate of submission and >> publication for affected documents could provide some insight. >> There are a variety of reasons that could go into that motivation; in = some companies, as an example, publishing an RFC is rewarded financially = in a way that an internal technical report is not. =20 >> >> Joel has written on some of the difficulties in working out what to me= asure here, and I appreciate any consideration you can give to that; it's= not an easy problem, but if there is no data to work from forward motion= on the basis of anything other than impressionistic anecdotes will be di= fficult. >> >> regards, >> >> Ted >> >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 >=20 >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 From nobody Tue Jul 3 23:04:52 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06F8130DDF for ; Tue, 3 Jul 2018 23:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 6f4qRh4MZJqX for ; Tue, 3 Jul 2018 23:04:48 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0608D130DD7 for ; Tue, 3 Jul 2018 23:04:48 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 816BE1008FB; Wed, 4 Jul 2018 08:04:46 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 624FB40136; Wed, 4 Jul 2018 08:04:46 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0399.000; Wed, 4 Jul 2018 08:04:46 +0200 From: To: Martin Thomson , "rfcplusplus@ietf.org" Thread-Topic: [Rfcplusplus] Outlining the experiment Thread-Index: AQHUEqASQ4Zvnrf55Eyx5KJ3/NpuXqR+jFUw Date: Wed, 4 Jul 2018 06:04:45 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF51569@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Rfcplusplus] Outlining the experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 06:04:51 -0000 Hi Martin,=20 You said:=20 =3D=3D=3D RFC 7974 is the best example I have of this. It bears a warning nearly that strong and yet I have received or witnessed strong endorsements of its virtues on several occasions. =3D=3D=3D=3D I'm puzzled with this statement for many reasons, but will focus only on tw= o:=20 * You seem to assume that a reader has not to have his/her OWN analysis on = the merits/"virtues" of a technical proposal, but must adhere to whatever a= n IESG note says. * Why not considering the problem from another perspective: wouldn't the "s= trong endorsements" be a signal to question a note itself? There is no shame in including Experimental or information RFCs in RFPs or = in strongly claiming the merits of an RFC published under the ISE stream!=20 This is the responsibility of the one asking for it. =20 The use of another stream or label is IMHO unlikely to change the situation= . Consider these sample examples:=20 - suppose that DC-TCP is published as EXP8257, instead of current RFC 8257 - suppose that TFO is published as EXP7413, instead of current RFC 7413 - or RFC 6234 is published under INF6234 If one of these features is needed in an RFP, the corresponding FOO/BAR doc= uments will be listed.=20 How can this be measured in the proposed experiment? Cheers, Med > -----Message d'origine----- > De=A0: Rfcplusplus [mailto:rfcplusplus-bounces@ietf.org] De la part de Ma= rtin > Thomson > Envoy=E9=A0: mardi 3 juillet 2018 09:33 > =C0=A0: rfcplusplus@ietf.org > Objet=A0: [Rfcplusplus] Outlining the experiment >=20 > It's been good to see the level of engagement on this list. I've been > reading with some interest. >=20 > I've submitted a draft that attempts to summarize the proposed > experiment: https://datatracker.ietf.org/doc/draft-thomson-rfcplusplus-la= bel/ > [0] >=20 > I had hoped to get this out sooner, but the urgency of other tasks > meant that I barely met the draft submission deadline, and it's very > rough still. Hopefully that draft clarifies some of the questions > people had about the scope of the proposed experiment. >=20 > Obviously, this is just my view, and I don't think that everything in > there is correct (Adrian already found one hole). As Ted said, the > IAB are generally of the view that this is a topic worth discussing, > but as a group we don't agree on a particular solution. This is, more > than anything else, a convenient strawman. >=20 > However, based on the feedback thus far, it seems like it might be > good to examine some of the more fundamental issues: >=20 > 1. What is the problem? >=20 > I think that the problem is well understood. The common perception of > "RFC" encompasses a far simpler notion than the reality. >=20 > The debate seems to be centred more on the question of whether this - > of the multitude of problems that we might tackle - is the one that is > worth addressing. Several people have suggested that the broader > issues might be tackled more comprehensively. I'm personally not > opposed to that, though the thought was to keep the focus narrow. >=20 > Brian cites the ISD proposal [1], which is much more ambitious, but > it's been a few years since anything like this has been attempted, > maybe there is enough pent-up demand for change that we could find a > more comprehensive set of changes. >=20 > 2. Why this problem? >=20 > It's a relatively small problem, with a (proposed) small solution. >=20 > There are some potential advantages that might be later realized from > a looser coupling between different sources. There are certain > uniform expectations about publication as RFC that mean that certain > streams tend to affect the outcome of others, sometimes in ways that > are less than ideal. >=20 > For instance, we see that all RFCs tend to have a security > considerations section, even if the notion is a little ridiculous (BCP > 78 says as much). Security considerations make sense for standards, > but less so for other types of document. Besides, I think that they > exist solely for the comfort of SEC ADs now, we've a pretty strongly > enculturated understanding of the importance of security in our > designs [2]. >=20 > Similarly, one of the ideas floated early in this process was that > this might allow the RFC 5742 conflict review process to be removed. > That was intended to allow documents to proceed with fewer explicit > controls. Feedback from the ISE and ISEB indicated that they found > this process extremely valuable and the IESG don't see it as a burden, > so that's unlikely to be something that comes out of this, but I > mention it to illustrate the potential. >=20 > 3. Why now? >=20 > Why not? I don't really have a good answer for this, other than the > fact that there seemed to be sufficient interest in doing something > and that this was a reasonable candidate. >=20 > 4. This is so unscientific! >=20 > Yeah. That's the nature of the problem. Alissa articulated this > neatly in her email, it's a human problem. >=20 > We should definitely explore deeper, because this is small, but it > isn't simple. My personal view though is that if this gets to the > point where we're employing market research companies, something has > gone seriously wrong. Going that deep, or dragging in a laundry list > of other unsolved problems, might be a good way to ensure continuation > of the status quo. >=20 > 5. Why not erect a bigger sign? >=20 > The current boilerplate in RFCs could be improved, but - as the draft > says - that doesn't really get to the crux of the issue. >=20 > Even if there was a huge banner on every RFC that wasn't standards > track that said "DON'T IMPLEMENT OR DEPLOY THIS PROTOCOL. > IMPLEMENTING THIS PROTOCOL WILL HURT THE INTERNET", it won't stop > someone from receiving conflicting advice. >=20 > At the risk of being the first to invoke what will eventually be > verboten under the terms of Godwin's Law, RFC 7974 is the best example > I have of this. It bears a warning nearly that strong and yet I have > received or witnessed strong endorsements of its virtues on several > occasions. >=20 >=20 > [0] You can find a more readable and updated version here: > https://martinthomson.github.io/is-the-future/draft-thomson-rfcplusplus- > label.html > [1] https://tools.ietf.org/html/draft-ietf-newtrk-sample-isd-00 > [2] This is as it should be, alongside all the other things we might > consider as constraints on designs: privacy, deployment, operations, > usability, internationalization, human rights, economic effects, > intellectual property, etc... >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Tue Jul 3 23:18:00 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1505130E2D for ; Tue, 3 Jul 2018 23:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 VluP8NR5wZua for ; Tue, 3 Jul 2018 23:17:56 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E249E130DD7 for ; Tue, 3 Jul 2018 23:17:55 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id k81-v6so8579467oib.4 for ; Tue, 03 Jul 2018 23:17:55 -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=NWdOpzOnnGqgf/c7jIKVkZze2TUZY87LC6hblcuZWXw=; b=hyJ6CdRQKYzvlDZbfKfzft/T1rE6QVSMQ7enEaMQfMBOEVbBW9Clry1/548gvemoZt dgsQpLqqA6YNOhyPrx9Dqdi6lmHeaKfHqzlaq3HeNLBoqUW1V5OPtkvgaSWq9WanaNLW 5f5rBlNgsRJa8Qofp/IdVUAlK0KPoOpXmjwV4j17K1Ia/op/jkg0cuQS33+GxsWUYqmX m+QQVqXIfrNpZHnJgXDbYhFATM+5IIAKhvtOH0RfOok5M601VmnjFhXlq65IA8L0J6WN FdArKSXTRgK1i//76+O4hVu7vSI6wVLCw691iH1z9iT97pEFmPVedA5xoTitHGfUFuX9 0Gcg== 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=NWdOpzOnnGqgf/c7jIKVkZze2TUZY87LC6hblcuZWXw=; b=n1cVOV16Jtdp82/Pd++VGOAHspcUSMSrSHB2xqC8YqlOJ4Db87ugyG2pJvw98CX392 CEyLbAM3g/jUnfc+FAqxfEYKo1aqsFsAlsBPe7ppO56pHp+59TDqr7r0PCHP/Oo51zk4 J5Fun5HFENuffhkzWbXRcL89/CINmIhKL34+9vcYMy/i618H4iI/edEjW7L/ruOzZBIx mZ706LJnnYbrDaeold6c5Kjg2qfo+tNpsDXVyrlmoL+kTht/fxUT4WtBwEQcNrEg8Yha HiPkVKm7afg2jo3rNJSj7tWcQHGgI+aSZjpAPRovuYOTvhalXmdBKUUsEyi6z3Wwazqn SECg== X-Gm-Message-State: APt69E35BFefU0ISqFsDUd6RzDTlqQhnBDUgqvvCqRuX7C6BTJnnNcOe lTigGEANhW3Ed1X+EPTL78EB2AS3mAQcQp06R+w= X-Google-Smtp-Source: AAOMgpe2xfXHmaB72lxkIpp5p6uY3ZKWj4swWg8v1cM/ao5kDaYJXMSjL09L0qmnALJpJlf9gz/AL0Dpe81IbQyfsU4= X-Received: by 2002:aca:5155:: with SMTP id f82-v6mr796603oib.272.1530685075141; Tue, 03 Jul 2018 23:17:55 -0700 (PDT) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302DF51569@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF51569@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Martin Thomson Date: Wed, 4 Jul 2018 16:17:43 +1000 Message-ID: To: mohamed.boucadair@orange.com Cc: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] Outlining the experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 06:17:58 -0000 On Wed, Jul 4, 2018 at 4:04 PM wrote: > * Why not considering the problem from another perspective: wouldn't the "strong endorsements" be a signal to question a note itself? They could be. You can make that assessment for yourself, but the IESG don't make these statements lightly, and I respect their conclusions. FWIW, Section 1.2 of that document is pretty frank about the purpose of the document, so the question of dishonesty clearly doesn't apply, just the potential for confusion. But as an author of that document, what value do you see that publication as RFC provides in this case? As opposed to publication as FOO 7974, that is. Maybe also consider a comparison with publishing an internet-draft. > If one of these features is needed in an RFP, the corresponding FOO/BAR documents will be listed. > > How can this be measured in the proposed experiment? Poorly, most likely. But if that is the standard we insist upon, we're probably done here already. From nobody Tue Jul 3 23:34:52 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE00130EEC for ; Tue, 3 Jul 2018 23:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seQdJ6_rR4rL for ; Tue, 3 Jul 2018 23:34:34 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D0C130F5F for ; Tue, 3 Jul 2018 23:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2910; q=dns/txt; s=iport; t=1530686066; x=1531895666; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=3DFg8BKhA2mKLCX/ZRn2+2rVJgYf1isn17LkKxaMCbg=; b=HmdpAp14gRvj5jIuXhK+7dRfT9VHxDFeIE/wvfNvthBKpA4PN/+ZQJtl pzY0NHcawrllt09HwVo/qqQTrSadSxAncsLrwlKxGFZzGu7Y3i5aT5iKY TGG+Y6EoZBz2ilngL+c1SVmw85K1ttJG6OA+FNTqnNkNL9vs9MKxtvY9S I=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQB6aTxb/xbLJq1cDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGFGBKEIYhjjUYilyYIA4RsAoI7OBQBAgEBAgEBAm0ohTY?= =?us-ascii?q?BAQQBI1YFCyMqAgJXBgEMCAEBgxwBgXcIqEWCHIhRgSsPiwKBNgyKV4JVApl?= =?us-ascii?q?LCYNagViJaAaIEoVFkgmBWCGBUjMaCBsVgyWCS41MPD2RUAEB?= X-IronPort-AV: E=Sophos; i="5.51,306,1526342400"; d="asc'?scan'208"; a="4958693" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2018 06:34:24 +0000 Received: from [10.61.96.59] (dhcp-10-61-96-59.cisco.com [10.61.96.59]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w646YNwT027878; Wed, 4 Jul 2018 06:34:24 GMT To: Benjamin Kaduk , "Joel M. Halpern" Cc: Martin Thomson , rfcplusplus@ietf.org References: <20180704020155.GB60996@kduck.kaduk.org> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <29f028f4-3dec-4377-eaf3-915916f96a99@cisco.com> Date: Wed, 4 Jul 2018 08:34:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180704020155.GB60996@kduck.kaduk.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qRcp4TPQl1cEmmcWBAHLSwAAhfx7LCgwg" Archived-At: Subject: [Rfcplusplus] OT: argument style and substance Re: draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 06:34:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qRcp4TPQl1cEmmcWBAHLSwAAhfx7LCgwg Content-Type: multipart/mixed; boundary="pt1oZpToxyKjqJx8wiHtJ9vsiLwhUr1Q1"; protected-headers="v1" From: Eliot Lear To: Benjamin Kaduk , "Joel M. Halpern" Cc: Martin Thomson , rfcplusplus@ietf.org Message-ID: <29f028f4-3dec-4377-eaf3-915916f96a99@cisco.com> Subject: OT: argument style and substance Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 References: <20180704020155.GB60996@kduck.kaduk.org> In-Reply-To: <20180704020155.GB60996@kduck.kaduk.org> --pt1oZpToxyKjqJx8wiHtJ9vsiLwhUr1Q1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Ben, Since you asked... On 04.07.18 04:01, Benjamin Kaduk wrote: > On Tue, Jul 03, 2018 at 09:56:23PM -0400, Joel M. Halpern wrote: >> PS: Your text indicating that you consider some of the responses to be= =20 >> "emotional" seems to me to be irrelevant and inappropriate. > Is it? My view.., With a=C2=A0 general statement, it certainly can be a form of poisoning t= he well or tone policing, and should generally be avoided in argumentation.=C2=A0 That's not to excuse appeal to emotion itself, but o= ne should be specific (e.g., "the above argument doesn't stand on its own because it is an appeal to emotion").=C2=A0 Nor should we excuse sloppy arguments. It is, I think, also ok to point out that a debate is emotional, but that point must be made without being pejorative.=C2=A0 To lay claim or i= mply that all those opposing are arguing irrationally because they are emotional is pejorative.=C2=A0 Alissa's note, I think, demonstrates how t= o get that right. > Given the above, I'm not sure what argument would support a claim of > inappropriateness. I hope I have ;-) Eliot --pt1oZpToxyKjqJx8wiHtJ9vsiLwhUr1Q1-- --qRcp4TPQl1cEmmcWBAHLSwAAhfx7LCgwg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAls8amUACgkQh7ZrRtnS ejNR6gf5Ade2wY3LhKBPSltD8nq1tUr1AMouPnZJLq7FFUlvk04Iw6xPgR9sz5cX ChpXMU68zjT9Y//ped/FV85P3vQWFE0qV4uHZf/iGFjSonQIqj/AS+Rz1GXismqu kNVv03+7/vhkTCNkk66So2O+OyH1CyJZWAPHrl+1w9EcoVYQMO2DHjk+D5zfShLP njLxSEkBZeEEW3arlrl6lwpdtaqjt54h2jkHrXsaWzBkxXo96sAhSZg4WYJ5D+pY i22s5tzYC0qa3zegq+bYIg8juXd5aPJiLtuWuo7iNZ08oNzCsJPxQNvef9Ytk8Gn suJFGBsU9laxoKwDEDUw6jL5t/E3Ag== =Cf/x -----END PGP SIGNATURE----- --qRcp4TPQl1cEmmcWBAHLSwAAhfx7LCgwg-- From nobody Tue Jul 3 23:39:14 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE92130ECE for ; Tue, 3 Jul 2018 23:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Fi5BfyPU42aA for ; Tue, 3 Jul 2018 23:38:55 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F08D130EB4 for ; Tue, 3 Jul 2018 23:38:55 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id AD6981606E7; Wed, 4 Jul 2018 08:38:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 93564C008D; Wed, 4 Jul 2018 08:38:53 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0399.000; Wed, 4 Jul 2018 08:38:53 +0200 From: To: Martin Thomson CC: "rfcplusplus@ietf.org" Thread-Topic: [Rfcplusplus] Outlining the experiment Thread-Index: AQHUEqASQ4Zvnrf55Eyx5KJ3/NpuXqR+jFUw///qU4CAACHsQA== Date: Wed, 4 Jul 2018 06:38:52 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF51618@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302DF51569@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Rfcplusplus] Outlining the experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 06:39:11 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRp bi50aG9tc29uQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSA0IGp1aWxsZXQgMjAx OCAwODoxOA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+IENjwqA6IHJmY3Bs dXNwbHVzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbUmZjcGx1c3BsdXNdIE91dGxpbmluZyB0 aGUgZXhwZXJpbWVudA0KPiANCj4gT24gV2VkLCBKdWwgNCwgMjAxOCBhdCA0OjA0IFBNIDxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4gPiAqIFdoeSBub3QgY29uc2lkZXJp bmcgdGhlIHByb2JsZW0gZnJvbSBhbm90aGVyIHBlcnNwZWN0aXZlOiB3b3VsZG4ndCB0aGUNCj4g InN0cm9uZyBlbmRvcnNlbWVudHMiIGJlIGEgc2lnbmFsIHRvIHF1ZXN0aW9uIGEgbm90ZSBpdHNl bGY/DQo+IA0KPiBUaGV5IGNvdWxkIGJlLiAgWW91IGNhbiBtYWtlIHRoYXQgYXNzZXNzbWVudCBm b3IgeW91cnNlbGYsIGJ1dCB0aGUNCj4gSUVTRyBkb24ndCBtYWtlIHRoZXNlIHN0YXRlbWVudHMg bGlnaHRseSwgYW5kIEkgcmVzcGVjdCB0aGVpcg0KPiBjb25jbHVzaW9ucy4gIEZXSVcsIFNlY3Rp b24gMS4yIG9mIHRoYXQgZG9jdW1lbnQgaXMgcHJldHR5IGZyYW5rIGFib3V0DQo+IHRoZSBwdXJw b3NlIG9mIHRoZSBkb2N1bWVudCwgc28gdGhlIHF1ZXN0aW9uIG9mIGRpc2hvbmVzdHkgY2xlYXJs eQ0KPiBkb2Vzbid0IGFwcGx5LCBqdXN0IHRoZSBwb3RlbnRpYWwgZm9yIGNvbmZ1c2lvbi4NCg0K W01lZF0gVGhlcmUgbWlnaHQgYmUgY29uZnVzaW9uIGlmIG9uZSBkb2Vzbid0IHJlYWQgdGhlIGRv Y3VtZW50LiANCg0KVGhhdCBkb2N1bWVudCBjbGVhcmx5IGluZGljYXRlOiANCg0KKiBJdHMgaXMg YW4gIkluZGVwZW5kZW50IFN1Ym1pc3Npb24iDQoqIEl0IGlzIGFuICJJbmZvcm1hdGlvbmFsIiBk b2N1bWVudCANCg0KQW5kLCBpdCBpbmNsdWRlczogDQoqIGFuIElTRSBub3RlIGFib3V0IHRoZSBp bnRlbnQgb2YgdGhlIGRvY3VtZW50DQoqIGEgbm90ZSBmcm9tIHRoZSBJRVNHDQoqIGEgc2NvcGUg c2VjdGlvbiAoMS4yKQ0KDQo+IA0KPiBCdXQgYXMgYW4gYXV0aG9yIG9mIHRoYXQgZG9jdW1lbnQs IHdoYXQgdmFsdWUgZG8geW91IHNlZSB0aGF0DQo+IHB1YmxpY2F0aW9uIGFzIFJGQyBwcm92aWRl cyBpbiB0aGlzIGNhc2U/DQoNCltNZWRdIFdlIGhhdmUgYWxyZWFkeSBhbnN3ZXJlZCB0byB0aGlz IGluIFNlY3Rpb24gMS4yIG9mIHRoYXQgUkZDLCBidXQgSSBjYW4gY2l0ZSB0aGUgZm9sbG93aW5n OiANCg0KKiBHb29kIHRlY2huaWNhbCByZXZpZXdzIGluIGJvdGggdGhlIElFVEYgYW5kIElTRSBz dHJlYW1zDQoqIEVuY291cmFnZSBmb3IgbW9yZSBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9u cw0KDQpJIGRvIHN0aWxsIHRoaW5rIHRoYXQgUkZDNzk3NCBpcyBzdXBlcmlvciB0byBSRkMgNzIz OSAod2hpY2ggaXMgcHVibGlzaGVkIGluIHRoZSBTdGFuZGFyZCBUcmFjaykuIA0KDQoNCiAgQXMg b3Bwb3NlZCB0byBwdWJsaWNhdGlvbg0KPiBhcyBGT08gNzk3NCwgdGhhdCBpcy4NCg0KW01lZF0g SSdtIG5vdCBzdXJlIGFib3V0IHRoZSBwb3NzaWJsZSBpbXBsaWNhdGlvbiBvbiBkb2N1bWVudHMg cmV2aWV3LCBidXQgSSBkb24ndCBzZWUgbXVjaCBkaWZmZXJlbmNlIGV4Y2VwdCByZWR1Y2luZyB0 aGUgcGFnZSBjb3VudCBhcyB0aGUgbm90ZXMgbWVudGlvbmVkIGFib3ZlIGFyZSBsaWtlbHkgdG8g YmUgZGVsZXRlZCBiZWNhdXNlIHRoaXMgd2lsbCBiZSBpbXBsaWVkIGJ5IHRoZSBGT08gbGFiZWwg aXRzZWxmLiANCg0KDQogIE1heWJlIGFsc28gY29uc2lkZXIgYSBjb21wYXJpc29uIHdpdGgNCj4g cHVibGlzaGluZyBhbiBpbnRlcm5ldC1kcmFmdC4NCj4gDQo+ID4gSWYgb25lIG9mIHRoZXNlIGZl YXR1cmVzIGlzIG5lZWRlZCBpbiBhbiBSRlAsIHRoZSBjb3JyZXNwb25kaW5nIEZPTy9CQVINCj4g ZG9jdW1lbnRzIHdpbGwgYmUgbGlzdGVkLg0KPiA+DQo+ID4gSG93IGNhbiB0aGlzIGJlIG1lYXN1 cmVkIGluIHRoZSBwcm9wb3NlZCBleHBlcmltZW50Pw0KPiANCj4gUG9vcmx5LCBtb3N0IGxpa2Vs eS4gIEJ1dCBpZiB0aGF0IGlzIHRoZSBzdGFuZGFyZCB3ZSBpbnNpc3QgdXBvbiwNCj4gd2UncmUg cHJvYmFibHkgZG9uZSBoZXJlIGFscmVhZHkuDQo= From nobody Tue Jul 3 23:58:36 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE7D130DD2 for ; Tue, 3 Jul 2018 23:58:34 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 yqmz3UvxGdXd for ; Tue, 3 Jul 2018 23:58:31 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FE0120049 for ; Tue, 3 Jul 2018 23:58:31 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fabkE-000Htr-5U; Wed, 04 Jul 2018 02:58:30 -0400 Date: Wed, 04 Jul 2018 02:58:23 -0400 From: John C Klensin To: Brian E Carpenter , Ted Hardie cc: rfcplusplus@ietf.org Message-ID: <6D7150456CAE76F39CB94544@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] FYI series[was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 06:58:35 -0000 --On Wednesday, July 4, 2018 16:53 +1200 Brian E Carpenter wrote: >... >> Given that there are many other distribution mechanisms >> available today, we do not have to treat the RFC series as >> the only place where such documentation can take place. > > That is true. This is why the ION series was kept separate from > the RFC series - because distribution-by-web-page seemed > necessary and sufficient for the purpose, at the time the ION > series was invented. Web pages weren't an option when the FYI > series started. Another piece of that issue is that we've gone to some lengths over the years to make sure the RFC Series has reasonably good properties from an archival standpoint. That is not true for may, or most, of those "other distribution mechanisms" (noting as a particular example the density of bad links on the IETF's own web pages). If I encounter some popular, but badly designed and implemented, piece of protocol on the Internet, it is good to be able to find a description of it, in a known format, and to know that the description will be equally accessible some years down the line. If the thing is a hazard, but out there, the Internet is, IMO, still better off if "we" encourage documentation and make it available, accompanied, if it is appropriate and worth the effort, by Applicability Statements that explain why using it is a Really Bad Idea, rather than pretending it does not exist and hoping that, if we ignore it long enough, it will disappear. >From that point of view, the right remedy for a terrible protocol idea --especially one that is either widely-deployed or that seems likely to get traction-- is publication alongside a well-reasoned critique or denunciation, not attempts to suppress documentation or discussion of it. The Internet's technical community, via the RFC Editor, has long felt some obligation to provide a consistent, curated, collection of such protocol documentation, in addition to documentation of its own work (standards-related or not) as a service to the Internet. If we are really having a conversation about giving up that role and responsibility and letting the RFC Editor Function publish only those things the IETF either develops or likes, let's have that conversation and not disguise it as a discussion of how we label things. I would hope that such a discussion would consider the possibility that at least part of the reason the IETF has been as successful and influential as it has been is that we have felt, and demonstrated, that level of responsibility for the protocols of the whole Internet, rather than being just another standards body doing its own thing and pushing its own work. Lots of those out there and most of them are easier to push work through than the IETF. I would also hope that people who would prefer to eliminate or severely constrain the Independent Stream would recognize that "less workload for the IESG" should not be an objective. Today, the Independent Stream acts as a sort of safety valve for documents the IETF does not find of sufficient interest and, by using its own editorial review and selection process, avoids putting that workload on the IESG and the IETF as a whole. Eliminate that mechanism and the number of requests for AD Sponsorship will, I think inevitably, go up and, in the absence of that safety valve, it is likely that the number of appeals of AD decisions to not sponsor documents will go up too, probably followed by community insistence that every AD decision to sponsor (or not sponsor) a document be well-documented with reasoning, etc. Certainly that does not reduce the workload on the IESG. Because every AD sponsored document goes through IETF Last Call and IESG balloting, it would also increase the workload on IETF participants as well. I think "be careful what you wish for" might be in order. The comments above are rather different from worrying about descriptions of particular applications on particular platforms. In addition to the self-filtering that others have described, we have almost never been in the business (either in the IETF or as Independent Submissions) of developing or publishing descriptions of actual applications, platform-specific or not. We do mail protocols and formats but, at least AFAIK, have never published a description of an MUA. We do calendar protocols and data formats, but don't do actual calendaring programs. We do PGP and S/MIME, and specify or publish the cryptographic algorithms and procedures that underlie them, but have stayed away from specifying (or publishing in the Independent Stream) the UIs for those protocols. So I see a discussion of the number of applications on, e.g., the iPhone or iPad, as fairly close to a strawman. > However, I think it's rather orthogonal to the question of > what types of document are suitable for inclusion in the RFC > series. Yes. And it seems to me that even that question is rather different from anything I see in the BOF proposal, which brings me back to the question of what we are talking about. best, john From nobody Wed Jul 4 00:03:05 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00405130DD7 for ; Wed, 4 Jul 2018 00:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 sO-AxjM5n8gi for ; Wed, 4 Jul 2018 00:03:00 -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 6FB0E120049 for ; Wed, 4 Jul 2018 00:03:00 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id w6472sJR015289; Wed, 4 Jul 2018 08:02:54 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 232702203A; Wed, 4 Jul 2018 08:02:54 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 16FD922032; Wed, 4 Jul 2018 08:02:54 +0100 (BST) Received: from 950129200 ([141.85.216.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w6472qrL020830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2018 08:02:53 +0100 Reply-To: From: "Adrian Farrel" To: "'Alissa Cooper'" , "'Andrew G. Malis'" Cc: Date: Wed, 4 Jul 2018 08:02:49 +0100 Message-ID: <027501d41365$06112ac0$12338040$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdQTZQHOLm0f8xnjRlGw9nV346QY9Q== X-Originating-IP: 141.85.216.4 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23946.005 X-TM-AS-Result: No--9.617-10.0-31-10 X-imss-scan-details: No--9.617-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23946.005 X-TMASE-Result: 10--9.616700-10.000000 X-TMASE-MatchedRID: n9cYXgEdfuvau9iF5mAFe1aOpp/sV5nVr72V2jJOAXxrE1c4mB5Umq6K cZmReFA9Xl64mb0OGZfKDu32JYk7iWovLfQMyHIfpLS2yK6GQKN7bhUXQJ5xBaaDeNpTFrdeNSL atMg7EYYWl6j129YpPqj2ZU8bi03nW3NX3Rq13v0D2WXLXdz+AbUwd+ikkFP0XR2HO74CQIhrQg SRg6yiRe8G1zkmiyotLFw7yKu54WxQVXITChRgIyUmV2yxpawtHEJw6UOhV9P9k2xa9Ahjg2XU/ J5x8nVFJQxv904fAdcPjfLkrvJIsJG468S7yeiwCz1WR8KHe4CH7D1bP/FcOglbhF7ZTanLqo+j KHcX3vjXFJTHU3zxIdXB+YzuQ0ZYGh6744KLCtKeAiCmPx4NwHJnzNw42kCxxEHRux+uk8h+ICq uNi0WJNPG5Gw4yHBLhzwdwilXVdrLMjT3+9lzHam/moBpR5pMftwZ3X11IV0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Rfcplusplus] Financial rewards [draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 07:03:03 -0000 > Regarding your example of authors being financially rewarded for RFC > publication, I=E2=80=99m sure that would extend to any IETF = publication type if > the IETF were to run this experiment,=20 >> >> Why are you sure? I=E2=80=99m curious because this aspect has come up = in the >> IESG=E2=80=99s discussions of the proposed experiment, namely the = notion that >> a document with the label =E2=80=9CRFC=E2=80=9D is or would be = considered more valuable >> than a document with a different label. The relative rewards exist already. Companies are not generally dumb = about how they hand out money when they have objectives they want to = leverage using that money. Thus (for some companies with which I may or may not have had dealings = at some time in my life) there may be a scale roughly from top to = bottom... - standards track RFC - bcp - other IETF consensus RFC - WG draft - ISE or IRTF RFC - individual draft Changing the document labelling: - might stop employees bamboozling their employers - could make it easier to automate reward payments Otherwise it would be unlikely to make a difference. Furthermore, this really should not be a consideration in the solution = space. Yes, it is an observational input to understanding the value of = two brands: "RFC" and "IETF consensus". But the idea that IETF would = attempt to socially engineer the behaviour of remuneration systems is (I = hope) out of scope. Indeed, if my boss wishes to pay me for the number = of times I use the word "unicorn" in a WG draft, that is between me and = her. So, back to the analysis of the perceived problem, the level of harm = caused, the size of the problem, why we think it needs to be fixed, and = then (and only then?) whether the proposed solution is = functional/harmful/practical/achievable/legal. Thanks, Adrian From nobody Wed Jul 4 00:10:56 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594F7130ED6 for ; Wed, 4 Jul 2018 00:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 C3aftlHKM18Y for ; Wed, 4 Jul 2018 00:10:45 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 DBCCF130EE6 for ; Wed, 4 Jul 2018 00:10:44 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id s198-v6so8794478oih.11 for ; Wed, 04 Jul 2018 00:10:44 -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=I7l+IoC6DXd7l6IaCVNMaqJEBB0bC5zazU++hzGvuSI=; b=GBwJUoPY1gnObx82AVcLnmAz/bd3JW09TxjjsLGBygOryDQExq7CKPVU3s4jJMSv0G RXUTH0sZYd8qeVaygxSO+OPUWndNJrSsZ+vQormz/HKMWrxN//MHK3nZmhS5WLLEbv3w y8YmQxSUx+BmkVVPSFtvjD9NU3tWS0NTJoAUBf5apbeDw7+FF2sPQlXmEOhUcWh3Xq2H v2QkEfdLQYvRPRbWbe4cgeLmeBveVntFzts/k1qeuJ/uZn05auW4jSwqsQmdjP8cZ8lk b3lJ4BbIvGu1lH400MT+Cmycya31izIglROLlBA1by9UzzJOPDo0tjiL1+lzBZPtr0gg iTXQ== 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=I7l+IoC6DXd7l6IaCVNMaqJEBB0bC5zazU++hzGvuSI=; b=pTBTeGW0wVihj9qQ2feDB187jVqzTA8Q6UV/d5UcMALKMBjyqM/ZNFzLGHnlcYVCjP vVOydr5isTWNDlmpbMTaesr4sFsUNPfWXHCFZAsZs7gY/QsJU2S1PXigzRoYxf/0i4Gb AEaxgwoRx4i9p98T9m2SFYq922GRxgYgMRi2ggArvZ8DAIO2HNwFR8PMbSm+uSBlco4j h9Tu8qeE7bshHlQBqSap4SfYunXRtKXOcIA7o3FZXFIgXQRgKouySXlAhsv5dWB+S8rI Aef9lkDpTx2oRkLjLWGj8Es/s4vY+1egijYoK5sk9EBZuI6wEcKxG28AkKaOkbyKY96z ylFQ== X-Gm-Message-State: APt69E0uQqUlpv1gTyXcn3QO09FQ1zVjsF3dOeNLmUGliBIYdll0DOHQ uX7sMfFKLlSWnkSBwXmiqAYXrdoiKfdte9D/Mnc= X-Google-Smtp-Source: AAOMgpcCGPuv33XICDJzJaZn9u/MqriB3IOHPSKHE81MAix6a5xfA7yXIUNPs/vRHLrOvz5yDIHnsiiunhbVCsrMAQQ= X-Received: by 2002:aca:100f:: with SMTP id 15-v6mr999075oiq.110.1530688244159; Wed, 04 Jul 2018 00:10:44 -0700 (PDT) MIME-Version: 1.0 References: <027501d41365$06112ac0$12338040$@olddog.co.uk> In-Reply-To: <027501d41365$06112ac0$12338040$@olddog.co.uk> From: Martin Thomson Date: Wed, 4 Jul 2018 17:10:32 +1000 Message-ID: To: adrian@olddog.co.uk Cc: Alissa Cooper , "Andrew G. Malis" , rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfcplusplus] Financial rewards [draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 07:10:54 -0000 On Wed, Jul 4, 2018 at 5:03 PM Adrian Farrel wrote: > Furthermore, this really should not be a consideration in the solution sp= ace. Yes, it is an observational input to understanding the value of two br= ands: "RFC" and "IETF consensus". But the idea that IETF would attempt to s= ocially engineer the behaviour of remuneration systems is (I hope) out of s= cope. That's my read on this too. I don't see much more value to be extracted from that topic. > Indeed, if my boss wishes to pay me for the number of times I use the wor= d "unicorn" in a WG draft, that is between me and her. For a challenge, see how much Insane Clown Posse lyrics you can get in :) From nobody Wed Jul 4 00:14:10 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF14120049 for ; Wed, 4 Jul 2018 00:14:09 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 TZU1jhoW5qaM for ; Wed, 4 Jul 2018 00:14:07 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7176C130DD7 for ; Wed, 4 Jul 2018 00:14:07 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fabzJ-000IIO-Ec; Wed, 04 Jul 2018 03:14:05 -0400 Date: Wed, 04 Jul 2018 03:13:58 -0400 From: John C Klensin To: Brian E Carpenter cc: Alissa Cooper , "Andrew G. Malis" , Ted Hardie , rfcplusplus@ietf.org Message-ID: <500C011C761A520733E47438@PSB> In-Reply-To: References: <3044F577-E367-44D5-BCE0-DE1E29EE6C13@cooperw.in> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 07:14:10 -0000 --On Wednesday, July 4, 2018 17:27 +1200 Brian E Carpenter wrote: >> Why are you sure? I'm curious because this aspect has come >> up in the IESG's discussions of the proposed experiment, >> namely the notion that a document with the label "RFC" is >> or would be considered more valuable than a document with a >> different label. (FWIW, I agree with Bob's view that >> "RFC" is a very strong brand.) > > Predicting how corporate management will react is always hard, > but if I was still in the job I had at a 3-letter company, I > could imagine writing something like this to the bosses: > > 'By the way, the IETF has just decided to rename some of the > documents in "RFC" series as "FOO" or "BAR" to reduce > confusion about document status. There will be no changes in > the document review processes. I suggest that for bonus > calculations, we can ignore this administrative change.' > > But really, we can't predict. You think? Let me predict anyway. There are several mechanisms out there called "impact scores". There is also a lot of literature about why they are lousy measures of what they allegedly measure, but they are wildly popular among counters of beans, academic promotion committees, etc., precisely because they provide quantitative, interval-scale, measures that are easily compared. By those measures, the RFC Series does fairly well if only because there are lots and lots of references around to technical standards for the Internet. In a way, they are the quantitative reflection of "strong brand". Now if one splits things off into different pieces, maybe the scores for the RFC Series actually go up because documents that might be important but are not widely references are somewhere else. However, if one examines those other collections three years down the line, they are likely to have scores in the "why should we bother with that or support our employees in writing such things" range. There may be good (and bad) reasons for breaking things up, but at least on that dimension, I'd predict negative outcomes for any new and more narrowly focused series. best, john From nobody Wed Jul 4 00:56:53 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68347130DEC for ; Wed, 4 Jul 2018 00:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 n3kTwlOS2TuS for ; Wed, 4 Jul 2018 00:56: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 B6F81130DC1 for ; Wed, 4 Jul 2018 00:56:48 -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 w647ukBa015261 for ; Wed, 4 Jul 2018 08:56:46 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D7A032203C for ; Wed, 4 Jul 2018 08:56:45 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id C28042203B for ; Wed, 4 Jul 2018 08:56:45 +0100 (BST) Received: from 950129200 ([141.85.216.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id w647uiIo005488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Jul 2018 08:56:45 +0100 Reply-To: From: "Adrian Farrel" To: Date: Wed, 4 Jul 2018 08:56:41 +0100 Message-ID: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdQTZ53FhZbiRdGiRrCVtN3V5o6Ipg== X-Originating-IP: 141.85.216.4 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23946.005 X-TM-AS-Result: No--2.946-10.0-31-10 X-imss-scan-details: No--2.946-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23946.005 X-TMASE-Result: 10--2.945900-10.000000 X-TMASE-MatchedRID: 3HVpdioef+YAzT8btdR14/HkpkyUphL9q8zHTxACKxY0R6Qa5msxBIGB bVcwF0YPlS6V5K9z0atfn9E3FZubttZIep26hpHh3FqOVb7PDEIKajiKVoihqbrfxlRjqBJ3D0C RkZ8VIH+lCCcCBg2p3VJNbSu6g2GO7Hz728uiamAa4TdTJQcbVwkN8Uvsy+nt2viB/Jr4D1QqBv wF+qucauQi57zK7946pRYb157ByoxsGQsY/Fc7u6ZCFtxq3n99R9R86+kr2LABWxwPU6jS0LCQu Jto3I58rcApmJvt+qP7c8qMpCnr4Jd+1F/LHa/jlcKRfmdbgrfZVGwEiLyZWJsoi2XrUn/JmTDw p0zM3zoqtq5d3cxkNVIc3O7Mj/yCT8PA83qZhpPBZVOqhzUyITm0ct1+Y3TFO5hitJp+TLx4m+q JDZ0pJIcB7RIuMpqyQJaSYyj/M2e0nDwbCAvvPhIpsaMU2m+xr3LE7lHo4NKJkNr6rpsABVVB/O byHMK5ZzbwncYrg9dDDKa3G4nrLQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 07:56:52 -0000 Buried in this thread there was... >> As opposed to publication as FOO 7974, that is. >=20 > [Med] I'm not sure about the possible implication on documents review, = but I > don't see much difference except reducing the page count as the notes > mentioned above are likely to be deleted because this will be implied = by the FOO > label itself. That's an interesting point. Suppose a document contained the specification of a protocol that = competed with an IETF consensus protocol. Suppose further that = implementation of the specified protocol likely caused negative = interactions with the IETF consensus protocol and so risked the = stability of the Internet. - Where the document is in the IETF stream, we know how to handle it. - Where the document is in the IRTF or Independent Streams we have a time-tested mechanism and (I think) no evidence of harm through publication. - If the IRTF and Independent Stream documents became FOO and BAR=20 documents, we would need to understand what control/input the IESG expected to have. - If the publication is moved to another venue, the only thing the IESG can do is plead or bang shoes on tables. There seems to be an correlation: the closer to looking like an IETF = consensus document, the more IESG input. Now, it might be thought (this is possibly a branding thing) that the = further from looking like an IETF consensus document the less we have to = care about the "protocol conflict problem", but I would argue that the = less input the IESG has, the more we have to worry. Thus, were an = alternative venue for publishing competing specifications to be = developed, I would claim that this is harmful to the RFC band and to = both the IETF's brand and raison d'=C3=AAtre.=20 From nobody Wed Jul 4 01:07:17 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02C1130EB1 for ; Wed, 4 Jul 2018 01:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=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=opendkim.org header.b=2Myo5OUu; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=QbCVdoUQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZEIPJGBRqo8 for ; Wed, 4 Jul 2018 01:06:59 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8749D130E88 for ; Wed, 4 Jul 2018 01:06:59 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.48.6]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id w6486h52026128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2018 01:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1530691615; x=1530778015; bh=xH37EPM+POrToEWqD70yOAdRqZinlRIa6cBGilVoPLk=; h=Date:To:From:Subject:In-Reply-To:References; b=2Myo5OUutK3S8pDDR9c1hsdt/hu6ONkQeUrcaySeENBEd/mGsquQoPmeJJ/y+jC+d YWyQ60wq3Tz6yWDogRaaLUyyFLkkRdQ3X8VTmxZgdGnhtyh7tr9EofviCQhlIJFG+r zdVreXxZHr40rHjycGKPEgPiNIQBPTjKbyr3YQKI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1530691615; x=1530778015; i=@elandsys.com; bh=xH37EPM+POrToEWqD70yOAdRqZinlRIa6cBGilVoPLk=; h=Date:To:From:Subject:In-Reply-To:References; b=QbCVdoUQp1fyQyJGaHupKIuUEqUv88/ugGvICjIhAZk+327Ccvk8VUwm5FyMvW8N8 jVy2oKLgMDcWo4jZZfnx95ptw7X+yDtF0e6zeVIIN60w4Xdtoj5w+ygLsFold3Xe+P jTQfQa8u6wQWFznUCxlfJsCqLACu2pd7dV6pxuZI= Message-Id: <6.2.5.6.2.20180703234604.0b3e3b08@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Jul 2018 01:02:37 -0700 To: Martin Thomson , rfcplusplus@ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20180703135941.0cf5ab78@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfcplusplus] Comments on draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 08:07:15 -0000 Hi Martin, At 05:58 PM 03-07-2018, Martin Thomson wrote: >Not so much. I don't believe that allocating codepoints should be use >as a locus of control. We've seen some pretty awful consequences from >that. Recently: three-way squatting on the same codepoint in TLS, for >instance. > >The concern is simpler: the creation of non-interoperable deployments. There was a perception that codepoint allocation was a locus of control. It is one of the underlying IETF debates which happen every now and then, e.g. when the allocation requirement is "RFC required". >Bad choice of words maybe, because that's just my opinion. That is, I >believe that DASH is perfectly adequate for the use case and that the >publication of HLS as an RFC is entirely unnecessary. That the >conflict review found no conflict is unsurprising, but that's a very >narrow determination. As a comment about "use case", it is sometimes used within the IETF to argue for some change or that a proposal is "inadequate". I took a quick look at "usage" of the RFC and I found that it is referenced outside the IETF as a vendor specification. One of the references is to tools.ietf.org. Publication of other RFCs under the IETF domain name might have led to some confusion about IETF RFCs and other RFCs. Regards, S. Moonesamy P.S. I am okay with the choice of words for the draft. From nobody Wed Jul 4 01:10:54 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FD1130DEC for ; Wed, 4 Jul 2018 01:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gQGXlMNcKS0 for ; Wed, 4 Jul 2018 01:10:49 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C8F130DC1 for ; Wed, 4 Jul 2018 01:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9326; q=dns/txt; s=iport; t=1530691849; x=1531901449; h=to:from:subject:message-id:date:mime-version; bh=2a0RTIk2pbwStlBkjqFz5L6mQk3wSyeakJ8OV4er8cQ=; b=m0Ht8hWAi8fACoa5DuP8HkSdm4rms7eE1ysLkVJ5wgChlCMbZ8eSyf45 2urBSFf/Mow+znc1BoMQrAjqcLCRbwSu9SpaqldKWFrMbpbTqhF8Oi7Vf Zn2Ex8Be9+74Cw0AAop5t3O+1KI9rXJC9OmodgmzBfUAUcc5pY2b6xZ4Y U=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAQBfgDxb/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYUYEoQhiGONRpBAhwgIA4cvOBQBAgEBAgEBAm0ohWCBMwJsCAE?= =?us-ascii?q?BEIMMAYF/qD6CHB+INIErD4sCgQ8nDIcigzWCVQKHQJILCYNagViJaAaIEoV?= =?us-ascii?q?FkgmBWCGBUjMaCBsVgyWCIxeOGT2RUAEB?= X-IronPort-AV: E=Sophos;i="5.51,306,1526342400"; d="asc'?scan'208,217";a="4902220" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2018 08:10:46 +0000 Received: from [10.61.96.59] (dhcp-10-61-96-59.cisco.com [10.61.96.59]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w648Akhb016300 for ; Wed, 4 Jul 2018 08:10:46 GMT To: rfcplusplus@ietf.org From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Wed, 4 Jul 2018 10:10:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OXn390LTC2C8qIftPxEsXEjwaJWB2t1Yf" Archived-At: Subject: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 08:10:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OXn390LTC2C8qIftPxEsXEjwaJWB2t1Yf Content-Type: multipart/mixed; boundary="ryjFbNOCpm4KAHwox4Mp9NPHI7wRUEWqD"; protected-headers="v1" From: Eliot Lear To: rfcplusplus@ietf.org Message-ID: Subject: labeling/experiments/ and ramifications --ryjFbNOCpm4KAHwox4Mp9NPHI7wRUEWqD Content-Type: multipart/alternative; boundary="------------E1C6C47A5D7451E3C37568AE" Content-Language: en-US This is a multi-part message in MIME format. --------------E1C6C47A5D7451E3C37568AE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for thinking aloud a bit here... As Alissa as alluded, the debate has become a bit mixed up with the use of experimental language.=C2=A0 It seems to me that we should be more explicit about this: * Are we experimenting?=C2=A0 or * Are we taking a permanent action?=C2=A0 or * Are we taking a step toward a permanent action, with the option to revert? Seems to me that we're really considering that latter choice.=C2=A0 The question, then, is really whether bothering with labels is the right approach.=C2=A0 As community veterans, we all recognize that relabeling t= he a stream is likely to cause a serious reduction of publications precisely because the RFC is a brand, and excluding access to that brand would put alternatively labeled publications at a distinct disadvantage.=C2=A0 Why = not consider a less drawn out death? Why not, indeed... It's already a struggle to get academic participation in the IRTF.=C2=A0 Removing incentives would risk further reducing such participation, albeit marginally (RFCs' stature is improving, thanks to Heather pursuing DOIs, for instance).=C2=A0 Do we run the risk of brand exploitation/dilution in the IRTF series?=C2=A0 Perhaps, but maybe the ri= sk is worth it.=C2=A0 It's possible that the IRSG could be given guidance to= take care to avoid such problems. Should we continue the ISE stream?=C2=A0 What is its value?=C2=A0 To me t= he value in large part in providing input to the Internet community about ideas that are not intended as standards and yet have value in their consideration.=C2=A0 Those ideas include: * Documentation of protocols or algorithms that are used on the Internet.=C2=A0 IAX seems like a good example of this.=C2=A0 So do en= cryption algorithms.=C2=A0 WRT what EKR said, it seems better to have the algorithm documented than not, if it is being used.=C2=A0 The test: i= s it really being used?=C2=A0 This *is* protocol work, but doesn't really benefit that much from brand exploitation. * Commentary on the IETF processes or decisions.=C2=A0 Dave Crocker and= I have both written such commentaries for reflection by the community.=C2=A0 This is a bit of an escape value, along the lines, o= f "Think about what you've done and its ramifications".=C2=A0 It's not = a consensus document, but it can hardly be confused as a protocol work, and thus does not subject the RFC label to brand dilution.=C2=A0= These are also relatively rare pieces of work.=C2=A0 I wish there wer= e more. * Other interesting mechanisms that are not widely deployed.=C2=A0 This= is where brand exploitation becomes at least a marginal, if not real, possibility.=C2=A0 The question is whether we really care.=C2=A0 By w= ay of example, there are a whole lot of Keynote documents published through the ISE.=C2=A0 Have they helped or harmed the Internet and ha= ve they helped or harmed the RFC brand?=C2=A0 (Maybe this is the wrong example; pick your own; Barry certainly did). I believe the first two uses are valuable, and the third use has also been of value, although there is some noise.=C2=A0 I wonder if we could handle all of this by having the IAB provide some guidance to the ISE.=C2= =A0 Brand dilution is a risk, and if the community thinks it's a big enough risk, then of course we should act on it.=C2=A0 But there are also risks = of acting. Eliot --------------E1C6C47A5D7451E3C37568AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sorry for thinking aloud a bit here...

As Alissa as alluded, the debate has become a bit mixed up with the use of experimental language.=C2=A0 It seems to me that we shou= ld be more explicit about this:

  • Are we experimenting?=C2=A0 or
  • Are we taking a permanent action?=C2=A0 or
  • Are we taking a step toward a permanent action, with the option to revert?

Seems to me that we're really considering that latter choice.=C2=A0= The question, then, is really whether bothering with labels is the right approach.=C2=A0 As community veterans, we all recognize that relabeling the a stream is likely to cause a serious reduction of publications precisely because the RFC is a brand, and excluding access to that brand would put alternatively labeled publications at a distinct disadvantage.=C2=A0 Why not consider a less drawn out= death?

Why not, indeed...

It's already a struggle to get academic participation in the IRTF.=C2=A0 Removing incentives would risk further reducing such participation, albeit marginally (RFCs' stature is improving, thanks to Heather pursuing DOIs, for instance).=C2=A0 Do we run the= risk of brand exploitation/dilution in the IRTF series?=C2=A0 Perha= ps, but maybe the risk is worth it.=C2=A0 It's possible that the IRSG c= ould be given guidance to take care to avoid such problems.

Should we continue the ISE stream?=C2=A0 What is its value?=C2=A0 = To me the value in large part in providing input to the Internet community about ideas that are not intended as standards and yet have value in their consideration.=C2=A0 Those ideas include:

  • Documentation of protocols or algorithms that are used on the Internet.=C2=A0 IAX seems like a good example of this.=C2=A0 So d= o encryption algorithms.=C2=A0 WRT what EKR said, it seems better t= o have the algorithm documented than not, if it is being used.=C2=A0= The test: is it really being used?=C2=A0 This is protocol work, but doesn't really benefit that much from brand exploitation.
  • Commentary on the IETF processes or decisions.=C2=A0 Dave Crock= er and I have both written such commentaries for reflection by the community.=C2=A0 This is a bit of an escape value, along the line= s, of "Think about what you've done and its ramifications".=C2=A0 It= 's not a consensus document, but it can hardly be confused as a protocol work, and thus does not subject the RFC label to brand dilution.=C2=A0 These are also relatively rare pieces of work.=C2= =A0 I wish there were more.
  • Other interesting mechanisms that are not widely deployed.=C2=A0= This is where brand exploitation becomes at least a marginal, if not real, possibility.=C2=A0 The question is whether we really ca= re.=C2=A0 By way of example, there are a whole lot of Keynote documents published through the ISE.=C2=A0 Have they helped or harmed the Internet and have they helped or harmed the RFC brand?=C2=A0 (May= be this is the wrong example; pick your own; Barry certainly did).

I believe the first two uses are valuable, and the third use has also been of value, although there is some noise.=C2=A0 I wonder if= we could handle all of this by having the IAB provide some guidance to the ISE.=C2=A0 Brand dilution is a risk, and if the community th= inks it's a big enough risk, then of course we should act on it.=C2=A0 B= ut there are also risks of acting.

Eliot

--------------E1C6C47A5D7451E3C37568AE-- --ryjFbNOCpm4KAHwox4Mp9NPHI7wRUEWqD-- --OXn390LTC2C8qIftPxEsXEjwaJWB2t1Yf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAls8gQQACgkQh7ZrRtnS ejPTpggA04LG7vH45vY9ba+cNjk8okdRjLhzH6dXxGBXKH3S3Uiz0GcQK/y5xOlA 5peoo0UJQ3tNsF/BLdEBp1fGZVn5QDOjuzh18uXCEv4mJFuL2I0qVL1LbbuXV1Y7 HmdEni5cZslaWBU6/TsNVuzMkvsyBZ50iu2Eg8S+HkrUdyPt8lFcmglsA3SID5MW AWfPGxR8NVnIxrl/h4uCoKMsHfelml5vqoPepDJOIlocHmimEvKJIi7QgXkpwRFq GMHGGyiqTO57r2y+vkTlRnq8j5lPtP0RszVNAwsDAqLsjtMD7zibPiUX0nXI3ZLg UprhTQuRu3i3+NG58fKjMIvzrQja4g== =HBmJ -----END PGP SIGNATURE----- --OXn390LTC2C8qIftPxEsXEjwaJWB2t1Yf-- From nobody Wed Jul 4 02:52:38 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A689130E46 for ; Wed, 4 Jul 2018 02:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 PI1p8IxyOdyx for ; Wed, 4 Jul 2018 02:52:31 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 8212B130DC4 for ; Wed, 4 Jul 2018 02:52:31 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id c6-v6so9651500oiy.0 for ; Wed, 04 Jul 2018 02:52:31 -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=n9UBgIyzzTzK5J6Bp6+ggNxMlXDxpqS4WdJD8bxmEBI=; b=UgvCSCoLd5poF3NGu/zoB38E+3dZIDocFcx9oIb08w8jkwh3e8rkrhv6kXGtW+sTWy Ykm4Vki89c31Jv+Gc35OEdMysDXL7bWlbwjK/WOTaR4Z1fW7ftSYYKVufzVSeTNzpP+d HXJ6faHX6m9OSheqz2d0zLesXy5ePhBuPdiPr5uEOqEmecABH4BPM64kBgDpxI5i7bhc 4qnJ5pSwwYV7XzWU+3DLVBVIVoqnVm1hRfbo8WJ5JwqISD3iU47CqoVasHZuMct+QHbk NihA2pxiG+5ksoYgcZVdpKhYywqLiUFyC/JseXpSkS59F5fl7s/ltLr7usXBvBXWhLB6 TZQA== 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=n9UBgIyzzTzK5J6Bp6+ggNxMlXDxpqS4WdJD8bxmEBI=; b=Ww3NQi78LM/7MqdXi0A0VrVD/vPiVLK/HcNjGB5sqhbLXQNPwNxPt9UlZkYZy0ldIE btuVCa1+YBNetbEDXkrNs17bnneXzS+z2f2VwjQ2bmU9ofitcJUgdabq86ELF6X7Djmx 1asjGYlRga3CCH1brEdKkEtuO9MxTERL6j8qpzHZtdA0dRs/XvN1FBTtKc7foUmzCgNE hvfwsRpHuYI5j+iDxsUJLK7MB7V3vYD0fVYU/R1IYsCEQoCTsZkq/J8atBt+IsmnLDxn Bt5WFLROwJMPbvw5ZyWJsX+fgzkeZ0AKFtmAoZCBW6n9DrUncsZCzjQvClTOCzb2/QGu RpLw== X-Gm-Message-State: APt69E2JqvKC+8fWSpaYTvrcV82hhnjq8nFEOq7lD8aAqdm3awLmT0tO GraNpEx/qwOmA7vhxfa226kZVXDMA2e1S0LuvQdX/4Vs X-Google-Smtp-Source: AAOMgpfgYYiEp2EnqaxVsvcuMwQZa/V82fJIm96l9U7X57YkfftDygN1V5Q1Ou1kbnMeZzxku6QNbfVgGoWfCfNpbZY= X-Received: by 2002:aca:d592:: with SMTP id m140-v6mr1486354oig.346.1530697950710; Wed, 04 Jul 2018 02:52:30 -0700 (PDT) MIME-Version: 1.0 References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> In-Reply-To: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> From: Martin Thomson Date: Wed, 4 Jul 2018 19:52:19 +1000 Message-ID: To: adrian@olddog.co.uk Cc: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 09:52:36 -0000 Firstly, to answer the question in the subject line. There was no mention of RFC 5742 (conflict review) in the proposed experiment. I mentioned it in my write-up, but it's probably worth repeating: there was a perception of significant value in the process (non-binding as it is), and fulfilling the IESG end was not a burden. Thus, no proposed change there. On Wed, Jul 4, 2018 at 5:56 PM Adrian Farrel wrote: > There seems to be an correlation: the closer to looking like an IETF consensus document, the more IESG input. Are you suggesting that if this step is taken, then there will be less incentive for the IESG to provide their input for things like IRTF and Independent documents? To the extent that we choose people who care about what is good for the Internet, which is still the primary desiderata by my reckoning, I don't see much risk of that happening. On the contrary, where conflict arises, I've seen the IESG take care to provide feedback well outside of our little circle, even if that is a job that usually falls to the IAB. > were an alternative venue for publishing competing specifications to be developed I'd say a lot more has to change than a label before that becomes a serious concern. From nobody Wed Jul 4 03:23:05 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78622130E2F for ; Wed, 4 Jul 2018 03:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 XfeC9cyMedMC for ; Wed, 4 Jul 2018 03:23:01 -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 02484130DC4 for ; Wed, 4 Jul 2018 03:23:00 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w64AMvVq000916; Wed, 4 Jul 2018 11:22:58 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E3FD72203A; Wed, 4 Jul 2018 11:22:57 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id CE10522032; Wed, 4 Jul 2018 11:22:57 +0100 (BST) Received: from 950129200 ([141.85.216.4]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id w64AMtFj008933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2018 11:22:56 +0100 Reply-To: From: "Adrian Farrel" To: "'Martin Thomson'" Cc: References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> In-Reply-To: Date: Wed, 4 Jul 2018 11:22:52 +0100 Message-ID: <02e401d41380$f8bca040$ea35e0c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQG0HSINijmUip1fsXvoWMMwPJekRwGjIZcOpLGm8GA= X-Originating-IP: 141.85.216.4 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23946.006 X-TM-AS-Result: No--26.355-10.0-31-10 X-imss-scan-details: No--26.355-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23946.006 X-TMASE-Result: 10--26.354800-10.000000 X-TMASE-MatchedRID: oCj5caaCQymnykMun0J1wvHkpkyUphL9ak19OpMx65e1eX0jEQ9c6rsI asnPqvyQRvmsVtJsdUpb0VokccNxq6xPoOv3z9vJQ38UP1itDPyFXSyuOiq3HxjQD3m2MCf7hLa HsAD9XHJZzzDA0sjQDT4Mbpv0fAWBZfBDFP8YtaA5eifu3mpbVtjtDfNmCX5a31GU/N5W5BDo3E qslgKKwMPF1PGy80/SyBa+h+fxxKa+9Go4BgFPZnBRIrj8R47FFk73i4rVVIEBWxwPU6jS0Fb4z oda1Vi+gyyevK+EPm4B4u2+YbijGPCqHY1BrPtJNcoW2wO1ntNxb5XAeatg5fjonJ70OQpaTHBh hRXBeAs0hfJKFYkOycdAVDCLCSGcP9QURhuOJ62p2P3/+3QxY6GL0wLo4E7CDZjzHLL3eRaj6kc B7a4dPqQhh8k1xrJOwjkBkJff7t0RMOyeyGLjQCgAQWWdzz5F2u7dK7eipEAdGynCN4u9Jf0Ws+ 9uQ42SYOnCqW7DlGK0UzIszyiEoXosIIFUXbdTRBo4oAu24+SUctRw0zzl2t14Aqe8EzF8WmB3n 3nOpxK/VQbNHOdHkJWAx6tFR9SU7h1xPdlpOhw4jxClIfsQfjoSfZud5+GgkzE2kM4b6Hoo36Y8 tkZdKJSCPKJzP4F23BTxUdcaKkK/WXZS/HqJ2lZ0V5tYhzdWxEHRux+uk8jpP8tMOyYmaA== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 10:23:04 -0000 Thanks Martin, > Firstly, to answer the question in the subject line. There was no > mention of RFC 5742 (conflict review) in the proposed experiment. I > mentioned it in my write-up, but it's probably worth repeating: there > was a perception of significant value in the process (non-binding as > it is), and fulfilling the IESG end was not a burden. Thus, no > proposed change there. Clarity is always welcomed. We refer to 5742 reviews, and that is a helpful label that everyone = understands. But just to note that 5742 describes how the IESG = (currently) plans to handle "conflict reviews" as set out in 4846. I'm glad to hear that you hear that 5742 reviews are not perceived (by = the IESG) as being a burden on the IESG. But I wasn't asking about the reviews (nor was the subject line) but = about "IESG notes". So... > On Wed, Jul 4, 2018 at 5:56 PM Adrian Farrel = wrote: > > There seems to be an correlation: the closer to looking like an IETF = consensus >> document, the more IESG input. >=20 > Are you suggesting that if this step is taken, then there will be less > incentive for the IESG to provide their input for things like IRTF and > Independent documents? To the extent that we choose people who care > about what is good for the Internet, which is still the primary > desiderata by my reckoning, I don't see much risk of that happening. > On the contrary, where conflict arises, I've seen the IESG take care > to provide feedback well outside of our little circle, even if that is > a job that usually falls to the IAB. Hmmm. I am not suggesting anything. I'm asking. I have no doubt that the IESG is empowered to review or delegate review = of anything. And I assume that all Right-Thinking People (TM) will = listen carefully to any input they get from that source. I'm asking whether the IESG believes that if it asks (say) the IRTF to = include an "IESG Note" on a document published as IRD9003 (instead of = RFC9003) it is just as likely to be listened to as it is today. And you (sort of answered)... > > were an alternative venue for publishing competing specifications to = be >> developed >=20 > I'd say a lot more has to change than a label before that becomes a > serious concern. And this may (hopefully) be true. It is worth considering, however, what it is that bonds the IRTF and IS = to the IETF (beyond the obvious technology relationship). The = "misconception" that the RFC series is an amorphous mass might be = exactly the thing that makes the IRTF and IS keep close to the IETF. To be pedantic about this, 4846 says it describes the editorial and = processing norms that can be used for Independent Submissions as the = community goes forward into new relationships between the IETF community = and its primary technical publisher." Someone might argue that the rules = and procedures in 4846 are important and adhered to precisely because = the IS documents are published in the RFC series alongside the IETF = documents. In other words, the very "confusion" you talk about in your = draft necessitates the procedures, but take IS documents out of the RFC = series and (regardless of the use of the same primary publisher) then = nothing in 4846 applies.=20 Now, for an abundance of clarity [(c) Terry Manderson], please = understand that I am not expressing a view or promoting an opinion: I am = asking what people think and why. Thanks, Adrian From nobody Wed Jul 4 04:24:17 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1200130E3B for ; Wed, 4 Jul 2018 04:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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=cooperw.in header.b=SuMALrAi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fXM6fi+D Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zku5f7A7WpTS for ; Wed, 4 Jul 2018 04:24:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7370130DCE for ; Wed, 4 Jul 2018 04:24:13 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E70BD21BBA; Wed, 4 Jul 2018 07:24:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 04 Jul 2018 07:24:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=F+NbfMpKWVPBfBMUXZ8VSYWpGf10M bZ7uY46XYcNlEc=; b=SuMALrAigXV6n6kw/oY+/05MQPMxrV55Woj6VubkGBYVw H+RHGqvO1r8lMq3C9vF0pxt/9+TuneHlVlDUnBL+UOLBGMkru5rpAyUObe09Tcxa b12bP9sKj011kmNbSpEaXtE7UIcClPr7l+dv5vWf+58DfW4FM2Ew4FsVpw14TcyZ TXTWGLepd2ANXY6H5gpZurVIEYSQ8P4rGY88WQzD3+1Sj1qZLztU15O8khxybmLq jZGn9q/b+/K7+Kxwcfa0DHDGS+TremMJWt4QF5s/aF3EgYh2UIAQFTS4nI+mtC3l mWgiqgMVvm0Q9yxiGMtkKMcafhD2g5Swe5Xjx4hoQ== 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=F+NbfM pKWVPBfBMUXZ8VSYWpGf10MbZ7uY46XYcNlEc=; b=fXM6fi+DwEkizNTbZZZNkV dJdlfG7vf5vZ2ruNPAiX49O8eadrvratVjeK4Ph+LeNw/lvxOYJmkpJGKakSWxo6 uNIXGhpikhCBb/ypP1Qf0DZDVL7C6elW04TXWccec6G8qgHcgegyFLXoAw+ZZyyZ nFBhwzQ3bQrrUBmqqSdcRv3YKSzElKWZcL044O7hCDcAk1wxSVCMut1vJ6gFSbPO OnjYKImEyozqAwp/9L6Z1Xt/KQvhLHOHnYOskW1SmgkVEy7mMcgSlgrRRdD6Gfpd NkICCIFYIPEX7VbE7npQhuFuqatvahJObu/PlT48RjdPLwWDr9WpjHdE+BA55oCA == X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.160] (pool-108-18-47-61.washdc.fios.verizon.net [108.18.47.61]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F94EE4686; Wed, 4 Jul 2018 07:24:12 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Alissa Cooper X-Mailer: iPhone Mail (15F79) In-Reply-To: <027501d41365$06112ac0$12338040$@olddog.co.uk> Date: Wed, 4 Jul 2018 07:24:11 -0400 Cc: "Andrew G. Malis" , rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <027501d41365$06112ac0$12338040$@olddog.co.uk> To: adrian@olddog.co.uk Archived-At: Subject: Re: [Rfcplusplus] Financial rewards [draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 11:24:16 -0000 Hi Adrian, On Jul 4, 2018, at 3:02 AM, Adrian Farrel wrote: >> Regarding your example of authors being financially rewarded for RFC >> publication, I=E2=80=99m sure that would extend to any IETF publication t= ype if >> the IETF were to run this experiment,=20 >>>=20 >>> Why are you sure? I=E2=80=99m curious because this aspect has come up in= the >>> IESG=E2=80=99s discussions of the proposed experiment, namely the notion= that >>> a document with the label =E2=80=9CRFC=E2=80=9D is or would be considere= d more valuable >>> than a document with a different label. >=20 > The relative rewards exist already. I didn=E2=80=99t read Andy=E2=80=99s point as being about relative rewards. I= read it as a claim that the perceived value of RFC9700 would be the same as= INF9700 or EXP9700. But perhaps he can clarify if I misunderstood. > Furthermore, this really should not be a consideration in the solution spa= ce. Yes, it is an observational input to understanding the value of two bran= ds: "RFC" and "IETF consensus". This was exactly why I asked, so as to understand Andy=E2=80=99s perception o= f the brand. > But the idea that IETF would attempt to socially engineer the behaviour of= remuneration systems is (I hope) out of scope. I haven=E2=80=99t seen anyone suggest doing this. Alissa= From nobody Wed Jul 4 05:41:16 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04C0130E61 for ; Wed, 4 Jul 2018 05:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 mzmsviWHZ4_O for ; Wed, 4 Jul 2018 05:41:13 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 06E19130E5C for ; Wed, 4 Jul 2018 05:41:13 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id p129-v6so1880800ywg.7 for ; Wed, 04 Jul 2018 05:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HA4M+5BYOnvPTEMlmU/oJzPChQ1zsX+R1V+uAUEp3Ts=; b=IYMwiJ3NMOnM2FEI+rD5BorE+Z0jnZYnsWmdIQRGryN3pGFvk6NUSJgB2z3zKwYtcm sUZLOL0oX2eBNrJH7pFAGXlz6rnbLfBuxdU+y2qnPWtM1ukH7WbMwqiSmZOCb/Yb0USb vYjnZOaz4In2vAFLFcPbWNeBG8T7OQHCg0d0ApkmAnLg9x/Q45zMSzSjLygqNYnWKpku 3X4fOHGhIDOl7iyD42KKBGH2n1RNLuAPI9UWW49JK8kvelFDlIRGEXfn9RJmFMld5kuX /sOVPLvohe6lQuMxyk6BtCsF5szZ5UDNsFIdqn13FawEzO55dQ/DuRHAJc3+/bJCJ3is LYIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HA4M+5BYOnvPTEMlmU/oJzPChQ1zsX+R1V+uAUEp3Ts=; b=UNm0kdqk9ab15SED+HCi9Xht/l2CqQJTTGzTNr2V8plXunEqg9bWqQE/JntP7xI09c TZlE+RZvAhLFQbyi8RllIrLqvXJG85omRxjpZmFYj/HJim1QZ/g0hColyCJb1Hyy3xCy tQXd1Sy/COBZlODceWM+UDvULK5FdOHVHvQNe1eLPMEZFHjzELA14O9fs3kse/31wxve D88qfeYNK3VDq9RXFCadq7mVMAPnOcKqilajovFlnImrcMOjlxjd4I8J3huaFPqVvSqU G2gg1pEUCpXSHKJjO6ubjswPmLa5K7CAkCbhRykDteCW2Gc534ClCFq4U4cEbuhJ9wJ0 wdTA== X-Gm-Message-State: APt69E16AtHcx+BOkTpIryQhrrHyWWXgW47jcUV4W0P5Gxxodt6hqBZC 1MW5fyy73ROdMrrIi9I63mv9F/bfLsOTlWdE15t+UQ== X-Google-Smtp-Source: AAOMgpfEj2fjRBA0rS27AmGGYYatJALYN46gDEJxzwXCyrQMyacE45F+gZdJPksxw+nwO2qXb93Qk8rp9ag6khprVfM= X-Received: by 2002:a81:b642:: with SMTP id h2-v6mr828956ywk.102.1530708072217; Wed, 04 Jul 2018 05:41:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 05:40:31 -0700 (PDT) In-Reply-To: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> From: Eric Rescorla Date: Wed, 4 Jul 2018 05:40:31 -0700 Message-ID: To: Brian E Carpenter Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000e6554e05702bbe04" Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 12:41:15 -0000 --000000000000e6554e05702bbe04 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 10:17 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Eric, > > Thanks for that substantive answer. To be frank I'd rather > leave the response to someone who understands more about > crypto deployment than I do. Fair enough. It does seem to me that for > national algorithms, they will be in the libraries anyway because > they will be mandatory procurement requirements. That's certainly an understandable prediction, but I haven't found it to be true in practice. For instance, NSS doesn't implement GOST or SM, and to the best of my knowledge neither does BoringSSL. And if we did decide to implement those algorithms for some market reason, having them documented in an RFC would not make our lives substantially easier. Thanks, -Ekr --000000000000e6554e05702bbe04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 3, 2018 at 10:17 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
Eric,

Thanks for that substantive answer. To be frank I'd rather
leave the response to someone who understands more about
crypto deployment than I do.

Fair enough.


It does= seem to me that for
national algorithms, they will be in the libraries anyway because
they will be mandatory procurement requirements.

That's certain= ly an understandable prediction, but I haven't found it to be true in p= ractice. For instance, NSS doesn't implement GOST or SM, and to the bes= t of my knowledge neither does BoringSSL. And if we did decide to implement= those algorithms for some market reason, having them documented in an RFC = would not make our lives substantially easier.

Thanks,
-Ekr


--000000000000e6554e05702bbe04-- From nobody Wed Jul 4 05:45:20 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78928130E7F for ; Wed, 4 Jul 2018 05:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=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 fJF2d5Mil15D for ; Wed, 4 Jul 2018 05:45:11 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11BD130F56 for ; Wed, 4 Jul 2018 05:45:11 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id h127-v6so2024517ybg.12 for ; Wed, 04 Jul 2018 05:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2trB5uQ7YtMwH2mHpf/PAY3b/8hZK80ysU7FvvEEgfg=; b=NsbzaJsSicyePKHivMD4EYIPb29BEwI2x5UW9Gn3PR3ZctrMQ9D4EetUcCcmFO1JuG yrUXqa68kDOId0Grwmrncw7SqTRXDQYswCA8n9ZBzlCALe9wusKWIoUJttpr5zfzW3aO CAhlbJ8UNKmlSQDqbPkZIM+JhQYPbIM5yyEB8lPHW3Vdswv4/fkp9ZDLpH4IsovuIusN iP7nj+xljVnvPTkR4BuhldoKfr0VtsPXDjDjd0sDeXSpxFhHP48iODQC6cZMuSGaMJWj drONWh48hIkvtENVCNGeTpgT4yxydvztS3pMBjqkDRiTU50w49q8+1pGVxXQjfFD6U/i 2iVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2trB5uQ7YtMwH2mHpf/PAY3b/8hZK80ysU7FvvEEgfg=; b=SAXmFAmZ0wV19V+OBFHy1bRvp7oD9K0VBxFZFJeueiJcRqQ7uLBtvNLr1ghrVXcwGu ivSgqwcZ3p1fvQnYXsJXPqJ9KwzS06bNggvsJsxllzMBGveLreys2irjewPuUuGbadku pevhDgCtJnK73VeL5XocDPtFETD6ixkboFzg+1UtkQUwXwTPqApPxorJJqIPIB3bQfUP IkQaCWh2bYpyISMuvCSbZ+3Ioz7l2Kzmylux1CTsLKX1I69a5x+7nLu2ha8OWU1fbi+x 0BZqsx/a1dLTCppUm/SJafNWHTORAAgRaFm8S735Ex9F5Y71JgJZl6ay9GKwaHeVON8o rChQ== X-Gm-Message-State: APt69E3YrryCWOeLAcz0iIJizmc5SEDKGH7RTNJKq9LyMliq5NTfvwIc YQaUgd5xWkPhyQaB8zXkopzPpQZhyg3OiF2XJ9s8kw== X-Google-Smtp-Source: AAOMgpfdCpYAsEThmYbELIshPdJlHcifT9ESznX5lVAdTAB41KSFpb0EcDNj/h6zB7x06YkUAx8LJMVRveOssDXgxp8= X-Received: by 2002:a25:adcb:: with SMTP id d11-v6mr944376ybe.73.1530708310971; Wed, 04 Jul 2018 05:45:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 05:44:30 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20180703234604.0b3e3b08@elandnews.com> References: <6.2.5.6.2.20180703135941.0cf5ab78@elandnews.com> <6.2.5.6.2.20180703234604.0b3e3b08@elandnews.com> From: Eric Rescorla Date: Wed, 4 Jul 2018 05:44:30 -0700 Message-ID: To: S Moonesamy Cc: Martin Thomson , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000216eac05702bcde0" Archived-At: Subject: Re: [Rfcplusplus] Comments on draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 12:45:18 -0000 --000000000000216eac05702bcde0 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 4, 2018 at 1:02 AM, S Moonesamy wrote: > Hi Martin, > At 05:58 PM 03-07-2018, Martin Thomson wrote: > >> Not so much. I don't believe that allocating codepoints should be use >> as a locus of control. We've seen some pretty awful consequences from >> that. Recently: three-way squatting on the same codepoint in TLS, for >> instance. >> >> The concern is simpler: the creation of non-interoperable deployments. >> > > There was a perception that codepoint allocation was a locus of control. Yes, I agree with that. What Martin is alluding to is that much of the security area has concluded for its protocols that that was a mistake; the result has been code point squatting, collisions, and unnecessary debate and effort about documents which really only existed in the IETF because the authors needed code point allocations. What we are instead moving towards is the strategy embodied in https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/: make it easy to do code point registrations (i.e., with just an I-D or a readily available external reference) but mark such registrations "Not Recommended". Of course, people may have different opinions about whether this is a good idea. -Ekr It is one of the underlying IETF debates which happen every now and then, > e.g. when the allocation requirement is "RFC required". > > Bad choice of words maybe, because that's just my opinion. That is, I >> believe that DASH is perfectly adequate for the use case and that the >> publication of HLS as an RFC is entirely unnecessary. That the >> conflict review found no conflict is unsurprising, but that's a very >> narrow determination. >> > > As a comment about "use case", it is sometimes used within the IETF to > argue for some change or that a proposal is "inadequate". > > I took a quick look at "usage" of the RFC and I found that it is > referenced outside the IETF as a vendor specification. One of the > references is to tools.ietf.org. Publication of other RFCs under the > IETF domain name might have led to some confusion about IETF RFCs and other > RFCs. > > Regards, > S. Moonesamy > > P.S. I am okay with the choice of words for the draft. > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --000000000000216eac05702bcde0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 4, 2018 at 1:02 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:
H= i Martin,
At 05:58 PM 03-07-2018, Martin Thomson wrote:
Not so much.=C2=A0 I don't believe that allocating codepoints should be= use
as a locus of control.=C2=A0 We've seen some pretty awful consequences = from
that.=C2=A0 Recently: three-way squatting on the same codepoint in TLS, for=
instance.

The concern is simpler: the creation of non-interoperable deployments.

 There was a perception that codepoint allocation was a locus of control.=C2= =A0

Yes, I agree with that.

=

-Ek= r

It = is one of the underlying IETF debates which happen every now and then, e.g.= when the allocation requirement is "RFC required".

Bad choice of words maybe, because that's just my opinion.=C2=A0 That i= s, I
believe that DASH is perfectly adequate for the use case and that the
publication of HLS as an RFC is entirely unnecessary.=C2=A0 That the
conflict review found no conflict is unsurprising, but that's a very narrow determination.

 As a comment about "use case", it is sometimes used within the IE= TF to argue for some change or that a proposal is "inadequate".
I took a quick look at "usage" of the RFC and I found that it is = referenced outside the IETF as a vendor specification.=C2=A0 One of the ref= erences is to tools.ietf.org.=C2=A0 Publication of other RFCs under the I= ETF domain name might have led to some confusion about IETF RFCs and other = RFCs.

Regards,
S. Moonesamy

P.S.=C2=A0 I am okay with the choice of words for the draft.
_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus

--000000000000216eac05702bcde0-- From nobody Wed Jul 4 05:52:53 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293E0130F03 for ; Wed, 4 Jul 2018 05:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=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 h6j25nO9tpd3 for ; Wed, 4 Jul 2018 05:52:49 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 9EB17130F1E for ; Wed, 4 Jul 2018 05:52:49 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id s8-v6so2036922ybe.8 for ; Wed, 04 Jul 2018 05:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ThLfsSj9FmflxIDCRpCUcBDp24+kHfCTxV8uj9od9UI=; b=L01qZb1259qYIYdP7xpM+XDfVcosHUYpkyKGOcHf2bSD4mzk/inPWIP8j+Sv7B8rQn 3idi9vIlr1IDBM90VSqjJUZmWO3w6Sh6cI6JMBwtO2Vrku/9QvvHx+quEbWpk5a83P/s Y9n0tl9gehBrMMSRfgeANrrPLVZpTkvob5QgmAQmyqd9ON84HTaeel2ZOamIkQaWRnTY Htl3qKy5oA3Idn1TjP3NKfc9zliu5n2Ip4liTwBqzAtyCmw5vAZAZgAM3HidPq50lKk+ yFrIllOomaB8MQK3ULB6fizTMI4ty88zDROt7sgw2OJiZbmLQZlQ38RQ+6AdbONj5a5Q tdbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ThLfsSj9FmflxIDCRpCUcBDp24+kHfCTxV8uj9od9UI=; b=W3A2gTSWZdRWrOh+LYI8CrFzDYbGRBYfz/iQshkTXa8FtkNB147wH+QxzPoszs86Pm WNe1x/qNQHxGA4+kX81AmVetvXy+Py8Wwongext4se+g9YjLTw4sPYmTfQXF9QM/GKab 4Wfm/xNYTKPe1DNPQ0ZigqMaDxI/Jri/zNgHqgLf2E9abhVoN+KtS8VeE2fNVL3Uvt3j Q5/xDVi146xBUu1cTkxDQqcptWakiEaJBEB+qU5iOYuw+ctUjuBXQuaXZE9yr7FMg5Iq r67EHDILth2C7AUAtItmwlJFJC9/ZYCKVHUIDtFi9zylsL7DcYfHLp3s5S28J/FaEFLn P6/g== X-Gm-Message-State: APt69E0FAPh3956dQUAnJjPPecunP3WMColCnPnVl68AZoGmFVZxeup9 I+vAlqtjux2yxLVlzRymITZDVziuQ4JUy30cK/vs1ukf X-Google-Smtp-Source: AAOMgpcy0ZerVRiC9gJYPgF4cQ8rmVxL7GU9XOKfU4neGmQVUnKw28A5CJXuOWRCmq0H1/3H8CehxXvB3I8zAy8F0y0= X-Received: by 2002:a25:3496:: with SMTP id b144-v6mr938227yba.275.1530708768940; Wed, 04 Jul 2018 05:52:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 05:52:08 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 4 Jul 2018 05:52:08 -0700 Message-ID: To: Eliot Lear Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000006d698405702be8de" Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 12:52:52 -0000 --0000000000006d698405702be8de Content-Type: text/plain; charset="UTF-8" On Wed, Jul 4, 2018 at 1:10 AM, Eliot Lear wrote: > So do encryption algorithms. WRT what EKR said, it seems better to have > the algorithm documented than not, if it is being used. The test: is it > really being used? > I want to narrow my response to this point: what we've done in TLS is allow code point registration with any stable reference, internal or external. This includes an I-D. We didn't make this change primarily in order to address the issues raised by this BOF, but I do think it was a good change. Can you explain why you don't think that this suffices? -Ekr --0000000000006d698405702be8de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 4, 2018 at 1:10 AM, Eliot Lear <lear=3D40c= isco.com@dmarc.ietf.org> wrote:
=20 =20 =20
=C2=A0 So do encryption algorithms.=C2=A0 WRT what EKR said, it seems better to have the algorithm documented than not, if it is being used.=C2=A0 The test: is it really being used?=C2=A0

I want to narrow my response to this point: what we've= done in TLS is allow code point registration with any stable reference, in= ternal or external. This includes an I-D. We didn't make this change pr= imarily in order to address the issues raised by this BOF, but I do think i= t was a good change. Can you explain why you don't think that this suff= ices?

-Ekr

--0000000000006d698405702be8de-- From nobody Wed Jul 4 06:22:15 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B20130E96 for ; Wed, 4 Jul 2018 06:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIsoC5gwsMvF for ; Wed, 4 Jul 2018 06:22:10 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907AF130E65 for ; Wed, 4 Jul 2018 06:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10041; q=dns/txt; s=iport; t=1530710529; x=1531920129; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=vwv9zZYWHXOtXNnk/L6IDwL3fidvMrhWdWCN4eA/m3A=; b=QZe5pUHymYZUKUZTh2FOPFcU897AJDWK1J9wxijphHxNK9hQ7w9rm9hx hk8TIMoQqxAuUDTBuTu0yBqH7kotc9vR62a7zn48jQh7mBKDxCyfFewRB EqFu9plX2j1BObh5vs1YeLjcubkTXdlYQsbm+cXSvmw2VYt1XlEoi+c9j U=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCJyDxb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUYEiiDeohjjTQqkB+HCAgDhGwCgkU4FAECAQECAQECbSh?= =?us-ascii?q?CEAGEZAEFI1YQCw4KJwMCAkYRBg0GAgEBgxwBgX+oUoIcH4g1gSsPiwKBDye?= =?us-ascii?q?Ban6DGASEX4JVAplMCYNagViDOIYwBogShUWSCYFYIYFSMxoIGxWDJIIkF44?= =?us-ascii?q?ZPTABiAKJXwEB?= X-IronPort-AV: E=Sophos;i="5.51,306,1526342400"; d="asc'?scan'208,217";a="4965668" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2018 13:22:07 +0000 Received: from [10.61.96.59] (dhcp-10-61-96-59.cisco.com [10.61.96.59]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w64DM7H8015095; Wed, 4 Jul 2018 13:22:07 GMT To: Eric Rescorla Cc: rfcplusplus@ietf.org References: From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Wed, 4 Jul 2018 15:22:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tUpefDNmXdQlcQkahAH0Xobpx4da8P2qu" Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 13:22:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tUpefDNmXdQlcQkahAH0Xobpx4da8P2qu Content-Type: multipart/mixed; boundary="xcDzi916bRoIakFIM919ilMp9TkiMc7CT"; protected-headers="v1" From: Eliot Lear To: Eric Rescorla Cc: rfcplusplus@ietf.org Message-ID: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications References: In-Reply-To: --xcDzi916bRoIakFIM919ilMp9TkiMc7CT Content-Type: multipart/alternative; boundary="------------840F89904976B9CB3010B19F" Content-Language: en-US This is a multi-part message in MIME format. --------------840F89904976B9CB3010B19F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Eric, On 04.07.18 14:52, Eric Rescorla wrote: > > > On Wed, Jul 4, 2018 at 1:10 AM, Eliot Lear > > wrote: > > =C2=A0 So do encryption algorithms.=C2=A0 WRT what EKR said, it see= ms better > to have the algorithm documented than not, if it is being used.=C2=A0= > The test: is it really being used?=C2=A0 > > > I want to narrow my response to this point: what we've done in TLS is > allow code point registration with any stable reference, internal or > external. This includes an I-D. We didn't make this change primarily > in order to address the issues raised by this BOF, but I do think it > was a good change. Can you explain why you don't think that this suffic= es? > I wasn't really thinking in terms of code points when I wrote that, but since you asked: "Any stable reference" sounds fine.=C2=A0 Journal refere= nces in the face of scribd and DOIs are pretty cool these days.=C2=A0=C2=A0 A = nit: we don't normally count I-Ds in that group, and the boiler plate explains wh= y: > =C2=A0=C2=A0 Internet-Drafts are draft documents valid for a maximum of= six months > =C2=A0=C2=A0 and may be updated, replaced, or obsoleted by other docume= nts at any > =C2=A0=C2=A0 time.=C2=A0 It is inappropriate to use Internet-Drafts as = reference > =C2=A0=C2=A0 material or to cite them other than as "work in progress."= They are not intended to be stable references.=C2=A0 One way we know this= to be the case is that they may not be normatively referenced, and most notably, they're supposed to expire, and can be rev'd leading to some amount of confusion if you then don't do another code point assignment. What I was thinking about: I'm not sure that this is just about a code point reference.=C2=A0 It's also about providing access to information by= which others can assess the value of the algorithm.=C2=A0 Yes, there are other venues, but as you yourself pointed out, there really hasn't been any harm in having the algorithm published as an RFC: > > It does seem to me that for > national algorithms, they will be in the libraries anyway because > they will be mandatory procurement requirements.=20 > > > That's certainly an understandable prediction, but I haven't found it > to be true in practice. Not a great demonstration of brand dilution, right?=C2=A0 Perhaps that br= and dilution took place in Russia?=C2=A0 I dunno.=C2=A0 (And yes, there was s= ome hooha in the press at the time the GOST RFCs were released.=C2=A0 I do see them= referenced here and there, by the way- not sure there's much difference between that and an I-D; probably better spelling and grammar). Also, a reminder of the context in which you quoted that text: if the algorithm is used, that provides strong incentive for it to be properly documented.=C2=A0 In fact, one of the earlier RFC authors and IETF participants, Brian Kantor (NNTP co-author) made a very good point that RFCs are often most valuable when they document existing practice.=C2=A0 That's a very high bar these days. Eliot --------------840F89904976B9CB3010B19F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Eric,

On 04.07.18 14:52, Eric Rescorla wrote= :


On Wed, Jul 4, 2018 at 1:10 AM, Elio= t Lear <lear=3D40cisco= =2Ecom@dmarc.ietf.org> wrote:
=C2=A0 So do encr= yption algorithms.=C2=A0 WRT what EKR said, it seems better to h= ave the algorithm documented than not, if it is being used.=C2= =A0 The test: is it really being used?=C2=A0

I want to narrow my response to this point: what we've done in TLS is allow code point registration with any stable reference, internal or external. This includes an I-D. We didn't make this change primarily in order to address the issues raised by this BOF, but I do think it was a good change. Can you explain why you don't think that this suffices?

I wasn't really thinking in terms of code points when I wrote that, but since you asked: "Any stable reference" sounds fine.=C2=A0 Journa= l references in the face of scribd and DOIs are pretty cool these days.=C2=A0=C2=A0 A nit: we don't normally count I-Ds in that group, = and the boiler plate explains why:

=C2=A0=C2=A0 Internet-Drafts are draft docu= ments valid for a maximum of six months
=C2=A0=C2=A0 and may be updated, replaced, or obsoleted by other do= cuments at any
=C2=A0=C2=A0 time.=C2=A0 It is inappropriate to use Internet-Drafts= as reference
=C2=A0=C2=A0 material or to cite them other than as "work in progre= ss."

They are not intended to be stable references.=C2=A0 One way we know = this to be the case is that they may not be normatively referenced, and most notably, they're supposed to expire, and can be rev'd leading to some amount of confusion if you then don't do another code point assignment.

What I was thinking about: I'm not sure that this is just about a code point reference.=C2=A0 It's also about providing access to information by which others can assess the value of the algorithm.=C2= =A0 Yes, there are other venues, but as you yourself pointed out, there really hasn't been any harm in having the algorithm published as an RFC:

It does seem to me that for
national algorithms, they will be in the libraries anyway because
they will be mandatory procurement requirements.

That's certainly an understandable prediction, but I haven't found it to be true in practice.

Not a great demonstration of brand dilution, right?=C2=A0 Perhaps tha= t brand dilution took place in Russia?=C2=A0 I dunno.=C2=A0 (And yes, t= here was some hooha in the press at the time the GOST RFCs were released.=C2=A0= I do see them referenced here and there, by the way- not sure there's much difference between that and an I-D; probably better spelling and grammar).

Also, a reminder of the context in which you quoted that text: if the algorithm is used, that provides strong incentive for it to be properly documented.=C2=A0 In fact, one of the earlier RFC authors an= d IETF participants, Brian Kantor (NNTP co-author) made a very good point that RFCs are often most valuable when they document existing practice.=C2=A0 That's a very high bar these days.

Eliot
--------------840F89904976B9CB3010B19F-- --xcDzi916bRoIakFIM919ilMp9TkiMc7CT-- --tUpefDNmXdQlcQkahAH0Xobpx4da8P2qu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAls8yf4ACgkQh7ZrRtnS ejMzNAgA2z1RfrQZr6MCpUlCCBv4MStIaIv3+k+t+GLD5eFG/e4ox47n37cXh/B8 PPpck8/cjtICfBaagTtD0ezXgPtu+HqUkx+AWmRFsShrfJvISt0lUNkANuizTCUS 9pwidae1TIVZTKIMtZtj/uwipdoMWdL1hqCHcFK320175KtWgCLEvZb4/qFSowhx JpsAwulOsE/pfCcuP5v8HfwdaAzQEhhkw2o9F3bnyw/gij68oXVzJgDJo5LvE7LG HBirQ6IaheznwaQlFySUhSOaUbSpVTxx8VvzwW8leqj+VbVMI8gU/siHswzen8Nv hH+qL2VyM1sRkSlz20CVrs6Nw66QJA== =QVJq -----END PGP SIGNATURE----- --tUpefDNmXdQlcQkahAH0Xobpx4da8P2qu-- From nobody Wed Jul 4 06:24:53 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212A9130DBE for ; Wed, 4 Jul 2018 06:24:52 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 s1FYFikEad2D for ; Wed, 4 Jul 2018 06:24:50 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0F4130E65 for ; Wed, 4 Jul 2018 06:24:47 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fahm0-000J3z-3p; Wed, 04 Jul 2018 09:24:44 -0400 Date: Wed, 04 Jul 2018 09:24:36 -0400 From: John C Klensin To: Martin Thomson , adrian@olddog.co.uk cc: rfcplusplus@ietf.org Message-ID: In-Reply-To: References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 13:24:52 -0000 --On Wednesday, July 4, 2018 19:52 +1000 Martin Thomson wrote: > Firstly, to answer the question in the subject line. There > was no mention of RFC 5742 (conflict review) in the proposed > experiment. I mentioned it in my write-up, but it's probably > worth repeating: there was a perception of significant value > in the process (non-binding as it is), and fulfilling the IESG > end was not a burden. Thus, no proposed change there. You mean "no intentional proposed change". Considering my comments some hours ago about impact factors and Eliot's (IMO very insightful and relevant) analysis of labeling/experiments/ and ramifications. Suppose that "IRTFnnnn" rather than "RFCnnnn" causes impact scores and/or the near-term perception of review quality and the like to drop and that causes some of those whose participate in the IRTF (or support for that participation) depends on those types of publication credits. If the number of those people started to have significant negative consequences for the amount of quality that could be done and the IRTF were completely rational about it, it would be appropriate for them to consider jumping ship, possibly taking the series to a commercial academic publisher with a large and effective marketing and public relations department. That, in turn, could have two side effects: (1) Unless new and careful arrangements were made, the IESG, as an authority, would end up with zero input, conflict review or otherwise. (2) Whether or not that occurred, the perceived value of the RFC Series/ brand would probably go down as the publisher would have significant incentives to promote their IRTF journal as the premium product in the Internet space with the left-behind parts of the RFC Series representing lower quality from an academic, etc., standpoint. The ISE situation is different, but not much different. Am I confident that any of those things would happen? No. But I think the risks are clear enough that we should include them in our considerations. john From nobody Wed Jul 4 06:56:22 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4677130FC4 for ; Wed, 4 Jul 2018 06:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 FH_dLpL-ZB6D for ; Wed, 4 Jul 2018 06:56:04 -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 680C2130F88 for ; Wed, 4 Jul 2018 06:56:04 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w64DtuM8022253; Wed, 4 Jul 2018 14:55:57 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C745A2203B; Wed, 4 Jul 2018 14:55:56 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id B1D662203C; Wed, 4 Jul 2018 14:55:56 +0100 (BST) Received: from 950129200 (86-120-69-50.rdsnet.ro [86.120.69.50] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id w64Dttq0000505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2018 14:55:56 +0100 Reply-To: From: "Adrian Farrel" To: "'Alissa Cooper'" Cc: "'Andrew G. Malis'" , References: <027501d41365$06112ac0$12338040$@olddog.co.uk> In-Reply-To: Date: Wed, 4 Jul 2018 14:55:52 +0100 Message-ID: <035201d4139e$b9b03380$2d109a80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQKqx+3cmPKdTx0m9LN/mfPi6JkuOgMVLz6UorkB8ZA= X-Originating-IP: 86.120.69.50 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23946.006 X-TM-AS-Result: No--11.713-10.0-31-10 X-imss-scan-details: No--11.713-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23946.006 X-TMASE-Result: 10--11.712900-10.000000 X-TMASE-MatchedRID: cgbqQT5W8hc4HKI/yaqRm5mug812qIbz9mnDjfUPq553lJyxFpl46ZiF Tjjm/a6UfeZYbD4N2sA3LXzHrryidbXAj35CMHKuZSNLxsgoyr9+Mk6ACsw4JjNzZQXTq3sObwI uAyuB59wKEV0L9GBl4UF5k0kEYQz280agMA16DhXkNIw8RlACQ520dShmm+V5T7S4ZU4XTxCMHQ N0PX3GJOfOVcxjDhcwPcCXjNqUmkUgBwKKRHe+r87SSTwTeYSqK4hL8ZVAlUgkQ3ZAwpNDh8Kgk NKCDrESfkXrtpXMDaQ= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfcplusplus] Financial rewards [draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 13:56:21 -0000 Hi, >>>> Regarding your example of authors being financially rewarded for = RFC >>>> publication, I=E2=80=99m sure that would extend to any IETF = publication type if >>>> the IETF were to run this experiment, > >> > >> Why are you sure? I=E2=80=99m curious because this aspect has come = up in the > >> IESG=E2=80=99s discussions of the proposed experiment, namely the = notion that > >> a document with the label =E2=80=9CRFC=E2=80=9D is or would be = considered more valuable > >> than a document with a different label. > > > > The relative rewards exist already. >=20 > I didn=E2=80=99t read Andy=E2=80=99s point as being about relative = rewards. I read it as a claim that > the perceived value of RFC9700 would be the same as INF9700 or = EXP9700. But > perhaps he can clarify if I misunderstood. Right. And I am saying (not suggesting or asking) that in institutions = where rewards exist, there is already a gradation between different = types of RFC. IOW the organisations that pay rewards are not confused by = the different types of RFC and pay different amounts for different RFCs = according to the organisation's objectives.=20 > > But the idea that IETF would attempt to socially engineer the = behaviour of > > remuneration systems is (I hope) out of scope. >=20 > I haven=E2=80=99t seen anyone suggest doing this. Good. Adrian From nobody Wed Jul 4 08:41:32 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221821310A0 for ; Wed, 4 Jul 2018 08:41:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 fHrJljpg2B_7 for ; Wed, 4 Jul 2018 08:41:17 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E221130E52 for ; Wed, 4 Jul 2018 08:41:17 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1faju4-000JOi-8w; Wed, 04 Jul 2018 11:41:12 -0400 Date: Wed, 04 Jul 2018 11:41:04 -0400 From: John C Klensin To: Martin Thomson , mohamed.boucadair@orange.com, Paul Hoffman cc: rfcplusplus@ietf.org Message-ID: In-Reply-To: References: <787AE7BB302AE849A7480A190F8B93302DF51569@OPEXCLILMA3.corporate.a droot.infra.ftgroup> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Outlining the experiment X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 15:41:30 -0000 Martin and Med, Let me build a bit on Paul's summary of vendor customer requirements for things that are not standards. Inline below. --On Wednesday, July 4, 2018 06:04 +0000 mohamed.boucadair@orange.com wrote: > Hi Martin, > > You said: > > === > RFC 7974 is the best example > I have of this. It bears a warning nearly that strong and yet > I have received or witnessed strong endorsements of its > virtues on several occasions. and --On Wednesday, July 4, 2018 16:17 +1000 Martin Thomson wrote: > On Wed, Jul 4, 2018 at 4:04 PM > wrote: >> * Why not considering the problem from another perspective: >> wouldn't the "strong endorsements" be a signal to question a >> note itself? > > They could be. You can make that assessment for yourself, but > the IESG don't make these statements lightly, and I respect > their conclusions. FWIW, Section 1.2 of that document is > pretty frank about the purpose of the document, so the > question of dishonesty clearly doesn't apply, just the > potential for confusion. I respect the IESG's conclusions too and IETF informed consensus conclusions about the right way to go even more so. But, when a vendor decides to require support for some spec that is not on the standards track (even one the IESG has warned against in some detail), I think there are three possibilities. (i) They have reviewed the spec and concluded it is a good idea for their purposes, even though the IETF has reached an opposite conclusion. (b) The spec is widely-deployed enough that they have customer requirements to interoperate with it. (c) They are idiots or excessively influenced by aggressive marketing and have therefore uncritically accepted the specification probably without reading either it or the notes attached to it. I don't think we can solve the third problem. Different labels are unlikely to make a difference, disclaimers that are not read because the document isn't might as well not be there, and, were the spec published in the Journal of Irreproducible Results rather than the RFC Series, that likely wouldn't make any difference either. We can only hope that the marketplace deals appropriately with such companies. So, moving on to the other two... Much as we might wish it otherwise, neither the IESG nor even IETF consensus decisions are endowed with either infallibility or perfect foresight. Sometimes the marketplace is going to make decisions, either broadly or in particular areas, that are inconsistent with our preferences and decisions. The broader Internet community knows that and, if we carry looking at a protocol, data structure, crypto method, or something else some or all of us don't like, and saying "nasty, nasty, unapproved" very forcefully when marketplace decision-makers are making other decisions, we hurt the IETF's credibility in a way that no amount of fussing with labels or "statements" of various sorts is going to fix. If we see a particular specification as a significant problem, it may be that the very best thing we can do is to encourage it to be completely and adequately documented and then publish (in the same series) an Applicability Statement that carefully describes why we think it is a bad idea. That may not work either, but it at least has some hope of solving the problme... which more statements that are easily construed as "you shouldn't do this because we said so and we are the all-powerful, all-knowing, and all seeing IETF" is definitely not going to help much. john From nobody Wed Jul 4 10:03:00 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C127F12DD85 for ; Wed, 4 Jul 2018 10:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=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 ppHceRNkieww for ; Wed, 4 Jul 2018 10:02:55 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A69612777C for ; Wed, 4 Jul 2018 10:02:55 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id y203-v6so2121690ywd.9 for ; Wed, 04 Jul 2018 10:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fjs49tOIxfQBxCeNGcxDGWI8eXsok4PQIAOx63TQ/cQ=; b=1YIHYO8XIblBfoKhsoQfXfvJc1FYFMSeat88P3dyG/danbinOVB/BZoJTC1rWROTwy AQLN0mddzT/6n2KBuZ++LJbpddso7wrtbJOw3Mj3WSdaqAzyPFbJ9fQ+beF9xmezmNxg 0BGkWYkIIlwv3M39ShcwclJfI9zdDRyBHCET/6bjaB7Oi8fgRRag/fC8N834I18y2DEJ smDzyq3QC9IP97XYu9Ad/YjPZ4UQRmlbERjDEiShWceCuiecqyZI03YLHI0vZhaR6Zh5 NghmwHVM6xqdjgWSgzzm2KTEPpSOtf4NO0H2mlorcnqIxeI2W7lu4DeKkUKl8k5JK16g QloQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fjs49tOIxfQBxCeNGcxDGWI8eXsok4PQIAOx63TQ/cQ=; b=Ig5m5BEuEfCue5HBLE4ZJ3J2zYnD7gI8P5LVpw5W6whyqAFQMsVkI9Y/IyqPBMF2Sd x8PExo9x2bVwbHgGeZW5xrrR0CPp12/hVwhE2IdRHIRxw7xoEc5s3CPIQMqDHgE8SEXZ HPzaMlNGzK6dF+iFia5K9BIXA5RQwsgbr3DELVXc1lcPhMVQeYAddDF8lizjgcS66jZY o6bPc9/UnvZvJcuAjcS+Yr9WSRnkt4bn587loityup6mCvfZywSieyp+V4IO7xJJqAfa aAIba2aLR698/3HYWmwuwVf+UdxOO2c0OMJ1eOvX+zueFkgfULQOH2tHEMnBTAQcxV6C 3F9A== X-Gm-Message-State: APt69E1+XW/tlPlEVVh/zxhYeEInApvlgU8AtkAbq9dCprJJb+4qswgE qVWrC6C34SwJzINCbzNXxWg4dkUx33ncWz8yZ3r8mus2foY= X-Google-Smtp-Source: AAOMgpczixpzqA6jlyUX86gtgDqwHeAcu79NYE56I6ytW6tCOafTAoljyZ7kNaNaxxDRctUFDxlXx3WCva+sXB/I2nY= X-Received: by 2002:a0d:f286:: with SMTP id b128-v6mr1293428ywf.489.1530723774205; Wed, 04 Jul 2018 10:02:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 10:02:13 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 4 Jul 2018 10:02:13 -0700 Message-ID: To: Eliot Lear Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000cf95b205702f6680" Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 17:02:58 -0000 --000000000000cf95b205702f6680 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 4, 2018 at 6:22 AM, Eliot Lear wrote: > Hi Eric, > On 04.07.18 14:52, Eric Rescorla wrote: > > > > On Wed, Jul 4, 2018 at 1:10 AM, Eliot Lear org> wrote: > >> So do encryption algorithms. WRT what EKR said, it seems better to >> have the algorithm documented than not, if it is being used. The test: is >> it really being used? >> > > I want to narrow my response to this point: what we've done in TLS is > allow code point registration with any stable reference, internal or > external. This includes an I-D. We didn't make this change primarily in > order to address the issues raised by this BOF, but I do think it was a > good change. Can you explain why you don't think that this suffices? > > I wasn't really thinking in terms of code points when I wrote that, but > since you asked: "Any stable reference" sounds fine. Journal references in > the face of scribd and DOIs are pretty cool these days. A nit: we don't > normally count I-Ds in that group, and the boiler plate explains why: > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > > They are not intended to be stable references. One way we know this to be > the case is that they may not be normatively referenced, and most notably, > they're supposed to expire, and can be rev'd leading to some amount of > confusion if you then don't do another code point assignment. > I am aware of this boilerplate, but I don't think it comports well with the way we actually handle IDs, which is that they stick around on the IETF site forever. Remember, the only purpose here is that when you see the code point on the Internet, you know what it means. As for the reving issue, that's addressed by referring to a specific version. I would note that https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ encodes this practice and it's currently in the RFC-Ed queue, so if you object, you ought to do it soon. > What I was thinking about: I'm not sure that this is just about a code > point reference. It's also about providing access to information by which > others can assess the value of the algorithm. Yes, there are other venues, > but as you yourself pointed out, there really hasn't been any harm in > having the algorithm published as an RFC: > > > It does seem to me that for >> national algorithms, they will be in the libraries anyway because >> they will be mandatory procurement requirements. > > > That's certainly an understandable prediction, but I haven't found it to > be true in practice. > > > Not a great demonstration of brand dilution, right? > Well, maybe. We got requests to implement these, and the fact that they were RFCs and in some cases standards track RFCs was, IIRC, used as an argument. However, we also felt we could say "no". However, I've also seen algorithms in libraries (including NSS) mostly because someone decided to do as much as was in some set of RFCs, so practices differ, even within projects. -Ekr --000000000000cf95b205702f6680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 4, 2018 at 6:22 AM, Eliot Lear <lear@cisco.com>= wrote:
=20 =20 =20

Hi Eric,

On 04.07.18 = 14:52, Eric Rescorla wrote:
=20
I wasn't really thinking in terms of code points when I wrote that, but since you asked: "Any stable reference" sounds fine.=C2= =A0 Journal references in the face of scribd and DOIs are pretty cool these days.=C2=A0=C2=A0 A nit: we don't normally count I-Ds in that group= , and the boiler plate explains why:

=C2=A0=C2=A0 Internet-Drafts are draft docume= nts valid for a maximum of six months
=C2=A0=C2=A0 and may be updated, replaced, or obsoleted by other docu= ments at any
=C2=A0=C2=A0 time.=C2=A0 It is inappropriate to use Internet-Drafts a= s reference
=C2=A0=C2=A0 material or to cite them other than as "work in pro= gress."

They are not intended to be stable references.=C2=A0 One way we know th= is to be the case is that they may not be normatively referenced, and most notably, they're supposed to expire, and can be rev'd lead= ing to some amount of confusion if you then don't do another code point assignment.


I would no= te that https://datatracker.ietf.org/doc/draft-ietf-tls-iana-regist= ry-updates/ encodes this practice and it's currently in the RFC-Ed = queue, so if you object, you ought to do it soon.


What I was thinking about: I'm not sure that this is just about a code point reference.=C2=A0 It's also about providing access to information by which others can assess the value of the algorithm.=C2= =A0 Yes, there are other venues, but as you yourself pointed out, there really hasn't been any harm in having the algorithm published as an RFC:

It does seem to me that for
national algorithms, they will be in the libraries anyway because
they will be mandatory procurement requirements.

That's certainly an understandable prediction, but I haven't = found it to be true in practice.

Not a great demonstration of brand dilution, right?
=

Well, maybe. We got requests to implement these, and th= e fact that they were RFCs and in some cases standards track RFCs was, IIRC= , used as an argument. However, we also felt we could say "no". H= owever, I've also seen algorithms in libraries (including NSS) mostly b= ecause someone decided to do as much as was in some set of RFCs, so practic= es differ, even within projects.

-Ekr

--000000000000cf95b205702f6680-- From nobody Wed Jul 4 10:33:00 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7AF130E6D for ; Wed, 4 Jul 2018 10:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuYoDEEPR8Eh for ; Wed, 4 Jul 2018 10:32:56 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECEC413104B for ; Wed, 4 Jul 2018 10:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8829; q=dns/txt; s=iport; t=1530725576; x=1531935176; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=NIKxO/4L7ZHF9I0zUoejm4TrXZZbsgV0VgO5MKg7sJU=; b=BXEHROvqUBlDW9wsxbIppUZvsHn8NOqQv4ELcRmOnbGpIbLei1pKBGo5 d6YOWQxDcFaFJ029PGbZu/9+yrh3BKGCokkcUEZNHYP/TiTnRM4/+YOWR 3Spw5qdSB+gjMlo5TZdMD7LKjqXd6EM0i6b1TbGzuUiHbIK7rM03tutyj A=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAQBvAz1b/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYQrbRKEIohjjV2QH4cICAMjhEkCgkU3FQECAQECAQECbRwMhTY?= =?us-ascii?q?BAQEDASNWEAsOCioCAlcGDQgBAYMcAYF3CA+oTIIcH4gwgSsKBYsCgQ8ngmi?= =?us-ascii?q?DGAIDAYRdglUCmUwJg1qBWFSJFAaIEoVFijWHVIFXIoFSMxoIGxWDJYIjF4h?= =?us-ascii?q?ZhUA9QZFUAQE?= X-IronPort-AV: E=Sophos;i="5.51,306,1526342400"; d="asc'?scan'208,217";a="4969514" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2018 17:32:53 +0000 Received: from [10.61.96.59] (dhcp-10-61-96-59.cisco.com [10.61.96.59]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w64HWrBW032402; Wed, 4 Jul 2018 17:32:53 GMT To: Eric Rescorla Cc: rfcplusplus@ietf.org References: From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <2c8871ae-f4c4-40bd-296a-f52b4adbe385@cisco.com> Date: Wed, 4 Jul 2018 19:32:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eHW5IOJfw8XWQJ8GYhfKdoXFcTuk9UO2y" Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 17:32:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eHW5IOJfw8XWQJ8GYhfKdoXFcTuk9UO2y Content-Type: multipart/mixed; boundary="WlTTU8wt5vIymlWDeg2OBaWHd6942MJXy"; protected-headers="v1" From: Eliot Lear To: Eric Rescorla Cc: rfcplusplus@ietf.org Message-ID: <2c8871ae-f4c4-40bd-296a-f52b4adbe385@cisco.com> Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications References: In-Reply-To: --WlTTU8wt5vIymlWDeg2OBaWHd6942MJXy Content-Type: multipart/alternative; boundary="------------8DE658AA1685E0672B00A644" Content-Language: en-US This is a multi-part message in MIME format. --------------8DE658AA1685E0672B00A644 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi EKR, On 04.07.18 19:02, Eric Rescorla wrote: > > I would note that > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ > encodes this practice and it's currently in the RFC-Ed queue, so if > you object, you ought to do it soon. > That seems a bit late.=C2=A0 If ALL you're saying in that document is, =E2=80=9Cspecification required=E2=80=9D, no reason to stall that draft i= f it's in the RFC Editor queue.=C2=A0 Still, I don't think Internet Drafts are what the authors of 8126 had in mind when they wrote that text, and it would raise a concern about what the registry would look like with such multiple entries, and how interoperability would be affected.=C2=A0 A nice attribute of an RFC is t= hat it denotes at least a clear stop of specification development, and that's not nothing.=C2=A0 This having been said, that would presumably al= so be true of any other labeled thing we are talking about here (I hope). > > What I was thinking about: I'm not sure that this is just about a > code point reference.=C2=A0 It's also about providing access to > information by which others can assess the value of the > algorithm.=C2=A0 Yes, there are other venues, but as you yourself > pointed out, there really hasn't been any harm in having the > algorithm published as an RFC: >> >> It does seem to me that for >> national algorithms, they will be in the libraries anyway beca= use >> they will be mandatory procurement requirements.=20 >> >> >> That's certainly an understandable prediction, but I haven't >> found it to be true in practice. > > Not a great demonstration of brand dilution, right? > > > Well, maybe. We got requests to implement these, and the fact that > they were RFCs and in some cases standards track RFCs was, IIRC, used > as an argument. However, we also felt we could say "no". However, I've > also seen algorithms in libraries (including NSS) mostly because > someone decided to do as much as was in some set of RFCs, so practices > differ, even within projects. You guys may be in a good position to say no.=C2=A0 I could EASILY imagin= e (remember?) others who weren't in so good a position. Eliot --------------8DE658AA1685E0672B00A644 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi EKR,


On 04.07.18 19:02, Eric Rescorla wrote= :

I would note that https://datatracker.ietf.org/doc= /draft-ietf-tls-iana-registry-updates/ encodes this practice and it's currently in the RFC-Ed queue, so if you object, you ought to do it soon.


That seems a bit late.=C2=A0 If ALL you're saying in that document is= , =E2=80=9Cspecification required=E2=80=9D, no reason to stall that dra= ft if it's in the RFC Editor queue.=C2=A0

Still, I don't think Internet Drafts are what the authors of 8126 had in mind when they wrote that text, and it would raise a concern about what the registry would look like with such multiple entries, and how interoperability would be affected.=C2=A0 A nice attribute of= an RFC is that it denotes at least a clear stop of specification development, and that's not nothing.=C2=A0 This having been said, tha= t would presumably also be true of any other labeled thing we are talking about here (I hope).



What I was thinking about: I'm not sure that this is just about a code point reference.=C2=A0 It's also about providing access to information by which others can assess the value of the algorithm.=C2=A0 Yes, there are o= ther venues, but as you yourself pointed out, there really hasn't been any harm in having the algorithm published as an RFC:

It does seem to me that for
national algorithms, they will be in the libraries anyway because
they will be mandatory procurement requirements.

That's certainly an understandable prediction, but I haven't found it to be true in practice.

Not a great demonstration of brand dilution, right?

Well, maybe. We got requests to implement these, and the fact that they were RFCs and in some cases standards track RFCs was, IIRC, used as an argument. However, we also felt we could say "no". However, I've also seen algorithms in libraries (including NSS) mostly because someone decided to do as much as was in some set of RFCs, so practices differ, even within projects.

You guys may be in a good position to say no.=C2=A0 I could EASILY imagine (remember?) others who weren't in so good a position.

Eliot
--------------8DE658AA1685E0672B00A644-- --WlTTU8wt5vIymlWDeg2OBaWHd6942MJXy-- --eHW5IOJfw8XWQJ8GYhfKdoXFcTuk9UO2y Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAls9BMUACgkQh7ZrRtnS ejPvnAf8CjmPN/hc7QdqwRcqanVNQlNjjTEphEq5JUGOSWX4zqIfqHftUbMP8Vmb TnGvj8uL2PrcLl6h3418JstHOIcLkOZi9CmO8/P3ePEWdY4tc36GtYm/nknlVlSX RjMxkDvUTRDwlpdvLNF0c512Go7a8FWtVILMaw6g3mBA6rLYvDKY8epeRtwv6B0Z TcJnb4lDivr6EjrhcD0V7ZF+Qgand0oc09tAafdpPtXuJN5isWUkjla+j0BDcuqs 65KVgeZytASMnM0vuTKHHD8F+VuieJMD9ylCBRE2Ogs/tFYDQrmsZhTgQMLzS1fU yoWNK8BjmHYSXQWS1Xhui4Tycenx1w== =yIzB -----END PGP SIGNATURE----- --eHW5IOJfw8XWQJ8GYhfKdoXFcTuk9UO2y-- From nobody Wed Jul 4 10:37:14 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66875131055 for ; Wed, 4 Jul 2018 10:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIxhkvSL0R24 for ; Wed, 4 Jul 2018 10:37:10 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377A6130E6D for ; Wed, 4 Jul 2018 10:37:10 -0700 (PDT) X-AuditID: 1209190c-5e1ff70000003bbf-4e-5b3d05c46d81 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id AE.83.15295.5C50D3B5; Wed, 4 Jul 2018 13:37:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w64Hb7YR009987; Wed, 4 Jul 2018 13:37:07 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w64Hb3Bm022074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jul 2018 13:37:06 -0400 Date: Wed, 4 Jul 2018 12:37:03 -0500 From: Benjamin Kaduk To: Eliot Lear Cc: Eric Rescorla , rfcplusplus@ietf.org Message-ID: <20180704173703.GJ60996@kduck.kaduk.org> References: <2c8871ae-f4c4-40bd-296a-f52b4adbe385@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2c8871ae-f4c4-40bd-296a-f52b4adbe385@cisco.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixCmqrHuU1Tba4PcZLosVr8+xW5x4vZzF 4uX2OgdmjxPLrrB6LFnyk8lj8uM25gDmKC6blNSczLLUIn27BK6Mn30PWQtucVQ8ebSVuYGx k72LkZNDQsBE4uTKb4xdjFwcQgKLmSS2LN3IDJIQEtjAKNH1qA4icYVJYv2uO2AdLAIqEmc2 bgWz2YDshu7LYA0iAgYS/Uc7wOLMAmYSv+5eZgOxhQWcJNpu3GIEsXmBtn34dJoVYugGJomW N+vZIBKCEidnPmGBaFaX+DPvEtBQDiBbWmL5Pw6IsLxE89bZYLs4BWwleg9+ZgKxRQWUJfb2 HWKfwCg4C8mkWUgmzUKYNAvJpAWMLKsYZVNyq3RzEzNzilOTdYuTE/PyUot0DfVyM0v0UlNK NzGCA12SZwfjmTdehxgFOBiVeHgNztlEC7EmlhVX5h5ilORgUhLlld9oHS3El5SfUpmRWJwR X1Sak1p8iFGCg1lJhFfzF1A5b0piZVVqUT5MSpqDRUmcN3sRY7SQQHpiSWp2ampBahFMVoaD Q0mCdz+LbbSQYFFqempFWmZOCUKaiYMTZDgP0PArIDW8xQWJucWZ6RD5U4yWHC8W9Uxi5ui5 NwVI/nk/dRKzEEtefl6qlDhvJUiDAEhDRmke3ExQ4pLI3l/zilEc6EVh3ocgVTzApAc39RXQ QiaghT3bLEEWliQipKQaGPOvNdw+skzj2P1zy0+eU9Tkck8puCtmstLR6OQXB/ub4su0f1zn ap3Yu23Cj6ec266a7HfMyxLM90y6/7J0zi7+f6xrHgSaq+WtP3I7kks/Zr+3oHruRsu1L9Q6 yh7s9VzqVv586ytGZ8WcY3HLBDJWPcyMypmhemm2fNHNRR1iIZXLP7w+u0GJpTgj0VCLuag4 EQCNj+u9NwMAAA== Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 17:37:13 -0000 On Wed, Jul 04, 2018 at 07:32:53PM +0200, Eliot Lear wrote: > Hi EKR, > > > On 04.07.18 19:02, Eric Rescorla wrote: > > > > I would note that > > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ > > encodes this practice and it's currently in the RFC-Ed queue, so if > > you object, you ought to do it soon. > > > > That seems a bit late.  If ALL you're saying in that document is, > “specification requiredâ€, no reason to stall that draft if it's in the > RFC Editor queue.  Currently live at https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml : Note The role of the designated expert is described in [RFC-ietf-tls-iana-registry-updates-05]. The designated expert [RFC8126] ensures that the specification is publicly available. An Internet Draft that is posted and never published or a standard in another standards body, industry consortium, university site, etc. suffices. The expert may provide more in depth reviews, but their approval should not be taken as an endorsement of the extension. -Ben From nobody Wed Jul 4 11:50:51 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7286130E50 for ; Wed, 4 Jul 2018 11:50:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuuyHFhBWvt5 for ; Wed, 4 Jul 2018 11:50:48 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F83130E30 for ; Wed, 4 Jul 2018 11:50:48 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1famrT-000KLr-Vg; Wed, 04 Jul 2018 14:50:43 -0400 Date: Wed, 04 Jul 2018 14:50:36 -0400 From: John C Klensin To: Benjamin Kaduk cc: Eliot Lear , Eric Rescorla , rfcplusplus@ietf.org Message-ID: In-Reply-To: <20180704173703.GJ60996@kduck.kaduk.org> References: <2c8871ae-f4c4-40bd-296a-f52b4adbe385@cisco.com> <20180704173703.GJ60996@kduck.kaduk.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 18:50:50 -0000 --On Wednesday, July 4, 2018 12:37 -0500 Benjamin Kaduk wrote: > On Wed, Jul 04, 2018 at 07:32:53PM +0200, Eliot Lear wrote: >> Hi EKR, >>=20 >>=20 >> On 04.07.18 19:02, Eric Rescorla wrote: >> >=20 >> > I would note that >> > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-regist >> > ry-updates/ encodes this practice and it's currently in the >> > RFC-Ed queue, so if you object, you ought to do it soon. >> >=20 >>=20 >> That seems a bit late.=C2=A0 If ALL you're saying in that >> document is, "specification required", no reason to stall >> that draft if it's in the RFC Editor queue.=C2=A0 >=20 > Currently live at > https://www.iana.org/assignments/tls-extensiontype-values/tls- > extensiontype-values.xhtml : >=20 > Note > The role of the designated expert is described in=20 > [RFC-ietf-tls-iana-registry-updates-05]. The designated expert = > [RFC8126] ensures that the specification is publicly > available. An Internet Draft that is posted and never > published or a standard in another standards body, industry > consortium, university site, etc. suffices. The expert may > provide more in depth reviews, but their approval should not > be taken as an endorsement of the extension. =20 Ben, The state of TLS may be that the above is entirely reasonable and I certainly would not try to second-guess it. As a principle, when special circumstances exist, I think the IETF is better off making sensible judgments that are specific to those circumstances rather than consulting a one-size-fits-all rule book. However, for most cases, I think most of our references should be not only publicly available but also stable and, with a nod in the direction of those who are concerned about Internet history, archival -- likely to be available and readable/ accessible for a very long time, even when the related protocols or parameters have fallen into disuse. I-Ds do not have those properties. They can be updated at any time, creating some ambiguity about whether the citation is intended to be to the most current version (appropriate if the updates are clarifications) or to the one at the time the registry entry was created (possibly appropriate if there were substantive changes). While the IETF has decided to keep older I-Ds accessible to the public rather than making them inaccessible without special measures right after they expired, we have had problems with bad links when the various web pages are rearranged and there are no guarantees that the IETF will be around forever and what will happen if it ceases being able to support those archives. So, again, if references to anything that is publicly available at the time of registration is what the TLS community and the IESG are convinced TLS needs, go for it. But let's be careful about moving more generally in that direction. john p.s. If we are going to treat I-Ds as appropriate for stable and archival references, we should probably be reviewing whether we actually need the RFC Series and why (at least for more than a source of labels and serial numbers). I think the answer after a careful examination would still be "yes", but going through the exercise might allow us to focus on what we think is necessary and thereby save some procedures and money. From nobody Wed Jul 4 12:16:50 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4E0130DCD for ; Wed, 4 Jul 2018 12:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=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 5siidG2ZIg4n for ; Wed, 4 Jul 2018 12:16:44 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6646612F1A2 for ; Wed, 4 Jul 2018 12:16:44 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id s1-v6so2403880ybk.3 for ; Wed, 04 Jul 2018 12:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d+eMbgG/9XALaLOgo9PJ9tGskrOzmGhdr6NLSH1N1R8=; b=dkwhLXbiBws2adjyZz8fgA4tJCMk7ZlKOuI2K962J28+1X4IfTDDw+5vzUklPpKxe0 GX/TUC6103OCeKDYrPi9CYyIcarq9D414/QNe0iyhXA2PjGXk8Atdnd0vAO7lSqhElzK 4hsAySSEDoXeMhfQXYfEpHw/SvwTMv9JPndkM6d2CB9wabj7dSBwLtZFqcgKRcAGNdHq 7D1gV4s40tteKtCKQhu7dHyxTJAm45MeBiowMcaqhEMsvxqXQKyChBuxSS2zRPxPwnZ+ 5dfBSlSRI44BwyCCVVCzUn3daj8qXmj+C9eqxmhZNfSoGJhwcOYfQU0GeKGDrnsgu9Zr Gp9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d+eMbgG/9XALaLOgo9PJ9tGskrOzmGhdr6NLSH1N1R8=; b=qv6kE+3DsTe+WvuPezdnJOYz5FpSO3RO4YqXgV+bDj8Pw7sgPTiG7ccNeQne6EjbW8 8ukXJfPnEkqf7RrFzrNolRMYl4+Xxr8yawv4eKRTTM796HbQnkJ69marDkzdKC0kXLLF B+Lueu6eD5BGpU4hep0+8rR5QVd5z8t948ESn9H+TA0aPrnQBZbDakOVQi/iKBMO3VbH N+N+24/8Xb8SJbcXf8RNRptK2BZGqpLfrwNhQc7QLemtIy6CIU3If5bKm8RWn4a07KtN AkpeVpe+VKvOnuYm7m+O6TxKelbTWh1/x+IJforPgacTJRiqS+W0IwhpNThbH9+77M7l ADPg== X-Gm-Message-State: APt69E2M/R2WWoHvNMOaRN51q+piOcOZrDHG+CoGHeuQpgiD5Ux+e0DT jcv7LWXpV2phVCPTGk4wDfObNvQa1TV/dWu/VWT2tA== X-Google-Smtp-Source: AAOMgpeDDW7lcWyKBE62se7ygwdQ0n5GUDj7A8TVKgLA8FCxoTFKM/O0NYdfHyiOf2exMeOTyaGh46Wmt+9Qs4AlHYk= X-Received: by 2002:a25:acd0:: with SMTP id x16-v6mr1773305ybd.407.1530731803587; Wed, 04 Jul 2018 12:16:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 12:16:03 -0700 (PDT) In-Reply-To: References: <2c8871ae-f4c4-40bd-296a-f52b4adbe385@cisco.com> <20180704173703.GJ60996@kduck.kaduk.org> From: Eric Rescorla Date: Wed, 4 Jul 2018 12:16:03 -0700 Message-ID: To: John C Klensin Cc: Benjamin Kaduk , Eliot Lear , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000006647f0057031450e" Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 19:16:49 -0000 --0000000000006647f0057031450e Content-Type: text/plain; charset="UTF-8" Hi John, I think you're onto something important here: in the nearly 40 years since the RFC series began, the economics of publishing stuff have changed pretty radically. In particular, it's become far cheaper to publish documents which: - Are widely available - Have a reasonable story about ongoing availability - Are referentially stable; specifically, if the document is available in the future, you can be sure that you have the right document [0]. At the same time, it hasn't gotten much cheaper to produce documents which have multistakeholder consensus (I assume some would argue it has gotten more expensive, but I think we can all agree it hasn't gotten cheaper at the rate that publishing has). So, I still think there is real value in having a mechanism for ensuring that documents have that level of review and consensus (leaving aside how that mechanism works, though I'd be happy to get into that in a separate note). Narrowing this to the question of code point registration: Many protocols have large code point spaces so there's no need to restrict code point assignments in order to conserve space. In at least some of these protocols, we've come to the conclusion that restricting code point assignment in order to prevent people from making ill-advised extensions doesn't work well (people just squat and you get a mess). We could deal with this by just allowing registrations to be FCFS, but there was a general feeling that it wasn't great to have code points exist with no way for people to know what they meant, so we concluded that there ought to be some reference to a document describing the meaning of the extension, and that one ought to be able to have a good chance of finding the document. I take this to be the spirit of RFC 8126 specification required. Specifically: The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path, including informal documentation. I think it's clear that this definition would encompass a link to a blog or a github repository ("informal publication") as long as that was referentially stable. I agree that that the text we use to describe I-Ds suggests that these properties don't apply to I-Ds, but I would submit that as a practical matter, I-Ds (as long as they are referenced by version) do have these properties at least as much as a blog entry or Github link does. It's for that reason that we opted to allow this in TLS (and, I expect, in other groups going forward). >From your email, I take it that you don't think this is generally a good idea. Can you explain a bit more why in light of the comments above? -Ekr [0] It's also much easier to publish documents which are referentially unstable in the sense that you get the most up-to-date version, which is a source of confusion. On Wed, Jul 4, 2018 at 11:50 AM, John C Klensin wrote: > > > --On Wednesday, July 4, 2018 12:37 -0500 Benjamin Kaduk > wrote: > > > On Wed, Jul 04, 2018 at 07:32:53PM +0200, Eliot Lear wrote: > >> Hi EKR, > >> > >> > >> On 04.07.18 19:02, Eric Rescorla wrote: > >> > > >> > I would note that > >> > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-regist > >> > ry-updates/ encodes this practice and it's currently in the > >> > RFC-Ed queue, so if you object, you ought to do it soon. > >> > > >> > >> That seems a bit late. If ALL you're saying in that > >> document is, "specification required", no reason to stall > >> that draft if it's in the RFC Editor queue. > > > > Currently live at > > https://www.iana.org/assignments/tls-extensiontype-values/tls- > > extensiontype-values.xhtml : > > > > Note > > The role of the designated expert is described in > > [RFC-ietf-tls-iana-registry-updates-05]. The designated expert > > [RFC8126] ensures that the specification is publicly > > available. An Internet Draft that is posted and never > > published or a standard in another standards body, industry > > consortium, university site, etc. suffices. The expert may > > provide more in depth reviews, but their approval should not > > be taken as an endorsement of the extension. > > Ben, > > The state of TLS may be that the above is entirely reasonable > and I certainly would not try to second-guess it. As a > principle, when special circumstances exist, I think the IETF is > better off making sensible judgments that are specific to those > circumstances rather than consulting a one-size-fits-all rule > book. > > However, for most cases, I think most of our references should > be not only publicly available but also stable and, with a nod > in the direction of those who are concerned about Internet > history, archival -- likely to be available and readable/ > accessible for a very long time, even when the related protocols > or parameters have fallen into disuse. > > I-Ds do not have those properties. They can be updated at any > time, creating some ambiguity about whether the citation is > intended to be to the most current version (appropriate if the > updates are clarifications) or to the one at the time the > registry entry was created (possibly appropriate if there were > substantive changes). While the IETF has decided to keep older > I-Ds accessible to the public rather than making them > inaccessible without special measures right after they expired, > we have had problems with bad links when the various web pages > are rearranged and there are no guarantees that the IETF will be > around forever and what will happen if it ceases being able to > support those archives. > > So, again, if references to anything that is publicly available > at the time of registration is what the TLS community and the > IESG are convinced TLS needs, go for it. But let's be careful > about moving more generally in that direction. > > john > > p.s. If we are going to treat I-Ds as appropriate for stable and > archival references, we should probably be reviewing whether we > actually need the RFC Series and why (at least for more than a > source of labels and serial numbers). I think the answer after > a careful examination would still be "yes", but going through > the exercise might allow us to focus on what we think is > necessary and thereby save some procedures and money. > > > > --0000000000006647f0057031450e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

I think you're onto something importan= t here: in the nearly 40 years
since the RFC series began, the economics= of publishing stuff have
changed pretty radically.

In particular= , it's become far cheaper to publish documents which:

- Are wide= ly available
- Have a reasonable story about ongoing availability
- A= re referentially stable; specifically, if the document is
=C2=A0 availab= le in the future, you can be sure that you have
=C2=A0 the right documen= t [0].

At the same time, it hasn't gotten much cheaper to produc= e documents
which have multistakeholder consensus (I assume some would a= rgue it
has gotten more expensive, but I think we can all agree it hasn&= #39;t
gotten cheaper at the rate that publishing has). So, I still think=
there is real value in having a mechanism for ensuring that
document= s have that level of review and consensus (leaving
aside how that mechan= ism works, though I'd be happy to get into
that in a separate note).=


Narrowing this to the question of code point registration: Many=
protocols have large code point spaces so there's no need to restri= ct
code point assignments in order to conserve space. In at least some o= f
these protocols, we've come to the conclusion that restricting cod= e
point assignment in order to prevent people from making ill-advisedextensions doesn't work well (people just squat and you get a mess).
We could deal with this by just allowing registrations to be FCFS,but there was a general feeling that it wasn't great to have code
p= oints exist with no way for people to know what they meant, so
we conclu= ded that there ought to be some reference to a document
describing the m= eaning of the extension, and that one ought to be
able to have a good ch= ance of finding the document. I take this
to be the spirit of RFC 8126 s= pecification required. Specifically:

=C2=A0=C2=A0 The intention behi= nd "permanent and readily available" is that a
=C2=A0=C2=A0 do= cument can reasonably be expected to be findable and retrievable
=C2=A0= =C2=A0 long after IANA assignment of the requested value.=C2=A0 Publication= of an
=C2=A0=C2=A0 RFC is an ideal means of achieving this requirement,= but
=C2=A0=C2=A0 Specification Required is intended to also cover the c= ase of a
=C2=A0=C2=A0 document published outside of the RFC path, includ= ing informal
=C2=A0=C2=A0 documentation.

I think it's clear t= hat this definition would encompass a link to
a blog or a github reposit= ory ("informal publication") as long as
that was referentially= stable. I agree that that the text we
use to describe I-Ds suggests tha= t these properties don't apply
to I-Ds, but I would submit that as a= practical matter, I-Ds
(as long as they are referenced by version) do h= ave these properties
at least as much as a blog entry or Github link doe= s. It's for
that reason that we opted to allow this in TLS (and, I e= xpect,
in other groups going forward).

From your email, I take it= that you don't think this is generally
a good idea. Can you explain= a bit more why in light of the comments
above?

-Ekr

[0] I= t's also much easier to publish documents which are referentially
un= stable in the sense that you get the most up-to-date version, which
is a= source of confusion.







On Wed, Jul 4, 2018 at 11:= 50 AM, John C Klensin <john-ietf@jck.com> wrote:


--On Wednesday, July 4, 2018 12:37 -0500 Benjamin Kaduk
<kaduk@mit.edu>= wrote:

> On Wed, Jul 04, 2018 at 07:32:53PM +0200, Eliot Lear wrote:
>> Hi EKR,
>>
>>
>> On 04.07.18 19:02, Eric Rescorla wrote:
>> >
>> > I would note that
>> > https://datatracker.ietf.or= g/doc/draft-ietf-tls-iana-regist
>> > ry-updates/ encodes this practice and it's current= ly in the
>> > RFC-Ed queue, so if you object, you ought to= do it soon.
>> >
>>
>> That seems a bit late.=C2=A0 If ALL you're saying in that
>> document is, "specification required", no reason to stal= l
>> that draft if it's in the RFC Editor queue.=C2=A0
>
> Currently live at
> https://www.iana.org/assignm= ents/tls-extensiontype-values/tls-
> extensiontype-values.xhtml :
>
> Note
> The role of the designated expert is described in
> [RFC-ietf-tls-iana-registry-updates-05]. The designated expert > [RFC8126] ensures that the specification is publicly
> available.=C2=A0 An=C2=A0 Internet Draft that is posted and never
> published or a standard in=C2=A0 another standards body, industry
> consortium, university site, etc.=C2=A0 suffices.=C2=A0 The expert may=
> provide more in depth reviews, but their=C2=A0 approval should not
> be taken as an endorsement of the extension.=C2=A0 =C2=A0

Ben,

The state of TLS may be that the above is entirely reasonable
and I certainly would not try to second-guess it.=C2=A0 =C2=A0 As a
principle, when special circumstances exist, I think the IETF is
better off making sensible judgments that are specific to those
circumstances rather than consulting a one-size-fits-all rule
book.

However, for most cases, I think most of our references should
be not only publicly available but also stable and, with a nod
in the direction of those who are concerned about Internet
history, archival -- likely to be available and readable/
accessible for a very long time, even when the related protocols
or parameters have fallen into disuse.

I-Ds do not have those properties.=C2=A0 They can be updated at any
time, creating some ambiguity about whether the citation is
intended to be to the most current version (appropriate if the
updates are clarifications) or to the one at the time the
registry entry was created (possibly appropriate if there were
substantive changes).=C2=A0 While the IETF has decided to keep older
I-Ds accessible to the public rather than making them
inaccessible without special measures right after they expired,
we have had problems with bad links when the various web pages
are rearranged and there are no guarantees that the IETF will be
around forever and what will happen if it ceases being able to
support those archives.

So, again, if references to anything that is publicly available
at the time of registration is what the TLS community and the
IESG are convinced TLS needs, go for it.=C2=A0 But let's be careful
about moving more generally in that direction.

=C2=A0 =C2=A0john

p.s. If we are going to treat I-Ds as appropriate for stable and
archival references, we should probably be reviewing whether we
actually need the RFC Series and why (at least for more than a
source of labels and serial numbers).=C2=A0 I think the answer after
a careful examination would still be "yes", but going through
the exercise might allow us to focus on what we think is
necessary and thereby save some procedures and money.




--0000000000006647f0057031450e-- From nobody Wed Jul 4 12:31:11 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918B9130DE3 for ; Wed, 4 Jul 2018 12:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m8G2VV7oU8P for ; Wed, 4 Jul 2018 12:31:08 -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 EB071130DCD for ; Wed, 4 Jul 2018 12:31:07 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id w64JV3jS026178; Wed, 4 Jul 2018 20:31:03 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8EC8722048; Wed, 4 Jul 2018 20:31:03 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 717A722042; Wed, 4 Jul 2018 20:31:03 +0100 (BST) Received: from 950129200 (86-120-69-50.rdsnet.ro [86.120.69.50] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id w64JV1qe015431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2018 20:31:02 +0100 Reply-To: From: "Adrian Farrel" To: "'Benjamin Kaduk'" , "'Eliot Lear'" Cc: "'Eric Rescorla'" , References: <2c8871ae-f4c4-40bd-296a-f52b4adbe385@cisco.com> <20180704173703.GJ60996@kduck.kaduk.org> In-Reply-To: <20180704173703.GJ60996@kduck.kaduk.org> Date: Wed, 4 Jul 2018 20:30:58 +0100 Message-ID: <03c401d413cd$89a40c00$9cec2400$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQCltZWAD1jt8JRyeJyxh84BbYvxGwFd22XJAd6+dj0B+ErpzwG5BibuAe227FCmlVII8A== X-Originating-IP: 86.120.69.50 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23948.002 X-TM-AS-Result: No--25.949-10.0-31-10 X-imss-scan-details: No--25.949-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23948.002 X-TMASE-Result: 10--25.949400-10.000000 X-TMASE-MatchedRID: 1GZI+iG+MtfZfnct5UBzcVYH5oZvsyJ4myqQJWNsukkoQueHSn6dgMLm p4jPUF8tAWMdzSV1Iwb2mhGQByUXXuFokojhrXL/JrUxoq6hvw+dpfncOF/0WRHfiujuTbedyE9 OxUqh9b9NqDqh5NJ43uQB9gS0XiouYhdzVnzdRn1wUSK4/EeOxcWmFF22SfTePILl10bYlyAans FgOu2thrcfsuZWVAS3S2Rr+mzYSq/pzoZfJABOupRrnSy7UTtbGW6TfocNCnsfTpbqvC281Uene 5ELSwGvII20fGkZ4zIu7f845UEBB4aMgxBwJcDYqbg9uWhLYLd1k+gP1XamtJsoi2XrUn/JIq95 DjCZh0y93aL9exgp0lZ0V5tYhzdWxEHRux+uk8jpP8tMOyYmaA== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 19:31:10 -0000 Well, I am not that bothered, but it looks like you should have used = "Expert Review" with the strictures and guidance to the Designated = Experts, rather than "Specification Required" with an (implicit) = alteration of 8126 and the I-D boilerplate. > -----Original Message----- > From: Rfcplusplus [mailto:rfcplusplus-bounces@ietf.org] On Behalf Of = Benjamin > Kaduk > Sent: 04 July 2018 18:37 > To: Eliot Lear > Cc: Eric Rescorla; rfcplusplus@ietf.org > Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications >=20 > On Wed, Jul 04, 2018 at 07:32:53PM +0200, Eliot Lear wrote: > > Hi EKR, > > > > > > On 04.07.18 19:02, Eric Rescorla wrote: > > > > > > I would note that > > > = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ > > > encodes this practice and it's currently in the RFC-Ed queue, so = if > > > you object, you ought to do it soon. > > > > > > > That seems a bit late. If ALL you're saying in that document is, > > =E2=80=9Cspecification required=E2=80=9D, no reason to stall that = draft if it's in the > > RFC Editor queue. >=20 > Currently live at > = https://www.iana.org/assignments/tls-extensiontype-values/tls-extensionty= pe- > values.xhtml : >=20 > Note > The role of the designated expert is described in > [RFC-ietf-tls-iana-registry-updates-05]. The designated expert > [RFC8126] ensures that the specification is publicly available. An > Internet Draft that is posted and never published or a standard in > another standards body, industry consortium, university site, etc. > suffices. The expert may provide more in depth reviews, but their > approval should not be taken as an endorsement of the extension. >=20 > -Ben >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Wed Jul 4 21:43:29 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981FC130DE2 for ; Wed, 4 Jul 2018 21:43:27 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 kCfLYkiBBRQL for ; Wed, 4 Jul 2018 21:43:25 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 BA9EF1277CC for ; Wed, 4 Jul 2018 21:43:25 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id b17-v6so4275780pfi.0 for ; Wed, 04 Jul 2018 21:43:25 -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=GFCpelar15SZ95jvo1vbeJgvx7H8sJ9AzWjBuBsL8AY=; b=Lttj3sD+OvKVx1MXzJyu+JCLDgv7ewNkxygryMsq9EC6s0rkavyK2wOIWv2EX9C/Sh faYXjqllWcVD2GyuYRuzc22JY0FNavCHE4gRTPpE04aPJQfD4uFfR7tNkubnc1CnhPJY +udjDgpxAiTW3eyH5/PEnJmnzVSllyNTknqCFHBmiX+mTFDxZAotacBZbHH4ElM4JLGo XDxz221TtXTHFb3te0DUEDgE5yjyDucFnkUDf6MPQID/nv8IC1mYg8NuysL2IcmSgfTP Dg+iLOSsJrSKDU260e4MdzViM7Gn0lkCl0SQkH0i+Z6SwDaRJbZsS52KoUjeuKeDrHdq fclg== 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=GFCpelar15SZ95jvo1vbeJgvx7H8sJ9AzWjBuBsL8AY=; b=JEebN+dWQ20QcKKck6KBNM+nem9SD2aHJnJrw8yl+SklO+wMi1Paedn01hnYkcD7xw tEQyFBSMgMF+SJIcFKJnYQ+Ck6unDzi+xBDPtHV/jZZK/4ADBaF9bhwlirqh3kqhY5Ui EZFhvlw86HqFL14qkImXw4EEwyiMVtWS3ddN0SPmjJ+g9SNQZr2/hQb+schrzKCS2PKs b75ufSaFZ7FETmfjhCOlt1D9oMFfVpREGDqY6gWJRnzRmL5SOAwmtKpraT4B/yfIxqT5 mVIW98ps4Vm+xHQkgB0yj2VyTC9Sv4UEqHq0+RHuFMr0oKxZnhZCsvE0kXHTl/KOxoAs x8aw== X-Gm-Message-State: APt69E2hcFqUOQ3IMVY0HSiQHNMg1NS326HPeJgZSZKdtHek0UPzr9DD 12Lk/K3WsH7zLsLK4bsq+bhbjw== X-Google-Smtp-Source: AAOMgpfWmp7j+wkpFsLmZo5F7t7Eqg21655t7yexiDrCNnLvU0A/3oebd5Gih682sGr57mdA759G6w== X-Received: by 2002:a62:ed13:: with SMTP id u19-v6mr4729857pfh.125.1530765804904; Wed, 04 Jul 2018 21:43:24 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id n22-v6sm7233037pgv.60.2018.07.04.21.43.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 21:43:24 -0700 (PDT) To: John C Klensin , Martin Thomson , mohamed.boucadair@orange.com, Paul Hoffman Cc: rfcplusplus@ietf.org References: <787AE7BB302AE849A7480A190F8B93302DF51569@OPEXCLILMA3.corporate.a droot.infra.ftgroup> From: Brian E Carpenter Message-ID: Date: Thu, 5 Jul 2018 16:43:26 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] things that are not standards [Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 04:43:28 -0000 On 05/07/2018 03:41, John C Klensin wrote: > Martin and Med, > > Let me build a bit on Paul's summary of vendor customer > requirements for things that are not standards. Inline below. > > --On Wednesday, July 4, 2018 06:04 +0000 > mohamed.boucadair@orange.com wrote: > >> Hi Martin, >> >> You said: >> >> === >> RFC 7974 is the best example >> I have of this. It bears a warning nearly that strong and yet >> I have received or witnessed strong endorsements of its >> virtues on several occasions. > > and > > --On Wednesday, July 4, 2018 16:17 +1000 Martin Thomson > wrote: > >> On Wed, Jul 4, 2018 at 4:04 PM >> wrote: >>> * Why not considering the problem from another perspective: >>> wouldn't the "strong endorsements" be a signal to question a >>> note itself? >> >> They could be. You can make that assessment for yourself, but >> the IESG don't make these statements lightly, and I respect >> their conclusions. FWIW, Section 1.2 of that document is >> pretty frank about the purpose of the document, so the >> question of dishonesty clearly doesn't apply, just the >> potential for confusion. > > I respect the IESG's conclusions too and IETF informed consensus > conclusions about the right way to go even more so. > > But, when a vendor decides to require support for some spec that > is not on the standards track (even one the IESG has warned > against in some detail), I think there are three possibilities. > > (i) They have reviewed the spec and concluded it is a good idea > for their purposes, even though the IETF has reached an opposite > conclusion. > > (b) The spec is widely-deployed enough that they have customer > requirements to interoperate with it. > > (c) They are idiots or excessively influenced by aggressive > marketing and have therefore uncritically accepted the > specification probably without reading either it or the notes > attached to it. > > I don't think we can solve the third problem. Different labels > are unlikely to make a difference, disclaimers that are not read > because the document isn't might as well not be there, and, were > the spec published in the Journal of Irreproducible Results > rather than the RFC Series, that likely wouldn't make any > difference either. We can only hope that the marketplace deals > appropriately with such companies. So, moving on to the other > two... > > Much as we might wish it otherwise, neither the IESG nor even > IETF consensus decisions are endowed with either infallibility > or perfect foresight. Sometimes the marketplace is going to > make decisions, either broadly or in particular areas, that are > inconsistent with our preferences and decisions. The broader > Internet community knows that and, if we carry looking at a > protocol, data structure, crypto method, or something else some > or all of us don't like, and saying "nasty, nasty, unapproved" > very forcefully when marketplace decision-makers are making > other decisions, we hurt the IETF's credibility in a way that no > amount of fussing with labels or "statements" of various sorts > is going to fix. There is of course a poster child for exactly that, and in some ways the IETF is lucky to have survived it. I refer to RFC 1597 and RFC 1631. We threw our toys out of the playpen (e.g. RFC 2993) for years, but to no avail. BCP 5 even managed to avoid any reference whatever to address translation. I doubt that the history of NAT would have been much different if those had been INDEP 1597, INDEP 1631 and IAB 2993. Brian > If we see a particular specification as a significant problem, > it may be that the very best thing we can do is to encourage it > to be completely and adequately documented and then publish (in > the same series) an Applicability Statement that carefully > describes why we think it is a bad idea. That may not work > either, but it at least has some hope of solving the problme... > which more statements that are easily construed as "you > shouldn't do this because we said so and we are the > all-powerful, all-knowing, and all seeing IETF" is definitely > not going to help much. > > john > > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > From nobody Wed Jul 4 21:54:54 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADE9130E3A for ; Wed, 4 Jul 2018 21:54:52 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 cmJP1xYe2z9g for ; Wed, 4 Jul 2018 21:54:25 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 49A2F1277CC for ; Wed, 4 Jul 2018 21:54:25 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id j3-v6so4282376pfh.11 for ; Wed, 04 Jul 2018 21:54:25 -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=E416lNDw3Qclw4cP74NmMMeF0yDNgI7ElkgcXcYyMdE=; b=kditUOWXuMLg9zqvkRn5/ZfiQYs6wNtEXmXWaERj7w6YuRnGkiC7JKNR4uxEyrfGLF gihq1/zu7Pbaot2RduT5bqZsXwb8Ja9ZUi80hzLc132qLooxwcMaBw6UDhTsbuMfRC6c PfJnrTuUImafxED25SzcE33mInAh4k6uCnwAlh5OlqwTdoyekNtYWzckczrDompM0N76 /3GJzT5l7b40qpGrAb0hqSAWPWbT8ux3C92y3LwLO4SpviHe9sjFNukzS3qAj5lkW+wL QdPJKUPui8nR4frabmcZ0O4vSILzuthALdh+gfxj4WzukTGIZ4huNuLFRcZ7AtpTAvRq g7vg== 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=E416lNDw3Qclw4cP74NmMMeF0yDNgI7ElkgcXcYyMdE=; b=Tyd05fY92hfGcHlodSj+LIoD8FrEwEARwpG7zmnJi+iAScRXsn2eIKzcO9oe8KRnMB i8kyE2XJd67B8I7HWxbItPaQ08bx2njVLeKscaDoBUGmGyCs595vLgCWf857j06DdqEw zXYuSLPz/YYM+dA3EvQHSLwEXSDMhX4xrt7aO8pohgKrPS6Cgm3A/WEycbpvxhR5g2pz 4HMpBJZ/Tg1TzlmDvhyrh369C3Bza1wN6bzcfFb16HYpUSYET6d9zJM9a77T+TnsSel7 nfH+LhHzO5wvafQ9CtiQeJ/FL+/PVJFU7s8OcFktjsUkuTHsjLhg4fceS+KrZQ02Z6JK +E0A== X-Gm-Message-State: APt69E2kW5kMZJhNhKGDMJIYWkinaRH9BW1HuwFlWBWH4ezp0I7a+Ev4 kJ8KO1z22p8l0E5wiX9zh2NbsQ== X-Google-Smtp-Source: AAOMgpcfzwuiS3eiFg9WV1CuU1nDT9XAn4SbbnjTadgHH5aa/ePFpxsqcSd8eku2wTGNC9rANv8Scg== X-Received: by 2002:a65:44c3:: with SMTP id g3-v6mr4124800pgs.231.1530766464620; Wed, 04 Jul 2018 21:54:24 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id t78-v6sm10170238pfa.160.2018.07.04.21.54.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 21:54:23 -0700 (PDT) To: rfcplusplus@ietf.org References: <2c8871ae-f4c4-40bd-296a-f52b4adbe385@cisco.com> <20180704173703.GJ60996@kduck.kaduk.org> <03c401d413cd$89a40c00$9cec2400$@olddog.co.uk> From: Brian E Carpenter Message-ID: Date: Thu, 5 Jul 2018 16:54:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <03c401d413cd$89a40c00$9cec2400$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 04:54:53 -0000 Adrian, IMHO that's for the TLS WG to decide and the IESG (and IANA) to agree to.= If the result is somewhat fewer Independent Submissions, that seems like a win-win in the end (and somewhat irrelevant to the BOF topic). Brian On 05/07/2018 07:30, Adrian Farrel wrote: > Well, I am not that bothered, but it looks like you should have used "E= xpert Review" with the strictures and guidance to the Designated Experts,= rather than "Specification Required" with an (implicit) alteration of 81= 26 and the I-D boilerplate. >=20 >> -----Original Message----- >> From: Rfcplusplus [mailto:rfcplusplus-bounces@ietf.org] On Behalf Of B= enjamin >> Kaduk >> Sent: 04 July 2018 18:37 >> To: Eliot Lear >> Cc: Eric Rescorla; rfcplusplus@ietf.org >> Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications >> >> On Wed, Jul 04, 2018 at 07:32:53PM +0200, Eliot Lear wrote: >>> Hi EKR, >>> >>> >>> On 04.07.18 19:02, Eric Rescorla wrote: >>>> >>>> I would note that >>>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-update= s/ >>>> encodes this practice and it's currently in the RFC-Ed queue, so if >>>> you object, you ought to do it soon. >>>> >>> >>> That seems a bit late. If ALL you're saying in that document is, >>> =E2=80=9Cspecification required=E2=80=9D, no reason to stall that dra= ft if it's in the >>> RFC Editor queue. >> >> Currently live at >> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensio= ntype- >> values.xhtml : >> >> Note >> The role of the designated expert is described in >> [RFC-ietf-tls-iana-registry-updates-05]. The designated expert >> [RFC8126] ensures that the specification is publicly available. An >> Internet Draft that is posted and never published or a standard in >> another standards body, industry consortium, university site, etc. >> suffices. The expert may provide more in depth reviews, but their >> approval should not be taken as an endorsement of the extension. >> >> -Ben >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 From nobody Wed Jul 4 21:56:42 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D16130DD0 for ; Wed, 4 Jul 2018 21:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 kB4XEEmpjscG for ; Wed, 4 Jul 2018 21:56:39 -0700 (PDT) Received: from mail-yb0-x241.google.com (mail-yb0-x241.google.com [IPv6:2607:f8b0:4002:c09::241]) (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 12E661277CC for ; Wed, 4 Jul 2018 21:56:39 -0700 (PDT) Received: by mail-yb0-x241.google.com with SMTP id x10-v6so2744757ybl.10 for ; Wed, 04 Jul 2018 21:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x36k6lgn1Q1UpixNBIaStd0t3zNBcxSbF25Aoz4xe+o=; b=Bcxs4mOpw/O45c/uGl5s2pBlmgCu4ZvzhwdDtAKK7XUpVF2hmd1rUUuMkB29xRwCio xQlNb2wy2D8OweEdHmpTmX5cyfFCuGrcW6qc8ZfWkOz70pWxtwximuN9yRFK3lpjz2fT uh21K2W8nvKphQSBttZMDiWLPJUebiQMmxzlqg7P+F8GxJdKauY6GIlM7wH2sf2p4TdJ 4eUEIZkAQLcx24DjvaeNuRrwZV3wrpWYBiT/w0VrtS6z7EqNtTlObhc1KHhfyG0sqPw8 TRWiwPEh+NWtN3e7d6PDD3yzW1yotolS0LitDo14HnnaGdQrLhgoh08yhtrsXJOsu0no 4BuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x36k6lgn1Q1UpixNBIaStd0t3zNBcxSbF25Aoz4xe+o=; b=UjzdBBSkN8npAkubK9f2bej/wvM5EMHSwBZRfCv4UwLrgylTv2fYuykqE/Z8cqYE7p f9IBVWyO0+Kyma/myXAHYYrq/wZ6Xq0S1RakZ4huAjX5H4PgL1iUI0UYO6wFFaVlg+EP wCY8yHoUhmQa9HXnz+fqqMJTOvp3/TDjQYPlxMJRPbjReFXYQPr5+nEAngsqEcIKBZ/+ wRfG7lZWGGH6immZRWUlTS70GUJis9guFay8L51QL8eQL34ZHrpknRkv7pat0NxfEM6W A90sxf7Bf5U/f/2gPscRa+OhTWex5BJqqmDnTAEpIijpXc43S9tQ/jkoSBmqzUc2CHhA NHxw== X-Gm-Message-State: APt69E1WZC+1MMFPy+L4LJ1WsK0PFC3ghYjedrSBRxXACzFXoWiYj/ZL sPTWyRTyJ08xF5k1yMCi2YeU3QBf2CqNCDCvFy8Msg== X-Google-Smtp-Source: AAOMgpeEcms6y8yiA+jO5di4wH5UppUfp5WORKyWpQl5cLN9R3j42CnkfOTHXpfu1SyQqYw3G/iJuOc+MKrjCHtZe34= X-Received: by 2002:a25:acd0:: with SMTP id x16-v6mr2445413ybd.407.1530766598267; Wed, 04 Jul 2018 21:56:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 21:55:57 -0700 (PDT) In-Reply-To: References: <2c8871ae-f4c4-40bd-296a-f52b4adbe385@cisco.com> <20180704173703.GJ60996@kduck.kaduk.org> <03c401d413cd$89a40c00$9cec2400$@olddog.co.uk> From: Eric Rescorla Date: Wed, 4 Jul 2018 21:55:57 -0700 Message-ID: To: Brian E Carpenter Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000005304da0570395f53" Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 04:56:41 -0000 --0000000000005304da0570395f53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, I wouldn't have objected to Expert Review here. I just didn't object to Spec Required :) -Ekr On Wed, Jul 4, 2018 at 9:54 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Adrian, > > IMHO that's for the TLS WG to decide and the IESG (and IANA) to agree to. > If the result is somewhat fewer Independent Submissions, that seems > like a win-win in the end (and somewhat irrelevant to the BOF topic). > > Brian > > On 05/07/2018 07:30, Adrian Farrel wrote: > > Well, I am not that bothered, but it looks like you should have used > "Expert Review" with the strictures and guidance to the Designated Expert= s, > rather than "Specification Required" with an (implicit) alteration of 812= 6 > and the I-D boilerplate. > > > >> -----Original Message----- > >> From: Rfcplusplus [mailto:rfcplusplus-bounces@ietf.org] On Behalf Of > Benjamin > >> Kaduk > >> Sent: 04 July 2018 18:37 > >> To: Eliot Lear > >> Cc: Eric Rescorla; rfcplusplus@ietf.org > >> Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications > >> > >> On Wed, Jul 04, 2018 at 07:32:53PM +0200, Eliot Lear wrote: > >>> Hi EKR, > >>> > >>> > >>> On 04.07.18 19:02, Eric Rescorla wrote: > >>>> > >>>> I would note that > >>>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana- > registry-updates/ > >>>> encodes this practice and it's currently in the RFC-Ed queue, so if > >>>> you object, you ought to do it soon. > >>>> > >>> > >>> That seems a bit late. If ALL you're saying in that document is, > >>> =E2=80=9Cspecification required=E2=80=9D, no reason to stall that dra= ft if it's in the > >>> RFC Editor queue. > >> > >> Currently live at > >> https://www.iana.org/assignments/tls-extensiontype- > values/tls-extensiontype- > >> values.xhtml : > >> > >> Note > >> The role of the designated expert is described in > >> [RFC-ietf-tls-iana-registry-updates-05]. The designated expert > >> [RFC8126] ensures that the specification is publicly available. An > >> Internet Draft that is posted and never published or a standard in > >> another standards body, industry consortium, university site, etc. > >> suffices. The expert may provide more in depth reviews, but their > >> approval should not be taken as an endorsement of the extension. > >> > >> -Ben > >> > >> _______________________________________________ > >> Rfcplusplus mailing list > >> Rfcplusplus@ietf.org > >> https://www.ietf.org/mailman/listinfo/rfcplusplus > > > > _______________________________________________ > > Rfcplusplus mailing list > > Rfcplusplus@ietf.org > > https://www.ietf.org/mailman/listinfo/rfcplusplus > > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --0000000000005304da0570395f53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW, I wouldn't have objected to Expert Review h= ere. I just didn't object to Spec Required :)

<= div>-Ekr


On Wed, Jul 4, 2018 at 9:54 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Adrian,

IMHO that's for the TLS WG to decide and the IESG (and IANA) to agree t= o.
If the result is somewhat fewer Independent Submissions, that seems
like a win-win in the end (and somewhat irrelevant to the BOF topic).

=C2=A0 =C2=A0Brian

On 05/07/2018 07:30, Adrian Farrel wrote:
> Well, I am not that bothered, but it looks like you should have used &= quot;Expert Review" with the strictures and guidance to the Designated= Experts, rather than "Specification Required" with an (implicit)= alteration of 8126 and the I-D boilerplate.
>
>> -----Original Message-----
>> From: Rfcplusplus [mailto:rfcplusplus-bounces@ietf.org] On Behalf Of Benjamin
>> Kaduk
>> Sent: 04 July 2018 18:37
>> To: Eliot Lear
>> Cc: Eric Rescorla; rfcplus= plus@ietf.org
>> Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications=
>>
>> On Wed, Jul 04, 2018 at 07:32:53PM +0200, Eliot Lear wrote:
>>> Hi EKR,
>>>
>>>
>>> On 04.07.18 19:02, Eric Rescorla wrote:
>>>>
>>>> I would note that
>>>> https://datat= racker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
>>>> encodes this practice and it's currently in the RFC-Ed= queue, so if
>>>> you object, you ought to do it soon.
>>>>
>>>
>>> That seems a bit late.=C2=A0 If ALL you're saying in that = document is,
>>> =E2=80=9Cspecification required=E2=80=9D, no reason to stall t= hat draft if it's in the
>>> RFC Editor queue.
>>
>> Currently live at
>> https://www.ian= a.org/assignments/tls-extensiontype-values/tls-extensiontype-=
>> values.xhtml :
>>
>> Note
>> The role of the designated expert is described in
>> [RFC-ietf-tls-iana-registry-updates-05]. The designated exper= t
>> [RFC8126] ensures that the specification is publicly available.=C2= =A0 An
>> Internet Draft that is posted and never published or a standard in=
>> another standards body, industry consortium, university site, etc.=
>> suffices.=C2=A0 The expert may provide more in depth reviews, but = their
>> approval should not be taken as an endorsement of the extension. >>
>> -Ben
>>
>> _______________________________________________
>> Rfcplusplus mailing list
>> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinf= o/rfcplusplus
>
> _______________________________________________
> Rfcplusplus mailing list
> Rfcplusplus@ietf.org
> https://www.ietf.org/mailman/listinfo/rfc= plusplus
>

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus

--0000000000005304da0570395f53-- From nobody Wed Jul 4 22:12:44 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165AF1271FF for ; Wed, 4 Jul 2018 22:12:43 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bboJo9a60SLY for ; Wed, 4 Jul 2018 22:12:40 -0700 (PDT) Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::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 CED41130934 for ; Wed, 4 Jul 2018 22:12:40 -0700 (PDT) Received: by mail-pl0-x236.google.com with SMTP id z9-v6so687082plo.1 for ; Wed, 04 Jul 2018 22:12:40 -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=09zcxN7xcs6rwUsELYMZeaf9734b2eQwRcbAZQQ5j6Y=; b=oHozyUFClIpsVcviXQqNjkLO9IbBNRloGO0DmDKMt9FG+umVRArn/MB8rFp61t9H3B RmdRRnc1A5x65r5LmxiSKYm4sslr9CF6aTlNjpB8d50kvfiZKULhH2apxUj59GM22Vmh hsI5Ik6/bV/OziNfZx/rQTrgMcufsCAQrKwk148Nfh3aowlEjQInHWAIolf7slhZUcg1 OhveBWKlKP/AOmz7KFWe95Vp2HetlsM9VpLYFl0b5H1ChXtzchWxXYLeFwfp+9OUdH3+ /rkpIzghqVFFTFcecK1iJSA5/R5r/iT60gW3A9hOGm7I3aw4Q5wGEXrimi110GIUqhWo o7pA== 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=09zcxN7xcs6rwUsELYMZeaf9734b2eQwRcbAZQQ5j6Y=; b=rDZa/inHPUtLmS4KHZaxJXl25IWiDCyQTkzRpZDbFTNXtYvyh3y63YmZDlSMlNy1aB CjDMAG244YO0A4EamjubWpnSN8uCLC8LMHaa+lpFbMLEqnEka9k9UVu0ygNO8NJ9BMqT pZSMLvMmWjK6/k/XVg4ZNtEJdMzlqHIBncXUxTscTxpyxXpgU3bUG7ezOy9Ubt7xeYRZ hozxmpXN1zlax8fk0RDrjN2uKLefo2HXagyW+1tA3tkZykXl4731Twjc1eDkSxj495jZ B9sEKDSQ3bXGdM3Rhko+Uzm99TmXEEIbVQIGVVII7JKgZNh1iyAr/TQW8hKfz5tBiJVu mJ3g== X-Gm-Message-State: APt69E3iWpbS/HcfD5Pq2iuWm719mjbuPSFuRmO9dJFXzT81L9UbKqSs 5gOLqApvRRaJoAG5FX3UMjiBdg== X-Google-Smtp-Source: AAOMgpcTcsT+kLWoBloTkUF4YiptTUEDPEth9/1UOQjQi/EeGPts/EDytgyDOhhqft6nKcuI+O7Wpw== X-Received: by 2002:a17:902:543:: with SMTP id 61-v6mr4674383plf.47.1530767559873; Wed, 04 Jul 2018 22:12:39 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id k186-v6sm9659132pgk.94.2018.07.04.22.12.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 22:12:39 -0700 (PDT) To: Eliot Lear , rfcplusplus@ietf.org References: From: Brian E Carpenter Message-ID: Date: Thu, 5 Jul 2018 17:12:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 05:12:43 -0000 On 04/07/2018 20:10, Eliot Lear wrote: =2E..=20 > I believe the first two uses are valuable, and the third use has also > been of value, although there is some noise.=C2=A0 I wonder if we could= > handle all of this by having the IAB provide some guidance to the ISE. = The IAB is chartered very narrowly on this: "The IAB must approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor." [BCP39] The general policy and scope of the Independent series is defined in [RFC4846]. These documents were written before the ISE was a separate job, but that change [RFC6548] doesn't really change anything fundamental, except by splitting the ISE job out from the RSE job. So, if there are issues in RFC4846, it's for the ISE to propose any changes for IAB approval (after community review, of course). Brian From nobody Thu Jul 5 17:41:27 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B13130FA9 for ; Thu, 5 Jul 2018 17:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jf6YFR6dx-64 for ; Thu, 5 Jul 2018 17:41:24 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 650A3130E27 for ; Thu, 5 Jul 2018 17:41:24 -0700 (PDT) X-AuditID: 1209190e-713ff7000000664b-47-5b3ebab2ce42 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 1D.CC.26187.3BABE3B5; Thu, 5 Jul 2018 20:41:23 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w660fLT8007644; Thu, 5 Jul 2018 20:41:22 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w660fITj011352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jul 2018 20:41:20 -0400 Date: Thu, 5 Jul 2018 19:41:18 -0500 From: Benjamin Kaduk To: Eliot Lear Cc: rfcplusplus@ietf.org Message-ID: <20180706004117.GS60996@kduck.kaduk.org> References: <20180704020155.GB60996@kduck.kaduk.org> <29f028f4-3dec-4377-eaf3-915916f96a99@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <29f028f4-3dec-4377-eaf3-915916f96a99@cisco.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUixCmqrLt5l120QV+DsMXXfx0sFi+31zkw eUz5vZHVY8mSn0wBTFFcNimpOZllqUX6dglcGROP2hdM5qrYMHUfSwPjR/YuRk4OCQETiX89 05m7GLk4hAQWM0nMfvmAHcLZwChx6Np9qMwVJonJfy8xg7SwCKhIdJ19zQJiswHZDd2XweIi AvISrWf3s4LYzAISEku3fgOrERZIkbj3biMTiM0LtG7J7g9QQ2cxSSxte8QMkRCUODnzCQtE s47Ezq132LoYOYBsaYnl/zggwvISzVtng5VzCthKHFr1F8wWFVCW2Nt3iH0Co+AsJJNmIZk0 C2HSLCSTFjCyrGKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11svNLNFLTSndxAgOakm+HYyTGrwP MQpwMCrx8EbI2kULsSaWFVfmHmKU5GBSEuUtWQEU4kvKT6nMSCzOiC8qzUktPsQowcGsJMK7 NxAox5uSWFmVWpQPk5LmYFES581exBgtJJCeWJKanZpakFoEk5Xh4FCS4FUHRq+QYFFqempF WmZOCUKaiYMTZDgP0PDzO0GGFxck5hZnpkPkTzEac5y6N2USM8ef91MnMQux5OXnpUqJ8waB lAqAlGaU5sFNAyUmiez9Na8YxYGeE+YtAqniASY1uHmvgFYxAa2aKAC2qiQRISXVwHh5V3lA 0/sH2+OqnxrqXZr5TNM/MCl3TvHlT8e7dhmcWta9SmjP7j8+yiUukhP2zXl5XTdnzqomQfnP OyW27T8pVHcmkWWf4lkuV7FEDcaNLxvkZBaVtKm49B29/cBl/vqDkwITq2rbzjFovposunni W1abJ3+f1drY77Lv79Y8b5ysxXbtpoYSS3FGoqEWc1FxIgBFdhpiJwMAAA== Archived-At: Subject: Re: [Rfcplusplus] OT: argument style and substance Re: draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 00:41:26 -0000 Hi Eliot, On Wed, Jul 04, 2018 at 08:34:13AM +0200, Eliot Lear wrote: > Hi Ben, > > Since you asked... > > On 04.07.18 04:01, Benjamin Kaduk wrote: > > On Tue, Jul 03, 2018 at 09:56:23PM -0400, Joel M. Halpern wrote: > >> PS: Your text indicating that you consider some of the responses to be > >> "emotional" seems to me to be irrelevant and inappropriate. > > Is it? > > My view.., > > With a  general statement, it certainly can be a form of poisoning the > well or tone policing, and should generally be avoided in > argumentation.  That's not to excuse appeal to emotion itself, but one > should be specific (e.g., "the above argument doesn't stand on its own > because it is an appeal to emotion").  Nor should we excuse sloppy > arguments. > > It is, I think, also ok to point out that a debate is emotional, but > that point must be made without being pejorative.  To lay claim or imply > that all those opposing are arguing irrationally because they are > emotional is pejorative.  Alissa's note, I think, demonstrates how to > get that right. It does, especially so compared to mine. > > Given the above, I'm not sure what argument would support a claim of > > inappropriateness. > > I hope I have ;-) I think you have, yes. Thanks! -Ben From nobody Fri Jul 6 04:18:16 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEB7130EA3 for ; Fri, 6 Jul 2018 04:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Nferc-CMaBda for ; Fri, 6 Jul 2018 04:18:12 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B5C126CB6 for ; Fri, 6 Jul 2018 04:18:12 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id v17-v6so3614474qkb.11 for ; Fri, 06 Jul 2018 04:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bu2HfLVMyVRSy4R8sMizPBUyFD/DdN96vPNK0d5x0VA=; b=uNBAVLPOoZqRQMEmn97zSJrG/LKyc9OL3WyRVvaghoEQJArN0zvlbnvJl4OGZSGKIF SutyCy7YVw6teXSggUuntLDeMGjltBmTOzioIT65qSD+ttzrXLbDD5tJr3mnkcwYADD/ 4mk9ZN/eMLPbEIIFtk7Tjr5J6IyBJDI56OqcsxTOP1DOWQT7NnNTAT/VudvSzAvpiybK pvlrB8/ijKwH7f8xxcZEb7paSQzkhOsAyJPB/1ElwDDmIjXvVco+EKh28fx4RdoarSs7 diyE4UcQ4iq4Rm888Enoy49tyoCyfDegmzf0QAjCU2WZBewcwKf12NNPXvyrKqudJ98n VCYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bu2HfLVMyVRSy4R8sMizPBUyFD/DdN96vPNK0d5x0VA=; b=CECgAkR8GoPQtAVX2N5ceFta5aXH0qnss+kewALNQpctlZDGpVBPYxUYeAeg5EHVrt siOq1CQzplOJ5ZdzszZiRLZ2DT+lCESpIw7YIl9JPUGuHKP++uXZisHmFfsRo2+h2JK9 RwR6mjY6usS9IEw4o45WtJNdWONCEgVbc5Ra8XOqgL/aE9yvpc/+5ZgPdUht8huuYgGZ 18JTnODgxRaTihRuN6xl3L67MLiMlxkeVMrLeXgEHcp1RjCe1XNhl6B2pGVfBcSEtST+ mLtaOe0MEEGsIlG1wIwnIRz0zSvdpRWMn+IZJ8CcCC0X3A8Jl5xfMuqj7SPKbe2qbFNO fdGA== X-Gm-Message-State: APt69E1EjctORdLVj9beH8ceNcp4lsb1cpKYWWge8Mj0s8VhwlD5ztam 1FzaCdvKU0PStLm91oNB62gQ1myp X-Google-Smtp-Source: AAOMgpe5yt/gVA1arMKnQ94k+a8ovy9Q/KMIbuy06HIU3dUu8Kw4jTNDL1fS6o/xqQ1+wQTnSg20yQ== X-Received: by 2002:a37:ab14:: with SMTP id u20-v6mr8279038qke.120.1530875891629; Fri, 06 Jul 2018 04:18:11 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id e18-v6sm6430193qte.68.2018.07.06.04.18.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 04:18:10 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-458CCFFE-1FF6-40A0-A4CF-F6041BC40FB4 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Fri, 6 Jul 2018 07:18:10 -0400 Cc: Brian E Carpenter , rfcplusplus@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> To: Eric Rescorla Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 11:18:15 -0000 --Apple-Mail-458CCFFE-1FF6-40A0-A4CF-F6041BC40FB4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my mobile device > On Jul 4, 2018, at 8:40 AM, Eric Rescorla wrote: >=20 >=20 >=20 >> On Tue, Jul 3, 2018 at 10:17 PM, Brian E Carpenter wrote: >> Eric, >>=20 >> Thanks for that substantive answer. To be frank I'd rather >> leave the response to someone who understands more about >> crypto deployment than I do. >=20 > Fair enough. >=20 >=20 >> It does seem to me that for >> national algorithms, they will be in the libraries anyway because >> they will be mandatory procurement requirements. >=20 >=20 > That's certainly an understandable prediction, but I haven't found it to b= e true in practice. For instance, NSS doesn't implement GOST or SM, and to t= he best of my knowledge neither does BoringSSL. And if we did decide to impl= ement those algorithms for some market reason, having them documented in an R= FC would not make our lives substantially easier. I work for Dell (EMC, VMWare, RSA, Pivotal) and we have needed to implement s= everal national algorithms. I verified this with the team that has done at l= east 3 of them and they used the RFCs to implement. Best, Kathleen=20 >=20 > Thanks, > -Ekr >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --Apple-Mail-458CCFFE-1FF6-40A0-A4CF-F6041BC40FB4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent= from my mobile device

On Jul 4, 2018, at 8:40 AM, Eric Rescor= la <ekr@rtfm.com> wrote:



On Tue, Jul 3, 2018 at 10:17 PM, Brian= E Carpenter <brian.e.carpenter@gmail.com> wrote:
Eric,

Thanks for that substantive answer. To be frank I'd rather
leave the response to someone who understands more about
crypto deployment than I do.

Fair enough.


It does see= m to me that for
national algorithms, they will be in the libraries anyway because
they will be mandatory procurement requirements.

That's certainly an u= nderstandable prediction, but I haven't found it to be true in practice. For= instance, NSS doesn't implement GOST or SM, and to the best of my knowledge= neither does BoringSSL. And if we did decide to implement those algorithms f= or some market reason, having them documented in an RFC would not make our l= ives substantially easier.

=
I work for Dell (EMC, VMWare, RSA, Pivotal) and we have needed to impl= ement several national algorithms.  I verified this with the team that h= as done at least 3 of them and they used the RFCs to implement.

Best,
Kathleen 


Thanks,
-Ekr


____________________= ___________________________
Rfcplusplus mailing list<= br>Rfcplusplus@ietf.org
= https://www.ietf.org/mailman/listinfo/rfcplusplus
= --Apple-Mail-458CCFFE-1FF6-40A0-A4CF-F6041BC40FB4-- From nobody Fri Jul 6 04:38:42 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93846130EA3 for ; Fri, 6 Jul 2018 04:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zav2EuDptM_p for ; Fri, 6 Jul 2018 04:38:39 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB803130E5B for ; Fri, 6 Jul 2018 04:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3351; q=dns/txt; s=iport; t=1530877119; x=1532086719; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=oX18V0R4sY6JNAvcb52D2LG65Y9cuEL4cohA8ghOox0=; b=YOcLEi4fw/RcqpaaMYOR/uAQab7DS0PYtVLRdDW4tei7+QWSaF/XUHJu xoglV4prQJ6i3pVso6VA8OQTSUnzcSUiNEzrvNRuhIL5DVpttuUnuFdh2 BOJhf06gofr2F+tAJC3zN4DBg52+5CuS3RRhO0+I+8jn2WND3gZqrLp1B g=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQDM+T5b/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUYEoQiiGONXZUwgXoIA4RsAoJONhYBAgEBAgEBAm0ohTc?= =?us-ascii?q?BBSNWEAsYKgICSQ4GAQwIAQEQgwwBgX+pJIIciE+BKw+HPYNFgQ8ngmiFJoJ?= =?us-ascii?q?VglUCiAeRSAmDWoFYiWoGiBKFRpILgUgMJYFSMxoIGxWDJZBTPZACAQE?= X-IronPort-AV: E=Sophos; i="5.51,316,1526342400"; d="asc'?scan'208"; a="5007459" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2018 11:38:36 +0000 Received: from [10.61.226.185] ([10.61.226.185]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w66BcZn2015183; Fri, 6 Jul 2018 11:38:35 GMT To: Kathleen Moriarty , Eric Rescorla Cc: rfcplusplus@ietf.org References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> Date: Fri, 6 Jul 2018 13:38:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ti8PZZOjNzQIf91DvEFexov4S5EoaCkyr" Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 11:38:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ti8PZZOjNzQIf91DvEFexov4S5EoaCkyr Content-Type: multipart/mixed; boundary="t4bYfUC5i5PuyTM1Sro9qSW36hso8GWf9"; protected-headers="v1" From: Eliot Lear To: Kathleen Moriarty , Eric Rescorla Cc: rfcplusplus@ietf.org Message-ID: <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> In-Reply-To: <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> --t4bYfUC5i5PuyTM1Sro9qSW36hso8GWf9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Kathleen: On 06.07.18 13:18, Kathleen Moriarty wrote: > I work for Dell (EMC, VMWare, RSA, Pivotal) and we have needed to > implement several national algorithms. =C2=A0I verified this with the t= eam > that has done at least 3 of them and they used the RFCs to implement. That's good information.=C2=A0 It seems to me that we seem to have an ove= rt concern and a less overt concern.=C2=A0 The overt concern is that we are committing resources to something that does not have community consensus, for one reason or another.=C2=A0 The less-than-overt concern i= s that the specifications are faulty or not well vetted.=C2=A0 Add to this = the RFC cachet that attaches to the work.=C2=A0 In the case of national algorithms, I'm going to claim that the cachet doesn't matter: national algorithms are going to get implemented where it is necessary for market entrance, even if the label we attach is "MASSIVELY-STUPID-IDEA-0001". In other words, this cut both ways in this discussion: we can use the RFC label or some other label, the production costs are going to be the same, and people will just implement when they need to.=C2=A0 On the othe= r hand, there isn't really brand dilution, and so who really cares if RFC is used? The one benefit of the ISE doing any of this is that we get to have a say about the work.=C2=A0 That's not nothing.=C2=A0 In addition, the work= can be legible and freely available.=C2=A0 But, as discussed with EKR, other ven= ues can serve that function. Eliot --t4bYfUC5i5PuyTM1Sro9qSW36hso8GWf9-- --ti8PZZOjNzQIf91DvEFexov4S5EoaCkyr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAls/VLsACgkQh7ZrRtnS ejMKpAgAqvEIJdWXRrUCsMkeENDcJ8tHcYk2/pVHXZXCanHMmIoUBphciT6Wr0U2 +G1B8Cvd2yQCFAPcAyCo2zG5QQoh/vBmI71/QkcD3rZYeasBNRnF+aYjxLazfaBR 1n/Ak0ptbHcUPfk1kjUUttJLh8qCWvNVvrI1crL8UGymX9ntoWt6s0IzUNnWo10/ Ekh/vmJitXvEUnHqVBwjDQgG+2likeGogdhTkAeSVLAPucd1pqI9DVs6V2jWe90R UKJxkMSgB6l6H+ev3g162D03XmzqOa7bWbeWkPRmcVcay0qmn08NQJjCXa32WQgo c+KrHPf3K4DijEGZyhLExWC98NWhpw== =3Q9t -----END PGP SIGNATURE----- --ti8PZZOjNzQIf91DvEFexov4S5EoaCkyr-- From nobody Fri Jul 6 05:57:56 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809D5130E34 for ; Fri, 6 Jul 2018 05:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 hx6pxgRHZaCL for ; Fri, 6 Jul 2018 05:57:53 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 05147126F72 for ; Fri, 6 Jul 2018 05:57:53 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id q12-v6so9812495qtp.6 for ; Fri, 06 Jul 2018 05:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nzK6h/Bk/DNjoNOBN60qHCOY8n0OL2CrtgzjqchqIgc=; b=ik/Ijn+TJTcRrAwYBqzzOusoTZ/1kx/I8IJz/st0JGEQ20kV7G5hxei9IvcOQOkN/U 2xJVYTfQ3Dya0Bi7XXvLV0fEWRzx7UdXkVuP57Jljow2+v9fhbCio/65DqTRhCp/Qkn9 MVlXYWGrb/zK3wc0iJo2dHHknI50YUGxRkIzY51Lb+nS9rgzjnvCC3UfFaqZZiC3tKO4 McxbI97WXcEE81xeVOmpZwNuKN8JdVMtlnn7mfAFNTR+tP7u3tAjsOs/u0D1SfDRMzWK zNdJ4qh3rNty0NOObYN80E7O2uxdhB+ghtcMJcd1qpNsS3zZH3Xqh8XouvJyH5ri7wxJ ofiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nzK6h/Bk/DNjoNOBN60qHCOY8n0OL2CrtgzjqchqIgc=; b=crAPvCxFEvhO3VrCRSVAqKtCINqkwRbbQ9M2ERGh60SoNq/NtS1DqMaXUxVxNbWFCo GZPNxJZ34YO6J7ma1h7DXVWPTE9WcudTLtJvzlxhg4jajyooLa7DR6FQhHljuDf2ZDse P0smwHL+1Un69HDF+aYAfP6zzg/yRPrLmSerBOrSvkJqxhdMIhjuS7vWg2uhD5Fg9fmJ vZZkHsGU85rcs7Z+R8LmukZwQlEA9bfam72K5wlhWiJatsXwptlx0SnH2O21hnldnjgg PCZkKt3sh/9V5c/OPtb4enQvzPV3a3jdhfKetmT+L0QrId8cBDohLUo4MXODRCNTJSQA mckQ== X-Gm-Message-State: APt69E2BfccKatP2Rx/K34l7kAs9KtuMBFSAyVhBuOjOJ2xs3HIX/pOZ sRoUomUWC7v0IbW7+Ww+SyQ= X-Google-Smtp-Source: AAOMgpdQ38bD6b4JA+rjUV+C7k6BbpDkG55bDoytioFUmiBqeEf2Ry7y3ycCpCcnrH1JyLiz+dA6vA== X-Received: by 2002:aed:2518:: with SMTP id v24-v6mr9056407qtc.151.1530881872205; Fri, 06 Jul 2018 05:57:52 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id e9-v6sm5833622qtb.78.2018.07.06.05.57.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 05:57:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> Date: Fri, 6 Jul 2018 08:57:50 -0400 Cc: Eric Rescorla , rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <04AD8D4E-28EF-4C7B-ACF5-2E27654405D9@gmail.com> References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> To: Eliot Lear Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 12:57:55 -0000 I=E2=80=99d like to add that crypto algorithms are used in more than just TL= S. We should not be scoping use of these algorithms by a few libraries of o= ne (very broadly used) protocol. Kathleen=20 Sent from my mobile device > On Jul 6, 2018, at 7:38 AM, Eliot Lear wrote: >=20 > Hi Kathleen: >=20 >> On 06.07.18 13:18, Kathleen Moriarty wrote: >> I work for Dell (EMC, VMWare, RSA, Pivotal) and we have needed to >> implement several national algorithms. I verified this with the team >> that has done at least 3 of them and they used the RFCs to implement. >=20 > That's good information. It seems to me that we seem to have an overt > concern and a less overt concern. The overt concern is that we are > committing resources to something that does not have community > consensus, for one reason or another. The less-than-overt concern is > that the specifications are faulty or not well vetted. Add to this the > RFC cachet that attaches to the work. In the case of national > algorithms, I'm going to claim that the cachet doesn't matter: national > algorithms are going to get implemented where it is necessary for market > entrance, even if the label we attach is "MASSIVELY-STUPID-IDEA-0001". >=20 > In other words, this cut both ways in this discussion: we can use the > RFC label or some other label, the production costs are going to be the > same, and people will just implement when they need to. On the other > hand, there isn't really brand dilution, and so who really cares if RFC > is used? >=20 > The one benefit of the ISE doing any of this is that we get to have a > say about the work. That's not nothing. In addition, the work can be > legible and freely available. But, as discussed with EKR, other venues > can serve that function. >=20 > Eliot >=20 From nobody Fri Jul 6 06:02:27 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F482130EF4 for ; Fri, 6 Jul 2018 06:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=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 fRVMq-0XYCPx for ; Fri, 6 Jul 2018 06:02:23 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113DE126F72 for ; Fri, 6 Jul 2018 06:02:23 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id k127-v6so4514579ybk.6 for ; Fri, 06 Jul 2018 06:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q4ZjqXF97TxvnIF6mIcR/I+zge38DCwqxdGfiHOPCH4=; b=2MfHJETEsyg1NPq65M49vSZ+nUEKLxcJaDrf9Bec3m31XeZovaB0kYvXTTwsVU8PWP WG08coOGIfCkr3xVfgv4N5615x6M3VJWtjw197Ddoi91bGNeWfbH3tZSayYdXeXLcGGS b24R+A3vMtaR0qHL7EOhMMU38f3AIjbgPOx4aJ4ngZbMAtn2mx82E9aEv6YNfT8P+CEf 8sUAvELgRm/Ij+StsqkJFuwALCPsnvULw96yeC9zfAjpa58armsin/j8ClyiJ93l+1wq 3SOlkkQ6/bEiYDpovbMTKwWkTSknDAK8pu05U8bktuouoG6X1Qcqrg3mfBIpP1xg0QMH jt6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q4ZjqXF97TxvnIF6mIcR/I+zge38DCwqxdGfiHOPCH4=; b=kvPp5cww55IzGJSZGnKO/+13LkxgkOh23HfafssDB6o8KQ5hRkGhQsSjptWtQpDhrd wSow7TdoWZvHrRQoFoRu9mmGZt99ayeyvCTxL9WsNEybQFbyVD2yu8MdexCkKp2saqNL 06970eOq3wBqqfiNPUoeA8/QWYNcl+qS/wTYGVcE60MCRqNSjE34tcjWP3+JdJ489mpL MufdN8D7aUztrA9qgw8xGX/Un/9aMlFU75eWjeoibQWc0Bbqi3ne6+wQSGIpoGW8DM4m Lcaw/zpocjgSpjwUeeLrw6srpML97wnAkIy/EI2o3C3NLCWi+wla3tNKi2P/kt6lDvKJ GObA== X-Gm-Message-State: APt69E0vK9lBMhwhbxTTg1xPIQcH2jFCi1jHNAniON3D56yKbc+bkbs8 t771+6AMk97O5nxqgZGQmE2r0RxZwM28J4HCEGXg4A== X-Google-Smtp-Source: AAOMgpfsfrHfOnrlO/tQrfvSNk1smgSNlNAE1A0a5nOxy9P40XrduPB012raFzuZvHwTs4Ce76b8AJUyD98hAFxDnCY= X-Received: by 2002:a25:32c1:: with SMTP id y184-v6mr5267271yby.168.1530882142124; Fri, 06 Jul 2018 06:02:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 06:01:41 -0700 (PDT) In-Reply-To: <04AD8D4E-28EF-4C7B-ACF5-2E27654405D9@gmail.com> References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> <04AD8D4E-28EF-4C7B-ACF5-2E27654405D9@gmail.com> From: Eric Rescorla Date: Fri, 6 Jul 2018 06:01:41 -0700 Message-ID: To: Kathleen Moriarty Cc: Eliot Lear , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000046551c05705446b3" Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 13:02:26 -0000 --00000000000046551c05705446b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 6, 2018 at 5:57 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > I=E2=80=99d like to add that crypto algorithms are used in more than just= TLS. Indeed. In fact, Firefox uses crypto algorithms for more than just TLS. And in fact, libraries such as NSS, BoringSSL, and OpenSSL (despite the names) are widely used to provide crypto for other protocols. We should not be scoping use of these algorithms by a few libraries of one > (very broadly used) protocol. > I don't think I'm suggesting otherwise. I'm merely reporting that the question of RFC status does in fact come up in discussions of whether to implement specific algorithms in crypto libraries and products which I am familiar with. -Ekr > Kathleen > > Sent from my mobile device > > > On Jul 6, 2018, at 7:38 AM, Eliot Lear wrote: > > > > Hi Kathleen: > > > >> On 06.07.18 13:18, Kathleen Moriarty wrote: > >> I work for Dell (EMC, VMWare, RSA, Pivotal) and we have needed to > >> implement several national algorithms. I verified this with the team > >> that has done at least 3 of them and they used the RFCs to implement. > > > > That's good information. It seems to me that we seem to have an overt > > concern and a less overt concern. The overt concern is that we are > > committing resources to something that does not have community > > consensus, for one reason or another. The less-than-overt concern is > > that the specifications are faulty or not well vetted. Add to this the > > RFC cachet that attaches to the work. In the case of national > > algorithms, I'm going to claim that the cachet doesn't matter: national > > algorithms are going to get implemented where it is necessary for marke= t > > entrance, even if the label we attach is "MASSIVELY-STUPID-IDEA-0001". > > > > In other words, this cut both ways in this discussion: we can use the > > RFC label or some other label, the production costs are going to be the > > same, and people will just implement when they need to. On the other > > hand, there isn't really brand dilution, and so who really cares if RFC > > is used? > > > > The one benefit of the ISE doing any of this is that we get to have a > > say about the work. That's not nothing. In addition, the work can be > > legible and freely available. But, as discussed with EKR, other venues > > can serve that function. > > > > Eliot > > > --00000000000046551c05705446b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 6, 2018 at 5:57 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
We should not be scoping use of these algorithms by a= few libraries of one (very broadly used) protocol.

I don't think I'm suggesting other= wise. I'm merely reporting that the question of RFC status does in fact= come up in discussions of whether to implement specific algorithms in cryp= to libraries and products which I am familiar with.

-Ekr

=C2=A0
= Kathleen

Sent from my mobile device

> On Jul 6, 2018, at 7:38= AM, Eliot Lear <lear@cisco.com>= ; wrote:
>
> Hi Kathleen:
>
>> On 06.07.18 13:18, Kathleen Moriarty wrote:
>> I work for Dell (EMC, VMWare, RSA, Pivotal) and we have needed to<= br> >> implement several national algorithms.=C2=A0 I verified this with = the team
>> that has done at least 3 of them and they used the RFCs to impleme= nt.
>
> That's good information.=C2=A0 It seems to me that we seem to have= an overt
> concern and a less overt concern.=C2=A0 The overt concern is that we a= re
> committing resources to something that does not have community
> consensus, for one reason or another.=C2=A0 The less-than-overt concer= n is
> that the specifications are faulty or not well vetted.=C2=A0 Add to th= is the
> RFC cachet that attaches to the work.=C2=A0 In the case of national > algorithms, I'm going to claim that the cachet doesn't matter:= national
> algorithms are going to get implemented where it is necessary for mark= et
> entrance, even if the label we attach is "MASSIVELY-STUPID-IDEA-0= 001".
>
> In other words, this cut both ways in this discussion: we can use the<= br> > RFC label or some other label, the production costs are going to be th= e
> same, and people will just implement when they need to.=C2=A0 On the o= ther
> hand, there isn't really brand dilution, and so who really cares i= f RFC
> is used?
>
> The one benefit of the ISE doing any of this is that we get to have a<= br> > say about the work.=C2=A0 That's not nothing.=C2=A0 In addition, t= he work can be
> legible and freely available.=C2=A0 But, as discussed with EKR, other = venues
> can serve that function.
>
> Eliot
>

--00000000000046551c05705446b3-- From nobody Fri Jul 6 06:05:36 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC1A130E06 for ; Fri, 6 Jul 2018 06:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yy7tqzhE9lXF for ; Fri, 6 Jul 2018 06:05:32 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 C8536130EF1 for ; Fri, 6 Jul 2018 06:05:31 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id m13-v6so9845406qth.1 for ; Fri, 06 Jul 2018 06:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BRgfARqE9qxZQDdkTwnIupbbQ9Ggd5/I6c3tSENHNC8=; b=qWRR7KrxuOuPiTiYDvduMX5h29l+KiAVqLWSLk1faADPKAWJUyTGLKg+Tw0b7PPRb0 F+DwhR1cMm8/kmpJ2ZVea+lMrr0HUfpecpAI5J1Nf/Vnoz7WfLRyc78mDCqOTDnAAcqJ hpePkzxZzu6on3gjnUlWTA9GZIJCYky7GTGxfCURlBeG0LHSC23bjxfF704IQHKBhnfR 8QTfRIe3YoNcLYJt2iqWiuqe73hzeK8o2cTTgKIyq1ymfJDGXXjvwDlKh5gRKMboO6QG 1SrJ/vWpgYc9w+awTbXXyr6/beoore+j2OClQhea2C957aSKbzT9WezAsN9Cnu/2tzHh 85xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BRgfARqE9qxZQDdkTwnIupbbQ9Ggd5/I6c3tSENHNC8=; b=edcYLy82b6zDae3Evcjkb0hy80toRTFBVJ23mltylDXKXvbAJubYvy2g3pOV5JSsAU VxWJXOCc+zeK2sNBqhzU7RdftiPZe1mQxBbLiMyZFOujC6gbZqVe3NN7pr8jo+mqUwPj FRW7N9Z+26OeWdtG5/meAERAa6Qw8Nw737FXOK410kzG8YDniIU/A/q806waReQLjGpC uOkev1gWeY2wNq/VVTw62VOWNbPsvWiv+g1FVal8V9Xo76FXjdqNaDA+PEttDjD8ZHYH G6Ur0t+lAXqDLPOaVjcw5MjROOMnY++oj9YKpk6cYk/IYZy3DyBIdLMp/HrboqJV8FCs o0gA== X-Gm-Message-State: APt69E2+RyCWDy1ai8SNPO4ZVC93osXo5Am3iOIBjH0RHlCAU3S3+9oz ftIbTMyHXElXkT28rwuERkhWDNJs X-Google-Smtp-Source: AAOMgpeCyqr9iO8omD1IEmqr+Of2KhbNPW6llWMiMJs5+6byKnjqnHze/lkt6GISQe/nYlhhHAUPjg== X-Received: by 2002:a0c:b5d8:: with SMTP id o24-v6mr8399105qvf.189.1530882331026; Fri, 06 Jul 2018 06:05:31 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id c9-v6sm4746203qth.35.2018.07.06.06.05.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 06:05:30 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D8B43A35-A808-44A4-AE31-D2150C5AA3DF Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Fri, 6 Jul 2018 09:05:29 -0400 Cc: Eliot Lear , rfcplusplus@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> <04AD8D4E-28EF-4C7B-ACF5-2E27654405D9@gmail.com> To: Eric Rescorla Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 13:05:35 -0000 --Apple-Mail-D8B43A35-A808-44A4-AE31-D2150C5AA3DF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my mobile device > On Jul 6, 2018, at 9:01 AM, Eric Rescorla wrote: >=20 >> On Fri, Jul 6, 2018 at 5:57 AM, Kathleen Moriarty wrote: >> I=E2=80=99d like to add that crypto algorithms are used in more than just= TLS.=20 >=20 > Indeed. In fact, Firefox uses crypto algorithms for more than just TLS. An= d in fact, libraries such as NSS, BoringSSL, and OpenSSL (despite the names)= are widely used to provide crypto for other protocols. >=20 >=20 >> We should not be scoping use of these algorithms by a few libraries of on= e (very broadly used) protocol. >=20 > I don't think I'm suggesting otherwise. I'm merely reporting that the ques= tion of RFC status does in fact come up in discussions of whether to impleme= nt specific algorithms in crypto libraries and products which I am familiar w= ith. Sure, understandable. For those not in this space, having insight to places= where national algorithms are implemented may factor into their thoughts on= the usefulness of these algorithms being published in the RFC series. We a= re just one company headquartered in the US, I=E2=80=99m sure others impleme= nt them as well. =20 Best, Kathleen=20 >=20 > -Ekr >=20 > =20 >> Kathleen=20 >>=20 >> Sent from my mobile device >>=20 >> > On Jul 6, 2018, at 7:38 AM, Eliot Lear wrote: >> >=20 >> > Hi Kathleen: >> >=20 >> >> On 06.07.18 13:18, Kathleen Moriarty wrote: >> >> I work for Dell (EMC, VMWare, RSA, Pivotal) and we have needed to >> >> implement several national algorithms. I verified this with the team >> >> that has done at least 3 of them and they used the RFCs to implement. >> >=20 >> > That's good information. It seems to me that we seem to have an overt >> > concern and a less overt concern. The overt concern is that we are >> > committing resources to something that does not have community >> > consensus, for one reason or another. The less-than-overt concern is >> > that the specifications are faulty or not well vetted. Add to this the= >> > RFC cachet that attaches to the work. In the case of national >> > algorithms, I'm going to claim that the cachet doesn't matter: national= >> > algorithms are going to get implemented where it is necessary for marke= t >> > entrance, even if the label we attach is "MASSIVELY-STUPID-IDEA-0001". >> >=20 >> > In other words, this cut both ways in this discussion: we can use the >> > RFC label or some other label, the production costs are going to be the= >> > same, and people will just implement when they need to. On the other >> > hand, there isn't really brand dilution, and so who really cares if RFC= >> > is used? >> >=20 >> > The one benefit of the ISE doing any of this is that we get to have a >> > say about the work. That's not nothing. In addition, the work can be >> > legible and freely available. But, as discussed with EKR, other venues= >> > can serve that function. >> >=20 >> > Eliot >> >=20 >=20 --Apple-Mail-D8B43A35-A808-44A4-AE31-D2150C5AA3DF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent= from my mobile device

On Jul 6, 2018, at 9:01 AM, Eric Rescor= la <ekr@rtfm.com> wrote:


Sure, understandable.  For those not in this space, h= aving insight to places where national algorithms are implemented may factor= into their thoughts on the usefulness of these algorithms being published i= n the RFC series.  We are just one company headquartered in the US, I=E2= =80=99m sure others implement them as well.  

Best,<= /div>
Kathleen 
=

-E= kr

 
Kathleen

Sent from my mobile device

> On Jul 6, 2018, at 7:38 A= M, Eliot Lear <lear@cisco.com> w= rote:
>
> Hi Kathleen:
>
>> On 06.07.18 13:18, Kathleen Moriarty wrote:
>> I work for Dell (EMC, VMWare, RSA, Pivotal) and we have needed to >> implement several national algorithms.  I verified this with t= he team
>> that has done at least 3 of them and they used the RFCs to implemen= t.
>
> That's good information.  It seems to me that we seem to have an o= vert
> concern and a less overt concern.  The overt concern is that we ar= e
> committing resources to something that does not have community
> consensus, for one reason or another.  The less-than-overt concern= is
> that the specifications are faulty or not well vetted.  Add to thi= s the
> RFC cachet that attaches to the work.  In the case of national
= > algorithms, I'm going to claim that the cachet doesn't matter: national=
> algorithms are going to get implemented where it is necessary for marke= t
> entrance, even if the label we attach is "MASSIVELY-STUPID-IDEA-0001".<= br> >
> In other words, this cut both ways in this discussion: we can use the > RFC label or some other label, the production costs are going to be the=
> same, and people will just implement when they need to.  On the ot= her
> hand, there isn't really brand dilution, and so who really cares if RFC=
> is used?
>
> The one benefit of the ISE doing any of this is that we get to have a > say about the work.  That's not nothing.  In addition, the wo= rk can be
> legible and freely available.  But, as discussed with EKR, other v= enues
> can serve that function.
>
> Eliot
>

= --Apple-Mail-D8B43A35-A808-44A4-AE31-D2150C5AA3DF-- From nobody Fri Jul 6 06:33:25 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50DF1277BB for ; Fri, 6 Jul 2018 06:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=kQAUNo+4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tsvfuPz7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjQZEZhFsfc8 for ; Fri, 6 Jul 2018 06:33:19 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A06130DC1 for ; Fri, 6 Jul 2018 06:33:19 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7927F21A7B; Fri, 6 Jul 2018 09:33:18 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 06 Jul 2018 09:33:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=Obsc9ZkggWy4FyOQQRCJpvmPUgFYmzRaOnjMqgyWIOs=; b=kQAUNo+4 04q6EgUn2R9vvOFlDzRC1ypqdI2wTpO4bsbF8pGxh+mpgsOtIlfCdLNtOj1sS0XY bg7JElXSEJIlOLtjQjIZOgjG91BWH+3pVqL+1ESkwVXrRjVqp0U3h4G393HWltlp y3UF3y6IzSEmlAovRE9I7/QsVnkgOvEp22jtU73QnZF/eONV+qneveA5iIz4Mg2r eE2VJX5s6QpBmOikhmnSvWO6kqbBa641Q9H0bxp7rncyzUTQYlZAUjV3fBvRDxpa 5WBNog1zmNAU9dIKOr6rLIJ/oqpVSeiq1o0fcalBsrB3SCkOns9rqQUDkk5S1wiw de17MmEv8/43tA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=Obsc9ZkggWy4FyOQQRCJpvmPUgFYm zRaOnjMqgyWIOs=; b=tsvfuPz7gjCLnOL3CgEzSVq6qSkxaar/Y+Bn4yIPRX0Ud AwfJ9CxOi8dXofwFZLhM6shFQzVi0KtLkCvw088WLYEIi+ISclZt48tcdv8872No SlSH8J/6D4oRKHd/MpBGBQIiB7k1iIIhmEn82X3U7PszFWtA8BahPBDx/y1LBayS DetOcjAI9m8q36xpK+v09QW4jXKLlaA2B+jbfYT90zdKYlnZEngf4BO2qWvJtlGv 5ZTTO2P4tsJG7sR7iznj+Z+BfqLmJrcTodIf7bqfCPsuAEh9SSs9A4+vxvFe9Z73 7elrkNn90jkJVLiq9d/VpsVCCdQqo1Xdf98rcWDEQ== X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id 801D0102B6; Fri, 6 Jul 2018 09:33:17 -0400 (EDT) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_24CC6067-36DD-4BFF-9B8F-3AE3581D4138" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 6 Jul 2018 09:33:15 -0400 In-Reply-To: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> Cc: rfcplusplus@ietf.org To: Adrian Farrel References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 13:33:23 -0000 --Apple-Mail=_24CC6067-36DD-4BFF-9B8F-3AE3581D4138 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 4, 2018, at 3:56 AM, Adrian Farrel wrote: >=20 > Buried in this thread there was... >=20 >>> As opposed to publication as FOO 7974, that is. >>=20 >> [Med] I'm not sure about the possible implication on documents = review, but I >> don't see much difference except reducing the page count as the notes >> mentioned above are likely to be deleted because this will be implied = by the FOO >> label itself. >=20 > That's an interesting point. >=20 > Suppose a document contained the specification of a protocol that = competed with an IETF consensus protocol. Suppose further that = implementation of the specified protocol likely caused negative = interactions with the IETF consensus protocol and so risked the = stability of the Internet. >=20 > - Where the document is in the IETF stream, we know how to handle it. > - Where the document is in the IRTF or Independent Streams we have a > time-tested mechanism and (I think) no evidence of harm through > publication. > - If the IRTF and Independent Stream documents became FOO and BAR=20 > documents, we would need to understand what control/input the IESG > expected to have. > - If the publication is moved to another venue, the only thing the = IESG > can do is plead or bang shoes on tables. >=20 > There seems to be an correlation: the closer to looking like an IETF = consensus document, the more IESG input. I agree with this conclusion, modulo the ability for liaison statements = and cross-participation in other venues to have an influence on what = gets published in other venues. All of the above seems to be by design.=20= >=20 > Now, it might be thought (this is possibly a branding thing) that the = further from looking like an IETF consensus document the less we have to = care about the "protocol conflict problem", but I would argue that the = less input the IESG has, the more we have to worry. Thus, were an = alternative venue for publishing competing specifications to be = developed, I would claim that this is harmful to the RFC band and to = both the IETF's brand and raison d'=C3=AAtre.=20 I=E2=80=99m not following this. If someone cares about how the Internet = works, then having a poorly designed specification that risks the = Internet=E2=80=99s stability published in any venue is a problem. That = doesn=E2=80=99t mean the IESG or any individual participant is = necessarily going to be able to address that problem, but it=E2=80=99s = still a problem. Having that specification labeled with =E2=80=9CRFC=E2=80= =9D means the IESG and the IETF face the potential additional problem of = having the specification confused for an IETF consensus output. Alternative venues for publishing competing specifications already exist = (e.g., https://url.spec.whatwg.org/ ). = They may or may not be harmful to the Internet, but I don=E2=80=99t see = how they=E2=80=99re specifically harmful to the RFC brand. They=E2=80=99re= certainly not more harmful to the RFC brand than competing = specifications labeled =E2=80=9CRFC." Alissa >=20 >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --Apple-Mail=_24CC6067-36DD-4BFF-9B8F-3AE3581D4138 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 4, 2018, at 3:56 AM, Adrian Farrel <adrian@olddog.co.uk>= wrote:

Buried in this thread there was...

 As opposed to publication as FOO 7974, that is.

[Med] I'm not sure about the = possible implication on documents review, but I
don't see = much difference except reducing the page count as the notes
mentioned above are likely to be deleted because this will be = implied by the FOO
label itself.

That's an interesting point.

Suppose a document contained the specification = of a protocol that competed with an IETF consensus protocol. Suppose = further that implementation of the specified protocol likely caused = negative interactions with the IETF consensus protocol and so risked the = stability of the Internet.

- Where the = document is in the IETF stream, we know how to handle it.
- = Where the document is in the IRTF or Independent Streams we have a
  time-tested mechanism and (I think) no evidence = of harm through
  publication.
- = If the IRTF and Independent Stream documents became FOO and BAR
 documents, we would need to understand what = control/input the IESG
 expected to have.
- If the publication is moved to another venue, the only = thing the IESG
  can do is plead or bang shoes = on tables.

There seems to be an = correlation: the closer to looking like an IETF consensus document, the = more IESG input.

I agree with this conclusion, modulo the ability = for liaison statements and cross-participation in other venues to have = an influence on what gets published in other venues. All of the above = seems to be by design. 


Now, it might = be thought (this is possibly a branding thing) that the further from = looking like an IETF consensus document the less we have to care about = the "protocol conflict problem", but I would argue that the less input = the IESG has, the more we have to worry. Thus, were an alternative venue = for publishing competing specifications to be developed, I would claim = that this is harmful to the RFC band and to both the IETF's brand and = raison d'=C3=AAtre.

I=E2=80=99m not following this. If someone cares = about how the Internet works, then having a poorly designed = specification that risks the Internet=E2=80=99s stability published in = any venue is a problem. That doesn=E2=80=99t mean the IESG or any = individual participant is necessarily going to be able to address that = problem, but it=E2=80=99s still a problem. Having that specification = labeled with =E2=80=9CRFC=E2=80=9D means the IESG and the IETF face the = potential additional problem of having the specification confused for an = IETF consensus output.

Alternative = venues for publishing competing specifications already exist = (e.g., https://url.spec.whatwg.org/). They may or may not be = harmful to the Internet, but I don=E2=80=99t see how they=E2=80=99re = specifically harmful to the RFC brand. They=E2=80=99re certainly not = more harmful to the RFC brand than competing specifications labeled = =E2=80=9CRFC."

Alissa




_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusplus

= --Apple-Mail=_24CC6067-36DD-4BFF-9B8F-3AE3581D4138-- From nobody Fri Jul 6 06:34:11 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60638130E4A for ; Fri, 6 Jul 2018 06:34: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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJX7NPQmhIqc for ; Fri, 6 Jul 2018 06:34:08 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD361277BB for ; Fri, 6 Jul 2018 06:34:08 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fbQs8-0008KO-Fu; Fri, 06 Jul 2018 09:34:04 -0400 Date: Fri, 06 Jul 2018 09:33:57 -0400 From: John C Klensin To: Eliot Lear , Kathleen Moriarty , Eric Rescorla cc: rfcplusplus@ietf.org Message-ID: In-Reply-To: <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 13:34:10 -0000 --On Friday, July 6, 2018 13:38 +0200 Eliot Lear wrote: >... > The one benefit of the ISE doing any of this is that we get to > have a say about the work.=C2=A0 That's not nothing.=C2=A0 In > addition, the work can be legible and freely available.=C2=A0 = But, > as discussed with EKR, other venues can serve that function. There is one other benefit that I think we should not lose sight of. Over the years (including well before there was an IETF) "we" have presented the RFC Series as the go-to place for technical specifications about what is used on the Internet. I suggest that role is one of the reasons the RFC brand is as strong as it is. To the extent to which specifications are adopted, deployed widely, and used (even if only within countries where they are mandated) but that are not included in the RFC series, that reputation and brand suffers.=20 In a way, being explicit that no specification will be published in the RFC Series unless it is approved of (favored) by the IETF (or the IESG) is an advantage because it explicitly drops the "what is used on the Internet" assumption for "what the IETF approves of". But that is likely to reduce the value of the brand even more, especially for organizations (and governments) for which the IETF's endorsement is less important that market pressures, their own evaluations, etc. =20 >From that perspective, your "get to have a say" observation is even more important because it both preserves the IETF's reputation for making decisions based on technical merit and openness to ideas not invented here. The best way to preserve and support that reputation is to go ahead and publish things we don't like and explain why we don't like them. For the latter, "the IETF does not recommend this because XYZ was deemed superior because" is far stronger than "the IETF does not recommend this because, when sniffed, it let off a bad odor" but either is better than ignoring a spec that is widely-deployed and used because we don't like it. Let me give an example that lies a bit outside the crypto realm and that may therefore be easier for the rest of us to understand. Suppose the IETF adopts a protocol that is carefully designed for maximum privacy. Now suppose that something comes along that is faster, lighter-weight, supported or mandated by some governments but that protects privacy from everyone but those governments (but leaves information completely exposed to them). We can certainly ignore the latter as just bad news but I contend we protect our reputation and the privacy-safety of users, and make the Internet better, far more by publishing its specs, explaining the vulnerabilities it creates, and recommending against it unless one is actually required to use it than by ignoring it. Does that require extra work? Of course it does, but pushing it off into the Independent Submission process mitigates some of that. Maybe we can't do it or need to take shortcuts with the level of detail in our explanations. But that isn't without costs because every further step we take toward ignoring such specifications brings us a step further away from the image of an engineering organization that produces standards when that is appropriate and toward just another standards body that arrives at its conclusions by obscure means and then pushes them. Precisely because we have never wanted to (and cannot) claim credibility on the basis of the companies, established national bodies, or governments who agree to make the standards, that engineering orientation and commitment to the welfare and improvement of the Internet is all we have to stand on. best, john From nobody Fri Jul 6 06:53:46 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0ABB130F5B for ; Fri, 6 Jul 2018 06:53:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 pPSO18PfyCXB for ; Fri, 6 Jul 2018 06:53:42 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B98130E55 for ; Fri, 6 Jul 2018 06:53:42 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fbRB6-0008VL-NF; Fri, 06 Jul 2018 09:53:40 -0400 Date: Fri, 06 Jul 2018 09:53:33 -0400 From: John C Klensin To: Eric Rescorla cc: Kathleen Moriarty , rfcplusplus@ietf.org, Eliot Lear Message-ID: <96972B9E99F8BADB18E7F6BD@PSB> In-Reply-To: References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> <04AD8D4E-28EF-4C7B-ACF5-2E27654405D9@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 13:53:45 -0000 --On Friday, July 6, 2018 06:01 -0700 Eric Rescorla wrote: >> We should not be scoping use of these algorithms by a few >> libraries of one (very broadly used) protocol. > I don't think I'm suggesting otherwise. I'm merely reporting > that the question of RFC status does in fact come up in > discussions of whether to implement specific algorithms in > crypto libraries and products which I am familiar with. Sure. As well it should. But, if the people participating in the discussions and doing the evaluation have any sense and knowledge at all (as Mozilla and Dell/EMC certainly do and would even without you or Kathleen), then "RFC status" is precisely what should be examined. That certainly includes the difference between Experimental and Informational. If we took maturity levels as seriously as RFC 2026 anticipated, it would include the difference between Proposed and Full Standards. And, if we used Applicability Statements as often as some of us thought we should (or at least more often than near-zero), they would be part of the picture too. In most cases, it should include the difference between, e.g., a WG Informational document and an Informational Document published by the ISE for the information of the community with no endorsement by anyone other than the authors (not even endorsement by the ISE). However "question of RFC status" and "discussions of whether to implement" are about people who are actually reading the documents. It seems to me that whether a document is flagged with one series code or label or another is likely to make very little difference to them because they are reading it anyway. The people who are arguably protected by label changes are those who are not knowledgeably "discussing" or "evaluating" specifications but who are relying entirely on marketing claims or government assertions. Many years ago, a colleague of my was fond of quoting his father as saying that, while one can reasonably aspire to make a system fool proof, making one d*mn fool proof was probably an unreasonable goal. best, john From nobody Fri Jul 6 07:00:41 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF78130E4C for ; Fri, 6 Jul 2018 07:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 1b6JAWRMTlVM for ; Fri, 6 Jul 2018 07:00:36 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 E3627130E55 for ; Fri, 6 Jul 2018 07:00:35 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id b15-v6so23608012oib.10 for ; Fri, 06 Jul 2018 07:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DEoiaCPMzF6nINEtb6EkedJCR3Ax2qwh318qB8YpvJw=; b=ibhx/Ye393lfOOvi+eZm7iwenF96XV5Rrea60DqNogAxxT6Q75SLZX/wkhcXJT8Zny P4kGoolbZ5VYWi71SgNCu+WoHHlj82I9S3xpSf95lpbofiGtoL9iQ8htjQ0fYzaUfjd8 Nbhn6B4NuL9QMWhoSN1mmBCDFPwXIAaF3XNFeoM9D8aOqTeEZ4MeuIYaP+6yBIFFY7lL 72jJ+NK0AgNVgvuH9yFr2VooQZsGlSWmbvUdXrIEecOIaRpbOPXkFtmktlM5vBKcmBST qPx6KKZlKl+lufZMs1j8OFM897X29fxm7b2+g2iGS/SOfbdtNlVS9jyTIEAXdXLwQPcu Qd/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DEoiaCPMzF6nINEtb6EkedJCR3Ax2qwh318qB8YpvJw=; b=KINOb/AaAhWQ77UzEP6qQsFlVBlGiJy5/h66p+wUQKI74ivtylRoNIk+kMGgKD4es5 NK2K31lNCk8AjBb9ODH2q+yeK4RW6f9BJt5TyvFxsUNnbuusKyj2kB7gWvQvoDuBe5pA yFFY03m4ATQhWTAUvwTsRlLJW7RehIL3Raat4SmQsjHYrRWjrKiWvHEZs0HvCR2Jgx/2 4L+AKvuiN3uvxc//Bbu0MjQQi0PNRU8RpW2qjsq83XQWqCMNz9PUQenliOCFW35PjOBe I4qI/18ZdQcjKygAKhttkDOCt3YLA39LP0wWcHdwDwvXcefdlUX1cc5kmlvUxL+ePI3Q 9XEw== X-Gm-Message-State: APt69E0d8ew/oMxL0d4lgcqilnD9in0azJ1SMAxL+0c+8gcct7NV5b9J vVRAgWa/mULu0Elw68D50eZ5EPuKbJcUJmw2r3A= X-Google-Smtp-Source: AAOMgpdVWxU52ZH8m4KH0JBgKuFf/1R92eAIODUndalki2+PVCWu6tCf5KLYT/fewFm4sAndyytPPOEqj+IP7S218Mg= X-Received: by 2002:aca:3254:: with SMTP id y81-v6mr11034135oiy.317.1530885635323; Fri, 06 Jul 2018 07:00:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:7ad0:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 06:59:54 -0700 (PDT) In-Reply-To: <96972B9E99F8BADB18E7F6BD@PSB> References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> <04AD8D4E-28EF-4C7B-ACF5-2E27654405D9@gmail.com> <96972B9E99F8BADB18E7F6BD@PSB> From: Kathleen Moriarty Date: Fri, 6 Jul 2018 09:59:54 -0400 Message-ID: To: John C Klensin Cc: Eric Rescorla , rfcplusplus@ietf.org, Eliot Lear Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 14:00:38 -0000 On Fri, Jul 6, 2018 at 9:53 AM, John C Klensin wrote: > > > --On Friday, July 6, 2018 06:01 -0700 Eric Rescorla > wrote: > >>> We should not be scoping use of these algorithms by a few >>> libraries of one (very broadly used) protocol. > >> I don't think I'm suggesting otherwise. I'm merely reporting >> that the question of RFC status does in fact come up in >> discussions of whether to implement specific algorithms in >> crypto libraries and products which I am familiar with. > > Sure. As well it should. But, if the people participating in > the discussions and doing the evaluation have any sense and > knowledge at all (as Mozilla and Dell/EMC certainly do and would > even without you or Kathleen), then "RFC status" is precisely > what should be examined. Our teams implementing fully understand the difference without any explanation needed. When I asked the question to find out what national algorithms we had implemented, I received a very thorough response including the algorithms, RFC#s and an explanation in short order. They monitor various RFCs and I at times get educated questions on status in terms of publication and path for publication. Best, Kathleen > That certainly includes the difference > between Experimental and Informational. If we took maturity > levels as seriously as RFC 2026 anticipated, it would include > the difference between Proposed and Full Standards. And, if we > used Applicability Statements as often as some of us thought we > should (or at least more often than near-zero), they would be > part of the picture too. In most cases, it should include the > difference between, e.g., a WG Informational document and an > Informational Document published by the ISE for the information > of the community with no endorsement by anyone other than the > authors (not even endorsement by the ISE). > > However "question of RFC status" and "discussions of whether to > implement" are about people who are actually reading the > documents. It seems to me that whether a document is flagged > with one series code or label or another is likely to make very > little difference to them because they are reading it anyway. > The people who are arguably protected by label changes are those > who are not knowledgeably "discussing" or "evaluating" > specifications but who are relying entirely on marketing claims > or government assertions. Many years ago, a colleague of my > was fond of quoting his father as saying that, while one can > reasonably aspire to make a system fool proof, making one d*mn > fool proof was probably an unreasonable goal. > > best, > john > -- Best regards, Kathleen From nobody Fri Jul 6 07:34:32 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3A5130F26 for ; Fri, 6 Jul 2018 07:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=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 3Bp3j5VZ99LS for ; Fri, 6 Jul 2018 07:34:28 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F42130EBA for ; Fri, 6 Jul 2018 07:34:27 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id p129-v6so4245669ywg.7 for ; Fri, 06 Jul 2018 07:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZD/fJYiZFya7B2/ZJySe58flS+OYpRtSx9v7hNEkKqU=; b=peTDpsTliXHIXDFqABXmtbDn7x82yjrBR/rj4MROUyTxwlbmS156xztkOUsYEfftLK Y0pj/7wkUJQpO/aSLSwn9p1MfKsmPXA0YI2zj111PFzqGnM5Ox+FRHX+qt1t8ge9Vup3 yEn9lL8YxQie3qG45ZmzxAvjxkcm8fSTArYgRfw7pILRlpkoSxrEt9Eo8p04Ma6BUo7T BkAwTRTYDiew0oruoRqT1GJk+6WoFfBD/rnZJnZ7/ZToIB4pHqWMfA4Q8549EnCED5YB 1v7fMJCtudZXQ/kIRzm8sBVUsFdF3TjAnOxQDHenQVRvpXeDSELdiWBAHRREFC/IIk5B /0RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZD/fJYiZFya7B2/ZJySe58flS+OYpRtSx9v7hNEkKqU=; b=N2xe1y6F7dTrvuGcBbeyVbamzotXp7qmzPSiJmTXYO4aVMkxI2f608QA3qHvk1BM3A 07t15oeQ22vs6ohAMnfDZQ1siLYsf9hhXNcnpWsvUsrx0UK+sxuhJMBlI7R2Y6NXXxMV HqevqC3N4ZFvroV7VvODrg/yJAUhuwd3S2TJeJQNZraQW2WQB0zB/hXzQFouPhU4aXU2 NGmA5I5ZAUZB9+kcTPmskdsvqQvgKyNHbJkCFTx1QTwejqFLSm3Fo635LekfqwYbsFN+ 4daTYB5ENS+NKFX3cJU1dYsLtQdylf57dVvhAOPD6A9t5txf7H8aCPyPtHMcO4ROaB0s rI8g== X-Gm-Message-State: APt69E0aHwuSxeHb21P8opIeEiDd820rwNzgbrwWGXmRADnOWKdfTocQ QLpvN1VfkNy7+c27Ezu8tM8g8YZNHlLTr659uVLuOw== X-Google-Smtp-Source: AAOMgpdlPjFEn/V1S/J7rcOIVQ2alQXyzq4kbTKCdsW3Cd95UcMAuCVsmVAW6FDkwC/Ru9kVLEIjkvjNDmjzS3eFJaI= X-Received: by 2002:a0d:f286:: with SMTP id b128-v6mr4931696ywf.489.1530887666885; Fri, 06 Jul 2018 07:34:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 07:33:46 -0700 (PDT) In-Reply-To: References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> From: Eric Rescorla Date: Fri, 6 Jul 2018 07:33:46 -0700 Message-ID: To: John C Klensin Cc: Eliot Lear , Kathleen Moriarty , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000009380690570558fef" Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 14:34:31 -0000 --0000000000009380690570558fef Content-Type: text/plain; charset="UTF-8" On Fri, Jul 6, 2018 at 6:33 AM, John C Klensin wrote: > > > --On Friday, July 6, 2018 13:38 +0200 Eliot Lear > wrote: > > >... > > The one benefit of the ISE doing any of this is that we get to > > have a say about the work. That's not nothing. In > > addition, the work can be legible and freely available. But, > > as discussed with EKR, other venues can serve that function. > > There is one other benefit that I think we should not lose sight > of. Over the years (including well before there was an IETF) > "we" have presented the RFC Series as the go-to place for > technical specifications about what is used on the Internet. Hmm... This seems to me to be true only if one has a pretty narrow definition of "on the Internet". Here are a few examples of things which get used on the Internet on a regular basis that aren't RFCs: - HTML (WHATWG and/or W3C) - JavaScript (TC39) - H.264 (MPEG) - JPEG - AES, P-256 (NIST) - Bittorrent - Tor I spent a bunch of time trying to think of a characterization of the role of the RFC series (or the IETF's) role that was succinct, but in truth I think we're part of a broad coaltion of people publishing Internet protocol specificationswith somewhat fuzzily defined boundaries between the areas of work. > Let me give an example that lies a bit outside the crypto realm and that may therefore be easier for the rest of us to > understand. Suppose the IETF adopts a protocol that is > carefully designed for maximum privacy. Now suppose that > something comes along that is faster, lighter-weight, supported > or mandated by some governments but that protects privacy from > everyone but those governments (but leaves information > completely exposed to them). We can certainly ignore the > latter as just bad news but I contend we protect our reputation > and the privacy-safety of users, and make the Internet better, > far more by publishing its specs, explaining the vulnerabilities > it creates, and recommending against it unless one is actually > required to use it than by ignoring it. > This hypothetical contains a number of things "we" might do (publish the spec, critique it, recommend against it). I don't think it's actually a particular service to the world for us to publish the spec as long as it's readily found by other means. It's not clear to me how that helps. I certainly think critiquing it and recommending against it are good ideas (though depending on the technology, perhaps making something that had the good properties without the bad would be even better). It's not clear to me that having those critiques in the RFC series is that helpful, though having the IETF recommend against the protocol (whether that recommendation was in an RFC or not) might well be. With that said, this hypothetical isn't *that* far off the mark. Tor is a privacy protocol better than anything in the IETF (though to the best of my knowledge it doesn't have the negative properties of the protocol in your hypothetical). Its protocol is mostly defined by the implementation although there's a not-particularly clear spec. There are a pile of papers describing potential attacks. To the best of my knowledge, none of this is in the RFC series. From my perspective as a protocol implementer: - Having a good spec published would be valuable. Having it in the RFC series would not be particularly helpful, though it would not be harmful [0] - Having an IETF standard would probably be helpful depending on whether it improved Tor. It would likely lead to a clearer spec, which would be good. - Having the various attacks/critiques published in the RFC series would not be helpful. Currently, they are in peer-reviewed venues (e.g., IEEE Oakland) which do a better job of review than we do. Moreover, the academic community is where the conversation about the security of this type of protocol takes place. So, in this particular example, I don't actually think that the RFC series -- as opposed to the IETF -- is bringing that much to the party, -Ekr [0] One might argue that the process of turning the spec into an RFC would make it clearer. I'm note sure that's true; the spec is at about -00 level now. But in any case, if we think it would be good for specs to be clearer, we could pay to have them copy-edited inside or outside the RFC series. --0000000000009380690570558fef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 6, 2018 at 6:33 AM, John C Klensin <john-ie= tf@jck.com> wrote:


--On Friday, July 6, 2018 13:38 +0200 Eliot Lear
<lear=3D= 40cisco.com@dmarc.ietf.org> wrote:

>...
> The one benefit of the ISE doing any of this is that we get to > have a say about the work.=C2=A0 That's not nothing.=C2=A0 In
> addition, the work can be legible and freely available.=C2=A0 But,
> as discussed with EKR, other venues can serve that function.

There is one other benefit that I think we should not lose sight
of.=C2=A0 =C2=A0Over the years (including well before there was an IETF) "we" have presented the RFC Series as the go-to place for
technical specifications about what is used on the Internet.=C2=A0

Hmm... This seems to me to be true only if one has = a pretty narrow definition of "on the Internet". Here are a few e= xamples of things which get used on the Internet on a regular basis that ar= en't RFCs:

- HTML (WHATWG and/or W3C)
- JavaScript (TC39)
- H.264 (MPEG)
- JPEG
-= AES, P-256 (NIST)
- Bittorrent
- Tor

I spent a bunch of time trying to think of a characterization of th= e role of the RFC series (or the IETF's) role that was succinct, but in= truth I think we're part of a broad coaltion of people publishing Inte= rnet protocol specificationswith somewhat fuzzily defined boundaries betwee= n the areas of work.

=C2=A0
Let me give an example that lies a bit outside the crypto realm=C2=A0
and that may therefore be easier for = the rest of us to
understand.=C2=A0 Suppose the IETF adopts a protocol that is
carefully designed for maximum privacy.=C2=A0 =C2=A0Now suppose that
something comes along that is faster, lighter-weight, supported
or mandated by some governments but that protects privacy from
everyone but those governments (but leaves information
completely exposed to them).=C2=A0 =C2=A0 We can certainly ignore the
latter as just bad news but I contend we protect our reputation
and the privacy-safety of users, and make the Internet better,
far more by publishing its specs, explaining the vulnerabilities
it creates, and recommending against it unless one is actually
required to use it than by ignoring it.

This hypothetical contai= ns a number of things "we" might do (publish the spec, critique i= t, recommend against it). I don't think it's actually a particular = service to the world for us to publish the spec as long as it's readily= found by other means. It's not clear to me how that helps. I certainly= think critiquing it and recommending against it are good ideas (though dep= ending on the technology, perhaps making something that had the good proper= ties without the bad would be even better). It's not clear to me that h= aving those critiques in the RFC series is that helpful, though having the = IETF recommend against the protocol (whether that recommendation was in an = RFC or not) might well be.

With that said, this hypothetical isn't *that*= far off the mark. Tor is a privacy protocol better than anything in the IE= TF (though to the best of my knowledge it doesn't have the negative pro= perties of the protocol in your hypothetical). Its protocol is mostly defin= ed by the implementation although there's a not-particularly clear spec= . There are a pile of papers describing potential attacks. To the best of m= y knowledge, none of this is in the RFC series. From my perspective as a pr= otocol implementer:

- Having a good spec published would be valuable. Having = it in the RFC series would not be particularly helpful, though it would not= be harmful [0]
- Having an IETF standa= rd would probably be helpful depending on whether it improved Tor. It would= likely lead to a clearer spec, which would be good.
- Having the various attacks/critiques published in the RFC serie= s would not be helpful. Currently, they are in peer-reviewed venues (e.g., = IEEE Oakland) which do a better job of review than we do. Moreover, the aca= demic community is where the conversation about the security of this type o= f protocol takes place.

So, in this particular example, I don't actually thin= k that the RFC series -- as opposed to the IETF -- is bringing that much to= the party,

-Ekr

[0] One might argue that the process of turning the spec into an R= FC would make it clearer. I'm note sure that's true; the spec is at= about -00 level now. But in any case, if we think it would be good for spe= cs to be clearer, we could pay to have them copy-edited inside or outside t= he RFC series.
--0000000000009380690570558fef-- From nobody Fri Jul 6 07:40:43 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5104B130FC4 for ; Fri, 6 Jul 2018 07:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xi2PlcAoy4m4 for ; Fri, 6 Jul 2018 07:40:38 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11151130F1F for ; Fri, 6 Jul 2018 07:40:38 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id y203-v6so4252178ywd.9 for ; Fri, 06 Jul 2018 07:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FponHQuSdIVyAKH6XZtVG8zBm4gGYmv0HkAS7eLcmcY=; b=r8IGNviUJ/x4oXP+rkBlH4uFqUCB26AjZwncKI/jKEF3u3ZHdt4KyaQMZZ/l3uthMb LiZdqoJ+RHFUBfXCNoujdzl3ZtKsxt4LB+l35A5tyvNUWhD0/kRHc4Lfg2PhlUYdftF9 9DzmaThDFZffv6YI5AMYhjRyzmkHFeR/a1P/VxdfcsVzzhC83T3hz4obzn7WYcR71RDU ZZt+GJ4iwLjM16vA8yZ1htz36m+4ogbUOLCIkTyEd/dUlQLDHJ75sS6ntnhbSDSbjixt +vB+gNJAt+vhQkhMFLofB0fozwhKA9Zo7XgXk4B5hdZGYpwXdNwPyJgGL7/0st9UjFFH Cufw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FponHQuSdIVyAKH6XZtVG8zBm4gGYmv0HkAS7eLcmcY=; b=XSZGK12MxwsN+/L2qr2CivFr0c3gxABDe+5GQrVkuo3fintP4M4z4aTfmpuAM4QmUm BNJY2AnJ3kLbAgw9dQtOfuJ3yPU6yOLE2iztixTBCfaK+BMcJRkUXTtIxKpDsSAelGfO qohS+CEFGC7xlVduZtAD5Rqbr1eANhg/mKGx2Zk97cSvy9MyLEdnkh4Bco3iRs1Fhijd oJ5e18bK3kYzYq0u1WZQujIrPq2P8T/NHlGmwbhV1FrU/P1tR1qaNCcDa9S9GdMmOEma dVo1+e+tU7gvUgkUKR81wPKL5c3MMDDT0JDPt1rR/mJ5gvFJO1uI9aIhSAECdT4OpVdo wokQ== X-Gm-Message-State: APt69E04FU5OOCZd1z2f3prAXK/T8G+CB4F4FI5zuD+/7T5/MG8zeviN oxTYboA19xHivm+eABJBZ7wdbqaR1++yOENe0jWdrQ== X-Google-Smtp-Source: AAOMgpdP6igV97ErxLvlfbVGBpCwJi6xmTLR9HWk+LBtwTbEWvBxTdEb3G4Bwszz8jyEgEIsxKUnl9RiQ9e0oC/k8Gc= X-Received: by 2002:a81:918b:: with SMTP id i133-v6mr5163658ywg.175.1530888037316; Fri, 06 Jul 2018 07:40:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 07:39:56 -0700 (PDT) In-Reply-To: References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> From: Eric Rescorla Date: Fri, 6 Jul 2018 07:39:56 -0700 Message-ID: To: John C Klensin Cc: Eliot Lear , Kathleen Moriarty , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000a7d32f057055a51c" Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 14:40:42 -0000 --000000000000a7d32f057055a51c Content-Type: text/plain; charset="UTF-8" On Fri, Jul 6, 2018 at 7:33 AM, Eric Rescorla wrote: > On Fri, Jul 6, 2018 at 6:33 AM, John C Klensin wrote: > >> >> >> --On Friday, July 6, 2018 13:38 +0200 Eliot Lear >> wrote: >> >> >... >> > The one benefit of the ISE doing any of this is that we get to >> > have a say about the work. That's not nothing. In >> > addition, the work can be legible and freely available. But, >> > as discussed with EKR, other venues can serve that function. >> >> There is one other benefit that I think we should not lose sight >> of. Over the years (including well before there was an IETF) >> "we" have presented the RFC Series as the go-to place for >> technical specifications about what is used on the Internet. > > > Hmm... This seems to me to be true only if one has a pretty narrow > definition of "on the Internet". Here are a few examples of things which > get used on the Internet on a regular basis that aren't RFCs: > > - HTML (WHATWG and/or W3C) > I should have footnoted this: there is an HTML spec in the RFC series [RFC1866] but it's prehistoric and if you try to use it on the Web you're going to have a bad day. -Ekr - JavaScript (TC39) > - H.264 (MPEG) > - JPEG > - AES, P-256 (NIST) > - Bittorrent > - Tor > > I spent a bunch of time trying to think of a characterization of the role > of the RFC series (or the IETF's) role that was succinct, but in truth I > think we're part of a broad coaltion of people publishing Internet protocol > specificationswith somewhat fuzzily defined boundaries between the areas of > work. > > > >> Let me give an example that lies a bit outside the crypto realm > > and that may therefore be easier for the rest of us to >> understand. Suppose the IETF adopts a protocol that is >> carefully designed for maximum privacy. Now suppose that >> something comes along that is faster, lighter-weight, supported >> or mandated by some governments but that protects privacy from >> everyone but those governments (but leaves information >> completely exposed to them). We can certainly ignore the >> latter as just bad news but I contend we protect our reputation >> and the privacy-safety of users, and make the Internet better, >> far more by publishing its specs, explaining the vulnerabilities >> it creates, and recommending against it unless one is actually >> required to use it than by ignoring it. >> > > This hypothetical contains a number of things "we" might do (publish the > spec, critique it, recommend against it). I don't think it's actually a > particular service to the world for us to publish the spec as long as it's > readily found by other means. It's not clear to me how that helps. I > certainly think critiquing it and recommending against it are good ideas > (though depending on the technology, perhaps making something that had the > good properties without the bad would be even better). It's not clear to me > that having those critiques in the RFC series is that helpful, though > having the IETF recommend against the protocol (whether that recommendation > was in an RFC or not) might well be. > > With that said, this hypothetical isn't *that* far off the mark. Tor is a > privacy protocol better than anything in the IETF (though to the best of my > knowledge it doesn't have the negative properties of the protocol in your > hypothetical). Its protocol is mostly defined by the implementation > although there's a not-particularly clear spec. There are a pile of papers > describing potential attacks. To the best of my knowledge, none of this is > in the RFC series. From my perspective as a protocol implementer: > > - Having a good spec published would be valuable. Having it in the RFC > series would not be particularly helpful, though it would not be harmful [0] > - Having an IETF standard would probably be helpful depending on whether > it improved Tor. It would likely lead to a clearer spec, which would be > good. > - Having the various attacks/critiques published in the RFC series would > not be helpful. Currently, they are in peer-reviewed venues (e.g., IEEE > Oakland) which do a better job of review than we do. Moreover, the academic > community is where the conversation about the security of this type of > protocol takes place. > > So, in this particular example, I don't actually think that the RFC series > -- as opposed to the IETF -- is bringing that much to the party, > > -Ekr > > [0] One might argue that the process of turning the spec into an RFC would > make it clearer. I'm note sure that's true; the spec is at about -00 level > now. But in any case, if we think it would be good for specs to be clearer, > we could pay to have them copy-edited inside or outside the RFC series. > --000000000000a7d32f057055a51c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 6, 2018 at 7:33 AM, Eric Rescorla <ekr@rtfm.com> = wrote:
= On Fri, Jul 6, 2018 at 6:33 AM, John C Klensin <john-ietf@jck.com><= /span> wrote:


--On Friday, July 6, 2018 13:38 +0200 Eliot Lear
<lear=3D= 40cisco.com@dmarc.ietf.org> wrote:

>...
> The one benefit of the ISE doing any of this is that we get to > have a say about the work.=C2=A0 That's not nothing.=C2=A0 In
> addition, the work can be legible and freely available.=C2=A0 But,
> as discussed with EKR, other venues can serve that function.

There is one other benefit that I think we should not lose sight
of.=C2=A0 =C2=A0Over the years (including well before there was an IETF) "we" have presented the RFC Series as the go-to place for
technical specifications about what is used on the Internet.=C2=A0

Hmm... This seems to me to be true only if o= ne has a pretty narrow definition of "on the Internet". Here are = a few examples of things which get used on the Internet on a regular basis = that aren't RFCs:

- HTML (WHATWG and/or W3C)

I should have footno= ted this: there is an HTML spec in the RFC series [RFC1866] but it's pr= ehistoric and if you try to use it on the Web you're going to have a ba= d day.

-Ekr


- JavaScript (TC39)
- H.264 (MP= EG)
- JPEG
- AES, P-256 (NIST)
- Bittorrent
- Tor

I spent a bunch of time trying to t= hink of a characterization of the role of the RFC series (or the IETF's= ) role that was succinct, but in truth I think we're part of a broad co= altion of people publishing Internet protocol specificationswith somewhat f= uzzily defined boundaries between the areas of work.

=C2=A0
Let me give an example that lies a bit outside the crypto realm=C2=A0
and that may therefore be easier for = the rest of us to
understand.=C2=A0 Suppose the IETF adopts a protocol that is
carefully designed for maximum privacy.=C2=A0 =C2=A0Now suppose that
something comes along that is faster, lighter-weight, supported
or mandated by some governments but that protects privacy from
everyone but those governments (but leaves information
completely exposed to them).=C2=A0 =C2=A0 We can certainly ignore the
latter as just bad news but I contend we protect our reputation
and the privacy-safety of users, and make the Internet better,
far more by publishing its specs, explaining the vulnerabilities
it creates, and recommending against it unless one is actually
required to use it than by ignoring it.

This hypothetical= contains a number of things "we" might do (publish the spec, cri= tique it, recommend against it). I don't think it's actually a part= icular service to the world for us to publish the spec as long as it's = readily found by other means. It's not clear to me how that helps. I ce= rtainly think critiquing it and recommending against it are good ideas (tho= ugh depending on the technology, perhaps making something that had the good= properties without the bad would be even better). It's not clear to me= that having those critiques in the RFC series is that helpful, though havi= ng the IETF recommend against the protocol (whether that recommendation was= in an RFC or not) might well be.

<= /div>
With that said, this hypothetical isn't= *that* far off the mark. Tor is a privacy protocol better than anything in= the IETF (though to the best of my knowledge it doesn't have the negat= ive properties of the protocol in your hypothetical). Its protocol is mostl= y defined by the implementation although there's a not-particularly cle= ar spec. There are a pile of papers describing potential attacks. To the be= st of my knowledge, none of this is in the RFC series. From my perspective = as a protocol implementer:

- Having a good spec published would be valuable. = Having it in the RFC series would not be particularly helpful, though it wo= uld not be harmful [0]
- Having an IETF= standard would probably be helpful depending on whether it improved Tor. I= t would likely lead to a clearer spec, which would be good.
- Having the various attacks/critiques published in the RF= C series would not be helpful. Currently, they are in peer-reviewed venues = (e.g., IEEE Oakland) which do a better job of review than we do. Moreover, = the academic community is where the conversation about the security of this= type of protocol takes place.

So, in this particular example, I don't actual= ly think that the RFC series -- as opposed to the IETF -- is bringing that = much to the party,

-Ekr

[0] One might argue that the process of turning the spec i= nto an RFC would make it clearer. I'm note sure that's true; the sp= ec is at about -00 level now. But in any case, if we think it would be good= for specs to be clearer, we could pay to have them copy-edited inside or o= utside the RFC series.

--000000000000a7d32f057055a51c-- From nobody Fri Jul 6 08:57:08 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FD3130FFE for ; Fri, 6 Jul 2018 08:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 bShlayFp8fB2 for ; Fri, 6 Jul 2018 08:57:04 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52496130E6E for ; Fri, 6 Jul 2018 08:57:04 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id y207-v6so24321827oie.13 for ; Fri, 06 Jul 2018 08:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xs7aB/GMd8ykvb4L4xPgQ5kTwEhGjoiNGnFRecafrJQ=; b=mS5dyepl2f4Y+Gul6CG/eFDTaWyvM2AZr+m4EC3v5ejEozjDG8rI4/JZInxXyi+UzW aMMsgETjHsEfHwJ/USaT6ulZvPmNMQIqez3AruP8iXiMYxFxme7ixWcwyPFaxF7pF0fN psSjYZZYg7OzAbF69qDSj7ayNc6RMVi1dVTLinaBW+9g0UraXXWQqHcUmR2RD3ZFMiOV x0A2+KNtUZNjUrVw4zNNH9y189QVPK5JRtun+JuIL/2X4PuKoe9PmNOfslcwdft0HMX0 AKN3nOMfrxgFDQ5TzeJ/WpY6AVRZZzXdMZY1C2ZcvviZ6xAr/5VMFXXONkyvihas1W3j bCtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xs7aB/GMd8ykvb4L4xPgQ5kTwEhGjoiNGnFRecafrJQ=; b=ZgCtkcDtHslHNA0Q55HY+jmAL20/Pz4ZGppvM047fspsbA7Cru2TZuvplLUVB4StJ8 hd3RohFn4PE7Nk36/G397UCKcVAiP1ncFwhYXkNd3M/lyqPfDwXFi4sHoEmpQfmKmdgq RAhJoaP3+M68C81zDQmp/qT/6lfpJwOLST5G8HuW9BvPAimlMF31hfMBWmkPMJmHQ6Mp Zd6uTB8urRsXVLl484UIO75EVsFnYx4tKabbzYaVpogkm/OgAKOE0ziqJsZ+cFdbxaHO wcOEeLsnkL6Ctav+TDn3hblViKe6QImiA4+N974shC/XOJaReprL6ChxHreGR312voVR hSAw== X-Gm-Message-State: APt69E2rMd/sOKaZI9uThjYxGM36a7LAvXNB2uUmQWZN5SDVtFXkpl1z 7UF1UCjxCGljEvq6U/PunM2WuZM5aSg3jGKPdJA= X-Google-Smtp-Source: AAOMgpfTNkTJ8s19v+uBNp4xYbdNoQ0IWDsFx3xQU/3OMdtuUfiX0zScqxbDHpkQiJjYT839Fak78d99USAH19eqpA8= X-Received: by 2002:aca:6287:: with SMTP id w129-v6mr12788520oib.122.1530892623487; Fri, 06 Jul 2018 08:57:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 08:56:32 -0700 (PDT) In-Reply-To: <500C011C761A520733E47438@PSB> References: <3044F577-E367-44D5-BCE0-DE1E29EE6C13@cooperw.in> <500C011C761A520733E47438@PSB> From: Ted Hardie Date: Fri, 6 Jul 2018 15:56:32 +0000 Message-ID: To: John C Klensin Cc: Brian E Carpenter , Alissa Cooper , "Andrew G. Malis" , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000000327d7057056b77f" Archived-At: Subject: Re: [Rfcplusplus] draft-thomson-rfcplusplus-label-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 15:57:07 -0000 --0000000000000327d7057056b77f Content-Type: text/plain; charset="UTF-8" On Wed, Jul 4, 2018 at 7:13 AM, John C Klensin wrote: > > There are several mechanisms out there called "impact scores". > There is also a lot of literature about why they are lousy > measures of what they allegedly measure, but they are wildly > popular among counters of beans, academic promotion committees, > etc., precisely because they provide quantitative, > interval-scale, measures that are easily compared. Just to add to this that there may be more than one impact score associated with the same series. As was noted earlier, the impact of the RFC Series is not that high in academic circles, and that has a follow-on impact on the IRTF. Ted > By those > measures, the RFC Series does fairly well if only because there > are lots and lots of references around to technical standards > for the Internet. In a way, they are the quantitative > reflection of "strong brand". Now if one splits things off into > different pieces, maybe the scores for the RFC Series actually > go up because documents that might be important but are not > widely references are somewhere else. However, if one examines > those other collections three years down the line, they are > likely to have scores in the "why should we bother with that or > support our employees in writing such things" range. There may > be good (and bad) reasons for breaking things up, but at least > on that dimension, I'd predict negative outcomes for any new and > more narrowly focused series. > > best, > john > > --0000000000000327d7057056b77f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 4, 2018 at 7:13 AM, John C Klensin <john-ie= tf@jck.com> wrote:

There are several mechanisms out there called "impact scores". There is also a lot of literature about why they are lousy
measures of what they allegedly measure, but they are wildly
popular among counters of beans, academic promotion committees,
etc., precisely because they provide quantitative,
interval-scale, measures that are easily compared.=C2=A0 =C2=A0

Just to add to this that there may be more than one im= pact score associated with the same series.=C2=A0 As was noted earlier, the= impact of the RFC Series is not that high in academic circles, and that ha= s a follow-on impact on the IRTF.

Ted

=C2=A0
By those
measures, the RFC Series does fairly well if only because there
are lots and lots of references around to technical standards
for the Internet.=C2=A0 In a way, they are the quantitative
reflection of "strong brand".=C2=A0 Now if one splits things off = into
different pieces, maybe the scores for the RFC Series actually
go up because documents that might be important but are not
widely references are somewhere else.=C2=A0 However, if one examines
those other collections three years down the line, they are
likely to have scores in the "why should we bother with that or
support our employees in writing such things" range.=C2=A0 There may be good (and bad) reasons for breaking things up, but at least
on that dimension, I'd predict negative outcomes for any new and
more narrowly focused series.

best,
=C2=A0 =C2=A0john


--0000000000000327d7057056b77f-- From nobody Fri Jul 6 14:04:40 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E40130F4F for ; Fri, 6 Jul 2018 14:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FD_B4xiWibB for ; Fri, 6 Jul 2018 14:04:36 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 F04F0130DDC for ; Fri, 6 Jul 2018 14:04:35 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id b15-v6so25816123oib.10 for ; Fri, 06 Jul 2018 14:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3xlIZvAh886pPDDV/agjnyLJUOJ7uoK135SInQn8Lcw=; b=BZQA6N027RKXg0nIA5aT30mb9USPHm/NGf9+g8wxZnCTCOAu7B3EFmsT2Qzp82MFrx URoO9vM/xW8UFWj13WpQftpgyXuZtrfbwJHgg0r3QMYwDVJAcV8WbydWcuN0alY1dhEe A4iw/L3p62/HjeijuI5GergVMAfl0mOfw1tmbqX7MJdQ5ArArFLUJ6mDTOvRwpQ6H3uN GpGI+dhu/oQoc2+1pYliE8DC18gOB63+0bH3VMUMTz83aa8bx5AIFvfuXzGXki4bGUxT xD3nEtL78BSlpR28F7BUQcEo2ZQzD+7uRYkEP3kTyidpnhD841HdHutRb2VsIIvFH79I O93Q== 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=3xlIZvAh886pPDDV/agjnyLJUOJ7uoK135SInQn8Lcw=; b=NcwaMfbUcLSh9e6ijfWwRuIxBQu0f+lbippnlGLxbqudjqlqs5N5n+b8xPSqJ7B0du 54SNElgMPqyvBGK0P0ycZTJAH+0l7LhcmijIxfW+WJWUFF7bdOrJv5sMXRs2fpHTLaPO kx4esItJ+GuxxuCRPM+cJORo7rnxf8OV2ynLd6ZkERBkICi98OJ6faSqutKsvWc9nkUg GX7FPxiGE1nIuEQnzdQbeTJRsPIQDtRr1zPQWfbD7d02XAa0ej6MyzQZFcNjVPu+DWPG 4rcNi6f61KwUqXAGLAE8XO5NW9lZBXYUVN6+byhTzGoltN6iVcN8DCFW1x4ZfZ/tTjNa oOHA== X-Gm-Message-State: APt69E3g6hG/4tXH17HC+0qqq0dYJ5kWLDMUixfPKpZbnin3aHamByPL 6MgbteVjrPAoeJZHA2ur9h0bDqyue0IbGOfOyO7Vnw== X-Google-Smtp-Source: AAOMgpeNv4iuEXoN+CNWo919/0y3SRLCqCAL7zyreb36Rg2WGeca9cdwoVqQgWjUYY8G/HzupV+c6ofHdc5lzAhpTik= X-Received: by 2002:aca:3002:: with SMTP id w2-v6mr12040271oiw.29.1530911075231; Fri, 06 Jul 2018 14:04:35 -0700 (PDT) MIME-Version: 1.0 References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> In-Reply-To: From: Richard Barnes Date: Fri, 6 Jul 2018 17:04:23 -0400 Message-ID: To: Eric Rescorla Cc: John C Klensin , Kathleen Moriarty , lear=40cisco.com@dmarc.ietf.org, rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000d27abf05705b02f4" Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 21:04:40 -0000 --000000000000d27abf05705b02f4 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 6, 2018 at 10:40 AM Eric Rescorla wrote: > > > On Fri, Jul 6, 2018 at 7:33 AM, Eric Rescorla wrote: > >> On Fri, Jul 6, 2018 at 6:33 AM, John C Klensin wrote: >> >>> >>> >>> --On Friday, July 6, 2018 13:38 +0200 Eliot Lear >>> wrote: >>> >>> >... >>> > The one benefit of the ISE doing any of this is that we get to >>> > have a say about the work. That's not nothing. In >>> > addition, the work can be legible and freely available. But, >>> > as discussed with EKR, other venues can serve that function. >>> >>> There is one other benefit that I think we should not lose sight >>> of. Over the years (including well before there was an IETF) >>> "we" have presented the RFC Series as the go-to place for >>> technical specifications about what is used on the Internet. >> >> >> Hmm... This seems to me to be true only if one has a pretty narrow >> definition of "on the Internet". Here are a few examples of things which >> get used on the Internet on a regular basis that aren't RFCs: >> >> - HTML (WHATWG and/or W3C) >> > > I should have footnoted this: there is an HTML spec in the RFC series > [RFC1866] but it's prehistoric > I don't **think** that's one of the labels we have today. But there's a lot of them, so I might be wrong. --Richard > and if you try to use it on the Web you're going to have a bad day. > > -Ekr > > > - JavaScript (TC39) >> - H.264 (MPEG) >> - JPEG >> - AES, P-256 (NIST) >> - Bittorrent >> - Tor >> >> I spent a bunch of time trying to think of a characterization of the role >> of the RFC series (or the IETF's) role that was succinct, but in truth I >> think we're part of a broad coaltion of people publishing Internet protocol >> specificationswith somewhat fuzzily defined boundaries between the areas of >> work. >> >> >> >>> Let me give an example that lies a bit outside the crypto realm >> >> and that may therefore be easier for the rest of us to >>> understand. Suppose the IETF adopts a protocol that is >>> carefully designed for maximum privacy. Now suppose that >>> something comes along that is faster, lighter-weight, supported >>> or mandated by some governments but that protects privacy from >>> everyone but those governments (but leaves information >>> completely exposed to them). We can certainly ignore the >>> latter as just bad news but I contend we protect our reputation >>> and the privacy-safety of users, and make the Internet better, >>> far more by publishing its specs, explaining the vulnerabilities >>> it creates, and recommending against it unless one is actually >>> required to use it than by ignoring it. >>> >> >> This hypothetical contains a number of things "we" might do (publish the >> spec, critique it, recommend against it). I don't think it's actually a >> particular service to the world for us to publish the spec as long as it's >> readily found by other means. It's not clear to me how that helps. I >> certainly think critiquing it and recommending against it are good ideas >> (though depending on the technology, perhaps making something that had the >> good properties without the bad would be even better). It's not clear to me >> that having those critiques in the RFC series is that helpful, though >> having the IETF recommend against the protocol (whether that recommendation >> was in an RFC or not) might well be. >> >> With that said, this hypothetical isn't *that* far off the mark. Tor is a >> privacy protocol better than anything in the IETF (though to the best of my >> knowledge it doesn't have the negative properties of the protocol in your >> hypothetical). Its protocol is mostly defined by the implementation >> although there's a not-particularly clear spec. There are a pile of papers >> describing potential attacks. To the best of my knowledge, none of this is >> in the RFC series. From my perspective as a protocol implementer: >> >> - Having a good spec published would be valuable. Having it in the RFC >> series would not be particularly helpful, though it would not be harmful [0] >> - Having an IETF standard would probably be helpful depending on whether >> it improved Tor. It would likely lead to a clearer spec, which would be >> good. >> - Having the various attacks/critiques published in the RFC series would >> not be helpful. Currently, they are in peer-reviewed venues (e.g., IEEE >> Oakland) which do a better job of review than we do. Moreover, the academic >> community is where the conversation about the security of this type of >> protocol takes place. >> >> So, in this particular example, I don't actually think that the RFC >> series -- as opposed to the IETF -- is bringing that much to the party, >> >> -Ekr >> >> [0] One might argue that the process of turning the spec into an RFC >> would make it clearer. I'm note sure that's true; the spec is at about -00 >> level now. But in any case, if we think it would be good for specs to be >> clearer, we could pay to have them copy-edited inside or outside the RFC >> series. >> > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --000000000000d27abf05705b02f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Jul 6, 2018 at 10:40 AM Eric Rescorla <ekr@rtfm.com> wrote:


On= Fri, Jul 6, 2018 at 7:33 AM, Eric Rescorla <ekr@rtfm.com> wrot= e:
On Fri, Jul 6, = 2018 at 6:33 AM, John C Klensin <john-ietf@jck.com> wrote:


--On Friday, July 6, 2018 13:38 +0200 Eliot Lear
<lear=3D= 40cisco.com@dmarc.ietf.org> wrote:

>...
> The one benefit of the ISE doing any of this is that we get to > have a say about the work.=C2=A0 That's not nothing.=C2=A0 In
> addition, the work can be legible and freely available.=C2=A0 But,
> as discussed with EKR, other venues can serve that function.

There is one other benefit that I think we should not lose sight
of.=C2=A0 =C2=A0Over the years (including well before there was an IETF) "we" have presented the RFC Series as the go-to place for
technical specifications about what is used on the Internet.=C2=A0

Hmm... This seems to me to be true only if o= ne has a pretty narrow definition of "on the Internet". Here are = a few examples of things which get used on the Internet on a regular basis = that aren't RFCs:

- HTML (WHATWG and/or W3C)

I should have footno= ted this: there is an HTML spec in the RFC series [RFC1866] but it's pr= ehistoric

I don= 9;t **think** that's one of the labels we have today.=C2=A0 But there&#= 39;s a lot of them, so I might be wrong.

--Richard=

=C2=A0
a= nd if you try to use it on the Web you're going to have a bad day.
<= /div>

-Ekr


- JavaScript (TC39)
- H.264 (MPEG)
- JPEG
- AES, P-256 (NIST)
- Bittorrent
- = Tor

I spent a bunch of time trying to think of a c= haracterization of the role of the RFC series (or the IETF's) role that= was succinct, but in truth I think we're part of a broad coaltion of p= eople publishing Internet protocol specificationswith somewhat fuzzily defi= ned boundaries between the areas of work.

=C2=A0
Let me give an example that lies a bit outside the crypto realm=C2=A0
and that may therefore be easier for = the rest of us to
understand.=C2=A0 Suppose the IETF adopts a protocol that is
carefully designed for maximum privacy.=C2=A0 =C2=A0Now suppose that
something comes along that is faster, lighter-weight, supported
or mandated by some governments but that protects privacy from
everyone but those governments (but leaves information
completely exposed to them).=C2=A0 =C2=A0 We can certainly ignore the
latter as just bad news but I contend we protect our reputation
and the privacy-safety of users, and make the Internet better,
far more by publishing its specs, explaining the vulnerabilities
it creates, and recommending against it unless one is actually
required to use it than by ignoring it.

This hypothetical= contains a number of things "we" might do (publish the spec, cri= tique it, recommend against it). I don't think it's actually a part= icular service to the world for us to publish the spec as long as it's = readily found by other means. It's not clear to me how that helps. I ce= rtainly think critiquing it and recommending against it are good ideas (tho= ugh depending on the technology, perhaps making something that had the good= properties without the bad would be even better). It's not clear to me= that having those critiques in the RFC series is that helpful, though havi= ng the IETF recommend against the protocol (whether that recommendation was= in an RFC or not) might well be.

<= /div>
With that said, this hypothetical isn't= *that* far off the mark. Tor is a privacy protocol better than anything in= the IETF (though to the best of my knowledge it doesn't have the negat= ive properties of the protocol in your hypothetical). Its protocol is mostl= y defined by the implementation although there's a not-particularly cle= ar spec. There are a pile of papers describing potential attacks. To the be= st of my knowledge, none of this is in the RFC series. From my perspective = as a protocol implementer:

- Having a good spec published would be valuable. = Having it in the RFC series would not be particularly helpful, though it wo= uld not be harmful [0]
- Having an IETF= standard would probably be helpful depending on whether it improved Tor. I= t would likely lead to a clearer spec, which would be good.
- Having the various attacks/critiques published in the RF= C series would not be helpful. Currently, they are in peer-reviewed venues = (e.g., IEEE Oakland) which do a better job of review than we do. Moreover, = the academic community is where the conversation about the security of this= type of protocol takes place.

So, in this particular example, I don't actual= ly think that the RFC series -- as opposed to the IETF -- is bringing that = much to the party,

-Ekr

[0] One might argue that the process of turning the spec i= nto an RFC would make it clearer. I'm note sure that's true; the sp= ec is at about -00 level now. But in any case, if we think it would be good= for specs to be clearer, we could pay to have them copy-edited inside or o= utside the RFC series.

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusplus
--000000000000d27abf05705b02f4-- From nobody Fri Jul 6 15:12:19 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EF6131062 for ; Fri, 6 Jul 2018 15:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 vhcWUZsXeiVF for ; Fri, 6 Jul 2018 15:12:15 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB93E131064 for ; Fri, 6 Jul 2018 15:12:13 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id 30-v6so3425930pld.13 for ; Fri, 06 Jul 2018 15:12:13 -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=9IwJEYbZM3b3GfIuL6S82CYZqiNqEU6Sc1PzBZjCdh8=; b=VKQrgvA105CdZxWSY5nOMjFuTv8EkoHaUnTwEtVPiYgYE/IrDEfSOEqVqVhYfMvP3L N48aYfWFcTKM1CrxuCplSDLmfACMiFC7UILING999GDD5NisY5eKRb1O5Ak9i/WR8OIV 7yoTpvGxyWXIxCEEQd+rq3Gqx70ccsW11Qkd+tGH70DNAAUnRA7ZGu10/y5IFvMi6Z2V MBgfAscvtacWy2PKwRYGoPvMSPPup8Cu8UGLiX5i8ixX8GkEwdL8Zm29a1cFBX4b2+XK zCR7+A7+WUxaEcjO4ZhupTxJZhNs+ri3CKVcjOF5PONOkTGfApioHMdT3AN6rt53kTiI SOeQ== 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=9IwJEYbZM3b3GfIuL6S82CYZqiNqEU6Sc1PzBZjCdh8=; b=sEVX0hLl4wwNB5FExlBBl689BHlc1xtMXaWJQO1RavgxE2SLrOWPCr+3/3ZqAZbBKI Z2arSEZaHFbqEdyl51FTsNoBoEy6NN3C3hOf6D0tlCT0qVbUtuPQa51zVxIUQSSvCwe0 MZjI+XUfPzAPxsKJb1WnFhGsx2JdmKVolHzpKOlhI/IU0M4ZU3oLKc0QNWjB4yti5jFQ sDsJ6aHWJWiKBsJbR6PPrH6Aa1e3NVay8LNjW/K1R/kbwKic1zUZ2rSfahMf6sz02iRu vzbQqCYMYF/n1L2ZnvAKasRinU2WnBlf8pGFTW2kAvLBoxthRmUlXsGBjNe51w02+4jX OrOA== X-Gm-Message-State: APt69E1D4xCJvPq6JCygCRMlrIByBQqwdUhKsGjbZIHcJ7v5MuoCwGlU H47rqbKaTFCvEJk+HS3BXEhi4A== X-Google-Smtp-Source: AAOMgpd96iJfjXgmsK8xLqulYeC/qGOKsLPwPAa91QJa/EeoJ+8TVQWnjsIZT8IoeNY0BMaG0GcZEw== X-Received: by 2002:a17:902:9307:: with SMTP id bc7-v6mr11784502plb.292.1530915132967; Fri, 06 Jul 2018 15:12:12 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id z8-v6sm16069051pfg.24.2018.07.06.15.12.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 15:12:12 -0700 (PDT) To: rfcplusplus@ietf.org References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> From: Brian E Carpenter Message-ID: Date: Sat, 7 Jul 2018 10:12:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 22:12:18 -0000 On 07/07/2018 01:33, Alissa Cooper wrote: >=20 >=20 >> On Jul 4, 2018, at 3:56 AM, Adrian Farrel wrote:= >> >> Buried in this thread there was... >> >>>> As opposed to publication as FOO 7974, that is. >>> >>> [Med] I'm not sure about the possible implication on documents review= , but I >>> don't see much difference except reducing the page count as the notes= >>> mentioned above are likely to be deleted because this will be implied= by the FOO >>> label itself. >> >> That's an interesting point. >> >> Suppose a document contained the specification of a protocol that comp= eted with an IETF consensus protocol. Suppose further that implementation= of the specified protocol likely caused negative interactions with the I= ETF consensus protocol and so risked the stability of the Internet. >> >> - Where the document is in the IETF stream, we know how to handle it. >> - Where the document is in the IRTF or Independent Streams we have a >> time-tested mechanism and (I think) no evidence of harm through >> publication. >> - If the IRTF and Independent Stream documents became FOO and BAR=20 >> documents, we would need to understand what control/input the IESG >> expected to have. >> - If the publication is moved to another venue, the only thing the IES= G >> can do is plead or bang shoes on tables. >> >> There seems to be an correlation: the closer to looking like an IETF c= onsensus document, the more IESG input. >=20 > I agree with this conclusion, modulo the ability for liaison statements= and cross-participation in other venues to have an influence on what get= s published in other venues. All of the above seems to be by design.=20 >=20 >> >> Now, it might be thought (this is possibly a branding thing) that the = further from looking like an IETF consensus document the less we have to = care about the "protocol conflict problem", but I would argue that the le= ss input the IESG has, the more we have to worry. Thus, were an alternati= ve venue for publishing competing specifications to be developed, I would= claim that this is harmful to the RFC band and to both the IETF's brand = and raison d'=C3=AAtre.=20 >=20 > I=E2=80=99m not following this. If someone cares about how the Internet= works, then having a poorly designed specification that risks the Intern= et=E2=80=99s stability published in any venue is a problem. That doesn=E2= =80=99t mean the IESG or any individual participant is necessarily going = to be able to address that problem, but it=E2=80=99s still a problem. Hav= ing that specification labeled with =E2=80=9CRFC=E2=80=9D means the IESG = and the IETF face the potential additional problem of having the specific= ation confused for an IETF consensus output. Ultimately the IESG and the IETF don't matter, and in particular our prid= e doesn't matter in the least. What matters is whether the Internet works= better or works worse as the result of a particular document being publi= shed. What a number of us here are saying is that document labels are lar= gely irrelevant to that question. Implementers and operators do what *the= y* think is best for the Internet, and very often that doesn't include re= ading the labels or boilerplate on documents. =20 > Alternative venues for publishing competing specifications already exis= t (e.g., https://url.spec.whatwg.org/ ). Th= ey may or may not be harmful to the Internet, but I don=E2=80=99t see how= they=E2=80=99re specifically harmful to the RFC brand. They=E2=80=99re c= ertainly not more harmful to the RFC brand than competing specifications = labeled =E2=80=9CRFC." That depends on what you think the value of the "Request for Comments" br= and is. I think it's the fact that it says right up front that the docume= nt is tentative, might be wrong, and needs to be read critically and comm= ented upon. And for those in the know, that it comes from one section or = another of the wider Internet technical community after open peer review.= If that isn't how the IETF wants its standards to be branded, that's fine= , but it means starting a new series for IETF standards that doesn't bear= the label "Request for Comments". Unfortunately we can't call them "IS" = because that's already taken. Brian From nobody Fri Jul 6 15:52:18 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1431C13106B for ; Fri, 6 Jul 2018 15:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 DTS3ERZSVbp5 for ; Fri, 6 Jul 2018 15:52:14 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 5458A131064 for ; Fri, 6 Jul 2018 15:52:14 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id 81-v6so4720690ywb.6 for ; Fri, 06 Jul 2018 15:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L1KNg9z4cptrPbGbiR5JbMj5jQTk8mG82Exe8i9ItNw=; b=Ue3Zvroes66GDSXU+DCCUVCeL86XcsmvHX3l4SwJ93/c7qTxxdsN/FtyF6r4ylyC3I 6YGEPvvNLLh2El2a/2VGeencnbY5SFQO7g21ejVLlETXvzqbmFiJ14LkQDiMMnEip4pN mcr6fkHTCnsXNkPLumXlCE08gfuVRP1gorCEeDbFTMaq/hdBVB9WuJBaT6LDG5EgfPfE +F/zBcMusv0fBm6QBG3bHxtVThRrDrgIZSBcNh/A/F5kx1fxJpGl+elAXnvGQLBjnWFv ePFa8vec0nscUOcW/1TQbG/OuB6o/D7KQvI6ic/yZ+EfjvF/t9jN+EFsFxmkEuI4bX+a TT6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L1KNg9z4cptrPbGbiR5JbMj5jQTk8mG82Exe8i9ItNw=; b=Dck4MBEGlLT03IWqjCTWKtiVWK3cRVelZsd9zdPinsEQr/UNl23aQ8phxC7ewU1b4F hEwic5XargQC46ow+TsW/0VCttFsDtQQlChkjX0IeTJ5mOCYuORpeC2j3ZOPDD7OMfDD 8tCMVLW/McLfg/2f697Gl4xiN0P3pwFfqGuEbO/n5fLUPAT9+cyOm8vXwYHGR/ZR9hBv GuzZbeSHnRNkv34swnBfEf/a3hCtn+7wJ1u/fv5nlImQthI9RI7RcYOjapNY8Z24MLDl FiE7pxJpwvQjsJRvZBJM7rNk88N5vGdNjVCfMiRguUHNLjf2GHiNl57d7TlWCvXRlny6 klAQ== X-Gm-Message-State: APt69E3mC07O9ASGpaeAG5JzoePboU3ryht0niDOdfuSqQ5YsxCtPe9x iOgcsSj9/dfFN1BxO5MZpAUJYKDOC5ZIKMu4w8RVAg== X-Google-Smtp-Source: AAOMgpd8wgg/UEBkOg5oHE7QsYXJo2zHNXMtZWCwD7ZvitfyJ5QwibxTOdK3j0Ei5Bzi3/3R5Mm/Kw26XYHAKV/zTKg= X-Received: by 2002:a0d:f286:: with SMTP id b128-v6mr5763844ywf.489.1530917533501; Fri, 06 Jul 2018 15:52:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 15:51:32 -0700 (PDT) In-Reply-To: References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> From: Eric Rescorla Date: Fri, 6 Jul 2018 15:51:32 -0700 Message-ID: To: Brian E Carpenter Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000c3e04305705c8346" Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 22:52:17 -0000 --000000000000c3e04305705c8346 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 6, 2018 at 3:12 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > That depends on what you think the value of the "Request for Comments" > brand is. I think it's the fact that it says right up front that the > document is tentative, might be wrong, and needs to be read critically and > commented upon. And for those in the know, that it comes from one section > or another of the wider Internet technical community after open peer review. > I want to focus on this point a bit, as I've heard it a few times. I recognize that formally "RFC" stands for "Request for Comments", but my suspicion is that at this point it's much more like "laser" or 'scuba", i.e., it's an acronym but people don't bother to think of the expansion at all but just chunk it as a name. As I said, it's just my opinion, but I'd be interested in any evidence you have that the broader community thinks otherwise. -Ekr --000000000000c3e04305705c8346 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 6, 2018 at 3:12 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
That dep= ends on what you think the value of the "Request for Comments" br= and is. I think it's the fact that it says right up front that the docu= ment is tentative, might be wrong, and needs to be read critically and comm= ented upon. And for those in the know, that it comes from one section or an= other of the wider Internet technical community after open peer review.
=

I want to focus on this point a bit, as I&= #39;ve heard it a few times. I recognize that formally "RFC" stan= ds for "Request for Comments", but my suspicion is that at this p= oint it's much more like "laser" or 'scuba", i.e., i= t's an acronym but people don't bother to think of the expansion at= all but just chunk it as a name. As I said, it's just my opinion, but = I'd be interested in any evidence you have that the broader community t= hinks otherwise.

-Ekr


--000000000000c3e04305705c8346-- From nobody Fri Jul 6 16:08:19 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FB6130EA7 for ; Fri, 6 Jul 2018 16:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 PEliKryFjhJL for ; Fri, 6 Jul 2018 16:08:16 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D30124D68 for ; Fri, 6 Jul 2018 16:08:15 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id t79-v6so7123496qke.4 for ; Fri, 06 Jul 2018 16:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KJx6Z8zbfWbIDgMMraTXpAK/lhVFtJd73L8MLXdY3II=; b=h8lyc+U4towcWPg4KU9V1VBW/FUZ7uroi6yPbRA82Pls7w9pwgG25xty47jyIaJ3G/ l50IxZfLgvuICxbJ0I+wUBTlecrdQmUqQU9FDkW6wHGlPYZxu0s2XiSds7AhoOmKvwC2 /w4BZmZoy5KLtIx7fpnsgw9URrzFcdhUDEBKzYWSS0yRUglqE6Xi4NRYF0oPh4lsz03S 7S9WtyKIkHoAeTSRKJzz52HgMlMeexqXM7181jc6QlZZrHTzhypEyTNghnkYGr84i3Gb AP7WXIcd+USdGC0M+9bdwQ7uK5APgRlLQ/j02FzsjgarrrPElCPTByaH2otWyZtqSfuq zuDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KJx6Z8zbfWbIDgMMraTXpAK/lhVFtJd73L8MLXdY3II=; b=MMqjACzZIvSC9L3Dd2vrZSVAG23X7y1rk7oDfGHhwvvxXi/JkSyrSn+ircK95inmiT pkg9sPTq3kRcY/qqwubalI5Aqv8MsBu9ipS9+K2P7Lw61Q16KaI8YxAhWppQ35rD/hsS wKN9Wz/NL3G5QYrkbT4FSnNIaziqFiyE40IrBLoTie8W8/JSnml08uJwWVjUPWRIrCLC e/braHTyJndee8tUGWB8dJ7uEX6faBf2Jkxap9qqBAlh4I+Dwr7TfCKIipB8Wk6r7b1d M8byT2Zr3hgvrP8XAuDQn6PsbMUglnFNQeDw2RBo3WkCBD/gePuL+gDjX2aHZiv7mSzn cViA== X-Gm-Message-State: APt69E3ewOQtsVmhOpY68ODZTDkPsjkH2qs5v4yI7re+f9drv15+LyGt 9IXaMXYlP1kXvgZ96gm2U763U1Xw X-Google-Smtp-Source: AAOMgpfmUBoCdaF2YJqZiMv50bQsHiHmux0ZqEo0KVQoTOF3i5Zjid85h1Hq8YtEf+FHralqfbh5TQ== X-Received: by 2002:a37:4792:: with SMTP id u140-v6mr10573384qka.100.1530918494858; Fri, 06 Jul 2018 16:08:14 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id c93-v6sm9064308qkh.90.2018.07.06.16.08.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 16:08:14 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-809B725F-D2BA-462D-955E-6FBF83A79E56 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Fri, 6 Jul 2018 19:08:13 -0400 Cc: Brian E Carpenter , rfcplusplus@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <71A34570-1974-45A4-90AA-C74E4784D50C@gmail.com> References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> To: Eric Rescorla Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 23:08:19 -0000 --Apple-Mail-809B725F-D2BA-462D-955E-6FBF83A79E56 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my mobile device > On Jul 6, 2018, at 6:51 PM, Eric Rescorla wrote: >=20 >> On Fri, Jul 6, 2018 at 3:12 PM, Brian E Carpenter wrote: >> That depends on what you think the value of the "Request for Comments" br= and is. I think it's the fact that it says right up front that the document i= s tentative, might be wrong, and needs to be read critically and commented u= pon. And for those in the know, that it comes from one section or another of= the wider Internet technical community after open peer review. >=20 > I want to focus on this point a bit, as I've heard it a few times. I recog= nize that formally "RFC" stands for "Request for Comments", but my suspicion= is that at this point it's much more like "laser" or 'scuba", i.e., it's an= acronym but people don't bother to think of the expansion at all but just c= hunk it as a name. As I said, it's just my opinion, but I'd be interested in= any evidence you have that the broader community thinks otherwise. The errata process supports the idea of Request For Comments and it=E2=80=99= s used quite a bit. Bis drafts are evidence too as are experimental documen= ts later becoming standards track, and proposed standard moving to standards= track. The clearest problem statement I=E2=80=99ve heard just points in the directi= on that we should be using STD more to further disambiguate document status.= I think that would be a positive step toward the stated goals, but would r= equire effort or a change in process to make it easier for documents to begi= n in this state if there are enough interoperable implementations at time of= publication. Best, Kathleen=20 >=20 > -Ekr >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --Apple-Mail-809B725F-D2BA-462D-955E-6FBF83A79E56 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent= from my mobile device

On Jul 6, 2018, at 6:51 PM, Eric Rescor= la <ekr@rtfm.com> wrote:

On Fri, Jul 6, 2018 at 3= :12 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
That depends on what you think the value of the "Reque= st for Comments" brand is. I think it's the fact that it says right up front= that the document is tentative, might be wrong, and needs to be read critic= ally and commented upon. And for those in the know, that it comes from one s= ection or another of the wider Internet technical community after open peer r= eview.

I want to focus on this point a b= it, as I've heard it a few times. I recognize that formally "RFC" stands for= "Request for Comments", but my suspicion is that at this point it's much mo= re like "laser" or 'scuba", i.e., it's an acronym but people don't bother to= think of the expansion at all but just chunk it as a name. As I said, it's j= ust my opinion, but I'd be interested in any evidence you have that the broa= der community thinks otherwise.

The errata process supports the idea of Request For Comment= s and it=E2=80=99s used quite a bit.  Bis drafts are evidence too as ar= e experimental documents later becoming standards track, and proposed standa= rd moving to standards track.

The clearest problem statem= ent I=E2=80=99ve heard just points in the direction that we should be using S= TD more to further disambiguate document status.  I think that would be= a positive step toward the stated goals, but would require effort or a chan= ge in process to make it easier for documents to begin in this state if ther= e are enough interoperable implementations at time of publication.

Best,
Kathleen 


-Ekr


____________________= ___________________________
Rfcplusplus mailing list<= br>Rfcplusplus@ietf.org
= https://www.ietf.org/mailman/listinfo/rfcplusplus
= --Apple-Mail-809B725F-D2BA-462D-955E-6FBF83A79E56-- From nobody Fri Jul 6 16:13:46 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E30D12777C for ; Fri, 6 Jul 2018 16:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=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 T5oBuMnLsZ-c for ; Fri, 6 Jul 2018 16:13:42 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A86124D68 for ; Fri, 6 Jul 2018 16:13:42 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id r3-v6so4742536ywc.5 for ; Fri, 06 Jul 2018 16:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2pZJwRiFUjNeJ68tTC8LmUojy3Q+2t1IBmeIclNAt/8=; b=1WSTQTeDONWGb/dqs8pKwFErpC4eL/qSXOyWhVwjLCZ6r5cTNNLUJhnHGGlawiZZrc Vr10TnZ3og2GGg8hIOp8ewf2PH48yQ06+KSJzatTToOO5gYmUJhTlGw2ACou7brxuq3Q Bc0SHn7WznHlM/s1K6JSNd33DMLVIH+A1XiOSEuTNIm0ZL/Xzv4Z03cm/673CYHiHvEC vO2a227FCP5BHNvsXfDsO+TJM0XBAIidk5K7JCeCf204Uso0ZKy3anS1WJFidVjP3QJq XBgbzWQJ9qdRXr/ckbVGbiMD/WhnMlXOs1qI5dWoLTgKj8P84zrEgolVWalNkqLmV6C8 rLtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2pZJwRiFUjNeJ68tTC8LmUojy3Q+2t1IBmeIclNAt/8=; b=X0L2fipgMhex9vO63xlpentMqfHzZjM4+8isupARgL+umljpPKwWKwo5355J3EtlzX ajdBM7WBuYc+2QHqmJ/zxUk9Nwixis5dam3qy36WcJVKIO2YupXvhB30hANCpbK2tSa5 p/Zw7OLvZE42DrSg4vo6sfl5baIHAXtgQv5/5Y3qF47P0p0Jy6VQN6BMNI4jGH17b0JK D1pEY6RNQl8TPekKElTPxn7cv4qNPYnY5Pdd7gz2MZDJtn+nsoobihNAmIWLtB8X4miw SJevaE2Rl5FHgKXfM8bxRFGzmhIbUfq9kbY8GXdz7uwVoqQsPi9LcKIv/S2dl1dzAwo0 KnpA== X-Gm-Message-State: APt69E3OIwWJXyBWQcE+BnhP0Bg4Z3F+Igs/CS3y7t6n5p8w6wu5dsPu ZhCL+2ljXiGvRMUFLMXsyxjSddKG18s5xI3QtKJR4klg X-Google-Smtp-Source: AAOMgpd9xlZR8slVWL/qhZ9wKrJRFMsO+DllsenBT/MN4Q3rbL4cJwawT1kWLrLQS1pEYVmICBuqG3PJ/EQI9OcPYYg= X-Received: by 2002:a0d:fe07:: with SMTP id o7-v6mr5726202ywf.167.1530918821594; Fri, 06 Jul 2018 16:13:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 16:13:01 -0700 (PDT) In-Reply-To: <71A34570-1974-45A4-90AA-C74E4784D50C@gmail.com> References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> <71A34570-1974-45A4-90AA-C74E4784D50C@gmail.com> From: Eric Rescorla Date: Fri, 6 Jul 2018 16:13:01 -0700 Message-ID: To: Kathleen Moriarty Cc: Brian E Carpenter , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000008a9eb405705cd073" Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 23:13:45 -0000 --0000000000008a9eb405705cd073 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 6, 2018 at 4:08 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > Sent from my mobile device > > On Jul 6, 2018, at 6:51 PM, Eric Rescorla wrote: > > On Fri, Jul 6, 2018 at 3:12 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> That depends on what you think the value of the "Request for Comments" >> brand is. I think it's the fact that it says right up front that the >> document is tentative, might be wrong, and needs to be read critically a= nd >> commented upon. And for those in the know, that it comes from one sectio= n >> or another of the wider Internet technical community after open peer rev= iew. >> > > I want to focus on this point a bit, as I've heard it a few times. I > recognize that formally "RFC" stands for "Request for Comments", but my > suspicion is that at this point it's much more like "laser" or 'scuba", > i.e., it's an acronym but people don't bother to think of the expansion a= t > all but just chunk it as a name. As I said, it's just my opinion, but I'd > be interested in any evidence you have that the broader community thinks > otherwise. > > > The errata process supports the idea of Request For Comments and it=E2=80= =99s used > quite a bit. Bis drafts are evidence too as are experimental documents > later becoming standards track, and proposed standard moving to standards > track. > Hmm... I'm not sure how persuaded I am by this. Other standards bodies have errata processes (e.g., ITU corrigendum), bis documents (cf. V42.bis), and multilevel standards (cf. W3C CR and PR), even though their standards aren't named RFC. So I agree that people expect that standards are imperfect and need revision, but this doesn't seem like evidence that naming them RFC makes people think that they are any more provisional than naming them Recommendation. -Ekr > The clearest problem statement I=E2=80=99ve heard just points in the dire= ction > that we should be using STD more to further disambiguate document status. > I think that would be a positive step toward the stated goals, but would > require effort or a change in process to make it easier for documents to > begin in this state if there are enough interoperable implementations at > time of publication. > > Best, > Kathleen > > > -Ekr > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > > --0000000000008a9eb405705cd073 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 6, 2018 at 4:08 PM, Kathleen Moriarty <= ;kath= leen.moriarty.ietf@gmail.com> wrote:


Sent from my mobile device

On Jul 6, 2018, at 6:51 PM, Eric Rescorla <ekr@rtfm.com> wrote:

<= blockquote type=3D"cite">
On Fri, Jul 6, 2018 at 3:12 = PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
That depends on what you think the value of the "= ;Request for Comments" brand is. I think it's the fact that it say= s right up front that the document is tentative, might be wrong, and needs = to be read critically and commented upon. And for those in the know, that i= t comes from one section or another of the wider Internet technical communi= ty after open peer review.

I want to fo= cus on this point a bit, as I've heard it a few times. I recognize that= formally "RFC" stands for "Request for Comments", but = my suspicion is that at this point it's much more like "laser"= ; or 'scuba", i.e., it's an acronym but people don't bothe= r to think of the expansion at all but just chunk it as a name. As I said, = it's just my opinion, but I'd be interested in any evidence you hav= e that the broader community thinks otherwise.
<= /div>

The errata process supports the ide= a of Request For Comments and it=E2=80=99s used quite a bit.=C2=A0 Bis draf= ts are evidence too as are experimental documents later becoming standards = track, and proposed standard moving to standards track.<= div>
Hmm... I'm not sure how persuaded I am by this. Othe= r standards bodies have errata processes (e.g., ITU corrigendum), bis docum= ents (cf. V42.bis), and multilevel standards (cf. W3C CR and PR), even thou= gh their standards aren't named RFC. So I agree that people expect that= standards are imperfect and need revision, but this doesn't seem like = evidence that naming them RFC makes people think that they are any more pro= visional than naming them Recommendation.

-Ekr=

=
The clearest problem statement I=E2=80=99ve heard just point= s in the direction that we should be using STD more to further disambiguate= document status.=C2=A0 I think that would be a positive step toward the st= ated goals, but would require effort or a change in process to make it easi= er for documents to begin in this state if there are enough interoperable i= mplementations at time of publication.

Best,
=
Kathleen=C2=A0


-Ekr


_____________= __________________________________
Rfcplusplus mailing= list
Rfcplusplus@ietf.org
https://www.ietf.org/mai= lman/listinfo/rfcplusplus

--0000000000008a9eb405705cd073-- From nobody Fri Jul 6 16:34:39 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A936130F6A for ; Fri, 6 Jul 2018 16:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gDQpHTkGxFv1 for ; Fri, 6 Jul 2018 16:34:34 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 31665130DD5 for ; Fri, 6 Jul 2018 16:34:34 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id q12-v6so11283729qtp.6 for ; Fri, 06 Jul 2018 16:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X3XogseFzzr56nkgEYnCtsqaYu/q1LGHOfHOYXOkr+w=; b=XBFJD6Q4HJF+pf0oaAHfmsXJqWUB7iGVhAdhrqbrMT9f7+Qx/pjti2w1jTmKR2K3e+ NMvjE+bsfZTq+Ob34wWf2c8U0k5ODDs5rWiiRk0crDDdQdVA1Z+eU50B1SVciucwRmlc OrfjzdHwq8Ka8tJbKJDSYG0Km9O47YKOO+PFSLyHV43Le9s2kaFCneZaavEB7AnZfFW3 JQ60sSQ6cl0Jbq8ANgZldXgCW990YlA1UczmKafnUFafp3EP3zAU7jeSKdIcyf4xpxGc ERA0hkOaKwk9ShabpwFe/hTVv8H6rInnmJlrnfKcWgDnQw/xvKDlumIQMKb/NGs3v0mi b59A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X3XogseFzzr56nkgEYnCtsqaYu/q1LGHOfHOYXOkr+w=; b=Qt5D+jBgA+DoGhH1SDi2eMLd2dzJh+gZaHlk439+c/2udiPMayXetihqbIvMCbuldV nNRe0ZGeU+7HCQG8itGK3Twin0uQ6b7md2mPBG17OZxiytdVXzvFMc2kCkTDpl6FFjAs JjwkeirTHBzyagH7NmS7lNfrh/tXBir+tJ1EJzXqzaWUgDSebQ4VjZq0S654ZWLC3obm eb1c4IL1t0/1kMQVyJUzsz6BwXQ18rnmEmYoEs77CJex81QoHW9oHgD/KGIicqZX+nLk Pa5p9kTMD1fQ5mRDWsIIMXx2bQqE/bbCQsQ2lezUC/j8+u3eDhIItJYLiPKUgrIwYOb7 xryg== X-Gm-Message-State: APt69E3zJ6/n0sg2K0MdOYocInKtaXhHiG05cCjQOqR1BYRx2Ij7+wip I7AhzI7KW/dODeifzyReOJpDZYkK X-Google-Smtp-Source: AAOMgpeYZKlGUpu2tN1HwMB9b1akhkAX7RFBeU9v3cQcjVWEn35OKGmLR5/WmEMhBUrHcNsky9+MeQ== X-Received: by 2002:aed:3f1d:: with SMTP id p29-v6mr10719225qtf.320.1530920073208; Fri, 06 Jul 2018 16:34:33 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id k67-v6sm6455657qte.95.2018.07.06.16.34.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 16:34:32 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-19FD089C-EAEF-45BD-A98A-183641F9CA31 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Fri, 6 Jul 2018 19:34:31 -0400 Cc: Brian E Carpenter , rfcplusplus@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> <71A34570-1974-45A4-90AA-C74E4784D50C@gmail.com> To: Eric Rescorla Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 23:34:38 -0000 --Apple-Mail-19FD089C-EAEF-45BD-A98A-183641F9CA31 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my mobile device > On Jul 6, 2018, at 7:13 PM, Eric Rescorla wrote: >=20 >=20 >=20 >> On Fri, Jul 6, 2018 at 4:08 PM, Kathleen Moriarty wrote: >>=20 >>=20 >> Sent from my mobile device >>=20 >>> On Jul 6, 2018, at 6:51 PM, Eric Rescorla wrote: >>>=20 >>>> On Fri, Jul 6, 2018 at 3:12 PM, Brian E Carpenter wrote: >>>> That depends on what you think the value of the "Request for Comments" b= rand is. I think it's the fact that it says right up front that the document= is tentative, might be wrong, and needs to be read critically and commented= upon. And for those in the know, that it comes from one section or another o= f the wider Internet technical community after open peer review. >>>=20 >>> I want to focus on this point a bit, as I've heard it a few times. I rec= ognize that formally "RFC" stands for "Request for Comments", but my suspici= on is that at this point it's much more like "laser" or 'scuba", i.e., it's a= n acronym but people don't bother to think of the expansion at all but just c= hunk it as a name. As I said, it's just my opinion, but I'd be interested in= any evidence you have that the broader community thinks otherwise. >>=20 >> The errata process supports the idea of Request For Comments and it=E2=80= =99s used quite a bit. Bis drafts are evidence too as are experimental docu= ments later becoming standards track, and proposed standard moving to standa= rds track. >=20 > Hmm... I'm not sure how persuaded I am by this. Other standards bodies hav= e errata processes (e.g., ITU corrigendum), bis documents (cf. V42.bis), and= multilevel standards (cf. W3C CR and PR), even though their standards aren'= t named RFC. So I agree that people expect that standards are imperfect and n= eed revision, but this doesn't seem like evidence that naming them RFC makes= people think that they are any more provisional than naming them Recommenda= tion. Having spent a few years attending ITU meetings and assisting with ISO 27000= for my organization, I disagree. The IETF process is more open, contributi= ons follow a much less formal process (we take email on a list as input from= anyone, whereas in the ITU and other standards bodies, a member has to form= ally submit a contribution within a certain time period while the document i= s open for review). For the IETF, this can happen at any point in the proce= ss. While standards may be reopened in other bodies, the process is more fo= rmal. RFCs means we are open to input from anyone (hopefully reasonable and= helpful input) without restriction. Best regards, Kathleen=20 >=20 > -Ekr >=20 >>=20 >> The clearest problem statement I=E2=80=99ve heard just points in the dire= ction that we should be using STD more to further disambiguate document stat= us. I think that would be a positive step toward the stated goals, but woul= d require effort or a change in process to make it easier for documents to b= egin in this state if there are enough interoperable implementations at time= of publication. >>=20 >> Best, >> Kathleen=20 >>=20 >>>=20 >>> -Ekr >>>=20 >>>=20 >>> _______________________________________________ >>> Rfcplusplus mailing list >>> Rfcplusplus@ietf.org >>> https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 --Apple-Mail-19FD089C-EAEF-45BD-A98A-183641F9CA31 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent= from my mobile device

On Jul 6, 2018, at 7:13 PM, Eric Rescor= la <ekr@rtfm.com> wrote:



On Fri, Jul 6, 2018 at 4:08 PM, Kathle= en Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:


Sent fro= m my mobile device

On Jul 6, 2018, at 6:51 PM, Eric Resc= orla <ekr@rtfm.com&= gt; wrote:

On Fri= , Jul 6, 2018 at 3:12 PM, Brian E Carpenter <brian.e.carpenter@gma= il.com> wrote:
That depends on what you think the v= alue of the "Request for Comments" brand is. I think it's the fact that it s= ays right up front that the document is tentative, might be wrong, and needs= to be read critically and commented upon. And for those in the know, that i= t comes from one section or another of the wider Internet technical communit= y after open peer review.

I want to focu= s on this point a bit, as I've heard it a few times. I recognize that formal= ly "RFC" stands for "Request for Comments", but my suspicion is that at this= point it's much more like "laser" or 'scuba", i.e., it's an acronym but peo= ple don't bother to think of the expansion at all but just chunk it as a nam= e. As I said, it's just my opinion, but I'd be interested in any evidence yo= u have that the broader community thinks otherwise.

The errata process supports the i= dea of Request For Comments and it=E2=80=99s used quite a bit.  Bis dra= fts are evidence too as are experimental documents later becoming standards t= rack, and proposed standard moving to standards track.

Hmm... I'm not sure how persuaded I am by this. Other stand= ards bodies have errata processes (e.g., ITU corrigendum), bis documents (cf= . V42.bis), and multilevel standards (cf. W3C CR and PR), even though their s= tandards aren't named RFC. So I agree that people expect that standards are i= mperfect and need revision, but this doesn't seem like evidence that naming t= hem RFC makes people think that they are any more provisional than naming th= em Recommendation.

Having spent a few years attending ITU meetings and assisting with ISO 2= 7000 for my organization, I disagree.  The IETF process is more open, c= ontributions follow a much less formal process (we take email on a list as i= nput from anyone, whereas in the ITU and other standards bodies, a member ha= s to formally submit a contribution within a certain time period while the d= ocument is open for review).  For the IETF, this can happen at any poin= t in the process.  While standards may be reopened in other bodies, the= process is more formal.  RFCs means we are open to input from anyone (= hopefully reasonable and helpful input) without restriction.

<= div>Best regards,
Kathleen 


-Ekr


The clearest problem statement I=E2= =80=99ve heard just points in the direction that we should be using STD more= to further disambiguate document status.  I think that would be a posi= tive step toward the stated goals, but would require effort or a change in p= rocess to make it easier for documents to begin in this state if there are e= nough interoperable implementations at time of publication.

Best,
Kathleen 


-Ekr


______________= _________________________________
Rfcplusplus mailing l= ist
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/= listinfo/rfcplusplus

= --Apple-Mail-19FD089C-EAEF-45BD-A98A-183641F9CA31-- From nobody Sat Jul 7 05:19:46 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8870D130E17 for ; Sat, 7 Jul 2018 05:19:44 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99AqvbJEc_2e for ; Sat, 7 Jul 2018 05:19:43 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE192130E0D for ; Sat, 7 Jul 2018 05:19:42 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fbmBe-000Cax-1G; Sat, 07 Jul 2018 08:19:38 -0400 Date: Sat, 07 Jul 2018 08:19:32 -0400 From: John C Klensin To: Eric Rescorla cc: Eliot Lear , Kathleen Moriarty , rfcplusplus@ietf.org Message-ID: <55AB5BE68668E81159822818@PSB> In-Reply-To: References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2018 12:19:45 -0000 --On Friday, July 6, 2018 07:33 -0700 Eric Rescorla wrote: >> There is one other benefit that I think we should not lose >> sight of. Over the years (including well before there was >> an IETF) "we" have presented the RFC Series as the go-to >> place for technical specifications about what is used on the >> Internet. > > > Hmm... This seems to me to be true only if one has a pretty > narrow definition of "on the Internet". Here are a few > examples of things which get used on the Internet on a regular > basis that aren't RFCs: Sure. I would agree if you had just said that presentation is something of a myth, but suggest it is a myth that works in our favor. We definitely don't have a monopoly. If we ever did, it probably hasn't been since the late 70s or early 80s. In particular... > - HTML (WHATWG and/or W3C) As you mention, there was an early version (or two?) of HTML that we did publish in the RFC series. Then, after W3C decided it wanted to be in the standards business after all, there was a fairly explicit agreement and handoff. > - JavaScript (TC39) And ECMA (or whatever it is called now), and several other places. > - H.264 (MPEG) > - JPEG Content types, which we have rather explicitly said we don't want beyond registering their names and pointers to their descriptions. > - AES, P-256 (NIST) Yes. And incorporated into various of our protocols by reference (and referenced from them). > - Bittorrent > - Tor Both, IIR, things that, at one point or another, we decided we didn't want. You left at least one thing off your list that is arguably as important to today's Internet as several of those put together, which is the internal protocols and mechanisms used by various CDNs and other providers to > I spent a bunch of time trying to think of a characterization > of the role of the RFC series (or the IETF's) role that was > succinct, but in truth I think we're part of a broad coaltion > of people publishing Internet protocol specificationswith > somewhat fuzzily defined boundaries between the areas of work. I would agree with that. I don't think it changes my underlying point any more than your list above does, but YMMD. >> Let me give an example that lies a bit outside the crypto >> realm > > and that may therefore be easier for the rest of us to >> understand. Suppose the IETF adopts a protocol that is >> carefully designed for maximum privacy. Now suppose that >> something comes along that is faster, lighter-weight, >> supported or mandated by some governments but that protects >> privacy from everyone but those governments (but leaves >> information completely exposed to them). We can certainly >> ignore the latter as just bad news but I contend we protect >> our reputation and the privacy-safety of users, and make the >> Internet better, far more by publishing its specs, explaining >> the vulnerabilities it creates, and recommending against it >> unless one is actually required to use it than by ignoring it. > This hypothetical contains a number of things "we" might do > (publish the spec, critique it, recommend against it). I don't > think it's actually a particular service to the world for us > to publish the spec as long as it's readily found by other > means. It's not clear to me how that helps. I think that depends a lot on the same issues that drove my earlier note on which you asked for more details (haven't forgotten that, just haven't been able to make time yet). "Not actually a particular service" implies that everyone who might be interested can follow links with ease, that there are no advantages to a uniform format and style, that either one doesn't care about these things for the long term (e.g., for understanding the history of various protocol developments and choices some years on) or that links never go bad, etc. I think those things are important and have learned to be very conservative (largely in the "conservation" sense) about them. YMMD. > I certainly think > critiquing it and recommending against it are good ideas > (though depending on the technology, perhaps making something > that had the good properties without the bad would be even > better). If the bad stuff is already in wide use and especially if the newer version is better but not obviously and overwhelmingly better, both may be needed. More important, "X is better than Y" is a much more absolute statement than many of the design choices we face. In many situations, we are less likely to have "the good properties without the bad" as an option but find ourselves dealing with tradeoffs in which optimizing one thing pessimizes another and we have to make tradeoffs. I suggest that, at least in recent years, the IETF has been fairly poor about being explicit about those choices, preferring to either leave the information out in the hope that its choices will be more accepted or just not wanting to take the time to document them. I think that is unfortunate for those who need to make choices in the marketplace, for our reputation as an engineering-oriented body that is consistently trying to make good overall choices for the Internet, and for the academic considerations you mention in another context below. Again, YMMD. > It's not clear to me that having those critiques in > the RFC series is that helpful, though having the IETF > recommend against the protocol (whether that recommendation > was in an RFC or not) might well be. There are, as far as I know, only two ways to recommend against a protocol. One is to do so on the basis of some clear critique the other is to say some form of "you shouldn't use this because we are the IETF, we know more about these things than you do, and we are all-seeing and all-knowing". To me, the latter is even worse that "we recommend this and against everything else because we are a collection of government representatives and we not only know more than you do but can make you". And, btw, in case it hasn't be clear, I think critiques of whatever the IETF decides on are at least as important as IETF critiques as everything else. If nothing else, if they are done well, they keep us honest and help clarify the tradeoffs we are making. > With that said, this hypothetical isn't *that* far off the > mark. Tor is a privacy protocol better than anything in the > IETF (though to the best of my knowledge it doesn't have the > negative properties of the protocol in your hypothetical). Its > protocol is mostly defined by the implementation although > there's a not-particularly clear spec. There are a pile of > papers describing potential attacks. To the best of my > knowledge, none of this is in the RFC series. From my > perspective as a protocol implementer: > > - Having a good spec published would be valuable. Having it in > the RFC series would not be particularly helpful, though it > would not be harmful [0] - Having an IETF standard would > probably be helpful depending on whether it improved Tor. It > would likely lead to a clearer spec, which would be good. - > Having the various attacks/critiques published in the RFC > series would not be helpful. Currently, they are in > peer-reviewed venues (e.g., IEEE Oakland) which do a better > job of review than we do. Moreover, the academic community is > where the conversation about the security of this type of > protocol takes place. And should therefore probably stay there. My arguments would be more relevant if the IETF decided to develop and standardize a TORjunior and TORbis protocol and push it instead of the original. I also suggest that the decision to use tor rather than more traditional routing is also something that involves tradeoffs, something of which at least parts of that research community are aware, but which appear to be under-documented. Probably that is ok in their context, but I'd hope that, when we produce standards, we don't set such things aside. Incidentally, if you believe that other peer-reviewed venues, such as IEEE Oakland in your example, consistently do a better job of review than we do, that is a fairly good argument, not for changing the labels on RFCs or constraining the ISE, but for just stopping the efforts to make the RFC series more academically credible and for abandoning the IRTF entirely. If syntax models like HTML are better done elsewhere than in the IETF, we should recognize that and hand them off (as we have, explicitly). If specialized routing models like tor are better explored and developed in parts of the academic community, then we should encourage, not, resist that. From the other side, if some protocol is developed and widely deployed in industry --for their own reasons rather than as a way of doing an end run around IETF review while seeking IETF endorsement anyway-- decides that a particular protocol or syntax is better further developed and curated by the IENT rather than continuing as an industry-proprietary mechanism, then I think we should embrace the transfer if it is within our normal scope. But, if you believe our review mechanisms are not effective, or even just not as effective as others that are out there, it is time to ask much deeper questions that ones about the labels on documents. best, john From nobody Sat Jul 7 13:54:47 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F13B130E01 for ; Sat, 7 Jul 2018 13:54:45 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 n3YStT_5IjY8 for ; Sat, 7 Jul 2018 13:54:44 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006B112F1A2 for ; Sat, 7 Jul 2018 13:54:43 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fbuE6-000FTk-Jt; Sat, 07 Jul 2018 16:54:42 -0400 Date: Sat, 07 Jul 2018 16:54:36 -0400 From: John C Klensin To: Kathleen Moriarty cc: rfcplusplus@ietf.org Message-ID: <0CF177439EBA01BB4284279B@PSB> In-Reply-To: <71A34570-1974-45A4-90AA-C74E4784D50C@gmail.com> References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> <71A34570-1974-45A4-90AA-C74E4784D50C@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2018 20:54:46 -0000 Kathleen, --On Friday, July 6, 2018 19:08 -0400 Kathleen Moriarty wrote: >... > The clearest problem statement I've heard just points in the > direction that we should be using STD more to further > disambiguate document status. I think that would be a > positive step toward the stated goals, but would require > effort or a change in process to make it easier for documents > to begin in this state if there are enough interoperable > implementations at time of publication. Addressing just this one issue, it seems to me that you just re-invented the original intent of the distinction between Proposed and Draft Standard. In principle, because the 2026 definition of Proposed Standard has never been changed, Proposed Standards are supposed to be well-thought-out, with no known technical defects, but, in general, with no requirement for deployment or implementation experience at all. Draft Standard, by contrast, still does not require community consensus that the document is a really good idea and that the spec is solid, but does require more than one implementation and some experience in use. We eliminated Draft Standard some years ago with RFC 6410. If I recall, the assumption was that doing so would result in more specifications moving to Full Standard because there has been only one step. However, I think one problem has been that the typical bar for Proposed Standards has risen even further. That issue, as of the discussion leading up toe 6410, is discussed in the long-expired draft-bradner-restore-proposed-00. If that document were taken as predictive, I think the prediction has largely played out. The proposals (e.g., draft-klensin-std-numbers-02 and the much earlier draft-klensin-newtrk-std-repurposing-00 and draft-ietf-newtrk-docid-00) to just give all standards-track documents STD numbers so we can better talk about current versions (and, if we are fussing with labels, better use that one) assumed that, if the Internet was going to run on Proposed Standards, it was time that we be less critical about the numbers but not try to differentiate between better and worse quality proposed standards -- solutions to a slightly different set of problems. In poking through old drafts to get the references above, I was accidentally reminded that we've looked at the question of separating IETF process documents from the BCPs that actually talk about Internet operational procedures and the like (draft-ietf-newtrk-sd-00). We've been over a _lot_ of the territory covered in these discussions before and, in Newtrk, devised (and Brian and others have pointed out) a comprehensive model rather than assuming that a few small patches here and there (like new labels or even blowing non-IETF documents out of the RFC Series) were going to accomplish enough to be worthwhile. best, john From nobody Sat Jul 7 20:18:25 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E458E130F5E for ; Sat, 7 Jul 2018 20:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 hcluUFZ5v84m for ; Sat, 7 Jul 2018 20:18:19 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 38B19130F63 for ; Sat, 7 Jul 2018 20:18:19 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id k127-v6so5997105ybk.6 for ; Sat, 07 Jul 2018 20:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V1nwDTBowXxWuqkVu6Lqfs81TH4nA6h3zg5uR+jaNa0=; b=fL+oInR8tPhSWufa4PVKclwRNXkxoMA2b3+HzZjff3aqey0wOx4RVePvjYIf4ITfnL BKDTl4O++9ko2TFq7+liyPL07j0XSm+UGuwBKnnH2aGRIIcjbr/1v0tDERyqdPevBdfQ hgOUf95yfE2TvL097jTxxSwzVkG7Wm4yXEoKuuV1rF2bSjfRjEYTgt4hnpAY7fq9Hi7D VneT8kcQvgeu1dcjZHuPMEt6fl/Tf+EVLJN/WCljzZuSyqwDHo9NmeFGP3pbY114rn/n ntX7GtrRNam5oovs/XiqJsuJCNFalW+Wk/2YiKA69MOZW0/HcVqViD/83sDLelIFkYvr 2Nfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V1nwDTBowXxWuqkVu6Lqfs81TH4nA6h3zg5uR+jaNa0=; b=mdr/9my8ew7i/6wrpccBjLQZot4s2AAb5KDVJAfE/ORPCESqPKiAZdymS49CIwLEBA QuXGmZsp6VRbk6WesYejQugyw84LLW08lkfp4Bk8n/0RvSk6jw3rkt3VRvu6xA7AO/Qt d/7Bc0/jXGYn61ztOkfDyQRVh/ax43WTXq+niyxJ9z6nl3teGut4MfRjtl1LnPEel0KG GyNQMFEsOIYRzYR2DNdcVW8Z5p916aZwIPEg4NOueX7FDjM3AkJ9hS57UeXF69/nNSYM ACaZnmR4ibBoT4/qSIpohWHM4yiw5AnSiNxZ2mC2INlG4KB6yngG8rMrkzYtErp8yU90 vYxw== X-Gm-Message-State: APt69E2ZiJ7/6WQweGkLr+uypwxmB9I9qy4Y0kpL7yX7l/0tX8bdB+0B 93RQkArEKQtD5scboTime37zM5k58c3rRpGhYaHxPQ== X-Google-Smtp-Source: AAOMgpclgHpA68dZjS2Fi0+OvLejzfvDP0rFg2EdOm2lZuMM6n+BZtCVKyzdz9ufGFAkrbbtM0tGJVFpzU/yITwMezY= X-Received: by 2002:a25:9a49:: with SMTP id r9-v6mr8033539ybo.451.1531019898021; Sat, 07 Jul 2018 20:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Sat, 7 Jul 2018 20:17:37 -0700 (PDT) In-Reply-To: <55AB5BE68668E81159822818@PSB> References: <6c159ca4-ec56-c6fa-a886-76eaa2d580ad@gmail.com> <2F895DD8-0FA6-450C-9C7D-F0F0A469BD56@gmail.com> <8b0cbc62-e605-0b77-aa38-2f995e248a05@cisco.com> <55AB5BE68668E81159822818@PSB> From: Eric Rescorla Date: Sat, 7 Jul 2018 20:17:37 -0700 Message-ID: To: John C Klensin Cc: Eliot Lear , Kathleen Moriarty , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000002a807b05707459be" Archived-At: Subject: Re: [Rfcplusplus] Crypto algorithms [was draft-thomson-rfcplusplus-label-00] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 03:18:23 -0000 --0000000000002a807b05707459be Content-Type: text/plain; charset="UTF-8" > > --On Friday, July 6, 2018 07:33 -0700 Eric Rescorla > wrote: > > >> There is one other benefit that I think we should not lose > >> sight of. Over the years (including well before there was > >> an IETF) "we" have presented the RFC Series as the go-to > >> place for technical specifications about what is used on the > >> Internet. > > > > > > Hmm... This seems to me to be true only if one has a pretty > > narrow definition of "on the Internet". Here are a few > > examples of things which get used on the Internet on a regular > > basis that aren't RFCs: > > Sure. I would agree if you had just said that presentation is > something of a myth, but suggest it is a myth that works in our > favor Well, I'm not sure I agree that it's something "we" have generally presented (though I'm sure that some people have said this at one time or another.) But in any case, it sounds like we agree that it's not true, and I don't think most people working directly with protocol standards are likely to be confused on this point. > We definitely don't have a monopoly. If we ever did, > it probably hasn't been since the late 70s or early 80s. In > particular... > > - HTML (WHATWG and/or W3C) > > As you mention, there was an early version (or two?) of HTML > that we did publish in the RFC series. Then, after W3C decided > it wanted to be in the standards business after all, there was a > fairly explicit agreement and handoff. Yes. > > - JavaScript (TC39) > > And ECMA (or whatever it is called now), and several other > places. TC39 is an ECMA technical committee. > > - H.264 (MPEG) > > - JPEG > > Content types, which we have rather explicitly said we don't > want beyond registering their names and pointers to their > descriptions. Well, we standardized OPUS, RFC 2083 describes OPUS, and we currently have a videocodec WG, so I'm not sure I agree we don't want media formats. > > - AES, P-256 (NIST) > > Yes. And incorporated into various of our protocols by > reference (and referenced from them). > > > - Bittorrent > > - Tor > > Both, IIR, things that, at one point or another, we decided we > didn't want. Potentially, though I don't recall this. > You left at least one thing off your list that is arguably as > important to today's Internet as several of those put together, > which is the internal protocols and mechanisms used by various > CDNs and other providers to It wasn't intended to be an exhaustive list. > >> Let me give an example that lies a bit outside the crypto > >> realm > > > > and that may therefore be easier for the rest of us to > >> understand. Suppose the IETF adopts a protocol that is > >> carefully designed for maximum privacy. Now suppose that > >> something comes along that is faster, lighter-weight, > >> supported or mandated by some governments but that protects > >> privacy from everyone but those governments (but leaves > >> information completely exposed to them). We can certainly > >> ignore the latter as just bad news but I contend we protect > >> our reputation and the privacy-safety of users, and make the > >> Internet better, far more by publishing its specs, explaining > >> the vulnerabilities it creates, and recommending against it > >> unless one is actually required to use it than by ignoring it. > > > This hypothetical contains a number of things "we" might do > > (publish the spec, critique it, recommend against it). I don't > > think it's actually a particular service to the world for us > > to publish the spec as long as it's readily found by other > > means. It's not clear to me how that helps. > > I think that depends a lot on the same issues that drove my > earlier note on which you asked for more details (haven't > forgotten that, just haven't been able to make time yet). "Not > actually a particular service" implies that everyone who might > be interested can follow links with ease, that there are no > advantages to a uniform format and style, that either one > doesn't care about these things for the long term (e.g., for > understanding the history of various protocol developments and > choices some years on) or that links never go bad, etc. I think > those things are important and have learned to be very > conservative (largely in the "conservation" sense) about them. > YMMD. Indeed. I don't think there are *no* advantages, but I think they're pretty modest. Moreover, the uniformity is pretty superficial (7-bit ASCII, etc.) One need only look at the QUIC specs to see an example of this, with TLS-style PDU definitions nestled next to ASCII art bit diagrams. > > It's not clear to me that having those critiques in > > the RFC series is that helpful, though having the IETF > > recommend against the protocol (whether that recommendation > > was in an RFC or not) might well be. > > There are, as far as I know, only two ways to recommend against > a protocol. One is to do so on the basis of some clear > critique the other is to say some form of "you shouldn't use > this because we are the IETF, we know more about these things > than you do, and we are all-seeing and all-knowing". I'm not sure what you're responding to here. My position isn't that the documents ought not to provide detailed critiques, but rather that it's not obviously important that they be in the RFC series. It's not clear to me that that's a relevant factor. > Incidentally, if you believe that other peer-reviewed venues, > such as IEEE Oakland in your example, consistently do a better > job of review than we do, that is a fairly good argument, not > for changing the labels on RFCs or constraining the ISE, but for > just stopping the efforts to make the RFC series more > academically credible and for abandoning the IRTF entirely. Well, I wasn't offering it as an argument for anything in particular, just stating my opinion -- albeit one supported by considerable evidence -- about where the relevant work in critiquing a certain class of protocols is published. Those critiques then get fed into the IETF process. A good example of this is the development of TLS 1.3, which was done in close collaboration with the academic community and led to quite a few academic papers which then influenced the design of the protocol. Appendix E of the TLS draft provides citations to quite a bit of this work: https://tools.ietf.org/html/draft-ietf-tls-tls13-28#appendix-E With that said, at least in my field, I think the IRTF (specifically the CFRG) is serving an important function in terms of liaising between the academic community and the IETF protocol development community, so I don't think it would be good to shut down that piece of the IRTF. Despite that, the academics who do cryptography tend to publish that work in academic conferences and then later it may get transcribed into an RFC in IRTF. > If > syntax models like HTML are better done elsewhere than in the > IETF, we should recognize that and hand them off (as we have, > explicitly). If specialized routing models like tor are better > explored and developed in parts of the academic community, then > we should encourage, not, resist that. I fear you may be misunderstanind me. For context, here's what I said: would not be harmful [0] - Having an IETF standard would probably be helpful depending on whether it improved Tor. It would likely lead to a clearer spec, which would be good. - Having the various attacks/critiques published in the RFC series would not be helpful. Currently, they are in peer-reviewed venues (e.g., IEEE Oakland) which do a better job of review than we do. Moreover, the academic community is where the conversation about the security of this type of protocol takes place. My point is not that things like Tor are better developed in the academic community but rather that the development of protocol standards -- at least in the area of communication security -- involves a number of different types of technical work (protocol specification, analysis, verification, prototyping, etc. That work is done by a number of communities that overlap to some extent, and each community has its conventional venues for sharing its work [0]. So, when those communities collaborate, it involves publication in multiple venues. To return to the TLS 1.3 example: - The protocol development itself happened in conventional IETF venues (mailing lists, meetings, etc.) but also on Github. - Implementation coordination was done over Slack, Github, hackathons, etc. - Analysis was done in academic-type venues (eprint, conferences, workshops, etc.) The RFC series (and also I-Ds) have an important role to play here, but it also exists in conversation with a lot of other publication venues, and I think that's healthy. -Ekr [0] To some extent this is just path dependence, but it's also the case that different kinds of work demand different kinds of tools. To give just one example, cryptographic papers are full of symbols and almost invariably written in LaTeX, and for obvious reasons, cryptographers aren't excited about using the IETF's tools. On Sat, Jul 7, 2018 at 5:19 AM, John C Klensin wrote: > > > --On Friday, July 6, 2018 07:33 -0700 Eric Rescorla > wrote: > > >> There is one other benefit that I think we should not lose > >> sight of. Over the years (including well before there was > >> an IETF) "we" have presented the RFC Series as the go-to > >> place for technical specifications about what is used on the > >> Internet. > > > > > > Hmm... This seems to me to be true only if one has a pretty > > narrow definition of "on the Internet". Here are a few > > examples of things which get used on the Internet on a regular > > basis that aren't RFCs: > > Sure. I would agree if you had just said that presentation is > something of a myth, but suggest it is a myth that works in our > favor. We definitely don't have a monopoly. If we ever did, > it probably hasn't been since the late 70s or early 80s. In > particular... > > > - HTML (WHATWG and/or W3C) > > As you mention, there was an early version (or two?) of HTML > that we did publish in the RFC series. Then, after W3C decided > it wanted to be in the standards business after all, there was a > fairly explicit agreement and handoff. > > > - JavaScript (TC39) > > And ECMA (or whatever it is called now), and several other > places. > > > - H.264 (MPEG) > > - JPEG > > Content types, which we have rather explicitly said we don't > want beyond registering their names and pointers to their > descriptions. > > > - AES, P-256 (NIST) > > Yes. And incorporated into various of our protocols by > reference (and referenced from them). > > > - Bittorrent > > - Tor > > Both, IIR, things that, at one point or another, we decided we > didn't want. > > You left at least one thing off your list that is arguably as > important to today's Internet as several of those put together, > which is the internal protocols and mechanisms used by various > CDNs and other providers to > > > I spent a bunch of time trying to think of a characterization > > of the role of the RFC series (or the IETF's) role that was > > succinct, but in truth I think we're part of a broad coaltion > > of people publishing Internet protocol specificationswith > > somewhat fuzzily defined boundaries between the areas of work. > > I would agree with that. I don't think it changes my > underlying point any more than your list above does, but YMMD. > > >> Let me give an example that lies a bit outside the crypto > >> realm > > > > and that may therefore be easier for the rest of us to > >> understand. Suppose the IETF adopts a protocol that is > >> carefully designed for maximum privacy. Now suppose that > >> something comes along that is faster, lighter-weight, > >> supported or mandated by some governments but that protects > >> privacy from everyone but those governments (but leaves > >> information completely exposed to them). We can certainly > >> ignore the latter as just bad news but I contend we protect > >> our reputation and the privacy-safety of users, and make the > >> Internet better, far more by publishing its specs, explaining > >> the vulnerabilities it creates, and recommending against it > >> unless one is actually required to use it than by ignoring it. > > > This hypothetical contains a number of things "we" might do > > (publish the spec, critique it, recommend against it). I don't > > think it's actually a particular service to the world for us > > to publish the spec as long as it's readily found by other > > means. It's not clear to me how that helps. > > I think that depends a lot on the same issues that drove my > earlier note on which you asked for more details (haven't > forgotten that, just haven't been able to make time yet). "Not > actually a particular service" implies that everyone who might > be interested can follow links with ease, that there are no > advantages to a uniform format and style, that either one > doesn't care about these things for the long term (e.g., for > understanding the history of various protocol developments and > choices some years on) or that links never go bad, etc. I think > those things are important and have learned to be very > conservative (largely in the "conservation" sense) about them. > YMMD. > > > I certainly think > > critiquing it and recommending against it are good ideas > > (though depending on the technology, perhaps making something > > that had the good properties without the bad would be even > > better). > > If the bad stuff is already in wide use and especially if the > newer version is better but not obviously and overwhelmingly > better, both may be needed. More important, "X is better > than Y" is a much more absolute statement than many of the > design choices we face. In many situations, we are less likely > to have "the good properties without the bad" as an option but > find ourselves dealing with tradeoffs in which optimizing one > thing pessimizes another and we have to make tradeoffs. I > suggest that, at least in recent years, the IETF has been fairly > poor about being explicit about those choices, preferring to > either leave the information out in the hope that its choices > will be more accepted or just not wanting to take the time to > document them. I think that is unfortunate for those who need > to make choices in the marketplace, for our reputation as an > engineering-oriented body that is consistently trying to make > good overall choices for the Internet, and for the academic > considerations you mention in another context below. Again, > YMMD. > > > It's not clear to me that having those critiques in > > the RFC series is that helpful, though having the IETF > > recommend against the protocol (whether that recommendation > > was in an RFC or not) might well be. > > There are, as far as I know, only two ways to recommend against > a protocol. One is to do so on the basis of some clear > critique the other is to say some form of "you shouldn't use > this because we are the IETF, we know more about these things > than you do, and we are all-seeing and all-knowing". To me, the > latter is even worse that "we recommend this and against > everything else because we are a collection of government > representatives and we not only know more than you do but can > make you". And, btw, in case it hasn't be clear, I think > critiques of whatever the IETF decides on are at least as > important as IETF critiques as everything else. If nothing > else, if they are done well, they keep us honest and help > clarify the tradeoffs we are making. > > > With that said, this hypothetical isn't *that* far off the > > mark. Tor is a privacy protocol better than anything in the > > IETF (though to the best of my knowledge it doesn't have the > > negative properties of the protocol in your hypothetical). Its > > protocol is mostly defined by the implementation although > > there's a not-particularly clear spec. There are a pile of > > papers describing potential attacks. To the best of my > > knowledge, none of this is in the RFC series. From my > > perspective as a protocol implementer: > > > > - Having a good spec published would be valuable. Having it in > > the RFC series would not be particularly helpful, though it > > would not be harmful [0] - Having an IETF standard would > > probably be helpful depending on whether it improved Tor. It > > would likely lead to a clearer spec, which would be good. - > > Having the various attacks/critiques published in the RFC > > series would not be helpful. Currently, they are in > > peer-reviewed venues (e.g., IEEE Oakland) which do a better > > job of review than we do. Moreover, the academic community is > > where the conversation about the security of this type of > > protocol takes place. > > And should therefore probably stay there. My arguments would be > more relevant if the IETF decided to develop and standardize a > TORjunior and TORbis protocol and push it instead of the > original. I also suggest that the decision to use tor rather > than more traditional routing is also something that involves > tradeoffs, something of which at least parts of that research > community are aware, but which appear to be under-documented. > Probably that is ok in their context, but I'd hope that, when we > produce standards, we don't set such things aside. > > Incidentally, if you believe that other peer-reviewed venues, > such as IEEE Oakland in your example, consistently do a better > job of review than we do, that is a fairly good argument, not > for changing the labels on RFCs or constraining the ISE, but for > just stopping the efforts to make the RFC series more > academically credible and for abandoning the IRTF entirely. If > syntax models like HTML are better done elsewhere than in the > IETF, we should recognize that and hand them off (as we have, > explicitly). If specialized routing models like tor are better > explored and developed in parts of the academic community, then > we should encourage, not, resist that. From the other side, if > some protocol is developed and widely deployed in industry --for > their own reasons rather than as a way of doing an end run > around IETF review while seeking IETF endorsement anyway-- > decides that a particular protocol or syntax is better further > developed and curated by the IENT rather than continuing as an > industry-proprietary mechanism, then I think we should embrace > the transfer if it is within our normal scope. But, if you > believe our review mechanisms are not effective, or even just > not as effective as others that are out there, it is time to ask > much deeper questions that ones about the labels on documents. > > best, > john > > --0000000000002a807b05707459be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>
> --On Friday, July 6, 2018 07:33 -0700 Eric R= escorla
> <ekr@rtfm.com> wr= ote:
>
> >> There is one other benefit that I think we s= hould not lose
> >> sight of.=C2=A0=C2=A0 Over the years (inclu= ding well before there was
> >> an IETF) "we" have pr= esented the RFC Series as the go-to
> >> place for technical sp= ecifications about what is used on the
> >> Internet.
> &= gt;
> >
> > Hmm... This seems to me to be true only if = one has a pretty
> > narrow definition of "on the Internet&qu= ot;. Here are a few
> > examples of things which get used on the I= nternet on a regular
> > basis that aren't RFCs:
>
&= gt; Sure.=C2=A0=C2=A0 I would agree if you had just said that presentation = is
> something of a myth, but suggest it is a myth that works in our<= br>> favor

Well, I'm not sure I agree that it's something= "we" have generally
presented (though I'm sure that some = people have said this at
one time or another.) But in any case, it sound= s like we agree
that it's not true, and I don't think most peopl= e working
directly with protocol standards are likely to be confused
= on this point.


> We definitely don't have a monopoly.=C2= =A0 If we ever did,
> it probably hasn't been since the late 70s = or early 80s.=C2=A0=C2=A0 In
> particular...


> > - H= TML (WHATWG and/or W3C)
>
> As you mention, there was an early= version (or two?) of HTML
> that we did publish in the RFC series.= =C2=A0=C2=A0 Then, after W3C decided
> it wanted to be in the standar= ds business after all, there was a
> fairly explicit agreement and ha= ndoff.

Yes.


> > - JavaScript (TC39)
>
>= ; And ECMA (or whatever it is called now), and several other
> places= .

TC39 is an ECMA technical committee.


> > - H.264 = (MPEG)
> > - JPEG
>
> Content types, which we have ra= ther explicitly said we don't
> want beyond registering their nam= es and pointers to their
> descriptions.

Well, we standardized= OPUS, RFC 2083 describes OPUS,
and we currently have a videocodec WG, s= o I'm not sure
I agree we don't want media formats.


&= gt; > - AES, P-256 (NIST)
>
> Yes.=C2=A0 And incorporated i= nto various of our protocols by
> reference (and referenced from them= ).
>
> > - Bittorrent
> > - Tor
>
> B= oth, IIR, things that, at one point or another, we decided we
> didn&= #39;t want.

Potentially, though I don't recall this.


= > You left at least one thing off your list that is arguably as
> = important to today's Internet as several of those put together,
>= which is the internal protocols and mechanisms used by various
> CDN= s and other providers to

It wasn't intended to be an exhaustive = list.


> >> Let me give an example that lies a bit outsi= de the crypto
> >> realm
> >
> > and that ma= y therefore be easier for the rest of us to
> >> understand.=C2= =A0 Suppose the IETF adopts a protocol that is
> >> carefully d= esigned for maximum privacy.=C2=A0=C2=A0 Now suppose that
> >> = something comes along that is faster, lighter-weight,
> >> supp= orted or mandated by some governments but that protects
> >> pr= ivacy from everyone but those governments (but leaves
> >> info= rmation completely exposed to them).=C2=A0=C2=A0=C2=A0 We can certainly
= > >> ignore the latter as just bad news but I contend we protect> >> our reputation and the privacy-safety of users, and make th= e
> >> Internet better, far more by publishing its specs, expla= ining
> >> the vulnerabilities it creates, and recommending aga= inst it
> >> unless one is actually required to use it than by = ignoring it.
>
> > This hypothetical contains a number of t= hings "we" might do
> > (publish the spec, critique it, = recommend against it). I don't
> > think it's actually a p= articular service to the world for us
> > to publish the spec as l= ong as it's readily found by other
> > means. It's not cle= ar to me how that helps.
>
> I think that depends a lot on the= same issues that drove my
> earlier note on which you asked for more= details (haven't
> forgotten that, just haven't been able to= make time yet).=C2=A0=C2=A0 "Not
> actually a particular servic= e" implies that everyone who might
> be interested can follow li= nks with ease, that there are no
> advantages to a uniform format and= style, that either one
> doesn't care about these things for the= long term (e.g., for
> understanding the history of various protocol= developments and
> choices some years on) or that links never go bad= , etc.=C2=A0 I think
> those things are important and have learned to= be very
> conservative (largely in the "conservation" sens= e) about them.
> YMMD.

Indeed. I don't think there are *no= * advantages, but I think
they're pretty modest. Moreover, the unifo= rmity is pretty
superficial (7-bit ASCII, etc.) One need only look at th= e
QUIC specs to see an example of this, with TLS-style
PDU definition= s nestled next to ASCII art bit diagrams.



> > It's= not clear to me that having those critiques in
> > the RFC series= is that helpful, though having the IETF
> > recommend against the= protocol (whether that recommendation
> > was in an RFC or not) m= ight well be.
>
> There are, as far as I know, only two ways t= o recommend against
> a protocol.=C2=A0=C2=A0 One is to do so on the = basis of some clear
> critique the other is to say some form of "= ;you shouldn't use
> this because we are the IETF, we know more a= bout these things
> than you do, and we are all-seeing and all-knowin= g".

I'm not sure what you're responding to here. My pos= ition isn't
that the documents ought not to provide detailed critiqu= es,
but rather that it's not obviously important that they be
in = the RFC series. It's not clear to me that that's a relevant
fact= or.


> Incidentally, if you believe that other peer-reviewed v= enues,
> such as IEEE Oakland in your example, consistently do a bett= er
> job of review than we do, that is a fairly good argument, not> for changing the labels on RFCs or constraining the ISE, but for
&= gt; just stopping the efforts to make the RFC series more
> academica= lly credible and for abandoning the IRTF entirely.

Well, I wasn'= t offering it as an argument for anything in particular,
just stating my= opinion -- albeit one supported by considerable
evidence -- about where= the relevant work in critiquing a certain
class of protocols is publish= ed. Those critiques then get fed
into the IETF process. A good example o= f this is the development
of TLS 1.3, which was done in close collaborat= ion with the academic
community and led to quite a few academic papers w= hich then influenced
the design of the protocol. Appendix E of the TLS d= raft provides
citations to quite a bit of this work:

https://tool= s.ietf.org/html/draft-ietf-tls-tls13-28#appendix-E

With that sai= d, at least in my field, I think the IRTF (specifically
the CFRG) is ser= ving an important function in terms of liaising
between the academic com= munity and the IETF protocol development
community, so I don't think= it would be good to shut down that
piece of the IRTF. Despite that, the= academics who do cryptography
tend to publish that work in academic con= ferences and then
later it may get transcribed into an RFC in IRTF.
<= br>
> If
> syntax models like HTML are better done elsewhere th= an in the
> IETF, we should recognize that and hand them off (as we h= ave,
> explicitly).=C2=A0 If specialized routing models like tor are = better
> explored and developed in parts of the academic community, t= hen
> we should encourage, not, resist that.

I fear you may be= misunderstanind me. For context, here's what
I said:

=C2=A0= =C2=A0=C2=A0 would not be harmful [0] - Having an IETF standard would
= =C2=A0=C2=A0=C2=A0 probably be helpful depending on whether it improved Tor= . It
=C2=A0=C2=A0=C2=A0 would likely lead to a clearer spec, which would= be good. -
=C2=A0=C2=A0=C2=A0 Having the various attacks/critiques publ= ished in the RFC
=C2=A0=C2=A0=C2=A0 series would not be helpful. Current= ly, they are in
=C2=A0=C2=A0=C2=A0 peer-reviewed venues (e.g., IEEE Oakl= and) which do a better
=C2=A0=C2=A0=C2=A0 job of review than we do. More= over, the academic community is
=C2=A0=C2=A0=C2=A0 where the conversatio= n about the security of this type of
=C2=A0=C2=A0=C2=A0 protocol takes p= lace.

My point is not that things like Tor are better developed in t= he
academic community but rather that the development of protocol
sta= ndards -- at least in the area of communication security --
involves a n= umber of different types of technical work
(protocol specification, anal= ysis, verification, prototyping, etc.
That work is done by a number of c= ommunities that overlap to
some extent, and each community has its conve= ntional venues for
sharing its work [0]. So, when those communities coll= aborate,
it involves publication in multiple venues.

To return to= the TLS 1.3 example:

- The protocol development itself happened in = conventional IETF
=C2=A0 venues (mailing lists, meetings, etc.) but also= on Github.
- Implementation coordination was done over Slack, Github,=C2=A0 hackathons, etc.
- Analysis was done in academic-type venues (e= print, conferences,
=C2=A0 workshops, etc.)

The RFC series (and a= lso I-Ds) have an important role to play here,
but it also exists in con= versation with a lot of other publication
venues, and I think that's= healthy.

-Ekr


[0] To some extent this is just path depen= dence, but it's also
the case that different kinds of work demand di= fferent kinds of
tools. To give just one example, cryptographic papers a= re
full of symbols and almost invariably written in LaTeX, and
for ob= vious reasons, cryptographers aren't excited about
using the IETF= 9;s tools.







=
On Sat, Jul 7, 2018 at 5:19 AM, John C Klens= in <john-ietf@jck.com> wrote:


--On Friday, July 6, 2018 07:33 -0700 Eric Rescorla
<ekr@rtfm.com> w= rote:

>> There is one other benefit that I think we should not lose
>> sight of.=C2=A0 =C2=A0Over the years (including well before there = was
>> an IETF) "we" have presented the RFC Series as the go-to=
>> place for technical specifications about what is used on the
>> Internet.
>
>
> Hmm... This seems to me to be true only if one has a pretty
> narrow definition of "on the Internet". Here are a few
> examples of things which get used on the Internet on a regular
> basis that aren't RFCs:

Sure.=C2=A0 =C2=A0I would agree if you had just said that presentati= on is
something of a myth, but suggest it is a myth that works in our
favor.=C2=A0 =C2=A0We definitely don't have a monopoly.=C2=A0 If we eve= r did,
it probably hasn't been since the late 70s or early 80s.=C2=A0 =C2=A0In=
particular...

> - HTML (WHATWG and/or W3C)

As you mention, there was an early version (or two?) of HTML
that we did publish in the RFC series.=C2=A0 =C2=A0Then, after W3C decided<= br> it wanted to be in the standards business after all, there was a
fairly explicit agreement and handoff.

> - JavaScript (TC39)

And ECMA (or whatever it is called now), and several other
places.

> - H.264 (MPEG)
> - JPEG

Content types, which we have rather explicitly said we don't
want beyond registering their names and pointers to their
descriptions.

> - AES, P-256 (NIST)

Yes.=C2=A0 And incorporated into various of our protocols by
reference (and referenced from them).

> - Bittorrent
> - Tor

Both, IIR, things that, at one point or another, we decided we
didn't want.

You left at least one thing off your list that is arguably as
important to today's Internet as several of those put together,
which is the internal protocols and mechanisms used by various
CDNs and other providers to

> I spent a bunch of time trying to think of a characterization
> of the role of the RFC series (or the IETF's) role that was
> succinct, but in truth I think we're part of a broad coaltion
> of people publishing Internet protocol specificationswith
> somewhat fuzzily defined boundaries between the areas of work.

I would agree with that.=C2=A0 =C2=A0I don't think it changes my=
underlying point any more than your list above does, but YMMD.

>> Let me give an example that lies a bit outside the crypto
>> realm
>
> and that may therefore be easier for the rest of us to
>> understand.=C2=A0 Suppose the IETF adopts a protocol that is
>> carefully designed for maximum privacy.=C2=A0 =C2=A0Now suppose th= at
>> something comes along that is faster, lighter-weight,
>> supported or mandated by some governments but that protects
>> privacy from everyone but those governments (but leaves
>> information completely exposed to them).=C2=A0 =C2=A0 We can certa= inly
>> ignore the latter as just bad news but I contend we protect
>> our reputation and the privacy-safety of users, and make the
>> Internet better, far more by publishing its specs, explaining
>> the vulnerabilities it creates, and recommending against it
>> unless one is actually required to use it than by ignoring it.

> This hypothetical contains a number of things "we" might do<= br> > (publish the spec, critique it, recommend against it). I don't
> think it's actually a particular service to the world for us
> to publish the spec as long as it's readily found by other
> means. It's not clear to me how that helps.

I think that depends a lot on the same issues that drove my
earlier note on which you asked for more details (haven't
forgotten that, just haven't been able to make time yet).=C2=A0 =C2=A0&= quot;Not
actually a particular service" implies that everyone who might
be interested can follow links with ease, that there are no
advantages to a uniform format and style, that either one
doesn't care about these things for the long term (e.g., for
understanding the history of various protocol developments and
choices some years on) or that links never go bad, etc.=C2=A0 I think
those things are important and have learned to be very
conservative (largely in the "conservation" sense) about them. YMMD.

> I certainly think
> critiquing it and recommending against it are good ideas
> (though depending on the technology, perhaps making something
> that had the good properties without the bad would be even
> better).

If the bad stuff is already in wide use and especially if the
newer version is better but not obviously and overwhelmingly
better, both may be needed.=C2=A0 =C2=A0 =C2=A0More important, "X is b= etter
than Y" is a much more absolute statement than many of the
design choices we face.=C2=A0 In many situations, we are less likely
to have "the good properties without the bad" as an option but find ourselves dealing with tradeoffs in which optimizing one
thing pessimizes another and we have to make tradeoffs.=C2=A0 I
suggest that, at least in recent years, the IETF has been fairly
poor about being explicit about those choices, preferring to
either leave the information out in the hope that its choices
will be more accepted or just not wanting to take the time to
document them.=C2=A0 =C2=A0I think that is unfortunate for those who need to make choices in the marketplace, for our reputation as an
engineering-oriented body that is consistently trying to make
good overall choices for the Internet, and for the academic
considerations you mention in another context below.=C2=A0 Again,
YMMD.

> It's not clear to me that having those critiques in
> the RFC series is that helpful, though having the IETF
> recommend against the protocol (whether that recommendation
> was in an RFC or not) might well be.

There are, as far as I know, only two ways to recommend against
a protocol.=C2=A0 =C2=A0One is to do so on the basis of some clear
critique the other is to say some form of "you shouldn't use
this because we are the IETF, we know more about these things
than you do, and we are all-seeing and all-knowing".=C2=A0 To me, the<= br> latter is even worse that "we recommend this and against
everything else because we are a collection of government
representatives and we not only know more than you do but can
make you".=C2=A0 And, btw, in case it hasn't be clear, I think
critiques of whatever the IETF decides on are at least as
important as IETF critiques as everything else.=C2=A0 If nothing
else, if they are done well, they keep us honest and help
clarify the tradeoffs we are making.

> With that said, this hypothetical isn't *that* far off the
> mark. Tor is a privacy protocol better than anything in the
> IETF (though to the best of my knowledge it doesn't have the
> negative properties of the protocol in your hypothetical). Its
> protocol is mostly defined by the implementation although
> there's a not-particularly clear spec. There are a pile of
> papers describing potential attacks. To the best of my
> knowledge, none of this is in the RFC series. From my
> perspective as a protocol implementer:
>
> - Having a good spec published would be valuable. Having it in
> the RFC series would not be particularly helpful, though it
> would not be harmful [0] - Having an IETF standard would
> probably be helpful depending on whether it improved Tor. It
> would likely lead to a clearer spec, which would be good. -
> Having the various attacks/critiques published in the RFC
> series would not be helpful. Currently, they are in
> peer-reviewed venues (e.g., IEEE Oakland) which do a better
> job of review than we do. Moreover, the academic community is
> where the conversation about the security of this type of
> protocol takes place.

And should therefore probably stay there.=C2=A0 My arguments would b= e
more relevant if the IETF decided to develop and standardize a
TORjunior and TORbis protocol and push it instead of the
original.=C2=A0 I also suggest that the decision to use tor rather
than more traditional routing is also something that involves
tradeoffs, something of which at least parts of that research
community are aware, but which appear to be under-documented.
Probably that is ok in their context, but I'd hope that, when we
produce standards, we don't set such things aside.=C2=A0

Incidentally, if you believe that other peer-reviewed venues,
such as IEEE Oakland in your example, consistently do a better
job of review than we do, that is a fairly good argument, not
for changing the labels on RFCs or constraining the ISE, but for
just stopping the efforts to make the RFC series more
academically credible and for abandoning the IRTF entirely.=C2=A0 If
syntax models like HTML are better done elsewhere than in the
IETF, we should recognize that and hand them off (as we have,
explicitly).=C2=A0 If specialized routing models like tor are better
explored and developed in parts of the academic community, then
we should encourage, not, resist that.=C2=A0 =C2=A0From the other side, if<= br> some protocol is developed and widely deployed in industry --for
their own reasons rather than as a way of doing an end run
around IETF review while seeking IETF endorsement anyway--
decides that a particular protocol or syntax is better further
developed and curated by the IENT rather than continuing as an
industry-proprietary mechanism, then I think we should embrace
the transfer if it is within our normal scope.=C2=A0 =C2=A0 But, if you
believe our review mechanisms are not effective, or even just
not as effective as others that are out there, it is time to ask
much deeper questions that ones about the labels on documents.

best,
=C2=A0 =C2=A0 john


--0000000000002a807b05707459be-- From nobody Sun Jul 8 12:47:19 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193BF130E29 for ; Sun, 8 Jul 2018 12:47:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eR_YKntjvkdR for ; Sun, 8 Jul 2018 12:47:10 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885211310F0 for ; Sun, 8 Jul 2018 12:47:10 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fcFeE-000Lv7-2o; Sun, 08 Jul 2018 15:47:06 -0400 Date: Sun, 08 Jul 2018 15:46:59 -0400 From: John C Klensin To: Eric Rescorla cc: Benjamin Kaduk , Eliot Lear , rfcplusplus@ietf.org Message-ID: <61A4AB9DBA384CEDB8C0134F@PSB> In-Reply-To: References: <2c8871ae-f4c4-40bd-296a-f52b4adbe385@cisco.com> <20180704173703.GJ60996@kduck.kaduk.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 19:47:13 -0000 Eric, I don't think we are going to agree on many of these things. This note, responding to yours of several days ago, is an attempt to explore some of the places where or perspectives differ (whether that leads to actual disagreement or not) in the hope of informing the conversation a bit. I don't know that turning it into a lengthy discussion is worth either of our efforts, but I'm prepared to be convinced otherwise. --On Wednesday, July 4, 2018 12:16 -0700 Eric Rescorla wrote: > Hi John, > > I think you're onto something important here: in the nearly 40 > years since the RFC series began, the economics of publishing > stuff have changed pretty radically. > > In particular, it's become far cheaper to publish documents > which: > > - Are widely available > - Have a reasonable story about ongoing availability Yes, although our criteria "ongoing availability" may well be different. In particular, if a document is intended to provide information for implementation on the Internet, ten or fifteen years is typically more than enough, even though there are exceptions (SMTP, with which I have some experience, is fairly clearly one of them despite predictions that IM, Twitter, etc., will replace it soon). Even then, there are some oddities. Picking an example that has almost nothing to do with the IETF, if I were trying to write a program to determine if a new files, as they arrive, were identical to ones I already had in a repository (that mostly contained fairly large files), I'd look to find a hash with a good many information bits and a generation algorithm that was hard to fake (for reasons and with details you can certainly explain better than I can). However, I ran into a program a few weeks ago that is support just that sort of duplication detection and it is quite a bit faster than those that use contemporary hashes. Turns out that it is relying on simple additive-digit checksums. Now I know what those are and you are probably old enough that you do too, but I'd lay good odds that there are people around the IETF who would need to look the algorithm up in order to figure out if they are really adequate and why not. I just did a Google search on "checksum" and, on the first page, found several definitions that were wrong of misleading in different ways as well as one correct answer. Unless one already knows the answer, picking which of those is authoritative is hard. So, while it clearly isn't the IETF's fault, that one flunks "ongoing availability". More important to me (but not necessarily others reading this), some of us are concerned about the historical record in which the issue may be decades or even centuries rather than a few years. Every time someone claims the Web is the most important invention, at least to knowledge dissemination, since Gutenberg, some of us start thinking about a need to preserve things at least as long, i.e., for a minimum of five or six centuries and maybe for times comparable to ink on sheepskin or papyrus under good storage conditions. > - Are referentially stable; specifically, if the document is > available in the future, you can be sure that you have > the right document [0]. > [0] It's also much easier to publish documents which are > referentially unstable in the sense that you get the > most up-to-date version, which is a source of confusion. Yes. The RFC Series has been rather good at the first (in part because there has been an "archival" requirement since before there was an IETF). Things like STD numbers are intended to solve the latter requirement if that is what one wants, even though they have not worked well for reasons that have been discussed elsewhere. It is not clear where new sets of number series would leave us except that, if we were to create a new numbering series, put documents in it (without RFC numbers) and then abandoned the experiment, went back to RFC numbers, and dropped the new system (or connected it to links that eventually stopped working, we would have lost on both referential approaches). I hope we can also agree that, in the general case, whatever URLs are, they don't provide much in the way of referential stability (with the IETF web site as, IMO, a sad example). > At the same time, it hasn't gotten much cheaper to produce > documents which have multistakeholder consensus (I assume some > would argue it has gotten more expensive, but I think we can > all agree it hasn't gotten cheaper at the rate that publishing > has). So, I still think there is real value in having a > mechanism for ensuring that documents have that level of > review and consensus (leaving aside how that mechanism works, > though I'd be happy to get into that in a separate note). It also hasn't gotten much cheaper to produce documents that are of high quality editorially, including checks for ambiguous language and, where that is important, easy translatability. I think that has been a goal for the RFC Series. It is certainly a goal for, e.g., ISO Standards even when there is agreement to publish in only one language. How well we have been doing is a separate question, of course. > Narrowing this to the question of code point registration: Many > protocols have large code point spaces so there's no need to > restrict code point assignments in order to conserve space. In > at least some of these protocols, we've come to the conclusion > that restricting code point assignment in order to prevent > people from making ill-advised extensions doesn't work well > (people just squat and you get a mess). Indeed. Having made the argument that excessive restrictions and complex procedures just lead to squatting and less-available documentation several times in cases when the IETF has moved from a requirement for IETF approval to much more flexible procedures that focus more on quality of descriptions, I'd be in bad trouble if I didn't agree. Where we may disagree is about what "extension" means in terms of the base protocol specification. We use that term for at least two different kinds of situations. In one the extension(s) change, or might change, the semantics of the base protocol, particularly in a way that might be confusing or harmful to those who are not opting to use that extension itself. In the other, they are just add-ons: additional parameters, values, options, etc., that can be used with the base specification but don't need to be and that have no effect on the unextended base protocol (or syntax, or whatever) if not used. If the base protocol is an IETF specification, I suggest that the review process has failed, perhaps seriously, if that distinction is not clear from the text, usually in the IANA Considerations Section and that, if that section says "specification required" or "FCFS", we had better be dealing with one of the second set of cases. > We could deal with this by just allowing registrations to be > FCFS, but there was a general feeling that it wasn't great to > have code points exist with no way for people to know what > they meant, so we concluded that there ought to be some > reference to a document describing the meaning of the > extension, and that one ought to be able to have a good chance > of finding the document. I take this to be the spirit of RFC > 8126 specification required. Specifically: > > The intention behind "permanent and readily available" is > that a document can reasonably be expected to be findable > and retrievable long after IANA assignment of the requested > value. Publication of an RFC is an ideal means of > achieving this requirement, but Specification Required is > intended to also cover the case of a document published > outside of the RFC path, including informal documentation. See above. And... > I think it's clear that this definition would encompass a link > to a blog or a github repository ("informal publication") as > long as that was referentially stable. I agree that that the > text we use to describe I-Ds suggests that these properties > don't apply to I-Ds, but I would submit that as a practical > matter, I-Ds (as long as they are referenced by version) do > have these properties at least as much as a blog entry or > Github link does. It's for that reason that we opted to allow > this in TLS (and, I expect, in other groups going forward). Again, my criteria for referential stability and accessibility may be different from yours (and probably are). I don't think a link to a github repository is acceptable because there are no long-term stability guarantees there and in particular, whomever has write access on the particular repository can (and, in my experience, often do) change the document out from under the link. In most case, those changes are for the better, but no guarantees. Blogs depend on the blog and the repository; I don't think it is possible to make a general statement. I-Ds are actually better than either from that point of view because, at least so far, once an I-D is posted with a particular name and version number, we don't do back an alter them (although they can be removed from the archive even though I don't think we have done that for some years. But that is where the historical perspective comes back in. For the RFC Series, we've made "archival" promises, something that the current RSE has extended by making some specific arrangements with depository libraries. If, e.g., the IETF and the earthquake-prone coast of the US vanish from the face of the earth, the RFC Series will still be available in an organized and accessible form. If there are any similar guarantees about Internet-Drafts, I'm not aware of them. I hope I'm wrong, but my guess is that the IETF's agreement with its current cloud provider doesn't specify preservation of the I-D archives significantly beyond when we stop paying the bills. And I'm pessimistic enough about these sorts of things to not have high confidence that the IETF will be around forever or even for another few decades. > From your email, I take it that you don't think this is > generally a good idea. Can you explain a bit more why in light > of the comments above? See if the above helps. And, again, if the TLS WG decided that referencing I-Ds was the right thing to do and the IESG, after due consideration, agreed, I have no inclination to second-guess the decision. But not, in the general case, I don't think it is a good idea. best, john From nobody Sun Jul 8 13:21:50 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA72E130E6C for ; Sun, 8 Jul 2018 13:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 j_SZPJP0i36k for ; Sun, 8 Jul 2018 13:21:45 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9B6130DF0 for ; Sun, 8 Jul 2018 13:21:44 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id k18-v6so5872310ywm.11 for ; Sun, 08 Jul 2018 13:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dJNMlavQMcFHQqOAGbzGcmwCZAYTRHCOtkgnduzCptc=; b=g8T0cqAg3TK2C8Fr1DteE4u9SWZRO88sbWNIv7IM6zHhr4uvcphTvyRj+uQiuLAf/O gJwsV5lEBDAdG7aoOX9L56eTCpPs0WEBtEqHKOfPVoohpCTP5BYuvbUpEyy8bhTUUQz8 V1hyJ45nI9lk3znow3nz2QfI1mGZ2k5TbYUv/SYLUOgAZrt3s8r1qy54P4H+5a01LFaI EdJ8q/lMfVxQuzKQdBeHHifGpzzDn7uOZeLtws7JYIJaTGgci1Z/7+zFmFW1bysB7j77 rvQMMGUASd99gxFHWheF74igMK6uymcmvyKs/dJmg54eGPYgJsHGng87AX4HhOHmUmHq fIWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dJNMlavQMcFHQqOAGbzGcmwCZAYTRHCOtkgnduzCptc=; b=r91MgUpfI+p/5QAaIdXhNYLnhyMKABkSTWD3qW6PWpjGB7sJi9wKxWMBKeUIbVt8TP 2rax/XV0mXLmNU+vGI6XzgwGGotOJUr3hey2hSZq/iDI3W+1IotftTSbxvQSXfCG5leX 9BjH2XFpbkWIIpReo/xeiIaZkbDyd09B1qvXaH2l7udjYRXncozNQFlceBUdIvjbIzXQ T3O42wx66mnr5yZRmATNM+w5/NIIsRoU6ruHRRudmGuR3otSmHSAI1N5urMT8g663klK e3FQo2R5EjIFg3tWRrBPexAWsVECqBTrGfRU2nqYLHPOFgmjLLHF73CQ1F5gQTHuwrGs uDAw== X-Gm-Message-State: APt69E1gvXN+W0x4Cpm4A5Xu9CShHsP9vbi+y3oFKheJqnqLdB9eEL7M 18Z15kiYgDt5BTG+vwLhVDpoAreJ3TEMuPTbcbCKPQ== X-Google-Smtp-Source: AAOMgpc+laJ1CBGLWL8Tcr+fjxNn7OTUgqah/WavozPhMEr8JJXdvpjX5hVKgug391ng10iwXYCAIt2M80CoVEJn3Bg= X-Received: by 2002:a81:a9c4:: with SMTP id g187-v6mr6434115ywh.238.1531081304096; Sun, 08 Jul 2018 13:21:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Sun, 8 Jul 2018 13:21:03 -0700 (PDT) In-Reply-To: <61A4AB9DBA384CEDB8C0134F@PSB> References: <2c8871ae-f4c4-40bd-296a-f52b4adbe385@cisco.com> <20180704173703.GJ60996@kduck.kaduk.org> <61A4AB9DBA384CEDB8C0134F@PSB> From: Eric Rescorla Date: Sun, 8 Jul 2018 13:21:03 -0700 Message-ID: To: John C Klensin Cc: Benjamin Kaduk , Eliot Lear , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000040d9b1057082a5ae" Archived-At: Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 20:21:49 -0000 --00000000000040d9b1057082a5ae Content-Type: text/plain; charset="UTF-8" John, Thanks for your response. It does clarify your thinking. Ultimately, I think it comes down to our respective views of the required level of temporal stability for standards documents, so it's probably not worth going into much more depth here. With that said, I do want to bring out one point. On Sun, Jul 8, 2018 at 12:46 PM, John C Klensin wrote: > > I think it's clear that this definition would encompass a link > > to a blog or a github repository ("informal publication") as > > long as that was referentially stable. I agree that that the > > text we use to describe I-Ds suggests that these properties > > don't apply to I-Ds, but I would submit that as a practical > > matter, I-Ds (as long as they are referenced by version) do > > have these properties at least as much as a blog entry or > > Github link does. It's for that reason that we opted to allow > > this in TLS (and, I expect, in other groups going forward). > > Again, my criteria for referential stability and accessibility > may be different from yours (and probably are). I don't think > a link to a github repository is acceptable because there are no > long-term stability guarantees there and in particular, whomever > has write access on the particular repository can (and, in my > experience, often do) change the document out from under the > link. Well, sort of. It's quite straightforward to produce links to Github repositories that have a higher guarantee of referential stability than RFCs do: you simply reference the commit-id which is a hash. So, the repo might be removed but it's not practical (as long as SHA-1 remains strong) to change the contents. In most case, those changes are for the better, but no > guarantees. Blogs depend on the blog and the repository; I > don't think it is possible to make a general statement. I-Ds > are actually better than either from that point of view because, > at least so far, once an I-D is posted with a particular name > and version number, we don't do back an alter them (although > they can be removed from the archive even though I don't think > we have done that for some years. > This is certainly a reasonable perspective, but I don't really see how to square it with the 8126 language of "reasonably be expected" and "informal publication". So if your position is that I-Ds don't meet the Specification Required bar, I'm left wondering what sorts of "informal publication" do. Can you elaborate? -Ekr --00000000000040d9b1057082a5ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
John,

Thanks for your respon= se. It does clarify your thinking. Ultimately, I think it comes down to our= respective views of the required level of temporal stability for standards= documents, so it's probably not worth going into much more depth here.= With that said, I do want to bring out one point.

=

On Sun, Jul 8, 20= 18 at 12:46 PM, John C Klensin <john-ietf@jck.com> wrote:
> I think it's clear that this definition would encompass a link
> to a blog or a github repository ("informal publication") as=
> long as that was referentially stable. I agree that that the
> text we use to describe I-Ds suggests that these properties
> don't apply to I-Ds, but I would submit that as a practical
> matter, I-Ds (as long as they are referenced by version) do
> have these properties at least as much as a blog entry or
> Github link does. It's for that reason that we opted to allow
> this in TLS (and, I expect, in other groups going forward).

Again, my criteria for referential stability and accessibility
may be different from yours (and probably are).=C2=A0 =C2=A0 I don't th= ink
a link to a github repository is acceptable because there are no
long-term stability guarantees there and in particular, whomever
has write access on the particular repository can (and, in my
experience, often do) change the document out from under the
link.

Well, sort of. It's quite straigh= tforward to produce links to Github repositories that have a higher guarant= ee of referential stability than RFCs do: you simply reference the commit-i= d which is a hash. So, the repo might be removed but it's not practical= (as long as SHA-1 remains strong) to change the contents.


=C2=A0 =C2=A0In most case= , those changes are for the better, but no
guarantees.=C2=A0 Blogs depend on the blog and the repository; I
don't think it is possible to make a general statement.=C2=A0 I-Ds
are actually better than either from that point of view because,
at least so far, once an I-D is posted with a particular name
and version number, we don't do back an alter them (although
they can be removed from the archive even though I don't think
we have done that for some years.

This = is certainly a reasonable perspective, but I don't really see how to sq= uare it with the 8126 language of "reasonably be expected" and &q= uot;informal publication". So if your position is that I-Ds don't = meet the Specification Required bar, I'm left wondering what sorts of &= quot;informal publication" do. Can you elaborate?

=
-Ekr




--00000000000040d9b1057082a5ae-- From nobody Mon Jul 9 01:01:42 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EECB130E14 for ; Mon, 9 Jul 2018 01:01:39 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 LnkPU74pF0kX for ; Mon, 9 Jul 2018 01:01:38 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD01C1277CC for ; Mon, 9 Jul 2018 01:01:37 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fcR72-000OR1-Fo; Mon, 09 Jul 2018 04:01:36 -0400 Date: Mon, 09 Jul 2018 04:01:31 -0400 From: John C Klensin To: Alissa Cooper cc: rfcplusplus@ietf.org Message-ID: In-Reply-To: References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 08:01:40 -0000 --On Friday, July 6, 2018 09:33 -0400 Alissa Cooper wrote: >> Now, it might be thought (this is possibly a branding thing) >> that the further from looking like an IETF consensus document >> the less we have to care about the "protocol conflict >> problem", but I would argue that the less input the IESG has, >> the more we have to worry. Thus, were an alternative venue >> for publishing competing specifications to be developed, I >> would claim that this is harmful to the RFC band and to both >> the IETF's brand and raison d'=C3=AAtre.=20 >=20 > I'm not following this. If someone cares about how the > Internet works, then having a poorly designed specification > that risks the Internet's stability published in any venue > is a problem.=20 It seems to me that view makes a strong argument for having as many specifications as possible in the RFC Series (or perhaps some equivalent series controlled by the RFC Editor) so that we, as a community can exercise at least some control over both technical and editorial quality. However --and here we may have to agree to disagree-- I'd much rather see it published with either an IESG note that says "this is a terrible idea because..." or with a separate critique (ideally at the same time and with a consecutive RFC number) that explains why it is a bad idea than drive the author into some other publication venue or even some competitive standards body where the risk to the Internet's stability might be much higher and we are in no position to comment. > That doesn't mean the IESG or any individual > participant is necessarily going to be able to address that > problem, but it's still a problem. Having that specification > labeled with "RFC" means the IESG and the IETF face the > potential additional problem of having the specification > confused for an IETF consensus output. As I've said earlier in more detail, there are two kinds of users of specifications, those who actually look at them and those who don't. For those who do, while there is lots of generic evidence that people skim over boilerplate that appears, superficially, on every document, there is no evidence that they do not read and understand carefully-written and specification-specific disclaimers and critiques. In that regard, the following are possibilities in ascending order of usefulness and likely effectiveness. (i) This is not an IETF consensus specification (ii) This specification conflicts with IETF consensus specifications. (iii) This specification conflicts with IETF consensus specifications documented in XXX, YYY, and ZZZ. (iv) This specification conflicts with IETF consensus specifications documented in XXX, YYY, and ZZZ. This approach is considered a less desirable approach than those because... and dangerous to the stability of the Internet because ... IMO, if published documents continue to bear copyright notices and rights statements connected to the IETF Trust and IETF, the odds that simply changing labels (at least for those who read the documents) will be any more effective that (i) --which we are already doing-- is just about zero because, if the IETF claims to be the publisher of the document, any risks of having the IETF be blamed aren't going to be changed. =20 For the people who don't read the specifications themselves, I've argued elsewhere that they will be subject to deliberate deception about the IETF status of the documents even if they are only posted as I-Ds (or, perhaps, in I-D format with the author contemplating posting them as I-Ds. We have seen such claims in the past, so that is not speculation. > Alternative venues for publishing competing specifications > already exist (e.g., https://url.spec.whatwg.org/ > ). They may or may not be > harmful to the Internet, but I don't see how they're > specifically harmful to the RFC brand. They're certainly not > more harmful to the RFC brand than competing specifications > labeled "RFC." No, they probably aren't. But, using that example, they may be far more harmful to the Internet, if only because WHATWG tends to be narrowly focused on the web and to essentially be a consortium of a small number of vendors. That has some advantages but (apparently) doesn't give them the perspective needed to say "that might make a web browser work better, but will reduce overall Internet performance or stability" or any of the other things that we claim and hope can come out of cross-area review. As to the harm caused by competing specifications labeled "RFC", it seems to me that "harm" is a much stronger claim than "confusion about whether something is an IETF consensus specification or not". It would seem to imply that the technical review processes used in at least the IRTF and Independent Streams are intrinsically of lower quality than the IETF one. As far as I can tell (but I don't watch them at all closely), the IRTF does a rather good job within its area of scope. And, while some things have been published that I don't like or for which I would have suggested additional work, I think Nevil and, so far, Adrian have done an outstanding job of assembling and using editorial review processes and reviewers of very high quality and to stand by a principle that, if reviewers and reviews of sufficient quality cannot be found, the document does not get published. By contrast, recent years have shown us several examples of WGs with small numbers of active participants, all or almost all from the same cooperating cluster of companies and more than a few AD-sponsored documents that have made it through the system with substantially no substantive community input on IETF Last Call and then get through the IESG with the minimum number of "yes" votes and many "no objections", presumably deferring to the AD who made the decision to sponsor the document. =20 If we think the kind of renaming that is being proposed is needed to differentiate between documents that are published with IETF consensus and those that are not, I suggest that the IESG should eliminate AD Sponsored documents entirely (or at least push them off into another series) and establish criteria for breadth and balance in WGs, dealing differently with those that don't obviously manifest those properties. best, john From nobody Mon Jul 9 06:04:36 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B541130E08 for ; Mon, 9 Jul 2018 06:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 UsBxBq22xRRp for ; Mon, 9 Jul 2018 06:04:31 -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 2E5CE126CB6 for ; Mon, 9 Jul 2018 06:04:31 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w69D4OvB017217; Mon, 9 Jul 2018 14:04:25 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 960412204E; Mon, 9 Jul 2018 14:04:24 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 7FB5222048; Mon, 9 Jul 2018 14:04:24 +0100 (BST) Received: from 950129200 (6.152.51.84.dyn.plus.net [84.51.152.6] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id w69D4NfG027343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2018 14:04:23 +0100 Reply-To: From: "Adrian Farrel" To: "'Alissa Cooper'" Cc: References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> In-Reply-To: Date: Mon, 9 Jul 2018 14:04:24 +0100 Message-ID: <03e201d41785$5cb85320$1628f960$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG0HSINijmUip1fsXvoWMMwPJekRwHhPMxEpLe8ZeA= Content-Language: en-gb X-Originating-IP: 84.51.152.6 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23956.006 X-TM-AS-Result: No--10.203-10.0-31-10 X-imss-scan-details: No--10.203-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23956.006 X-TMASE-Result: 10--10.203100-10.000000 X-TMASE-MatchedRID: 6lay9u8oTUMtqx4vLVZ3FvHkpkyUphL9R9R86+kr2LBgg+UjPGL1RXFD 0I0jlEDdnj1DDyg14U5ZpgBZgcDt6zat+PrxTZ+F7DzBuedLDxsg53nwyuJ3/v9b1MifZCVyXtV 5JugI/orsKmXeqOVUMM9yPhsCXZKwoLRtQ0gFiJKiI3xhOar5y0MYW8F4HadczLaOlkXoxeVvlt Sm4q5U27D5OgnGfFVfTm8XI5YTRTYemLejT6iiQ7kM+JfpduJWGSqdEmeD/nUWug0bekn/33LMR Sx26gTikYxBLdqQ2bKN/HIAigZQwT+0CTVqlSZU3FqOVb7PDEK/yN2q8U674g8x3RwK3jjFfCxP mMXdYL4+b5powLiZtyDNvnwPc2ZNH5chC2o3feKdVNZaI2n6/+Bgp+G3IXxrG0N1z/ycuLL5tGE /m3Vqrm9bx5wyIexDPjx6vHt5yN6/WXZS/HqJ2gtuKBGekqUpI/NGWt0UYPDtWSsVPe9qq4k4H0 byd5L04TL3JTnKg+YISzR5O5lXiq8e8eBqaP6r X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 13:04:35 -0000 [snip] >> Now, it might be thought (this is possibly a branding thing) that the = further from=20 >> looking like an IETF consensus document the less we have to care = about the=20 >> "protocol conflict problem", but I would argue that the less input = the IESG has, >> the more we have to worry. Thus, were an alternative venue for = publishing >> competing specifications to be developed, I would claim that this is = harmful >> to the RFC brand and to both the IETF's brand and raison d'=C3=AAtre. = > > I=E2=80=99m not following this. If someone cares about how the = Internet works, then > having a poorly designed specification that risks the = Internet=E2=80=99s stability published > in any venue is a problem. That doesn=E2=80=99t mean the IESG or any = individual=20 > participant is necessarily going to be able to address that problem, = but it=E2=80=99s still a > problem. Having that specification labeled with =E2=80=9CRFC=E2=80=9D = means the IESG and the=20 > IETF face the potential additional problem of having the specification = confused > for an IETF consensus output. I'm trying to avoid looping the discussion or coming to any early = conclusions on the right answer, but I will push again on this... I believe I read you as saying that the IESG would not, as a matter of = course, read or consider FOO9002 on its way to publication if that = publication is out of the IETF Stream. They would not expect to be = notified of the progress of that work towards publication. In some = cases, the IESG might become aware of the work and have comments that = they wish to send to the publish body (such as, through a liaison = statement). While the IESG might have some hope of being listened to, = they would have no expectation of that, and would, in particular, not = request the inclusion of an "IESG Note" in any such document. That was the clarity I was hoping for. My point about branding was manifold: - The IETF would like to remain *the* source for documents that describe = and define the Internet. Any action that weakens that (such as by giving = another venue or publication) is unfortunate. - The IESG would like to remain authoritative evaluators and = commentators on the merit and consensus of Internet standards - "RFC" as a label may cause confusion as to the source of the work, but = buys the ability to influence the content by review and input. > Alternative venues for publishing competing specifications already = exist (e.g., > https://url.spec.whatwg.org/). They may or may not be harmful to the = Internet, > but I don=E2=80=99t see how they=E2=80=99re specifically harmful to = the RFC brand. They=E2=80=99re certainly > not more harmful to the RFC brand than competing specifications = labeled =E2=80=9CRFC." It needs to be noted that the non-IETF stream sources of RFCs constitute = "venues" for publication. The proposal on the table opens the gap = between those venues and the IETF. That might or might not be a good = thing, but it is important to understand the implications. Adrian From nobody Mon Jul 9 06:46:03 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0F5130FDB for ; Mon, 9 Jul 2018 06:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 rIgs4GGHaM4b for ; Mon, 9 Jul 2018 06:45:59 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 AEA53130FD7 for ; Mon, 9 Jul 2018 06:45:58 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id e9-v6so7193086ybq.1 for ; Mon, 09 Jul 2018 06:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=el+7U8WOu3E8PlLeIVkL8Ba5L+HdQTtEEp8iFIs8eQc=; b=cYgESFfUhTX+u6bIoYv1j/qs1UPSIbVq3RCCs23XRJ3prPkXESviaJSWQ3sob2XFFa SOvPDWunZRTU/0l1dTD910lGFdiAZQY2D3hzqhqQp1osKwigMrO268hXU++Zu+1C7CuL e5ujgAeT9+QH4XH7LPixtqryJicbnZ2D6oo1dS6UzR7CHetvZIcFE59MWNUqQWJVaEnO oegnVfh+vQa2FKQubEiijRa7SI3XehzK2GYxN8u0yfuwN2PCS2OBuytHz31Xh11UIYXn JdFltYhKyv10r7KrwoIWgViTCvdjmlc/zxqyR653l4L+Ki+yRpd4gUnEgvw5amOprEeh 06aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=el+7U8WOu3E8PlLeIVkL8Ba5L+HdQTtEEp8iFIs8eQc=; b=D6vacpjV5OxV77ccZ+sm/ZPAwYbAHmWkIt35B2ca0hUQ6/LPsrMU1r1MVxVCL54q3/ Po2x/ME9qI/Hs+G4kfN+fUH8ZlwdUEXLctiA4TQU3vFpKMnPHE6ajV7rXIddJTm11PkC TPJH9HLQuF4OWxM1YGmPcfsLGdbcjSM8dR3rs1mDzZts1DTS/0T/tGjPTi6AveN8Fqco f6ymTUXLPIpzG4W7nRw4rWWjZtrezVETKhhjWAjKDnMJtFCL93Zf2XpRGxYi2H7lolSu zZqYex5fHhIreRoHJ6UwID4Istek/xM3UPSJQGhJ8S5GZ9P9Lpjs0QzPYJ4ID3kIGdHY 5oDg== X-Gm-Message-State: APt69E3r3li2IB5jVy5d9+eyO1dtV2dsbNyeKVQr3j+3CPQ7BwxEeuzK mWsDBWvXjQ+ScSHTLpo57iTqFxRstWVXY8s2NgrxFanLgcU= X-Google-Smtp-Source: AAOMgpe2jTvsRIfGWj882dMmNUFrGjPA7lMqbAdsyDS+2nU4XvqsDUqgExUoGgzrcBiXpiD0zUYubruP7cvhzbrGdCI= X-Received: by 2002:a25:3496:: with SMTP id b144-v6mr11238823yba.275.1531143957865; Mon, 09 Jul 2018 06:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 06:45:17 -0700 (PDT) In-Reply-To: References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> From: Eric Rescorla Date: Mon, 9 Jul 2018 06:45:17 -0700 Message-ID: To: John C Klensin Cc: Alissa Cooper , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000b581100570913b4e" Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 13:46:02 -0000 --000000000000b581100570913b4e Content-Type: text/plain; charset="UTF-8" Responding on a narrow point. On Mon, Jul 9, 2018 at 1:01 AM, John C Klensin wrote: > > By contrast, recent years have shown us several examples of WGs > with small numbers of active participants, all or almost all > from the same cooperating cluster of companies and more than a > few AD-sponsored documents that have made it through the system > with substantially no substantive community input on IETF Last > Call and then get through the IESG with the minimum number of > "yes" votes and many "no objections", presumably deferring to > the AD who made the decision to sponsor the document. > I certainly wouldn't argue with the claim that many poor quality documents get through the IETF with minimal review, etc. However, I would be wary of drawing that conclusion based on the IETF ballots. Once a ballot is on the agenda, it almost always has a Yes from the AD who put it there (whether it is a WG document or AD-sponsored), and so the actual effect of "Yes" and "No-objection" is the same [0]. For that reason, I almost always ballot No-Objection, rather than try to distinguish between the cases where I think it's good and I just don't care [1]. My sense is that balloting procedures vary within the IESG, but I don't think I'm unique in this respect. I suppose one could argue that I'm (we're) Doing It Wrong and that the ballot procedures ought to be clarified/improved, but in any case it's not a signal that I'm just deferring to the AD. > If we think the kind of renaming that is being proposed is > needed to differentiate between documents that are published > with IETF consensus and those that are not, I suggest that the > IESG should eliminate AD Sponsored documents entirely (or at > least push them off into another series) and establish criteria > for breadth and balance in WGs, dealing differently with those > that don't obviously manifest those properties > I tend to agree with you that it would be good to sharply reduce AD-sponsored documents, though I don't know if it's possible to eliminate them entirely, because it's not uncommon to use them for small matters that you wouldn't spin up a WG for. E.g,, https://datatracker.ietf.org/doc/draft-housley-suite-b-to-historic/. I also share your concern about the breadth and balance of WGs, but I'm having trouble seeing what procedures we could actually put in place to address that. Would of course be interested in hearing any suggestions you might have on that front. -Ekr [0] Leaving aside the Alternate ballot procedure. [1] cf. https://en.wikipedia.org/wiki/Approval_voting --000000000000b581100570913b4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Responding on a narrow point.

On Mon, Jul 9, 2018 at 1:01 AM, John = C Klensin <john-ietf@jck.com> wrote:

By contrast, recent years have shown us several examples of WGs
with small numbers of active participants, all or almost all
from the same cooperating cluster of companies and more than a
few AD-sponsored documents that have made it through the system
with substantially no substantive community input on IETF Last
Call and then get through the IESG with the minimum number of
"yes" votes and many "no objections", presumably deferr= ing to
the AD who made the decision to sponsor the document.=C2=A0

I certainly wouldn't argue with the claim that ma= ny poor quality documents get through the IETF with minimal review, etc. Ho= wever, I would be wary of drawing that conclusion based on the IETF ballots= . Once a ballot is on the agenda, it almost always has a Yes from the AD wh= o put it there (whether it is a WG document or AD-sponsored), and so the ac= tual effect of "Yes" and "No-objection" is the same [0]= . For that reason, I almost always ballot No-Objection, rather than try to = distinguish between the cases where I think it's good and I just don= 9;t care [1]. My sense is that balloting procedures vary within the IESG, b= ut I don't think I'm unique in this respect. I suppose one could ar= gue that I'm (we're)=C2=A0 Doing It Wrong and that the ballot proce= dures ought to be clarified/improved, but in any case it's not a signal= that I'm just deferring to the AD.

=C2= =A0
If we think the kind of renaming that is being proposed is
needed to differentiate between documents that are published
with IETF consensus and those that are not, I suggest that the
IESG should eliminate AD Sponsored documents entirely (or at
least push them off into another series) and establish criteria
for breadth and balance in WGs, dealing differently with those
that don't obviously manifest those properties
I tend to agree with you that it would be good to sharply reduc= e AD-sponsored documents, though I don't know if it's possible to e= liminate them entirely, because it's not uncommon to use them for small= matters that you wouldn't spin up a WG for. E.g,, https://datatra= cker.ietf.org/doc/draft-housley-suite-b-to-historic/.

I also share your concern about the breadth and balance of WGs, but= I'm having trouble seeing what procedures we could actually put in pla= ce to address that. Would of course be interested in hearing any suggestion= s you might have on that front.

-Ekr


[0] Leaving aside the Alternate b= allot procedure.

--000000000000b581100570913b4e-- From nobody Mon Jul 9 07:04:53 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39C912D949 for ; Mon, 9 Jul 2018 07:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 r66rAepSrUEH for ; Mon, 9 Jul 2018 07:04:50 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 0DC4D130DBE for ; Mon, 9 Jul 2018 07:04:44 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id l10-v6so15463695qtj.0 for ; Mon, 09 Jul 2018 07:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EMl0Q1ZgX73mgt2PfcOvRM5pFvOtRBASHRwjS2sV+tw=; b=XgIeYKWt5f8FU/ADzqIdkFOHL7ZihVJc3rZW+d37rRYsoVfza0YFSCZptpBirA0Xfz ylX39kuz9mPtHnfOtdmp8wThli5zCjaJT9LOvVjULXRYia4LhMdADFT5FxZGN05tQLbq FMoL1LiJrwZvOwK1KKAG0hwdKyhZZDTD64p5DooJUVpVNuVUSMK66mqholzTveVc+Fzb idmj6H9bjpZuatOuHyxzkhQvvdaji6jNRSdzY1qQvmHMVQJQfQUYfEDFbC4j7Ck+KT+5 zxpWEiakiQbO6rdyEt6RGZ3jJsGr+bwB0aPFy2L9jkLK3OMbXO2ypvrjbsibyeSaY+CI z2sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EMl0Q1ZgX73mgt2PfcOvRM5pFvOtRBASHRwjS2sV+tw=; b=uQyh9GP8ZLovkKERQTP0F7H3V2z+jqLMnHXfwsHdoXSXElT0B7lHI7ukepyDl88HNx HGQ9nGDOIMWGODv0GKZZ5U6aKt5KE6KhvI+W8ANy8pXnDDCw+3Pxsb/dKkXyAXSSNGAb icrumL7zWm98odoz0cad8Kyj8/dAWQnypHz8LY2ljW/78rT1vUpZxZ1T7lbJ07RxSmc4 uOc5RAtFPmFF3icgjRZE7qW+29o5FDoMEgC37PBKtDxV6UK/6gBAk9hd+FZankJAp3ci uhhLAEYI1UyhxRiMylf98uSo2zsPjGQKi+dl4QtBY77QPRS9qdecqByRViUW29ZlPLrt ledA== X-Gm-Message-State: APt69E1FXwxy7ZsjwjBLp5FGfXskNeSFizx9KsgmLHrKquRvxQUazcm7 ZGTL4kT/+apDtFVD+VJGTzsKmIQb X-Google-Smtp-Source: AAOMgpdEIdrESezYGy13O+YOEnNwsgRqglN+TQ3x8RvSPpcTzXDqgoUbWi9pOQdO4U8iOy8Qv+hnDw== X-Received: by 2002:ac8:2fc6:: with SMTP id m6-v6mr18156597qta.170.1531145083903; Mon, 09 Jul 2018 07:04:43 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id v1-v6sm3922520qtg.7.2018.07.09.07.04.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 07:04:43 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-99F54EA6-FA4C-4DDF-AC5F-B384BF9FA6C1 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Mon, 9 Jul 2018 10:04:42 -0400 Cc: John C Klensin , Alissa Cooper , rfcplusplus@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <2D7B9C1B-22D0-4B9B-BAC5-FE11AD29041B@gmail.com> References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> To: Eric Rescorla Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 14:04:53 -0000 --Apple-Mail-99F54EA6-FA4C-4DDF-AC5F-B384BF9FA6C1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my mobile device > On Jul 9, 2018, at 9:45 AM, Eric Rescorla wrote: >=20 > Responding on a narrow point. >=20 >> On Mon, Jul 9, 2018 at 1:01 AM, John C Klensin wrote:= >>=20 >> By contrast, recent years have shown us several examples of WGs >> with small numbers of active participants, all or almost all >> from the same cooperating cluster of companies and more than a >> few AD-sponsored documents that have made it through the system >> with substantially no substantive community input on IETF Last >> Call and then get through the IESG with the minimum number of >> "yes" votes and many "no objections", presumably deferring to >> the AD who made the decision to sponsor the document. =20 >=20 > I certainly wouldn't argue with the claim that many poor quality documents= get through the IETF with minimal review, etc. However, I would be wary of d= rawing that conclusion based on the IETF ballots.. Once a ballot is on the a= genda, it almost always has a Yes from the AD who put it there (whether it i= s a WG document or AD-sponsored), and so the actual effect of "Yes" and "No-= objection" is the same [0].. For that reason, I almost always ballot No-Obje= ction, rather than try to distinguish between the cases where I think it's g= ood and I just don't care [1]. My sense is that balloting procedures vary wi= thin the IESG, but I don't think I'm unique in this respect. I suppose one c= ould argue that I'm (we're) Doing It Wrong and that the ballot procedures o= ught to be clarified/improved, but in any case it's not a signal that I'm ju= st deferring to the AD.=20 For non-sponsoring ADs, a YES means they believe in the work strongly enough= that they would also be happy to sponsor it. That=E2=80=99s come up as imp= ortant as ADs roll off. I=E2=80=99ve used no objection in a similar way, but= purposefully used YES on documents as well. For no objection, it means I tr= ust the AD (person balloting didn=E2=80=99t have enough time), my parts are o= k (no major security issues), or I read the document thoroughly and only hav= e comment level suggestions and am fine publishing it anyway. That maps wel= l to the Alternate ballot procedure where no objection is the same as yes - i= t=E2=80=99s fine to publish this. Best, Kathleen=20 >=20 > =20 >> If we think the kind of renaming that is being proposed is >> needed to differentiate between documents that are published >> with IETF consensus and those that are not, I suggest that the >> IESG should eliminate AD Sponsored documents entirely (or at >> least push them off into another series) and establish criteria >> for breadth and balance in WGs, dealing differently with those >> that don't obviously manifest those properties >=20 > I tend to agree with you that it would be good to sharply reduce AD-sponso= red documents, though I don't know if it's possible to eliminate them entire= ly, because it's not uncommon to use them for small matters that you wouldn'= t spin up a WG for. E.g,, https://datatracker.ietf.org/doc/draft-housley-sui= te-b-to-historic/. >=20 > I also share your concern about the breadth and balance of WGs, but I'm ha= ving trouble seeing what procedures we could actually put in place to addres= s that. Would of course be interested in hearing any suggestions you might h= ave on that front. >=20 > -Ekr >=20 >=20 >=20 > [0] Leaving aside the Alternate ballot procedure.=20 > [1] cf. https://en.wikipedia.org/wiki/Approval_voting >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --Apple-Mail-99F54EA6-FA4C-4DDF-AC5F-B384BF9FA6C1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent= from my mobile device

On Jul 9, 2018, at 9:45 AM, Eric Rescor= la <ekr@rtfm.com> wrote:

Responding on a narrow p= oint.

On M= on, Jul 9, 2018 at 1:01 AM, John C Klensin <john-ietf@jck.com>= wrote:

By contrast, recent years have shown us several examples of WGs
with small numbers of active participants, all or almost all
from the same cooperating cluster of companies and more than a
few AD-sponsored documents that have made it through the system
with substantially no substantive community input on IETF Last
Call and then get through the IESG with the minimum number of
"yes" votes and many "no objections", presumably deferring to
the AD who made the decision to sponsor the document. 

I certainly wouldn't argue with the claim that many poo= r quality documents get through the IETF with minimal review, etc. However, I= would be wary of drawing that conclusion based on the IETF ballots.. Once a= ballot is on the agenda, it almost always has a Yes from the AD who put it t= here (whether it is a WG document or AD-sponsored), and so the actual effect= of "Yes" and "No-objection" is the same [0].. For that reason, I almost alw= ays ballot No-Objection, rather than try to distinguish between the cases wh= ere I think it's good and I just don't care [1]. My sense is that balloting p= rocedures vary within the IESG, but I don't think I'm unique in this respect= . I suppose one could argue that I'm (we're)  Doing It Wrong and that t= he ballot procedures ought to be clarified/improved, but in any case it's no= t a signal that I'm just deferring to the AD.

For non-sponsoring ADs, a YES means th= ey believe in the work strongly enough that they would also be happy to spon= sor it.  That=E2=80=99s come up as important as ADs roll off. I=E2=80=99= ve used no objection in a similar way, but purposefully used YES on document= s as well. For no objection, it means I trust the AD (person balloting didn=E2= =80=99t have enough time), my parts are ok (no major security issues), or I r= ead the document thoroughly and only have comment level suggestions and am f= ine publishing it anyway.  That maps well to the Alternate ballot proce= dure where no objection is the same as yes - it=E2=80=99s fine to publish th= is.

Best,
Kathleen 


 
If we think the kind of renaming that is being proposed is
needed to differentiate between documents that are published
with IETF consensus and those that are not, I suggest that the
IESG should eliminate AD Sponsored documents entirely (or at
least push them off into another series) and establish criteria
for breadth and balance in WGs, dealing differently with those
that don't obviously manifest those properties

I tend to agree with you that it would be good to sharply reduce AD-s= ponsored documents, though I don't know if it's possible to eliminate them e= ntirely, because it's not uncommon to use them for small matters that you wo= uldn't spin up a WG for. E.g,, https://datatracker.ietf.org/doc/draft-ho= usley-suite-b-to-historic/.

I also share your c= oncern about the breadth and balance of WGs, but I'm having trouble seeing w= hat procedures we could actually put in place to address that. Would of cour= se be interested in hearing any suggestions you might have on that front.

-Ekr



[0] Leaving aside the Alternate ballot procedure.

____________________= ___________________________
Rfcplusplus mailing list<= br>Rfcplusplus@ietf.org
= https://www.ietf.org/mailman/listinfo/rfcplusplus
= --Apple-Mail-99F54EA6-FA4C-4DDF-AC5F-B384BF9FA6C1-- From nobody Mon Jul 9 08:24:46 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B156130DF4 for ; Mon, 9 Jul 2018 08:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 V9KD90WyjAgi for ; Mon, 9 Jul 2018 08:24:41 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1059126DBF for ; Mon, 9 Jul 2018 08:24:41 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id v8-v6so36621787oie.5 for ; Mon, 09 Jul 2018 08:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Q77FNNzKxvYSFh/LiZszYbswf3gaHFNdKYTWpF8XzAY=; b=So8vstduLivsCALPqFq72CRVObcDWksmjnhT1C7qEdds8IyD56QERhVDxwU2z0GjJi DuchTnWtXQt6VpTwKbVURkwWIJPSIfA5DuHxpupN1ukE8kooa59d614w8Z6Yvlpj4O/Z Q14iU3CuPicLErm3EG2KfXPjqLvQdHgcKITXuJqJ3AgSPiDAHNMqqvNZownhbZpPh7Zl d2RTUMC/eWp4GnNi2LVDzovKboHhDAoSX9pyqYdt7OnSHxi8Ge1oAwreXYGeRx2dGAWx wUxDVsUE3bl1tveEJucC2RLXI7uV8yzufjk6ck9+Cqui8L9RFZXjs3Hqn89s8xmtv5AE Ocyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Q77FNNzKxvYSFh/LiZszYbswf3gaHFNdKYTWpF8XzAY=; b=rQgIdbst68Cc3eCga0WtRiIK7fYuMx5W5CNFoHpVboKs9vBuqnP69IGa+ML27DWH8B uyzJXcKc3AedvbxM/6mhCsZZsSM05mqaUqImX+/t6g9EzKVTd+2aQZFHI/FD8VQCUVD2 4MaCXW0HL/jHqgiOHTKrY3UuwBC9vGoc8ylpP+kU52BkKDGZic3BhkVv7eGPmmaF89h9 OweRwvrmfRR1yI6gkjSoviqjEm+K40KGmJ0voNv8cXyeaxCrUfmXG3ilhYz9rB6llxRL AepMmkHZLlKKNq6rlfY070aHmadxc+qsuk8nbC17MG6pM/ALj+kzJJwzspLhsnw+y92Y XxGA== X-Gm-Message-State: APt69E1qDCVTxEUuivHOBp5ZF3284eCXfQBwzgf66BCv06U7SIl/OijE f22vOfBYDwFkSvk3C4KwpPtwLAEAhwuLpWZ6V9oRJA== X-Google-Smtp-Source: AAOMgpcpkOLB+nyGB+n07l5VIniO95lpvKJPoGBRZNw+zA9PHPS5htF4/WMPzCERXkLvVjM7leSvDYBG0ySP9JOFIKQ= X-Received: by 2002:aca:3c45:: with SMTP id j66-v6mr21712043oia.118.1531149880562; Mon, 09 Jul 2018 08:24:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 08:24:10 -0700 (PDT) From: Ted Hardie Date: Mon, 9 Jul 2018 08:24:10 -0700 Message-ID: To: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000bac6c30570929c1f" Archived-At: Subject: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:24:44 -0000 --000000000000bac6c30570929c1f Content-Type: text/plain; charset="UTF-8" In a different thread, Eric made a statement about the RFC Series being in conversation with other publications: The RFC series (and also I-Ds) have an important role to play here, but it > also exists in conversation with a lot of other publication venues, and I > think that's healthy. > While I agree with him, I think the metaphor of "conversation" is even more useful in describing both the current series and the question before us. >From my personal perspective, the primary reason we use "RFC" as a series identifier is to identify a specific set of technical documents as part of a common "conversation". The adoption of the term and series by the IETF was a signal about the conversation their documents were to be part of; choosing a different document series (like ANSI, ISO, or minting a new one) would have sent a signal about a different technical community with whom the IETF was in dialog. When the idea of different streams and stream managers gelled, we kept the same series identifier for all of them. I think, personally, we did that because we wanted to be clear that all of the documents continued to be part of a larger conversation about the development of Internet technologies. One way to understand the problem motivating this BoF is also through the metaphor of conversation: many outside the community simply don't recognize that there are multiple voices inside that conversation. They see all of the documents as utterances by a single, somewhat nebulous group. That can cause problems. Among those named earlier were the academic community's failure to value the output of the IRTF; vendors or customers not distinguishing consensus output from proprietary alternatives; and even a few efforts to get rejected ideas to appear to have been accepted ones. The question before us could be cast as: is it more important now to highlight the different voices that the streams and statuses currently convey, so that others understand them as disctinct? As Eric points out, there are other ways to maintain a conversation among different groups than to make their output part of a single series. There are also other ways we could try to make sure that we highlight that distinction more fully (using STD numbers for all IETF standards documents, for example, from proposed standard onward). But I think this is the core of the tension, shorn of discussion of brand or history: how to we get to the right balance of maintaining the conversation while improving the understanding that these are individual voices within it? My thoughts as individual, regards, Ted --000000000000bac6c30570929c1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In a different thread, Eric made a statement about th= e RFC Series being in conversation with other publications:

<= /div>
The RFC series = (and also I-Ds) have an important role to play here, but it also exists in = conversation with a lot of other publication venues, and I think that's= healthy.

While I agree with him,= I think the metaphor of "conversation" is even more useful in de= scribing both the current series and the question before us.=C2=A0 From my = personal perspective, the primary reason we use "RFC" as a series= identifier is to identify a specific set of technical documents as part of= a common "conversation".=C2=A0 The adoption of the term and seri= es by the IETF was a signal about the conversation their documents were to = be part of; choosing a different document=C2=A0 series (like ANSI, ISO, or = minting a new one) would have sent a signal about a different technical com= munity with whom the IETF was in dialog.=C2=A0

When the idea of different streams and stream managers gelled, we kept th= e same series identifier for all of them.=C2=A0 I think, personally, we did= that because we wanted to be clear that all of the documents continued to = be part of a larger conversation about the development of Internet technolo= gies.

One way to understand the problem motivating= this BoF is also through the metaphor of conversation: many outside the co= mmunity simply don't recognize that there are multiple voices inside th= at conversation.=C2=A0 They see all of the documents as utterances by a sin= gle, somewhat nebulous group.=C2=A0 That can cause problems.=C2=A0 Among th= ose named earlier were the academic community's failure to value the ou= tput of the IRTF; vendors or customers not distinguishing consensus output = from proprietary alternatives; and even a few efforts to get rejected ideas= to appear to have been accepted ones.

The questio= n before us could be cast as:=C2=A0 is it more important now to highlight t= he different voices that the streams and statuses currently convey, so that= others understand them as disctinct?=C2=A0

A= s Eric points out, there are other ways to maintain a conversation among di= fferent groups than to make their output part of a single series.=C2=A0 The= re are also other ways we could try to make sure that we highlight that dis= tinction more fully (using STD numbers for all IETF standards documents, fo= r example, from proposed standard onward).=C2=A0 But I think this is the co= re of the tension, shorn of discussion of brand or history:=C2=A0 how to we= get to the right balance of maintaining the conversation while improving t= he understanding that these are individual voices within it?

=
My thoughts as individual,

regards,

Ted
--000000000000bac6c30570929c1f-- From nobody Mon Jul 9 08:46:38 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCC6130E48 for ; Mon, 9 Jul 2018 08:46:31 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Jxav+3CP; dkim=pass (1024-bit key) header.d=yitter.info header.b=BVE1cxPP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfQlonq6NBZf for ; Mon, 9 Jul 2018 08:46:28 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BA812F1A5 for ; Mon, 9 Jul 2018 08:46:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id C93CCBEBEB for ; Mon, 9 Jul 2018 15:46:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1531151186; bh=RdsaWAhzaHXnkGNdTTDTi0uB717M+v/QfPNkoN31kBI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Jxav+3CP4ZzS/qWzVUPwddZKJWEcuMyvrvRyRMCNXYOrTSgaVp/rEWeoMwnWY+ttr wSw84xDkonGV9Lr7eKFnqbdzPl14UriiP1+fsZsgl8x1L0kS7/uBC3j5zHClgMndr4 UCvyHoRaQsRIEDXsimtC9m4TlIc6uPp8FCAHEBy0= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn7WDHdyu_GA for ; Mon, 9 Jul 2018 15:46:25 +0000 (UTC) Date: Mon, 9 Jul 2018 11:46:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1531151185; bh=RdsaWAhzaHXnkGNdTTDTi0uB717M+v/QfPNkoN31kBI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=BVE1cxPPXrf5uiiVqZ3IwOMxkA/nXvJMZzGXDvP54Cyj/cgMFARe4QqKFiEfN/D0n z19ZVbYnElJBupHio4LQs+cQxdb+tn0k6BFLysn60BYTxlAlOEPIoK4+Vfp2B/Czjv udOkIEJqFQ5edtXlFPUxHPNxGASI3/265rDerpco= From: Andrew Sullivan To: rfcplusplus@ietf.org Message-ID: <20180709154623.GH8628@mx4.yitter.info> References: <57A2C19672ED019677D8905E@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <57A2C19672ED019677D8905E@PSB> Archived-At: Subject: [Rfcplusplus] What do we want to give up? (was Re: Appeal of IESG Conflict Review process and decision on draft-mavrogiannopoulos-pkcs8-validated-parameters-02) X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:46:32 -0000 Dear colleagues, On Sat, Jul 07, 2018 at 03:40:43PM -0400, John C Klensin wrote: > IESG, > > After a discussion with the IETF Chair as required by RFC 2026 > and concluding that discussion could not satisfy my concerns, > this note constitutes an appeal of the conflict review decision > on draft-mavrogiannopoulos-pkcs8-validated-parameters-02 posted > last month. Because IESG conflict review decision are not > binding on the Independent Submission Editor, this appeal is not > a request that the IESG take a different position on that > document but about the mechanisms, reasoning, and process that > appear to have been followed in this case (including what appear > to be some substantive errors in that process). […] I don't wish to discuss the particulars of John's appeal here, because it is ongoing, but given that it is an appeal that is not expected (even by the appellant's note) to produce any result in the specific case I guess it's ok to use it as an example[1]. It seems to me that the appeal might well be understood as claiming the IESG did not do its job because it did not provide an "appropriate justification" for its conclusion that the I-D in question conflicted with IETF work. I observe that the conflict review is not only for things that clearly conflict in a formal sense, but also in "the case where there is a proposed change or extension to an IETF protocol that was not anticipated by the original authors and that may be detrimental to the normal usage of the protocol." [RFC 5742] The question I have for this list is whether we think this is the best use of IESG time. The IESG is busy, and annually during the nomcom periods there is hand-wringing about the time committment that the AD role takes. Every thing we ask the IESG to do is time that is used up and therefore potentially taken away from processing IETF documents and undertaking other IETF business. Reviewing Indepndent Stream documents is one of those things we are asking for. Since the Independent Stream is, by definition, not the IETF's business, we are faced with a basic question: does the Internet as a whole benefit from the conflation of "RFC", "standard", and "IETF product" that is manifest in the Internet community[2]? I have seen on this list a number of arguments to the effect that the Internet does benefit from that, but I think this appeal provides some evidence to the contrary. In our protocols, we generally take the stance that, if the interoperating Internet is at odds with what the protocol documents actually say, then the documents are wrong. We don't, of course, always fix it; but that failure to fix is _itself_ a part of IETF culture, and we make (sometimes not too gentle) fun of the "weenies" and "mafia" who enforce their narrow view in the documents when everybody knows that's not how things work. I suggest that the insistence that "RFCs are not always IETF documents" is true to us, and to approximately nobody else. We collectively spend a significant amount of IESG time reviewing these things so that the series doesn't contradict itself except on purpose and explicitly (e.g. when we deprecate something). I think it would be useful for BoF particpants to ask themselves whether that is the best contribution to the Internet of the finite quantity of time we have to spend on these matters. We will have to give up something. Either the IESG can be required to review all the things that might impinge on protocols and might be called "RFC", or we can stop calling them RFCs and therefore stop asking the IESG to do this monitoring. Which gives us more value? Best regards, Andrew (only for myself, of course) [1] It might be tempting to some to explore the utility of appeals that are not intended to change anything. Fortunately, this is not the list for such inquiry, so I earnestly hope we will not be distracted by that topic. [2] Even modest Googling efforts show this up pretty quickly. From my location just now, a search for "RFC definition" yields as its first result a page that claims RFCs come from the IETF even though they're not all standards. Next is the Wikipedia page, then another page that appears to be a copy of the first one, then another definition that claims the IETF is always in charge and that any document can become an Internet Standard. The next one is a mash-up site that leads to yet another site with an ostensive definition of RFC that barely touches on how they work. At the bottom of that first page is RFC 2119. -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jul 9 10:36:41 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AA513104F for ; Mon, 9 Jul 2018 10:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huf9648Bxd0U for ; Mon, 9 Jul 2018 10:36:28 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB74131054 for ; Mon, 9 Jul 2018 10:36:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id ACC7A1D1B84 for ; Mon, 9 Jul 2018 10:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jQdrIoO4S7U for ; Mon, 9 Jul 2018 10:36:22 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:f803:9f89:bf22:411a]) by c8a.amsl.com (Postfix) with ESMTPSA id 7C3901CA3BA for ; Mon, 9 Jul 2018 10:36:22 -0700 (PDT) To: rfcplusplus@ietf.org From: "Heather Flanagan (RFC Series Editor)" Message-ID: <4444ba48-a52b-00c3-6770-e9cab66eacb2@rfc-editor.org> Date: Mon, 9 Jul 2018 10:36:22 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Rfcplusplus] Marketing, Branding, and Subject Matter Expertise X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 17:36:38 -0000 Hello all, Early on in the process that spun into the BoF, before it became a BoF, I suggested that taking a step back to properly review and clarify the scope of the problem, and to determine the varying options we had (and will have) for solving them made more sense than throwing an idea against the figurative wall to see if it would stick. I still think that idea is a good one, and something that I should be handling as RSE. One of the things I would like to do is talk to people who understand marketing and branding for a living--there are people at ISOC that have the level of experience I think we need--rather than watch ideas abound from very smart engineers. -Heather From nobody Mon Jul 9 11:18:23 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A9B130E65 for ; Mon, 9 Jul 2018 11:18:21 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ffdyKcfHxn6K for ; Mon, 9 Jul 2018 11:18:19 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E77126CC7 for ; Mon, 9 Jul 2018 11:18:18 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id k12-v6so37620858oiw.8 for ; Mon, 09 Jul 2018 11:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1+0uPQZHKupPszXqvrIXnJXqNwNYvdn7uBtNpw2Igys=; b=vWnMkvKCJVDKOcN5gmRX9Xox5vIbRhIhMCP/mb96uMBAeIFXIRBHrpiLvuzAqSzX0D QOy0hTgi3aiFQmjqmMBHp5irkTDuQWGolWcJISxr2C8qwBzcy3OYYuohmWN5geMHKFm7 ysgr8ELM5qSATrwli1uwRXpPpm3+Vlvp+DRPk1J+OOXitaPpTP45Z2oEeWMSM1F30fyJ US/VBVVtXBAF1z9BiGfNDccOeNqXpP0b6dD1rS9cAnazf9gyaRQDPWRkYX4U8KUfGjHV 2OOjSAf2b02eK3XHFkb97i53Xv0nqUuTiN+Mab5s5FHSQ5luweCajm6C+IdrZ8z9hSpU VRNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1+0uPQZHKupPszXqvrIXnJXqNwNYvdn7uBtNpw2Igys=; b=LpXcUMGg2FAJRer/FI5ECO3ZPDjKsVvh0So6l/akj0iZ65w5FQkZICu/K0lPvTcpV1 zW4yjxiHprNvrIYYTYqc9vtmth3n/3WJSqiF8U0y2yCyOBfcrdTV9WMs2/FOAUvL8W/M 2vbda7bQd+tPpxsnRoBM3Sjklsw62IUVlx9Ykd0pGG/ZAcELve05citgRgTOGmsGohpA CjKWfEhzpWYgpDjYkCKsYXlLkVO+34L+93lyIgDsZy8JiBh9oYZRodBWbQv5jdoyUsGI aCtOpK918+9ZRy4YmPsFKFxG1BbB4KWrFumZlVW5oP88/FT1syqA/l4w7j6um4wVaeiv wZww== X-Gm-Message-State: APt69E2u5XhDOyXH9j/xRe98XqELfIP0ZPKoobn98IIH5jp/CTVzzFDX YNCSqy7PnlIqhiwtZ0RN/yrdaJOhggbEpXGg9r8= X-Google-Smtp-Source: AAOMgpd5pogSCvhkhTswgUQTPJXsVR8+OdZ4wEJp0xVMPGWWU6T/lj2ftuGDL/njw46QUTddD953REdf+//F8BLq1y0= X-Received: by 2002:aca:3254:: with SMTP id y81-v6mr23117054oiy.317.1531160298283; Mon, 09 Jul 2018 11:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:7ad0:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 11:17:37 -0700 (PDT) In-Reply-To: <20180709154623.GH8628@mx4.yitter.info> References: <57A2C19672ED019677D8905E@PSB> <20180709154623.GH8628@mx4.yitter.info> From: Kathleen Moriarty Date: Mon, 9 Jul 2018 14:17:37 -0400 Message-ID: To: Andrew Sullivan Cc: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfcplusplus] What do we want to give up? (was Re: Appeal of IESG Conflict Review process and decision on draft-mavrogiannopoulos-pkcs8-validated-parameters-02) X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 18:18:22 -0000 On Mon, Jul 9, 2018 at 11:46 AM, Andrew Sullivan w= rote: > Dear colleagues, > > On Sat, Jul 07, 2018 at 03:40:43PM -0400, John C Klensin wrote: >> IESG, >> >> After a discussion with the IETF Chair as required by RFC 2026 >> and concluding that discussion could not satisfy my concerns, >> this note constitutes an appeal of the conflict review decision >> on draft-mavrogiannopoulos-pkcs8-validated-parameters-02 posted >> last month. Because IESG conflict review decision are not >> binding on the Independent Submission Editor, this appeal is not >> a request that the IESG take a different position on that >> document but about the mechanisms, reasoning, and process that >> appear to have been followed in this case (including what appear >> to be some substantive errors in that process). > > [=E2=80=A6] > > I don't wish to discuss the particulars of John's appeal here, because > it is ongoing, but given that it is an appeal that is not expected > (even by the appellant's note) to produce any result in the specific > case I guess it's ok to use it as an example[1]. > > It seems to me that the appeal might well be understood as claiming > the IESG did not do its job because it did not provide an "appropriate > justification" for its conclusion that the I-D in question conflicted > with IETF work. I observe that the conflict review is not only for > things that clearly conflict in a formal sense, but also in "the case > where there is a proposed change or extension to an IETF protocol that > was not anticipated by the original authors and that may be > detrimental to the normal usage of the protocol." [RFC 5742] > > The question I have for this list is whether we think this is the best > use of IESG time. The IESG is busy, and annually during the nomcom > periods there is hand-wringing about the time committment that the AD > role takes. Every thing we ask the IESG to do is time that is used up > and therefore potentially taken away from processing IETF documents > and undertaking other IETF business. Reviewing Indepndent Stream > documents is one of those things we are asking for. > > Since the Independent Stream is, by definition, not the IETF's > business, we are faced with a basic question: does the Internet as a > whole benefit from the conflation of "RFC", "standard", and "IETF > product" that is manifest in the Internet community[2]? I have seen > on this list a number of arguments to the effect that the Internet > does benefit from that, but I think this appeal provides some evidence > to the contrary. > > In our protocols, we generally take the stance that, if the > interoperating Internet is at odds with what the protocol documents > actually say, then the documents are wrong. We don't, of course, > always fix it; but that failure to fix is _itself_ a part of IETF > culture, and we make (sometimes not too gentle) fun of the "weenies" > and "mafia" who enforce their narrow view in the documents when > everybody knows that's not how things work. I suggest that the > insistence that "RFCs are not always IETF documents" is true to us, > and to approximately nobody else. We collectively spend a significant > amount of IESG time reviewing these things so that the series doesn't > contradict itself except on purpose and explicitly (e.g. when we > deprecate something). > > I think it would be useful for BoF particpants to ask themselves > whether that is the best contribution to the Internet of the finite > quantity of time we have to spend on these matters. We will have to > give up something. Either the IESG can be required to review all the > things that might impinge on protocols and might be called "RFC", or > we can stop calling them RFCs and therefore stop asking the IESG to do > this monitoring. Which gives us more value? I didn't read the appeal the same way you did. I read it as in the IESG didn't document the reasons for the recommendation as part of the conflict review and there were a few reasons in looking at the document that the IESG recommendation didn't make sense. Typically, there is reasoning provided with these reviews if the response is one as strong as Do Not Publish and that explanation was lacking in this conflict review. The reviews don't take a lot of time even noted by Martin in his draft. Is the BoF about something other than what it's purported to be? A clear problem statement would be very helpful. > > Best regards, > > Andrew (only for myself, of course) > > [1] It might be tempting to some to explore the utility of appeals > that are not intended to change anything. Fortunately, this is not > the list for such inquiry, so I earnestly hope we will not be > distracted by that topic. I think the reporting out on conflict reviews may have been an intended target for change. More information is normally provided, so this was out of the ordinary in terms of the ballot information and write up from the IESG. Best regards, Kathleen > > [2] Even modest Googling efforts show this up pretty quickly. From my > location just now, a search for "RFC definition" yields as its first > result a page that claims RFCs come from the IETF even though they're > not all standards. Next is the Wikipedia page, then another page that > appears to be a copy of the first one, then another definition that > claims the IETF is always in charge and that any document can become > an Internet Standard. The next one is a mash-up site that leads to > yet another site with an ostensive definition of RFC that barely > touches on how they work. At the bottom of that first page is RFC 2119. > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --=20 Best regards, Kathleen From nobody Mon Jul 9 13:55:25 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A4013107A for ; Mon, 9 Jul 2018 13:55:23 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 GJjDIfI2L_kq for ; Mon, 9 Jul 2018 13:55:13 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 766421310D8 for ; Mon, 9 Jul 2018 13:55:08 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id v8-v6so38519132oie.5 for ; Mon, 09 Jul 2018 13:55:08 -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=myXEoC/5LS9Ejn2WFa7cgDUPm3caxSNqrN9PMjI2wDM=; b=HDr/ca8EgMQqLD3DrOPDgx9BU+POerwx6mHKbffIT0EH00oozuDf6kLU80GAHkhb8M piK3y5vVbf2MVlrF7tKdNz/cggzlPutWRnpCy/1wKN1zeD61V1io6iQFUk7i57624it0 tBQFnogEljiQ0pdjS0dFYzyTvSRZJ/oCT5TOkYU/EUlO4OqoTdCwNHGQEL/sdJeSpErd 9Ut/AvPT9JsHFBgEd+THKhkGQQulXpDAoBh8tlRyQt4ghDNjDhHQGuyOzC/J2gQ5aMZO XakzpmOQAAIRPaH38ElsYojgQ6vnvJ09n22S0Qi7qG1tejnFyBATNqg7Ltz56Aezms9a 7X9g== 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=myXEoC/5LS9Ejn2WFa7cgDUPm3caxSNqrN9PMjI2wDM=; b=OiHVHEFpYLlM8grtTqiY4GGH38gzFhhQkjAFmHanMqV78RF43uaQMdYKHA+ttDmZ1Z 8DLF8gXfTxDtHTgo4wCHb6ghdTnVuZ0syxBsMsdb/NYgWXMJ15xke2XZy95uUGHX8la5 rVI3Bw7tmkBMp+OXr4JshRDCKSsv9EI49eIQRTR4CdSDKwrJd81HS1dodPSQGz4xNQzZ ATRRFKTwGeD43FL76MxsxE+LHOmKTCp4Xw/SFa9IRA0wdMrXrmde93M1j3ce7lWFvcKQ Tf9L3eRWqPXcj/5z+p61l+O+NzLjeVQuRxTFrvoMhKocyki6yteOEx+7uh7StGZGl4IF J36w== X-Gm-Message-State: APt69E2AF+RpTuS14i9ISp0nEYm72KBo+Pi5NTqNqB0vcAwvr5lbaeKB LMNKEAfKCR1Bqg0nD/z4+N8tfRCAidk6ZRn+1LQ= X-Google-Smtp-Source: AAOMgpeg3+a47+vVjG1bxiFJ0ORjndj6rpM5qnV5mSQEvkAY424jUKmAtkEh+QWbsd/ZWZclZ0Rkc7bJ8mI6z7sfgMk= X-Received: by 2002:aca:120e:: with SMTP id 14-v6mr11465971ois.144.1531169707493; Mon, 09 Jul 2018 13:55:07 -0700 (PDT) MIME-Version: 1.0 References: <57A2C19672ED019677D8905E@PSB> <20180709154623.GH8628@mx4.yitter.info> In-Reply-To: From: Martin Thomson Date: Tue, 10 Jul 2018 06:54:57 +1000 Message-ID: To: Kathleen Moriarty Cc: Andrew Sullivan , rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] What do we want to give up? (was Re: Appeal of IESG Conflict Review process and decision on draft-mavrogiannopoulos-pkcs8-validated-parameters-02) X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 20:55:24 -0000 On Tue, Jul 10, 2018 at 4:27 AM Kathleen Moriarty wrote: > I didn't read the appeal the same way you did. I read it as in the > IESG didn't document the reasons for the recommendation as part of the > conflict review and there were a few reasons in looking at the > document that the IESG recommendation didn't make sense. Typically, > there is reasoning provided with these reviews if the response is one > as strong as Do Not Publish and that explanation was lacking in this > conflict review. The reviews don't take a lot of time even noted by > Martin in his draft. Kathleen's assessment of the cost of conflict review here more closely matches mine (not as much the appeal, but I'm not going into that). That is, the IESG - in determining whether there is a conflict - does not spend inordinate amounts of time on independent submissions. But that is primarily because this is explicitly not a technical review. My impression is that Andrew's comment is addressed at the technical quality of documents. From nobody Mon Jul 9 14:15:16 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09BC1310A0 for ; Mon, 9 Jul 2018 14:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oicmVQgWOiZW for ; Mon, 9 Jul 2018 14:15:07 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C967131073 for ; Mon, 9 Jul 2018 14:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12928; q=dns/txt; s=iport; t=1531170901; x=1532380501; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=gfi27Ak/GduT45tzx9omZSgpox4RNeUlUiG168d1JP4=; b=QPVXbWb+Qf9uXDExTwTRv+zNQGMiT3ghljJFwc+YDIex7qj7JBOOOdOA GYim4Wpt+LQHsBV44Vg2GpBeSMQsuKYZJqgf+bnB/jhCctQQWxXQyYoVO ngEjp/VJ2Jam7xGFTUALaMmv6+0wAIW66hB6dbuCiJMotm3Jf36bxKaYJ I=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8AgDPz0Nb/xbLJq1TChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGEK20SKIN6iGONMiqQJIcICAMYAQqEA0YCgmY4FAECAQE?= =?us-ascii?q?CAQECbRwMQhABhGQBAQEDAQEMFSQeCRsLGCoCAicwBgEMBgIBARCDDAGBfw+?= =?us-ascii?q?peoIcH4MGhSeBKwoFiwOBDyeCaIMYAQGBNYMsglUCiAGFe4tTCYNcgViJaga?= =?us-ascii?q?IFoVHhxKKfoFYIYFSMxoIGxU7gmmCJBeIWYVAPTCGI4gPAQE?= X-IronPort-AV: E=Sophos;i="5.51,330,1526342400"; d="asc'?scan'208,217";a="5072857" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2018 21:14:59 +0000 Received: from [10.61.195.132] ([10.61.195.132]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w69LEwvh030953; Mon, 9 Jul 2018 21:14:59 GMT To: Ted Hardie , rfcplusplus@ietf.org References: From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Mon, 9 Jul 2018 23:14:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="slUXA9YIJnQgp2Erju4t75ilPF5T9jEZc" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 21:15:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --slUXA9YIJnQgp2Erju4t75ilPF5T9jEZc Content-Type: multipart/mixed; boundary="sEAFLYFyc8psUGbXbX7jBpR4vYeHRmW3B"; protected-headers="v1" From: Eliot Lear To: Ted Hardie , rfcplusplus@ietf.org Message-ID: Subject: Re: [Rfcplusplus] Conversation as metaphor References: In-Reply-To: --sEAFLYFyc8psUGbXbX7jBpR4vYeHRmW3B Content-Type: multipart/alternative; boundary="------------BD5C79F78A1DE364AA5B980A" Content-Language: en-US This is a multi-part message in MIME format. --------------BD5C79F78A1DE364AA5B980A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ted, I like your metaphor of a conversation, but it seems to me that we have to bound what we mean.=C2=A0 This is not a conversation between friends, = nor a @Tweet, but a very formal conversation in which a well supported specification or point of view is articulated.=C2=A0 Each contribution to= that conversation, as far as RFCs are concerned, should be sufficiently clear so as to be consumable, and each should be important, no matter which stream they come from. As to voices, one of the perhaps lost aspects of RFCs is that Jon always encouraged dissenting views on important topics to be published, so long as they were well reasoned and reasonably well written.=C2=A0 Personally = I'd like to see more dissenting views coming out of independent submissions.=C2=A0 I know I have quite a few to share ;-)=C2=A0 I offer t= hat only in as much as having a few dissenting views might make clear that we really do speak with multiple voices. Anyway, I won't be in Montreal, so here's my own bottom line:=C2=A0 if th= e IAB are serious about actually using different labels, ask yourselves what the plan is to make those new series successful.=C2=A0 How will the = new series be promoted?=C2=A0 What will you attract readership?=C2=A0 And wha= t will the rules of the road be for the series?=C2=A0 If you do not have a plan,= then let's not be under any illusions that the new series will be successful. Eliot On 09.07.18 17:24, Ted Hardie wrote: > In a different thread, Eric made a statement about the RFC Series > being in conversation with other publications: > > The RFC series (and also I-Ds) have an important role to play > here, but it also exists in conversation with a lot of other > publication venues, and I think that's healthy. > > > While I agree with him, I think the metaphor of "conversation" is even > more useful in describing both the current series and the question > before us.=C2=A0 From my personal perspective, the primary reason we us= e > "RFC" as a series identifier is to identify a specific set of > technical documents as part of a common "conversation".=C2=A0 The adopt= ion > of the term and series by the IETF was a signal about the conversation > their documents were to be part of; choosing a different document=C2=A0= > series (like ANSI, ISO, or minting a new one) would have sent a signal > about a different technical community with whom the IETF was in dialog.= =C2=A0 > > When the idea of different streams and stream managers gelled, we kept > the same series identifier for all of them.=C2=A0 I think, personally, = we > did that because we wanted to be clear that all of the documents > continued to be part of a larger conversation about the development of > Internet technologies. > > One way to understand the problem motivating this BoF is also through > the metaphor of conversation: many outside the community simply don't > recognize that there are multiple voices inside that conversation.=C2=A0= > They see all of the documents as utterances by a single, somewhat > nebulous group.=C2=A0 That can cause problems.=C2=A0 Among those named = earlier > were the academic community's failure to value the output of the IRTF; > vendors or customers not distinguishing consensus output from > proprietary alternatives; and even a few efforts to get rejected ideas > to appear to have been accepted ones. > > The question before us could be cast as:=C2=A0 is it more important now= to > highlight the different voices that the streams and statuses currently > convey, so that others understand them as disctinct?=C2=A0 > > As Eric points out, there are other ways to maintain a conversation > among different groups than to make their output part of a single > series.=C2=A0 There are also other ways we could try to make sure that = we > highlight that distinction more fully (using STD numbers for all IETF > standards documents, for example, from proposed standard onward).=C2=A0= But > I think this is the core of the tension, shorn of discussion of brand > or history:=C2=A0 how to we get to the right balance of maintaining the= > conversation while improving the understanding that these are > individual voices within it? > > My thoughts as individual, > > regards, > > Ted > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --------------BD5C79F78A1DE364AA5B980A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Ted,

I like your metaphor of a conversation, but it seems to me that we have to bound what we mean.=C2=A0 This is not a conversation bet= ween friends, nor a @Tweet, but a very formal conversation in which a well supported specification or point of view is articulated.=C2=A0= Each contribution to that conversation, as far as RFCs are concerned, should be sufficiently clear so as to be consumable, and each should be important, no matter which stream they come from.

As to voices, one of the perhaps lost aspects of RFCs is that Jon always encouraged dissenting views on important topics to be published, so long as they were well reasoned and reasonably well written.=C2=A0 Personally I'd like to see more dissenting views com= ing out of independent submissions.=C2=A0 I know I have quite a few to share ;-)=C2=A0 I offer that only in as much as having a few dissen= ting views might make clear that we really do speak with multiple voices.

Anyway, I won't be in Montreal, so here's my own bottom line:=C2=A0= if the IAB are serious about actually using different labels, ask yourselves what the plan is to make those new series successful.=C2= =A0 How will the new series be promoted?=C2=A0 What will you attract readership?=C2=A0 And what will the rules of the road be for the series?=C2=A0 If you do not have a plan, then let's not be under an= y illusions that the new series will be successful.

Eliot


On 09.07.18 17:24, Ted Hardie wrote:
In a different thread, Eric made a statement about the RFC Series being in conversation with other publications:

The RFC series (and also I-Ds) have an important role to play here, but it also exists in conversation with a lot of other publication venues, and I think that's healthy.

While I agree with him, I think the metaphor of "conversation" is even more useful in describing both the current series and the question before us.=C2=A0 From my person= al perspective, the primary reason we use "RFC" as a series identifier is to identify a specific set of technical documents as part of a common "conversation".=C2=A0 The adoptio= n of the term and series by the IETF was a signal about the conversation their documents were to be part of; choosing a different document=C2=A0 series (like ANSI, ISO, or minting a n= ew one) would have sent a signal about a different technical community with whom the IETF was in dialog.=C2=A0

When the idea of different streams and stream managers gelled, we kept the same series identifier for all of them.=C2=A0= I think, personally, we did that because we wanted to be clear that all of the documents continued to be part of a larger conversation about the development of Internet technologies.

One way to understand the problem motivating this BoF is also through the metaphor of conversation: many outside the community simply don't recognize that there are multiple voices inside that conversation.=C2=A0 They see all of the documents as utterances by a single, somewhat nebulous group.=C2= =A0 That can cause problems.=C2=A0 Among those named earlier were t= he academic community's failure to value the output of the IRTF; vendors or customers not distinguishing consensus output from proprietary alternatives; and even a few efforts to get rejected ideas to appear to have been accepted ones.

The question before us could be cast as:=C2=A0 is it more important now to highlight the different voices that the streams and statuses currently convey, so that others understand them as disctinct?=C2=A0

As Eric points out, there are other ways to maintain a conversation among different groups than to make their output part of a single series.=C2=A0 There are also other ways we cou= ld try to make sure that we highlight that distinction more fully (using STD numbers for all IETF standards documents, for example, from proposed standard onward).=C2=A0 But I think this= is the core of the tension, shorn of discussion of brand or history:=C2=A0 how to we get to the right balance of maintainin= g the conversation while improving the understanding that these are individual voices within it?

My thoughts as individual,

regards,

Ted


_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusplus

--------------BD5C79F78A1DE364AA5B980A-- --sEAFLYFyc8psUGbXbX7jBpR4vYeHRmW3B-- --slUXA9YIJnQgp2Erju4t75ilPF5T9jEZc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltD0FMACgkQh7ZrRtnS ejNmEAgAmE0+CiTT/4y8zanxFVWRMu1P1bRlYPxKHxportTvWh3VK8qL/VhdBb5H R1q5BjzA8E4whIkbmQ5yM+jVGI1QukvBGw54YoWDPmQxgU8GhL8L/xxmJZvbAaMC xVgrqKOLxYhw/G/+YxHLXFSxJNUocYCs/aq7YjdXVSEAhYOkSMQCBRM4Ozmy+jrN Ey47j5FQvHVQbuv7zTF1nKwNo/Dzeuq6ov92vHS9dlmsHVWSXqhfk/Z6xS/z1XM6 ixCQmOaioIAG6Vry2Oh+ZUhDrEyZr3bzLR7wx7ZWanOd+Hi1dh0yHifVUZIZwA62 1IoAH69WaEwKjI6c+8Rsw45dSuw9ww== =O9oV -----END PGP SIGNATURE----- --slUXA9YIJnQgp2Erju4t75ilPF5T9jEZc-- From nobody Mon Jul 9 15:17:21 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93738130EA1 for ; Mon, 9 Jul 2018 15:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REO-EFqGRn5I for ; Mon, 9 Jul 2018 15:17:13 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD79130DC3 for ; Mon, 9 Jul 2018 15:17:13 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id b15-v6so38841276oib.10 for ; Mon, 09 Jul 2018 15:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=88K65akGRNudCLWuN1ZDZSTouMOldE2r0ICgCRyrZWg=; b=g7qNGSQYt1Sa4l+fgLzJnWzuLfuGm/GwwXzXHgc6BBFTg8S2AFY9dp14jQ5a225Zjx gnYHqhVM6/xSHi1p8g1xqpxb/XndZPQxeY/dMMsATYO4ylu7UF1zwd7unLYwzVFY/vDk N3OSbSJ10hZ0zLkpvkrH38MDFSq2Ua6UxMjRT3CuwZGKGjqOWaU8+vZ9Nhyzy+e8pSKz OqXmIiLMW6daSVgQzKeyUQPXa6D6/Ra5F4Pvz+QTxIb7zxg9YT/CewtGP1PXC6HZhw3S qdCgBBZGgtuCerd6jFZvqEB60Itq6bCPZWEMKMy2VOv3JnuAuwYfTuJyN1fMh5W5VzC6 4EMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=88K65akGRNudCLWuN1ZDZSTouMOldE2r0ICgCRyrZWg=; b=iuezDZ1aDLGCycZwWYQgk99EpLEEAaJMUwNMFv+sWBm9/FhyLbNc84ELjqOopTU4hM NvjxmybQx17XYtrTFtq5V2v4/5msbaA3WpPyPKgIE5RkiVcan95hTlcgSGr4JH9odRUU 6GVG+QJUdEqcBVuzVEf+2IG/HQ1zjjzwVjjcnWjchukgKGA2TWs5YWOEmDQwguwTaBCu OgPW7omKf1obEnEy8Z8SaZdjqWzztGqIQC5t0rN+SIqGimYCfL5MBjNWMZOT+sJMTHa4 cZgIYGHZKqvBfJtyvtEttlb5E1bY33a1fQcfIe5oeD/fx8nBADhkp1skl0znC7yGlXMe kyLw== X-Gm-Message-State: APt69E0K0D3Cyl0gOLmcwoB4MKfbAJIznyRvgLn6Gfsp8VOknMWN50cr vHIkwf1Zn7ZcYfFa01KwFEMj8M6/dAm4LdYsMnYi5Oz2lP0= X-Google-Smtp-Source: AAOMgpc6hQXccSkyJbiQO+861eYra89DtyCtUXHlalVUOpYKImdcIn0V7yu7s7EJ7i7nwI8N8wLswgzGAWN3ytyyU+M= X-Received: by 2002:aca:d088:: with SMTP id j8-v6mr26011668oiy.276.1531174632120; Mon, 09 Jul 2018 15:17:12 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 9 Jul 2018 18:17:00 -0400 Message-ID: To: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000009b77a05709860cf" Archived-At: Subject: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 22:17:18 -0000 --00000000000009b77a05709860cf Content-Type: text/plain; charset="UTF-8" Hey all, I'm still catching up on the many emails on this list, so I might be missing something, but I wanted to surface two arguments that seem to me to be pretty dispositive that there is a problem here to solve: 1. A recommendation to hold is a recommendation to buy / sunk cost fallacy Suppose someone came to you with the following problem statement: - We have 16 (or so) types of document that we want to publish - We need readers of one of these documents to be clear on which type they're reading Is there anyone here who would look at that problem statement and say, "The ideal way to do that is to throw all the documents into one linear series, and have the reader look for distinguishing marks in the text of the document"? We shouldn't keep supporting a system we wouldn't build today. 2. This is not about us There are a total of a little over 30 unique senders on this list. The person closest to being a newcomer is Joe Hall, whose first IETF meeting was IETF 89, more than four years ago. This discussion isn't about us -- it's about the much larger group of people who read these documents and try to build products off of them that work. In an ideal world, some of those folks would be participating here. Until that happens, we should rely on what data we can gather. We've already head several anecdotes, and they're pretty much all on one side -- the current arrangement causes confusion and makes RFCs less useful. To try to be slightly more systematic, I sent a survey out over the weekend to a bunch of communities I participate in that are "IETF-adjacent". It got 115 responses, and the data [1] are consistent with the anecdata: - 52% of respondents thought that an RFC was "A document published by the IETF that defines a technical standard for the Internet" - While 93% of respondents agreed that the IETF can publish RFCs, the other streams came in much farther behind; the IAB was second-most recognized, at only 26% - Nobody has any idea that about the taxonomy of RFCs. A majority of people said they thought that there were 5 types, but I would conjecture that's just an artifact of the options I put in there. Based on those observations, I hope it's clear to folks that there is a problem to be solved here. The survey data, sketchy as they are, also point toward the solution, which is to refine the RFC label to have a much more limited semantic, probably only IETF and possibly only standards. Hope that helps, --Richard [1] https://docs.google.com/forms/d/e/1FAIpQLSeMoeR0TBWkZNpBKXJN3Am6nUL04Vr4-12T2VgEbiRdBwzngQ/viewanalytics --00000000000009b77a05709860cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

I'm still catching up on the many emai= ls on this list, so I might be missing something, but I wanted to surface t= wo arguments that seem to me to be pretty dispositive that there is a probl= em here to solve:


1. A recommendation to hold is a recommendatio= n to buy / sunk cost fallacy

Suppose someone came to you with the fo= llowing problem statement:

- We have 16 (or so) types of document th= at we want to publish
- We need readers of one of these documents to be = clear on which type they're reading

Is there anyone here who wou= ld look at that problem statement and say, "The ideal way to do that i= s to throw all the documents into one linear series, and have the reader lo= ok for distinguishing marks in the text of the document"?=C2=A0 We sho= uldn't keep supporting a system we wouldn't build today.

2. This is not about us

There are a total of a little over 30 uniqu= e senders on this list.=C2=A0 The person closest to being a newcomer is Joe= Hall, whose first IETF meeting was IETF 89, more than four years ago.=C2= =A0 This discussion isn't about us -- it's about the much larger gr= oup of people who read these documents and try to build products off of the= m that work.

In an ideal world, some of those folks would be partici= pating here.=C2=A0 Until that happens, we should rely on what data we can g= ather.=C2=A0 We've already head several anecdotes, and they're pret= ty much all on one side -- the current arrangement causes confusion and mak= es RFCs less useful.

To try to be slightly more systematic, I sent a= survey out over the weekend to a bunch of communities I participate in tha= t are "IETF-adjacent".=C2=A0 It got 115 responses, and the data [= 1] are consistent with the anecdata:

- 52% of respondents thought th= at an RFC was "A document published by the IETF that defines a technic= al standard for the Internet"

- While 93% of respondents agreed= that the IETF can publish RFCs, the other streams came in much farther beh= ind; the IAB was second-most recognized, at only 26%

- Nobody has an= y idea that about the taxonomy of RFCs.=C2=A0 A majority of people said the= y thought that there were 5 types, but I would conjecture that's just a= n artifact of the options I put in there.

Based on those observation= s, I hope it's clear to folks that there is a problem to be solved here= .=C2=A0 The survey data, sketchy as they are, also point toward the solutio= n, which is to refine the RFC label to have a much more limited semantic, p= robably only IETF and possibly only standards.

Hope that helps,
<= br>--Richard

[1] https://d= ocs.google.com/forms/d/e/1FAIpQLSeMoeR0TBWkZNpBKXJN3Am6nUL04Vr4-12T2VgEbiRd= BwzngQ/viewanalytics
--00000000000009b77a05709860cf-- From nobody Mon Jul 9 15:32:34 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764F5130DF0 for ; Mon, 9 Jul 2018 15:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nmF54I-PBVEV for ; Mon, 9 Jul 2018 15:32:30 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (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 41637130DC3 for ; Mon, 9 Jul 2018 15:32:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 2A158E86FFE; Mon, 9 Jul 2018 15:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1531175550; bh=FvyxxoFfjFo1D42c5d8DQzjvx8Bp6qupo2fTGsMv+fQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=n+QYKhR+jjHZo2rLnbMQqbKdUoHnng2GXGVC7d8u+mLfgnVjAI0n2i8MWsed2l4M6 qTGNw5x2zwZK1x0E54CApqZIJgE+5fr4PbZemoC6n4H73ULtKU9LuSPHDv4AV/zXgW b13UK6Nv6l2O3WuqhIJ7HA0YyfmZj83mJtEecD5A= X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id A8861E86FFB; Mon, 9 Jul 2018 15:32:29 -0700 (PDT) To: Richard Barnes , rfcplusplus@ietf.org References: From: "Joel M. Halpern" Message-ID: Date: Mon, 9 Jul 2018 18:32:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.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: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 22:32:33 -0000 This formulation assumes that change does not have a cost. It does. I agree that not changing has some cost. However, absent indication that the changes will actually address the claimed problem, paying the various direct and indirect costs of changing things is not inherently a good thing. If we really want to change something that causes confusion in a way that actually causes us process problems, maybe we should actually tackle one? In particular, in looking at kinds of confusion, one of the ones that causes the IETF real and significant problems is when outside groups look at individual Internet Drafts, and treat them like working group adopted products. (I would like to fix folks treating adotped I-Ds as if they were finished RFCs, but given that those already have clearly distinct labels, that does not seem possible.) In one sense, fixing that would likely require changing quite a few moving parts in our process. It is clearly something the IETF owns. It is something that causes myriad issues between us and other standards bodies and between us an users. We often have to actually put in work pushing back on folks mis-characterizing individual I-Ds as IETF work. Yours, Joel PS: I do not see how we can draw any conclusion from the very informal survey. We have been lectured, with good reason, in the past about the dangers of drawing conclusions from even carefully formulated and carefully distributed surveys. On 7/9/18 6:17 PM, Richard Barnes wrote: > Hey all, > > I'm still catching up on the many emails on this list, so I might be > missing something, but I wanted to surface two arguments that seem to me > to be pretty dispositive that there is a problem here to solve: > > > 1. A recommendation to hold is a recommendation to buy / sunk cost fallacy > > Suppose someone came to you with the following problem statement: > > - We have 16 (or so) types of document that we want to publish > - We need readers of one of these documents to be clear on which type > they're reading > > Is there anyone here who would look at that problem statement and say, > "The ideal way to do that is to throw all the documents into one linear > series, and have the reader look for distinguishing marks in the text of > the document"?  We shouldn't keep supporting a system we wouldn't build > today. > > > 2. This is not about us > > There are a total of a little over 30 unique senders on this list.  The > person closest to being a newcomer is Joe Hall, whose first IETF meeting > was IETF 89, more than four years ago.  This discussion isn't about us > -- it's about the much larger group of people who read these documents > and try to build products off of them that work. > > In an ideal world, some of those folks would be participating here. > Until that happens, we should rely on what data we can gather.  We've > already head several anecdotes, and they're pretty much all on one side > -- the current arrangement causes confusion and makes RFCs less useful. > > To try to be slightly more systematic, I sent a survey out over the > weekend to a bunch of communities I participate in that are > "IETF-adjacent".  It got 115 responses, and the data [1] are consistent > with the anecdata: > > - 52% of respondents thought that an RFC was "A document published by > the IETF that defines a technical standard for the Internet" > > - While 93% of respondents agreed that the IETF can publish RFCs, the > other streams came in much farther behind; the IAB was second-most > recognized, at only 26% > > - Nobody has any idea that about the taxonomy of RFCs.  A majority of > people said they thought that there were 5 types, but I would conjecture > that's just an artifact of the options I put in there. > > Based on those observations, I hope it's clear to folks that there is a > problem to be solved here..  The survey data, sketchy as they are, also > point toward the solution, which is to refine the RFC label to have a > much more limited semantic, probably only IETF and possibly only standards. > > Hope that helps, > > --Richard > > [1] > https://docs.google.com/forms/d/e/1FAIpQLSeMoeR0TBWkZNpBKXJN3Am6nUL04Vr4-12T2VgEbiRdBwzngQ/viewanalytics > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > From nobody Mon Jul 9 17:30:46 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FB7130EB3 for ; Mon, 9 Jul 2018 17:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 44NfoR0b2V2W for ; Mon, 9 Jul 2018 17:30:42 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 18A42130EB0 for ; Mon, 9 Jul 2018 17:30:42 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id j3-v6so14797959pfh.11 for ; Mon, 09 Jul 2018 17:30:42 -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=PlXAEHp3oEYeSdDpDp3NbFZXApRVuXabDR6JU+ECb54=; b=FClv0e+R6CtkGCh6aFnf42uprWyle+ovEQLu9bFPzECRYTR/jAnCRudTYmHUeLgSCx unJbG2VFeHg37lyvzGWYw2V/Njth+2PKXk3uYE8ZyybiFJdkNWc5R2BN3EZVaoB0TMuI ldijNWWqv+mTzfTHsZrcGeyPihRXSxUACRtMJkz5yDqROdWywZh+ArZ8QCpg8/ocszDn JH9TZrazLU+NP1ivWdbxwKzR4QzNZuGJ6P7OMpBvmONEPCW0ZuwI+3cEyrcwgyex2Z+M bOtYVLeKtiOwk0tuS3w4oQkwWg6ot25eXSSMnM758pwsKNymm+koa2rxBfPfBdb0hAcM 0/BA== 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=PlXAEHp3oEYeSdDpDp3NbFZXApRVuXabDR6JU+ECb54=; b=UN3X3hcky6fqXU5r0W3qIduclxqd8OcHFV8t/23Ty1QzD6uT5R6r/9UPcZOTUAEd4e 6MC7ELW7ViXYwxu0Xvg5ESKwYRrhhQNyGBZY4p5DS/yyF7a//cKK9yiMffWfI5jqR5/s XW/fK6/XnZ0fAneu51xrL/4qF/M/XK4I6WFF5oJUE6oiZMwsG6G3waiajRoVXAyhMOjj 1MrNFKgxSoZ3vVKnY1r0eEzXvQ+tcQbpLrEUHvfgY0FQGm+SjbpXcdYFXfA5KZxgWG2T /11BfrerzbwgjnXcmYI3pTbAjpkKuv7UdMnfRAIGvBJv4ebP2BJXjrDBM1KtNP9eM0qT LNyA== X-Gm-Message-State: APt69E3Yp/xaNMvNJv3EFmeWk3hoAGnJlFoySiEkGujg9NzGBxbryKnY 49eb4fRgzwAntm/brlc33gtcnQ== X-Google-Smtp-Source: AAOMgpclKD/k8KcIo+DPUZVl3KlOGjYZojErfr/ua1Y2z79UM+QJXl+pla6HLVAoaS7UlSl18Rqk8A== X-Received: by 2002:a63:fc44:: with SMTP id r4-v6mr20736473pgk.169.1531182641444; Mon, 09 Jul 2018 17:30:41 -0700 (PDT) Received: from [130.216.38.4] (sc-cs-316971.cs.auckland.ac.nz. [130.216.38.4]) by smtp.gmail.com with ESMTPSA id h7-v6sm3774552pfd.155.2018.07.09.17.30.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 17:30:40 -0700 (PDT) To: "Joel M. Halpern" , Richard Barnes , rfcplusplus@ietf.org References: From: Brian E Carpenter Message-ID: Date: Tue, 10 Jul 2018 12:30:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 00:30:44 -0000 On 10/07/2018 10:32, Joel M. Halpern wrote: ... > PS: I do not see how we can draw any conclusion from the very informal > survey. We have been lectured, with good reason, in the past about the > dangers of drawing conclusions from even carefully formulated and > carefully distributed surveys. It's worse than that. The survey was hastily designed and included at least one ad hominem entry, and I think anyone with experience of surveys and their analysis would simply junk the results. See below for something more concrete on that. On 7/9/18 6:17 PM, Richard Barnes wrote: ... > Based on those observations, I hope it's clear to folks that there is a > problem to be solved here.. The survey data, sketchy as they are, also > point toward the solution, which is to refine the RFC label to have a > much more limited semantic, probably only IETF and possibly only standards. That's a pretty perfect example of confirmation bias. Sorry, but even if we accept that there's a problem worth solving, the "data" don't point to any particular solution. I hope that as scientists and engineers, we can do better than this. By the way, the full results are at https://docs.google.com/forms/d/e/1FAIpQLSeMoeR0TBWkZNpBKXJN3Am6nUL04Vr4-12T2VgEbiRdBwzngQ/viewanalytics The last question is interesting.: "Does an RFC published by the IETF require IETF consensus?" got 58.8% "no", which is the correct answer. However, this seems very unlikely as the preferred response from outsiders. Only insiders know that only some IETF stream RFCs require IETF consensus. So I don't think the data can reasonably be assumed to represent the opinion of outsiders. Brian From nobody Mon Jul 9 19:24:04 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB88131083 for ; Mon, 9 Jul 2018 19:24:02 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 J2Z5A383fhCp for ; Mon, 9 Jul 2018 19:24:00 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 3541F130EC0 for ; Mon, 9 Jul 2018 19:24:00 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id x5-v6so1654744pgp.7 for ; Mon, 09 Jul 2018 19:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:organization:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=8wytkQquvnUPE0otCsT7vg7V/TY6W0GSLqZ33Zukteg=; b=lm1vogFGQtZE+U5py+xr2SeO+OAWbUH1lRHBzKrhKpn1uEJAZ1KYecHxNCXKHhPrSZ 6eYytDQA9sNSDDL2eWhfg++vfIYC0DDEPrM7tkAlh8PvFdSqsXcIRiwkl5wjTAceCSip AyIhim8oFgfaxTgJcGAkMw4b1gMOIFZi51TVnitw8DYBy1rsWqirYcFLC2xGdSfQZ/OF mdjRbj7//of6voujF0fBujR0/va0/VD2X7stOw2tmiyA5h22QtHbJVqj6Pi673Z3Ntjg l1+bXYGXJIQkvDbtngDMeQnGwqxbYtA93ywaYZH4KA3/ltLWm1C3+DZRW2jE2p4uiojh UR0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:organization:to:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=8wytkQquvnUPE0otCsT7vg7V/TY6W0GSLqZ33Zukteg=; b=TwEgKLDAMje+4kogWXCVtWV2+hAIbgQfV4GsPoLut6FIIhETq8blTVtqa8JAI3o4nG pTHy3TfeW1XRYVj82gr/iKReyDWrTH3Jqn99Wt9NiqXKgbJc1khZxInwYvbtU3TRJ5pi ygIOyUJTa7+MJsZXJ+MAGcIKegFQk8O6qclvhAcyTiDVlcjCVE5O5wyfZfeZaoEOAjKY +IDsb5KDr7yv/yZ9J1zysMPU/sr6VtMWoIvZB4k47O3gKOn4WlSr3b5CaGrKxRBhQd0y LLZS5U2jU/04q/i2cfTqDaLPqt2SlY65s8rqJpvUqfF/SWeiP3nDsZ+pxa+shrgQI37O 84Og== X-Gm-Message-State: APt69E3ayUEYBPmp4YAxdBesC4M2g0xAqLi1UYB0+Cheh4Nc9tJHf471 NT34BTP3JWHojKUH34Sl1dwc3A== X-Google-Smtp-Source: AAOMgpc1GWntN19SCEARMebOSKSNCl3HMUABtSu0MmskVPR3QZCDpDOjPwiBrZz1XVxuQbRT8iWs/g== X-Received: by 2002:a63:d20e:: with SMTP id a14-v6mr1461646pgg.226.1531189439383; Mon, 09 Jul 2018 19:23:59 -0700 (PDT) Received: from [130.216.38.4] (sc-cs-316971.cs.auckland.ac.nz. [130.216.38.4]) by smtp.gmail.com with ESMTPSA id x68-v6sm27775582pfb.138.2018.07.09.19.23.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 19:23:58 -0700 (PDT) From: Brian E Carpenter Organization: University of Auckland To: rfcplusplus@ietf.org Message-ID: <888b184e-51ea-23fc-afaa-f9b5116d480a@gmail.com> Date: Tue, 10 Jul 2018 14:23:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfcplusplus] Qualified labels X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 02:24:03 -0000 Hi, I don't think there's any disagreement that better labels are desirable. I do think this would all be a lot simpler if we could just agree to move to a single-stage standards track, but since we must support status changes within the standards track, including obsoletion, we are forced to have external labels that are not in the archived format. That's an opportunity as well as a challenge. So here's a proposal: 1) Continue to use the RFC series as today for multiple purposes. But recognise more clearly that the number is an archival reference. 2) For all normal purposes, including citations, use a *qualified* label. Rather than writing a formal definition, there's an example of each qualifier below. An advantage is that this can be retrofitted straightforwardly to *all* RFCs, indexes, citation libraries, etc. And it could be removed just as easily if it proves to be a problem rather than a solution. RFC8200-STD (or RFC8200-STD86) RFC8414-PS RFC5681-DS RFC2026-BCP (or RFC2026-BCP9) RFC7557-EXPT RFC8394-INFO (for IETF informationals) RFC7663-IAB RFC7575-RSCH (for IRTF informationals) RFC8351-INDEP (for Independent informationals) RFC2460-OBS RFC1128-UNK RFC1130-HIST Regards Brian From nobody Mon Jul 9 19:44:28 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFE4131070 for ; Mon, 9 Jul 2018 19:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epODcs-BCHdi for ; Mon, 9 Jul 2018 19:44:23 -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 793D61310D4 for ; Mon, 9 Jul 2018 19:44:23 -0700 (PDT) Received: from unescapeable.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6A2iM8x058428 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 9 Jul 2018 21:44:23 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be unescapeable.local To: rfcplusplus@ietf.org References: <888b184e-51ea-23fc-afaa-f9b5116d480a@gmail.com> From: Robert Sparks Message-ID: <0dbf07da-969c-9704-9618-8d3d7ff03004@nostrum.com> Date: Mon, 9 Jul 2018 21:44:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <888b184e-51ea-23fc-afaa-f9b5116d480a@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] Qualified labels X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 02:44:27 -0000 On 7/9/18 9:23 PM, Brian E Carpenter wrote: > Hi, > > I don't think there's any disagreement that better labels are > desirable. I do think this would all be a lot simpler if we > could just agree to move to a single-stage standards track, > but since we must support status changes within the standards > track, including obsoletion, we are forced to have external > labels that are not in the archived format. That's an opportunity > as well as a challenge. So here's a proposal: > > 1) Continue to use the RFC series as today for multiple purposes. > But recognise more clearly that the number is an archival reference. > > 2) For all normal purposes, including citations, use a *qualified* > label. Rather than writing a formal definition, there's an example > of each qualifier below. > > An advantage is that this can be retrofitted straightforwardly > to *all* RFCs, indexes, citation libraries, etc. If we were to pursue this path: That's not quite straightforward. It's easy if you just snapshot the current qualifiers, but if you want to be historically correct, it's going to take some non-straightforward work. It would also need a decision about edges like the following (both for handling what has happened, and what could happen in the future): Would RFC5249-INFO and RFC5249-PS be different documents, or aliases for the same document? (I assume having RFC5249-INFO disappear from the archival record would be unacceptable). How would a user finding RFC5249-INFO learn about RFC5249-PS? (And a string of very familiar questions would follow here). > And it > could be removed just as easily if it proves to be a problem > rather than a solution. > > RFC8200-STD (or RFC8200-STD86) > RFC8414-PS > RFC5681-DS > RFC2026-BCP (or RFC2026-BCP9) > > RFC7557-EXPT > RFC8394-INFO (for IETF informationals) > RFC7663-IAB > RFC7575-RSCH (for IRTF informationals) > RFC8351-INDEP (for Independent informationals) > > RFC2460-OBS > RFC1128-UNK > RFC1130-HIST > > Regards > Brian > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Mon Jul 9 19:50:04 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187A8131158 for ; Mon, 9 Jul 2018 19:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXzNVuSY68dd for ; Mon, 9 Jul 2018 19:49:52 -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 B80D7131179 for ; Mon, 9 Jul 2018 19:49:52 -0700 (PDT) Received: from unescapeable.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6A2npHm059400 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 9 Jul 2018 21:49:52 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be unescapeable.local From: Robert Sparks To: rfcplusplus@ietf.org References: <888b184e-51ea-23fc-afaa-f9b5116d480a@gmail.com> <0dbf07da-969c-9704-9618-8d3d7ff03004@nostrum.com> Message-ID: <7787043f-1ab0-f957-2d26-e915009c4d3f@nostrum.com> Date: Mon, 9 Jul 2018 21:49:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <0dbf07da-969c-9704-9618-8d3d7ff03004@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] Qualified labels X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 02:50:01 -0000 _sigh_ - even after carefully trying to point to a particular edge, I transcribed the number incorrectly. Please substitute 5289 for all the rfc number examples I pointed to below. RjS p.s. On 7/9/18 9:44 PM, Robert Sparks wrote: > > > On 7/9/18 9:23 PM, Brian E Carpenter wrote: >> Hi, >> >> I don't think there's any disagreement that better labels are >> desirable. I do think this would all be a lot simpler if we >> could just agree to move to a single-stage standards track, >> but since we must support status changes within the standards >> track, including obsoletion, we are forced to have external >> labels that are not in the archived format. That's an opportunity >> as well as a challenge. So here's a proposal: >> >> 1) Continue to use the RFC series as today for multiple purposes. >> But recognise more clearly that the number is an archival reference. >> >> 2) For all normal purposes, including citations, use a *qualified* >> label. Rather than writing a formal definition, there's an example >> of each qualifier below. >> >> An advantage is that this can be retrofitted straightforwardly >> to *all* RFCs, indexes, citation libraries, etc. > If we were to pursue this path: > > That's not quite straightforward. It's easy if you just snapshot the > current qualifiers, but if you want to be historically correct, it's > going to take some non-straightforward work. It would also need a > decision about edges like the following (both for handling what has > happened, and what could happen in the future): > > Would RFC5249-INFO and RFC5249-PS be different documents, or aliases > for the same document? (I assume having RFC5249-INFO disappear from > the archival record would be unacceptable). How would a user finding > RFC5249-INFO learn about RFC5249-PS? (And a string of very familiar > questions would follow here). >>   And it >> could be removed just as easily if it proves to be a problem >> rather than a solution. >> >> RFC8200-STD (or RFC8200-STD86) >> RFC8414-PS >> RFC5681-DS >> RFC2026-BCP (or RFC2026-BCP9) >> >> RFC7557-EXPT >> RFC8394-INFO  (for IETF informationals) >> RFC7663-IAB >> RFC7575-RSCH  (for IRTF informationals) >> RFC8351-INDEP (for Independent informationals) >> >> RFC2460-OBS >> RFC1128-UNK >> RFC1130-HIST >> >> Regards >>      Brian >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Mon Jul 9 21:53:49 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4F0130E13 for ; Mon, 9 Jul 2018 21:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 UlyppjBCTkVA for ; Mon, 9 Jul 2018 21:53:46 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD74130DDB for ; Mon, 9 Jul 2018 21:53:45 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id s21-v6so15245733pfm.6 for ; Mon, 09 Jul 2018 21:53: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=T3IRhsoN1FiF00RWFICMfWTFp9y9iFu2NShSvsTsDDY=; b=Bs898zYtXsjdAGSCNS82QnlvctJZil3tdk8j7xs//H01CRzNOy45ebeI0HBK5S9Q+3 EMU4eU6594i3JehPfAdOjwymdXWwkwKMya4zHkdyXpl684/lmdEc4JLsGC7S9vhvsjZo hPRlDB1tFN0NmxwnKSV8rfWAXb52OKkSX8WWNVZ39gxB0mILZP+sfm4Tym+l/XL1AgmW xZ7R6trnd1uwn+vPsraASiMCL0glPVjWiIwibrhvY3w655MJI6sVEmmS0+Uk0IqzHWwc qawN1n8/G9iRjzMTHU0kp9/7QvFynxezJiPkb8zyQQaGTz4Czl3eEj8cZ5fstWCKa9mu 9YQw== 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=T3IRhsoN1FiF00RWFICMfWTFp9y9iFu2NShSvsTsDDY=; b=akkca6WSNTrj9J4uVqSscLK7AOS99BU1ojxLirQZ5lyW7bi0Oh3gafGlXRsMVIGZc7 FeQLBfPQE24nxl23OBp8l9r4JTLbToHAwVkR53d8tvhzTDvHdtJbkiwO4SK60/NZ6HS8 DJBmgx1f1LEm18W/JNN3ciR5KKalV/mdGhfTQpjw4Yw3BslBhVLp2FKVOq0MAXoINXBV V8qWbWLOwEHwyshbmyMuZcCkSaRpYv04OWSchGUVO9+Lst0/I/l97+8ZO55E7+NvPeSt pdkwcTJAWM6QVS3o//fRbiFoPMdELl3mVpSAAAOouhgJjhU1pFXI+jSU3eNnP4+zwhL6 IlaA== X-Gm-Message-State: APt69E3FmLoQJZqWsAOUqISuiZ3QsJS2vgKrnSmEuL87aVQjJHmq97wR TkCP6ROcux9GUL0MM82b0miL3w== X-Google-Smtp-Source: AAOMgpf08bNScP0j9z+pMB3cjOrJLQC3++qi6BZcGHScQseFVVwL6CwLwhv8gbH/XA6IGE6UzIzJGA== X-Received: by 2002:a62:ce81:: with SMTP id y123-v6mr24272516pfg.95.1531198425107; Mon, 09 Jul 2018 21:53:45 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id o12-v6sm11062521pgd.71.2018.07.09.21.53.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 21:53:44 -0700 (PDT) To: Robert Sparks , rfcplusplus@ietf.org References: <888b184e-51ea-23fc-afaa-f9b5116d480a@gmail.com> <0dbf07da-969c-9704-9618-8d3d7ff03004@nostrum.com> <7787043f-1ab0-f957-2d26-e915009c4d3f@nostrum.com> From: Brian E Carpenter Message-ID: <10f6771e-7de6-530d-0c7b-4b347a23612c@gmail.com> Date: Tue, 10 Jul 2018 16:53:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7787043f-1ab0-f957-2d26-e915009c4d3f@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfcplusplus] Qualified labels X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 04:53:48 -0000 On 10/07/2018 14:49, Robert Sparks wrote: > _sigh_ - even after carefully trying to point to a particular edge, I=20 > transcribed the number incorrectly. >=20 > Please substitute 5289 for all the rfc number examples I pointed to bel= ow. Right. My thinking is that the label would indeed need to be ephemeral in case a document changes status, and I guess that would lead to tombstones in the citation libraries. Or to put it another way, a document would have a label stack, with the current label on top, but the previous ones still there for the sake of previous citations. So the label stack for RFC5289 should** be 1. RFC5289-PS 2. RFC5289-INFO and that for RFC2460 should be 1. RFC2460-OBS 2. RFC2460-DS ** However, you have hit upon a bug. The IESG may believe that they upgraded RFC5289, but it seems that nobody told the RFC Editor, since it is still officially listed as Informational. Even the tracker is confused. So we have a procedural glitch in this area already. Brian >=20 > RjS >=20 > p.s.=20 > >=20 >=20 > On 7/9/18 9:44 PM, Robert Sparks wrote: >> >> >> On 7/9/18 9:23 PM, Brian E Carpenter wrote: >>> Hi, >>> >>> I don't think there's any disagreement that better labels are >>> desirable. I do think this would all be a lot simpler if we >>> could just agree to move to a single-stage standards track, >>> but since we must support status changes within the standards >>> track, including obsoletion, we are forced to have external >>> labels that are not in the archived format. That's an opportunity >>> as well as a challenge. So here's a proposal: >>> >>> 1) Continue to use the RFC series as today for multiple purposes. >>> But recognise more clearly that the number is an archival reference. >>> >>> 2) For all normal purposes, including citations, use a *qualified* >>> label. Rather than writing a formal definition, there's an example >>> of each qualifier below. >>> >>> An advantage is that this can be retrofitted straightforwardly >>> to *all* RFCs, indexes, citation libraries, etc. >> If we were to pursue this path: >> >> That's not quite straightforward. It's easy if you just snapshot the=20 >> current qualifiers, but if you want to be historically correct, it's=20 >> going to take some non-straightforward work. It would also need a=20 >> decision about edges like the following (both for handling what has=20 >> happened, and what could happen in the future): >> >> Would RFC5249-INFO and RFC5249-PS be different documents, or aliases=20 >> for the same document? (I assume having RFC5249-INFO disappear from=20 >> the archival record would be unacceptable). How would a user finding=20 >> RFC5249-INFO learn about RFC5249-PS? (And a string of very familiar=20 >> questions would follow here). >>> =C2=A0 And it >>> could be removed just as easily if it proves to be a problem >>> rather than a solution. >>> >>> RFC8200-STD (or RFC8200-STD86) >>> RFC8414-PS >>> RFC5681-DS >>> RFC2026-BCP (or RFC2026-BCP9) >>> >>> RFC7557-EXPT >>> RFC8394-INFO=C2=A0 (for IETF informationals) >>> RFC7663-IAB >>> RFC7575-RSCH=C2=A0 (for IRTF informationals) >>> RFC8351-INDEP (for Independent informationals) >>> >>> RFC2460-OBS >>> RFC1128-UNK >>> RFC1130-HIST >>> >>> Regards >>> =C2=A0=C2=A0=C2=A0=C2=A0 Brian >>> >>> _______________________________________________ >>> Rfcplusplus mailing list >>> Rfcplusplus@ietf.org >>> https://www.ietf.org/mailman/listinfo/rfcplusplus >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 From nobody Tue Jul 10 07:21:33 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BE7130DFD for ; Tue, 10 Jul 2018 07:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjk-7oMXNNps for ; Tue, 10 Jul 2018 07:21:27 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88C6128BAC for ; Tue, 10 Jul 2018 07:21:27 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id i12-v6so42929152oik.2 for ; Tue, 10 Jul 2018 07:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WFSY2zoSCVEcgkfS5PVkyd8EYejmXLvk5ibAcepDmB8=; b=ZGpuyGCxKmFbCeg7CDG53pEPSrn5RRrzM55TaoVW3e5Fw052FHnA9nd9fk5E7RPkcg Xv2u4q57mf+v7Xdb93p4qGxWglxNao9a2HZnfaJqaobeUDdDlDE8YNzA0HRGIja+Zof7 dWciGqFkZYUAl3znAZRf8+KVs8LptjgT24QaMyP+fa3+Bg84y6lpa7HvlMcoN3wjtgYU 2fguTq/afDytDnuBFnqWJ0Ynzn6uk3nU6bTfgxvhIsU7/DYYFBRPN76gZmGgF9EaUwg/ gGL4QQuaxWoVbMaesqMQtE3MnZ40/Ti9va4eEL2sELjYUsUQ6Pq9QgQh93R9+DUKGToF BUuw== 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=WFSY2zoSCVEcgkfS5PVkyd8EYejmXLvk5ibAcepDmB8=; b=UJq7kar+RrOY+g0kq6eb7JMN0dtZLfETCB+FpfRn98rG6/cY58VW0kCsC8xtrf1OC7 yTIhhH1MLrYwQJCT7osLg4bCc1/RiBrVDMj4HO6dMCV8tb809ImhUzql99TM+Mr5aK3/ ZbwFg/wssub1cRA5CQItdi6i3BmeR1VXXYT+KgUIz9YTdzXPR/eIpLVGl0rl06kOUxS8 IIAfEjOU1dYzDRjFTgqkHts4UG04spch6lawIdl9LjmjFhewU05uOopfWwk7s61EyarM gyzLn+dTL7j2AHOWAaGvQ5N2JI5aayWEagWYXbGxC0rOcNzpkUbfxgYc6XvqGyVjnddc UuLw== X-Gm-Message-State: APt69E3XF2K8WABqLEIwRN21lwSstOWtOClFclZORo9gB+CRiRLgPuMU UHfcHe5uo8Hr2syppgK1AMfu8CJRvdAQYNSMjNgtNQ== X-Google-Smtp-Source: AAOMgpdsAtJWGzDPK+/5f57aNWBK74KkWqY3TAYYLwGkwgzs7/GlNg4KKgOuXXh1s1LGMpJNNkHvaUKPghgv+GPnqnk= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr26072495oib.155.1531232486749; Tue, 10 Jul 2018 07:21:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 10 Jul 2018 10:21:15 -0400 Message-ID: To: "Joel M. Halpern" Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000007109ea0570a5d89d" Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 14:21:32 -0000 --0000000000007109ea0570a5d89d Content-Type: text/plain; charset="UTF-8" On Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern wrote: > This formulation assumes that change does not have a cost. It does. I > agree that not changing has some cost. However, absent indication that > the changes will actually address the claimed problem... People are presenting indications. Attach what caveats you need to my little study; it's still real data from a relevant population. Do you have better data? > If we really want to change something that causes confusion in a way > that actually causes us process problems, maybe we should actually > tackle one? Without commenting on whether this I-D problem is a worthwhile problem to solve, it is not the one this list is here to discuss. --Richard > In particular, in looking at kinds of confusion, one of the > ones that causes the IETF real and significant problems is when outside > groups look at individual Internet Drafts, and treat them like working > group adopted products. (I would like to fix folks treating adotped > I-Ds as if they were finished RFCs, but given that those already have > clearly distinct labels, that does not seem possible.) > In one sense, fixing that would likely require changing quite a few > moving parts in our process. It is clearly something the IETF owns. It > is something that causes myriad issues between us and other standards > bodies and between us an users. We often have to actually put in work > pushing back on folks mis-characterizing individual I-Ds as IETF work. > > Yours, > Joel > > PS: I do not see how we can draw any conclusion from the very informal > survey. We have been lectured, with good reason, in the past about the > dangers of drawing conclusions from even carefully formulated and > carefully distributed surveys. > > On 7/9/18 6:17 PM, Richard Barnes wrote: > > Hey all, > > > > I'm still catching up on the many emails on this list, so I might be > > missing something, but I wanted to surface two arguments that seem to me > > to be pretty dispositive that there is a problem here to solve: > > > > > > 1. A recommendation to hold is a recommendation to buy / sunk cost > fallacy > > > > Suppose someone came to you with the following problem statement: > > > > - We have 16 (or so) types of document that we want to publish > > - We need readers of one of these documents to be clear on which type > > they're reading > > > > Is there anyone here who would look at that problem statement and say, > > "The ideal way to do that is to throw all the documents into one linear > > series, and have the reader look for distinguishing marks in the text of > > the document"? We shouldn't keep supporting a system we wouldn't build > > today. > > > > > > 2. This is not about us > > > > There are a total of a little over 30 unique senders on this list. The > > person closest to being a newcomer is Joe Hall, whose first IETF meeting > > was IETF 89, more than four years ago. This discussion isn't about us > > -- it's about the much larger group of people who read these documents > > and try to build products off of them that work. > > > > In an ideal world, some of those folks would be participating here. > > Until that happens, we should rely on what data we can gather. We've > > already head several anecdotes, and they're pretty much all on one side > > -- the current arrangement causes confusion and makes RFCs less useful. > > > > To try to be slightly more systematic, I sent a survey out over the > > weekend to a bunch of communities I participate in that are > > "IETF-adjacent". It got 115 responses, and the data [1] are consistent > > with the anecdata: > > > > - 52% of respondents thought that an RFC was "A document published by > > the IETF that defines a technical standard for the Internet" > > > > - While 93% of respondents agreed that the IETF can publish RFCs, the > > other streams came in much farther behind; the IAB was second-most > > recognized, at only 26% > > > > - Nobody has any idea that about the taxonomy of RFCs. A majority of > > people said they thought that there were 5 types, but I would conjecture > > that's just an artifact of the options I put in there. > > > > Based on those observations, I hope it's clear to folks that there is a > > problem to be solved here.. The survey data, sketchy as they are, also > > point toward the solution, which is to refine the RFC label to have a > > much more limited semantic, probably only IETF and possibly only > standards. > > > > Hope that helps, > > > > --Richard > > > > [1] > > > https://docs.google.com/forms/d/e/1FAIpQLSeMoeR0TBWkZNpBKXJN3Am6nUL04Vr4-12T2VgEbiRdBwzngQ/viewanalytics > > > > > > _______________________________________________ > > Rfcplusplus mailing list > > Rfcplusplus@ietf.org > > https://www.ietf.org/mailman/listinfo/rfcplusplus > > > --0000000000007109ea0570a5d89d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Jul 9, 2018 at 6:32 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
This formulation assumes that change does not ha= ve a cost.=C2=A0 It does.=C2=A0 I
agree that not changing has some cost.=C2=A0 However, absent indication tha= t
the changes will actually address the claimed problem...
<= br>
People are presenting indications.=C2=A0 Attach what caveats = you need to my little study; it's still real data from a relevant popul= ation.=C2=A0 Do you have better data?

=C2=A0
If we really want to change something that causes confusion in a way
that actually causes us process problems, maybe we should actually
tackle one?=C2=A0

Without commenting on wh= ether this I-D problem is a worthwhile problem to solve, it is not the one = this list is here to discuss.

--Richard
<= div>
=C2=A0
In particular= , in looking at kinds of confusion, one of the
ones that causes the IETF real and significant problems is when outside groups look at individual Internet Drafts, and treat them like working
group adopted products.=C2=A0 (I would like to fix folks treating adotped <= br> I-Ds as if they were finished RFCs, but given that those already have
clearly distinct labels, that does not seem possible.)
In one sense, fixing that would likely require changing quite a few
moving parts in our process.=C2=A0 It is clearly something the IETF owns.= =C2=A0 It
is something that causes myriad issues between us and other standards
bodies and between us an users.=C2=A0 We often have to actually put in work=
pushing back on folks mis-characterizing individual I-Ds as IETF work.

Yours,
Joel

PS: I do not see how we can draw any conclusion from the very informal
survey.=C2=A0 We have been lectured, with good reason, in the past about th= e
dangers of drawing conclusions from even carefully formulated and
carefully distributed surveys.

On 7/9/18 6:17 PM, Richard Barnes wrote:
> Hey all,
>
> I'm still catching up on the many emails on this list, so I might = be
> missing something, but I wanted to surface two arguments that seem to = me
> to be pretty dispositive that there is a problem here to solve:
>
>
> 1. A recommendation to hold is a recommendation to buy / sunk cost fal= lacy
>
> Suppose someone came to you with the following problem statement:
>
> - We have 16 (or so) types of document that we want to publish
> - We need readers of one of these documents to be clear on which type =
> they're reading
>
> Is there anyone here who would look at that problem statement and say,=
> "The ideal way to do that is to throw all the documents into one = linear
> series, and have the reader look for distinguishing marks in the text = of
> the document"?=C2=A0 We shouldn't keep supporting a system we= wouldn't build
> today.
>
>
> 2. This is not about us
>
> There are a total of a little over 30 unique senders on this list.=C2= =A0 The
> person closest to being a newcomer is Joe Hall, whose first IETF meeti= ng
> was IETF 89, more than four years ago.=C2=A0 This discussion isn't= about us
> -- it's about the much larger group of people who read these docum= ents
> and try to build products off of them that work.
>
> In an ideal world, some of those folks would be participating here.=C2= =A0
> Until that happens, we should rely on what data we can gather.=C2=A0 W= e've
> already head several anecdotes, and they're pretty much all on one= side
> -- the current arrangement causes confusion and makes RFCs less useful= .
>
> To try to be slightly more systematic, I sent a survey out over the > weekend to a bunch of communities I participate in that are
> "IETF-adjacent".=C2=A0 It got 115 responses, and the data [1= ] are consistent
> with the anecdata:
>
> - 52% of respondents thought that an RFC was "A document publishe= d by
> the IETF that defines a technical standard for the Internet"
>
> - While 93% of respondents agreed that the IETF can publish RFCs, the =
> other streams came in much farther behind; the IAB was second-most > recognized, at only 26%
>
> - Nobody has any idea that about the taxonomy of RFCs.=C2=A0 A majorit= y of
> people said they thought that there were 5 types, but I would conjectu= re
> that's just an artifact of the options I put in there.
>
> Based on those observations, I hope it's clear to folks that there= is a
> problem to be solved here..=C2=A0 The survey data, sketchy as they are= , also
> point toward the solution, which is to refine the RFC label to have a =
> much more limited semantic, probably only IETF and possibly only stand= ards.
>
> Hope that helps,
>
> --Richard
>
> [1]
> https://docs.google.com/forms/d/e/1FAIpQLSeMoeR0TBWkZNpBKXJN3Am6nU= L04Vr4-12T2VgEbiRdBwzngQ/viewanalytics
>
>
> _______________________________________________
> Rfcplusplus mailing list
> Rfcplusplus@= ietf.org
> https://www.ietf.org/mailman/listinfo/rfcplusp= lus
>
--0000000000007109ea0570a5d89d-- From nobody Tue Jul 10 07:34:22 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0167130FB1 for ; Tue, 10 Jul 2018 07:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkrFX3rB2QDo for ; Tue, 10 Jul 2018 07:34:17 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 46458130EBB for ; Tue, 10 Jul 2018 07:34:17 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id k81-v6so42999791oib.4 for ; Tue, 10 Jul 2018 07:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wL24YbJ8yN/PaztkLxTmiGgWKhI8TqF5nAGKwANQGk8=; b=tPPZMd3U84bjdGrTT/a70dqqaFClDYu8cstf/h82McOSoKw7SLlwdeisZvnjiEy/65 WFeYv+ecywCi/7K8Zs3n3jULMgu/ZYhoCs6VgERNCLKUI85kTTgkj8YmFPxthF0g4S2H LwuQ4rJZMQ7U5ABqsLUWEwbnyMB4g2yG9UINsQ/p13ZS7YSjZKJ6x4FKVS7v+p2kRW// PZ6th0pHtOFQbOMg0eY2VbdKqifTjxHH4Rno0xYzUaEf+Nj/Q1XU4frmRvlWFh1jKSG+ FfTR6MWfRxMhMr0qwd5AGUDy9yJAj505lXYVkyxWWUYSVF3RI4vVUWY4nQmmIN0TGato LieQ== 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=wL24YbJ8yN/PaztkLxTmiGgWKhI8TqF5nAGKwANQGk8=; b=JYY9XfLT6OvYUYJeHPFIp+PjZNVSMjM8VSwMRd9onhtcX/SbpE9wflPZRP9aDuw823 Z7FRSpXbTh+Ji6pPoz3kMoBd1Tzm02nWnJRhk/uLXLuIkPe7NXnPCv3ctPCUJ1ic0Mlb V+75SxfbJzjEKafO+z99KLz0NdrYOBvC7rXdW1sqf1iFq2zLUcFrI0yCir0xHo0SXtGz mmFN7hHNauoYBurbhO/X7kKnbHDLEuIC9FfWho7Dozd5t0NJ+iZFUh1zBRVP4MjLXlBB ezercD+b5AaTa9SQc+gINOrITnClVAQtpItz2+fe0lKPtDAcgFPXPdkno8DSZ1c253ga 53Hw== X-Gm-Message-State: APt69E3TsyhUFZJ48Hk7ty9kcQQzLpz3GO9g+Qhw0HitWtXGnPNEsV8y fUq8duE+r0ncjGNii+P+mb4XVmuvDnMj7xvGnWD0zg== X-Google-Smtp-Source: AAOMgpfQRe5FgDuyIOZ25uYszQT4Ceet8zCVMzVp61khe3y+Cb6Ji8ZASUWUHQ3wywTuKMUV7VLuSf9QtPgQV0H+KrA= X-Received: by 2002:aca:d088:: with SMTP id j8-v6mr29046301oiy.276.1531233256382; Tue, 10 Jul 2018 07:34:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 10 Jul 2018 10:34:05 -0400 Message-ID: To: Brian E Carpenter Cc: "Joel M. Halpern" , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000050e08c0570a606cd" Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 14:34:20 -0000 --00000000000050e08c0570a606cd Content-Type: text/plain; charset="UTF-8" On Mon, Jul 9, 2018 at 8:30 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 10/07/2018 10:32, Joel M. Halpern wrote: > ... > > PS: I do not see how we can draw any conclusion from the very informal > > survey. We have been lectured, with good reason, in the past about the > > dangers of drawing conclusions from even carefully formulated and > > carefully distributed surveys. > > It's worse than that. The survey was hastily designed and included > at least one ad hominem entry, and I think anyone with experience > of surveys and their analysis would simply junk the results. See > below for something more concrete on that. > I'll admit it was hastily conceived; the idea came to me as I was composing my message to the list on Friday. I won't admit it's ad-hominem -- it's simply fact that the process entitles Adrian can approve RFCs as he likes. But in the real world, when you're trying to make a decision, you either work with dirty data or you collect better data. I don't see anyone here doing any better survey work, so throwing out what data we have seems counterproductive. > On 7/9/18 6:17 PM, Richard Barnes wrote: > ... > > Based on those observations, I hope it's clear to folks that there is a > > problem to be solved here.. The survey data, sketchy as they are, also > > point toward the solution, which is to refine the RFC label to have a > > much more limited semantic, probably only IETF and possibly only > standards. > > That's a pretty perfect example of confirmation bias. > If you have another interpretation for the responses to questions 1 and 2, I would love to hear it. > I hope that as scientists and engineers, we can do better than this. > I have no doubt that we could do better, but so far, nobody's done the work. By the way, the full results are at > > https://docs.google.com/forms/d/e/1FAIpQLSeMoeR0TBWkZNpBKXJN3Am6nUL04Vr4-12T2VgEbiRdBwzngQ/viewanalytics > > The last question is interesting.: > "Does an RFC published by the IETF require IETF consensus?" > got 58.8% "no", which is the correct answer. However, this > seems very unlikely as the preferred response from outsiders. > Only insiders know that only some IETF stream RFCs require > IETF consensus. So I don't think the data can reasonably be > assumed to represent the opinion of outsiders. > I think this is more likely read as people just not understanding the question, and the role consensus plays in our process. If you think the respondents were insiders, how do you explain the abundantly "incorrect" responses to question 2? I actually asked people let me know when they filled out the survey, and got around 20 notifications, including some IETF newcomers, several senior developers for major projects, and a few newbie developers. Taking that together with the Q2 observation above, I doubt the sample was dominated by insiders. --Richard --00000000000050e08c0570a606cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 9, 2018 at 8:30 PM Brian E Carpenter <= brian.e.carpenter@gmail.com<= /a>> wrote:
On 10/07/2018 10:32, Joel M. Halpern wrote:
...
> PS: I do not see how we can draw any conclusion from the very informal=
> survey.=C2=A0 We have been lectured, with good reason, in the past abo= ut the
> dangers of drawing conclusions from even carefully formulated and
> carefully distributed surveys.

It's worse than that. The survey was hastily designed and included
at least one ad hominem entry, and I think anyone with experience
of surveys and their analysis would simply junk the results. See
below for something more concrete on that.

<= div>I'll admit it was hastily conceived; the idea came to me as I was c= omposing my message to the list on Friday.=C2=A0 I won't admit it's= ad-hominem -- it's simply fact that the process entitles Adrian can ap= prove RFCs as he likes.


I hope that as scientists and engineers, we can do better than this.

I have no doubt that we could do better, but = so far, nobody's done the work.
=C2=A0

By the way, the full results are at
https://docs.google.com/forms/d/e/1FAIpQLSeMoeR0TBWkZNpBKXJN3Am6nUL04Vr= 4-12T2VgEbiRdBwzngQ/viewanalytics

The last question is interesting.:
"Does an RFC published by the IETF require IETF consensus?"
got 58.8% "no", which is the correct answer. However, this
seems very unlikely as the preferred response from outsiders.
Only insiders know that only some IETF stream RFCs require
IETF consensus. So I don't think the data can reasonably be
assumed to represent the opinion of outsiders.

I think this is more likely read as people just not understanding t= he question, and the role consensus plays in our process. If you think the = respondents were insiders, how do you explain the abundantly "incorrec= t" responses to question 2?

I actually a= sked people let me know when they filled out the survey, and got around 20 = notifications, including some IETF newcomers, several senior developers for= major projects, and a few newbie developers.=C2=A0 Taking that together wi= th the Q2 observation above, I doubt the sample was dominated by insiders.<= br>

--Richard

--00000000000050e08c0570a606cd-- From nobody Tue Jul 10 07:45:33 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DACF130E0D for ; Tue, 10 Jul 2018 07:45:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yitter.info header.b=l58/Rqre; dkim=pass (1024-bit key) header.d=yitter.info header.b=dhLkXnsB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSGu1pNuVRii for ; Tue, 10 Jul 2018 07:45:29 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1DA130E79 for ; Tue, 10 Jul 2018 07:45:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id DB132BEBEB for ; Tue, 10 Jul 2018 14:45:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1531233928; bh=sq/S06zieWiXPCcccZPb75Ac+1LQKN8HrE2zVP0paQI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=l58/Rqre5aUwnJ0VYthQSR0QqKsejvgJm14Yb668jXvjDkZHSfQCy5gUCp3Y5BoeQ iQLm0UCS5Rf5PIkAvBfr0InlJw+YMvwSQPBg+F83Ajz1eh30YNJLJ6E9hXPPXUOh6U BDUBN8d/lTmAnFocSXu0KmSycvxzrm7n4CjA16w0= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rix_cBodHkx0 for ; Tue, 10 Jul 2018 14:45:27 +0000 (UTC) Date: Tue, 10 Jul 2018 10:45:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1531233927; bh=sq/S06zieWiXPCcccZPb75Ac+1LQKN8HrE2zVP0paQI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=dhLkXnsBimckoDMs9WgG+FKjYgxbr6NxixdgKJGFu3YNhKeRcRiUeg5eYRyiF7Mjg /BEBUvEQlyqYWmVtZ3aDPoR/bwchEMK6naJ1k+YDixfuKkFaOeyJ92wkAQfx180dKB ++3c5OtmoUW1qVjs1vCmfc1I2mrBI4dq5itYh8Zo= From: Andrew Sullivan To: rfcplusplus@ietf.org Message-ID: <20180710144525.GE20282@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 14:45:31 -0000 Hi, On Mon, Jul 09, 2018 at 06:32:28PM -0400, Joel M. Halpern wrote: > This formulation assumes that change does not have a cost. It does. I > agree that not changing has some cost. However, absent indication that the > changes will actually address the claimed problem, paying the various direct > and indirect costs of changing things is not inherently a good thing. I think this argument would be stronger if we understood what your estimation of the costs are. The analysis underpinning the proposal (in the BoF request), as near as I can tell, is that the costs are the using up of a few letters (for new series names) plus the cost of possibly reserving RFC numbers for the alternative series publications (in case they turn out not to work after 3 or more years), plus the costs to tooling changes. Are there other costs you can think of? Keep in mind, the proposal is for an experiment. Experiments do indeed result in some costs, and I think it is entirely reasonable to ask what those costs really would be. But I also think we ought to keep in mind the potential benefit of the experiment, which is to do an empirical evaluation of whether the long-debated confusion can be clarified (at least, in this way). Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jul 10 07:59:33 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3709E131072 for ; Tue, 10 Jul 2018 07:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO7kLo4qc0mM for ; Tue, 10 Jul 2018 07:59:21 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A3813105F for ; Tue, 10 Jul 2018 07:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3322; q=dns/txt; s=iport; t=1531234760; x=1532444360; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=kZY+kOsBN0Fj6307NRkfs1BGbfSNm+WPtplSrGl2xDs=; b=dRcWh2CpukoAn8uku69w+KynfIKwzb8UgDq6LOnky7ZUY3pFSial4Rcz 3L2DnzQKg5ZpjqeqWzSfeDPG+HLyKqOzmaBf5Ei5S5BBLaHJUmDtokfYW 3tu6QPWagD4MmsW+SWn1ctquI/KoWg4hbDPAzPLrzOT3dtevZO/9uVCaY 0=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzAQByyERb/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYUZEoQiiGONNgiQR4cICAOEbAKCSzgUAQIBAQIBAQJtKIUtCgY?= =?us-ascii?q?jVhALAwEKNAICVwYBDAgBAYMcAYF/qnWBLh+ILoEtD4sPgTcMgl6HfIJVApl?= =?us-ascii?q?SCYNdgViJawaIGIVIkhKBWCGBUjMaCBsVgyWQVD2OGwEB?= X-IronPort-AV: E=Sophos;i="5.51,335,1526342400"; d="asc'?scan'208,217";a="5085794" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2018 14:59:19 +0000 Received: from [10.61.195.132] ([10.61.195.132]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w6AExITw020145; Tue, 10 Jul 2018 14:59:18 GMT To: Richard Barnes , Brian E Carpenter Cc: "Joel M. Halpern" , rfcplusplus@ietf.org References: From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <888d8f56-1ae8-4812-c8b2-a0d99ce6edfa@cisco.com> Date: Tue, 10 Jul 2018 16:59:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R2fFSm9qOYwXWsz1Zt1xMQ6vXoXn3RYOP" Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 14:59:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R2fFSm9qOYwXWsz1Zt1xMQ6vXoXn3RYOP Content-Type: multipart/mixed; boundary="x40ImIVucmXylBgMW258Ck0hjgdLDA6dK"; protected-headers="v1" From: Eliot Lear To: Richard Barnes , Brian E Carpenter Cc: "Joel M. Halpern" , rfcplusplus@ietf.org Message-ID: <888d8f56-1ae8-4812-c8b2-a0d99ce6edfa@cisco.com> Subject: Re: [Rfcplusplus] Sunk cost + not about us References: In-Reply-To: --x40ImIVucmXylBgMW258Ck0hjgdLDA6dK Content-Type: multipart/alternative; boundary="------------BABEBDF8E061BC94933836D1" Content-Language: en-US This is a multi-part message in MIME format. --------------BABEBDF8E061BC94933836D1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10.07.18 16:34, Richard Barnes wrote: I have no doubt that we could do better, but so far, nobody's done the work. That seems like a far better place to start in all of this.=C2=A0 In fact= , it would be quite good if this group could even agree on what goo looks like.=C2=A0 That will also help clarify what measurements are important. Eliot --------------BABEBDF8E061BC94933836D1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 10.07.18 16:34, Richard Barnes wrote:

I have no doubt that we could do better, but so far, nobody's done the work.

That seems like a far better place to start in all of this.=C2=A0 In fact, it would be quite good if this group could even agree on what goo looks like.=C2=A0 That will also help clarify what measurements a= re important.

Eliot
--------------BABEBDF8E061BC94933836D1-- --x40ImIVucmXylBgMW258Ck0hjgdLDA6dK-- --R2fFSm9qOYwXWsz1Zt1xMQ6vXoXn3RYOP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltEycQACgkQh7ZrRtnS ejMutQf+LnI3mf73mBc/iisXvrQ2q/vyS81WeBEtlrlUvKJSttbSqKcc4K/I55Y3 1suhHoeWRl494ZrFNN4QHD3PnH5X0E5Znf0XowCvDeLhUktkAOhWSTVyuG9T5Cof 75v+dTfEfGX5t+1/ZNUXe4oyQi3YkDmnyEKSwX3KwlYkkPonoV+o+Q6Mpl8S+fT1 tyq42llDvHjswf2v6YT32Aj9tNBWDlhCtHSrfGRdZW/i7Mjpj5GeRBK8v5/UJ/i/ e/iGi7DQJc6UYJ9gJi88H2cj8t1CWcjt/m8siTpUGpvx4IUhnyO9bjXwRZiaUoYB Vyub8Q0F2i/ARXzNWpuucchvxmgM1A== =JBWZ -----END PGP SIGNATURE----- --R2fFSm9qOYwXWsz1Zt1xMQ6vXoXn3RYOP-- From nobody Tue Jul 10 08:01:23 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B13E130FD6 for ; Tue, 10 Jul 2018 08:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M34tS6qEBIMA for ; Tue, 10 Jul 2018 08:01:19 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D642130FCF for ; Tue, 10 Jul 2018 08:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3985; q=dns/txt; s=iport; t=1531234879; x=1532444479; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ThzKmG+lB/IF6ljV5IBM3SBRhuSfI1z2AWxvlT7lz9c=; b=hfVVs3ry0fKQxwJ/evMrSlDxjKr+eiLAEMmuVoHD7C/jXjRsYo5KUBCp FvDW4tjZbo7Ct/cTfwm5dwb+smyFmYeIS6tkbfab3AZbS5PEujc/QRu5k xcfN89uLdo02EUMw40R+WM7gsEbvqqaOC5yiMOYkgWwmC6+/Pn36TcG84 8=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQCYyURb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUZEoQiiGONNiuQJIcICAOEbAKCSzgUAQIBAQIBAQJtKIU?= =?us-ascii?q?3AQUjVhALBAETKgICVwYBDAgBAYMcAYF/qnyBLh+ILoEtD4sPgTeCaod8glU?= =?us-ascii?q?CmVIJg12BWIlrBoFDhA+CRoVIkhKBWCGBUjMaCBsVgyWQVD2OGwEB?= X-IronPort-AV: E=Sophos;i="5.51,335,1526342400"; d="asc'?scan'208,217";a="5085852" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2018 15:01:17 +0000 Received: from [10.61.195.132] ([10.61.195.132]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w6AF1GFf006002; Tue, 10 Jul 2018 15:01:16 GMT To: Eliot Lear , Richard Barnes , Brian E Carpenter Cc: "Joel M. Halpern" , rfcplusplus@ietf.org References: <888d8f56-1ae8-4812-c8b2-a0d99ce6edfa@cisco.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <814a552b-3f2a-798e-420b-9ffa237826ea@cisco.com> Date: Tue, 10 Jul 2018 17:01:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <888d8f56-1ae8-4812-c8b2-a0d99ce6edfa@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RgWvxVhLjNWb0CIs29pvazCyD5DBnGnGl" Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 15:01:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RgWvxVhLjNWb0CIs29pvazCyD5DBnGnGl Content-Type: multipart/mixed; boundary="MUiedCL1y6lstRLPI6z6NrPW5rByefhSD"; protected-headers="v1" From: Eliot Lear To: Eliot Lear , Richard Barnes , Brian E Carpenter Cc: "Joel M. Halpern" , rfcplusplus@ietf.org Message-ID: <814a552b-3f2a-798e-420b-9ffa237826ea@cisco.com> Subject: Re: [Rfcplusplus] Sunk cost + not about us References: <888d8f56-1ae8-4812-c8b2-a0d99ce6edfa@cisco.com> In-Reply-To: <888d8f56-1ae8-4812-c8b2-a0d99ce6edfa@cisco.com> --MUiedCL1y6lstRLPI6z6NrPW5rByefhSD Content-Type: multipart/alternative; boundary="------------F05F71974F4D70E32EBC9CAA" Content-Language: en-US This is a multi-part message in MIME format. --------------F05F71974F4D70E32EBC9CAA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Erm... On 10.07.18 16:59, Eliot Lear wrote: > > On 10.07.18 16:34, Richard Barnes wrote: > > I have no doubt that we could do better, but so far, nobody's done > the work. > > > That seems like a far better place to start in all of this.=C2=A0 In fa= ct, > it would be quite good if this group could even agree on what goo > looks like.=C2=A0 That will also help clarify what measurements are imp= ortant. s/goo/good/ Please send no textual descriptions of goo. Eliot --------------F05F71974F4D70E32EBC9CAA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Erm...


On 10.07.18 16:59, Eliot Lear wrote:

On 10.07.18 16:34, Richard Barnes wrote:

I have no doubt that we could do better, but so far, nobody's done the work.

That seems like a far better place to start in all of this.=C2=A0 I= n fact, it would be quite good if this group could even agree on what goo looks like.=C2=A0 That will also help clarify what measurements are important.

s/goo/good/

Please send no textual descriptions of goo.

Eliot
--------------F05F71974F4D70E32EBC9CAA-- --MUiedCL1y6lstRLPI6z6NrPW5rByefhSD-- --RgWvxVhLjNWb0CIs29pvazCyD5DBnGnGl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltEyjoACgkQh7ZrRtnS ejOlogf/eFmMOry6DOWuNiQFabmnaFoP2UNa+Hm7MN/qNebWbAti8/vXxiYMmxYd SkyDlyNDciRo9O3CesbJB9mrumWUtoTlkf8KVqFEHs5hff2JkeDEnzuIQTHVWf55 AagqXFSOu6pU+8itZVhpRKn08n2x4cPDuEO7J14MdGGM2oUjWTbxuQ4Igcu+Hlbb SXWs2rKKpjoM2mb2wMSzxLYbjHjYdk8lf4ib7B2z1qbLlOUO/CB0nefUOvHfW4SJ 1W035f1TQurE+EaA2qtjSeV5zA6Ad2eO1lCJ9eBTbcH7R4JrxxpmuOgc8EQ1HVrH Yr6RzlH47y56au9BoSFswNh0Ju/YDg== =/go6 -----END PGP SIGNATURE----- --RgWvxVhLjNWb0CIs29pvazCyD5DBnGnGl-- From nobody Tue Jul 10 08:20:48 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF735130FE2 for ; Tue, 10 Jul 2018 08:20:45 -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] 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 h13l0hoHv5zn for ; Tue, 10 Jul 2018 08:20:44 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 8E907130FDB for ; Tue, 10 Jul 2018 08:20:44 -0700 (PDT) Received: from [10.47.60.44] ([65.119.211.164]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w6AFKW4T048603 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 10 Jul 2018 08:20:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host [65.119.211.164] claimed to be [10.47.60.44] From: "Paul Hoffman" To: rfcplusplus@ietf.org Date: Tue, 10 Jul 2018 11:20:40 -0400 X-Mailer: MailMate (1.11.2r5507) Message-ID: <2CDA19FD-816B-4B4E-9F64-0DA494EB8B1A@vpnc.org> In-Reply-To: <20180710144525.GE20282@mx4.yitter.info> References: <20180710144525.GE20282@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 15:20:46 -0000 On 10 Jul 2018, at 10:45, Andrew Sullivan wrote: > Hi, > > On Mon, Jul 09, 2018 at 06:32:28PM -0400, Joel M. Halpern wrote: >> This formulation assumes that change does not have a cost. It does. >> I >> agree that not changing has some cost. However, absent indication >> that the >> changes will actually address the claimed problem, paying the various >> direct >> and indirect costs of changing things is not inherently a good thing. > > I think this argument would be stronger if we understood what your > estimation of the costs are. The analysis underpinning the proposal > (in the BoF request), as near as I can tell, is that the costs are the > using up of a few letters (for new series names) plus the cost of > possibly reserving RFC numbers for the alternative series publications > (in case they turn out not to work after 3 or more years), plus the > costs to tooling changes. Are there other costs you can think of? 1) Human costs for all authors for pointing to the new series while the experiment is running. 2) Human costs of arguing about how to measure the successfulness of the experiment. 3) If the experiment ends in failure (likely because we can't evaluate if there is less confusion with the new series than in the current setup), we will either have a bunch of small vestigial series with a bunch of RFCs pointing to them, or we have to update all of the RFCs that have pointers to the new series to instead point to the RFC numbers. > Keep in mind, the proposal is for an experiment. Experiments do > indeed result in some costs, and I think it is entirely reasonable to > ask what those costs really would be. But I also think we ought to > keep in mind the potential benefit of the experiment, which is to do > an empirical evaluation of whether the long-debated confusion can be > clarified (at least, in this way). We have not seen any suggestion of how such an empirical evaluation would take place. We have not seen any suggestion for, even if we could measure the problem today and a reduction of the measured problem, how much reduction would be labeled "success". --Paul Hoffman From nobody Tue Jul 10 09:04:52 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD62130E40 for ; Tue, 10 Jul 2018 09:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 leY-cmgt0Ic2 for ; Tue, 10 Jul 2018 09:04:48 -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 01A98130E3F for ; Tue, 10 Jul 2018 09:04:47 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id w6AG4jYv004054; Tue, 10 Jul 2018 17:04:45 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2C67422048; Tue, 10 Jul 2018 17:04:45 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 208302204A; Tue, 10 Jul 2018 17:04:45 +0100 (BST) Received: from 950129200 (6.152.51.84.dyn.plus.net [84.51.152.6] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id w6AG4h5P001538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2018 17:04:44 +0100 Reply-To: From: "Adrian Farrel" To: "'Richard Barnes'" , "'Brian E Carpenter'" Cc: References: In-Reply-To: Date: Tue, 10 Jul 2018 17:04:43 +0100 Message-ID: <069201d41867$b81fb1d0$285f1570$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHMlETSWAjUxgNWEkUie3WtlPHQtAIxDpphAZ9WTpgAv1T8B6RzI8aQ Content-Language: en-gb X-Originating-IP: 84.51.152.6 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23960.001 X-TM-AS-Result: No--3.745-10.0-31-10 X-imss-scan-details: No--3.745-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23960.001 X-TMASE-Result: 10--3.744600-10.000000 X-TMASE-MatchedRID: eVEkOcJu0F7MMRSV8EvXavHkpkyUphL9EQHduga0jMIcXmBZ3mI5SXke 9Qrwf4UGXntxLHyCxnlM8raLOkUhykt2tbQ9R41kTSPNp9e/u1OAfODDLypXmjEJregV5mtFF8Z Y2sNLB+niQTf9cYDd1AUS+L0rwKvvzq1TWjOPjtfsPMG550sPGyyZvBThPVi1rMVAtgU+HLJ4NB lm/4a7fWOzv34+Stdcg/pmYrFUdCOr9RIY1Sn+V6tWSWds/km2ndxf4OzpbpW6CoQ+nkvtfqo+Y Kr0HLtg+V7HYfFYcJwM/b/O2UosGrmvMSppeWbNYD9XTRdaMO0fXzVgO0hVqjTp2FynA0cQTV4G mIHLWScUyOs6VWLeU1FTcMw3aN0I5UcZtwNsCrqDGx/OQ1GV8t0H8LFZNFG76sBnwpOylLPzCM6 KgE8Yb2dzSaTDFOG4AjgCNJL0FO5HUKpFaQdbp05PQ4s9x2NCklhJipwvFAgkyzwnb9j/nKY/d/ RCNjhtvdqx1R6dUPQJAp5AN4f59Q+9NXX1QIs7ki/Tr7VHGv3uvg+PNpx4a37cGd19dSFd X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 16:04:51 -0000 All, >> It's worse than that. The survey was hastily designed and included >> at least one ad hominem entry, and I think anyone with experience >> of surveys and their analysis would simply junk the results. See >> below for something more concrete on that. > > I'll admit it was hastily conceived; the idea came to me as I was > composing my message to the list on Friday. I won't admit it's=20 > ad-hominem -- it's simply fact that the process entitles Adrian=20 > can approve RFCs as he likes. I can accept that it was not intentionally an attack on me or an attempt = to divert the argument from the real issues by focusing on me, and I = have spoken with Richard about it privately. Nevertheless, if it was not = carefully formulated and it definitely used my name rather than my role = as Independent Submissions Editor. I suspect that, despite it being in = the public domain that I am the ISE, it is not public knowledge. Thus, = if the responders truly knew little of the IETF (as requested in the = preamble) they should have had no idea who I am or why my name was = listed. Had the question used "Independent Submissions Editor" instead, = the answers might have been different. But who cares? Twitter is a wild park where idiots play. I am not = offended by anything that is said there, nor do I take seriously any = "results" of surveys or opinion storms that happen there. I may draw my = own conclusions about those who pay too much attention to Twitter, but = that is between me and my analyst. > But in the real world, when you're trying to make a decision, you = either > work with dirty data or you collect better data. I don't see anyone = here > doing any better survey work, so throwing out what data we have seems > counterproductive. Ah, "the real world". What are you trying to say, Richard? Is Twitter = the real world? Does Brian not live in the real world?=20 May I suggest that it does not help advance the discussion in any way to = proceed like this? I shall not be going to the pub tonight to ask three = drunks, the barmaid, and the landlord's dog. That would give us some = more data, but it, too, would have no value. Adrian (Finding it hard to keep separate my personal opinions and my = role as ISE when others confuse them, but still attempting to respond = from this address as an individual participant in the IETF.) From nobody Tue Jul 10 10:01:44 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0D913114C for ; Tue, 10 Jul 2018 10:01:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Tplytp2h4rZo for ; Tue, 10 Jul 2018 10:01:40 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739B9131142 for ; Tue, 10 Jul 2018 10:01:40 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fcw1C-0005Xp-SJ; Tue, 10 Jul 2018 13:01:38 -0400 Date: Tue, 10 Jul 2018 13:01:32 -0400 From: John C Klensin To: Richard Barnes cc: rfcplusplus@ietf.org Message-ID: <40A502D5A3E46151ADC19AF6@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:01:42 -0000 --On Tuesday, July 10, 2018 10:34 -0400 Richard Barnes wrote: >... > But in the real world, when you're trying to make a decision, > you either work with dirty data or you collect better data. I > don't see anyone here doing any better survey work, so > throwing out what data we have seems counterproductive. >... Richard, As someone who used to teach survey design, survey data analysis, and threats to validity of such analyses, I beg to disagree. To summarize a much longer tutorial... If one has data that are known to reflect sample biases relative to the population of interest (and some of this discussion leads me to believe we don't even have consensus about what that population is) or whose collection of questions cannot be clearly and unambiguously interpreted, show biases toward certain types of answers or are otherwise prone to confirmation bias, etc., then the results are likely to be of little or no value at all. That is very different from "dirty data". "Dirty data", while not a precise technical term, usually refers to data whose biases (statistical or substantive) we understand well enough to at least partially de-bias or adjust for its inadequacies. Bad data in which the biases are impossible to evaluate other than knowing that they are present and potentially serious (and as distinct from "dirty data" as above) may not only be worse than "no data" but may be quite a bit worse than someone standing up and saying "this is true because I said so". At least in the latter case, one has some reasonably chance of guessing at the expertise, prejudices, preconceptions, and general reliability of the source and calibrating the assertion accordingly. best, john From nobody Tue Jul 10 10:08:24 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E2F13114C for ; Tue, 10 Jul 2018 10:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 PzrLDFCw7cxF for ; Tue, 10 Jul 2018 10:08:20 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 DE99A129385 for ; Tue, 10 Jul 2018 10:08:19 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id b15-v6so43977456oib.10 for ; Tue, 10 Jul 2018 10:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5pSkjpaVpNw1ckeP1+W/oK0uZnb0sPfc12Wcu5BW/so=; b=k2f9USz4cuIjMz9OnlgWw+n+bbZZi77pHxfwceuJ9b8yNf1g+czIvymrt0la4XAqrk +0sKur/NuLLMhmCBYnd1eEQ6fb3c5sccuXHeqfCchgDW/e2fRga2VBllsy2IIdW4+yST 2iTLtX9Ol2cDdwpHzcLFAeMDQrDdJWNkwZZ2SXsy5QhQsfplTGzrKYtozkY4fKDV066Y lA85OcUDfAMRGB3z8vY5FUqlExEegol5LqbrNSMROHuoyYYrH0G23DWBU3tN+4/B5OZ9 ZqxfHkZZd1/9Yjl4PZkr78PiFB3k7tderUfZ5HEm7g27yB8ENtCxX+inkjuiY21CEXto Ub0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5pSkjpaVpNw1ckeP1+W/oK0uZnb0sPfc12Wcu5BW/so=; b=sUg1ofFupctGccfdcq4aqwfJw1gs6SUBfEGdLLmA6g7qxjsGj3gKd2Y+3l36ACtiLx djO7Pwomp1uGrQN5hjDSFp6DBchVYGmPa6R1KAJpI2rwJbGuOsDDZXl7anvaY7V2pLaX wFf/sm+axR2+sQehj8PJU+KYHTOVTBqIcFctghZJjx9Y79i6y6JyRlIDiu3j3xe2ATzw l9CLCLFIQ0eoTvQUzFMdI13u9bDtNsigcX5qNicHhg4e8y0AC1e5XKaiuHg/2VmCPbVl CfBK+ZoT/VYMdSEP39XEMyVoK+lzcvk7HJTeLsnb3MXGeOGe8lyUaKkcIXge8kQ6BxTA nnCg== X-Gm-Message-State: APt69E0CSwAGL0Lrm/ZAG6rZUlMSvNd25H3WmQ6gEYt4RfH/1dVTyfTA zeLRhba55EM5e3jaREGVAElgay1F+TiXTwwUXPY= X-Google-Smtp-Source: AAOMgpdKLe2/URS+4YX2ADkSIyooe5wFX27mleLiqsz/M40tczTcU+dkztUq0OZ6B+ZMgS+BYAmEOBY2b/LM97q/03Q= X-Received: by 2002:aca:dec6:: with SMTP id v189-v6mr29985223oig.98.1531242499087; Tue, 10 Jul 2018 10:08:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c2:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 10:07:58 -0700 (PDT) In-Reply-To: <2CDA19FD-816B-4B4E-9F64-0DA494EB8B1A@vpnc.org> References: <20180710144525.GE20282@mx4.yitter.info> <2CDA19FD-816B-4B4E-9F64-0DA494EB8B1A@vpnc.org> From: "Andrew G. Malis" Date: Tue, 10 Jul 2018 13:07:58 -0400 Message-ID: To: Paul Hoffman Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000003922e20570a82d60" Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:08:22 -0000 --0000000000003922e20570a82d60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Paul=E2=80=99s statement: > We have not seen any suggestion of how such an empirical evaluation would > take place. We have not seen any suggestion for, even if we could measure > the problem today and a reduction of the measured problem, how much > reduction would be labeled "success". Really says it all - other than anecdotes and opinions, there has been no hard evidence of a =E2=80=9Cproblem=E2=80=9D that a reasonable third party = could look at and evaluate, nor have there been any proposals as how to reasonably determine the results of the experiment in three years, were it to be held. I think the most of productive use of our time during the BoF session will be to discuss how to gather real evidence of a problem, and how to evaluate the effects of any resulting IETF actions. Only after we have agreement on the methodology, and carry it out, will it be time to discuss what we should or should not do based on the results. Cheers, Andy --0000000000003922e20570a82d60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Paul=E2=80=99s statement:<= /div>
=C2=A0
We have not seen any suggestion of how such an empirical e= valuation would take place. We have not seen any suggestion for, even if we= could measure the problem today and a reduction of the measured problem, h= ow much reduction would be labeled "success".
=

Really says it all - other than anecdotes and opinions,= there has been no hard evidence of a =E2=80=9Cproblem=E2=80=9D that a reas= onable third party could look at and evaluate, nor have there been any prop= osals as how to reasonably determine the results of the experiment in three= years, were it to be held.

I think the most of pr= oductive use of our time during the BoF session will be to discuss how to g= ather real evidence of a problem, and how to evaluate the effects of any re= sulting IETF actions. Only after we have agreement on the methodology, and = carry it out, will it be time to discuss what we should or should not do ba= sed on the results.

Cheers,
Andy

--0000000000003922e20570a82d60-- From nobody Tue Jul 10 10:14:27 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B946213117F for ; Tue, 10 Jul 2018 10:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 T98gZYkbMH7R for ; Tue, 10 Jul 2018 10:14:21 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 A4E30131169 for ; Tue, 10 Jul 2018 10:14:21 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id 13-v6so44079305ois.1 for ; Tue, 10 Jul 2018 10:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+LolzaTP97ogM/UW+g5vyXnE31BWnI1rq33x8lUKUNo=; b=diG3kftxC7GMJV0B6gTq93e+2Qdiu5tdXZTxoIYuFUw7ZOYR7sul3hmuXsze+vTKAL zZtaf1IR9NQxJuYJhwiYhfEqXMAdf5IEBacsRHZ9YOIlHHKKFGpcse3MGnin4gvzO0uW vIB9cw6ddbM/lO7KGriKpFbIInqstqLkuMQygK6STW354dMOj0pcRD8CAx4s5uAjSHae sfI9GnCwmZ/HsUmTjSh/PZoCAV66FXlyhKFb5czSY3S8BBDYsw5eEl7rsrdknw1Zo5AB IhyBDBoE0JbHePkhE4aQCyU8AKkKcEVuuoQb+hFuYais6mi4CsCfAl1qtgz8f3ygUYTO YjRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+LolzaTP97ogM/UW+g5vyXnE31BWnI1rq33x8lUKUNo=; b=mxObm2KrcXKoHIQuRgrNz/GubDJyh+uGKgS8nqCuTQQfC0WSLn2ccZmh3KIbigrRrs 8jGTQ9MRrA78CviBpL13vUwOpf+6Oh9H3lUkovcJlUfFxTH3xB3ZELIjqS0G7yomtttF Vp2eBxhy+cIcq6NKQElGyjmc1UoqgBYq1apJnFAVtaNUcI8lb81GqGLcybtH/37Menm9 k+NPTOEk2Zps7AcVHeKwooZTsyKBFfXW2BdjB5irc9kisNvP2C+K3wfSrHcUJfEkcySw Gk913YwoX4Lue4OLIl9JNadHLi+5mytFry9BVcO66XKMBnJliUNB0ATxYm6SSfSkbex3 /Sjg== X-Gm-Message-State: APt69E1ISN6nFnWEPXMeWzeJ5dszWj3bHP1O8Q5noeblw5W+Tphv3cqB XCegF5iOpuAHZs3eFsPyuVTReY44cZ7AY6E9qhY= X-Google-Smtp-Source: AAOMgpc7WbgKiEivz9AsaIm9mx8TNBegl7+weVsXddy5zOsFwjFzni3V9hcCS9bL915+2nctdoFjP5FDcStcVPCbEkI= X-Received: by 2002:aca:190d:: with SMTP id l13-v6mr30365613oii.216.1531242860753; Tue, 10 Jul 2018 10:14:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 10:13:50 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Tue, 10 Jul 2018 10:13:50 -0700 Message-ID: To: Eliot Lear Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000c7b68c0570a842b7" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:14:25 -0000 --000000000000c7b68c0570a842b7 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 9, 2018 at 2:14 PM, Eliot Lear wrote: > As to voices, one of the perhaps lost aspects of RFCs is that Jon always > encouraged dissenting views on important topics to be published, so long as > they were well reasoned and reasonably well written. Personally I'd like > to see more dissenting views coming out of independent submissions. I know > I have quite a few to share ;-) I offer that only in as much as having a > few dissenting views might make clear that we really do speak with multiple > voices. > I personally don't think the dissenting opinions are fewer now, but fewer of them are expressed in RFCs. The critiques and dissents come, as Eric mentioned, in other series or other forms. Anyway, I won't be in Montreal, so here's my own bottom line: if the IAB > are serious about actually using different labels, ask yourselves what the > plan is to make those new series successful. How will the new series be > promoted? What will you attract readership? And what will the rules of > the road be for the series? If you do not have a plan, then let's not be > under any illusions that the new series will be successful. > > I think you're quite right that making a successful change of this type will take work, and that promoting the output of the different streams will be part of that work. What's been interesting for me is that the thought of how different the audiences are for that promotion. Reaching the folks who need to understand what the IRTF's output is and means is a very different enterprise than reaching those who might need to understand what the Internet Architecture Board has to say. Given the acronym overload there, a portion of that has to be making sure which IAB is talking, an impact that the IAB or ISE would not feel. But I think that actually illustrates the problem folks have brought forward here: if we were promoting these voices, we would do so at least partly to very different audiences. That's may be an important signal. Ted > Eliot > > On 09.07.18 17:24, Ted Hardie wrote: > > In a different thread, Eric made a statement about the RFC Series being in > conversation with other publications: > > The RFC series (and also I-Ds) have an important role to play here, but it >> also exists in conversation with a lot of other publication venues, and I >> think that's healthy. >> > > While I agree with him, I think the metaphor of "conversation" is even > more useful in describing both the current series and the question before > us. From my personal perspective, the primary reason we use "RFC" as a > series identifier is to identify a specific set of technical documents as > part of a common "conversation". The adoption of the term and series by > the IETF was a signal about the conversation their documents were to be > part of; choosing a different document series (like ANSI, ISO, or minting > a new one) would have sent a signal about a different technical community > with whom the IETF was in dialog. > > When the idea of different streams and stream managers gelled, we kept the > same series identifier for all of them. I think, personally, we did that > because we wanted to be clear that all of the documents continued to be > part of a larger conversation about the development of Internet > technologies. > > One way to understand the problem motivating this BoF is also through the > metaphor of conversation: many outside the community simply don't recognize > that there are multiple voices inside that conversation. They see all of > the documents as utterances by a single, somewhat nebulous group. That can > cause problems. Among those named earlier were the academic community's > failure to value the output of the IRTF; vendors or customers not > distinguishing consensus output from proprietary alternatives; and even a > few efforts to get rejected ideas to appear to have been accepted ones. > > The question before us could be cast as: is it more important now to > highlight the different voices that the streams and statuses currently > convey, so that others understand them as disctinct? > > As Eric points out, there are other ways to maintain a conversation among > different groups than to make their output part of a single series. There > are also other ways we could try to make sure that we highlight that > distinction more fully (using STD numbers for all IETF standards documents, > for example, from proposed standard onward). But I think this is the core > of the tension, shorn of discussion of brand or history: how to we get to > the right balance of maintaining the conversation while improving the > understanding that these are individual voices within it? > > My thoughts as individual, > > regards, > > Ted > > > _______________________________________________ > Rfcplusplus mailing listRfcplusplus@ietf.orghttps://www.ietf.org/mailman/listinfo/rfcplusplus > > > --000000000000c7b68c0570a842b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 9, 2018 at 2:14 PM, Eliot Lear <lear@cisco.com> wrote:
=20 =20 =20

As to voices, one of the perhaps lost aspects of RFCs is that Jon always encouraged dissenting views on important topics to be published, so long as they were well reasoned and reasonably well written.=C2=A0 Personally I'd like to see more dissenting views c= oming out of independent submissions.=C2=A0 I know I have quite a few to share ;-)=C2=A0 I offer that only in as much as having a few dissenti= ng views might make clear that we really do speak with multiple voices.

I personally don't think t= he dissenting opinions are fewer now, but fewer of them are expressed in RF= Cs.=C2=A0 The critiques and dissents come, as Eric mentioned, in other seri= es or other forms.

<= div text=3D"#000000" bgcolor=3D"#FFFFFF">

Anyway, I won't be in Montreal, so here's my own bottom line= :=C2=A0 if the IAB are serious about actually using different labels, ask yourselves what the plan is to make those new series successful.=C2= =A0 How will the new series be promoted?=C2=A0 What will you attract readership?=C2=A0 And what will the rules of the road be for the series?=C2=A0 If you do not have a plan, then let's not be under = any illusions that the new series will be successful.

I think you're quite right that maki= ng a successful change of this type will take work, and that promoting the = output of the different streams will be part of that work.=C2=A0 What's= been interesting for me is that the thought of how different the audiences= are for that promotion.=C2=A0 Reaching the folks who need to understand wh= at the IRTF's output is and means is a very different enterprise than r= eaching those who might need to understand what the Internet Architecture B= oard has to say.=C2=A0 Given the acronym overload there, a portion of that = has to be making sure which IAB is talking, an impact that the IAB or ISE w= ould not feel.=C2=A0=C2=A0=C2=A0 But I think that actually illustrates the = problem folks have brought forward here:=C2=A0 if we were promoting these v= oices, we would do so at least partly to very different audiences.=C2=A0 Th= at's may be an important signal.

=

=C2=A0

Eliot


On 09.07.18 17:24,= Ted Hardie wrote:
=20
In a different thread, Eric made a statement about the RFC Series being in conversation with other publications:

The RFC series = (and also I-Ds) have an important role to play here, but it also exists in conversation with a lot of other publication venues, and I think that's healthy.

While I agree with him, I think the metaphor of "conversation" is even more useful in describing both t= he current series and the question before us.=C2=A0 From my personal perspective, the primary reason we use "RFC" as a serie= s identifier is to identify a specific set of technical documents as part of a common "conversation".=C2=A0 The= adoption of the term and series by the IETF was a signal about the conversation their documents were to be part of; choosing a different document=C2=A0 series (like ANSI, ISO, or minting a new one) would have sent a signal about a different technical community with whom the IETF was in dialog.=C2=A0

When the idea of different streams and stream managers gelled, we kept the same series identifier for all of them.=C2=A0= I think, personally, we did that because we wanted to be clear that all of the documents continued to be part of a larger conversation about the development of Internet technologies.

One way to understand the problem motivating this BoF is also through the metaphor of conversation: many outside the community simply don't recognize that there are multiple voices inside that conversation.=C2=A0 They see all of the documents as utterances by a single, somewhat nebulous group.=C2= =A0 That can cause problems.=C2=A0 Among those named earlier were the academic community's failure to value the output of the IRTF; vendors or customers not distinguishing consensus output from proprietary alternatives; and even a few efforts to get rejected ideas to appear to have been accepted ones.

The question before us could be cast as:=C2=A0 is it more important now to highlight the different voices that the streams and statuses currently convey, so that others understand them as disctinct?=C2=A0

As Eric points out, there are other ways to maintain a conversation among different groups than to make their output part of a single series.=C2=A0 There are also other ways we could try to make sure that we highlight that distinction more fully (using STD numbers for all IETF standards documents, for example, from proposed standard onward).=C2=A0 But I think this i= s the core of the tension, shorn of discussion of brand or history:=C2=A0 how to we get to the right balance of maintaining the conversation while improving the understanding that these are individual voices within it?

My thoughts as individual,

regards,

Ted


_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf=
.org/mailman/listinfo/rfcplusplus


--000000000000c7b68c0570a842b7-- From nobody Tue Jul 10 10:59:29 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5094130E25 for ; Tue, 10 Jul 2018 10:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-tlqfDfBBuM for ; Tue, 10 Jul 2018 10:59:25 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 88335130DCE for ; Tue, 10 Jul 2018 10:59:25 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6AHwNcG015640; Tue, 10 Jul 2018 10:59:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=PPS1017; bh=89y+neWb6HSp1pxxyQawPTlfVGdaEwmTw2BpoU6UJTw=; b=Jrn4iQtRo010vy+luLYYML0J6XfnWCwwVZe+ZUBYCfnfCsmDE/voCgJz9IVOdo7JbAwC VMPfsnlihStBrqL0xUUp1TsNPwIUXtnywWzjtKMldALCtczB6av2Jjy3CdgbeTYV7qf3 HUn0kjQOOkcxRQ7jBnLFiMrPxS5wozOyMeGv0PtD0MRDQ0ClE/dLMNe/q4+an4Si/znz R91Y1yBzGTnstQxQ/WognoxP+Ull/X54mOZ61pp6PlbdZ66SY3XkoSJNDDZ34M5OZsSh SkSs3agcWKhCKgD7GktTJtlPVd60bMwTcr4+CFDuturM4aB82bPprvFy7H97718N3YGr /Q== Received: from nam05-co1-obe.outbound.protection.outlook.com (mail-co1nam05lp0081.outbound.protection.outlook.com [216.32.181.81]) by mx0b-00273201.pphosted.com with ESMTP id 2k4wwn8jfj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 10 Jul 2018 10:59:24 -0700 Received: from [172.29.35.4] (66.129.241.10) by SN4PR0501MB3870.namprd05.prod.outlook.com (2603:10b6:803:4a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.10; Tue, 10 Jul 2018 17:59:21 +0000 To: Richard Barnes , rfcplusplus@ietf.org References: From: Eric C Rosen Message-ID: <4624709a-1bca-f5d6-4012-3f83147bd39b@juniper.net> Date: Tue, 10 Jul 2018 13:59:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BN6PR2201CA0020.namprd22.prod.outlook.com (2603:10b6:405:5e::33) To SN4PR0501MB3870.namprd05.prod.outlook.com (2603:10b6:803:4a::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 70533197-af14-41ad-d750-08d5e68edd48 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:SN4PR0501MB3870; X-Microsoft-Exchange-Diagnostics: 1; SN4PR0501MB3870; 3:i7q18/KtFa5v2esdlafSUb+REQMXRssLt+ECPBXQEw2+xcRN2XnP6jKlCuuz5AJVOP7peA5nZbAM821JUyqDYQ8rK2RXlH4tBEbnLwI96stAnELHqSMpYi8GV7bM10RTWjwxdLK1dwxKo1QC431z/UXcDfSpFf3+X9eCb8BVv5yCsjpAvR22x9UcVPZNdo6NC0uFXnZUYzYSs0zAdPrPogHfXt9T/XDe65GD5+rhmGrO1CNzR7TU5WgVeBvCS36m; 25:k6gYFjNdnkCxXHAmwYB7+pUoTZbYQCr2hUzdL5GIFtKE69o7XqK7+Y5Y8FLc1i3B08QjTfNMwkR50g7/l8eLRrf6cGaQG+ewCtj5RygX0hkYpwx6qHxUfOZphP7Auu67rLLs4U6mjhs0QVdXXVNvXcIyVsu1ORFQOPqUdG7vqVT+5PJAvrjURBLVy7sN3x3KBBJfJkK3GHmTIV/AkNFhjEpgDmst3ZqFBp+XcEVNGDoFZGwih9OR8EBxapbR5JbYi0IQ1UZ3d7H3W+Iam5zOExiDMG7a4D9IE3pd1dbIGQnUviO1jyIq/s5faOyQlGGMrBAWV3nV2lPijzbmfEH20A==; 31:9aAzR8M8hy4oOkBqWeFoqK4nMAfxrMo34uA747veIzI5zGl/30DemTqnkNS/Hgf+VHiGUFvI0QpCA40ZVWtgYxCS0s5VY7WuzPnq+FjvhYI1j27HrEmfzIBFLx66WgSHQBQ6fHMkkAl/tj0fyR/m/YgCe7RSrHVfZPZH4XiL3tJDIyG2mD8wMH2ojExagKfQmXCtvN1awxCq2JxxR3a2ArsnHgnQktcEFfKqLHT6WXU= X-MS-TrafficTypeDiagnostic: SN4PR0501MB3870: X-Microsoft-Exchange-Diagnostics: 1; SN4PR0501MB3870; 20:PrOIbQxx98qEICefvyeMqpbVNujopMA/k9G5XA6GrSiCXdTpEMQph2x8jlGYbl7+Q5Hlw7bpBZXvH+l6Cw249bShp7fWEjHPeLcIqeZgseCCL1kky9by6xV2ZxR51tP2tcBMn8HTVEm3676dtN/vGJwrXAv+Q2adRwIMv+FqrPFML3m4+x/y71qgwCrQTi6wf+L2kv/u11DF2rUn0DLvTaIQP23yhdZTxjwfKOux/EVyg0zNcLoXjdAf9bLyDXrA0/F1M2XOSo6XZcvBfK8nAwEo4a6dGT540Y2pTSeG3hriQwijvuPqnmhQpYI1DL5pzmavvJEJ3E8i4FZ4wphff2I60Oba3j8U/hUMEK/vxw3ZxIYO94pRwGCy9c0W3Tvcf3rg60y78M7QWei9nq4CHjn7+cxlTDrwTQMeHJlcl8aBYqhXvBXKpcpYLbmjvEeYQBYriNNhn9M5Fpid7uy1SBGa76oLJFBOIFqEkwLyzrUaz3lXWdeKX2teSE64A1ZtBMtSbYZPwdfMXEeXE7rD4ZihyLgvDRcbloNqTgit1eGOJfonw052yyoQp/Eq0xyf2mT9xANAUsSyxavbon4X09tP9l94HITZeoJhPC6SbGI=; 4:kPYJdmIJ3aCy/7GTweskOrz0ZGANLG6xqagcFBSIohi1ZP/pH9+Dc3rt+HFMdOyPJg19VwbNO2T39lKauO5nluM7o3Zn5G1tjZrUdI4Y50Vzb6baqoinjs0u533e6tjdMkLzqhCxV/5HzkOxxzxBTphB0SLKyEm9/RTEMo/qwh2ROI63onrTl6+99rEe+J1HDt3fU6QDgJ2sx/a2uiipUJT1amrG/55Qmqvg00fm5F6ODyo4k3Tn34QENziE02D1prHyjRzjI9borDfkigDylA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:SN4PR0501MB3870; BCL:0; PCL:0; RULEID:; SRVR:SN4PR0501MB3870; X-Forefront-PRVS: 0729050452 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(396003)(136003)(39860400002)(346002)(376002)(366004)(199004)(189003)(81166006)(65956001)(8676002)(2486003)(66066001)(52146003)(53936002)(65806001)(6246003)(26005)(8936002)(77096007)(52116002)(25786009)(3260700006)(50466002)(47776003)(97736004)(53546011)(386003)(86362001)(76176011)(23676004)(31686004)(31696002)(106356001)(105586002)(7736002)(81156014)(305945005)(64126003)(3846002)(16576012)(486006)(316002)(6116002)(36756003)(956004)(58126008)(2616005)(11346002)(446003)(476003)(5660300001)(67846002)(2870700001)(16526019)(65826007)(6666003)(229853002)(68736007)(478600001)(6486002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN4PR0501MB3870; H:[172.29.35.4]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjRQUjA1MDFNQjM4NzA7MjM6VTI2TUl0OUtyUUZnODgvSis5eGM1Y2w4?= =?utf-8?B?OFVsdGVCM3J1YUhNbXlzQ05lYVhZYnF1a285RUg0ZW5XanFUZ0F5R0QyS2dT?= =?utf-8?B?Sm5ZU0c5bVBSSEFiM0Y3cjdRNzVuK1FuR25JbXpSZ3V2b2NiTVRXNGRyRFFY?= =?utf-8?B?RGY2VDFSMHJzeG9VakxOU2w5LzQ2bUpEVjlBazhCM1d6Vk8xcjFiQ1dHR2Ni?= =?utf-8?B?czVTdk1IOElid3E0UHJnUDV4R2Z2K0FWWVRERFpHeGdXeGEvbFJJZDEzZ1BT?= =?utf-8?B?WUx6bnJkNEdHT1FnWHJXQWUxdDJOWHVHZmRSMDd2ZjN1YUJyVkVrZkkrdjEw?= =?utf-8?B?VmV4NkdtTFhoVThLeGM2Z09lMHVhL1JsbGdNRDIwS3MzZVJYWGRVRTRxRUhx?= =?utf-8?B?WXA5OUJiUzJDMUFyVTJzVW9DY3hRcDN6blBaWktCOGx6azg5S0pCendMS2Vh?= =?utf-8?B?MEU5cFl2RmJXdSs4T0NjM1RMWjdpbHFSa0xXeVBLMXhrY2dLTVFCSjRiVjBw?= =?utf-8?B?VGpzUk1JdmNnOUtGOWRhcWtabkVWU3RQSE5tY2lXc0c4MEdNakluZm1pTUFw?= =?utf-8?B?Unl5V0htK2VLclV0RUpkM1Jib3lUWmw3ZjhpV2s2cWowOEZ5S1NMckVTWUZQ?= =?utf-8?B?TzFlZDBWMHNYZ3c5WGRmMW9yVVc4bUVNT3lTSnhtdWpLanBtWUJSSlNwV3pN?= =?utf-8?B?N3FWK3doN3ZPaDY4dVZBdXUzSzhJVzFSUVJHbmRETEdONUZtSXE3U1pXODBG?= =?utf-8?B?VmMxUWlORnFjakFjdlN5QUptUW5oYXJYZG9FMlJvNWxRUGwzK0JoTHhQTnpF?= =?utf-8?B?dGRKTHNNUFBrWTIzNGlXMDd6cFJuc01FR3lqTHFicWJQalFlVWZ0UDJZWFNK?= =?utf-8?B?UzNvOHdKNTVQQ3dZV1JVVnQrNlZTT09WcmZLbkJJY0E2eUpxR0prejNFdGhv?= =?utf-8?B?L2tERUdpOE5BcU5HYlJ0L1ZkWHlZNXduR0trOWxDMEF1T3JXSTJ2WmFoR0tG?= =?utf-8?B?c2JCdlFrdnB2UHF3azVVNjVCRmJIRVNONllrQ1NZeTJ0UVVza29JTDAxUytD?= =?utf-8?B?K0VyUVdKZzVUV2s2blJjeW1XUGZ5UmxTSzF6NzhvbDZpcEJIUjRDalFNaGF4?= =?utf-8?B?bkVLc05oSG9tWUdENDEwaWVFMkRZUXBWY1o2MHJ6TFk2QTFhcVEvTjJySzhv?= =?utf-8?B?TUh4d010b1E1V3o4cTJmSGdhTEF4emdPTDRnRFY0OG0zTDAxdE4yQ2tyaE9P?= =?utf-8?B?RkpkenF5aUpmNld3U2ljbUR5MUUyMGl3djUvcnZJWVcralRVcFBUcitocm5Q?= =?utf-8?B?d0lGMDMwT1hJdnpTc1YzWEdUcXZxa0N4dDMvVEUyWURhYWd3UUtoTDBTeXNs?= =?utf-8?B?VGgraFI4UkQrb0E3QVBhNFN0elI2MWhFSHVpZjVqQURkTk1Kb0hWTndyaTBU?= =?utf-8?B?L0g5UkdsVDVtakkyNDZOdTNyd2NGSDEzMmlsY0hCb3g2eVR6aUVnSi8yTXQ4?= =?utf-8?B?cVRiT09FL3BhVnhTbGZOeXhPQWxycXFxNHlKSys1N2xSeTBlRVcrV0lLQ1Qv?= =?utf-8?B?aDlLWWZMREcwQ0l3Sitmak9tdTBxLzRTTWhlWG9QQzFLQWp2MVBkb29CWjJX?= =?utf-8?B?MmpkL3FDS2dTN3ZWUmx4RDd6NFY0QUZ2TzJXdkFFOHdjdkgyaEJiNlhpVElH?= =?utf-8?B?R1FpbzhkRVlnTzdIa3ErUGRlU21hYzJudFJqR01XbWVTVHdhOWcwQzFpeEZI?= =?utf-8?B?U3ArYkVhYXY2RlZudmE5U0JaTmNOd3NBV0dYencvYlhpV1BXa2lrb1d3WGF0?= =?utf-8?B?dWhMNTlGNmRmRWJxOWdUZzVZK2FxR050S0JiVDBxbytCcGNFRGV6ZzFvN3Yr?= =?utf-8?Q?R59QrZwfnHKiqHpqWzN8xrIseG22OW+1+p?= X-Microsoft-Antispam-Message-Info: kWgtFp19TNNtTbO0b6212ivJ7iSCmciUxTayACrxaGlnwgk/dX3lNTOYaSJhpqC94CAgBeR0u0utwiYwEdxFjqp8SyvWznrNRqG95NJGz3EDqlBmgUWxxq6ACOTV14DAgRclhkhHI8AMdP+EcNfwMmz8pZNehOakUhCwttNHVCGXLWzXs71Vp9zMUhNosP8/hvFRm2Qu2Kd3yZokwcretpJhfiXkXAi+UlWaumi6iH+eYCSgtOQr2V8UlZlFEsoXv6vPwDW4luimc/UI2RffpXFdFb6CEq507SqrKbW/11DxpyjGq8uFkVqV1k6f/CTPCi/GMDTjiTSt3t5hX/yBJdhVXDv6RSPaZ/Y6P8cE9YM= X-Microsoft-Exchange-Diagnostics: 1; SN4PR0501MB3870; 6:Lgrj7eXnSwMQDPilyw6v+xkqLSn3boCc2GkA1tZbQWE6nK6zPeq2XgI/kpgkHMSf2cZGJ0fiGvzNwOg2bOw1TbMu/AKYC+edZj/B18q2ZvND/08kp/YX0KTBjnD9mFYIxVkWc+0Ni9kkkYhS6HCpDLRWmszxc8RV2FK3gONAej4AwXy8/3L632LiGXMNGLxJkQ+AWG3gkjLVJj1sL3jH/BJUAb8ZBbf4IFJbwuq0W2iaaBoXJMk6LhnDUPNtpld2I4fcSJ1WKi9aXNXyuRCLKnJeXNY62TGSP/8O6G1wNzwUvI0Ead9DJJvgZh0AwybMdy/FbmeU0g0j53A1g7g4la7aiQQZ9Y+5rW0dT5ZB6omFKTu2fGbBhbwO/COUZiIOB25zFe2YoeCWlvr7KYxYWvo3pZsnryCJkxxMQydxXA+pn7Memp1dj8XdXS3SkWO94WVsgPKFW7fKdyG7wXT/Pw==; 5:S5imuwQ3VvJFqvrWg6lcvjoNwymavgJkLoJVbzQxmIQ7WcYIxZmzrHnTi3oex8woQ9XfmByPR/t1f9S9kZrfo9CXGtXLqcV03WGdt91xsD1QHhDLnHlT7KlcmY6+jmrQJuSxXHFUJN1XMkRn4epIFWbceSKyF3NcrU0K6hrz9PY=; 24:qPHtv5nMGNmua4yZkVs+WYGaYc+DA1ELNPMTR2lFfpJMGrn6ANrypdWzdjf92YgA3uk8cG5mSWRvlbUtfy+7RRrPxDXfI24N8CQDbgdM15k= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN4PR0501MB3870; 7:RJqmBkHlJETo1RX2xgLEcCTB3LIAL+D9ypgzLme/T6JvY/XIwJADb3smXZVvPytv+dOz7FSZYex1BF1UWi5rtuzhJI8BAdgHH6in7FdKlDodKGRNe0NF88+1wEuDnHIafyDCbBbsytJFdUcwUI3tySc0aQ3KVq4H8vnXchZf/aKAc24KLcpEDgJoFO5ivWjHqcAJLZhF03MEt8fjDn3SZBi4hksXB3xtgnRHvOS1/gWUfrw/Ho+EnTJNdocCoRlU X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2018 17:59:21.0412 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 70533197-af14-41ad-d750-08d5e68edd48 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0501MB3870 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-10_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807100192 Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:59:28 -0000 On 7/9/2018 6:17 PM, Richard Barnes wrote: > > Suppose someone came to you with the following problem statement: > > - We have 16 (or so) types of document that we want to publish > - We need readers of one of these documents to be clear on which type > they're reading > > Is there anyone here who would look at that problem statement and say, > "The ideal way to do that is to throw all the documents into one > linear series, and have the reader look for distinguishing marks in > the text of the document"?  We shouldn't keep supporting a system we > wouldn't build today. The bias here is in the statement of the problem. One could equally frame the problem as: - We have a long-standing and well-recognized series of documents containing a lot of useful information about how the Internet works, and about how one can interoperate with existing Internet deployments. - There are a number of different procedures for getting a document published in that series. - Sometimes it is of interest to the readers to know which procedure resulted in the publication of a particular document. How would you solve this problem? Well, you could add some text to each document saying which procedure resulted in the publication of the document. Alternatively, you can say, "Well, we need to break the series up into 16 different series, each with its own name, and with no apparent relation to the pre-existing series.  Then when one wants to understand some aspect of the Internet, one has 15 more places to look.  And before one can find out how to interoperate with an existing deployment, one has to figure out which of the series is likely to have the documents one needs.  Of course, to see all the relevant documents, one may have to look at two or three series, good luck finding them." I can't see that the latter alternative has much to recommend it. The former alternative seems much more sensible. BTW, the statement "we need readers of these documents to be clear on which type they're reading" is not a correct statement of the problem anyway.  Most of the anecdotes about confusion have to do with folks that have never read the documents and never will.  The RFP-writers who list RFC numbers without having a clue what's in those RFCs will still generate confusing and non-implementable RFPs.  The need to educate the customer could be regarded as a waste of time, but really it's just another aspect of sales support. Even the folks who do read the documents don't necessarily have to be clear on the procedure that caused the document to be published. If you're reading a protocol spec, it's probably because you need to interoperate with some existing deployments, and whether the protocol went through some particular process is irrelevant. > > To try to be slightly more systematic, I sent a survey out over the > weekend to a bunch of communities I participate in that are > "IETF-adjacent".  It got 115 responses, and the data [1] are > consistent with the anecdata: I think this pseudo-survey has been fully debunked by others. If one wants to show that there is a problem, one should provide evidence that there have been many cases where folks have implemented and deployed the wrong protocol, because they got confused about the status of the RFCs that specify the protocol. The fact that folks not involved in the publication process cannot say which procedures caused the documents to be published is really of no importance at all. From nobody Tue Jul 10 11:15:58 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF6C131028 for ; Tue, 10 Jul 2018 11:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 8SXNrNVwcPAu for ; Tue, 10 Jul 2018 11:15:53 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91FA130EAA for ; Tue, 10 Jul 2018 11:15:53 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id r16-v6so44452917oie.3 for ; Tue, 10 Jul 2018 11:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4c2NfTlKpvFh9fqkdOgsuoADV+wScd91uniUS28PvgE=; b=Gd+bvSiKPjHGufpDBqf3Y9WPETNCrPGoPTt5c5St7mRuTLYy84nFbAd0nNY40n6TLx Neu8U1QuSKEuu//dPHT48myM9iSsQ1z7mjMZPeX+1NWZ1Dx8cxAALrMUUZGe/GmvBqSM MqndfjDSyONRJbahL6UKvcjQ9KpeKJoJBWfxYui1k9o9jPtxOlv7UcxqI4IVFNT+Zl0b ZScrcg5ZPOZH76VvcKfdobfbiLgD/xdWdyr6msQDUXPZ0n2AdKD8oLU6AVIZdPQRgKPG p0jiNMtUc0R3inteO79YXl5UAOin4n/K4hhJ3XquuS6TyYiUZ7oOx2uUMepzmbyET0Bq LISA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4c2NfTlKpvFh9fqkdOgsuoADV+wScd91uniUS28PvgE=; b=bpSuYS93eSuiuLZvymR3oYu1VC61mtui3wCb9j6T9QPgwcpPFehoW9U/z96/+hofDO O9KzMWgob33BUoK/Sqa87teCxcn5ddsErc/uNCuDTumJwrX5nwmwqJRH8rF6+YIscvZv sdgIarLh/nwpq4jlopFV53kYvGjK3z1iNK2jrs3LUkcDJr95lw8FpIAQpHmQ8SEMM3ex tJEXL90n+IWB+EKSpg3Q1pxwvV+6ribXHP9e/p7Cxiv8w0sUL30gtMwI5FjaA1UKNnDd Tt9HbO+5SRZCu64EA1EIQREbKWP92fPRWqShKP/MokHMRFwqixVYji+onlm3CWJhBx72 A3lg== X-Gm-Message-State: APt69E3BMoMJUwsSu8f5gmAkfksS+/r1vErBSMwtW4cL+OjpC9bED5/y xhvAAR3mUa/h1hbFSkrFi+c6A3yQOYDrEyHPyHU= X-Google-Smtp-Source: AAOMgpe2b3uC8Hx4XUikuWsdczqydiLQgQtXtsNUyvz3b1XyEu7lIxwXDkRi6TP6h6WN4rJoS1l73eBJUm4tH/MbHvw= X-Received: by 2002:aca:3c45:: with SMTP id j66-v6mr26702688oia.118.1531246552876; Tue, 10 Jul 2018 11:15:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 11:15:22 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Tue, 10 Jul 2018 11:15:22 -0700 Message-ID: To: Eric C Rosen Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000d90b300570a91e24" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:15:57 -0000 --000000000000d90b300570a91e24 Content-Type: text/plain; charset="UTF-8" Howdy, On Tue, Jul 10, 2018 at 11:06 AM, Eric C Rosen wrote: > On 7/9/2018 11:24 AM, Ted Hardie wrote: > >> the academic community's failure to value the output of the IRTF >> > > I don't understand the relevance of this issue to anything being discussed > here. > > If a RG wishes to publish its output in a respected academic journal, I > don't think there is anything to stop them. > > I meant specifically "output as RFCs", sorry that wasn't as clear as it needed to be. > Maintaining the current publication process for RG output but changing the > name from "RFC" to "IRTF-Masterpiece" is not going to make any difference > in how the academic community values the work. > > That's not what others are saying. The problem as it has been explained to me is that tenure committees and similar academic assessments look at the output of the individual in part by looking at where the output has appeared. When it appears in a series which looks to them to be primarily engineering specifications, it is not valued as highly. A differently labeled series which was entirely composed of research output might be valued differently. I agree with Eliot's earlier point that this is a "might", and that the value ascribed to it depends not just on its output but on the work done to highlight the stream's output. regards, Ted --000000000000d90b300570a91e24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Tue, Jul 10, 2018 at 11:06 AM, Eric C Rosen <erosen= @juniper.net> wrote:
On 7/9/2018 11:24 AM, Ted Hardie wrote:
the academic community's failure to value the output of the IRTF

 I don't understand the relevance of this issue to anything being discus= sed here.

If a RG wishes to publish its output in a respected academic journal, I don= 't think there is anything to stop them.

I meant specifically "output as RFCs", sorr= y that wasn't as clear as it needed to be.
=C2=A0
Maintaining the current publication process for RG output but changing the = name from "RFC" to "IRTF-Masterpiece" is not going to m= ake any difference in how the academic community values the work.


That's not what others are saying.= =C2=A0 The problem as it has been explained to me is that tenure committees= and similar academic assessments look at the output of the individual in p= art by looking at where the output has appeared.=C2=A0 When it appears in a= series which looks to them to be primarily engineering specifications, it = is not valued as highly.=C2=A0 A differently labeled series which was entir= ely composed of research output might be valued differently.

=
I agree with Eliot's earlier point that this is a "migh= t", and that the value ascribed to it depends not just on its output b= ut on the work done to highlight the stream's output.

regards,

Ted

=
=C2=A0

--000000000000d90b300570a91e24-- From nobody Tue Jul 10 11:41:16 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433011311BA for ; Tue, 10 Jul 2018 11:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3ngnVfOatWM for ; Tue, 10 Jul 2018 11:40:58 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE06E131198 for ; Tue, 10 Jul 2018 11:40:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 1D7411D1B83; Tue, 10 Jul 2018 11:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZEj8fFbcsfe; Tue, 10 Jul 2018 11:40:57 -0700 (PDT) Received: from [10.5.50.125] (70-89-112-166-smc-wa.hfc.comcastbusiness.net [70.89.112.166]) by c8a.amsl.com (Postfix) with ESMTPSA id 9B7161CA3BA; Tue, 10 Jul 2018 11:40:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Alice Russo In-Reply-To: <10f6771e-7de6-530d-0c7b-4b347a23612c@gmail.com> Date: Tue, 10 Jul 2018 11:40:57 -0700 Cc: Robert Sparks , rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <515C68DD-F55F-49E5-97E7-569C0815462B@amsl.com> References: <888b184e-51ea-23fc-afaa-f9b5116d480a@gmail.com> <0dbf07da-969c-9704-9618-8d3d7ff03004@nostrum.com> <7787043f-1ab0-f957-2d26-e915009c4d3f@nostrum.com> <10f6771e-7de6-530d-0c7b-4b347a23612c@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] Qualified labels X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:41:14 -0000 On Jul 9, 2018, at 9:53 PM, Brian E Carpenter = wrote: >=20 > ** However, you have hit upon a bug. The IESG may believe that > they upgraded RFC5289, but it seems that nobody told the RFC Editor, > since it is still officially listed as Informational. Even the tracker > is confused. So we have a procedural glitch in this area already. Indeed. I am taking a look at what happened here and will report back. Thank you. RFC Editor/ar= From nobody Tue Jul 10 11:58:15 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B46130E6E for ; Tue, 10 Jul 2018 11:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDKmph55Du2U for ; Tue, 10 Jul 2018 11:58:11 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 4F1AD130E51 for ; Tue, 10 Jul 2018 11:58:11 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6AHwLIm015622; Tue, 10 Jul 2018 11:06:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=PPS1017; bh=W34kA0RWItOya3Vt/syh+gakMgynP8hoE786PwZnkEk=; b=ddyGnS7wLqr8uDBF3EUFWovkTCkfuu/7zI9wIjT4tBRhRE4YT8oELUn/JkLTzEq4MK+t 2A+CVQjiBOGpvtX41ERcbuUO5/Wo7mBhWrUzWLyf+mQf27QQTJKJexS4ntTFpZP+tG8U jIzW5H/Rm+2yzxzDfM9RZY7pun8WuAVUua+DHIXER+kB0wnZMsBlcWRJ2BRjdeNp9AVn PZecgxuyeFX13P7fFeLNFY7Er0M34bfONExemtDXARgOebXzUkeA7fs447vQy+W6oSff zqa0bQ8rKHluZ8hfwbjTjcjMKI4c7V0RjVIPni8xp/2Yb01EOOvXi2VPCDfNDpu6Nk9C JQ== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0183.outbound.protection.outlook.com [216.32.181.183]) by mx0b-00273201.pphosted.com with ESMTP id 2k4wwn8jtx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 10 Jul 2018 11:06:43 -0700 Received: from [172.29.35.4] (66.129.241.10) by CY4PR0501MB3857.namprd05.prod.outlook.com (2603:10b6:910:90::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.12; Tue, 10 Jul 2018 18:06:40 +0000 To: Ted Hardie , rfcplusplus@ietf.org References: From: Eric C Rosen Message-ID: Date: Tue, 10 Jul 2018 14:06:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.129.241.10] X-ClientProxiedBy: BN6PR2001CA0001.namprd20.prod.outlook.com (2603:10b6:404:b4::11) To CY4PR0501MB3857.namprd05.prod.outlook.com (2603:10b6:910:90::18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2895211d-fbc5-4515-51ea-08d5e68fe362 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:CY4PR0501MB3857; X-Microsoft-Exchange-Diagnostics: 1; CY4PR0501MB3857; 3:Pi9h8UNZbnJhw6Ee/OcExzc+VMfLY4zQLoFeL/1g058yXKrMizqMcKM/A7mMTaoZ3putXYLfEtcDX/Nzz691fS2T6w103iVCuykGEgg8glXdzDfFUwEfs3HME0gh2P32kaTHfyFogcKtT+fMOV2v0/DslDioYX+MuiLVq5UIyEZqrd9jK2lMd8M9FJdknOAD+637ipwe1Ek3D71pwKSir9JF28Z5udl+R6CcWBW/GQMJy0qmnwIvXjPJw2RPxy7L; 25:ppw3JczFtkBHC9CgYDkr18C41iZvqSR7kRci4ldl4JfJG3qRJW/Gh5eLWuFrfK+g5qfVkhOMcrs7jL5S6zw3PL2DQkW7gOVqOMKjf6LYc70/7/sGULnum7mh4nScbBJF2egaOMVPs3BQepmuM7s+9AhZGYx1ykA9TgyNFUsh2vRsf9Iv+ySciG7zCZqcxZz4PX5T7i1CVx5/ZhP6ezYkhzD9x6mSDRqa6z8AuUxatbDTAeaQc8ViYQt79tJST6+6CPYqDYSHyCBYh2oFmF8QjZmLUDTJDJCXQMCjwHlsPycndJQZsV/hJv+/XHcdfcD7n+SZGelwm1VDwJsZ8Msjqw==; 31:lW6QAYThkEwAyEhJo3tcKJjzLmp57v+jdJfAmi9W8N39kHyQJ6CNZM3gpiZuQD9wbPXR7y5Vgh35HQPRi9bd0SKu1tDVqmZ0K6jj8CXKKzIrjb7afbpDr77Jl7oMpNt6LzqL/kHA9QlNQumQIzpHTfKF2awkrF+11yYWZa+vfKwfZ93wv5yRr+ec9tMnHkpYekJxMpMnGUvHOfyO9+87D31G+bWFqmlbANQkQUIiJR4= X-MS-TrafficTypeDiagnostic: CY4PR0501MB3857: X-Microsoft-Exchange-Diagnostics: 1; CY4PR0501MB3857; 20:h0rjaSK8B+pMUYyY4kQHu6TFDzNfqa6AjvHNnbruWdKIa8OUFspRzGfnez46eb2TvB0kjl3x4DqEnlHF0zWBo70O+ZrU1Gt38aaBCPVNoB/WxmR9+OYpv+xhKGAWZG04DmPCZpy2OzDn+FTsrJst3n3wHDs62teA3TxJI+tuWgNYN1wo7KGyaOlrrTfVadFKsyV5aCBRLhFZtp2vq4Cx4Ft8+oiTj8+Qre35Z46pc+CRsIJ4PnwgMhBlio4Vf0zb5v/qfmPH33iFOhhdBpDUz/kjQFtPAU9EBk6qPPf+hUIAEQwMPEH5nY+dkFEkKkUWdD8A/0jKuIQs2PgqabmJvva0D/YBd8gg25DnOzwSIx2qf4oBiaUy+BLHV75x3qyku0UgBa6p3GwUmn5z/vXxbLMaSbQUN68awgunRVJjP4zGBK0yn15pT7KIXJ/rgQGqz2tU+7ugl0DfADXiby+PODBPm/ccR9FwkLZZw34kFVCE0MrVRsIgBavgpxwmEszIvYNHtf9FycfN2vpTMq1EyStVX+FdXjP+m3fJQUzKp4eUTRmZpH0Tf5TroD355tauLV+XKHDeGBA0CEAidg1U/zE6bhryXjy3uu5fB3CkvFY=; 4:Sei13PP35ldm9en9aey+V2EImjIcuqjB5M8SNRxVh2M2h6u1jm0iGNROWZUQE+PlR2jG3mA8EA0TDkqlGdM6BXbLA9DqflByFoH8yRbJnSN++WjbqV7GGq+K7EizltPVgo/+tgXbv18utc0qfgDLf3Ex675A1vI76llQhiABc0cR8tyKbT5AaSQuuPaK2aJIZqcfXD4RjXEpEo6natwLBEyWpSZm86004eSWsqQ/nkGIPVID54Fokr3YZjz2VohP4k1I7hN0Ut4zKAqsGde7WQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:CY4PR0501MB3857; BCL:0; PCL:0; RULEID:; SRVR:CY4PR0501MB3857; X-Forefront-PRVS: 0729050452 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(346002)(39860400002)(376002)(396003)(366004)(136003)(199004)(189003)(86362001)(66066001)(47776003)(31686004)(23676004)(52146003)(31696002)(65956001)(65806001)(76176011)(2486003)(5660300001)(53546011)(229853002)(106356001)(97736004)(52116002)(68736007)(2906002)(64126003)(11346002)(316002)(6666003)(386003)(65826007)(478600001)(105586002)(39060400002)(8676002)(2616005)(81156014)(81166006)(3260700006)(25786009)(486006)(305945005)(50466002)(16576012)(476003)(16526019)(26005)(7736002)(77096007)(6486002)(36756003)(3846002)(8936002)(446003)(956004)(230700001)(58126008)(6246003)(53936002)(6116002)(14444005)(67846002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0501MB3857; H:[172.29.35.4]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjA1MDFNQjM4NTc7MjM6UEdpNFcxS0RmbHFpZ2dQbXpYc1p0OENZ?= =?utf-8?B?NEJBb1k5OWpKUklQTzRaRmNIWGg3M1dGWk9SdTF5akFNNWhpdmVkb3JhTjNJ?= =?utf-8?B?UzErUDlpaVlVZ1FlbkUvcURHTDJadkVYa0VxODJVZDlaMXc5TmxKSndNa0VD?= =?utf-8?B?WnBzMVZDUkJ6c1JDUzM1VEJrTXhlRlMyOStyMUM2bGY4WFVJVERJMXJaYjR6?= =?utf-8?B?Zm5WbHl4KzFMRlRZNEZHNmxsck44M1FRNldkZ2F3eTFQSjQ0cmU5a3E2aGFl?= =?utf-8?B?TTNPa2ZQYTgxN1UrMnhSM3crdEVDakM4b2dkaWdMZ01ad3ZVK01ZNWkxUnRT?= =?utf-8?B?alhGdjM0YWpCaHRtc1htazRrRmhneFBnaDFPN1N6RnRtWGsrVjBOZmxpYkR5?= =?utf-8?B?MC85bEVlRXZWQW5NSEQ2QWx0OU9CajJZWTI3cHVVRXozVitmZ0k2TUR6UkRV?= =?utf-8?B?UFhCUGd2VzA2c1l3Qm5WNFcwSjBoQUtUZDNDT0tuUHpwN1hVTjhqRFZ2REVS?= =?utf-8?B?VU51TFJTRFVNNzRvcE5VSUJlNlgvenhzcFA3MlZINi9OT3VuMDdteS9KU0FO?= =?utf-8?B?MG1HRENHQ3hINkJVYnJ4UDFNVmJBOEc1a215cUkyNDdlN2phN3V4SkdvcWpz?= =?utf-8?B?TjRNeDhBSHZCUk5oS1luVjBkTXVFYkdnWlpETDFwdzFFamgwOTlGK2ExVEs5?= =?utf-8?B?UEg2cS9CMkJ1Z3NQcHdCRzMvZVdmR0JTWURTRXFTV211ZXJKdnErR1h0eE53?= =?utf-8?B?dEw4TjBvaWEwTnlSTDg2U2l1UUJmam5YNGJqajFsUFdWWjVDQklka1ZlRy9X?= =?utf-8?B?aTBiSjlkR2lzTndBSGtFejhGWldCWTRqdkNvczd0UlF4cE5RS0ZWNlk1UUEz?= =?utf-8?B?U2lpMDgwWUxDR21qcUVYZXcxUmIxVkFKemtibmZ3Q01uRUhTdUtWemtTNVVD?= =?utf-8?B?amJUU0Y2Y2FBL0pMQ2h5VVRXV2VETEtWTDRBNThVdmNuR3JxQWhCWW1icWFM?= =?utf-8?B?RnJ5ZktxSW4yN2x2dnQrMnBHakFUSWdYN1p3d3IvM0JObUxOdzNPSG40ZTZO?= =?utf-8?B?cURCaEVLZ0dqbXZyZ1lqRkJoUDJQdXFPY1BxT2wwdzBCakRWWkd2aFBzWFQz?= =?utf-8?B?dno4bUtLbFY3N1VBd1BXUFRLT2J4aUozT2xJVGptR250NmpGMDNGaFRwN1NR?= =?utf-8?B?cU82bTFkZi9LY20yR3QrVXpGWEVURndBZE5VaFZRT2ZMY1F6cjZMMjhqdlEw?= =?utf-8?B?QldYSURoNEFrVVdmanEvSjAwN0FNZS9GejZ3WXo0VHRmdCs2dW9LWmRzaHA5?= =?utf-8?B?dlFUZFY0QTJSNTJ5bDVZb0Z1cTQ3WW80MFAwaTE3bGhXdnlHNlh1b3JCM0RL?= =?utf-8?B?SExqcXYzSUZldnpSbkJZV05ISWZMekFrem9SQTg3VENwY1dxSXdhS1lxNGN5?= =?utf-8?B?dUtWL1g5RnZoTElFSEJPNHpPWWZLQU1nVVZoVTlSWjBwZmhEbWNCdm4vTTdv?= =?utf-8?B?UXlQVlpzb2VOeGxJZ0czTE9LM2c5bnNqbW5KUWlTMmhWMVdJYW1yUWhEMXlm?= =?utf-8?B?Y2RYQzJIZHZUU1BTUjdaRkZxSlc0KzZjZ2M3V0VYK3E2bE5rSW5SRG4rdGZy?= =?utf-8?B?Q2oyamlzVUZaSmR6WVBaVTBPbGN3Q1grWWkxSWp2bGp3amkwYnZpVWU1RC9w?= =?utf-8?B?OVBBWHFLbHhRWVljRHM3L1U1dXRCZnZwRklKdWIvR2hyZkZEMFRYQUxUWjcz?= =?utf-8?B?Z0E3NnhCOXBKWDQwaDhBMFBqWFdrREJUeGk3MG1wRTNkamg1cUhTcHM3RlJ3?= =?utf-8?B?b1ZTbkVldjV4WkovK3NxeGNubW15TS91aEdPQWluTDZBd1pGTEdvTWNoc3ZF?= =?utf-8?B?R3RYQ3FwNTNHQlZCcm5TdmxaWGJQalk3NFpGMTZoSHc3MzA1MHVYTEVZVmlS?= =?utf-8?Q?FVGNTpL7tIrkVcWjDIq9A7m02fMRRYYk=3D?= X-Microsoft-Antispam-Message-Info: YwBQPlrVtPAPc1besKA7gEOatBMuihw/XNHbJNQS1KFmpVnxdAksdYE6W4QgGyjgVqjyETF2W3TIgYohUnH9CheMuqXXLM/nMLerhE3fr0zZlrh0LGJRoEh6Ay8cjHTIRdBDBYcZhnugDQDbTKwNpipP6mlGMr0OFazvqjO0DaiAs9M+s/TedjlzKRbAuQeetnRbh1/comf+buSwlgtU2MpdJi8Vf93+0NxQ8HI7B5N4Va6FoAd0TBGnjqw6zod4cSrv5TdUkrxYSCYybrHIvoP90Dz8NpohEYS4BcDFsBpZK65UNzUiUpenRWo3B7/jmKCCtc6QY+uEVXfVLbTWtYJ4c5mgqYVW+Sm1Tx/BORc= X-Microsoft-Exchange-Diagnostics: 1; CY4PR0501MB3857; 6:GLxU9oOhhjMqTJ/d5sGXK5DZOv2s3nPbNrzU0zD7kN8Ftx4YlKoTrevh5r9HijIfPBhquS5VRTI9ty0KMrN0+JBxoIWSikbVGJ3f6FBypj/1bbNqnyMklUcO1SsWNWgXi6z+oPVb7hndtcx7c4t5mUsUciXxwan8s5eRwVh8y+pO5cN4TQfROKdJ3vvI7FG1y7rjVr4h8z2XzMIusBJOr/z07b7+Sx89XJ2Qs2p7JgvBzIo6Jv09yLjJlW8oxJZJva90QLnFE3EYO3EnqzKGVOTTqBJabz6hPi7E2YYHxjVIvd14feVkGR8Mb5zrHqkwzO3mY0hHM1pROLpE7mvz38yy7TsG+TIj+cCfAr6IaGjhj8hjydXCGhw9/Gm+/61rDnTW/UCVVpp0fU0P3ahiBxkZo6Db7Ny/xKVawDC/9pAhI09NtyjXN6fzlMvK8NPJYgbddHSWK/C/1f0s6tnLHw==; 5:/DhVevDufHoqMrAu1pJAkrpLB90EO1v34sM8qZR5FhaG4KkzB7/Qo4vSUJGrAVTU/ugYg+2UGNITcbugvdhHSuxc7tbEcQWm8RgeA8XUxS4T4pJsqiX+yiB3FqEOOh2Th3ZajTvdHyLY+xoNmLDTUSMbrA9lg77R5azc+TfNUtY=; 24:0DviOzzD+7mOTjQBrEsZtqUJqdB87c0ZIXjSYKJ35ZcVh4+Uf2tmqmMFa7TSVqZPWkmq/mQ8EJj6ROXhuqTNfzMJW+rvgcRTEvE4tlS1qfs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR0501MB3857; 7:pbm/kNFwCuf3ZdyvMbDw+y5520GQ+3Az8W9Sl2KZTI8ZrlhVkaTQsVR99idDg0UWLBihzJ36koOHd31eUrEOJ1D2yTlJfAxQrwA9GXJnlMELIarBXGVYnHlKUFqrgyzzyg+82kHUGzZp/MKUsc+hSg+1W6kCq1YyilTbwZCih06/CDt0LpQQpeGQnvyiMSaMnJ11dhhCdsk9FB2QXFy1YorbhjzEfvwvz/vV0jku7qQhuat/XFwyVAY2T9pcjDii X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2018 18:06:40.5181 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2895211d-fbc5-4515-51ea-08d5e68fe362 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0501MB3857 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-10_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=891 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807100192 Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:58:14 -0000 On 7/9/2018 11:24 AM, Ted Hardie wrote: > the academic community's failure to value the output of the IRTF I don't understand the relevance of this issue to anything being discussed here. If a RG wishes to publish its output in a respected academic journal, I don't think there is anything to stop them. Maintaining the current publication process for RG output but changing the name from "RFC" to "IRTF-Masterpiece" is not going to make any difference in how the academic community values the work. From nobody Tue Jul 10 12:20:11 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE74131169 for ; Tue, 10 Jul 2018 12:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 lGCQSIMSZa6f for ; Tue, 10 Jul 2018 12:20:02 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A9B1311A3 for ; Tue, 10 Jul 2018 12:20:02 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id x10-v6so6874947pfm.4 for ; Tue, 10 Jul 2018 12:20:02 -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=1oQJ8YPn78ICU75Ufkg+COzAF5+3m+0+8zj91r4rH6A=; b=u91Cht3TDR3cjgldQudBz/4psg57opznTuKlpS6j2UzJYfbrm4UmiuCPfepe3XskTd ZRKiyo+JRG6R3j0E91vtM8iwsLzGJfcScNa6t47D8tsv2+ugCh/FukZvHddenSUdHVns swVEQQxOEMpTGsl5We62T8qqlBHJB6pcfZGzLGNRicVzOG0QHVMiKZjQNm2QNIkcrHHe E1gRJlNR2Tgm06+gP+BzFnErT+FzMzWOAxwRt8rcARsm/J5GZ8UigX7k5OqEp3LLqeR/ lIt869aCq3fFeUCMjTGcorN+q+BJr0TAzZmBWPwHwdu8RIA1/D0+6/NO16lkpAmHpDzf pzOg== 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=1oQJ8YPn78ICU75Ufkg+COzAF5+3m+0+8zj91r4rH6A=; b=BXIHlwJHOR9UncUjgdqnC/KBQwkm7Q/9HwNcgom+TGFoi2wcK4KBYMY2K+7u/E89yG EN36G8TdOMTYNd0+mjKfX4FS+85N/zyyny3JcFvBUNIPD84xEK11X+/kL7ulGliN9By/ zev0V0chBqrEesi2t530DfOvf26ZgBdxWM0Wp9zCQUIf47EgrUgkPESStxcq167Fdn6N wBAtobHh9zwEZeWglaE4C3roXUNb1JfTaxfnPwIPks9NMUTldoBmnHwqJiNGhdbmviZ+ n/C3ACOP2Z1Xx9zAhLIeDFdSZCTKpPMWmMx8Bdpi/1Yn5LD3AjCaG8eUobPe+tVQZ+xM QouA== X-Gm-Message-State: APt69E319JDE+PKToYbSv2D8Tz0cAU5urHN8xBsXd+DDFs0UTc2gwtq1 Khr8JaW/opviwBntvHjkvFg= X-Google-Smtp-Source: AAOMgpfyGkiW/QPJZKYi3khjUhV1NpC+wDXC00Qi+xFtnpr7PsipI6mIRu1//071yLpoJAUUb94YyA== X-Received: by 2002:a63:842:: with SMTP id 63-v6mr24502257pgi.406.1531250401927; Tue, 10 Jul 2018 12:20:01 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id k64-v6sm19393679pgd.47.2018.07.10.12.20.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 12:20:01 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FC91CB61-B9DD-4A53-8F23-3CBBA9E62189"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 10 Jul 2018 12:19:58 -0700 In-Reply-To: Cc: Bob Hinden , Ted Hardie , rfcplusplus@ietf.org To: Eric C Rosen References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 19:20:05 -0000 --Apple-Mail=_FC91CB61-B9DD-4A53-8F23-3CBBA9E62189 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 10, 2018, at 11:06 AM, Eric C Rosen wrote: >=20 > On 7/9/2018 11:24 AM, Ted Hardie wrote: >> the academic community's failure to value the output of the IRTF >=20 > I don't understand the relevance of this issue to anything being = discussed here. >=20 > If a RG wishes to publish its output in a respected academic journal, = I don't think there is anything to stop them. >=20 > Maintaining the current publication process for RG output but changing = the name from "RFC" to "IRTF-Masterpiece" is not going to make any = difference in how the academic community values the work. Worse, I suspect it will make it harder. The RFC Series is well known, = the =E2=80=9CIRTF-Masterpice=E2=80=9D series will be new and not = trusted. Bob --Apple-Mail=_FC91CB61-B9DD-4A53-8F23-3CBBA9E62189 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAltFBt4ACgkQrut0EXfn u6gItAf/RKmJY0WvaYXSienSptqhi5bvBR2u9LS4MeS0XFzunengiIxdbrU0p+TW D3ClZnoevojnT2cxFyvhLrX0G9sJ4vLH43hvmDM08jGHbxv2tZC0fZ8LzqUwBH3p aryVSZTmTWfb2psVJfbeNTnOy+G3NT3MgyesBFI7l37TUjmsXcwDIOmLyNTamSVo prf/effMofxz843xUMcYBeH9rYwy9GiFBYHCuQuYb0Qd1q7OqTY9Kva2Ms/q1Vrf yG3itPaRvuusa/dxqp3T1h2zj3P2ImlHrxbzyNElFORtp/dbz9/bJ5DBKKTrdZ3c wMBPI7l1zBaM4/ozbzdvShrx0b5PNA== =mSCL -----END PGP SIGNATURE----- --Apple-Mail=_FC91CB61-B9DD-4A53-8F23-3CBBA9E62189-- From nobody Tue Jul 10 12:28:49 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701CC130E51 for ; Tue, 10 Jul 2018 12:28:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yitter.info header.b=USgfhT1S; dkim=pass (1024-bit key) header.d=yitter.info header.b=czIczwuo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06DTcXmC82Tc for ; Tue, 10 Jul 2018 12:28:44 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4CCA130E17 for ; Tue, 10 Jul 2018 12:28:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 08E7BBEBEB for ; Tue, 10 Jul 2018 19:28:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1531250894; bh=p/oqoZRrOlIpjOJlyhey49ot8kvLfD8YWhU3ZWLBB88=; h=Date:From:To:Subject:References:In-Reply-To:From; b=USgfhT1Se4xQ/LM3KW6tSGJfFeRy6jCMULLfGxdivmEPS9o7Tc2TCLAo519uWoA55 8S6gB8evO4G72WnyNAvS843szl7xjtUPeArgAZVJuHS4YTjvYePgGYWRkW+wVIPV1l cZZp7Poz0HZ+dXv5Z+BkzhicYtiRtjLh3QY2ZXn4= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE7defSpWNsc for ; Tue, 10 Jul 2018 19:28:12 +0000 (UTC) Date: Tue, 10 Jul 2018 15:28:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1531250892; bh=p/oqoZRrOlIpjOJlyhey49ot8kvLfD8YWhU3ZWLBB88=; h=Date:From:To:Subject:References:In-Reply-To:From; b=czIczwuo927shfv9mwXcyrOg3rD3BLZuotxc8HzYlO9G7MEJFYd/jeOdYRACcMur2 zD1F9ITKdYiSDkwZBdqFsowF5Dx4exNKJo5tW4n0WNOJL0H3WjOKgYFw/2wm6ZvySA qBhfOaw2mPYDIeiWTfShdwisMX6abWxoMnGxdKjY= From: Andrew Sullivan To: rfcplusplus@ietf.org Message-ID: <20180710192810.GQ20282@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 19:28:48 -0000 On Tue, Jul 10, 2018 at 12:19:58PM -0700, Bob Hinden wrote: > Worse, I suspect it will make it harder. Of course, as people have pointed out in other threads, we actually just have no real data about this and our gut feelings about what might happen are not a good guide. > The RFC Series is well known, the “IRTF-Masterpice†series will be > new and not trusted. One thing we _do_ have some data about is the low regard in which the RFC series is held in many academic contexts, because it is not considered a peer reviewed publication and because it is often considered a series for technical standards rather than for academic research. That is data that has been provided by various IRTF participants over several years, and with few exceptions I'm unaware of that having changed in any large degree recently. A different series with a different publication standard might have an easier time of getting acceptance for this role than an established one that "everyone knows" isn't a peer-reviewed publication. Certainly in the mists of time when I was still an aspiring academic, it was easier to establish a new journal's reputation than it was to rectify the reputation of a journal that was widely regarded as having passed its peak. Rather than speculating, however, I'd be inclined to do some research on journal ranking in the past decade among computer science people. This is again something that I doubt can be done without some investment. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jul 10 12:35:57 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970001311A3 for ; Tue, 10 Jul 2018 12:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 bfa_rTLxTOWp for ; Tue, 10 Jul 2018 12:35:52 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10EF1292AD for ; Tue, 10 Jul 2018 12:35:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C7DC71D1B8B; Tue, 10 Jul 2018 12:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2u6lFe71ulN; Tue, 10 Jul 2018 12:35:50 -0700 (PDT) Received: from [10.5.50.125] (70-89-112-166-smc-wa.hfc.comcastbusiness.net [70.89.112.166]) by c8a.amsl.com (Postfix) with ESMTPSA id 8ACB91D1B86; Tue, 10 Jul 2018 12:35:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Alice Russo In-Reply-To: <515C68DD-F55F-49E5-97E7-569C0815462B@amsl.com> Date: Tue, 10 Jul 2018 12:35:51 -0700 Cc: rfcplusplus@ietf.org, Robert Sparks Content-Transfer-Encoding: quoted-printable Message-Id: <3A370D7D-B731-4AA3-AC69-4F0826258217@amsl.com> References: <888b184e-51ea-23fc-afaa-f9b5116d480a@gmail.com> <0dbf07da-969c-9704-9618-8d3d7ff03004@nostrum.com> <7787043f-1ab0-f957-2d26-e915009c4d3f@nostrum.com> <10f6771e-7de6-530d-0c7b-4b347a23612c@gmail.com> <515C68DD-F55F-49E5-97E7-569C0815462B@amsl.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] Qualified labels X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 19:35:55 -0000 Reporting back re: RFC 5289. [FYI, the IESG has been sent this information separately.] We received the Protocol Action mail 20 March 2017 to change RFC 5289 to = Proposed Standard, but the status change was not carried out. I = apologize for this mistake.=20 At this point, the underlying data and derived displays have been = updated. The info page [1] and the list of all RFC status changes [2] = show "March 2017" for this change. However, if the preference is "July = 2018" to reflect when the RFC's metadata was updated, please let me = know. We'll review the mails re: status changes received thus far and revise = the process for handling them (as necessary) to prevent this in the = future. Typically, a notification mail is sent to rfc-dist and ietf-announce = when an RFC moves up in the Standards Track (in this case, onto the = Standards Track). We'll send that shortly. Thank you. RFC Editor/ar [1] https://www.rfc-editor.org/info/rfc5289=20 [2] https://www.rfc-editor.org/status_changes.php=20 > On Jul 10, 2018, at 11:40 AM, Alice Russo wrote: >=20 > On Jul 9, 2018, at 9:53 PM, Brian E Carpenter = wrote: >>=20 >> ** However, you have hit upon a bug. The IESG may believe that >> they upgraded RFC5289, but it seems that nobody told the RFC Editor, >> since it is still officially listed as Informational. Even the = tracker >> is confused. So we have a procedural glitch in this area already. >=20 > Indeed. >=20 > I am taking a look at what happened here and will report back. >=20 > Thank you. > RFC Editor/ar > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 From nobody Tue Jul 10 12:37:53 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9231D1292AD for ; Tue, 10 Jul 2018 12:37:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2asLGmBAzHDM for ; Tue, 10 Jul 2018 12:37:49 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E2013104C for ; Tue, 10 Jul 2018 12:37:49 -0700 (PDT) Received: from localhost ([::1] helo=JcK-T100) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fcySJ-0005uq-Og; Tue, 10 Jul 2018 15:37:47 -0400 Date: Tue, 10 Jul 2018 15:37:47 -0400 From: John C Klensin To: Eric C Rosen , rfcplusplus@ietf.org Message-ID: In-Reply-To: <4624709a-1bca-f5d6-4012-3f83147bd39b@juniper.net> References: <4624709a-1bca-f5d6-4012-3f83147bd39b@juniper.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 19:37:52 -0000 Eric, Thanks for, IMO, a very good summary. One addition: because the BOF request starts from a very old description of/assertions about the supposed confusion problem, it seems to me to be incumbent on those who claim there is still a problem serious enough to require drastic action to demonstrate that the many changes we have introduced to clarify the status of documents since then have been ineffective. thanks again, john =20 --On Tuesday, July 10, 2018 13:59 -0400 Eric C Rosen wrote: > On 7/9/2018 6:17 PM, Richard Barnes wrote: >>=20 >> Suppose someone came to you with the following problem >> statement: >>=20 >> - We have 16 (or so) types of document that we want to = publish >> - We need readers of one of these documents to be clear on >> which type they're reading >>=20 >> Is there anyone here who would look at that problem statement >> and say, "The ideal way to do that is to throw all the >> documents into one linear series, and have the reader look >> for distinguishing marks in the text of the document"?=C2=A0 = We >> shouldn't keep supporting a system we wouldn't build today. >=20 > The bias here is in the statement of the problem. >=20 > One could equally frame the problem as: >=20 > - We have a long-standing and well-recognized series of > documents containing a lot of useful information about how the > Internet works, and about how one can interoperate with > existing Internet deployments. >=20 > - There are a number of different procedures for getting a > document published in that series. >=20 > - Sometimes it is of interest to the readers to know which > procedure resulted in the publication of a particular = document. >=20 > How would you solve this problem? >=20 > Well, you could add some text to each document saying which > procedure resulted in the publication of the document. >=20 > Alternatively, you can say, "Well, we need to break the series > up into 16 different series, each with its own name, and with > no apparent relation to the pre-existing series.=C2=A0 Then = when > one wants to understand some aspect of the Internet, one has > 15 more places to look.=C2=A0 And before one can find out how = to > interoperate with an existing deployment, one has to figure > out which of the series is likely to have the documents one > needs.=C2=A0 Of course, to see all the relevant documents, one = may > have to look at two or three series, good luck finding them." >=20 > I can't see that the latter alternative has much to recommend > it. The former alternative seems much more sensible. >=20 > BTW, the statement "we need readers of these documents to be > clear on which type they're reading" is not a correct > statement of the problem anyway.=C2=A0 Most of the anecdotes = about > confusion have to do with folks that have never read the > documents and never will.=C2=A0 The RFP-writers who list RFC > numbers without having a clue what's in those RFCs will still > generate confusing and non-implementable RFPs.=C2=A0 The need = to > educate the customer could be regarded as a waste of time, but > really it's just another aspect of sales support. >=20 > Even the folks who do read the documents don't necessarily > have to be clear on the procedure that caused the document to > be published. If you're reading a protocol spec, it's probably > because you need to interoperate with some existing > deployments, and whether the protocol went through some > particular process is irrelevant. >=20 >>=20 >> To try to be slightly more systematic, I sent a survey out >> over the weekend to a bunch of communities I participate in >> that are "IETF-adjacent".=C2=A0 It got 115 responses, and = the >> data [1] are consistent with the anecdata: >=20 > I think this pseudo-survey has been fully debunked by others. >=20 > If one wants to show that there is a problem, one should > provide evidence that there have been many cases where folks > have implemented and deployed the wrong protocol, because they > got confused about the status of the RFCs that specify the > protocol. The fact that folks not involved in the publication > process cannot say which procedures caused the documents to be > published is really of no importance at all. >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Tue Jul 10 12:51:35 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31DB13104C for ; Tue, 10 Jul 2018 12:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 5IaXlboXSi5U for ; Tue, 10 Jul 2018 12:51:31 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F861310CD for ; Tue, 10 Jul 2018 12:51:31 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id 31-v6so8069335plc.4 for ; Tue, 10 Jul 2018 12:51:31 -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=t9uH8LJNMwsQrO0NoMOI9Rp2OT1qFm2QsUOI5mAVW+g=; b=uqBlw4eC/4B9jEXqQn9xyK+61zlhA2wmMks9D4d2ggjpQkLbFAVEJjwb4k+9WDYotv GgrneL1JCiNuhfiD+pWrjNb50YkEKZ+v3wEgXzh8/6lswAqbY/AvvNl4Fac6YLOmIWwF 5g5GH5HIGBtmvOYW5ONmtuOdREjmDZsJLvy2r6JV3HKBlTUKwMocSO+Ou+wRUA4xd0uM IIgywn/bRCaHQrj6vUobDvIVXm2KmyAKv6hJd0LUtBtb67Ftwp6XyvYkicUdUw69hNgM o1ylMiYB493Ewxt8LN+HHTy7XiwOXOyYfozbLMjc8pGYE85XPemAGmK2AfCjTmY+Nr7M wR3A== 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=t9uH8LJNMwsQrO0NoMOI9Rp2OT1qFm2QsUOI5mAVW+g=; b=Gt62+3MdfGlL828IKYKsTsm92H9DDL48KEwDeug4+oEbJAST3RC3mnMA6fubwFpOs4 Vns+uMG5CNnOa6NYBhBUeNkndJuLZbTDxHflIq7Lc4BGIac3Xdi1pqqwup0RFiW6FCdh BbvwR/I5/glGpszf0XdOzjkTbrusTKsnld3fiW/6xsukDNPA7m0ezplKjRVFDt9MUeUO TtwzBN0QHc9ezCk+zOv95/v/irjAJ+n0+nrp71zAT6GJblfbdCI6+PFBKyz4Dx8X3xyl m9X2VlWE7SR7SKz+SVAUiG2tM6DITX3DD0xDrueK5RPps3yhq3mvRHHnxIYaw5KgI1JP +yhg== X-Gm-Message-State: APt69E230i15rhvfkUM3QkXHbH72ZnGzpQubzR8zA5/MZZqWnkBhUvye mnDP4F6KHL1EAD0X2WiRm2U= X-Google-Smtp-Source: AAOMgpdLuhcEeVzwVMdLJWAS3s36BR3nvHz5Qu/tFrH9SO9ND05+gBn9jCox2PGwGcNhIojc0SdODg== X-Received: by 2002:a17:902:7009:: with SMTP id y9-v6mr25776969plk.217.1531252291197; Tue, 10 Jul 2018 12:51:31 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id g23-v6sm24698280pgv.26.2018.07.10.12.51.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 12:51:30 -0700 (PDT) From: Bob Hinden Message-Id: <4354E24C-458D-4A6B-9510-AAB49C230D65@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5E3FF79F-BEA6-4411-A367-BDD9D2E0E79D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 10 Jul 2018 12:51:27 -0700 In-Reply-To: <20180710192810.GQ20282@mx4.yitter.info> Cc: Bob Hinden , rfcplusplus@ietf.org To: Andrew Sullivan References: <20180710192810.GQ20282@mx4.yitter.info> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 19:51:34 -0000 --Apple-Mail=_5E3FF79F-BEA6-4411-A367-BDD9D2E0E79D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Andrew, > On Jul 10, 2018, at 12:28 PM, Andrew Sullivan = wrote: >=20 > On Tue, Jul 10, 2018 at 12:19:58PM -0700, Bob Hinden wrote: >> Worse, I suspect it will make it harder. >=20 > Of course, as people have pointed out in other threads, we actually > just have no real data about this and our gut feelings about what > might happen are not a good guide. >=20 >> The RFC Series is well known, the =E2=80=9CIRTF-Masterpice=E2=80=9D = series will be >> new and not trusted. >=20 > One thing we _do_ have some data about is the low regard in which the > RFC series is held in many academic contexts, because it is not > considered a peer reviewed publication and because it is often > considered a series for technical standards rather than for academic > research. That is data that has been provided by various IRTF > participants over several years, and with few exceptions I'm unaware > of that having changed in any large degree recently. >=20 > A different series with a different publication standard might have an > easier time of getting acceptance for this role than an established > one that "everyone knows" isn't a peer-reviewed publication. > Certainly in the mists of time when I was still an aspiring academic, > it was easier to establish a new journal's reputation than it was to > rectify the reputation of a journal that was widely regarded as having > passed its peak. Rather than speculating, however, I'd be inclined to > do some research on journal ranking in the past decade among computer > science people. This is again something that I doubt can be done > without some investment. Fair point. I think that=E2=80=99s a good summary for the whole topic of the BOF. = We don=E2=80=99t understand the problem (or even agree there is a = problem), nor have we done any real research on solutions. I continue to think a better way to approach these issues, is to hand = them to the RFC Editor and let her come back with a recommendation. Bob --Apple-Mail=_5E3FF79F-BEA6-4411-A367-BDD9D2E0E79D 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAltFDj8ACgkQrut0EXfn u6jbDQf9HaPtntGOOWZg4KYuItf1elbD2tTP+w9kvXuOpZ3VvtjwnLsyVpvcEx3A MUnz7ofZXpG+8JDOsskRCsBUDsKkDVLq6umZ1KoRHdmZmf5mCKX++U4KjfZAno2h CtxUCvVR0oimHQHWfI2u9Jp/Bw9yCtwc9F5HT4Y7K9vXt8STvVFv6yDp9k8N9Iub kLAs0chfpnV3SOS/3cZFa/d++Sx+/BQxrDuDI1MqBPRr9AOAeZ66mWKj7mFD3QNn ViDztljfJUwOR+XJLYhOwU4BMSKPKYxJKnpyGqCRsiwLkbfNXQUE+KxPu9q3g9y+ TN6flNPSHDYMN3S2sdMs+I/LMopPVg== =F4p5 -----END PGP SIGNATURE----- --Apple-Mail=_5E3FF79F-BEA6-4411-A367-BDD9D2E0E79D-- From nobody Tue Jul 10 12:59:11 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C110130E95 for ; Tue, 10 Jul 2018 12:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njud6gXqklIz for ; Tue, 10 Jul 2018 12:59:02 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 698A0130E7F for ; Tue, 10 Jul 2018 12:59:02 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6AJwW6p019636; Tue, 10 Jul 2018 12:58:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=PPS1017; bh=Yu/PieSDJ/mAmZ85c+dvD73IQKqNIOWBfNNAPNk49YM=; b=1ipv5HbNPiq0b4KqyJc8TQzm2OPMe5PZ2eKWuGcj07DajsubW0hHkRvZukqYuY1yIXNJ +I1SlXlWKLepsbZQt/oVmaQB+xaU95p4NHB2E7tlx8DanRwK7uNKc4yWRVIzvI/opzzg ozWY4Xlngtgwl1DOqiI0JYVSoFOUJJK8GPWFohFTa/QPYTkC4NZ8/kaMKpzV/100Ez1N crwcQo2A7Y5VlX1dL21h/k+7W9ozrkE6zA97kV6zXkY1f7oChrPLyFIq0GeNsKBF3VRh T9m5O54Dx9fJw5MTAge8lf2pxO8a37nHVMsLf/CpSXCp9Q0SzdAkYV814Yv2rjhr3gmY dw== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0019.outbound.protection.outlook.com [216.32.180.19]) by mx0a-00273201.pphosted.com with ESMTP id 2k4s8jsbar-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 10 Jul 2018 12:58:54 -0700 Received: from [172.29.35.4] (66.129.241.10) by MWHPR0501MB3867.namprd05.prod.outlook.com (2603:10b6:301:7b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.7; Tue, 10 Jul 2018 19:58:51 +0000 To: Andrew Sullivan , rfcplusplus@ietf.org References: <20180710192810.GQ20282@mx4.yitter.info> From: Eric C Rosen Message-ID: <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> Date: Tue, 10 Jul 2018 15:58:47 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <20180710192810.GQ20282@mx4.yitter.info> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BN6PR14CA0022.namprd14.prod.outlook.com (2603:10b6:404:79::32) To MWHPR0501MB3867.namprd05.prod.outlook.com (2603:10b6:301:7b::22) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9e86c636-d1a6-47cd-11c3-08d5e69f8f88 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:MWHPR0501MB3867; X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3867; 3:q5qjvUuc2jaxf/FJjOjZMBQ6vqdAC3B/aB2edhIB9BA544N5kvVXsbJqSquj5S3SDXcqP8TQlJRFHNdHIvXEjZpoXiTQN7aISM1vKzsGWnB8tjS5gvuSNNkCJTzpqtcVQbCKRoq9xAoErpvWjvvKf0YS/ad5zopNDGNI/J8Qx2AJ3ZBBHj8YR/1e3XN47yS2IBGZnAslS2p9KDVE8mwy5WW52SoYWdQ+LNr66eE4CEuMD8KeNsRyAIsaO41IlafQ; 25:294EDThJHEPHryqWuHqjAb5Ff/laGGRv3UbLKj7e6T/L1YXupqtPT/zzrEl4NpqifGCswI6BXdz/kus+ERRSHQr6WNGO38JPHFNhB9K048U+T7nqS3YlUs3tTVuGL8vFgWprHZcqASeqdplEhROknDKB+6c4E4eZ5iIKD8qjWiq5L+FzGe6dhhAY8i6rFt9atN0UZnmZk2aDLwatUaaneW+t5tlChWSugANoav9WMuuI5t9JswT8k2g3yX9+6NpEPkSk/A2KfVV1BZ7H8E59TggZbCfacHprmZfm0GE1X6yZlC5kVQrm57T6aPkBGEX+KR3neC+kH2/EpRFxinymjQ==; 31:35g0vRpkk/FEc2QLeYqoO42b/C8gf+GBIshqP+IBspQMGtAfqgwYH8xfxmCK0hxWEdCXPdrAbP/WkNWeJiT1f05vGmiJpBL+mV1jD4G6eUV1UA2UvUbaF/ur6KLtn2dP5tBnhVeq2u2XQVF4MIEjK25b3tfLALuib5B9UClYcVUWwbW2g8h6ot+uB/NcsO5isZqGlLO7vu4FsjHNik9aaxeWlqgFmxOxNI7RXptwFwQ= X-MS-TrafficTypeDiagnostic: MWHPR0501MB3867: X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3867; 20:BUMtKSuXwJLMVI8DLq306D9KplX63Xj+wlQtoEjmbQlS9ocOZLpT/sUepceW6FNkUeg3bPmys+LTB6e2Zs9a6z18L/1ODemDdgYw3/uUohEjgDvlaJV9tuRZ87NaluuFbdmkIsmRGnmVLzMMMhMLZpDraxD50OQT1y1Ak1vVn9t1rMmgvmA5mrFnkb8Yo1H0hts+0cGQb1aRFtdKgvZ8lJFSrui3zkyZixVXzl405lGtEX9+FZo0vNStbdKJ7+ShwwVc9bHinL8sicm9z2foKjFKuHLIFfosNtyQ0LtD5uHdmjUf9FIcP9Hz80dcAfY5cAYSxSUfr8UiBvLN1EOJMyhy0z2KQ+MA5IzQOcuGUZH+L5n91xmqV2dL0ze82Pd7+X18iwZLbhlkTZUAg5B4am7CZIESscP+lxoEkNb+d9itrLkZPTvAuKpM7sPCR6lEWIDDRPuYVpc1dy/zHW9wqxvapXnzlbcVVAP6B9a3QBP6V6aiux215jikFZW73Jz0WJXBIm9L1lqik83F+effAX5EKhP+HXZ5Kl7hroJuvAopmh8do5n7USwuftSm3nmrdzLeWKmBh1i9BYFKDE13Ty9dx0j3k8JiEd72dUkV/Wc=; 4:sR/14qEatF+M6iB/bLsf7VzMCLYkQY3sn2GLSla4LWt+xHA/lv35U2qQ8/mvtWOMUyIOqkAhc9Q512NPxjcKCO30CRmGF+g6lyNI5hMqtYekbQFJLTVzFIsJGX1g0sZ0DQZZOSejNFsymR7t+9B8RzNo9sysX8z01Sn2Qb9PlymKtcldrQVnuWOnkOgB5UwHR9hWB/vikT0njrfX12jMBu/Tlcgw8N8EEf9T6IhB7qlpOQOX83wBobtzoyqIibJ5UtoAz5rV4DajjZszRFHZpQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:MWHPR0501MB3867; BCL:0; PCL:0; RULEID:; SRVR:MWHPR0501MB3867; X-Forefront-PRVS: 0729050452 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(136003)(396003)(39860400002)(376002)(346002)(366004)(189003)(199004)(6666003)(47776003)(6246003)(25786009)(53936002)(3260700006)(50466002)(65956001)(93886005)(66066001)(65826007)(5660300001)(3846002)(58126008)(6116002)(316002)(2906002)(16576012)(68736007)(478600001)(65806001)(2870700001)(6486002)(8936002)(81166006)(81156014)(11346002)(16526019)(97736004)(64126003)(26005)(8676002)(229853002)(77096007)(31686004)(105586002)(86362001)(106356001)(446003)(486006)(476003)(956004)(2616005)(52116002)(76176011)(67846002)(23676004)(31696002)(305945005)(2486003)(52146003)(7736002)(386003)(36756003)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR0501MB3867; H:[172.29.35.4]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjA1MDFNQjM4Njc7MjM6aWpBUVlzekJJWkdCZ1VueGEwcWduYnBZ?= =?utf-8?B?Yit6anRrVS9WWFhJeHBjUzNhc3dJTDNrOHE3dHJhalU5NGplYnNOVGh4c0FQ?= =?utf-8?B?VTZvYXNUYlRTdmZ0dDk1bUh1bTNTL0R1aVN1OW1scjJsSkFrbzNUZWNOWGk1?= =?utf-8?B?bXY2QUVxOWRxRCsydDNLd0U0cnhuTUhVcVc5Y0J5UnNjT2R5b1NBVmRsOGRQ?= =?utf-8?B?NitPbTIyVjJxM040QXpsQlZuUVF6ZTZoMGZwYjBueHFQdkxnUjNldWxoTlhD?= =?utf-8?B?am42TXZFR09KZTVpM2k3a1lOZ25RZHRXL2U5eVl5NGJyeUU1blVBUE9UVW15?= =?utf-8?B?YWNJcXFCRnpta2NHcFZtcGpUMldRVXUyUnUrNUZWdU1KUXUxdkhwWm9YbmhB?= =?utf-8?B?T0JlLzhOWGJZVzQ0NU9teVJLUE5sTHp5Lzk5ZVE5RFdlanFlMWhBMktxRXVJ?= =?utf-8?B?dzFLVWNVQWl2NnhwWDY1S045SmNrSmppcjBvaTJZMHdmOHFLZGdmdFB3L1Nr?= =?utf-8?B?cStmcE1OcENGY0VUZUJTQkUyOWtjZlRHYjkvWmIzaFZWS1BQVGVYSmxzcTNJ?= =?utf-8?B?MnJrRUxySWxPY1pFY2QyTzd0ak0xbWVZeTVkc3JKQUtWRmxLZU02WHV1MFAw?= =?utf-8?B?VWNjVnMwaWtSSlp2aUR0aUpsZmRzcnFDZnY4TStuREJWQjFmM2FJQ2kxZ2hG?= =?utf-8?B?UTFBTDVsUjZMeDQ5NXB5REpZcVFuUVJiOWpIbW81TlVLTGppd0N1VjBpR0tr?= =?utf-8?B?RjRPOEw2MnVMTmdYWnJ0MXhscTdycDNuV2xEaW9hcjdXbnNaVlYvZEVSZTdj?= =?utf-8?B?cGZnSWVOM2liYXhYYzdIWWVyN2ZEQWFjcWYzK2I4NHR1Q1kraHV4d1VYRXR3?= =?utf-8?B?SHlGUEQxWGI1SEJlNWcwVytJemVRREN0MEx2R2pjY3FIWkJiOGtkL3IrZWxT?= =?utf-8?B?ZkF3K2xyRko2WEQwdVZsVzNLU0N4aHFKMFlBbEpocjYyWlJxTTZ3emV1b3RF?= =?utf-8?B?eEtaazFTN0V2cWcra1p6eWJSbmNBYWsyMFNkYmN6S3ladEE0cmt1SDRPWHI5?= =?utf-8?B?a3pPZGtENTd4VVpXNVZuTUJRMllra1RLN0hJZmZ2Si9ON29mY1RYK1JYZE5x?= =?utf-8?B?bHpIMlN1ZU1zSWFiUDlyUWlmdFhKbXlYalczMk1pV0JDOFJWNUs5aUVwc0F1?= =?utf-8?B?WVp6MWhWM0QvTi9WUHJ1OEhTUVYxUTUwZzVwWXd4Z3BhU0VwYXNXSHlHV2dv?= =?utf-8?B?ODlWNjl5VnBCY3h5RlBaakVJTFhHRjZoTlNYdFZkQWlCL0VDZmNJK29xVUR3?= =?utf-8?B?ekFBWHpFN0NGWjRCcHVoeVlSZW1GL2RoSCswMjZWUk9jWVdqYW1yRFJoQ0hR?= =?utf-8?B?dTVPTFJwVjR4Q1g4c1U4UHl1WCtiZjNZdjdGVDBZb1lYbnhhc1YrQTJEbFdt?= =?utf-8?B?aFA1VzhCY29RR2RyN2JqeWhLc0Y1WS9VcTFiUjV5dGpQYnVLbmhpbVpPMlVp?= =?utf-8?B?VG9LeFlZRTlCTnd5RXdhZUlMYmZFc1ZqMnFqdVNlVmo3UjI4T0NXV0pvUUow?= =?utf-8?B?bEVIVEM0TEN3UU42aVhRcG1YYVdpb3Nzbk1UTm9TZjBvMHErRU1uVTVmQzhn?= =?utf-8?B?MnJxanI0YkdSbE8zRE03bTNyQWFybTNJcC9uSnFlakREZ2JsdWtiZEFaY2sr?= =?utf-8?B?dDlxMW5CdUsvZ2FZc0ZWdmxIMmRVb0hITGllczIyNHRDb0JxSy9FM3VxZnBG?= =?utf-8?B?T1B2diszbVY4ZnVNY0NHRzI0aHo3eWRta08zT3cxS1lJTVNFUU1GV2xuTFpU?= =?utf-8?B?NWpVUDRENDFWY050cGduZ1A4YjBWUDZjS01QbUt2eDh5d0lWTy9hV3R3bS9U?= =?utf-8?B?LzVyNC9iT2RWYlJSSjZuWXRvc2w4c2VjNVlERFpPaDRlTVdyNnQwNkFGb1BD?= =?utf-8?B?OGtDdDRReXZKWGc9PQ==?= X-Microsoft-Antispam-Message-Info: tvjpqQOzKJEmYZCyDXwQS27Uz2ttms3/0AohQrKtc+fpbQTCoi2wIDoFc5T6j9g29Qo1o52SVwkhfGSvCgclByzcbpSObeoGQRRT6RxZRrHUN4GVcsYpb07WGeNErLz9YtfrN/cPuBky6ce8h5xKik823brK7MdjPYUVYBHMr/qWr6gfchdwNWmYg4TbYITXSFPCLw+GHYQNs9a1iuxSftwrUUWCO1yXercWDGFV/ddihc4l2y/koMTg6T9SaT0JzFqOlB/8BB9LdJR+xMh+xTa3XYsH2lfO8wQMGYabXf/N6OFAuVMcIFhzmupnGtnFsTeh2KAMsamq7AWDfpyNP9gJL+Ah2QoHZR8c8o2o3wk= X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3867; 6:QPFYgpcliiJJrbxcO1R8Z3ZSV30UpEjvjExun/LAr7el8GjsmQ/uRRaNO9TEtoWIH7zbDpxwoLaBQYj2ITnzWKRmkDYmBYmfgdOp/t+Fa3aFNr4AXuKNHApUHXD+jyhvyRNeDNIDeqx+6KiG9L77XYN0Q3wX6JPu0aQXW1oy3QNQI+NYhty9dSpwesG6ffsznBrhhtiQ+z3waKfST9BWrCtqcHHIaccJWhKgeIgwEV68fJ1dO8RKvNvx8SBFlm1yqidogAY3yGW3WTk/vKTTWDP8H8N1r0WjpyAojdLfuibFh57he7Kf76K6z1GPWJTKjt4r3n+731HGzuRAMItliQ74Qry25FJQUzdKOByueMZxaWT/Tj1zTqJx06BWG71eT87RSJPHBM9TAsce7fODEsabgO9rRfe47tiCEHgi4nHTMRw2cyL9trGz8ATfvv8a6dqbX0i/htkpH1/HthZG7Q==; 5:ADLcxKzSIuoQ/RBwNwYS0BjTEnx82bgd5xFcWZS+1CF0z5f099TGET15NnsS3LvUI+Wg2Dni2yywRb1b1riVeiyjIPwFYjQPYoMGx/quLA1kSZ35/dEpBmhEz360rpe5GSQBtDGxAh+RM0VRpnnrH8p87cWjItyyg4nkXjgYFxg=; 24:CH5NJaA8bap3Q3MC2TiPCYyJ2N5yPpT7DmfMXGfBDUy3UYlgR3TeiD+n9js9dtxqPdaxjM12PE6OvsElhth30SQC22ZqO4xmJADaPZwX2Eo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3867; 7:ljEk+5hYKLSjkgKBIir4PiwouGrTf/pwFbMZJ2E+a0qA7OuxPCjJGjGNQys3KT4MIIURatAUUD4/quIHjHhaVQssWgM1ROYLGwm/cR7xHgqAbT/xilNNY+REsu9AKrGK/OQBIoRcJyc69MJE2TgLREW67rSXP2SgRcl7E5qTBZIMOdg06MfIlO6MfGMe8osmRiTghA9qxgkOpBDGr0TJqY88YE3k9Q4+sBcbS9sW4N+gYLf2zvzIK4g/KZb1IgsO X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2018 19:58:51.7886 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9e86c636-d1a6-47cd-11c3-08d5e69f8f88 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0501MB3867 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-10_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807100212 Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 19:59:11 -0000 On 7/10/2018 3:28 PM, Andrew Sullivan wrote: > One thing we_do_ have some data about is the low regard in which the > RFC series is held in many academic contexts, because it is not > considered a peer reviewed publication and because it is often > considered a series for technical standards rather than for academic > research. If the IRTF determines that it would prefer a different publication venue, I certainly have no problem with that.  We shouldn't force researchers to publish their work as RFCs.  (I didn't think we did so, but ...)  If I were a researcher, I'd probably want to publish in a reputable academic journal, but perhaps my academic experience is a bit dated. But that's really irrelevant to the main topic of this discussion. What we are primarily discussing is whether we should prohibit folks from publishing RFCs when they want to do so and find it valuable to do so.  That's a completely different question. From nobody Tue Jul 10 13:04:02 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2D413104C for ; Tue, 10 Jul 2018 13:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=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 dzlFIrl8Flrv for ; Tue, 10 Jul 2018 13:03:57 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8C9130F2C for ; Tue, 10 Jul 2018 13:03:57 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id s14-v6so9118997ybp.13 for ; Tue, 10 Jul 2018 13:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FtSLY8oReLR7Jl7pY0ZvlNpMzhWNp6xbP2l+jiKSF+M=; b=0s5y+tj4paShaD0GXcwCXUnccI/bkOBcL+pZIScSUaXU2vkhPOjXfPEIcRjD3obQ7P 1YOkVJp4ywf4xPka8rteFVsPbV49w8C/ya5fKyHYEBFoPy2witT94KI+bvtTdXk6N3P6 8CIzOBUFML//GRJ166gU1w4oEtnfHsjXXdGx3bE4GxG7FTU0g43ehumqWhW3k4HRCy4+ yFvPdpEjNXQT558+KedTt3p1UzHPq5N8998nG/xEHvbWKd8JdXyRBHy2F+w+ne5D7gGp A0sLSJ97sklJBDId9qgOxaHhjSnBu7bBZU7uqzrgPO1betL0hvppgV7jgR3jZqwY7VpX A6dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FtSLY8oReLR7Jl7pY0ZvlNpMzhWNp6xbP2l+jiKSF+M=; b=FdjETK7/1WA2cD+hyjDSkdYT5wmdHwyfog6+qDyQYL/7oTj1da+aLDt6m/R6AZMYBX Sm1IKZNO6g4IeBFAULr7OHYdHHbJ7+/acm12ddpbc5akrebz0MqJWYmSY9zh1XTEOaMv AXQentxY01Lrg3gwBehN0rBjePJtJuKY7YwPQ3hD1bIbCeHC5xZPUqkKWuW5sg9T3Uit QtGlg1I3CXDpVka+z1nmhROb7hcjGwSjLbmM47MWlaq39gOWlZo5xfw0nv0KO39I9bkm CeMCdxj8vVaYxSJCzI6qJ4Q5TR70cedbI04Wgh3B3bX0zXVMbIEvpZjdq5R32e+CdfRU f4IA== X-Gm-Message-State: APt69E357GpMM82ugCgX8ZJuDDYie2u/FAIoQU8dfh3zQMi6gG+91+kK 7OZH6UKSajVzjE3/JhTa0uMNyaCqL4CMbPDHd+yKAQ== X-Google-Smtp-Source: AAOMgpd73oClXjpm2eThHKoNJdCPSqHgrd5q1Qpgj1osn1AF7cUfiz9MlAWLLxUwtJjawuM+488VNSoJQR8idF9JRiU= X-Received: by 2002:a25:32c1:: with SMTP id y184-v6mr14014196yby.168.1531253036812; Tue, 10 Jul 2018 13:03:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 13:03:16 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 10 Jul 2018 13:03:16 -0700 Message-ID: To: Ted Hardie Cc: Eliot Lear , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000052293c0570aaa1d9" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 20:04:01 -0000 --00000000000052293c0570aaa1d9 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 10:13 AM, Ted Hardie wrote: > On Mon, Jul 9, 2018 at 2:14 PM, Eliot Lear wrote: > >> As to voices, one of the perhaps lost aspects of RFCs is that Jon always >> encouraged dissenting views on important topics to be published, so long as >> they were well reasoned and reasonably well written. Personally I'd like >> to see more dissenting views coming out of independent submissions. I know >> I have quite a few to share ;-) I offer that only in as much as having a >> few dissenting views might make clear that we really do speak with multiple >> voices. >> > I personally don't think the dissenting opinions are fewer now, but fewer > of them are expressed in RFCs. The critiques and dissents come, as Eric > mentioned, in other series or other forms. > It's perhaps worthwhile to distinguish between a number of different types of this kind of meta-RFC material. Here's a non-exhaustive list - Alternate proposals that didn't get accepted - "Inside" critiques (some of the examples Eliot gave) - "Outside" critiques - Academic papers on a given protocol (e.g., the examples I gave for TLS 1.3) In my experience, the first two of these often get published as RFCs, but sometimes don't (though not always, see https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529). Conversely the last two almost never appear as RFCs. Critiques are typically blog posts, twitter, etc., with academic papers appearing in journals, conferences, etc. -Ekr > Anyway, I won't be in Montreal, so here's my own bottom line: if the IAB >> are serious about actually using different labels, ask yourselves what the >> plan is to make those new series successful. How will the new series be >> promoted? What will you attract readership? And what will the rules of >> the road be for the series? If you do not have a plan, then let's not be >> under any illusions that the new series will be successful. >> >> I think you're quite right that making a successful change of this type > will take work, and that promoting the output of the different streams will > be part of that work. What's been interesting for me is that the thought > of how different the audiences are for that promotion. Reaching the folks > who need to understand what the IRTF's output is and means is a very > different enterprise than reaching those who might need to understand what > the Internet Architecture Board has to say. Given the acronym overload > there, a portion of that has to be making sure which IAB is talking, an > impact that the IAB or ISE would not feel. But I think that actually > illustrates the problem folks have brought forward here: if we were > promoting these voices, we would do so at least partly to very different > audiences. That's may be an important signal. > > Ted > > > >> Eliot >> >> On 09.07.18 17:24, Ted Hardie wrote: >> >> In a different thread, Eric made a statement about the RFC Series being >> in conversation with other publications: >> >> The RFC series (and also I-Ds) have an important role to play here, but >>> it also exists in conversation with a lot of other publication venues, and >>> I think that's healthy. >>> >> >> While I agree with him, I think the metaphor of "conversation" is even >> more useful in describing both the current series and the question before >> us. From my personal perspective, the primary reason we use "RFC" as a >> series identifier is to identify a specific set of technical documents as >> part of a common "conversation". The adoption of the term and series by >> the IETF was a signal about the conversation their documents were to be >> part of; choosing a different document series (like ANSI, ISO, or minting >> a new one) would have sent a signal about a different technical community >> with whom the IETF was in dialog. >> >> When the idea of different streams and stream managers gelled, we kept >> the same series identifier for all of them. I think, personally, we did >> that because we wanted to be clear that all of the documents continued to >> be part of a larger conversation about the development of Internet >> technologies. >> >> One way to understand the problem motivating this BoF is also through the >> metaphor of conversation: many outside the community simply don't recognize >> that there are multiple voices inside that conversation. They see all of >> the documents as utterances by a single, somewhat nebulous group. That can >> cause problems. Among those named earlier were the academic community's >> failure to value the output of the IRTF; vendors or customers not >> distinguishing consensus output from proprietary alternatives; and even a >> few efforts to get rejected ideas to appear to have been accepted ones. >> >> The question before us could be cast as: is it more important now to >> highlight the different voices that the streams and statuses currently >> convey, so that others understand them as disctinct? >> >> As Eric points out, there are other ways to maintain a conversation among >> different groups than to make their output part of a single series. There >> are also other ways we could try to make sure that we highlight that >> distinction more fully (using STD numbers for all IETF standards documents, >> for example, from proposed standard onward). But I think this is the core >> of the tension, shorn of discussion of brand or history: how to we get to >> the right balance of maintaining the conversation while improving the >> understanding that these are individual voices within it? >> >> My thoughts as individual, >> >> regards, >> >> Ted >> >> >> _______________________________________________ >> Rfcplusplus mailing listRfcplusplus@ietf.orghttps://www.ietf..org/mailman/listinfo/rfcplusplus >> >> >> > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > > --00000000000052293c0570aaa1d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 10, 2018 at 10:13 AM, Ted Hardie <ted.ietf@gmail.com&= gt; wrote:
On Mon, Jul 9, 2018 at 2:14 PM, Eliot Lear <lear@cisco.com= > wrote:
=20 =20 =20

As to voices, one of the perhaps lost aspects of RFCs is that Jon always encouraged dissenting views on important topics to be published, so long as they were well reasoned and reasonably well written.=C2=A0 Personally I'd like to see more dissenting views c= oming out of independent submissions.=C2=A0 I know I have quite a few to share ;-)=C2=A0 I offer that only in as much as having a few dissenti= ng views might make clear that we really do speak with multiple voices.

I personally don't = think the dissenting opinions are fewer now, but fewer of them are expresse= d in RFCs.=C2=A0 The critiques and dissents come, as Eric mentioned, in oth= er series or other forms.

=
It's perhaps worthwhile to distinguish between a number of d= ifferent types of this kind of meta-RFC material. Here's a non-exhausti= ve list

- Alternate proposals that didn't get = accepted
- "Inside" critiques (some of the examples Eli= ot gave)
- "Outside" critiques
- Academic= papers on a given protocol (e.g., the examples I gave for TLS 1.3)

In my experience, the first two of these often get pu= blished as RFCs, but sometimes don't (though not always, see https:= //hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529). Converse= ly the last two almost never appear as RFCs. Critiques are typically blog p= osts, twitter, etc., with academic papers appearing in journals, conference= s, etc.

-Ekr


Anyway, I won't be in Montreal, so here's my own bottom line= :=C2=A0 if the IAB are serious about actually using different labels, ask yourselves what the plan is to make those new series successful.=C2= =A0 How will the new series be promoted?=C2=A0 What will you attract readership?=C2=A0 And what will the rules of the road be for the series?=C2=A0 If you do not have a plan, then let's not be under = any illusions that the new series will be successful.

I think you're quite right th= at making a successful change of this type will take work, and that promoti= ng the output of the different streams will be part of that work.=C2=A0 Wha= t's been interesting for me is that the thought of how different the au= diences are for that promotion.=C2=A0 Reaching the folks who need to unders= tand what the IRTF's output is and means is a very different enterprise= than reaching those who might need to understand what the Internet Archite= cture Board has to say.=C2=A0 Given the acronym overload there, a portion o= f that has to be making sure which IAB is talking, an impact that the IAB o= r ISE would not feel.=C2=A0=C2=A0=C2=A0 But I think that actually illustrat= es the problem folks have brought forward here:=C2=A0 if we were promoting = these voices, we would do so at least partly to very different audiences.= =C2=A0 That's may be an important signal.

Ted<= br>

=C2=A0

Eliot


On 09.07.18 17:24, Ted Hardie wrote:
=20
In a different thread, Eric made a statement about the RFC Series being in conversation with other publications:

The RFC series = (and also I-Ds) have an important role to play here, but it also exists in conversation with a lot of other publication venues, and I think that's healthy.

While I agree with him, I think the metaphor of "conversation" is even more useful in describing both t= he current series and the question before us.=C2=A0 From my personal perspective, the primary reason we use "RFC" as a serie= s identifier is to identify a specific set of technical documents as part of a common "conversation".=C2=A0 The= adoption of the term and series by the IETF was a signal about the conversation their documents were to be part of; choosing a different document=C2=A0 series (like ANSI, ISO, or minting a new one) would have sent a signal about a different technical community with whom the IETF was in dialog.=C2=A0

When the idea of different streams and stream managers gelled, we kept the same series identifier for all of them.=C2=A0= I think, personally, we did that because we wanted to be clear that all of the documents continued to be part of a larger conversation about the development of Internet technologies.

One way to understand the problem motivating this BoF is also through the metaphor of conversation: many outside the community simply don't recognize that there are multiple voices inside that conversation.=C2=A0 They see all of the documents as utterances by a single, somewhat nebulous group.=C2= =A0 That can cause problems.=C2=A0 Among those named earlier were the academic community's failure to value the output of the IRTF; vendors or customers not distinguishing consensus output from proprietary alternatives; and even a few efforts to get rejected ideas to appear to have been accepted ones.

The question before us could be cast as:=C2=A0 is it more important now to highlight the different voices that the streams and statuses currently convey, so that others understand them as disctinct?=C2=A0

As Eric points out, there are other ways to maintain a conversation among different groups than to make their output part of a single series.=C2=A0 There are also other ways we could try to make sure that we highlight that distinction more fully (using STD numbers for all IETF standards documents, for example, from proposed standard onward).=C2=A0 But I think this i= s the core of the tension, shorn of discussion of brand or history:=C2=A0 how to we get to the right balance of maintaining the conversation while improving the understanding that these are individual voices within it?

My thoughts as individual,

regards,

Ted


__________________________________=
_____________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf..org/mailman/l=
istinfo/rfcplusplus



_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus


--00000000000052293c0570aaa1d9-- From nobody Tue Jul 10 13:09:55 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D101130FCD for ; Tue, 10 Jul 2018 13:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 rmOVWL5lTHEK for ; Tue, 10 Jul 2018 13:09:51 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 3CA551311AC for ; Tue, 10 Jul 2018 13:09:50 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id q11-v6so19481722oic.12 for ; Tue, 10 Jul 2018 13:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qP/dGzHvPla1Qrw6iUiFwX2yfgAJZfS26UYc/Ajz+Aw=; b=iWZb1dCJPgH2PMUptPKPqPXWCUoZOhfWxc8iZENIrvMfsoxYxgdBzhHmxULIT03d05 7A8fnVT19ecAgiyhq4thtN3g+dRdkLlS7h5RMiqb19IKlqjC0iaVdazPgdLdmzyfa1ic g+VKeyUF3T+g7Hm5K1VgSD1zRIc/PEpzpKJS46nNpwjxgPYVYHtrEgmt8KVVLBiwXEsr 6zAlwASfeVa5TzLULBx9HWoEVEmkmVpLNuOYnvT6rv99/QHlfsWLHMiCpHSavrG9FZW/ pUMcYo7sMfnmG7hTkh0GKIMLyc80cB/8AfM0o9vAJ9a1AgL8mc5xNweFTznESFGWg36p XQLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qP/dGzHvPla1Qrw6iUiFwX2yfgAJZfS26UYc/Ajz+Aw=; b=ezpyIBZjVU1p/fvsh1botnEQ0wz0sBePwIoZ2MYzJFnVm7wcxi6EGHOxBG34VVqWCX qsr9g6Rmvs8N4hadMGaz3fQiwAZohTgU3TL2GSx+vPjjjPHgXFpFf2dPhCXnkjHGQegc DXpY6Xc+HJYvMly/NRzuvOePSHPy7St2UGqiMTv59ubsFBrHQqRhgCmcPhGrCFbOvR7l s8d7Csg/IZGHPCMHLixY0+ibZzVbSlNqh7u0Qen4qK/t5/55neEwF8S99tFizsXRmO+1 ua7gfeLij5YmmJNL1VphrrVLvJE4jh0ffXuEjdO2cKOAmqJa/vXWeTVB23pR+h1oU19p l2/A== X-Gm-Message-State: APt69E0jZ3biRQLrMadsLnxW9uVsk8Y3SYnR7RSp6zJalX/WmxGxhnJW LYYEGob8foNLbyHC5KZ11aXZMcTNpkXnqqD59+k= X-Google-Smtp-Source: AAOMgpfdgvL4AJSzYrvtn5sUOmLfK5cQkXrF8qBH+IRYLLRhL14nD1n1r8CZZRqIbQdGgZdXLKXEULvgaKlIYtlLeCQ= X-Received: by 2002:aca:6287:: with SMTP id w129-v6mr31372171oib.122.1531253389463; Tue, 10 Jul 2018 13:09:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 13:09:18 -0700 (PDT) In-Reply-To: <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> From: Ted Hardie Date: Tue, 10 Jul 2018 13:09:18 -0700 Message-ID: To: Eric C Rosen Cc: Andrew Sullivan , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000005714cd0570aab6b4" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 20:09:54 -0000 --0000000000005714cd0570aab6b4 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 12:58 PM, Eric C Rosen wrote: > > If the IRTF determines that it would prefer a different publication venue, > I certainly have no problem with that. We shouldn't force researchers to > publish their work as RFCs. (I didn't think we did so, but ...) If I were > a researcher, I'd probably want to publish in a reputable academic journal, > but perhaps my academic experience is a bit dated. > > But that's really irrelevant to the main topic of this discussion. What we > are primarily discussing is whether we should prohibit folks from > publishing RFCs when they want to do so and find it valuable to do so. > That's a completely different question. > > I must respectfully disagree that this is an irrelevant question. The proposed experiment would establish new identifiers for the work of the IRTF currently published as a stream within the RFC series. That output might (and I acknowledge again that it is only "might") change the academic assessment of that output while retaining its other characteristics. I personally believe this question is thus on topic for a discussion of the experiment. regards, Ted --0000000000005714cd0570aab6b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 10, 2018 at 12:58 PM, Eric C Rosen <erosen= @juniper.net> wrote:

If the IRTF determines that it would prefer a different publication venue, = I certainly have no problem with that.=C2=A0 We shouldn't force researc= hers to publish their work as RFCs.=C2=A0 (I didn't think we did so, bu= t ...)=C2=A0 If I were a researcher, I'd probably want to publish in a = reputable academic journal, but perhaps my academic experience is a bit dat= ed.

But that's really irrelevant to the main topic of this discussion. What= we are primarily discussing is whether we should prohibit folks from publi= shing RFCs when they want to do so and find it valuable to do so.=C2=A0 Tha= t's a completely different question.


I must respectfully d= isagree that this is an irrelevant question.=C2=A0 The proposed experiment = would establish new identifiers for the work of the IRTF currently publishe= d as a stream within the RFC series.=C2=A0 That output might (and I acknowl= edge again that it is only "might") change the academic assessmen= t of that output while retaining its other characteristics.=C2=A0 I persona= lly believe this question is thus on topic for a discussion of the experime= nt.

regards,

Ted
--0000000000005714cd0570aab6b4-- From nobody Tue Jul 10 13:12:01 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AED13104C for ; Tue, 10 Jul 2018 13:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 UG_isqnTozZl for ; Tue, 10 Jul 2018 13:11:57 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44623130FCD for ; Tue, 10 Jul 2018 13:11:57 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id a7-v6so8094835plp.3 for ; Tue, 10 Jul 2018 13:11:57 -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=7c/O7VHtgb6/jhCQ6um/KysWS3hQqgPUcEWhre31lM8=; b=fd8lUO+LebYt4ggta+CpRR+i6RfY4z18DmDjxTu9cV8aW70/+8y9ExX+tK6OB2+gIt aU5ladtFakNK3jZ9hNDZYqBrl2pnWdbzBL/d28E/CSgrId874RHFSODmI83wOEPZNtdR NOqrBosemeF/EmrJELtX4l+q256p1MnbuLCRibKfXjzcI/Q08tRtgUNAweu28ovFni6g EDrXQSC0iyfKaPZB5yFKk5pfK+1ZyNfcb0Qqfffep9VZ07+s/73RL/97jHObcAEN62x5 8it/Qlryub1233KYNo31HIj9rJ09Te3i6OPNwmlU1tRH20my+xFJvHsB0JwsEueE+5pC FnTA== 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=7c/O7VHtgb6/jhCQ6um/KysWS3hQqgPUcEWhre31lM8=; b=uKgfWZ7TcAszLnNXmOPP8VtDuy4Fvt1zER8k2xpeFSeXpst0Sj7aTPz3UZW3cQMLmI upOLxR/bMVhs99PHQAnw76Poj4S7a6fa3s3QzOUm9u1C7c9Bqj/nxeeT3GEiXoybYrQ7 p+pAe2thrW/mMutYe5YtRTZ1/AZWvICfnRc7n2NQmyHDgnwgUcnlBhQ641GUdh1C9LeR dVkU36QqwEvCijp6cX7AXdL/LTIUHBotT1KsdRrWU9OBrkzDlrCVrTLhzS1pUvGhG11Z +q3LlSxUfwQ7meG/RguFJo3SplrHC5RgMFYPyzYJpkQoLeDJ8MLZreKupen2orNeKtVH a2mA== X-Gm-Message-State: APt69E2JHvKgSI43E1yoaVhusCFfcRyco8Wtuz7LZdQ3FwK1+FT5STex xsS0xpQ1pMzsb15uo1A/rCw= X-Google-Smtp-Source: AAOMgpcTi00SgqAdPbTijfjAq5kjnS0DiMLMk3TFC/ujneKU0T26xo2Ezb8/tY+T1Jhdne+vnNvbiA== X-Received: by 2002:a17:902:8607:: with SMTP id f7-v6mr26170517plo.138.1531253516840; Tue, 10 Jul 2018 13:11:56 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id s12-v6sm27952398pfm.41.2018.07.10.13.11.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 13:11:56 -0700 (PDT) From: Bob Hinden Message-Id: <639B8766-A030-490D-8431-C3F9F3EAFCB4@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B61330EC-BCE9-42BA-8FC2-4F9A9254D7A7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 10 Jul 2018 13:11:54 -0700 In-Reply-To: Cc: Bob Hinden , "Joel M. Halpern" , rfcplusplus@ietf.org To: Richard Barnes References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 20:11:59 -0000 --Apple-Mail=_B61330EC-BCE9-42BA-8FC2-4F9A9254D7A7 Content-Type: multipart/alternative; boundary="Apple-Mail=_670BD445-7024-446C-9693-CAACE6FFADD8" --Apple-Mail=_670BD445-7024-446C-9693-CAACE6FFADD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Richard, > On Jul 10, 2018, at 7:21 AM, Richard Barnes wrote: >=20 >=20 >=20 > On Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern > wrote: > This formulation assumes that change does not have a cost. It does. = I > agree that not changing has some cost. However, absent indication = that > the changes will actually address the claimed problem... >=20 > People are presenting indications. Attach what caveats you need to my = little study; it's still real data from a relevant population. Do you = have better data? When I saw the survey, after I filled it in, I noticed that I could do = it again. There didn=E2=80=99t appear to be a mechanism to keep anyone = from taking it multiple times. Based on this, I don=E2=80=99t think = one can draw any conclusions. Bob --Apple-Mail=_670BD445-7024-446C-9693-CAACE6FFADD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Richard,

On Jul 10, 2018, at 7:21 AM, = Richard Barnes <rlb@ipv.sx> wrote:



On Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern = <jmh@joelhalpern.com> wrote:
This formulation = assumes that change does not have a cost.  It does.  I
agree that not changing has some cost.  However, absent indication = that
the changes will actually address the claimed = problem...

People are presenting indications.  Attach what caveats = you need to my little study; it's still real data from a relevant = population.  Do you have better data?


When I saw the survey, after = I filled it in, I noticed that I could do it again. There didn=E2=80=99t = appear to be a mechanism to keep anyone from taking it multiple times. =   Based on this, I don=E2=80=99t think one can draw any = conclusions.

Bob


= --Apple-Mail=_670BD445-7024-446C-9693-CAACE6FFADD8-- --Apple-Mail=_B61330EC-BCE9-42BA-8FC2-4F9A9254D7A7 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAltFEwoACgkQrut0EXfn u6jzsAf+OjG9sfvMT8YX0gZsA1CDtwiUq1Jda4akm06ux+lzq6F2eNOQlytbcb/G c4dhHirIuw7XP6WhfzGgfq8pIkdLRV99NeBjZw1+LmlfWuUNDdDph5xbPAa37SeK +vhz1gHR701uebux9e+hrOlf50dwvNa+s1EjBgHjV31dYAbDIbPLULBL+6KTm2dL KQAF3dgouHAxl26j/qb4ZK1q4fGgZICVGPMTYCB8CpTjPm4cAIE/UhnU0oidMGqG LbNPwuwirbM0pC8WzzJ5X8rO7Gn9niz2tMxKJTvT4k7oxD5MuqBvqC870a24Zt/+ R3tV14FWVA6rp2VxQoHAMCwJyRLEuw== =Enok -----END PGP SIGNATURE----- --Apple-Mail=_B61330EC-BCE9-42BA-8FC2-4F9A9254D7A7-- From nobody Tue Jul 10 13:23:51 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0716130E73 for ; Tue, 10 Jul 2018 13:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 jHOI6zlXrCz3 for ; Tue, 10 Jul 2018 13:23:46 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342621311B5 for ; Tue, 10 Jul 2018 13:23:45 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id m13-v6so19528911qth.1 for ; Tue, 10 Jul 2018 13:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=ZLo5WzyvMTBn+n9wWHvP2aHCZFe4FtQfIJNePvWf7Q4=; b=m+H80dbo2ahfSvyXgc/Azuf/4rxQ3wIu1Mg/9PG3hQDeKfSXR56mBqUuBAY+DCTeso hFpEsnqafqHFUGh69eVoDo0ObnQIMD9PM8eBFyQ2crvpnIx+W3hEuNY/RFPrdvdR4tgf wcrWc/EyupNukH6jO28HzKfOqQVu9tyRZkOen3wCGIGn/AhQm9qawsjnPGfSjdy0BgJX ABJU1O2FJbIeZnzEgyrTt/caYZCsg/+mNFGqjLnGnPLSO+P4UjV2LUOlgcjrkkATMfR1 Sq/eeSSB9qyJWKOTwFJuHIQEpU+D2R6QkdaWL5RfzQ/9MsSE5GgTl+48ewrJ5o9bbVy8 7+uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=ZLo5WzyvMTBn+n9wWHvP2aHCZFe4FtQfIJNePvWf7Q4=; b=lUBeTLVNGKIQdtqaU5IJWxyrDXbJhbIaHOrtdvm/9SY96A3oi20gBcdFK3lV5w/WXn gFovGwAyByhdml7LrjW2qhuxWD9IxjbaR6xofn5fe7qADsB/5XZ5miZojakpnxGdmGFP AzzsHfH/v53Xk3b+WiU0iTUkCXO3KFkRz2SbWW9Z0MmYaqqtblMWqnTJKhiTiJiFhtnU prABkeD4BWxkyFCrp0YFSh9xZ+70YUUU3zaQm/blcVgBqeCSNin0k6LuzeK6apyg98d4 NJvlE7LR/wJIJbuFhip2j7ylguGHs7zQjv7fgXT8Ldlpj7PEriOi/43SDK6cItA8ndtm mI9w== X-Gm-Message-State: APt69E1bp0Z15f45DwanudmLkZl2p1AY0INDZKFNMbrUWkQhm0FuKslk +bYOtkJsXgWA/ankz4iRauE= X-Google-Smtp-Source: AAOMgpcoz3O6CJVfh2XGIrTyYIWy9jwZuvRtIJ3y2ObeFgRQTr56D62yBNJow5Z5wHvqwLk5enTR/A== X-Received: by 2002:aed:2317:: with SMTP id h23-v6mr24134965qtc.85.1531254224919; Tue, 10 Jul 2018 13:23:44 -0700 (PDT) Received: from [172.19.33.154] ([2001:4878:a000:3000:f826:7a2c:984c:1004]) by smtp.gmail.com with ESMTPSA id p13-v6sm14108685qki.12.2018.07.10.13.23.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 13:23:44 -0700 (PDT) From: "Aaron Falk" To: "Ted Hardie" Cc: "Eric C Rosen" , rfcplusplus@ietf.org, "Andrew Sullivan" Date: Tue, 10 Jul 2018 16:23:42 -0400 X-Mailer: MailMate (1.11.2r5507) Message-ID: <1F7626CA-FB10-402A-BCF3-EA89526AC63C@gmail.com> In-Reply-To: References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_8E9775E6-1377-477F-908B-43E88A199413_=" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 20:23:50 -0000 --=_MailMate_8E9775E6-1377-477F-908B-43E88A199413_= Content-Type: text/plain; format=flowed On 10 Jul 2018, at 16:09, Ted Hardie wrote: > On Tue, Jul 10, 2018 at 12:58 PM, Eric C Rosen > wrote: > >> >> If the IRTF determines that it would prefer a different publication >> venue, >> I certainly have no problem with that. We shouldn't force >> researchers to >> publish their work as RFCs. (I didn't think we did so, but ...) If >> I were >> a researcher, I'd probably want to publish in a reputable academic >> journal, >> but perhaps my academic experience is a bit dated. >> >> But that's really irrelevant to the main topic of this discussion. >> What we >> are primarily discussing is whether we should prohibit folks from >> publishing RFCs when they want to do so and find it valuable to do >> so. >> That's a completely different question. >> >> > I must respectfully disagree that this is an irrelevant question. The > proposed experiment would establish new identifiers for the work of > the > IRTF currently published as a stream within the RFC series. That > output > might (and I acknowledge again that it is only "might") change the > academic > assessment of that output while retaining its other characteristics. > I > personally believe this question is thus on topic for a discussion of > the > experiment. As the IRTF chair when this stream was formalized I should point out that an important reason for RGs to publish RFCs is the same reason that they are RGs in the first place: to have their work be adjacent, influence, and possibly migrate to the IETF. Of course, that is not the only reason we have RGs but it is a good reason to have non-standards track output in similar format & repositories as the IETF. IIRC, the copyrights for IRTF stream RFCs default to permit publication elsewhere to allow for easy submission in more-recognized forums. Finally, I haven't seen anyone present that helping IRTF output get more recognition is a goal of this activity. Is someone asking for this? --aaron --=_MailMate_8E9775E6-1377-477F-908B-43E88A199413_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= br>

On 10 Jul 2018, at 16:09, Ted Hardie wrote:

On Tue, Jul 10, 2018 at 12:58 PM, E= ric C Rosen <erosen@juniper.net> wrote:

If the IRTF= determines that it would prefer a different publication venue,
I certainly have no problem with that. We shouldn't force researchers to=
publish their work as RFCs. (I didn't think we did so, but ...) If I we= re
a researcher, I'd probably want to publish in a reputable academic journa= l,
but perhaps my academic experience is a bit dated.

But that's really irrelevant to the main topic of this discussion. What w= e
are primarily discussing is whether we should prohibit folks from
publishing RFCs when they want to do so and find it valuable to do so. That's a completely different question.

I must respectfully disagree that this is an= irrelevant question. The
proposed experiment would establish new identifiers for the work of the IRTF currently published as a stream within the RFC series. That output<= br> might (and I acknowledge again that it is only "might") change the academ= ic
assessment of that output while retaining its other characteristics. I personally believe this question is thus on topic for a discussion of the=
experiment.

As the IRTF chair when this stream was forma= lized I should point out that an important reason for RGs to publish RFCs= is the same reason that they are RGs in the first place: to have their w= ork be adjacent, influence, and possibly migrate to the IETF. Of course, = that is not the only reason we have RGs but it is a good reason to have n= on-standards track output in similar format & repositories as the IET= F.

IIRC, the copyrights for IRTF stream RFCs default to perm= it publication elsewhere to allow for easy submission in more-recognized = forums.

Finally, I haven't seen anyone present that helping IRTF = output get more recognition is a goal of this activity. Is someone askin= g for this?

--aaron

--=_MailMate_8E9775E6-1377-477F-908B-43E88A199413_=-- From nobody Tue Jul 10 13:45:23 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488041310DC for ; Tue, 10 Jul 2018 13:45:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yitter.info header.b=aB/ziKsl; dkim=pass (1024-bit key) header.d=yitter.info header.b=JpL7a3Pa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KiVSqLfOqvS for ; Tue, 10 Jul 2018 13:45:18 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E05130E35 for ; Tue, 10 Jul 2018 13:45:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id DDF27BEBEB for ; Tue, 10 Jul 2018 20:45:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1531255515; bh=udRVV9pSFNBiYs8rVQTFUwhpL1aQsrVPymckxLnqCoc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=aB/ziKsl6phK15tQRPKQWiLvsPf2nylXJR9zvdRU+joyi2UJq4waEQcxAsRlENa0O yYYKFFfB0WTBrqKTbpt2pG56OpUeWefhrUUBZc/f1SXCpGL8j2MS+cjVeHH3sCBWOB LGLri6ZJ7Y1VPkP4mzYmNxPKxDxXdG2H6ntQfhj8= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAaWOtqLNre4 for ; Tue, 10 Jul 2018 20:45:14 +0000 (UTC) Date: Tue, 10 Jul 2018 16:45:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1531255514; bh=udRVV9pSFNBiYs8rVQTFUwhpL1aQsrVPymckxLnqCoc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=JpL7a3PaQkRSaQpfegSsBc/DbUGCizFN3PWqPbqqsKIKJylsc6WZuiSlDrs6XyHBr DnC4O5bUKWOQly4GHFBN/39Fwcyfw/ChUDs8lLkyT5TsXGfbE6gQdioy4yk8+clspN JaryslAMNoEY7SFnOSaVr0AAgaUX0gQ0bSaaT5eA= From: Andrew Sullivan To: rfcplusplus@ietf.org Message-ID: <20180710204512.GT20282@mx4.yitter.info> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 20:45:21 -0000 On Tue, Jul 10, 2018 at 03:58:47PM -0400, Eric C Rosen wrote: > certainly have no problem with that.  We shouldn't force researchers to > publish their work as RFCs.  (I didn't think we did so, but ...) Indeed. > But that's really irrelevant to the main topic of this discussion. What we > are primarily discussing is whether we should prohibit folks from publishing > RFCs when they want to do so and find it valuable to do so.  That's a > completely different question. It's a distinct question, but (as Ted argued) I think it's still on-topic. But I think your way of describing this issue has a certain merit, because you are in effect asserting that there is no benefit to the Internet community in having a gateway function to the RFC series. One proposed such gateway is IETF consensus, and the argument for that is that some significant population of people seem to believe already that the IETF is who is responsible for RFCs (see the remark I posted yesterday about Googling this). So, the argument goes, we should align what we claim with the way things are on the Internet, just as we might do in the case of our own protocols. Others seem to be arguing that the RFC series should in fact welcome anything on any topic, and as long as they can find someone willing to let them in, there's no reason they shouldn't be in the RFC series too (i.e. we shouldn't prohibit people "from publishing RFCs when they want to do so and find it valuable to do so"). It is an interesting question whether, if I wanted to publish an RFC about Wittgenstein's remarks on colour, whether the ISE would consider it. We do have the April 1st ones, after all. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jul 10 13:56:43 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA19D131157 for ; Tue, 10 Jul 2018 13:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avvd9e4bYlmb for ; Tue, 10 Jul 2018 13:56:31 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8C31310E2 for ; Tue, 10 Jul 2018 13:56:31 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id q11-v6so19730472oic.12 for ; Tue, 10 Jul 2018 13:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cJ3Q6fpXG0AMahV8uqHyiKVingguECjPir01LWVac9E=; b=G9GyE38EgFpXOmA511mh6GoYkRVi4PmAcsc/PeVOVrMvsng/5Jp3TL0VEoQKRe/dpu +HAuBlJL72dYKERs0jiQ+ZkrFQXnR/3JQiLKT/UF+PGlzh7xLeaJT9msRWX8lqi6Ihau RcM6hFaC33Avqs7Rkywru46oZpY9HWh71z8IGQ3RWkBRAHW8LdtI/UCPCx72urHHEPD3 VihPpJAxdbimzTqAeJZbNqEqP0Lr5GBZMy/7TAIkaAX+LkOnj5LcjqEz95BbTakFw6F9 su6JzsDRZiBBSKzfeJvaex75K7aDvTVYuGZl7tzmG1wqYkIdrZjgOqMrlOGOS6JLb8UM A4bQ== 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=cJ3Q6fpXG0AMahV8uqHyiKVingguECjPir01LWVac9E=; b=F96cVM/9TY9qcS+bL9SiXwn+cDVhC+XZc6EXpTaVp84s8WMQ+lRR+2MxxdbiqYTqrd enZK41NU0zZMeFBLrlotyL8fPFJ9zF0EOjwtPrh4yh4URIimXnHis3p9dYiprsjyqzQa 84YumRoPt2YJ4StxmCgZcGkUvGoT/NrxAfBJ4+e8bcXsTIZ87Ry2c8tCGu5t3X9Bh7nQ XcY3Xb1SXDgWC35NXv9WtjiO5DqTn1x2fPZF8BnYdik7lxlg8e5qQbMtTdgWzz5w4sFe H2l2qLLXgnU8W0vkLnP70Nn9PjI6qtgmNkMn1e2dFaNfM1dT3VS9XY/dFCfVLBHflBs8 gQmQ== X-Gm-Message-State: APt69E2sw8RdYvda614rhLbWwNFKbvLQ0yNsczTUF9HchIUdb2mWPRwL bvwajcrAn9WN6w7C9FkEwZNKTrGoKBZBsh1HtJ8AshEl X-Google-Smtp-Source: AAOMgpd65EZychNgRmxKWaIetcH0CTh61lMHZoUqMP2mmVZ3mpJUmzsNqMnAVTGGxdO1a8Y16AJ2neGMswlw662Znmw= X-Received: by 2002:aca:c0d5:: with SMTP id q204-v6mr27413198oif.77.1531256190625; Tue, 10 Jul 2018 13:56:30 -0700 (PDT) MIME-Version: 1.0 References: <639B8766-A030-490D-8431-C3F9F3EAFCB4@gmail.com> In-Reply-To: <639B8766-A030-490D-8431-C3F9F3EAFCB4@gmail.com> From: Richard Barnes Date: Tue, 10 Jul 2018 16:56:18 -0400 Message-ID: To: Bob Hinden Cc: "Joel M. Halpern" , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000004d7ed10570ab5d03" Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 20:56:40 -0000 --0000000000004d7ed10570ab5d03 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2018 at 4:11 PM Bob Hinden wrote: > Richard, > > On Jul 10, 2018, at 7:21 AM, Richard Barnes wrote: > > > > On Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern > wrote: > >> This formulation assumes that change does not have a cost. It does. I >> agree that not changing has some cost. However, absent indication that >> the changes will actually address the claimed problem... > > > People are presenting indications. Attach what caveats you need to my > little study; it's still real data from a relevant population. Do you ha= ve > better data? > > > > When I saw the survey, after I filled it in, I noticed that I could do it > again. There didn=E2=80=99t appear to be a mechanism to keep anyone from = taking it > multiple times. Based on this, I don=E2=80=99t think one can draw any c= onclusions. > Do you ever use telemetry from fielded products? How do you know your competitors aren't feeding you bad data? --Richard > > Bob > > > --0000000000004d7ed10570ab5d03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Jul 10, 2018 at 4:11 PM Bob Hinden <bob.hinden@gmail.com> wrote:
Richard,

On Jul 10, 2018, at 7:21 AM, Richard Barnes <rlb@ipv.sx> wrote:


On Mon, Jul 9, 201= 8 at 6:32 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
This formulation assumes that change does not have a cost.= =C2=A0 It does.=C2=A0 I
agree that not changing has some cost.=C2=A0 However, absent indication tha= t
the changes will actually address the claimed problem...
<= br>
People are presenting indications.=C2=A0 Attach what caveats = you need to my little study; it's still real data from a relevant popul= ation.=C2=A0 Do you have better data?


When I saw the survey, after I filled it i= n, I noticed that I could do it again. There didn=E2=80=99t appear to be a = mechanism to keep anyone from taking it multiple times. =C2=A0 Based on thi= s, I don=E2=80=99t think one can draw any conclusions.

Do you ever use telemetry from fielded produc= ts?=C2=A0 How do you know your competitors aren't feeding you bad data?=

--Richard

=C2=A0
<= div>
Bob


--0000000000004d7ed10570ab5d03-- From nobody Tue Jul 10 14:13:47 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5571310C3 for ; Tue, 10 Jul 2018 14:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 evnbYZeqw-gv for ; Tue, 10 Jul 2018 14:13:39 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15A1130DE1 for ; Tue, 10 Jul 2018 14:13:36 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id n84-v6so45381728oib.9 for ; Tue, 10 Jul 2018 14:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XTNBfuHRmMC+19juqQvwvd1CitiDu7T/mR7RYAbT1Qs=; b=Qjy8eqVvij4uVfDMasIPnUYTtLnu9DHaViu3ATVwhWyRmiRE1Gb68wzKgBI0BZaky4 2/YHlC68WbjpHXcMQBFBIg0u4Q8iGMheJvdJs8PMN2+8NLL9khqxzku5pnWWG//dcayA QslRVF96t0T9bpIqcxyS4/Wbc75vx1obfWRcYR6LckO6WojLt2ylWJ9PwADDx3Hefkgc OOFCDNYEeX7zloe86XgGNJjdwGwWGqfMVSetcnIHOwUeEGbWv0MxQ7wA58sko3X09lZN UmefAosFYsblXEWlJFThLkc6ix5xIATfWP+UuSCiBmq00T4B+f6ADLpo5yO0jvlBmKbR LZ3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XTNBfuHRmMC+19juqQvwvd1CitiDu7T/mR7RYAbT1Qs=; b=AkX5hftqfBhCCOG+qeJjxJj5fSQWEZbX5Guy3f7lUhEqnTdR2ZB6uH20zNrXMG1OIh UEcTP+KBshASYm89aSrfSFFNPGBnNg5xyZljp29/Gn0dhvXq4CXGDFUaZITvBBeeSLAy TRLHV+5VBCnKBUdDa4iLKj0PlmDB2bwmlPZX6qBUle33eTCBSyLZwfu5s7GgHqAISOBD bpsFCnu27RxlmHyIutKGLA86qGOMzoSsMdvdpFHvsBUWjVkLmLruFSWcGiXZoSnC5oJz 7SfZ096oEmb9h7yDbPGp5UfFCkKtih3QbLu9FTj2EfKWuV9TaqMz9Ynf4jvpY3Ssa0xx sjkg== X-Gm-Message-State: APt69E2kFIMgdTnI+UTsJpwz7JQiYHDdY+tX5sG66JkMFLkg8UVRMoh0 I/7WN6y0mFuyEbRosmM6NiQB9gpX6a7sP6Ve+gw= X-Google-Smtp-Source: AAOMgpeKNv+NZGtvB3mODFNxCVfGKNs/DSuZ9XGIh+S+DB2aCCvnY2CAfgYO6GmlNcGSZzqQt0yzPqtOLwEaTcQkWMQ= X-Received: by 2002:aca:3c45:: with SMTP id j66-v6mr27312588oia.118.1531257216054; Tue, 10 Jul 2018 14:13:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 14:13:05 -0700 (PDT) In-Reply-To: <1F7626CA-FB10-402A-BCF3-EA89526AC63C@gmail.com> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <1F7626CA-FB10-402A-BCF3-EA89526AC63C@gmail.com> From: Ted Hardie Date: Tue, 10 Jul 2018 14:13:05 -0700 Message-ID: To: Aaron Falk Cc: Eric C Rosen , rfcplusplus@ietf.org, Andrew Sullivan Content-Type: multipart/alternative; boundary="0000000000006c3be90570ab9a75" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 21:13:46 -0000 --0000000000006c3be90570ab9a75 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 1:23 PM, Aaron Falk wrote: > IIRC, the copyrights for IRTF stream RFCs default to permit publication > elsewhere to allow for easy submission in more-recognized forums. > Well, you're the author of the relevant doc, so I hesitate to cite it to you, but the text is in RFC 5743 and in https://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf. Basically, though, the individuals retain their own copyright (along with the Trust Copyright, managed by the IETF Trust at the request of the IRTF). They can re-submit. > Finally, I haven't seen anyone present that helping IRTF output get more > recognition is a goal of this activity. Is someone asking for this? > It's been a discussion between IRTF folk and the IAB for some time. It could, of course, be a separate activity from this experiment. Ted > --aaron > --0000000000006c3be90570ab9a75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 10, 2018 at 1:23 PM, Aaron Falk <aaron.fal= k@gmail.com> wrote:
IIRC, the copyrights for IRTF stream RFCs defaul= t to permit publication elsewhere to allow for easy submission in more-reco= gnized forums. =20

Well, you're the author o= f the relevant doc, so I hesitate to cite it to you, but the text is in RFC= 5743 and in https://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf.= =C2=A0 Basically, though, the individuals retain their own copyright (along= with the Trust Copyright, managed by the IETF Trust at the request of the = IRTF).=C2=A0 They can re-submit.=C2=A0

Finall= y, I haven't seen anyone present that helping IRTF output get more reco= gnition is a goal of this activity. Is someone asking for this?

<= /div>

It's been a discussion betw= een IRTF folk and the IAB for some time.=C2=A0 It could, of course, be a se= parate activity from this experiment.

Ted
=C2=A0

--aaron


--0000000000006c3be90570ab9a75-- From nobody Tue Jul 10 14:24:40 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7443130E35 for ; Tue, 10 Jul 2018 14:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 OJ_BfDshMBFY for ; Tue, 10 Jul 2018 14:24:35 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 B2A4B130DE1 for ; Tue, 10 Jul 2018 14:24:35 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id b5-v6so10399418qkg.6 for ; Tue, 10 Jul 2018 14:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=33e8npNgQ+WZECwFjCdBBTM8oxTQetIW5uf4e9FecSw=; b=j48vDa2fwfvH68cug3Uo1hKeyOngxUTuY2++N5rULQep5lZRe8PkwUFcbckjonXG5A 7NyWx90aOsw4TvT5dpNgq2U4vUvZHWU8Owl6jO/mWs+u/8qlWdpi1Sm+fd1YQIUj4wCT Qj9FF2Bn6Dk/gqYcEQc8wu5qkW96KXVjckK+PwD5PF6xicNqXNS+SoVOryAtRqV24B7k uFPfM9tFk03Ns9vu335dVgqIHywNBE+tWIP0Wf/+MN9dSw4bchnxtaWVhM/OYT/+sIS/ dZfYZi564z9+Mcu4AnnM5vSMDfKWcF2sF3fIjRvkIuEKvGJf6gFy0/JVrP2rKrUL+r5R p5JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=33e8npNgQ+WZECwFjCdBBTM8oxTQetIW5uf4e9FecSw=; b=LYNxQDWNd4NQSh312j6zrtEGmioE/JHAOPze/QfLMZk7JWoDvEeJrqpEhpc+UQuN2+ 5wGfONDlbFSfASwnc315xY8r1j9oUlcO/HQhqZDkjtq5dm4yzRXr31j+3GM7SMiDOYjy DfdePI4D3mLQJWUyXEvOcXQDVgvXimkVuSNYYRxovsMuGRyFt7tugfsTVUCZuSlXeoij 86t10+BbrzIFzdxs2q3iIG23uAmxlcbxjPRyKuV0VfuJ7u0USKRT2m5HUR9pbcP/6i5w NN9u63j9/2gGr8dezcXUp8Dhl3ZPMeLw4ESaQn6F0P7cQyOpLI3AlE7B34Egmv7LagdM JMpg== X-Gm-Message-State: APt69E2ep0munbpWua7tGYPY/Y9hKaK+GWDJghuf0Bd2aC96xcmzu71G hCOcFSyR86OD/kgj5rxC24w= X-Google-Smtp-Source: AAOMgpdmBtop04KR8AzHrqiVKbFDTUUiw4k7aLqa8ScDtLv4Ydcs6o5oNM18EWMKQN/WgyraFSQJLQ== X-Received: by 2002:a37:ba02:: with SMTP id k2-v6mr23782917qkf.134.1531257874545; Tue, 10 Jul 2018 14:24:34 -0700 (PDT) Received: from [172.19.33.154] ([2001:4878:a000:3000:f826:7a2c:984c:1004]) by smtp.gmail.com with ESMTPSA id g207-v6sm9774993qke.41.2018.07.10.14.24.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 14:24:33 -0700 (PDT) From: "Aaron Falk" To: "Ted Hardie" Cc: "Eric C Rosen" , rfcplusplus@ietf.org, "Andrew Sullivan" Date: Tue, 10 Jul 2018 17:24:31 -0400 X-Mailer: MailMate (1.11.2r5507) Message-ID: <6125AF9C-9112-4728-B4B3-E5CB06120B50@gmail.com> In-Reply-To: References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <1F7626CA-FB10-402A-BCF3-EA89526AC63C@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_EB8A3E80-B899-484E-87E0-444C9AB98379_=" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 21:24:39 -0000 --=_MailMate_EB8A3E80-B899-484E-87E0-444C9AB98379_= Content-Type: text/plain; format=flowed On 10 Jul 2018, at 17:13, Ted Hardie wrote: > On Tue, Jul 10, 2018 at 1:23 PM, Aaron Falk > wrote: > >> IIRC, the copyrights for IRTF stream RFCs default to permit >> publication >> elsewhere to allow for easy submission in more-recognized forums. >> > > Well, you're the author of the relevant doc, so I hesitate to cite it > to > you, but the text is in RFC 5743 and in > https://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf. > Basically, > though, the individuals retain their own copyright (along with the > Trust > Copyright, managed by the IETF Trust at the request of the IRTF). > They can > re-submit. Thanks for confirming my memory is still of some use. ;) > >> Finally, I haven't seen anyone present that helping IRTF output get >> more >> recognition is a goal of this activity. Is someone asking for this? >> > > It's been a discussion between IRTF folk and the IAB for some time. > It > could, of course, be a separate activity from this experiment. > Indeed. I think it is separate for the reason in my last message you chose not to cite: > an important reason for RGs to publish RFCs is the same reason that > they are RGs in the first place: to have their work be adjacent, > influence, and possibly migrate to the IETF. Of course, that is not > the only reason we have RGs but it is a good reason to have > non-standards track output in similar format & repositories as the > IETF. To be explicit: while there might be value in creating a peer-reviewed "IRTF Journal" or somesuch (and it has been proposed many times), many IRTF documents would be candidates for it. Compared the IRTF RFC Stream, the criteria for publication would be quite different. --aaron --=_MailMate_EB8A3E80-B899-484E-87E0-444C9AB98379_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">On 10 Jul 2018, at 17:13, Ted Hardie wrote:

On Tue, Jul 10, 2018 at 1:23 PM, Aa= ron Falk <aaron.falk@gmail.com> wrote:

IIRC, the c= opyrights for IRTF stream RFCs default to permit publication
elsewhere to allow for easy submission in more-recognized forums.

Well, you're the author of the relevant doc,= so I hesitate to cite it to
you, but the text is in RFC 5743 and in
https://trustee.ietf.org/docs/IETF-Trust-License-Poli= cy.pdf. Basically,
though, the individuals retain their own copyright (along with the Trust<= br> Copyright, managed by the IETF Trust at the request of the IRTF). They c= an
re-submit.

Thanks for confirming my memory is still of = some use. ;)

Finally, I haven't seen anyone present that helping IRTF outpu= t get more
recognition is a goal of this activity. Is someone asking for this?

It's been a discussion between IRTF folk and= the IAB for some time. It
could, of course, be a separate activity from this experiment.

Indeed. I think it is separate for the reas= on in my last message you chose not to cite:

an important reason for RGs to pub= lish RFCs is the same reason that they are RGs in the first place: to hav= e their work be adjacent, influence, and possibly migrate to the IETF. Of= course, that is not the only reason we have RGs but it is a good reason = to have non-standards track output in similar format & repositories a= s the IETF.

To be explicit: while there might be value i= n creating a peer-reviewed "IRTF Journal" or somesuch (and it has been pr= oposed many times), many IRTF documents would be candidates for it. Comp= ared the IRTF RFC Stream, the criteria for publication would be quite dif= ferent.

--aaron

--=_MailMate_EB8A3E80-B899-484E-87E0-444C9AB98379_=-- From nobody Tue Jul 10 14:29:42 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE89F1310FD for ; Tue, 10 Jul 2018 14:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVWnpvgtxGDE for ; Tue, 10 Jul 2018 14:29:39 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 C5215130DE1 for ; Tue, 10 Jul 2018 14:29:38 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6ALTT5l002447; Tue, 10 Jul 2018 14:29:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=PPS1017; bh=fh7a8xIne5kpBTCbpXvMXJjcX+dv4xyJ/E/5OWLnKuw=; b=1izrCMEUZkqEAHRA2BACxUt1hzQTjWETYOPm2210dBXrIXKI++rAp9Fk2nfZMsz+CWnl 546FpZUDbrfC4aabSZ/iQNhoZhNj9E2WQG/sDZkV6W3e/mnl2H9eXeXA1KfLEpqWF2Fi iIwidQipvzKdzrWeMljoFArbm0/kTR4Nj3s3bVr2MTMDH8RkUzwRs18pEAqdjIlXQ/Zg 5SXPtNgPILD6JzFtrXqPbYfyX+smZ1SXTcbZMgeFF349Pu3PJWqC+W8d1A73UO3M1L1/ rOtRzlMwe1QIh++YgflmOXyME6lkvC03eR6DflQxlwKXH8L1qzPK5ADI24xY9RAVO0ls qQ== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0021.outbound.protection.outlook.com [216.32.180.21]) by mx0b-00273201.pphosted.com with ESMTP id 2k51158ee5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 10 Jul 2018 14:29:29 -0700 Received: from [172.29.35.4] (66.129.241.10) by MWHPR0501MB3868.namprd05.prod.outlook.com (2603:10b6:301:7b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.8; Tue, 10 Jul 2018 21:29:26 +0000 To: Andrew Sullivan , rfcplusplus@ietf.org References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> From: Eric C Rosen Message-ID: Date: Tue, 10 Jul 2018 17:29:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <20180710204512.GT20282@mx4.yitter.info> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BN3PR03CA0114.namprd03.prod.outlook.com (2603:10b6:400:4::32) To MWHPR0501MB3868.namprd05.prod.outlook.com (2603:10b6:301:7b::23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1ca71f04-0238-453e-20b9-08d5e6ac36b9 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:MWHPR0501MB3868; X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3868; 3:mwrB23dTPO05x8kwb0H7ONz0C/Qh192gZx4ns9piIarnS6Dqd4u0VgnUxSnYzMvhxmILgxXhoPnH8W5D8JWmqWqmhm2ervgJsnL5Ape/sYuTvFK3o3jqxzuTkvRu84TtK1mf2pVn9DYZ7pEvQASJdXTVcuJzLQOzk4BwlY7kAw5MYUlJTPCSjL1hy2mydfF2FLb4IDj7fXTSR9MuuLAK0krLBfrFKwwx0EbYuL1/BY980pQ1nY3CyGFBg7XPLrY2; 25:x/qxEBne+bfvFHYrKclGI0b/Of+rI+EB0wXPGDZgHSnMi3qbVSjJVfyehB4glT2tAT6SSmyEfPHj4VJmLfxY6K8Xkx56f6sq1ZHBnAnBqQcBxsapeI6O9OsbJS7IgC/gba7JyptmchoMuBGTSWBOW3I7sYVZ/yFGUIqYkHbb8fxDiZRX96gSEso39GjG5as8aKL3qEXAPQicIVFGFF7H0iud96SegeRKiTSSg+El3gYvTEcz0bJuOSAuFkLoSVcXO3xowpdZCcnhRnL0I13kk+YD8rrb6k+H4wQ+Cm46/EOAdLScNm69ylvsOgM1BeGHKIv0/pZAnGN/ShokqFUpdg==; 31:m+unzGEjyx40sFnP0RylKWYjkRnqpBBc1HHL1gID12i75pfG0VCyeebATzGvDFhkQG5EH7ve3Ck+rlt8vaCnfPVoEIBs1mq2t007yqbq0eJrMW3rw0BtZojdacm+EYYpZHKDWpm12lXr1Isp4wmiKWIV8luUrXrjYEkIeVqC0ZZoN1exjEfWA8rvBuMpAcp5WnkPFzR6qtBOo5QnK+p6d8pZBKHVCUaD+knF3pOnwxw= X-MS-TrafficTypeDiagnostic: MWHPR0501MB3868: X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3868; 20:zwbuRUXyhIRnotsXRewRPBgPmE8EEUYqEUxz6gLRSoUGIAJuRAGB5uaBZdWKIH7yh8NPcgO/l3X627sddt7rw79oV1Y6j7m6sA/tUnZGgh/5lEKmlVySKSoQZKRS0862iktpqWpRjvarRuO4Aetr+HuotPpFxuQoNNAJJ/si1/0+1UvnusOd0td35SnNMBVs6u6b3o2SyFba04+1/ZJyAqshPbYYArcWv4s338Phe3DU/V2xp3nzqWNgbqLzONtYKUjb87sMmjdq5Ft2Heweym6AEUKQ6P4wzVXKoZY1JY6Nd1/tU+kZjus4zZJogBXBztuV2iG/KVaWD7cZhC1uJ8qzHlqZP3dwUJrMfwcibKKH5IG38ERw+CkpYVCldciG2MHyf5gTx+WYhgWR57SZFDrBcuUKMY8kMur17TqkF6vHAOuUkZkOgEo8+B+ornjDtseIlTtYXEwwBNgEZOM+CyzhSj+Mwh6GnzjUaD4vx3lYDofceSXy851jMig1qlYG+RjjRZwrP0HJSWSg9kRO2I8mEBA7dZ7aP4C5gP1qT1l1kG0plvO9RsPIBNdL9RVWZRl1L1bYoYlrHII7STmbCKgDXXwoSRxNXuu5GQGmUfI=; 4:IRF8N5gM9vLiGF4OtNR5YqPTVIlBTAukam4xRqP7fEuyeDql/QPQict33WX8g1WoTjD/umeheK5qeqiW3iwg6dR4qBOwPOOjf8Um6j1hB9NNtJ1XliFLKyQgPZd8uEw/4rsAu0Aw5Rtv3CD+93VKnF1/OlaBdXGuzRCBPrmADo3u/M/3IxeBuM00GMAUX/1WFKU1rIWXGrK4T5oF0LINnZo0QJ05ol6iGd6wsiks0oF+U3uBVK2BNJPaHoTSCdEPIxeL6YRpEEyCBxIlJb5FrA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:MWHPR0501MB3868; BCL:0; PCL:0; RULEID:; SRVR:MWHPR0501MB3868; X-Forefront-PRVS: 0729050452 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(39860400002)(366004)(346002)(376002)(396003)(136003)(199004)(189003)(53936002)(476003)(316002)(65956001)(478600001)(65806001)(66066001)(97736004)(956004)(47776003)(93886005)(2616005)(67846002)(11346002)(16576012)(58126008)(36756003)(25786009)(3260700006)(446003)(106356001)(105586002)(486006)(31686004)(6246003)(229853002)(52146003)(6486002)(6116002)(2486003)(52116002)(2906002)(23676004)(2870700001)(6666003)(76176011)(16526019)(3846002)(64126003)(7736002)(305945005)(26005)(77096007)(65826007)(5660300001)(68736007)(8936002)(31696002)(386003)(81156014)(50466002)(81166006)(53546011)(86362001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR0501MB3868; H:[172.29.35.4]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjA1MDFNQjM4Njg7MjM6TkFZLzBENXFrT1k1WkRBZ1RDVTc2cWZk?= =?utf-8?B?RS9GR01pMk90N1EwaStkbXNiN203OHh3aFU5eXBXZ0puaWhtWkZZRWN3UldK?= =?utf-8?B?Ym5uYUJvTGdJYnNXd3lXelFzcWk2bzhvWndjZ2oyMGlIU0liN0ovN0NRdis2?= =?utf-8?B?NXVRQXhqVWc1Y3Rpc0MzUEtVcnYzeEsyc3dZY1FuTzdSVFYxaXJZaVFVZWxU?= =?utf-8?B?U2lHNlN3QmIwaE5JQkMvSTFubUdrNkR0bXdBRmVzZmJmb1EwTjREeXhDT1Iz?= =?utf-8?B?dDltU3FsdDhoSmhBNHVXSW9IaXRsdG9aVGtTNmZsQjFCYXhydDNYaXgwM1BK?= =?utf-8?B?dDU5OGE4bGszd3JOdW40RkZFSVRyV2wvbE5xVjNWV1VzK3RDdEpjNmQ0M2Vh?= =?utf-8?B?UnRLKzFiQ3NzWi9TOEJOVzFDZndzTzZCcFVTaEVyWTlaUldWb2J6ZW9QcStQ?= =?utf-8?B?VGNrdWsvUVJiMGhRaDA3dHlhMjVFbmxHb3cxcHhVNVpoMjMwSCs1Wk1hcEFy?= =?utf-8?B?bUxkWHBJeTBNb2pLYTB2cWdlMThyWmhRaE0xb0tWMGFOL2lhVFNXTC93Y0ln?= =?utf-8?B?RE4zdEZ2bmt5RmJUYzVJY2tvV3dzcnJvdkpsbnRRbE1IQllOSDczaWRrZElP?= =?utf-8?B?WVJqOHUrV2dweDB1ZnIzdjU5NVdFVFMrRGJidnRnSG9WZGV4Y0pDdHduaXUy?= =?utf-8?B?RlBMUjQvOVdGV2gyMStibSt4dVFDcm9hRlN0V3pWMEdjemFva1hlVllTcjc1?= =?utf-8?B?c0hneVB5ZXgwR2VGaWxYd2drWlU5R0J1OXVTTDYyVlJ5eVN6N09BVmJEYXhV?= =?utf-8?B?ZEkzZ1pvUDI2M3Q2dVZBdUFvWml3RzRiRkdWdzJERlNiUkJuV25UL1JPTnk3?= =?utf-8?B?bE9oTGsycVhYdUtDVzFid0Yvb0RTZjBxcFpseWFnY0JQN1Z6ZnFVOXh0NzNM?= =?utf-8?B?emxYUzVhUXdrNUx4VXh3WXdnS3hFMVpyVjVmM0k4bk9QUkNqR1ZCZWxqbjhS?= =?utf-8?B?ZGY3cmhmTm4yZk1WSUtObWpWcktkdzVpZ1RHMGdPWExueGtGeVgxM3ZCWVBt?= =?utf-8?B?OW9JbEtPRFFHWDE3MkpiTzF4dmp6WmJZWmZCdmRpaEhGYmg4VEZzQSsyV2hk?= =?utf-8?B?cTJyMnhNNjZqTGhWR1VvdTBkaVJWdmJpL1hsejgvU2VCVUpLd2pWNVpWWG1K?= =?utf-8?B?WndHbjcwU1ZBMEVwNk8vRWxLZXhRZ2JnYVluRGp1WjlzM1cyMERqOCtEbStu?= =?utf-8?B?MG8vQkt5L3Zyb1dGOUFzalhRWkFLSFJDT3JRMWpDeEVuYmkvbnBlOTNZdGwx?= =?utf-8?B?VTVlVC9qTFFEQ3NjbHMxMWxhRFUvdkNxTzZ4RnFEUVhQUnppUy9SN3pHQ2pj?= =?utf-8?B?NitoSFpKT3pjYjYrd2F3VDNPRDRrSzh3RzBMTllwVWxaNGlUTnFWUnNvNTRi?= =?utf-8?B?MHlsdXNQd2VEbUdTZm00a3B0ajJudTBvV0F2dWhWcTA2UUlnaVhIa2prT1Uv?= =?utf-8?B?ZTZ2NklpTkcyNmxQUndHR0xvUERkRWtNcGVjdUJqTEpSOTdYYWhwSVV4MDNL?= =?utf-8?B?YzlVYi9SdjhsK2g1WE50Zlpzc1UxRmFFemxDMUpBUlFBWnlkS3E2WGxEbzcz?= =?utf-8?B?UFhzMk5iZDJNOVdOOUpEeStUUWhNdEZuY0VWcHpaSTAxalFCckRLV1RJN04z?= =?utf-8?B?QUU1eldaeGdhZlZLYVR6aTgvcU4vSjZpVFlxWFR1MHlLUmJJVStmaGNYcjFY?= =?utf-8?B?ci9VZDVLTFlDaC9QWWFBK0Qzcy8yc2U2TE1rNTJ2d3VRUVd6NTRJUWFaYzBI?= =?utf-8?B?UVpIWk9jNXVwZG1QaTZVeWVGSW9sYVdmV0l0bEVKTDJRZ3FzTldydVk2UTBx?= =?utf-8?B?U3JVV0gyc3YzSGZuMEJyUGUyRmo4UnlveWtHUzFCdS9OM2JDVnJBTEx0VWRY?= =?utf-8?B?MndsTUNGeDVFVGc9PQ==?= X-Microsoft-Antispam-Message-Info: gaxwwUCkT49jSABvt5WvgKKYW717Qe1Bn/eb7zpNWe0zvBXy3pS5oNovMKWdOIGEWaCAs+ETbq4JlEfRq5Xxhh1KRtA6hv2CCvqGQMKxuSTi7sReF/PR1PvKqtC4GeDJEzgh51SJfIogkWfb6cLTTTQGkqTHjObNyBIpqJ4zDdx+Hr4Zzy0hG1NgVSDTtgLUN2Dr6A1pD6gr7h6hQSGpFgM4C5LtjYOlkF0MNEsi1adELGea5gUErG27uvFBHlaup4U/QEMu4x7QDvPvgB22tQs+RAPvtCDy3ZY5oiwEyr0clhdVKZ2KIGC4r5ceu48XHyGuiMGOZXI8pM2lcQ41YWdHJp9t7c+TO93DSethuQk= X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3868; 6:dqLvI9lwGkCmbsbThDlmHDT3GsUXq5gGg899p+fjS1ecVsd5QrviMy7XnQ/glkWpC/gLUMpJLyhLje4FumSI7buRqWWFA63vOwxYyqQFiNL4sxUqZ1ooz65g9y9e8UqdkimGy2cPE9fA2rU8SbsjfoDE9YK0+3x2yIir/aUVPfHiI9F+TAC28az/poBccq0iC4TZP9dFv/QzeqZEwFkM0YAkE1pSdxA7D2bJByMluS12vKa6rIa2z7dj1jvvXTLrTrkEdKezKA+2g5rXdo4HerJXn6YLjpGUvufcRy+pwvrC9PdXgjwQeK3mAVneVCvk9ffT9eXN9kLb47V4FiP2DpSs5g+HGPuy3nh+yflSjr+wa03wvrcoIeSGNTf/b4XohflAHaLDC0ZHG8Sd1GdCjeGdUajG7tUHw7HRveudOV8cFx5VbvJqxIf34xXElIUTiegZJtI3JxWqHtq6e6vnvA==; 5:DfF22K5dt5E9j6hVCvSMwVsQQYJ+5/wfSDrBvnIQQDKsMAAebn30f/fJTwc3dN9WImM3glmWU6zA9MhkRMLRWouT0plz2DLEAoq3fiMKvIn2SAeTWH+tRoTg647JnUOjbcXE6+WYVc4Kemj3/1fke9I3cJh23p3OPBQOevZZiMU=; 24:Kn477GxJw2Q3KmdCJQZSukxRgdJTbdMQlsJxlv/h+tALuMuvBtd4f1nkXVRgZgVLVG5Nt1eIyRTM511GDD6QOZCR7frHjPihWXwb1qJ4EbE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MWHPR0501MB3868; 7:ji66VZO9J27qy7+3xEOsuiKTf9NQOw5ZrZJlOJ7WOjDa1wuZwWZHyA0ImFAxsIYazX5S2KS155lbHqmk6HZb/trTZ9ekcilMN8a8H6NMKkWU/Lk9gzVRBplUamfjHhfN64QA5JpbfWBXcDrzx8b6aaBln20+mZ1MGLfdaPnUzA2geQ+uLL0wdovoH7198CZ4lidoR9kIpLCpmXojy1haqdIJqzRvdqBJe046lsZeHrcz9hIbCHmjLWlXPllXa9Ui X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2018 21:29:26.2984 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1ca71f04-0238-453e-20b9-08d5e6ac36b9 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0501MB3868 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-10_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=872 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807100228 Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 21:29:41 -0000 On 7/10/2018 4:45 PM, Andrew Sullivan wrote: > you are in effect asserting that there is no benefit to the > Internet community in having a gateway function to the RFC series. What I would say is  that there is no benefit to the Internet community in making a major change to the existing gateway function. > It is an interesting > question whether, if I wanted to publish an RFC about Wittgenstein's > remarks on colour, whether the ISE would consider it I don't think that has any relevance to Internet engineering. From nobody Tue Jul 10 14:29:54 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4B41310FD for ; Tue, 10 Jul 2018 14:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 HxDg4p7-LHL5 for ; Tue, 10 Jul 2018 14:29:47 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E14D130DE1 for ; Tue, 10 Jul 2018 14:29:47 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id l10-v6so19704370qtj.0 for ; Tue, 10 Jul 2018 14:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=dc/L7hgbRH4gPCrujT8N72CAjLwRJAFFg3SNX45Y1FI=; b=sNZdrY5fvtlbIy1bhQ0cKeAQ5RzFV/YY6zp+mgLzlJsStvFSTD7dAvN1Mu+ZAhuB5G iWr2/XhMCNJvvmVQ2nAmga/RmhNpXauHzYApU9+4MMtkJIDtZp4EfQ3sHLYoX/nbBN5G afTXTSU3LcZlLY6BWS+Lr5yb3z9KIi/0BPLWlQkwMF2m6ZnFDK7ozLjhRYjQGSX462ma sNAIV5qeciDKlHX+Fcta2/jMniVUvaxPeMmHLNF64rwXYHsIw12q6n1wGPHP5DHwNFq/ uhaoe1Almd4XqBFN419eyaT2uIq4kbJaWRMYvb/dQcCSsTruPoxVhZUAyDbNCENkxd7+ tkWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=dc/L7hgbRH4gPCrujT8N72CAjLwRJAFFg3SNX45Y1FI=; b=LVLE9Tlrh22qa8R1hVLTRKNOJQmCKKjeor3Q7+gUdeUpMp9pDKlYLXU0dyLZGebiBx qCtX1WgVH3+CAitwL+MUhlMYVeudviF0DVsWoxpKPF/i/2jpa82QA9lDV8nhL+X643hv YBzt6hFdHhdQUUZv2u++V6Im+TcKbFBvuCJcxsMpt8ZGjUy4sFw4J5wVHRkVDhzfUZdV aSSD7hGcC8S4htJHUlh0eX11TrK0+Isi3FYpDirx0LgzUWUKphDN9s7O1wtqlypxRjWH Lw8/ooCQg4uEJ8kHAXBieGH99lbwDWlCjpn21eRKF1LfwPsecrNULeKL5hpojo2+yjce TjIw== X-Gm-Message-State: APt69E2kbnKXSAEyokbrEfvNgxjK3PVL2QJbMOHtSPkHH2idPHjef3kw aRoVXj6l4fQwLAQ3W9jtHFm7rytc X-Google-Smtp-Source: AAOMgpdQ9dTiWtoMKdcj8XBkIu52XevGD2ykm0t/aK6eeXaRaScjzjF8qNwacM1ky3MMt1TE25uMhQ== X-Received: by 2002:a0c:95fa:: with SMTP id t55-v6mr23165080qvt.246.1531258185905; Tue, 10 Jul 2018 14:29:45 -0700 (PDT) Received: from [172.19.33.154] ([2001:4878:a000:3000:f826:7a2c:984c:1004]) by smtp.gmail.com with ESMTPSA id b4-v6sm15568463qtb.64.2018.07.10.14.29.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 14:29:45 -0700 (PDT) From: "Aaron Falk" To: "Ted Hardie" Cc: "Eric C Rosen" , rfcplusplus@ietf.org, "Andrew Sullivan" Date: Tue, 10 Jul 2018 17:29:43 -0400 X-Mailer: MailMate (1.11.2r5507) Message-ID: <8517CAB5-EB55-4E1B-9FBE-01A965923901@gmail.com> In-Reply-To: <6125AF9C-9112-4728-B4B3-E5CB06120B50@gmail.com> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <1F7626CA-FB10-402A-BCF3-EA89526AC63C@gmail.com> <6125AF9C-9112-4728-B4B3-E5CB06120B50@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_575FB68F-C976-482D-B190-559015BD10B3_=" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 21:29:53 -0000 --=_MailMate_575FB68F-C976-482D-B190-559015BD10B3_= Content-Type: text/plain; format=flowed On 10 Jul 2018, at 17:24, Aaron Falk wrote: > On 10 Jul 2018, at 17:13, Ted Hardie wrote: > >> On Tue, Jul 10, 2018 at 1:23 PM, Aaron Falk >> wrote: >> >>> IIRC, the copyrights for IRTF stream RFCs default to permit >>> publication >>> elsewhere to allow for easy submission in more-recognized forums. >>> >> >> Well, you're the author of the relevant doc, so I hesitate to cite it >> to >> you, but the text is in RFC 5743 and in >> https://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf. >> Basically, >> though, the individuals retain their own copyright (along with the >> Trust >> Copyright, managed by the IETF Trust at the request of the IRTF). >> They can >> re-submit. > > Thanks for confirming my memory is still of some use. ;) > >> >>> Finally, I haven't seen anyone present that helping IRTF output get >>> more >>> recognition is a goal of this activity. Is someone asking for this? >>> >> >> It's been a discussion between IRTF folk and the IAB for some time. >> It >> could, of course, be a separate activity from this experiment. >> > > Indeed. I think it is separate for the reason in my last message you > chose not to cite: > >> an important reason for RGs to publish RFCs is the same reason that >> they are RGs in the first place: to have their work be adjacent, >> influence, and possibly migrate to the IETF. Of course, that is not >> the only reason we have RGs but it is a good reason to have >> non-standards track output in similar format & repositories as the >> IETF. > > To be explicit: while there might be value in creating a peer-reviewed > "IRTF Journal" or somesuch (and it has been proposed many times), many > IRTF documents would *not* (sigh) > be candidates for it. Compared the IRTF RFC Stream, the criteria for > publication would be quite different. > > --aaron --=_MailMate_575FB68F-C976-482D-B190-559015BD10B3_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 10 Jul 2018, at 17:24, Aaron Falk wrote:

O= n 10 Jul 2018, at 17:13, Ted Hardie wrote:

On Tue, Jul= 10, 2018 at 1:23 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

IIRC, the c= opyrights for IRTF stream RFCs default to permit publication
elsewhere to allow for easy submission in more-recognized forums.

Well, you're the author of the relevant doc,= so I hesitate to cite it to
you, but the text is in RFC 5743 and in
https://trustee.ietf.org/docs/IETF-Trust-License-Poli= cy.pdf. Basically,
though, the individuals retain their own copyright (along with the Trust<= br> Copyright, managed by the IETF Trust at the request of the IRTF). They c= an
re-submit.

Thanks for confirming my memory is still of = some use. ;)

Finally, I haven't seen anyone present= that helping IRTF output get more
recognition is a goal of this activity. Is someone asking for this?

It's been a discussion between IRTF folk and= the IAB for some time. It
could, of course, be a separate activity from this experiment.

Indeed. I think it is separate for the reas= on in my last message you chose not to cite:

an importa= nt reason for RGs to publish RFCs is the same reason that they are RGs in= the first place: to have their work be adjacent, influence, and possibly= migrate to the IETF. Of course, that is not the only reason we have RGs = but it is a good reason to have non-standards track output in similar for= mat & repositories as the IETF.

To be explicit: while there might be value i= n creating a peer-reviewed "IRTF Journal" or somesuch (and it has been pr= oposed many times), many IRTF documents would

not (sigh)

b= e candidates for it. Compared the IRTF RFC Stream, the criteria for publ= ication would be quite different.

--aaron

--=_MailMate_575FB68F-C976-482D-B190-559015BD10B3_=-- From nobody Tue Jul 10 14:49:26 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C572D1310FD for ; Tue, 10 Jul 2018 14:49:23 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 g352qyp7Y4tF for ; Tue, 10 Jul 2018 14:49:21 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 D9DC9130E90 for ; Tue, 10 Jul 2018 14:49:21 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id c21-v6so12351093pfn.8 for ; Tue, 10 Jul 2018 14:49:21 -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=FB/faFE1YaVpBE9qVmD7N09jHfW+Ng+3pEuN7Y6yghA=; b=RGBumY4wXedvsSTyFsYZiSqPgrXRA76jJ3ZApcM5EIB+oE4ZrptFyprKxaMQ1IAbi1 UfM9bSYrbdxCBr56C5CEsj48z2ruKQVVorPapt3/dA/K9Ad2thcMb/8YuRb//nthdFRY kE6Ntq/cXKSarmgzn4Ooz83kf2YUBuPW+K8hn8uquLRQstE2eTdKfHiwkSe95sAbD+IE OaHJJgaJdsIvIH3g0oGImtBcUE+Piqk3+uL62xB4cDtPI6uLEgugkjp3GMxtLczVS299 d3WNtHAXTv+ebN4DRG1UBNXwvl0T6iE3LdYqNSsIWLSTX7JqYOgVgXEA1b3/0She767H 4Dsw== 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=FB/faFE1YaVpBE9qVmD7N09jHfW+Ng+3pEuN7Y6yghA=; b=Q7TPaFWCFsYK3pxGw4CG6R0dDqrHRneyp5kaQFzxwSDBqmDtt/L9tyZ1cdugDATTiB Gma+Wi6nedzx8Hazr5Ik9QLKz6UT0K5Pg+gm4AvRSGHkMfFLSwBpK5RsPTAWQqxSKUMq BQPSQ7rZq3eLX2J52ab1AGUdZb+nuupqFoKPFRWISVYHGxqSigHQFSHaw0owJoAkFiGf 0HNEdq1eNXYPcrgzPofsV763OV87UgmI0nQq3bISJlFeYXPMXr5dzz+udmlWTiLm0wX+ OrY9DhH7hfaFqR0TNCwegcF8HcInPTBp/79j+G+RjdOmNdL/tG0AnwSxhHTeeppdo9Lr pBfw== X-Gm-Message-State: APt69E2BQafXNS/QtNaDFvDTmjqxIYffHue0Yz4nagK9z1rqbyJR3z+z MB8nZn1ZYCwGY2yQVkxgLfRYFA== X-Google-Smtp-Source: AAOMgpcCgKl/q/aTWCe+YudM2T3XmIBYdYrRxxcvWkY9WYcp+EsOSMbL8sJlwpirPdW/E1xHuz0LsQ== X-Received: by 2002:a63:1126:: with SMTP id g38-v6mr22417725pgl.122.1531259361157; Tue, 10 Jul 2018 14:49:21 -0700 (PDT) Received: from aspen.local (209-193-22-151-radius.dynamic.acsalaska.net. [209.193.22.151]) by smtp.gmail.com with ESMTPSA id b12-v6sm2631003pfe.148.2018.07.10.14.49.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 14:49:20 -0700 (PDT) To: rfcplusplus@ietf.org References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <1F7626CA-FB10-402A-BCF3-EA89526AC63C@gmail.com> From: Melinda Shore Message-ID: <06a2ec62-8c83-cc0f-9b28-c285f7b77602@gmail.com> Date: Tue, 10 Jul 2018 13:49:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1F7626CA-FB10-402A-BCF3-EA89526AC63C@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 21:49:24 -0000 On 7/10/18 12:23 PM, Aaron Falk wrote: > As the IRTF chair when this stream was formalized I should point out > that an important reason for RGs to publish RFCs is the same reason that > they are RGs in the first place: to have their work be adjacent, > influence, and possibly migrate to the IETF. Of course, that is not the > only reason we have RGs but it is a good reason to have non-standards > track output in similar format & repositories as the IETF. It's also probably worth mentioning that academics produce output other than research papers, and we've got at least one instance of a researcher who's got a protocol spec they'd like to see published as an RFC through the IRTF. It's already been submitted as a draft and that draft has led to the start of several independent implementations, and may be used as foundational technology for other work. There's at least some value to academics in having an I-related publication stream available, independent of whether or not an RFC carries the same stature as peer-reviewed publication. Melinda From nobody Tue Jul 10 14:51:24 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3546D130E90 for ; Tue, 10 Jul 2018 14:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ofsMWnu4VDII for ; Tue, 10 Jul 2018 14:51:14 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 9D92D131175 for ; Tue, 10 Jul 2018 14:51:13 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id a132-v6so12430971qkg.3 for ; Tue, 10 Jul 2018 14:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=SUNs/5unWbDpJSdlGYTDI3TiENovpHnOiGjV7ffwvwQ=; b=ai7kK4KaPVi97SOvkwf9g4YlxXnlcNy+JjiLGxeZNbC8TYCktJ4RXs9h+tAXzbOQNZ E1e1jsLCx95I58BmOaytc9HtDqmpnSKqXtk1yODT/LztfHrTEuqe9iSfWDOk3GaolFDm 9W7n/L99yneMJAbuEqtzP1cPfRsKvYVdO5XbCBSSKRO8PS2by1DpUN7PiQpBFbzGTung xsY1QMk5fU7SdmksS2l4IuGAXs7e0of5CBW9WzdTxjKEqRkc4giO/DGMpex5OeU7kJlz wtRHY6WsTWw8lTV9rZ6aZL/AKikbzWJwy3TmrMtgdihq6d3SMtNasp24nnOwxGFj38W+ hc3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=SUNs/5unWbDpJSdlGYTDI3TiENovpHnOiGjV7ffwvwQ=; b=clP7o3oI8CFixcJ87C2C07fqSHKhZTwke29/pf2ELnIH18mhARBWp6LSAe0QsaSu3K v/F5+mTp9kYjEz0N4pmIaUKVCA3M2t20RASLYbQzwT320JuRp9SsyzHTlcg2LBziTgtG P7VRB3pArEMe+4bzVkkyRp3oZOsJijfgL3vKWj3qsYpegThZ7FSrBmsoJ4KOmrMXerJ5 awvQ//Gg3NwVKkhY94gOIml37gbwWDWSBibUp/CuUgsGMfTYikD1XpUnDxuj/ldOoz5w stgwgbgwLQKgOs8V6v+Bcli0gISuBpOlPHbM3rXIFIHgtyGe+Bk7Q+DqHpAJzxa2hjQU yQQg== X-Gm-Message-State: APt69E2hjVoX2ByP5snRKZ+GMJLGp8fqVW8MnE5bovF2ZhUNNidYnd27 LZLEJTV0B0qWqKACZFsraLg= X-Google-Smtp-Source: AAOMgpd3iTRKcX8bsB1D6YMTBhwyc+GzQWIAoO2lPaSJL9xKPgWPAmEaxIqkWGmFRviM0Cbsgb3vkw== X-Received: by 2002:a37:d7c5:: with SMTP id t66-v6mr22789686qkt.51.1531259472494; Tue, 10 Jul 2018 14:51:12 -0700 (PDT) Received: from [172.19.33.154] ([2001:4878:a000:3000:f826:7a2c:984c:1004]) by smtp.gmail.com with ESMTPSA id y132-v6sm1638286qkb.56.2018.07.10.14.51.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 14:51:11 -0700 (PDT) From: "Aaron Falk" To: "Melinda Shore" Cc: rfcplusplus@ietf.org Date: Tue, 10 Jul 2018 17:51:10 -0400 X-Mailer: MailMate (1.11.2r5507) Message-ID: <0A89510C-0D20-4BD4-AEE5-2568E4EB853E@gmail.com> In-Reply-To: <06a2ec62-8c83-cc0f-9b28-c285f7b77602@gmail.com> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <1F7626CA-FB10-402A-BCF3-EA89526AC63C@gmail.com> <06a2ec62-8c83-cc0f-9b28-c285f7b77602@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_2235CE2F-9B01-4445-B131-F40DE9507F4F_=" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 21:51:22 -0000 --=_MailMate_2235CE2F-9B01-4445-B131-F40DE9507F4F_= Content-Type: text/plain; format=flowed On 10 Jul 2018, at 17:49, Melinda Shore wrote: > On 7/10/18 12:23 PM, Aaron Falk wrote: >> As the IRTF chair when this stream was formalized I should point out >> that an important reason for RGs to publish RFCs is the same reason >> that >> they are RGs in the first place: to have their work be adjacent, >> influence, and possibly migrate to the IETF. Of course, that is not >> the >> only reason we have RGs but it is a good reason to have non-standards >> track output in similar format & repositories as the IETF. > > It's also probably worth mentioning that academics produce output > other than research papers, and we've got at least one instance of > a researcher who's got a protocol spec they'd like to see published > as an RFC through the IRTF. It's already been submitted as a draft > and that draft has led to the start of several independent > implementations, and may be used as foundational technology for > other work. There's at least some value to academics in having > an I-related publication stream available, independent of whether > or not an RFC carries the same stature as peer-reviewed publication. Indeed. I would say this is a very common case. Researchers know the RFC series isn't the place to publish original research. --aaron --=_MailMate_2235CE2F-9B01-4445-B131-F40DE9507F4F_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= br>

On 10 Jul 2018, at 17:49, Melinda Shore wrote:

=

On 7/10/18 12:23 PM, Aaron Falk wro= te:

As the IRTF= chair when this stream was formalized I should point out
that an important reason for RGs to publish RFCs is the same reason that<= br> they are RGs in the first place: to have their work be adjacent,
influence, and possibly migrate to the IETF. Of course, that is not the only reason we have RGs but it is a good reason to have non-standards
= track output in similar format & repositories as the IETF.

It's also probably worth mentioning that aca= demics produce output
other than research papers, and we've got at least one instance of
a researcher who's got a protocol spec they'd like to see published
as an RFC through the IRTF. It's already been submitted as a draft
and that draft has led to the start of several independent
implementations, and may be used as foundational technology for
other work. There's at least some value to academics in having
an I-related publication stream available, independent of whether
or not an RFC carries the same stature as peer-reviewed publication.

Indeed. I would say this is a very common c= ase. Researchers know the RFC series isn't the place to publish original= research.

--aaron

--=_MailMate_2235CE2F-9B01-4445-B131-F40DE9507F4F_=-- From nobody Tue Jul 10 14:51:41 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C909130E90 for ; Tue, 10 Jul 2018 14:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 8FNuxq6zjD8u for ; Tue, 10 Jul 2018 14:51:32 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF7B131162 for ; Tue, 10 Jul 2018 14:51:31 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id v128-v6so451500wme.5 for ; Tue, 10 Jul 2018 14:51:31 -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=JKj/l8aiLcMYrSDC5+hpI5Yv4y6Db/EtttaOClUL9pg=; b=nbj7vFWuiBKA4dahpOKa1ZWCYAPl+6pZzWV/JBoeO3XQpX6Ga+3f8zEX+EyHM9PHVB ARRBrM/QnOUuLTpzhwgYnujpI3Ckg8GhrLHTgfPDPEBOB/Y9CTk4SStTWk026/bEzWvH lnXmYM3YCa9OUUaWIhNK9pufuMNcr6TtoOOM1rgbRmlWSwFKVkfJjWDR5iYr9wTAsJXf sKAeF0w2Yyc4fpEdwMZ4bD+5ZfyVgaSWULotvM+IUpwD8cR/IxtZt2UgOLp0RZB2q3Pk iyB0LcrMB8fi0PVqy+WtUlM6rA/Z5RHBEEGjCUkF18zvCciu1OEPRRo5aYAyKjWOHm75 dXvg== 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=JKj/l8aiLcMYrSDC5+hpI5Yv4y6Db/EtttaOClUL9pg=; b=QeqpBAI8+x/XWlp9mS9jGimXC6gBjSG+gj+afSTUDh3rV6HeI9vb/M8yPji4YcICXx l56/G1RoNpH4WZLivHrSLLubYiaLyxcFngBJ/n+PgeZTX9VsHAwL1VUHeTNc60Dwp00X MweDHU5HUSl7qCsPTuCHlnSsjbH7fNf4bE3K0JK7w+NdP5tGCmK0W9slmz7RjZr3Gbww A+Huxv7pn77+rCyikdr8iTDDQU1js4wE2WuX+I2fUZ72r40//+Fs4Mc/aWLgvTtJ9kiE Gix3wDrCrGxQe/2LZNSleOCarEcu+PWYLeh1CEIsPAPgHiWYnJY9Ecv64bIW6a0cV7b4 bELA== X-Gm-Message-State: APt69E353DeWlQiFEs2pfCWnOlfaXo5TxjZU1hOxXmZKzj/t5mF4mw7G 1x1DU0mMg1JIzVZwCJR6Zxw= X-Google-Smtp-Source: AAOMgpfUoCIcT+WSRuY6TxPi8YOG+Vzz7HD0ntiwHM8RRCy1RaJaM5Lj5NwPoo9fp09oVL1OCClDOw== X-Received: by 2002:a1c:be13:: with SMTP id o19-v6mr14868679wmf.1.1531259490341; Tue, 10 Jul 2018 14:51:30 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id k14-v6sm15542522wrg.38.2018.07.10.14.51.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 14:51:29 -0700 (PDT) From: Bob Hinden Message-Id: <8B48E5E5-90DC-423F-83C7-9B51A853A1A8@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7692534F-B70E-4077-9E7C-57C019F6C33D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 10 Jul 2018 14:51:23 -0700 In-Reply-To: Cc: Bob Hinden , "Joel M. Halpern" , rfcplusplus@ietf.org To: Richard Barnes References: <639B8766-A030-490D-8431-C3F9F3EAFCB4@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 21:51:36 -0000 --Apple-Mail=_7692534F-B70E-4077-9E7C-57C019F6C33D Content-Type: multipart/alternative; boundary="Apple-Mail=_415796FB-11BF-4940-85A0-A76A841BCB13" --Apple-Mail=_415796FB-11BF-4940-85A0-A76A841BCB13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 10, 2018, at 1:56 PM, Richard Barnes wrote: >=20 >=20 >=20 > On Tue, Jul 10, 2018 at 4:11 PM Bob Hinden > wrote: > Richard, >=20 >> On Jul 10, 2018, at 7:21 AM, Richard Barnes > wrote: >>=20 >>=20 >>=20 >> On Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern > wrote: >> This formulation assumes that change does not have a cost. It does. = I >> agree that not changing has some cost. However, absent indication = that >> the changes will actually address the claimed problem... >>=20 >> People are presenting indications. Attach what caveats you need to = my little study; it's still real data from a relevant population. Do = you have better data? >=20 >=20 > When I saw the survey, after I filled it in, I noticed that I could do = it again. There didn=E2=80=99t appear to be a mechanism to keep anyone = from taking it multiple times. Based on this, I don=E2=80=99t think = one can draw any conclusions. >=20 > Do you ever use telemetry from fielded products? How do you know your = competitors aren't feeding you bad data? You point is? That your flawed survey is OK because there are other = flawed surveys? Bob --Apple-Mail=_415796FB-11BF-4940-85A0-A76A841BCB13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 10, 2018, at 1:56 PM, Richard Barnes <rlb@ipv.sx> wrote:



On Tue, Jul 10, 2018 at 4:11 PM Bob Hinden <bob.hinden@gmail.com> wrote:
Richard,

On Jul 10, 2018, at 7:21 AM, Richard Barnes <rlb@ipv.sx>= wrote:



On Mon, Jul 9, 2018 at = 6:32 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
This formulation = assumes that change does not have a cost.  It does.  I
agree that not changing has some cost.  However, absent indication = that
the changes will actually address the claimed = problem...

People are presenting indications.  Attach what caveats = you need to my little study; it's still real data from a relevant = population.  Do you have better data?


When I saw the = survey, after I filled it in, I noticed that I could do it again. There = didn=E2=80=99t appear to be a mechanism to keep anyone from taking it = multiple times.   Based on this, I don=E2=80=99t think one can draw = any conclusions.

Do you ever use telemetry from fielded = products?  How do you know your competitors aren't feeding you bad = data?

You = point is?  That your flawed survey is OK because there are other = flawed surveys?

Bob



= --Apple-Mail=_415796FB-11BF-4940-85A0-A76A841BCB13-- --Apple-Mail=_7692534F-B70E-4077-9E7C-57C019F6C33D 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAltFKlsACgkQrut0EXfn u6gARQf7Bpdjfv53A3BSfxBgFhkIZg9SMSCGox69Ludot/Daze8ErhK22QJS/2hW IFJaNVLhNJNQKeKMa8qLblLCmlo35/PX8vawrfbOLusaMsfbluWr4CW8rFrqarZV YzwTI8KRHrlhZFMXWxRpKehfSjOoyT9SUC1fHZPplr+yl9yFSIriiYSg4Kw51MYt ndLbeP8H4dVeUHNf+zURdmo73s68hQXqnzqsNSpPUoPckOTLIB9yKeX1zIZLu92T p/6m6bPOISfAkUF2xzZHoaBWTYca/uXCoEW15iZWEoAFHZTNIhB0HJMlRX/pESbf 4EQrN0qraIPc8uf8bh72Vmb3nSB5iw== =hbDC -----END PGP SIGNATURE----- --Apple-Mail=_7692534F-B70E-4077-9E7C-57C019F6C33D-- From nobody Tue Jul 10 15:03:38 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BD013118A for ; Tue, 10 Jul 2018 15:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m5T5gpSQcck for ; Tue, 10 Jul 2018 15:03:31 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 8AA4F130E5D for ; Tue, 10 Jul 2018 15:03:31 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id k81-v6so45620491oib.4 for ; Tue, 10 Jul 2018 15:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f9iB3ir2/Fy55wQv+F8sgxdwD5IrOLlKpOK9CWqu/9E=; b=GD/d942bR87PU+97a7bSVEtuS9D/suvWegzypJuKKo7CE/KBzZAAm14DKCnYkPC9Tn Q+jcr8/2k1EuUrjtW1p0006lWzKk/zHALQBh6TdK4iuBFNdQUy1HIyAIkepxsyFn+cr3 WwhJ0nUIbZonEG4F+YgnxuozzMctuD+/HQ14qM8awguXLLMokqPP6rZxCNdBOtLSCCrJ PuNiCljx0djrcMXye1dwV5q8UfkrU8LDWw7Fljy64yxozSvX0oPh60I1oCCxaCYIpi3C lSY/h/fD38i88WAsDmTt0oQsoZCzmu6AwZXYpkUfS6FIL6RquOaOQlL9P+Gm5zDAHMh9 2xTw== 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=f9iB3ir2/Fy55wQv+F8sgxdwD5IrOLlKpOK9CWqu/9E=; b=d1VR+2tWSbqSYdRdclcNnR7W5qr5vKoJh4PYPGln6Hi2G/RohsAfJsO75xUGx1T7+X n7iL8jX885NeCv9Z1UeSL6sKs+6dj7PnghGUb6vQ9TncH1bmEaxDSDh0l54XEkJQdjGd +KCXhAokD9wjsSbDWXfyy9DI9z/CZkfiI//YJV2QQdNT80Zfcwido3yTG8XLv1YNGgKW qn7kxFILBK55uAZOpuWyX2yFsyc7/ZwMlJd3RngPh2kmBc8IZJu8IL6gfXjl4mApyTzw KgBCQOj4Tm6cO12l2tpjjuaxhpBQbfRQygOM/3RWumbO8wh0pIQ6/l5mgF3/dUVfkWKA q4mQ== X-Gm-Message-State: APt69E35bjp2rSV/K083NSnmEVFSdEnieddF7VuG2pyyc9TLqCQSdoRb Mg1C92Ok7xp9y7vzXqIp5ei9GQ0vlonpvO8NBzIlGw== X-Google-Smtp-Source: AAOMgpfblC/l7KpVXIWm3fYwTuncVRDllpe2JVGRiKarPY0ApCS3BNyPQVNFQAZzgCtw4RA6zre4UaE4w63WDdfftvs= X-Received: by 2002:aca:d088:: with SMTP id j8-v6mr30763783oiy.276.1531260210623; Tue, 10 Jul 2018 15:03:30 -0700 (PDT) MIME-Version: 1.0 References: <639B8766-A030-490D-8431-C3F9F3EAFCB4@gmail.com> <8B48E5E5-90DC-423F-83C7-9B51A853A1A8@gmail.com> In-Reply-To: <8B48E5E5-90DC-423F-83C7-9B51A853A1A8@gmail.com> From: Richard Barnes Date: Tue, 10 Jul 2018 18:03:18 -0400 Message-ID: To: Bob Hinden Cc: "Joel M. Halpern" , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000e9e05a0570ac4c96" Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 22:03:36 -0000 --000000000000e9e05a0570ac4c96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2018 at 5:51 PM Bob Hinden wrote: > > On Jul 10, 2018, at 1:56 PM, Richard Barnes wrote: > > > > On Tue, Jul 10, 2018 at 4:11 PM Bob Hinden wrote: > >> Richard, >> >> On Jul 10, 2018, at 7:21 AM, Richard Barnes wrote: >> >> >> >> On Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern >> wrote: >> >>> This formulation assumes that change does not have a cost. It does. I >>> agree that not changing has some cost. However, absent indication that >>> the changes will actually address the claimed problem... >> >> >> People are presenting indications. Attach what caveats you need to my >> little study; it's still real data from a relevant population. Do you h= ave >> better data? >> >> >> >> When I saw the survey, after I filled it in, I noticed that I could do i= t >> again. There didn=E2=80=99t appear to be a mechanism to keep anyone from= taking it >> multiple times. Based on this, I don=E2=80=99t think one can draw any = conclusions. >> > > Do you ever use telemetry from fielded products? How do you know your > competitors aren't feeding you bad data? > > > You point is? That your flawed survey is OK because there are other > flawed surveys? > Since Eden, we have lived in a fallen, flawed world, and we get along with flawed surveys. We extract what meaning we can. In any case, as I think I said elsewhere in this thread, I have talked to a few dozen real, live, honest respondents. So I've got pretty good confident that the survey is not massively tainted by abuse. --Richard > Bob > > > > --000000000000e9e05a0570ac4c96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Jul 10, 2018 at 5:51 PM Bob Hinden <bob.hinden@gmail.com> wrote:

On Jul 10, 2018, at 1:56 PM, Richard Barnes <rlb@ipv.sx> wrote:


On Tue, Jul 10, 2018 at 4:11 P= M Bob Hinden <= bob.hinden@gmail.com> wrote:
Richard,

On Jul 10, 2018, at 7:21 AM, Richard Barnes <rlb@ipv.sx> wrote:



On = Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">This formulation assumes that change does not= have a cost.=C2=A0 It does.=C2=A0 I
agree that not changing has some cost.=C2=A0 However, absent indication tha= t
the changes will actually address the claimed problem...
<= br>
People are presenting indications.=C2=A0 Attach what caveats = you need to my little study; it's still real data from a relevant popul= ation.=C2=A0 Do you have better data?


When I saw the survey, after I filled it i= n, I noticed that I could do it again. There didn=E2=80=99t appear to be a = mechanism to keep anyone from taking it multiple times. =C2=A0 Based on thi= s, I don=E2=80=99t think one can draw any conclusions.

Do you ever use telemetry from fielded produc= ts?=C2=A0 How do you know your competitors aren't feeding you bad data?=

You point is?=C2=A0 Tha= t your flawed survey is OK because there are other flawed surveys?

Since Eden, we have lived in a fallen, = flawed world, and we get along with flawed surveys.=C2=A0 We extract what m= eaning we can.

In any case, as I think I said else= where in this thread, I have talked to a few dozen real, live, honest respo= ndents.=C2=A0 So I've got pretty good confident that the survey is not = massively tainted by abuse.

--Richard


=C2=A0
Bob

<= br>

--000000000000e9e05a0570ac4c96-- From nobody Tue Jul 10 15:05:59 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D63313118A for ; Tue, 10 Jul 2018 15:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.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 qlmNaF0Ae8JV for ; Tue, 10 Jul 2018 15:05:55 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA97130E5D for ; Tue, 10 Jul 2018 15:05:54 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id l143-v6so6005444vke.1 for ; Tue, 10 Jul 2018 15:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IAJWSCeNIeMFw+CXXQzWsAYKkQu0kBfLjcRJ9OEMQwU=; b=h38JEl0yZfvbItJPDNrslCtF0VU5JCxn1CHr1n/f2f8o65nAFpE0KgdTyoIoQrAOk4 9S5EY7rOnXv3W+bZ+jYm6YDxQBUIrI5Yn2B0GyGp7yXEjmIeOvOWmlEteW0ih7aEM6qc vxSnQXNDnhNbMHxkyVN38kRsNbIofZXkzcYgU= 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=IAJWSCeNIeMFw+CXXQzWsAYKkQu0kBfLjcRJ9OEMQwU=; b=qklg4XFFBQKW0NRQeFLSGXcjHjLGNLhZ+w79nQVVo/0zr1WggPMbSRCz+1v/ptjN2S xEH+ut4toF5nM1xsfhdbOFWKoCG95Sw03U8Rl8sRu2FC/7PzUdx380T9m2jU/r+5wVRp iLJzmSmcRMMBt+ITDNR66686Q4n8CLCCzvssGs0Raa8kx7hVXf4eszgQQzTHPcehqVer Yra8MDhmT3GfrUeyOqLnPovt0cmv4wjZCcXvR5mZlpZjOUgc2XveAkOpMDK8tgMELAoh GoqmqYYylR98dCragH/omclwF68eqiH7KweCbL48IVoe1qJvLbwWjUsvgqcu7MKaLyvv U5YQ== X-Gm-Message-State: AOUpUlECPJAEXKkr6zl7n5ClKbA6EKbrq/sVmtG6dMo7xg6haEo/ilX6 yMWzimxCGVj16mGmnPZC52vV+/qlHYYGAF/gPgLLtg== X-Google-Smtp-Source: AAOMgpc+FheoUJ+cx6v1V8M5I1P4quJdjgYDyeLK0lqXixNr+3DhU8Mc0/1Iyy8Ao56AnjbqBcX/4eFAgMRtEfVCFZg= X-Received: by 2002:a1f:5ec1:: with SMTP id s184-v6mr300163vkb.94.1531260353400; Tue, 10 Jul 2018 15:05:53 -0700 (PDT) MIME-Version: 1.0 References: <639B8766-A030-490D-8431-C3F9F3EAFCB4@gmail.com> <8B48E5E5-90DC-423F-83C7-9B51A853A1A8@gmail.com> In-Reply-To: <8B48E5E5-90DC-423F-83C7-9B51A853A1A8@gmail.com> From: Joseph Lorenzo Hall Date: Tue, 10 Jul 2018 18:05:41 -0400 Message-ID: To: Bob Hinden Cc: Richard Barnes , "Joel M. Halpern" , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000006c689d0570ac55a5" Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 22:05:57 -0000 --0000000000006c689d0570ac55a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2018 at 5:51 PM Bob Hinden wrote: > > On Jul 10, 2018, at 1:56 PM, Richard Barnes wrote: > > > > On Tue, Jul 10, 2018 at 4:11 PM Bob Hinden wrote: > >> Richard, >> >> On Jul 10, 2018, at 7:21 AM, Richard Barnes wrote: >> >> >> >> On Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern >> wrote: >> >>> This formulation assumes that change does not have a cost. It does. I >>> agree that not changing has some cost. However, absent indication that >>> the changes will actually address the claimed problem... >> >> >> People are presenting indications. Attach what caveats you need to my >> little study; it's still real data from a relevant population. Do you h= ave >> better data? >> >> >> >> When I saw the survey, after I filled it in, I noticed that I could do i= t >> again. There didn=E2=80=99t appear to be a mechanism to keep anyone from= taking it >> multiple times. Based on this, I don=E2=80=99t think one can draw any = conclusions. >> > > Do you ever use telemetry from fielded products? How do you know your > competitors aren't feeding you bad data? > > > You point is? That your flawed survey is OK because there are other > flawed surveys? > > I have a hard time seeing any survey research design that would convince this group, and I think that Richard's survey is a non-trivial effort to get some granted ugly data. As Richard pointed out, I guess I'm the noob here on the list, having been attending IETFs since IETF 89 in London, about 4.5 years ago. I must admit I still find so much of IETF a bit baffling... now that I'm approaching my IETF adolescence, I'm starting to understand why certain things are the way they are at IETF, and I'm thankful that it does what it does well and thoroughly. (I've even chipped in on the IASA 2.0 effort to help adapt IETF's administrative structure for the future.) However, the document series still baffles me, and I know a lot of folks that squint at IETF and don't understand any of the distinctions we do (I would have answered the survey question as there being only 4 document series). Alissa had the unenviable task at one point of sitting me down and telling me the difference between and ID and RFC, even after I had thoroughly read the Tao and been to a couple IETFs. (The ID we've been working on for a while I even named (incorrectly) when setting up a github repository as an RFC: https://github.com/josephlhall/rfc-censorship-tech ). I'll throw my hat in and say I'd like to see data, qualitative or quantitative. I'm a mixed methods researcher and have experience in both. I know a number of us have had enough informal discussions with "liminal" IETF participants that there is enough confusion here to explore doing something about it. That may not warrant an immediate document identifier experiment, but I think we could settle on some sort of research design that would provide essentially something like "running code" we could work with. cheers, Joe --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --0000000000006c689d0570ac55a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Jul 10, 2018 at 5:51 PM Bob Hinden <bob.hinden@gmail.com> wrote:

On Jul 10, 2018, at 1:56 PM, Richard Barne= s <rlb@ipv.sx> wr= ote:



On Tue, Jul 10, 2018 at 4:11 PM Bob Hinden <bob.hinden@gmail.com> wrote:
Richard,

On Jul 10, 2018, at= 7:21 AM, Richard Barnes <rlb@ipv.sx> wrote:


On Mon, Jul 9, 2018 at 6:32 PM= Joel M. Halpern <jmh@joelhalpern.com> wrote:
This formulation assumes that change does not have a cost.=C2=A0 It d= oes.=C2=A0 I
agree that not changing has some cost.=C2=A0 However, absent indication tha= t
the changes will actually address the claimed problem...
<= br>
People are presenting indications.=C2=A0 Attach what caveats = you need to my little study; it's still real data from a relevant popul= ation.=C2=A0 Do you have better data?


When I saw the survey, after I filled it i= n, I noticed that I could do it again. There didn=E2=80=99t appear to be a = mechanism to keep anyone from taking it multiple times. =C2=A0 Based on thi= s, I don=E2=80=99t think one can draw any conclusions.

Do you ever use telemetry from fielded produc= ts?=C2=A0 How do you know your competitors aren't feeding you bad data?=

You point is?=C2=A0 Tha= t your flawed survey is OK because there are other flawed surveys?

I have a hard time seeing any surve= y research design that would convince this group, and I think that Richard&= #39;s survey is a non-trivial effort to get some granted ugly data.

As Richard pointed out, I guess I'm the noob here on = the list, having been attending IETFs since IETF 89 in London, about 4.5 ye= ars ago. I must admit I still find so much of IETF a bit baffling... now th= at I'm approaching my IETF adolescence, I'm starting to understand = why certain things are the way they are at IETF, and I'm thankful that = it does what it does well and thoroughly. (I've even chipped in on the = IASA 2.0 effort to help adapt IETF's administrative structure for the f= uture.)

However, the document series still baffles= me, and I know a lot of folks that squint at IETF and don't understand= any of the distinctions we do (I would have answered the survey question a= s there being only 4 document series). Alissa had the unenviable task at on= e point of sitting me down and telling me the difference between and ID and= RFC, even after I had thoroughly read the Tao and been to a couple IETFs. = (The ID we've been working on for a while I even named (incorrectly) wh= en setting up a github repository as an RFC: https://github.com/josephlhall/rfc-censors= hip-tech ).

I'll throw my hat in and say I= 'd like to see data, qualitative or quantitative. I'm a mixed metho= ds researcher and have experience in both. I know a number of us have had e= nough informal discussions with "liminal" IETF participants that = there is enough confusion here to explore doing something about it. That ma= y not warrant an immediate document identifier experiment, but I think we c= ould settle on some sort of research design that would provide essentially = something like "running code" we could work with. cheers, Joe
=
=C2=A0
--
Joseph Lorenzo Hall
Chief Technologist, Center= for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 200= 05-3497
e: joe@cdt.org<= /a>, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9= F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 A871

--0000000000006c689d0570ac55a5-- From nobody Tue Jul 10 15:18:09 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E821311C5 for ; Tue, 10 Jul 2018 15:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 U8ALBmwSSpRW for ; Tue, 10 Jul 2018 15:18:03 -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 8FC041311C2 for ; Tue, 10 Jul 2018 15:18:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7DB491C0423; Tue, 10 Jul 2018 15:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1531261083; bh=0H1MMC9lffU64+2x7EI9hwo7gfD1qIzvjC7UsWDdsYg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jlOuq4erWdWk9oeXgmaO13go34djYHgW/UEq5uE3BGAa3egMvHYJa18Y8WSfjuavj JJ+CyRaM3CG3UB86loCVecdEjUWWKPQ1dgPBNUybj8m1iMBt5INa1iMZPuORBfVnvz kzLjHvKwHXoQBNCk+feAr/zfwRhwXNpBCq2M4Klg= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E5B471C0402; Tue, 10 Jul 2018 15:18:02 -0700 (PDT) To: Joseph Lorenzo Hall Cc: rfcplusplus@ietf.org References: <639B8766-A030-490D-8431-C3F9F3EAFCB4@gmail.com> <8B48E5E5-90DC-423F-83C7-9B51A853A1A8@gmail.com> From: "Joel M. Halpern" Message-ID: <417f8cb3-f42f-2d65-554a-ae330cd9e2c6@joelhalpern.com> Date: Tue, 10 Jul 2018 18:18:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.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: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 22:18:08 -0000 Thank you Joseph.Yes, it is confusing. And it is confusing in many different ways for many different reasons. It is very strange to have a BoF about such confusion, and then be told that various specific forms of confusion (such as I-D vs RFC whcih you cite, or different kinds of I-Ds which I mentioned) are out of scope. Apparently, we know which problems are important to the community before we have the discussion. usually, we get that information from the email list discussion with the community before a BoF is requested. Yours, Joel On 7/10/18 6:05 PM, Joseph Lorenzo Hall wrote: > > > On Tue, Jul 10, 2018 at 5:51 PM Bob Hinden > wrote: > > >> On Jul 10, 2018, at 1:56 PM, Richard Barnes > > wrote: >> >> >> >> On Tue, Jul 10, 2018 at 4:11 PM Bob Hinden > > wrote: >> >> Richard, >> >>> On Jul 10, 2018, at 7:21 AM, Richard Barnes >> > wrote: >>> >>> >>> >>> On Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern >>> > wrote: >>> >>> This formulation assumes that change does not have a >>> cost.  It does.  I >>> agree that not changing has some cost.  However, absent >>> indication that >>> the changes will actually address the claimed problem... >>> >>> >>> People are presenting indications.  Attach what caveats you >>> need to my little study; it's still real data from a relevant >>> population.  Do you have better data? >> >> >> When I saw the survey, after I filled it in, I noticed that I >> could do it again. There didn’t appear to be a mechanism to >> keep anyone from taking it multiple times.   Based on this, I >> don’t think one can draw any conclusions. >> >> >> Do you ever use telemetry from fielded products?  How do you know >> your competitors aren't feeding you bad data? > > You point is?  That your flawed survey is OK because there are other > flawed surveys? > > > I have a hard time seeing any survey research design that would convince > this group, and I think that Richard's survey is a non-trivial effort to > get some granted ugly data. > > As Richard pointed out, I guess I'm the noob here on the list, having > been attending IETFs since IETF 89 in London, about 4.5 years ago. I > must admit I still find so much of IETF a bit baffling... now that I'm > approaching my IETF adolescence, I'm starting to understand why certain > things are the way they are at IETF, and I'm thankful that it does what > it does well and thoroughly. (I've even chipped in on the IASA 2.0 > effort to help adapt IETF's administrative structure for the future.) > > However, the document series still baffles me, and I know a lot of folks > that squint at IETF and don't understand any of the distinctions we do > (I would have answered the survey question as there being only 4 > document series). Alissa had the unenviable task at one point of sitting > me down and telling me the difference between and ID and RFC, even after > I had thoroughly read the Tao and been to a couple IETFs. (The ID we've > been working on for a while I even named (incorrectly) when setting up a > github repository as an RFC: > https://github.com/josephlhall/rfc-censorship-tech ). > > I'll throw my hat in and say I'd like to see data, qualitative or > quantitative. I'm a mixed methods researcher and have experience in > both. I know a number of us have had enough informal discussions with > "liminal" IETF participants that there is enough confusion here to > explore doing something about it. That may not warrant an immediate > document identifier experiment, but I think we could settle on some sort > of research design that would provide essentially something like > "running code" we could work with. cheers, Joe > -- > Joseph Lorenzo Hall > Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] > 1401 K ST NW STE 200, Washington DC 20005-3497 > e: joe@cdt.org , p: 202.407.8825, pgp: > https://josephhall.org/gpg-key > Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871 > From nobody Tue Jul 10 15:20:21 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A4B1311C4 for ; Tue, 10 Jul 2018 15:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 MqNiJsR-qzB8 for ; Tue, 10 Jul 2018 15:20:14 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEE01311C2 for ; Tue, 10 Jul 2018 15:20:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 97AD71D1B87; Tue, 10 Jul 2018 15:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb4RYtVeKIo9; Tue, 10 Jul 2018 15:20:12 -0700 (PDT) Received: from www.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 44B5A1CADDC; Tue, 10 Jul 2018 15:20:12 -0700 (PDT) Received: from 84.51.152.6 (SquirrelMail authenticated user rfcpise) by www.amsl.com with HTTP; Tue, 10 Jul 2018 15:20:12 -0700 Message-ID: <91657556b6024545dcf3ba1ad18efa5b.squirrel@www.amsl.com> In-Reply-To: <20180710204512.GT20282@mx4.yitter.info> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> Date: Tue, 10 Jul 2018 15:20:12 -0700 From: "RFC ISE (Adrian Farrel)" To: "Andrew Sullivan" Cc: rfcplusplus@ietf.org Reply-To: rfc-ise@rfc-editor.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [Rfcplusplus] What would the ISE publish [Was: Conversation as metaphor] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 22:20:20 -0000 Andrew Sullivan wrote: > It is an interesting > question whether, if I wanted to publish an RFC about Wittgenstein's > remarks on colour, whether the ISE would consider it. We do have the > April 1st ones, after all. If the question is so interesting you could, of course, ask the ISE and get an answer. :-) To save you the trouble... RFC 4846 provides some good guidance that I consider a little loose. The list of document types in Section 2 starts well mentioning "Internet" or "IETF" in every bullet. But then it stops doing that (perhaps the authors got tired of typing the same thing?). In my opinion all IS publications must be related to the Internet and/or the workings of the IETF. That applies even to "Satirical material," "Eulogies," and "Meeting notes and reports". I'm open to a discussion of that, and the easiest way to test it is to write your draft and ask for publication. Until then, the only connection to the Internet that I can see is that "Remarks on Colour is considered difficult on account of its fragmentation," [1] suggesting that Wittgenstein may have had opinions on what to do when the link MTU was exceeded. Of course, I have not been in harness long enough for anyone to establish a pattern for what documents I consider in or out of scope. I will always be interested to hear when a document I am considering or publication is considered out of scope. Thanks, Adrian [1] McGinn, M. (October 1991). "Wittgenstein's Remarks on Colour". Philosophy. 66 (258): 435–453. doi:10.1017/S0031819100065104. JSTOR 3751218. -- Adrian Farrel (ISE), rfc-ise@rfc-editor.org From nobody Tue Jul 10 16:30:49 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C8B1311C9 for ; Tue, 10 Jul 2018 16:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 1qDw6SJuVSCW for ; Tue, 10 Jul 2018 16:30:45 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EAFF130E67 for ; Tue, 10 Jul 2018 16:30:45 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id x13-v6so7180068pfh.5 for ; Tue, 10 Jul 2018 16:30:45 -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=rPS5LeGdXMoswglnjf1ZNTQ/M0bz9l5j/g3LZ8dbQCM=; b=k0UmoeF8RPMOYzRjPoeGUsG78/rD/eCM2613iO5JAf4KQb6E4mu8CdE9xnpzl7J9VD J99eSBzhRSWNUbpov5f7BSmwmlziVXXfZT6CkQuAESOwnBdt93LbVVY46xInjNS0+rKr FUoEFMWD7icTHWIOuehYv4lMrxR+6IzDmtL9duRZvEDYrilhBdPI+w+dOomhJVVTEPbT hD1UQGw5oGn9+Gt/zKJqKNxv2Mzo2GUCwxVv6yvD+PRszUn+cRB8is0kh6c+AL88bdVN rJetmWmOniRf0NcOuktHBFdPDXZasjRJsWGXrdQedmu8/GnhvXE+hYZl5nXP6WJwidYY Zw4Q== 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=rPS5LeGdXMoswglnjf1ZNTQ/M0bz9l5j/g3LZ8dbQCM=; b=ZWVjzJI/TxYQaxWoL+/jrOAwuYTisk/EGDFCg5EcF/wZrgeeww6VE3frRZ2vwCt7uo DVu8ccu368PF/8xZpn/sjrQE0bPap2G2a1IdF0kRgl/8l7PmX6Gy4eQp8h56QWMEffu+ rgE6SEhjZi7BK5aEvEwm5DEcIJ0vbk5auuB6+oTLMgcpI9GHqhmCLX6ByWr5d0EDs/m3 KBQ0EMPGg55lVvGL1XRev21hZL2Id9G3ESjxWReVIdqyUK6I8AjzgJ3Jq+dh2EUdzmCS 8mzNFQpuklmIkwEtDp45EyIkdD8PVlx28NoX6ah0XmSOT4mn0mk6Fv99SZY3tR5lX2Xn rrWQ== X-Gm-Message-State: APt69E0zbj4Vg6o/tPqnVwOWYAd4IMdUx64MRlO8WrJyjZCR5FZuh7Tn neltScEcEM0pA9/YbcanSfQ= X-Google-Smtp-Source: AAOMgpdBrai7Fz7qDNxdJ8GKZwH5AEAJsFlRYcON//5dvqD9M1Dfv3/EohHFqRbAUXOdQOAKkHpRaw== X-Received: by 2002:a63:383:: with SMTP id 125-v6mr18791021pgd.421.1531265444765; Tue, 10 Jul 2018 16:30:44 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id d23-v6sm43127626pfe.2.2018.07.10.16.30.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 16:30:43 -0700 (PDT) To: Alice Russo Cc: rfcplusplus@ietf.org, Robert Sparks References: <888b184e-51ea-23fc-afaa-f9b5116d480a@gmail.com> <0dbf07da-969c-9704-9618-8d3d7ff03004@nostrum.com> <7787043f-1ab0-f957-2d26-e915009c4d3f@nostrum.com> <10f6771e-7de6-530d-0c7b-4b347a23612c@gmail.com> <515C68DD-F55F-49E5-97E7-569C0815462B@amsl.com> <3A370D7D-B731-4AA3-AC69-4F0826258217@amsl.com> From: Brian E Carpenter Message-ID: <3b96e796-d30a-394a-79f1-baa38913be4a@gmail.com> Date: Wed, 11 Jul 2018 11:30:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <3A370D7D-B731-4AA3-AC69-4F0826258217@amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Qualified labels X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 23:30:48 -0000 Thanks Alice! Actually this glitch makes me think that completely regardless of the imminent BOF, we need some sort of shared format for the ephemeral "wrapping" of an RFC including current and previous status, and dates. Not a topic for this list, however. Regards Brian On 11/07/2018 07:35, Alice Russo wrote: > Reporting back re: RFC 5289. > > [FYI, the IESG has been sent this information separately.] > > We received the Protocol Action mail 20 March 2017 to change RFC 5289 to Proposed Standard, but the status change was not carried out. I apologize for this mistake. > > At this point, the underlying data and derived displays have been updated. The info page [1] and the list of all RFC status changes [2] show "March 2017" for this change. However, if the preference is "July 2018" to reflect when the RFC's metadata was updated, please let me know. > > We'll review the mails re: status changes received thus far and revise the process for handling them (as necessary) to prevent this in the future. > > Typically, a notification mail is sent to rfc-dist and ietf-announce when an RFC moves up in the Standards Track (in this case, onto the Standards Track). We'll send that shortly. > > Thank you. > RFC Editor/ar > > [1] https://www.rfc-editor.org/info/rfc5289 > [2] https://www.rfc-editor.org/status_changes.php > >> On Jul 10, 2018, at 11:40 AM, Alice Russo wrote: >> >> On Jul 9, 2018, at 9:53 PM, Brian E Carpenter wrote: >>> >>> ** However, you have hit upon a bug. The IESG may believe that >>> they upgraded RFC5289, but it seems that nobody told the RFC Editor, >>> since it is still officially listed as Informational. Even the tracker >>> is confused. So we have a procedural glitch in this area already. >> >> Indeed. >> >> I am taking a look at what happened here and will report back. >> >> Thank you. >> RFC Editor/ar >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >> > > From nobody Tue Jul 10 16:46:25 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BE9130DDC for ; Tue, 10 Jul 2018 16:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 srxZNATdxXLU for ; Tue, 10 Jul 2018 16:46:20 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4811311CF for ; Tue, 10 Jul 2018 16:46:19 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id w8-v6so8305615ply.8 for ; Tue, 10 Jul 2018 16:46:19 -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=mzJk2m4oqvzYXQh9aA2O1fOJYN1nmok8AFZVz/9Cjgc=; b=tUYNJrL5O0eNKt/tMf8mVaYWoqPyzbU2tiAtmBy8Zr4DulS5qOxSzgX7qgb9HeEKU5 wSXpXPEvosiXBxxUqKjTAq1iRzlk1NVDOTfWgRkI0BztFYnDW5dIBRsUdMcVyXf0s5hg Yls+ugqgx9VIrJLUZOOvkDM2bIViGM63ChDaCO9GTjABxRPoylBScziIrB8/1x4xMKMT 5aDONARgFPH6ZCGVwywktc6/7dgWNUtUPnXrSB5Fc51XJtUSrCi3C+uklfnWuA3UYmxD ZWam2CFeLzh2S9SgE3SdqzTbIHemC9Fose+w7YkOAMWD/OPmwMp2z17IGxnpYOuJtTeI JIlQ== 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=mzJk2m4oqvzYXQh9aA2O1fOJYN1nmok8AFZVz/9Cjgc=; b=jvbq20pMzEMqzaouHD5EDfpSbu2Avsu0uk9zrCuB6wSYsXEJ9VPeiDiFmfYgCeRelU FW4BqPO18saFX6b1ypMrwfs5TVp6A5DGk82py2rWv3CzgoR2saGTm8NJNJfRQPFZm7fj N0OMuwmqGh1FB1T4+lNYNZL7rJUMurQ4ltVhe8EKFlCp6HCNvJ8EYw5eqgsLLNWC2cks uFm7kJtkmneUvCj9nEGnLZ3buj8Ts1RZZmsGCNQWEoItWykDvLMBO48XPKMG68YM0RHH YIpmJHHo7TxdF3wXvok9zhiGN2Qx79U1R43mbNAo5kc42gy/W9ux9ktysto2Sh8R7qfT iE1A== X-Gm-Message-State: APt69E0Ky7ueJhuRntw9FUQHskA9ekVsGoj3LNXiBho865D56QaaIu47 7MFPycYZq3jSBOXnwIGSdfLVKQ== X-Google-Smtp-Source: AAOMgpfMkDkZBal7QHd1rACaM/OhShal0j+cz26lY/XRU+Y3fQ2YjoOq//bhK02MQY3Ce9YqsCTD7w== X-Received: by 2002:a17:902:7043:: with SMTP id h3-v6mr26594163plt.269.1531266379100; Tue, 10 Jul 2018 16:46:19 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id t3-v6sm33372773pfk.161.2018.07.10.16.46.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 16:46:18 -0700 (PDT) To: rfcplusplus@ietf.org References: From: Brian E Carpenter Message-ID: <9cc8662e-fe1e-f26f-a55e-1f654309917d@gmail.com> Date: Wed, 11 Jul 2018 11:46:19 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 23:46:24 -0000 On 11/07/2018 06:15, Ted Hardie wrote: > Howdy, > > On Tue, Jul 10, 2018 at 11:06 AM, Eric C Rosen wrote: > >> On 7/9/2018 11:24 AM, Ted Hardie wrote: >> >>> the academic community's failure to value the output of the IRTF >>> >> >> I don't understand the relevance of this issue to anything being discussed >> here. >> >> If a RG wishes to publish its output in a respected academic journal, I >> don't think there is anything to stop them. >> >> I meant specifically "output as RFCs", sorry that wasn't as clear as it > needed to be. > > >> Maintaining the current publication process for RG output but changing the >> name from "RFC" to "IRTF-Masterpiece" is not going to make any difference >> in how the academic community values the work. >> >> > That's not what others are saying. The problem as it has been explained to > me is that tenure committees and similar academic assessments look at the > output of the individual in part by looking at where the output has > appeared. When it appears in a series which looks to them to be primarily > engineering specifications, it is not valued as highly. A differently > labeled series which was entirely composed of research output might be > valued differently. That's highly unlikely. Although the whole business of journal impact factors and the value of conference publications is mainly pseudo-science, and the whole question of open-access journals (where the author's institution pays) versus traditional journals (where the reader's institution pays) is very contentious, the chance of a brand new series from the IRTF breaking into that game is vanishingly small. (IMNSHO, of course) RFCs have a 50 year history and are in fact widely cited in academic publications. My own 2nd highest citation count** is 422 for RFC1958 (unfortunately, most indexes have me as author, not editor). My highest non-RFC citation count is 153. **according to Google Scholar. Brian > I agree with Eliot's earlier point that this is a "might", and that the > value ascribed to it depends not just on its output but on the work done to > highlight the stream's output. > > regards, > > Ted > > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > From nobody Tue Jul 10 18:36:17 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5BA130EAB for ; Tue, 10 Jul 2018 18:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=CUHdmUY+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ktHK5rIh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RwHaw5-meyL for ; Tue, 10 Jul 2018 18:36:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06359130DD6 for ; Tue, 10 Jul 2018 18:36:13 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 67B2421B46; Tue, 10 Jul 2018 21:36:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 10 Jul 2018 21:36:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=7tGLcO3CL12YzRKXH1Xw8UqXUeRJa KnnyVgiP3TzAn8=; b=CUHdmUY+d9aTo0c7UrY5H9Ow26BzD6KlC3M6sLFgs8tT+ hDodsa3dJ3Xsp/ejI6IHmDj68r+zA54D5esT2HGxSm4HCSc6b/71GIHB8ffp+cp5 E/dX/q4mJuyt8oVYOq5Vf9AVCeAgQOGFtP62dHFcRVJrmPp1yOQU11gylgVOsCzW 84p2oSkmO7I1r+iI+bXLZlvCIMdX/NuhRpgUnQ47YCDHxvn3qd8WLFNeIYX7LEVq xRoavH8HO/6hHt5xAdJds627B+JOSb+m/69vYpxxtIj0dSU5Tg8uYxk49BFZ1Q3l sGLVT58b27VG/lsWdaE1ZySdkd9CU77AerBOuW9rg== 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=7tGLcO 3CL12YzRKXH1Xw8UqXUeRJaKnnyVgiP3TzAn8=; b=ktHK5rIhNSst7cZ9BloXss +MZcSNm7cVKD2Xn6k+mkeknC+BcxjZolVpuF6eQgf6yrnoOAQ04u493BwLxXpHTE xYBN9vdrmYWZPw2FlKxJYsqtNI+U3+EKoUMPkQHFlXA+f0QXSxb8XM8rXOcC4BrB QV+TbP2I/4GDSaBz/OythPsGylxSo4my5WrViDeW2M/CWMFE/F/B/ZaFTAWrCrI/ FQHEVKxfaRchjYDyVtmxT8hpJQnPrbAjfzJksjNoo+0oCwCMVL9SSSs0f6vRHA8c V/4SwitsLjVGo80PblHZ8nPnSe0popk1cRwGiy2z7SdL/Dqj0bMTUVKIY/x32l9g == X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id C0CD810285; Tue, 10 Jul 2018 21:36:11 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Alissa Cooper In-Reply-To: <417f8cb3-f42f-2d65-554a-ae330cd9e2c6@joelhalpern.com> Date: Tue, 10 Jul 2018 21:36:09 -0400 Cc: Joseph Lorenzo Hall , rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <553E8AC4-CEDB-42BA-9071-705B19EFBF24@cooperw.in> References: <639B8766-A030-490D-8431-C3F9F3EAFCB4@gmail.com> <8B48E5E5-90DC-423F-83C7-9B51A853A1A8@gmail.com> <417f8cb3-f42f-2d65-554a-ae330cd9e2c6@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:36:16 -0000 Hi Joel, > On Jul 10, 2018, at 6:18 PM, Joel M. Halpern = wrote: >=20 > Thank you Joseph.Yes, it is confusing. > And it is confusing in many different ways for many different reasons. >=20 > It is very strange to have a BoF about such confusion, and then be = told that various specific forms of confusion (such as I-D vs RFC whcih = you cite, or different kinds of I-Ds which I mentioned) are out of = scope. In my experience arguing about the scope of the problem is pretty = typical BOF fodder, so in that respect this one does not seem unusual = thus far. It=E2=80=99s true that the BOF description keyed off of the problem = statement in RFC 1796, which doesn=E2=80=99t mention Internet-drafts. I = don=E2=80=99t think that makes confusion about what I-Ds are or whether = they are standards out of scope. These also aren=E2=80=99t mutually = exclusive problems; tackling more than one of them seems like a valid = outcome if that=E2=80=99s what the community wants to do. > Apparently, we know which problems are important to the community = before we have the discussion. I=E2=80=99m not sure who you mean by =E2=80=9Cwe,=E2=80=9D but I don=E2=80= =99t feel like I could draw such a conclusion at this point.=20 Alissa > usually, we get that information from the email list discussion with = the community before a BoF is requested. >=20 > Yours, > Joel >=20 > On 7/10/18 6:05 PM, Joseph Lorenzo Hall wrote: >> On Tue, Jul 10, 2018 at 5:51 PM Bob Hinden > wrote: >>> On Jul 10, 2018, at 1:56 PM, Richard Barnes >> > wrote: >>>=20 >>>=20 >>>=20 >>> On Tue, Jul 10, 2018 at 4:11 PM Bob Hinden >> > wrote: >>>=20 >>> Richard, >>>=20 >>>> On Jul 10, 2018, at 7:21 AM, Richard Barnes >>> > wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern >>>> > wrote: >>>>=20 >>>> This formulation assumes that change does not have a >>>> cost. It does. I >>>> agree that not changing has some cost. However, absent >>>> indication that >>>> the changes will actually address the claimed problem... >>>>=20 >>>>=20 >>>> People are presenting indications. Attach what caveats you >>>> need to my little study; it's still real data from a = relevant >>>> population. Do you have better data? >>>=20 >>>=20 >>> When I saw the survey, after I filled it in, I noticed that I >>> could do it again. There didn=E2=80=99t appear to be a = mechanism to >>> keep anyone from taking it multiple times. Based on this, I >>> don=E2=80=99t think one can draw any conclusions. >>>=20 >>>=20 >>> Do you ever use telemetry from fielded products? How do you know >>> your competitors aren't feeding you bad data? >> You point is? That your flawed survey is OK because there are = other >> flawed surveys? >> I have a hard time seeing any survey research design that would = convince this group, and I think that Richard's survey is a non-trivial = effort to get some granted ugly data. >> As Richard pointed out, I guess I'm the noob here on the list, having = been attending IETFs since IETF 89 in London, about 4.5 years ago. I = must admit I still find so much of IETF a bit baffling... now that I'm = approaching my IETF adolescence, I'm starting to understand why certain = things are the way they are at IETF, and I'm thankful that it does what = it does well and thoroughly. (I've even chipped in on the IASA 2.0 = effort to help adapt IETF's administrative structure for the future.) >> However, the document series still baffles me, and I know a lot of = folks that squint at IETF and don't understand any of the distinctions = we do (I would have answered the survey question as there being only 4 = document series). Alissa had the unenviable task at one point of sitting = me down and telling me the difference between and ID and RFC, even after = I had thoroughly read the Tao and been to a couple IETFs. (The ID we've = been working on for a while I even named (incorrectly) when setting up a = github repository as an RFC: = https://github.com/josephlhall/rfc-censorship-tech ). >> I'll throw my hat in and say I'd like to see data, qualitative or = quantitative. I'm a mixed methods researcher and have experience in = both. I know a number of us have had enough informal discussions with = "liminal" IETF participants that there is enough confusion here to = explore doing something about it. That may not warrant an immediate = document identifier experiment, but I think we could settle on some sort = of research design that would provide essentially something like = "running code" we could work with. cheers, Joe >> --=20 >> Joseph Lorenzo Hall >> Chief Technologist, Center for Democracy & Technology = [https://www.cdt.org] >> 1401 K ST NW STE 200, Washington DC 20005-3497 >> e: joe@cdt.org , p: 202.407.8825, pgp: = https://josephhall.org/gpg-key >> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Tue Jul 10 18:57:13 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12E1130DFB for ; Tue, 10 Jul 2018 18:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=qK9lmwfJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZKP2OVHu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tF1OgzEgqth for ; Tue, 10 Jul 2018 18:57:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1677130DE8 for ; Tue, 10 Jul 2018 18:57:08 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1B21021AF5; Tue, 10 Jul 2018 21:57:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 10 Jul 2018 21:57:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=RtDJLmgRsey1iEW2wMjlASo0YY3Zd JQ1djEs3UHxo1g=; b=qK9lmwfJBaMagwkjJznOZ59+iGXq/Pk4F2XBPVvVJCk9Z qkfF7Wpm3Tiq+AMoboJeUgZ9f6lJPBmUGkF3KSmBUet8K7FTc6LffXqNLaxNN8Gv W84gSAxymGCJ5rheqANjJGO62nsOzvSUyital7EwtOaO4BaV6eU+A8ySlST4zQrV fk6fp7nA3mcTKHOJGnv9ukBHJX1TgTad0mweq0VzwbgX3fJUpGGQR1EyXge2WDNt jHSyCq0PkwNjpmsD9eje/+Mi6xIsX0zJj6aE6LKIM/JTgjszh6em2nBLbpLShrpC sZoBM6zHrpwoPTNTcneSsA2ptUSamU4OC9mEdjGWw== 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=RtDJLm gRsey1iEW2wMjlASo0YY3ZdJQ1djEs3UHxo1g=; b=ZKP2OVHuQSCEX6ZveOanUG CokI0c43nueY1mQgC0oKoHVbbs3O9WHEu5S5dl9RYBPhzh39s3G8O7hdvtqXukPY XRZzPsUYsNAoPiZoV4GGJa2uTLLB9BlKzapiMDNrvG83WdA71MWdbktN6JEjAvHf Nf/buVo8s+ova+DZYbYXb9eXJIQR7rsXc7ha2UKaDXwZOVKul+oWM3l8s+rmTAZA 8zplqJonAtVF+N0osXwFT0BqQK6mKNy/jkStdM8F8fXqBfS8mSsjDeunYwPcBjYP UnenVsaWyfPSA68Mf4oRBek0XNahVHYOAtSqO+B7de3FBYrE6ZCFoJBrxASuaQFw == X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id 8E96D10268; Tue, 10 Jul 2018 21:57:07 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Alissa Cooper In-Reply-To: <03e201d41785$5cb85320$1628f960$@olddog.co.uk> Date: Tue, 10 Jul 2018 21:57:04 -0400 Cc: rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <010FCCF0-A8B0-4909-8086-68A13F30C55E@cooperw.in> References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> <03e201d41785$5cb85320$1628f960$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:57:11 -0000 Hi Adrian, > On Jul 9, 2018, at 9:04 AM, Adrian Farrel wrote: >=20 > [snip] >=20 >>> Now, it might be thought (this is possibly a branding thing) that = the further from=20 >>> looking like an IETF consensus document the less we have to care = about the=20 >>> "protocol conflict problem", but I would argue that the less input = the IESG has, >>> the more we have to worry. Thus, were an alternative venue for = publishing >>> competing specifications to be developed, I would claim that this is = harmful >>> to the RFC brand and to both the IETF's brand and raison d'=C3=AAtre.=20= >>=20 >> I=E2=80=99m not following this. If someone cares about how the = Internet works, then >> having a poorly designed specification that risks the Internet=E2=80=99= s stability published >> in any venue is a problem. That doesn=E2=80=99t mean the IESG or any = individual=20 >> participant is necessarily going to be able to address that problem, = but it=E2=80=99s still a >> problem. Having that specification labeled with =E2=80=9CRFC=E2=80=9D = means the IESG and the=20 >> IETF face the potential additional problem of having the = specification confused >> for an IETF consensus output. >=20 > I'm trying to avoid looping the discussion or coming to any early = conclusions on the right answer, but I will push again on this... >=20 > I believe I read you as saying that the IESG would not, as a matter of = course, read or consider FOO9002 on its way to publication if that = publication is out of the IETF Stream. They would not expect to be = notified of the progress of that work towards publication. In some = cases, the IESG might become aware of the work and have comments that = they wish to send to the publish body (such as, through a liaison = statement). While the IESG might have some hope of being listened to, = they would have no expectation of that, and would, in particular, not = request the inclusion of an "IESG Note" in any such document. Actually when I wrote the above I was thinking about it in the present = tense. Documents get published in other venues today =E2=80=94 other = SDOs, web sites, journals, etc. Those specifications might risk the = Internet=E2=80=99s stability. That is less than ideal, but the ability = of the IESG and the IETF community to prevent it is limited. I think one = difference between such a document and the exact same document being = published with an RFC number is that the chance of the RFC being = confused for an IETF consensus output is greater than the chance of the = non-RFC being confused for an IETF consensus output. So I wasn=E2=80=99t = commenting about a hypothetical change of series identifier, but rather = the difference between documents in other venues (where =E2=80=9Cvenue=E2=80= =9D means something outside the scope of the current RFC series) and = RFCs in the current RFC series. I do have an opinion on IESG notes and conflict reviews if the stream = identifiers were to change but it=E2=80=99s not my opinion that matters = here so I=E2=80=99ll keep it to myself. :) Alissa >=20 > That was the clarity I was hoping for. >=20 > My point about branding was manifold: > - The IETF would like to remain *the* source for documents that = describe and define the Internet. Any action that weakens that (such as = by giving another venue or publication) is unfortunate. > - The IESG would like to remain authoritative evaluators and = commentators on the merit and consensus of Internet standards > - "RFC" as a label may cause confusion as to the source of the work, = but buys the ability to influence the content by review and input. >=20 >> Alternative venues for publishing competing specifications already = exist (e.g., >> https://url.spec.whatwg.org/). They may or may not be harmful to the = Internet, >> but I don=E2=80=99t see how they=E2=80=99re specifically harmful to = the RFC brand. They=E2=80=99re certainly >> not more harmful to the RFC brand than competing specifications = labeled =E2=80=9CRFC." >=20 > It needs to be noted that the non-IETF stream sources of RFCs = constitute "venues" for publication. The proposal on the table opens the = gap between those venues and the IETF. That might or might not be a good = thing, but it is important to understand the implications. >=20 > Adrian >=20 From nobody Tue Jul 10 19:04:50 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56D5130DD6 for ; Tue, 10 Jul 2018 19:04:47 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Q-I_KlooCM9u for ; Tue, 10 Jul 2018 19:04:45 -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 D913212E039 for ; Tue, 10 Jul 2018 19:04:45 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id y5-v6so2472320pgv.1 for ; Tue, 10 Jul 2018 19:04: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=LjLMXNXljeCGhQVhBVQJsdep4gidQVGAHKvnTu67xEc=; b=HFghUeuI9cg8CunVdPo1e1iG0snGZVX+bgJTONJfsI/f/otluzYqCxS/6eBqVob+DV IwuN83TRS606l1+Db//JxgZKNnMzIRUDYU0zRwUMZOK4ewHixU+6oaeYRWW3r+JW2yjp 7bPELYKzEyqLd3Kb+R3W5ebbY0c8OgcakEDbeoCa++Fp8rDRIcYrboVEfORr5kXDYW7r vsWVH2+gmBN9vyZOsrknKE/NfODNfvIFa9EQT0eFZ5uqbSqekj1bYKsLUxvhK6IP+Rjo fYpoj1/64JLFrky1XBi1RY5SyFe1kx+/6c984ZmKoausHFrkppfo05Cfr6R6FhtTp+7T q58A== 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=LjLMXNXljeCGhQVhBVQJsdep4gidQVGAHKvnTu67xEc=; b=WkVikTSoTWyV2GiEDxEOF5to/fPgZHuEzp35wXq3hZm7yG2ynGQvEIxi2WWgHBvFM5 LpMQbdY/vAJH4RCVnORw//KKACEaPFf4s3nXyplKjOQKV0RPcdzVcF3K004bD4g8gY2Z QwiKnb31xsYFd7MYncEs6pTRaZkIlnIbMH/QDftKwmel7aj52p5LeCMgZTzZGZgmOtWP fJ4spLHFs/UJ58yuz5P7RUllyZH0cP49Wrm6KRtN/X1CKcVRiZGTCDuPiqE25vDRgPjC kbE8z0AbIahJFr3Z6aiDquttH6Rnbgz4TAs8YoprgDid0xXRDSaoUYsgdsJPFTEY0GHP 3cRA== X-Gm-Message-State: APt69E3O7VqGg2nI7paiLnA/7xUM/1d+pLBlp2ezSljMuhNmvELdX67A Ory6o2g/QYQBmSL3lUJ0HYE3Uw== X-Google-Smtp-Source: AAOMgpdEzVRlYDjrZkOWBQSdJDCtEjaBLR7pC3+AIe1ke1cEvXIDhjxGXwtxKDxVca9OsoI70ovIaw== X-Received: by 2002:a62:229a:: with SMTP id p26-v6mr10271431pfj.53.1531274685141; Tue, 10 Jul 2018 19:04:45 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id j72-v6sm37563856pge.19.2018.07.10.19.04.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 19:04:44 -0700 (PDT) To: Eric C Rosen , Andrew Sullivan , rfcplusplus@ietf.org References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> From: Brian E Carpenter Message-ID: Date: Wed, 11 Jul 2018 14:04:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 02:04:48 -0000 On 11/07/2018 07:58, Eric C Rosen wrote: > On 7/10/2018 3:28 PM, Andrew Sullivan wrote: >> One thing we_do_ have some data about is the low regard in which the >> RFC series is held in many academic contexts, because it is not >> considered a peer reviewed publication and because it is often >> considered a series for technical standards rather than for academic >> research. >=20 > If the IRTF determines that it would prefer a different publication=20 > venue, I certainly have no problem with that.=C2=A0 We shouldn't force = > researchers to publish their work as RFCs.=C2=A0 (I didn't think we did= so,=20 > but ...)=C2=A0 If I were a researcher, I'd probably want to publish in = a=20 > reputable academic journal, but perhaps my academic experience is a bit= =20 > dated. >=20 > But that's really irrelevant to the main topic of this discussion. What= =20 > we are primarily discussing is whether we should prohibit folks from=20 > publishing RFCs when they want to do so and find it valuable to do so.=C2= =A0=20 > That's a completely different question. Indeed, and that (to repeat myself) is something that the IETF and its committees simply cannot do, since the RFC series belongs to a much wider= community. In that sense, the entire discussion is out of order. Brian From nobody Tue Jul 10 19:10:39 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7018B130DE8 for ; Tue, 10 Jul 2018 19:10:37 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 8W9cGZlq_7Ie for ; Tue, 10 Jul 2018 19:10:36 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E032112E039 for ; Tue, 10 Jul 2018 19:10:35 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id 31-v6so8435455plc.4 for ; Tue, 10 Jul 2018 19:10:35 -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=CfI2fteQRgN5vmGBZWXkFgPHGCPGX3ETdHwn/VZQbb4=; b=F0GCw/Y2v7pxsDT++RH4L0d/90avQex4NLa7s1qLC1lIYXoUXWMC7nAJbUqw6CDnq8 HSg2SRPTTMH+8EkEl1D3b3ogmYmswmRx0k7fzOcf3gqx/yANrOGKnRmqlOeblKvmofSD k78WI/6hPqdIkb47F5eiGuU3S03WR1yZbQ2HxZ01xsmyBZ0TGTindSiXCKZUY1/MtqV9 K1DUED2lhofBmLx7/t9bezPD4IbZcOLr3DY0WT1WMyIMWFO5sfivX6fc+9wX4XwVNTUv 9/NoPtDggBU1zmGxBUX1oA2fW7wwhtyaJVnk23QyTbZIj16GFUQSfhJyGLaAONslqmxA 6drQ== 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=CfI2fteQRgN5vmGBZWXkFgPHGCPGX3ETdHwn/VZQbb4=; b=Hde7d6liwp52jwapfduZ5HAEm5IKUtH077cRVsuMGdAP3FakEJvYlZYDcILqq9sSRr EdZx/W/Is7QgKrM85qaiQrwbe8SHbzTHKBNy551YvVwj1Afecq4TH1Nl8gDtCRTAmkDZ PKVzdOzxgdr/iS0JUQB56qLa1ucv06waNiHKavUNeFFjRTtPf1V1oAit8il6vtEHarUO jLZqnBvHpUIVpVimjFYQA7NGwe4tNWgbc1HrUbX0695VOvCbOyXlUSWhqbRwMWDM2yXI W6QlfBKZcOQjgtpiM8L3Cx+cyiMWtTG0zi8IueJYc/kiZPoZXuptsP+0VY8wu09T2+Sb WlwA== X-Gm-Message-State: APt69E1DuA2uIr5z2tL0tJxN6k4EGjUthk9rFIZCv2b0FxHtckABvmbX IxdPLwUyNJI9Kwb0vR20OVI= X-Google-Smtp-Source: AAOMgpdLmFCQnNLAFlsblCaPg9ydARL0P8JD5hzby1rYQ1w4wyqMAvk5Loz+UbOiLrQxWQ+OL+iaCQ== X-Received: by 2002:a17:902:3e3:: with SMTP id d90-v6mr26963051pld.12.1531275035410; Tue, 10 Jul 2018 19:10:35 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id p20-v6sm27966871pff.90.2018.07.10.19.10.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 19:10:34 -0700 (PDT) To: Ted Hardie , Eric C Rosen Cc: rfcplusplus@ietf.org, Andrew Sullivan References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> From: Brian E Carpenter Message-ID: <3d5402df-5fd6-43b8-f75e-0423253bb07e@gmail.com> Date: Wed, 11 Jul 2018 14:10:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 02:10:37 -0000 On 11/07/2018 08:09, Ted Hardie wrote: > On Tue, Jul 10, 2018 at 12:58 PM, Eric C Rosen wrote: > >> >> If the IRTF determines that it would prefer a different publication venue, >> I certainly have no problem with that. We shouldn't force researchers to >> publish their work as RFCs. (I didn't think we did so, but ...) If I were >> a researcher, I'd probably want to publish in a reputable academic journal, >> but perhaps my academic experience is a bit dated. >> >> But that's really irrelevant to the main topic of this discussion. What we >> are primarily discussing is whether we should prohibit folks from >> publishing RFCs when they want to do so and find it valuable to do so. >> That's a completely different question. >> >> > I must respectfully disagree that this is an irrelevant question. The > proposed experiment would establish new identifiers for the work of the > IRTF currently published as a stream within the RFC series. That output > might (and I acknowledge again that it is only "might") change the academic > assessment of that output while retaining its other characteristics. I > personally believe this question is thus on topic for a discussion of the > experiment. Ted, It would be on topic if there was a proposal inside the IRTF to change the publication venue for IRTF output. But this is an IETF BOF so all we can do is discuss how IETF stream documents are published. I know this is an inconvenient truth for some people, but there it is. Brian From nobody Tue Jul 10 19:14:59 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4201310D3 for ; Tue, 10 Jul 2018 19:14:50 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 MWDFbFy7WrDN for ; Tue, 10 Jul 2018 19:14:48 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A613D130EB2 for ; Tue, 10 Jul 2018 19:14:48 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id b17-v6so17343241pfi.0 for ; Tue, 10 Jul 2018 19:14: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=X+nw7ZXYwbcOKtmuJ5g5QL/LLabQKqtZji9v9y7+bGE=; b=mXR5AL6f/b6rX7oYFa8q1nHUHhrH4u53kVFVDAKkwOVatCu89CART+iC1V3Cxae8xr tiOUH9XbnOMX92Mxq9cBnXF0TMIcQMfZAlLYk3b/4iUS8U9zQKg4a1h9TFfu7UQMuTRP TItL8QnX+egfuiyW/Lxn4qK02Wg0yNHqn54v3zoeMGyOtHNtwhWsSWV/LeSvNBs4r4zS 3FtP9MvC2z/tfwxkK32/TGIKMyRkjYWKFQGFnv2u2+vA8c/7e6hrRauSNyLY7pDe82io 2aymLPJOfcIJ5G+e8SvKivTaal4/DOs/uHHpWhuD/JZHiyK6OzMPuan8Gnp1BXC7Ijzh csxg== 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=X+nw7ZXYwbcOKtmuJ5g5QL/LLabQKqtZji9v9y7+bGE=; b=MZuM4mTWUbNWHloGKFwh21xSuPji3dwAC+CoRuuszflP5pgLlkJYAoTQcdfelm8FBa yO+8FRtP1YXLEURl1B3f8wS3ox0gm/YkLU/0WA2hkxd+dllm7TDluN7OV9R2y5vbk0aH 1poIiyuhwMsSsSXovoY1yGoXDq+/DJ81PD+FEa/mXR/WuN3owo1GPRT2YWFTNmFOg2Cz p7ogU1BnXdizHdCclbkPDVAYCZuQtECjWNHzprCW8pegu4D0hmOgHsYHOxv17EWD3VPl MP6LXVLPWVPfbanjvDIdk2QqT5MLVTDsGfV2u5Knr8ytrTOmwO5GYN623I3cBNI1urYS BcwA== X-Gm-Message-State: APt69E3DpjPcbNfgtQ7kJKnio3YscXYvPNeZut7JmXwlJyco48Rm2GP0 jjPElMYNtSwQ4RpN+6fLCqdZKQ== X-Google-Smtp-Source: AAOMgpdn7ojkCFhVot2xPy/0hHGd96i29gKqrvzuERNGnTKLo+6dOVczIalV/K3tXZhCr16tZgTpHQ== X-Received: by 2002:a63:6e0a:: with SMTP id j10-v6mr18927860pgc.321.1531275287994; Tue, 10 Jul 2018 19:14:47 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id j129-v6sm33211359pfb.113.2018.07.10.19.14.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 19:14:47 -0700 (PDT) To: Andrew Sullivan , rfcplusplus@ietf.org References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> From: Brian E Carpenter Message-ID: Date: Wed, 11 Jul 2018 14:14:49 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180710204512.GT20282@mx4.yitter.info> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 02:14:58 -0000 On 11/07/2018 08:45, Andrew Sullivan wrote: ... > Others seem to be arguing that the RFC series should in fact welcome > anything on any topic, Really? I haven't seen that and it seems like a strawman to me. The Independent stream has criteria that have already been mentioned here; relevance to the Internet and surviving peer review are among them. > and as long as they can find someone willing to > let them in, there's no reason they shouldn't be in the RFC series too > (i.e. we shouldn't prohibit people "from publishing RFCs when they > want to do so and find it valuable to do so"). It is an interesting > question whether, if I wanted to publish an RFC about Wittgenstein's > remarks on colour, whether the ISE would consider it. We do have the > April 1st ones, after all. But even they are tested for relevance to the Internet and are peer reviewed, just not in public for fairly obvious reasons. Brian From nobody Tue Jul 10 19:19:49 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E565130DE8 for ; Tue, 10 Jul 2018 19:19:47 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 6ofY4bct9eFD for ; Tue, 10 Jul 2018 19:19:45 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9DA130DCD for ; Tue, 10 Jul 2018 19:19:44 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id c131-v6so12698374qkb.0 for ; Tue, 10 Jul 2018 19:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NSpDppIJ/rTmN7ktaAGvJmFGZKiaMiXFCQjhWfPaWhQ=; b=MlJEeiqlNweFV1AR7Al7hmSsaBIr857uCuqS0tofCsjgZ3xz8rkTwM+kutXBSBztlG mAbcb4Z2J5eVUdGa5Uc45imC/8U+sDtifObTvll4WC1dj+DtAXXYarwp60Q4loPilZa7 Xho0At6hBhz4elayzfjIODq1Hi4rgK4lBBBPwQUfnQCpN9I+yRtd5twbHuQnueCPi3pJ ZUcu6nBkLDjJ5cspzyB0NXI2MaX+U1PvsvmQUKDZrYXgG8QSoh59QeHujD4nARw9TBts HIuqq/b2EsDCZBh3sR6jdQQErFVV6T8Br+RPnOdwPV2UQJwnEvZiiP9MiqKi3N1sD0V3 tJnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NSpDppIJ/rTmN7ktaAGvJmFGZKiaMiXFCQjhWfPaWhQ=; b=nkCBAXXu0nDobtSfACUeYbqvOGIfBTAEdiPQrLGm9IGuzVC65+k7v+h9O7SaW13oYq xsj66xvRmOLsUcghJmB8HbRIM7YFu1bnHjBZ9TVljUAXjinZRnkcmMnGlNk6XXZQd1VF rK6+ldL1yUrQ3sbnSPJvo6/+IdYuVKb+ea/zGHbvZnIMe+R3yu0mQWPf6Urtr/eIdDdM R+U1gQKJMmVEPektllrunOuhsZpj+RCztlz1bLUwyT8NMfPDgsLRpPyW34QwKE2T+ydf aMdsCxG5QG3afPfkNKxSQoEZgv411CQREdQY7wKEau55XiDV2u9c0CgLSnP8sfp1QbUT 9CrQ== X-Gm-Message-State: APt69E1+h9JaxrT3eR3finRJejKwUoNefR0HXUPkoODcN2KE5m7QErQK VNFPyxIGPhrtVI9C1K8V2Od3TzFb X-Google-Smtp-Source: AAOMgpdAX5A7dwXZMYtsbbYrFuJH61RVw1mDQrWNJfhUfcu9GYzdXA7Hwdx+GvZEFnFy82Qw04/a4A== X-Received: by 2002:a37:6b84:: with SMTP id g126-v6mr14370135qkc.231.1531275584119; Tue, 10 Jul 2018 19:19:44 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id 3-v6sm15567569qts.31.2018.07.10.19.19.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 19:19:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: <4444ba48-a52b-00c3-6770-e9cab66eacb2@rfc-editor.org> Date: Tue, 10 Jul 2018 22:19:42 -0400 Cc: rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <31C349A4-5A87-40A8-B8E3-8B695688C0DD@gmail.com> References: <4444ba48-a52b-00c3-6770-e9cab66eacb2@rfc-editor.org> To: "Heather Flanagan (RFC Series Editor)" Archived-At: Subject: Re: [Rfcplusplus] Marketing, Branding, and Subject Matter Expertise X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 02:19:48 -0000 I agree. The problem and scope needs to be made more clear. This is a comm= on theme from participants on the list that are not proponents. I do hope t= hat this effort steps back to define the problem and scope before initiating= any experiment in case the one in mind from proponents does not solve the p= roblem(s) they cite. Engaging experts as Heather suggests sounds like a very useful exercise give= n the possible impact of proposals discussed so far. Best regards, Kathleen=20 Sent from my mobile device > On Jul 9, 2018, at 1:36 PM, Heather Flanagan (RFC Series Editor) wrote: >=20 > Hello all, >=20 > Early on in the process that spun into the BoF, before it became a BoF, I s= uggested that taking a step back to properly review and clarify the scope of= the problem, and to determine the varying options we had (and will have) fo= r solving them made more sense than throwing an idea against the figurative w= all to see if it would stick. I still think that idea is a good one, and som= ething that I should be handling as RSE. One of the things I would like to d= o is talk to people who understand marketing and branding for a living--ther= e are people at ISOC that have the level of experience I think we need--rath= er than watch ideas abound from very smart engineers. >=20 > -Heather >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Tue Jul 10 19:35:28 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9A5130E30 for ; Tue, 10 Jul 2018 19:35:27 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 yqWcd-Q7iFoC for ; Tue, 10 Jul 2018 19:35:24 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 C92DD130E26 for ; Tue, 10 Jul 2018 19:35:24 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id r5-v6so2448960pgv.0 for ; Tue, 10 Jul 2018 19:35:24 -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=KvIHiK3Yww+z8HJ+TN+7EXnE2pIJoq1q8Fl+rilNKZI=; b=ZInSUziQrLt1UBitHT5SdWHctHOBSQDjBxe4k78XWD3zYCWxF2A3TLBW8BzjGC0Uob AxmRs23+0t1ZNoqaxFmDeNcUzGsWI4CbCdzZr1Fe4RFR3CBDgAWtV+rWFg92DTKNACyX V1u3m/Zib8aW8ZFJTiyLkAIKdkQ1FMnFAP42kWSzW1Aw6ZfR/sD1cclEmEwfrthyOhr+ ePIu/IFMDB19XY4vpafNthI7izb/webVCLjI9XW6N4ED/BGjGrzMUAbBXjv+u2MT1kxM z5YfISk12TdNAV9puFXkhoNXy6MApQLv4TcsalPGIsHA8UvrlVEx4OL6dFYBIOzbC1wb G0dw== 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=KvIHiK3Yww+z8HJ+TN+7EXnE2pIJoq1q8Fl+rilNKZI=; b=jjrKOZAOcIaOt2jPpRwOMaF2wlJHVrz6TptPDfhZou1QFU9xpKlOmtKhfqISI/CDDZ hFcgKjOpMU9MM5NKgfngtSlx5X7HCu6FnCwll71ZoTGA2DypQnQg2dwG7u9igHRs9Sv2 CoH+Sau6pKnGzBLOECwnPJzx+yX1XWgIoo9wIsO1+ivG7oVvPlmvG7KwgoCgUkFirrI6 aT3bL7QCXzMSrdirOXBKYnjRIYCjL0vZpPuWxfqm8edDOUpWmZlkhP8gsuRXl+gQlXlF +gc1mEjXOrLXaEvVz5Id3ye7FYoo8Uxsx1QpO88YBkjFHmEcPU6W0EXBzydBqvSZ438/ z/Vw== X-Gm-Message-State: APt69E1UTE5huKgFd+Zgt7szF3/yjlPuDfQewydCAImMAN07Qr4BkU1j QfNmV2zOz8qTJSe4OY6ffhoRvg== X-Google-Smtp-Source: AAOMgpe07ulZ1T84br6VNMnFYMuzLv6N7LBViFvM4Id8dXpzUijX6DgPhOrdDTWvOZ83JneOLME0Kg== X-Received: by 2002:a62:5613:: with SMTP id k19-v6mr4666787pfb.212.1531276524086; Tue, 10 Jul 2018 19:35:24 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id r77-v6sm33335151pfr.117.2018.07.10.19.35.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 19:35:23 -0700 (PDT) To: Richard Barnes Cc: "Joel M. Halpern" , rfcplusplus@ietf.org References: From: Brian E Carpenter Message-ID: <78e48025-29b0-84c8-01c4-0e0388adb342@gmail.com> Date: Wed, 11 Jul 2018 14:35:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 02:35:27 -0000 On 11/07/2018 02:34, Richard Barnes wrote: > On Mon, Jul 9, 2018 at 8:30 PM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 10/07/2018 10:32, Joel M. Halpern wrote: >> ... >>> PS: I do not see how we can draw any conclusion from the very informal >>> survey. We have been lectured, with good reason, in the past about the >>> dangers of drawing conclusions from even carefully formulated and >>> carefully distributed surveys. >> >> It's worse than that. The survey was hastily designed and included >> at least one ad hominem entry, and I think anyone with experience >> of surveys and their analysis would simply junk the results. See >> below for something more concrete on that. >> > > I'll admit it was hastily conceived; the idea came to me as I was composing > my message to the list on Friday. I won't admit it's ad-hominem -- it's > simply fact that the process entitles Adrian can approve RFCs as he likes. > > But in the real world, when you're trying to make a decision, you either > work with dirty data or you collect better data. I don't see anyone here > doing any better survey work, so throwing out what data we have seems > counterproductive. > > > >> On 7/9/18 6:17 PM, Richard Barnes wrote: >> ... >>> Based on those observations, I hope it's clear to folks that there is a >>> problem to be solved here.. The survey data, sketchy as they are, also >>> point toward the solution, which is to refine the RFC label to have a >>> much more limited semantic, probably only IETF and possibly only >> standards. >> >> That's a pretty perfect example of confirmation bias. >> > > If you have another interpretation for the responses to questions 1 and 2, > I would love to hear it. That people are confused, or simply don't read the boilerplate, isn't news. What has not been demonstrated is whether this matters enough to be worth fixing in a disruptive way. Brian > > > >> I hope that as scientists and engineers, we can do better than this. >> > > I have no doubt that we could do better, but so far, nobody's done the work. > > > By the way, the full results are at >> >> https://docs.google.com/forms/d/e/1FAIpQLSeMoeR0TBWkZNpBKXJN3Am6nUL04Vr4-12T2VgEbiRdBwzngQ/viewanalytics >> >> The last question is interesting.: >> "Does an RFC published by the IETF require IETF consensus?" >> got 58.8% "no", which is the correct answer. However, this >> seems very unlikely as the preferred response from outsiders. >> Only insiders know that only some IETF stream RFCs require >> IETF consensus. So I don't think the data can reasonably be >> assumed to represent the opinion of outsiders. >> > > I think this is more likely read as people just not understanding the > question, and the role consensus plays in our process. If you think the > respondents were insiders, how do you explain the abundantly "incorrect" > responses to question 2? > > I actually asked people let me know when they filled out the survey, and > got around 20 notifications, including some IETF newcomers, several senior > developers for major projects, and a few newbie developers. Taking that > together with the Q2 observation above, I doubt the sample was dominated by > insiders. > > --Richard > From nobody Tue Jul 10 19:47:53 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B13130EBE for ; Tue, 10 Jul 2018 19:47:52 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 AYnNQ-uP_72I for ; Tue, 10 Jul 2018 19:47:50 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED77130EB7 for ; Tue, 10 Jul 2018 19:47:50 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id c21-v6so12768890pfn.8 for ; Tue, 10 Jul 2018 19:47: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=aglEPWcWZKfTysHsTfZTmCS/SfYdhNxTLHp6vmIHyM8=; b=fNOe+flDk0KRhP60moGqXVmnpCdobaXfuAIIB8hkgybyQvI1pG0fIt3xhYCVI9l0iE 5aBtyZv3FBiWMtrrOluatn6ue77FXDqMZcDcVZqQWZEOLHCCwoMyVUl/XyzoEfIec0XJ zzr9UcfNgBOdWoYmL8uGtkMj9Vt359JAv44Wc4D9+CIFUPoSo2jSqxzc3pgALQA2kxAq uD8bTzl6M6He617pimUWnuqBkviX1f3wRx1qf4iwx5uPePZJnq9J9gh0b2PwbPx5tTUz cdnjUrmIv6aTVqNRY6MAq1rbuRCLtpeeDKgYQYobji9Jbad2OnxLGbOZbn15NSdtLk8K yjZw== 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=aglEPWcWZKfTysHsTfZTmCS/SfYdhNxTLHp6vmIHyM8=; b=eRzJwbEmi5skCPfBwTI+ERnjKR40Y1Vo4/nVDgNwHQm7EPg0inv91wrF3G6wXcp5db 5aLbFvL3H466AAe9PeH2y1O63VSDktZ3Xl4qdSgmIs+XNHxpFVUalgYNWmkpBMIlkG3m tjVkTqyeMNtaRGc5lwArcT304uZNLWGRLahiPmy3i+Ypf5Ms7q19NWxnv1XJhm13DwQq 2ODBnDx4uCv3sFAMVEBbms3ZKST4bJp64saROoh+OPQcU9Nl6qyFg8dhpp4Yplyp3edS LH/fsg/UScGtcMCLuN33Av3D54q7MNijOAcrPQDT9raXyIKBLsXogQSWQohM3mt1dzRV yBYw== X-Gm-Message-State: APt69E0uaLC+05uJTnBoaPncORUlMf54G7Ju7U3EKmFzhyq/gSh4MH6l O15smsZlUGBCvceMZfu+sHMHNg== X-Google-Smtp-Source: AAOMgpdZm9IhZQA4ujRP6np1oJn2HoHtERRzV6aqd7lGOjQc+esAyQQVTB20rZiVjvK1laifgpvZ0g== X-Received: by 2002:a63:8e41:: with SMTP id k62-v6mr19877610pge.187.1531277270169; Tue, 10 Jul 2018 19:47:50 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id u9-v6sm90811pfi.4.2018.07.10.19.47.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 19:47:49 -0700 (PDT) To: Andrew Sullivan , rfcplusplus@ietf.org References: <20180710144525.GE20282@mx4.yitter.info> From: Brian E Carpenter Message-ID: Date: Wed, 11 Jul 2018 14:47:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180710144525.GE20282@mx4.yitter.info> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 02:47:53 -0000 Andrew, On 11/07/2018 02:45, Andrew Sullivan wrote: > Hi, > > On Mon, Jul 09, 2018 at 06:32:28PM -0400, Joel M. Halpern wrote: >> This formulation assumes that change does not have a cost. It does. I >> agree that not changing has some cost. However, absent indication that the >> changes will actually address the claimed problem, paying the various direct >> and indirect costs of changing things is not inherently a good thing. > > I think this argument would be stronger if we understood what your > estimation of the costs are. The analysis underpinning the proposal > (in the BoF request), as near as I can tell, is that the costs are the > using up of a few letters (for new series names) plus the cost of > possibly reserving RFC numbers for the alternative series publications > (in case they turn out not to work after 3 or more years), plus the > costs to tooling changes. Are there other costs you can think of? > > Keep in mind, the proposal is for an experiment. Andrew, It purports to be an experiment, but it's one that is hard to unwind. My own excursion into solutionism https://mailarchive.ietf.org/arch/msg/rfcplusplus/7GIxREzdIYAZFAHRSqCyp6S1JMo is, if implemented experimentally, much easier to unwind because it adds some wrapping to the archival series, and that wrapping could later be removed. However, what I'm getting clearly from the last 24 hours' email is that since we don't yet understand the problem, it's way too soon to seriously design an (experimental) solution. Brian > Experiments do > indeed result in some costs, and I think it is entirely reasonable to > ask what those costs really would be. But I also think we ought to > keep in mind the potential benefit of the experiment, which is to do > an empirical evaluation of whether the long-debated confusion can be > clarified (at least, in this way). > > Best regards, > > A > From nobody Tue Jul 10 20:22:09 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BA1130EC8 for ; Tue, 10 Jul 2018 20:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 eczz6zXacWgM for ; Tue, 10 Jul 2018 20:22:05 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 D423F130EC5 for ; Tue, 10 Jul 2018 20:22:04 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id i20-v6so5004501eds.12 for ; Tue, 10 Jul 2018 20:22:04 -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=pzH2baDPS3NWRlpAisVIHEJ3ER8QA9uwk9eO6Ie9+3g=; b=dpOQAR0bHdSdN9yeBa+R+zhGkd7bq4ol1k+hY2ti+uAb7HZDT8e7vgCHdLafLwYPiH QtqAU5M3yL4OiEAvPZtouyHGWbwvSNTyRQmbqQ98H2WUcZ/cAp4uYTxcFl5lMjlujOcm NS1w7hBjE6YFyCw6AzrD5AaX1r4CZwcR5V6hltU0KmIZv1IQswwPFJmp0DYx2Cp+7fB+ jPP4WnV2Zoto/H8Excv5ErTuiDunHxFaV6Y4usIXemezffM7shPt34Pb20f6nFBmmNSk sk78ntNZTh+Zlwh8xwteuMjwNhlS6fuqHRCMbtSRC1HU4pZOk1240kTAZetFepqu+VL1 CjjA== 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=pzH2baDPS3NWRlpAisVIHEJ3ER8QA9uwk9eO6Ie9+3g=; b=BPV5Au4o9SV9r4vsuUE1g5QULnUR62RjWehxMxuVr0p3gZIWADjITCnnmeKb0UvDLe nmqiJKAMVjz/zEVs7FQL0yYPWHDQ7M2d9+dbkCrzBYATt1dNhRLUJXALu+D178hMpXka 064NuL58eh2EezKJxT6u6Gb57HWEeh9TYuNvrwa5CKtPWQ9VC3YgOV4qN7v3l2eGjCND N6YmnEEHv3EmvWJeq7h/O4kLtKRrIsDOi9gvquusE5Mm8UKpDqEK59aS/XC/QnlQSCAE qJS5+zTFE+Nk6sTJGtio7wvKWeU8pij8MypGUV9LgZTdUAoBxMItODqSWX50eZWzkbCD aKjg== X-Gm-Message-State: APt69E1eV305U9V7jd5Dn70pBGQGltybMwBFNbtG70BttbtUNPfCsgvk 1+bTPIQ7ueJMQA+qvzN7pHHCvV2K8pe43drY30E= X-Google-Smtp-Source: AAOMgpc/aYRpvNIENWXK+XWwDlpRxpUWZiZiqwIigpvV23n6zPD2jGMPCThi7EUY41cFsH4EfEglsqEGs72iOuoO0to= X-Received: by 2002:a50:b134:: with SMTP id k49-v6mr23272331edd.55.1531279323241; Tue, 10 Jul 2018 20:22:03 -0700 (PDT) MIME-Version: 1.0 References: <4444ba48-a52b-00c3-6770-e9cab66eacb2@rfc-editor.org> <31C349A4-5A87-40A8-B8E3-8B695688C0DD@gmail.com> In-Reply-To: <31C349A4-5A87-40A8-B8E3-8B695688C0DD@gmail.com> From: Aaron Falk Date: Tue, 10 Jul 2018 23:21:52 -0400 Message-ID: To: Kathleen Moriarty Cc: "Heather Flanagan (RFC Series Editor)" , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000001d22030570b0c08c" Archived-At: Subject: Re: [Rfcplusplus] Marketing, Branding, and Subject Matter Expertise X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 03:22:07 -0000 --0000000000001d22030570b0c08c Content-Type: text/plain; charset="UTF-8" As a concrete suggestion along these lines, if there were a well-crafted questionnaire on how rfcs are perceived and used, I could be open to shepherding it through various groups in my company that see and issue RFPs, implement protocols etc. Aaron On Tue, Jul 10, 2018 at 22:19 Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > I agree. The problem and scope needs to be made more clear. This is a > common theme from participants on the list that are not proponents. I do > hope that this effort steps back to define the problem and scope before > initiating any experiment in case the one in mind from proponents does not > solve the problem(s) they cite. > > Engaging experts as Heather suggests sounds like a very useful exercise > given the possible impact of proposals discussed so far. > > Best regards, > Kathleen > > Sent from my mobile device > > > On Jul 9, 2018, at 1:36 PM, Heather Flanagan (RFC Series Editor) < > rse@rfc-editor.org> wrote: > > > > Hello all, > > > > Early on in the process that spun into the BoF, before it became a BoF, > I suggested that taking a step back to properly review and clarify the > scope of the problem, and to determine the varying options we had (and will > have) for solving them made more sense than throwing an idea against the > figurative wall to see if it would stick. I still think that idea is a good > one, and something that I should be handling as RSE. One of the things I > would like to do is talk to people who understand marketing and branding > for a living--there are people at ISOC that have the level of experience I > think we need--rather than watch ideas abound from very smart engineers. > > > > -Heather > > > > _______________________________________________ > > Rfcplusplus mailing list > > Rfcplusplus@ietf.org > > https://www.ietf.org/mailman/listinfo/rfcplusplus > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > -- -- aaron Sent from Gmail Mobile --0000000000001d22030570b0c08c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a concrete suggestion along these lines, if there= were a well-crafted questionnaire on how rfcs are perceived and used, I co= uld be open to shepherding it through various groups in my company that see= and issue RFPs, implement protocols etc.=C2=A0

Aaron

<= br>
On Tue, Jul 10, 2018 at 22:1= 9 Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
I agree.=C2=A0 The problem and scope needs to be made more cl= ear.=C2=A0 This is a common theme from participants on the list that are no= t proponents.=C2=A0 I do hope that this effort steps back to define the pro= blem and scope before initiating any experiment in case the one in mind fro= m proponents does not solve the problem(s) they cite.

Engaging experts as Heather suggests sounds like a very useful exercise giv= en the possible impact of proposals discussed so far.

Best regards,
Kathleen

Sent from my mobile device

> On Jul 9, 2018, at 1:36 PM, Heather Flanagan (RFC Series Editor) <<= a href=3D"mailto:rse@rfc-editor.org" target=3D"_blank">rse@rfc-editor.org> wrote:
>
> Hello all,
>
> Early on in the process that spun into the BoF, before it became a BoF= , I suggested that taking a step back to properly review and clarify the sc= ope of the problem, and to determine the varying options we had (and will h= ave) for solving them made more sense than throwing an idea against the fig= urative wall to see if it would stick. I still think that idea is a good on= e, and something that I should be handling as RSE. One of the things I woul= d like to do is talk to people who understand marketing and branding for a = living--there are people at ISOC that have the level of experience I think = we need--rather than watch ideas abound from very smart engineers.
>
> -Heather
>
> _______________________________________________
> Rfcplusplus mailing list
> Rfcplusplus@= ietf.org
> https://www.ietf.org/mailman/listinfo/rfcplusp= lus

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusplus
--
-- aaron Sent from Gmail Mobile
--0000000000001d22030570b0c08c-- From nobody Wed Jul 11 01:33:01 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0B6130DF5 for ; Wed, 11 Jul 2018 01:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=XE1xS+w4; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=F3JiL5mQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGsUnVMBMqcD for ; Wed, 11 Jul 2018 01:32:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B220012F1A6 for ; Wed, 11 Jul 2018 01:32:58 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.225.22.168]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id w6B8WjGr007670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2018 01:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1531297975; x=1531384375; bh=T5GmjXAsG5er8p36WFJh77llbCEZjRuZviyt4wU2IIU=; h=Date:To:From:Subject:In-Reply-To:References; b=XE1xS+w4aUZzpiwgvhnRAsvAD+qpAHnEg8rLSRotQurHw91JckUsRN4/8Pl+E48Ok qQ4I9b06BeouPwZ2wAHzHLZnIs01F4j7X5nGSj1PkLmMNUFL7v2j+CqAai9NJlp5k6 Zh+Ng0rR9V+AXR3+ius+BiSoksnMRhl6h50rPSog= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1531297975; x=1531384375; i=@elandsys.com; bh=T5GmjXAsG5er8p36WFJh77llbCEZjRuZviyt4wU2IIU=; h=Date:To:From:Subject:In-Reply-To:References; b=F3JiL5mQWfCpFiNrarQ5g032l1hWzw0VSCvXKAV/pA+1CLz3lN3PWhVUBDCch7Yfl vEEX62qxd4fgQG4DJgmy9NH5xJAu8IufqJQaCxvAX8w/7U3/EvOsoBtoIbI8q/oD6w 7IKJuoyIRrxoHZiBx3smZPKCY1guRvLKt9HSqfRg= Message-Id: <6.2.5.6.2.20180711011740.0c7449a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jul 2018 01:28:08 -0700 To: Joseph Lorenzo Hall , rfcplusplus@ietf.org From: S Moonesamy In-Reply-To: References: <639B8766-A030-490D-8431-C3F9F3EAFCB4@gmail.com> <8B48E5E5-90DC-423F-83C7-9B51A853A1A8@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 08:33:00 -0000 Hi Joseph, At 03:05 PM 10-07-2018, Joseph Lorenzo Hall wrote: >However, the document series still baffles me, and I know a lot of >folks that squint at IETF and don't understand any of the >distinctions we do (I would have answered the survey question as >there being only 4 document series). Alissa had the unenviable task >at one point of sitting me down and telling me the difference >between and ID and RFC, even after I had thoroughly read the Tao and >been to a couple IETFs. (The ID we've been working on for a while I >even named (incorrectly) when setting up a github repository as an >RFC: https://github.com/josephlhall/rfc-censorship-tech ). The IETF changed its position on Internet-Drafts a few years ago. There are cases where Internet-Drafts have been referenced as RFCs. As an off-topic comment, the repository states that the discussions of the work occurs on the censorship working group mailing list. I could not find that IETF working group. Regards, S. Moonesamy From nobody Wed Jul 11 01:58:14 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C243A130EDF for ; Wed, 11 Jul 2018 01:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ecDK1EvTfa2W for ; Wed, 11 Jul 2018 01:58:09 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6455130DEA for ; Wed, 11 Jul 2018 01:58:08 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 741CB340EB4; Wed, 11 Jul 2018 10:58:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.2198); Wed, 11 Jul 2018 10:58:05 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 11 Jul 2018 10:58:05 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 61016642; Wed, 11 Jul 2018 10:58:04 +0200 From: "Brian Trammell (IETF)" Message-Id: <68DDBAD8-F4B9-4ECD-A1B9-C1C3A23E0128@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_990663F6-2399-4DD8-89A7-34A672F4950A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 11 Jul 2018 10:58:03 +0200 In-Reply-To: <9cc8662e-fe1e-f26f-a55e-1f654309917d@gmail.com> To: rfcplusplus@ietf.org References: <9cc8662e-fe1e-f26f-a55e-1f654309917d@gmail.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 08:58:13 -0000 --Apple-Mail=_990663F6-2399-4DD8-89A7-34A672F4950A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 'Morning, all, pseudoacademic here (waves). > On 11 Jul 2018, at 01:46, Brian E Carpenter = wrote: >=20 > On 11/07/2018 06:15, Ted Hardie wrote: >> Howdy, >>=20 >> On Tue, Jul 10, 2018 at 11:06 AM, Eric C Rosen = wrote: >>=20 >>> Maintaining the current publication process for RG output but = changing the >>> name from "RFC" to "IRTF-Masterpiece" is not going to make any = difference >>> in how the academic community values the work. >>=20 >> That's not what others are saying. The problem as it has been = explained to >> me is that tenure committees and similar academic assessments look at = the >> output of the individual in part by looking at where the output has >> appeared. When it appears in a series which looks to them to be = primarily >> engineering specifications, it is not valued as highly. A = differently >> labeled series which was entirely composed of research output might = be >> valued differently. It depends on the committee and the question before them, but it's not = quite so cut-and-dried, at least outside the US. Engineering work is = valued (as impact) when there's also "more serious" academic work next = to or behind it; exclusively engineering work is generally not. > That's highly unlikely. Although the whole business of journal impact = factors > and the value of conference publications is mainly pseudo-science, Indeed, one of the nice things about Google Scholar (for us = pseudoacademics who have been fortunate enough to be able to play in the = space between Internet science and Internet engineering) is that it's = good enough for these pseudoscientific purposes (i.e. people who want a = number that allows them to classify a person as "a serious academic"), = while being quite a bit less picky about the label on the publication or = on the publications citing it. > and the > whole question of open-access journals (where the author's institution = pays) > versus traditional journals (where the reader's institution pays) is = very > contentious, the chance of a brand new series from the IRTF breaking = into > that game is vanishingly small. (IMNSHO, of course) >=20 > RFCs have a 50 year history and are in fact widely cited in academic > publications. My own 2nd highest citation count** is 422 for RFC1958 > (unfortunately, most indexes have me as author, not editor). My = highest > non-RFC citation count is 153. The case of RFCs-as-peer-reviewed-academic-work is one on which someone = could almost do academic work on. (Indeed, Brian co-authored an [article = on this for CCR][1], though it's an editorial note and therefore, = strictly speaking in the manner of caring about the difference between = Standards Track and Informational RFCs, does not count). On the one hand, they are usually often cited, because they're often = used as a citation when an academic work needs to refer to an Internet = protocol, which they often do. My own most-cited non-patent in [Google = Scholar][2] is an tutorial that was designed to be a more useful cite = than 5101/7011 for IPFIX and than 3954 for Netflow in these contexts; = number four is RFC 5103, usually cited as "this study uses bidirectional = flow data [RFC5103] as input...", i.e. it's most often used as academic = citation shorthand for the *problem* 5103 addresses, not the particular = solution therein described. On the other hand, protocol specifications are generally not = academically rigorous, in the sense that the decisions that they = document are sometimes (often?) made for accidental reasons as opposed = to essential ones (i.e. tradition or politics, not a rigorous = theoretical or empirical evaluation of the solution space). The criteria = for evaluation of a protocol are different than those for most academic = work in networking. (Whether *that's* a good thing is another question, = and one that in part MAPRG was set up to provide a venue to address.) On a, um, third hand, in academia there's a complete lack of = understanding (or interest in understanding) the work that goes into an = RFC. They're often thought of as equivalent to tech reports (maybe in = part because that's how you cite them in bibtex), but academics I've = explained the process to generally comment with surprise something like = "oh, so it's kind of like a big journal article", at least in the terms = of the amount of review. > **according to Google Scholar. The ** here is, if I recall correctly, the work of Heather, who worked = to get RFCs correctly indexed in Scholar. (Thanks, Heather!!) Back toward being on topic, what does the value of the brand mean in = academia? Different things to different academics. Do I support the use = of alternate stream labels and/or alternate publication venues for IRTF = output? Depends on the RG and the type of output, but I don't see that a = new label would automatically be a less-useful brand than RFC. (With respect to the IETF use of alternate labels specifically and the = future of the stream more generally, ISTM that the proposed experiment = has started a a useful conversation, and that converging on a problem = statement or statements would be a good outcome for Monday's BoF. I'm = still forming my own opinions on the relative importance of the various = problems with the series. "Unsuitability of RFCs as a publication stream = for Internet-related research" is not a big one, though.) [1]:http://delivery.acm.org/10.1145/1680000/1672315/p31-carpenter.pdf [2]:https://scholar.google.ch/citations?user=3DvTA2dL0AAAAJ&hl=3Den >=20 > Brian >=20 >> I agree with Eliot's earlier point that this is a "might", and that = the >> value ascribed to it depends not just on its output but on the work = done to >> highlight the stream's output. >>=20 >> regards, >>=20 >> Ted >>=20 >>=20 >>=20 >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >>=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --Apple-Mail=_990663F6-2399-4DD8-89A7-34A672F4950A 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAltFxpsACgkQihK3vwvq RqOCUQ//R4zT+c09ZVKl6X9s1HHJUAt+5cuylt0tPmciMY1heCOD0SgBUHvAb4rm GXPAGK3ERetcji3lbZ2IOJKPAE3TtYSSeGcnQsJ3lsflg473i+CxmCcitAczQr82 r2awgcTfcDl7ZngtnIZT1HGwnmgvty61mxzhsbAlr+PZsK0Lapy/7lNbG5g0h/Cd VzcO6S98BeLOz1TG2ISumyNoO+hYndBwGO39dblzouH9nLQcQHWxWGOI0LlU1mO8 O5UhlXf3skRCtCdB6WVDzG9eWxCFxEEwtq6QeGQibXTRSCYl10pG+OzJze23tFW/ bDp7Vqv2GkBzYHJ2eAeIT5lC2svZvk/MdSyEETW5fABapcU/fX7fTvru27sACtMK 06RJXEy4hviFFOo8tAXwhujKCwRLwXBazLdwZ+TzZDdODDzwbxdGVitrQEYG3KPF ww9c4yiTboeST7WldMoldskEfhAECfYjm+7x8ZpFDP6ZZyTsVO3YNLF5zaTzLinT 96r7yTqu2OIfnf2L9kIHi7S6Sw/7KIswvidfi7PElIPuhnQc39k0+ebdHf3JVofu Uk/IUMYKIjX5PdpB346qeEExBBhAYi6hPtbd6y9+4T+gRDiLp42BFaHeT8/cu3z2 eEjah6Xe7AJDc2P674TTMJMSSKvEV5VL/XTuEm4SWph4bz2yZ2U= =Ko4R -----END PGP SIGNATURE----- --Apple-Mail=_990663F6-2399-4DD8-89A7-34A672F4950A-- From nobody Wed Jul 11 04:03:05 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9544130DD0 for ; Wed, 11 Jul 2018 04:03:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.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 sGMAicwVvCDG for ; Wed, 11 Jul 2018 04:03:02 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 A20D2130DD1 for ; Wed, 11 Jul 2018 04:03:02 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id x24-v6so15917108ual.10 for ; Wed, 11 Jul 2018 04:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jFzMm5NCxgrgnW7CvN+4zNnKr+/kzAYo1tpx9YDDexI=; b=JSURy9xDteeD6Q9tU/GSj9W3S7Khfqqcd+SDUYeJv0vUK0iFsyLnjry+UyzEy1fGMq Aas9YhGxiFwcH6mWeFH9ZUnpk56uMukH+c51DQqizJn8NefOi8ATmCR4m1PzDUtLNHm5 JBt0fU7jrQSn2NjtYwlyQt2Nq4gwfbPZZV+5I= 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=jFzMm5NCxgrgnW7CvN+4zNnKr+/kzAYo1tpx9YDDexI=; b=TMk/EQ5/y4Tz7qQl0MEBtFLVqgiX6YQXCjizO7yxT2lkxF2sdBw+VVHqfdPYjueDIl evMpPXEQk1XV7nk5VnZ89J1U+pKqL43QWgtDoUcKdFunGrjBTxoX7iqeNhLig16szazz pyecR4gXuq2C5qGfI5N2JFhgbGEh2sZ8Zbd+Ef4bqiw6Kd66QasX74c6M3ZokS7BD/gM Olr6xTKoMpBg7FduTmoexHHjntSAfPI4OuikP0X1T1A490tRf0qCNlWi00vue3LmWuv9 t3ROL7ovso2l+I6dIiX5phzz4ZX+3Yd0PY1p4Kgzg0XB849lh09Jn5O0Io1IqSsAUk14 TapA== X-Gm-Message-State: APt69E00nzgP8ppjSyddyik+8Ks0W35L64V1QN0EUuKkcU8aBaomE0oq dGxohCOSJthXW2+xb5OslVtl5XoOESm+R+z/zVL/LAv0 X-Google-Smtp-Source: AAOMgpevpDa8Mv5HN83B0fnBKViH6fHguUWI0E4xJmP0undq8m7uAgI9IWnYRGJ3HHlpaSB9Q5U8uzTj4Bn7k5G43SM= X-Received: by 2002:ab0:15ea:: with SMTP id j39-v6mr17718529uae.96.1531306981088; Wed, 11 Jul 2018 04:03:01 -0700 (PDT) MIME-Version: 1.0 References: <639B8766-A030-490D-8431-C3F9F3EAFCB4@gmail.com> <8B48E5E5-90DC-423F-83C7-9B51A853A1A8@gmail.com> <6.2.5.6.2.20180711011740.0c7449a8@elandnews.com> In-Reply-To: <6.2.5.6.2.20180711011740.0c7449a8@elandnews.com> From: Joseph Lorenzo Hall Date: Wed, 11 Jul 2018 07:02:50 -0400 Message-ID: To: S Moonesamy Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000a673b30570b730b0" Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 11:03:05 -0000 --000000000000a673b30570b730b0 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 11, 2018 at 04:32 S Moonesamy wrote: > Hi Joseph, > At 03:05 PM 10-07-2018, Joseph Lorenzo Hall wrote: > >However, the document series still baffles me, and I know a lot of > >folks that squint at IETF and don't understand any of the > >distinctions we do (I would have answered the survey question as > >there being only 4 document series). Alissa had the unenviable task > >at one point of sitting me down and telling me the difference > >between and ID and RFC, even after I had thoroughly read the Tao and > >been to a couple IETFs. (The ID we've been working on for a while I > >even named (incorrectly) when setting up a github repository as an > >RFC: https://github.com/josephlhall/rfc-censorship-tech ). > > The IETF changed its position on Internet-Drafts a few years > ago. There are cases where Internet-Drafts have been referenced as RFCs. > > As an off-topic comment, the repository states that the discussions > of the work occurs on the censorship working group mailing list. I > could not find that IETF working group. There is certainly no WG for that; I suspect a typo or relic of the template used. > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --000000000000a673b30570b730b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= =
Hi Joseph,
At 03:05 PM 10-07-2018, Joseph Lorenzo Hall wrote:
>However, the document series still baffles me, and I know a lot of
>folks that squint at IETF and don't understand any of the
>distinctions we do (I would have answered the survey question as
>there being only 4 document series). Alissa had the unenviable task >at one point of sitting me down and telling me the difference
>between and ID and RFC, even after I had thoroughly read the Tao and >been to a couple IETFs. (The ID we've been working on for a while I=
>even named (incorrectly) when setting up a github repository as an
>RFC: https://github.com/josephlhall/rfc-censor= ship-tech ).

The IETF changed its position on Internet-Drafts a few years
ago.=C2=A0 There are cases where Internet-Drafts have been referenced as RF= Cs.

As an off-topic comment, the repository states that the discussions
of the work occurs on the censorship working group mailing list.=C2=A0 I could not find that IETF working group.

<= /div>
There is certainly no WG for that; I suspect a typo = or relic of the template used.
--
Joseph Lorenzo Hall
Chief Technologist, Cente= r for Democracy & Technology [https://w= ww.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
F= ingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A871
--000000000000a673b30570b730b0-- From nobody Wed Jul 11 06:49:54 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A5B130E19 for ; Wed, 11 Jul 2018 06:49:52 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 cXT1ja5ANKet for ; Wed, 11 Jul 2018 06:49:51 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CA2130E03 for ; Wed, 11 Jul 2018 06:49:51 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fdFV6-0008KM-Ox; Wed, 11 Jul 2018 09:49:48 -0400 Date: Wed, 11 Jul 2018 09:49:43 -0400 From: John C Klensin To: Brian E Carpenter , Alissa Cooper cc: rfcplusplus@ietf.org Message-ID: <53A44968B8377095ABB61DEC@PSB> In-Reply-To: References: <20180710144525.GE20282@mx4.yitter.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 13:49:53 -0000 --On Wednesday, July 11, 2018 14:47 +1200 Brian E Carpenter wrote: >... > However, what I'm getting clearly from the last > 24 hours' email is that since we don't yet understand the > problem, it's way too soon to seriously design an > (experimental) solution. Normally, I'd say that was true. But the situation is not normal. We are in a situation in which it seems clear that the thinking that went into draft-thomson-rfcplusplus-label-00 was key to the BOF proposal and that both it and the BOF proposal posit a very specific solution. While I accept Martin's explanation and hence have no reason to believe the posting of that draft at the last minute was intended to disadvantage any other proposed solutions, it does have that effect, an effect that is aggravated by there still being no posted agenda for a BOF that occurs on the first day of the meeting. That leaves us without knowing whether the intention is to discuss the problem or to assume, as the BOF proposal does, that there is a problem that is in need of solutions and that we are discussing solutions (or one specific solution). Perhaps the plan is "both", but, especially with only one possible solution available in I-D form before Monday morning and the amount of discussion about a variety of topics on the list, 90 minutes seems very compressed. Alissa, given that state of affairs and assuming that possible solutions are not going to be ruled out of order in Monday's discussion, can we get blanket permission for late-posting (before Monday) of any draft related to this BOF? I think it is generally accepted that discussing I-Ds, even hastily prepared ones, is usually more productive than discussing partial proposals that go by on mailing lists. And, while the posting cutoff was intended, in part, to allow people adequate time to read and study documents before IETF begins, it seems to me that giving people the weekend (and possibly even part of tomorrow and Friday) is preferable to either giving them zero time (solutions introduced at the BOF itself) or well under 24 hours between whenever I-D postings are allowed again on Monday (the "important dates" page appears to no longer show whether that is, e.g., 00:01 UTC or the starting time of the meeting). best, john From nobody Wed Jul 11 06:59:01 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D08128CF3 for ; Wed, 11 Jul 2018 06:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=0pR4/2N3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JQIur5Rt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR1uh8-6jmz3 for ; Wed, 11 Jul 2018 06:58:58 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE891277BB for ; Wed, 11 Jul 2018 06:58:58 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6B38E21C48; Wed, 11 Jul 2018 09:58:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 11 Jul 2018 09:58:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=iGSv1yf0pKtTYcMNdKTmKTrWtoL6E QURSIRJ3xCogtg=; b=0pR4/2N3DIJV6NdI4SwNaFtLx29Iz0+Cyx6uXrKuQhoit 6SRXUJVngWlH6Hss4eTURi89yvXF5wT9jKMUy5mc3r/P+faYFhXhsjhybWiwjvrS 6jVr25Yv6tket39LBFys/M0iF8szFUU4TzFAWywcPvcNttz/0+PLphZnIgxDdqQE pkB+Ah5swTsrYgYR8EK4TxuTt17tAsgq+nCXOmyT/W6rchsCxpZZ5BmCMitIew+z ipOJCqEGL0ofmXHVNuykOv5mNOp9zYsYkfJSrr0OQM6+OK+MmkX2U7WlOYg61NpU /shcntoWserguH8175Z0EeUnQ2FfYMfgvvypXjSXw== 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=iGSv1y f0pKtTYcMNdKTmKTrWtoL6EQURSIRJ3xCogtg=; b=JQIur5Rt4vooKDa8ZNFt3r NwCQyDs0VfWyKQskkkL9ZnoOz2pUBQzzin0tIDhx8IVLNtjBFNFr4ge6F2UJEi98 Y76ApsNI6VcZKVznZOzvsZSDTBeIB0VrFaFSESbfXWks8OJPFfH/126wu7HpsB/L CJnDPzp3huaCImMqHon/TgwGjNpmDoIoZiee5p380RWL/Vzu/7UrEUpmI2N3XYex pl/bjjNfWGTZHI20K2oAiiulHfCABFyhiCzuZR4gOsdtjVmi/eha5D+PG9acp2pL adm6Ka6DMXlIFibKlQH0grwqpCiqS5/91t0x5qoFMuvk1Q5CTDIpITM+1oVLyEPA == X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id E161510273; Wed, 11 Jul 2018 09:58:56 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Alissa Cooper In-Reply-To: <53A44968B8377095ABB61DEC@PSB> Date: Wed, 11 Jul 2018 09:58:55 -0400 Cc: Brian E Carpenter , rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6A472A36-1719-4D38-B2C5-DB5FAC37AC64@cooperw.in> References: <20180710144525.GE20282@mx4.yitter.info> <53A44968B8377095ABB61DEC@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Rfcplusplus] Sunk cost + not about us X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 13:59:00 -0000 Hi John, > On Jul 11, 2018, at 9:49 AM, John C Klensin wrote: >=20 >=20 >=20 > --On Wednesday, July 11, 2018 14:47 +1200 Brian E Carpenter > wrote: >=20 >> ... >> However, what I'm getting clearly from the last >> 24 hours' email is that since we don't yet understand the >> problem, it's way too soon to seriously design an >> (experimental) solution. >=20 > Normally, I'd say that was true. >=20 > But the situation is not normal. We are in a situation in which > it seems clear that the thinking that went into > draft-thomson-rfcplusplus-label-00 was key to the BOF proposal > and that both it and the BOF proposal posit a very specific > solution. While I accept Martin's explanation and hence have no > reason to believe the posting of that draft at the last minute > was intended to disadvantage any other proposed solutions, it > does have that effect, an effect that is aggravated by there > still being no posted agenda for a BOF that occurs on the first > day of the meeting. That leaves us without knowing whether the > intention is to discuss the problem or to assume, as the BOF > proposal does, that there is a problem that is in need of > solutions and that we are discussing solutions (or one specific > solution). Perhaps the plan is "both", but, especially with > only one possible solution available in I-D form before Monday > morning and the amount of discussion about a variety of topics > on the list, 90 minutes seems very compressed. >=20 > Alissa, given that state of affairs and assuming that possible > solutions are not going to be ruled out of order in Monday's > discussion, can we get blanket permission for late-posting > (before Monday) of any draft related to this BOF? =20 As has been my practice pretty much since I joined the IESG, I=E2=80=99m = fine with doing manual postings of late-arriving drafts between now and = when the submissions window opens, if people send them to me. And of = course there is nothing stopping people from sending pointers to = documents they=E2=80=99ve written that haven=E2=80=99t yet been posted = to the I-D repo, as has become more common in some WGs lately. Alissa > I think it is > generally accepted that discussing I-Ds, even hastily prepared > ones, is usually more productive than discussing partial > proposals that go by on mailing lists. And, while the posting > cutoff was intended, in part, to allow people adequate time to > read and study documents before IETF begins, it seems to me that > giving people the weekend (and possibly even part of tomorrow > and Friday) is preferable to either giving them zero time > (solutions introduced at the BOF itself) or well under 24 hours > between whenever I-D postings are allowed again on Monday (the > "important dates" page appears to no longer show whether that > is, e.g., 00:01 UTC or the starting time of the meeting). >=20 > best, > john >=20 >=20 >=20 >=20 >=20 From nobody Wed Jul 11 08:08:30 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995E5130DE5 for ; Wed, 11 Jul 2018 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 mShi-WHilcyQ for ; Wed, 11 Jul 2018 08:08:27 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 1BA55130DE6 for ; Wed, 11 Jul 2018 08:08:27 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id v8-v6so49871181oie.5 for ; Wed, 11 Jul 2018 08:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GEKS4jYnPVvuTGjgBB3vDrAGgoR1QyufA767oQ7DCaE=; b=QBmc44DH4xOZ6+8MCuzKrioKOJm285OnYVO2W+4fA4O8jtnzcsZLh/2Oy2p6J42L6A lSD88MTtISS26Zy5MOh8iLhaMdlfFlsamxzzJEj/Bh/5e/zFZvhl6qcfSHYizoMD5OO6 feN21Li2r/BoaEvzR7Tih0lrgfHYm7YVNMalgixi1uzNC5KEUy8qM6MSifMxpOvfhdL0 6C1ABmHFuiWr7vofp9lh2b4H0EHA7kRmtWcoaUJYlKC4Dwhdm3iFCpFcgmf/IkLEhOwH 0dxiLLMOgQFrnzM5iAQpNT3w1U2zw3cAHwuQM8LQeX0T4gRhiR1kdAXf4KRWh3LmNrWq mfog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GEKS4jYnPVvuTGjgBB3vDrAGgoR1QyufA767oQ7DCaE=; b=uXsUHg5pyM3LcR335hds03Cnf92j9/xpRxfwW8rbJ8tpcTQt4pd+hToaZNaCvbnymx OUtd4tcHRokC8p/4C7tDHSOEZPS86oB3JN7/VUU1q6HZVhnXLmTZlImSKRdJ6shV1634 Ys0yTFtu+BFetaV0BF3bYlh25srx+Gx+kwXfMHgFGSCKG2HJ1HRKHQEauKnPtq0Hp7jF jJ/XtKZBrQhw5GE1Vl8VWbwr96qi5nFgOtvdNCdDHnufxg7pzyxsz0rW/q89cBZN0TS0 QkseaZXjzD9BCN90SqTpkjHEJZ0+bgFp/jTInY3EEbWzNVo/sJytrxUH1CxcydzOpoA1 3GOg== X-Gm-Message-State: APt69E0dfVB6BeKOLezYVxWQkNLg8ly0t+0tTye73oTT5oNQEMrYxjY4 Q8UrCCqov1IIQJtBmkm8SHhYjYy4V74K+Y07cBM= X-Google-Smtp-Source: AAOMgpf4XX7349szqIdicwVs46pSeKtElxEB8gnr340Ki2dwWdqrt/NTOu1DYBPl5MBRpjoRHqNHLoxzautgDoLfZvQ= X-Received: by 2002:aca:6287:: with SMTP id w129-v6mr35053785oib.122.1531321706118; Wed, 11 Jul 2018 08:08:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 08:07:55 -0700 (PDT) In-Reply-To: <3d5402df-5fd6-43b8-f75e-0423253bb07e@gmail.com> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <3d5402df-5fd6-43b8-f75e-0423253bb07e@gmail.com> From: Ted Hardie Date: Wed, 11 Jul 2018 08:07:55 -0700 Message-ID: To: Brian E Carpenter Cc: Eric C Rosen , rfcplusplus@ietf.org, Andrew Sullivan Content-Type: multipart/alternative; boundary="00000000000054855a0570ba9e18" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 15:08:29 -0000 --00000000000054855a0570ba9e18 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 7:10 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > Ted, > > It would be on topic if there was a proposal inside the IRTF to change > the publication venue for IRTF output. But this is an IETF BOF so all > we can do is discuss how IETF stream documents are published. > > I know this is an inconvenient truth for some people, but there it is. > > Brian > If you have a suggestion for a label that would help communicate that this meeting involves all of the streams, I think we can get it applied and communicated quickly. Practically speaking, though, the co-location of this meeting with the IETF, the ANRW/IRTF, and the IAB gives us a large number of contributors across many streams. Adrian, as ISE, will also be present. The conflicts with this meeting within IETF 102 were strictly minimized, and I'm not sure how we could get a better opportunity to discuss it in a face-to-face meeting. Of course, the BoF has also given us a chance to have this discussion on a dedicated mailing list. (In a reply to a question which is almost certain to arise, Heather asked that we not hold this on rfc-interest, because a large number of RFC format issues were expected to be discussed at roughly the same time, and she did not think interleaving them would be a good idea). regards, Ted --00000000000054855a0570ba9e18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 10, 2018 at 7:10 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Ted,

It would be on topic if there was a proposal inside the IRTF to change
the publication venue for IRTF output. But this is an IETF BOF so all
we can do is discuss how IETF stream documents are published.

I know this is an inconvenient truth for some people, but there it is.

=C2=A0 =C2=A0 Brian

If=C2=A0 you have a suggestion for a label that= would help communicate that this meeting involves all of the streams, I th= ink we can get it applied and communicated quickly.=C2=A0 Practically speak= ing, though, the co-location of this meeting with the IETF, the ANRW/IRTF, = and the IAB gives us=C2=A0 a large number of contributors across many strea= ms.=C2=A0 Adrian, as ISE, will also be present.=C2=A0 The conflicts with th= is meeting within IETF 102 were strictly minimized, and=C2=A0 I'm not s= ure how we could get a better opportunity to discuss it in a face-to-face m= eeting.=C2=A0 Of course, the BoF has also given us a chance to have this di= scussion on a dedicated mailing list. (In a reply to a question which is al= most certain to arise, Heather asked that we not hold this on rfc-interest,= because a large number of RFC format issues were expected to be discussed = at roughly the same time, and she did not think interleaving them would be = a good idea).

regards,

Ted



--00000000000054855a0570ba9e18-- From nobody Wed Jul 11 09:03:07 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4BE130F30 for ; Wed, 11 Jul 2018 09:03:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Ks7lnjNL1Acw for ; Wed, 11 Jul 2018 09:03:02 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E34130E2F for ; Wed, 11 Jul 2018 09:03:02 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id z19-v6so24158890ioh.4 for ; Wed, 11 Jul 2018 09:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=s9hN2TxfQed/ys5U5guPC6XOGRzxlS39VFKG6j6ZMbU=; b=D97oToO8Insnb7or5BMXAm7BMFqIkjpDGpXAA2PQGLoTCwbfjFamvq2kwyIkeicehg zUvVIF27sXMeHBe7468cN/HkY4zYYvBKY4K6dBYWummZmBZsFH7+YHrDHY/5aF0szAvz ReCvElQ1XIrl6eHYBo93RQ02Tjj7n+Qq4f0G4= 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=s9hN2TxfQed/ys5U5guPC6XOGRzxlS39VFKG6j6ZMbU=; b=G3Bcdi9oENFn2/7nxuJNGMfCtWen2McV4B9p39dORMA3sA7Rib2gFhKL3nVb61LFsN PcyRim1eCcufTfpHKYTrDvPlhH5Ug1OmPXfBNOM0r7ldjGOjj+nYzjWlSDNVcRvi3FwQ S2Wyys5L1KN4BtCeSIODEEcy6hEciaNinqzLkgdO66+DDyG3qDj2tfsl/Og2XFAEuMSi aHCmRNpxw1DotIrj+nMJ23BMJ+NKXDhf6dElmdFXlZY6LMRkNUO5TFdYM08+fhYFQFGF MHAlEoLuBaz5nmeSehrjoobBgWlwarbvIFmvEvfM9q2q2nc9NBuMTPMg6g635JcOwx4z M5Mg== X-Gm-Message-State: AOUpUlHkD0CTfsFdOp2avXBgJ33XaGeYhAB/mYV8PNgRJanHOWgAYJ8M HaOSx7Eok/WULwCWFuv+cLeycQ== X-Google-Smtp-Source: AAOMgpe97kN95069qembkJJRAU60lYvZTFM9k8tW6FVN0ixAGeAbrejthjVaOYvcBBccAYbphTbhcA== X-Received: by 2002:a6b:b685:: with SMTP id g127-v6mr24485686iof.209.1531324982126; Wed, 11 Jul 2018 09:03:02 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id t66-v6sm1374712ita.24.2018.07.11.09.03.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 09:03:01 -0700 (PDT) To: Brian E Carpenter , Andrew Sullivan , rfcplusplus@ietf.org References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> Date: Wed, 11 Jul 2018 10:03:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tQRI2doNalx6QTUPSYj3ev4HIUE7uptIE" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 16:03:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tQRI2doNalx6QTUPSYj3ev4HIUE7uptIE Content-Type: multipart/mixed; boundary="csdBRoabdUXhFWC0ozbSnjAnXA8jencHs"; protected-headers="v1" From: Peter Saint-Andre To: Brian E Carpenter , Andrew Sullivan , rfcplusplus@ietf.org Message-ID: <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> Subject: Re: [Rfcplusplus] Conversation as metaphor References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> In-Reply-To: --csdBRoabdUXhFWC0ozbSnjAnXA8jencHs Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/10/18 8:14 PM, Brian E Carpenter wrote: > On 11/07/2018 08:45, Andrew Sullivan wrote: > .... >> Others seem to be arguing that the RFC series should in fact welcome >> anything on any topic, >=20 > Really? I haven't seen that and it seems like a strawman to me. >=20 > The Independent stream has criteria that have already been mentioned > here; relevance to the Internet and surviving peer review are among the= m. >=20 >> and as long as they can find someone willing to >> let them in, there's no reason they shouldn't be in the RFC series too= >> (i.e. we shouldn't prohibit people "from publishing RFCs when they >> want to do so and find it valuable to do so"). It is an interesting >> question whether, if I wanted to publish an RFC about Wittgenstein's >> remarks on colour, whether the ISE would consider it. We do have the >> April 1st ones, after all. >=20 > But even they are tested for relevance to the Internet and are peer > reviewed, just not in public for fairly obvious reasons. In what sense are Independent Stream documents peer reviewed? At a higher level, is there a good definition of "peer review" so that we can understand how documents from the various streams map to that definition? Peter --csdBRoabdUXhFWC0ozbSnjAnXA8jencHs-- --tQRI2doNalx6QTUPSYj3ev4HIUE7uptIE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltGKjQACgkQZWGMGH9o FKnCDw//UIACA8KFz67ZQp0Jm8QVMc+CoZ2GaDZwbmzA32FURedmWo+5q5d6xkfk F4PRT7vKf2k3ff5BxEsamVH1nnvBKb7fioQP9Zzjr9qvW3Z1UXhQYZkVNqIpUhLL VRX4u35Qy5TthDSndzcBKDziA0OSZi9EbaVQgv2jUXiuu/1xrSDQvLtQknpXmvDm XVkvHgZoqhE5V1OfsbKm33xW9vA/k7xnTEgCh36RV0p3mSg/vLXi1pPk0wRqUa2v 73Ds6Lrg+Cwd3c3d+c5PMHosvEvCTIN+OAJuLF/FaB0MiaBP3+0jEB++vv3v1bTk ybTfSvQu3KDjyqKiGTpowHUa3t7EJioEezUIDHogeK4VSy79ddw89mqzD65lCopB Fo1t+epXoFvTUaxoFRJqeqJBIJBMW8k+cebqlJvauNQtuDxvSSSDYyu3Co6Dh0BD Llge4By4RQFRv9rhBwIyb7HR/e6Yk+bxsOlwVJWwiSlz/Qh560lVdf4rUqLBXDDf i7z0ffj82dAJo5+UJrkbxhwYPl0tNTD9QeZAaGDq1peKL3+e0lM1dUkAjPzX0mu7 ApSdlaNhLF93P0dP6bJCHNW9NDUtvTVeRcPkBlH6TCytK8X6BRuoVQxJTKBc6Cqs 5gMO+8rY8L2cF5PTM72L6WHHLxrChr3BUu/W/RV7iDEvyrE/cYg= =J0Ec -----END PGP SIGNATURE----- --tQRI2doNalx6QTUPSYj3ev4HIUE7uptIE-- From nobody Wed Jul 11 09:19:36 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F67130F49 for ; Wed, 11 Jul 2018 09:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk2T3A51uz1T for ; Wed, 11 Jul 2018 09:19:32 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A38C130E24 for ; Wed, 11 Jul 2018 09:19:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 0E9B31D1B89; Wed, 11 Jul 2018 09:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmBD4-UJ-HhB; Wed, 11 Jul 2018 09:19:28 -0700 (PDT) Received: from www.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 9B4BC1D1B86; Wed, 11 Jul 2018 09:19:28 -0700 (PDT) Received: from 84.51.152.6 (SquirrelMail authenticated user rfcpise) by www.amsl.com with HTTP; Wed, 11 Jul 2018 09:19:28 -0700 Message-ID: In-Reply-To: <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> Date: Wed, 11 Jul 2018 09:19:28 -0700 From: "RFC ISE (Adrian Farrel)" To: "Peter Saint-Andre" Cc: "Brian E Carpenter" , "Andrew Sullivan" , rfcplusplus@ietf.org Reply-To: rfc-ise@rfc-editor.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 16:19:35 -0000 Peter Saint-Andre wrote: > In what sense are Independent Stream documents peer reviewed? > > At a higher level, is there a good definition of "peer review" so that > we can understand how documents from the various streams map to that > definition? Peter, "what is a peer and what constitutes a peer review?" are questions that have bothered me for a while even for tier one journals. I have received some frankly appalling journal reviews over the years (and I say that not just because I have disagreed with them) where the reviewers have clearly not understood the fundamentals of the material. I suspect we have all read journal article where we have wondered about the source of the substance being smoked. So you might be asking: what review is performed on the Independent Submissions stream? There is no secret about that, so here is a summary in no particular order: - The ISE reviews. This might not be a subject matter expert review as the ISE is a generalist with some areas of detailed knowledge. The review is often more for consistency and readability. - The ISE commissions two or three reviews from persons suggested by the authors but who are not directly involved in the work. It is evident to the ISE from these reviews whether the reviewer has sufficient subject knowledge to be classed as a peer. Note that failure to get sufficient reviews in this class is gating on publication - if even the authors can't find people to review their work then it really is of limited interest. - The ISE requests reviews from other experts in the IETF community. These are often drawn from the ISEB (names available on the web), but may be people that the ISE can see have a close interest in the subject matter. (If you would like to be more involved in this sort of review then I will bite your hand off!) - The RFC 5742 review by the IESG often draws review comments, although the IESG is not required or expected to provide such a review. Cheers, Adrian PS. Some I-Ds pass through WG and IETF last call with no comments at all (possibly suggesting no one is reviewing them) and get relatively light review in the IESG. Saying that is not an attack - just a comparison. -- Adrian Farrel (ISE), rfc-ise@rfc-editor.org From nobody Wed Jul 11 09:24:28 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A00130F52 for ; Wed, 11 Jul 2018 09:24:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 TV0dxWWDFWpO for ; Wed, 11 Jul 2018 09:24:24 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 422AA130E69 for ; Wed, 11 Jul 2018 09:24:24 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id l25-v6so24275546ioh.12 for ; Wed, 11 Jul 2018 09:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=1LhXsL8KnfQVHV3Tcz5GqOtA0ksTDitsvgITyXmlsVg=; b=R3IlL104iLwYe2TzvmSWoyWcs2gl2bkXsjd5hgN0xSU6W5QEWr1g/W2TrJeyW1Ly7m 7uZys+ZusC/SA6eHNe9Ba/3HdLOawi5CPqoyVNdddLb7RA4RaMotIE0AIHb78RBG2gZ8 o91N0sdRDonlvJc0AK30KhFF0U1uKTK5cAcuA= 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=1LhXsL8KnfQVHV3Tcz5GqOtA0ksTDitsvgITyXmlsVg=; b=r4zgAi/7taxa7UA6ZqSSQwoArb7co6g/LA9mpj4VyZIXyllNGkUQqOlj6Bvn/S7Xvl bn6LLQNCLa3xVqDkU2Kd28r0G1b+IsotE/xXdFaHJEaHEsTCIHvGOtJWQg4GJVJab/DT 99/I0MJgLbrSG/R8vWmFD+NeX+AQfPRlc2xKzZU4XDrpozTZYD2vzs0n6k05mXIKmOGg FROmd5ie9bnicthZSdBUp0K6NMbs0qBh/eSimX8HKT2AmfUl2h+OcbZVw0b7Jq9hskDb aFjOKXsjld3HUmjYCFq/qtY/YCl9gkPg5iIsC+MZkbyUF6J/pcI/hIhLcbh7rG3Pcp9R WWiw== X-Gm-Message-State: APt69E3JVaMZCh2iWT+zcmT2p+1u3uyFXnN9gfHR61iARjvbMdZ170zp lPU1+uTpsLCsesGZeZTKLbbzQQ== X-Google-Smtp-Source: AAOMgpcRuIe6GTqOwevhQtNTHNRtuXNCA+5Q6AQyoLQsSd77pZuSqrgb0UGFOhEziRenD/gpSRjo7w== X-Received: by 2002:a6b:254e:: with SMTP id l75-v6mr23818383iol.47.1531326251314; Wed, 11 Jul 2018 09:24:11 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id w20-v6sm6460197iob.24.2018.07.11.09.24.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 09:24:09 -0700 (PDT) To: rfc-ise@rfc-editor.org Cc: Brian E Carpenter , Andrew Sullivan , rfcplusplus@ietf.org References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Wed, 11 Jul 2018 10:24:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="83zaD4GQXQOK2115KgQQd60Rj6nEtycHD" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 16:24:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --83zaD4GQXQOK2115KgQQd60Rj6nEtycHD Content-Type: multipart/mixed; boundary="kgCZR81fOHbEkZm6qMj0ee5p5M1HpJHzN"; protected-headers="v1" From: Peter Saint-Andre To: rfc-ise@rfc-editor.org Cc: Brian E Carpenter , Andrew Sullivan , rfcplusplus@ietf.org Message-ID: Subject: Re: [Rfcplusplus] Conversation as metaphor References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> In-Reply-To: --kgCZR81fOHbEkZm6qMj0ee5p5M1HpJHzN Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/11/18 10:19 AM, RFC ISE (Adrian Farrel) wrote: > Peter Saint-Andre wrote: >=20 >> In what sense are Independent Stream documents peer reviewed? >> >> At a higher level, is there a good definition of "peer review" so that= >> we can understand how documents from the various streams map to that >> definition? >=20 > Peter, "what is a peer and what constitutes a peer review?" are questio= ns > that have bothered me for a while even for tier one journals. I have > received some frankly appalling journal reviews over the years (and I s= ay > that not just because I have disagreed with them) where the reviewers h= ave > clearly not understood the fundamentals of the material. I suspect we h= ave > all read journal article where we have wondered about the source of the= > substance being smoked. >=20 > So you might be asking: what review is performed on the Independent > Submissions stream? There is no secret about that, so here is a summary= in > no particular order: >=20 > - The ISE reviews. This might not be a subject matter expert review as = the > ISE is a generalist with some areas of detailed knowledge. The review i= s > often more for consistency and readability. >=20 > - The ISE commissions two or three reviews from persons suggested by th= e > authors but who are not directly involved in the work. It is evident to= > the ISE from these reviews whether the reviewer has sufficient subject > knowledge to be classed as a peer. Note that failure to get sufficient > reviews in this class is gating on publication - if even the authors ca= n't > find people to review their work then it really is of limited interest.= >=20 > - The ISE requests reviews from other experts in the IETF community. Th= ese > are often drawn from the ISEB (names available on the web), but may be > people that the ISE can see have a close interest in the subject matter= =2E > (If you would like to be more involved in this sort of review then I wi= ll > bite your hand off!) >=20 > - The RFC 5742 review by the IESG often draws review comments, although= > the IESG is not required or expected to provide such a review. Thanks for the clear summary of process and criteria. > PS. Some I-Ds pass through WG and IETF last call with no comments at al= l > (possibly suggesting no one is reviewing them) and get relatively light= > review in the IESG. Saying that is not an attack - just a comparison. Most definitely. We as a community seem to be confused about what level of "peer review" we think is important, appropriate, necessary, or sufficient. We're engineers, not academics, so comparing our publications to academic journals might not be relevant. Peter --kgCZR81fOHbEkZm6qMj0ee5p5M1HpJHzN-- --83zaD4GQXQOK2115KgQQd60Rj6nEtycHD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltGLygACgkQZWGMGH9o FKmasg/7BXO+/1C/aJu/ywnMfproVunpW8Yb9rRmyxh3sV12sWXi2JzB3dlGuAa9 Qkp/TVVV3jklE8ws2SgDXmUSAqxvZvWaaKphXXthNR3vWvcrQYcflX3y2408/Wb6 NjVMNczAtBT5Etrxz7ao+5ddCW5RD+lD+mloBd7lwOqAQxec2IJdDU+pqSClKe80 mUgyJDVBDcg88mK/DVz92XJxUuBxjaSJw56MA7mr9cwQlbAOZewGrWK4vr/mu/0y ZH+LSlHWL+sh5J968rPFv6HoKxnL9Nf7dwTp+Ta5Cz/azii4aRc53uzhY313lr8N kiWH9Yu0MEIvYidTlYoUwrQRB8QPD2QIp7yyqJcTyhJkhROxyvsw7BVfElI0ovAk 6zErgeRERfoIzrXtt9GQkJL47j6DuP+XYh0z5dXKsfYgnd72tMaraTctSVm7XSg2 PpAL4OKjC8ytGlZLPLZjHV0Kpayq+cSCovyj4K+7SBxe2bmdjQTnXBZmilDo6N3I 48EOEh9LxImJpnD+UEzZ30ptQE1VqQctGrthTNLW4P/KS29pjXBMVQr43HxvkKOi 7dFTD4SL6sDO1FvboBkJF6yH25Ni4lNxjCd4LB8sIz8BJj1RXWaxlt0+2jfkqFv7 wNCWA0+e45iMUVIMhHTA4kZNKHLD7IIR0IUbjBSIlCPfWYRm/1w= =zPsg -----END PGP SIGNATURE----- --83zaD4GQXQOK2115KgQQd60Rj6nEtycHD-- From nobody Wed Jul 11 10:26:19 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D61130DF2 for ; Wed, 11 Jul 2018 10:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 cRJeJcai1Pec for ; Wed, 11 Jul 2018 10:26:17 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 073A6130E40 for ; Wed, 11 Jul 2018 10:26:14 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id l9-v6so7215693pff.9 for ; Wed, 11 Jul 2018 10:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Sw/veljJCPRDmSrRaIhKjsgpVTParyWkmcS/4VvI3dE=; b=V8/DqI7U0EFo/o0KBrHaCT1F2vugF137cprtZtIOK5wCseiJulhDs3j8YNUtHW6w/S MJ1NHXUmP2oF83lYsuI1p2lRSnyFV9fYn2DWY2LZIqZMFUUOZHicMbasSYpgZXNMcdJ/ 83OePr3Qt0ngcofibrbwqcsRZc6IQpqo9tIi02FGkkyZEynlcJbGP07jdVxdccww9PTb IKXPrF9iKlmGHuYJvhMnSUTvYs9YiWbib0pbmFA0evdithsUb+yHKUiXohfmYD+vfwXN CYHLZDgpWOBLHnJPLLstvKfoHncezVQGG4+d3uAbt1yIDEE+NV85jNlkJ6M/x5YdonOL 5ZYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Sw/veljJCPRDmSrRaIhKjsgpVTParyWkmcS/4VvI3dE=; b=cKNImzxdMb4H98hV6v+Kzh+gSv4ZxKeQj+VMhIhn3WTMqFvH52EZOHpsLsCWll/nAA 7+uGgzannxaLameG9Qt3w29yaeaqCrygF1EVfpgDZvCvwv9lx7Hoj5Xz17hqZXXNAJNh SYm7LS0yv6hm/ekM6a9y5+5FHVkBKWu8r5ZaMJUk+RCl2MWTeo4ffxKL3kjiiOxkb3DK 7nQLdqJPdVwrT5whXyJZICY78GrT5M9UsKtwF7cXPDv33jQARTSep3HfCg7QHkTIHyde wjxQYnGIQQ7EqjxuwKuim5viqlL4wYUdBaak2eEeP615RdoHWJl9ue6HY6mi9IFDgNoa ydOQ== X-Gm-Message-State: APt69E2r6JgMC201o8rryxJyvMrIywW2iLCtuH8wY3e7aZeXv4cIPXrT U5Zzex7XrCwbyjvvq7aASl/T0vnZ9YXdziW4VdQ= X-Google-Smtp-Source: AAOMgpef0/WehxYr1ZASwaUR/772EmtJjxwfZ4rgi7LQTsMQ0lTFoL2F3wi1DvnG6K6TnsrvjZ7/e+nb1SaJ1ogL4/0= X-Received: by 2002:a62:5984:: with SMTP id k4-v6mr30685900pfj.116.1531329973289; Wed, 11 Jul 2018 10:26:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:ac18:0:0:0:0 with HTTP; Wed, 11 Jul 2018 10:26:12 -0700 (PDT) From: Allison Mankin Date: Wed, 11 Jul 2018 13:26:12 -0400 Message-ID: To: "Rfcplusplus@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001788750570bc8b08" Archived-At: Subject: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 17:26:19 -0000 --0000000000001788750570bc8b08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (IRTF Chair hat on) One of my goals as IRTF Chair is precisely to create a new, non-RFC stream for the IRTF. So, IRTF is very much an interested party in this BOF. The most common response I get during outreach into academia is that RFCs aren=E2=80=99t a good medium for most academics. This is despite researcher= s=E2=80=99 wish eventually to have ideas deployed. We=E2=80=99ve been exploring what work p= roduct will best serve the research community, and . this does include distinguishing the work from the RFCs. I like Brian Trammell=E2=80=99s disc= ussion in the =E2=80=9Cconversation=E2=80=9D thread very much, btw; he has express= ed how academics and pseudo-academics contribute very well. I notice there has been little call for data about IRTF and RFCs. I think it=E2=80=99s because RFC does mostly signify a production brand. I=E2=80=99= d encourage the other streams to examine what makes them production-ready. We in IRTF do have some work close to production, for example, CFRG crypto recommendations. I would want to talk with IESG about appropriate AD sponsorship when that would be the best context for a draft. Other work we would like to place into an IRTF stream with a new brand. I expect us to start developing an open, academically reviewed proceedings/journal soon, to best serve our researcher contributions. It will focus on applied research and running code, similar to ANRW. In summary, IRTF is ready to start our part of an rfcplusplus experiment. We are a part of the IETF community and indeed a part of this BOF (this responds to Brian Carpenter=E2=80=99s comment quoted below). Allison =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94- Brian Carpenter wrote: Ted, It would be on topic if there was a proposal inside the IRTF to change the publication venue for IRTF output. But this is an IETF BOF so all we can do is discuss how IETF stream documents are published. I know this is an inconvenient truth for some people, but there it is. Brian --0000000000001788750570bc8b08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(IRTF Chair hat= on)
One of my goals as IRTF Chair is precisely to create a new, non-RF= C stream for the IRTF. So, IRTF is very much an interested party in this BO= F.=C2=A0

The most common response I get during outreach into a= cademia is that RFCs aren=E2=80=99t a good medium for most academics. This = is despite researchers=E2=80=99 wish eventually to have ideas deployed. We= =E2=80=99ve been exploring what work product will best serve the research c= ommunity, and . this does include distinguishing the work from the RFCs. I = like Brian Trammell=E2=80=99s discussion in the =E2=80=9Cconversation=E2=80= =9D thread very much, btw; he has expressed how academics and pseudo-academ= ics contribute very well.
<= span style=3D"font-size:14px">
I notice there has been little call = for data about IRTF and RFCs. I think it=E2=80=99s because RFC does mostly = signify a production brand. I=E2=80=99d encourage the other streams to exam= ine what makes them production-ready.

We in IRTF do have som= e work close to production, for example, CFRG crypto recommendations. I wou= ld want to talk with IESG about appropriate AD sponsorship when that would = be the best context for a draft.=C2=A0

Other work we would li= ke to place into an IRTF stream with a new brand. I expect us to start deve= loping an open, academically reviewed proceedings/journal soon, to best ser= ve our researcher contributions. It will focus on applied research and runn= ing code, similar to ANRW.=C2=A0

In summary, IRTF is ready to = start our part of an rfcplusplus experiment. We are a part of the IETF comm= unity and indeed a part of this BOF (this responds to Brian Carpenter=E2=80= =99s comment quoted below).

Allison=C2=A0
<= div>
=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94-
<= br>
Brian Carp= enter wrote:

Ted,

It would be on topic if there wa= s a proposal inside the IRTF to change=C2=A0the publication venue for IRTF output. But this = is an IETF BOF so all=C2=A0we can do is discuss how IETF stream documents are published.

I know this is an inconvenient truth for some people, but there it is.

=C2=A0=C2=A0=C2=A0Brian --0000000000001788750570bc8b08-- From nobody Wed Jul 11 10:39:02 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FAB130F63 for ; Wed, 11 Jul 2018 10:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=Sfb3wUTm; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=iNBgERo2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lVuz5lNNUiU for ; Wed, 11 Jul 2018 10:38:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 487FC130F62 for ; Wed, 11 Jul 2018 10:38:58 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.224.109.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id w6BHckbC011515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2018 10:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1531330737; x=1531417137; bh=OMvxu/qefH69Lwwm4pNAmfHGeCTg6JO9lWfT3hrk8OQ=; h=Date:To:From:Subject:In-Reply-To:References; b=Sfb3wUTmMaazwZcytuZIEDf4qEeyVr5udsQLM9qvs/8k8pvQq+X+id9AZn4OX05eG nbLG4/N3UnzR8yF5BSsKNDjolr/3uW+QbmcfdeD4IVTojmUCiPsPB2XVNqkhMMOnRe h3QsWIkOS2kMP8YZW/Jy9a7hybnT+Nv1csGHdxg4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1531330737; x=1531417137; i=@elandsys.com; bh=OMvxu/qefH69Lwwm4pNAmfHGeCTg6JO9lWfT3hrk8OQ=; h=Date:To:From:Subject:In-Reply-To:References; b=iNBgERo2Fqx+zsjzgAXDa2LWfPYLzpUsrGfKoUfzTgOziuzcj16orZCEtLy9K6N+h RobrnRtZgeLkB3lfzDjQwQb+3RR2x0F/nWmLAFJylBFZFNbcalLwPuIBKpZSiLVSfp 4HXfUIQGOUY3ZpCq1uzDneQ5Epq3cQuZprxcPoV8= Message-Id: <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jul 2018 10:38:01 -0700 To: Peter Saint-Andre , rfcplusplus@ietf.org From: S Moonesamy In-Reply-To: References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 17:39:00 -0000 Hi Peter, At 09:24 AM 11-07-2018, Peter Saint-Andre wrote: >We as a community seem to be confused about what level of "peer review" >we think is important, appropriate, necessary, or sufficient. We're >engineers, not academics, so comparing our publications to academic >journals might not be relevant. Do IETF participants need a license [1] in the practice of engineering? There are academics who have authored RFCs in some of the Streams. There is an IAB RFC about citability of for scholarly publications. Why would academic journals not be relevant? There has to be some level of review or else there wouldn't be any quality control. I agree that there is some confusion on the level of review which is required. It has been an issue over the past decade. Some of the discussions about RFCs have a strong correlation to "IETF problems". Regards, S. Moonesamy 1. https://www.nytimes.com/2017/04/30/business/traffic-light-fine.html From nobody Wed Jul 11 10:53:36 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F790130E31 for ; Wed, 11 Jul 2018 10:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHuHHqmE1SpB for ; Wed, 11 Jul 2018 10:53:32 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30474130DF2 for ; Wed, 11 Jul 2018 10:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4755; q=dns/txt; s=iport; t=1531331612; x=1532541212; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=ta5xh7WMzjOAGCmDtC/voeE6WZKXA8FmbRkq3B8lBUg=; b=FDWjiBoz1jKjZ0OtnFRBejtplrJ1MxDRQzkVnAyMizHKcRsVePNVE0QH tezG4JbnWtXSHQNwcDz1oGjGfbNPggcBifIcFAkNH0uFyPSSFziGqSvBq i17v0Hzf4V/iPpPmNetXc47hIou2YvYTUt4smDjPsLs/hz+g8p6/ZFvyN o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AwCgQkZb/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJTgliEIohjjTgIJJAkhwgIA4RsAoJeOBQBAgEBAgEBAm0ohTc?= =?us-ascii?q?BBSNmCwQUKgICVwYBDAgBAYMcAYF/qjOBLh+JWA+HQoNSgRAnDIJeh3yCVQK?= =?us-ascii?q?ZVwmDXYFZiWsGgUOED4JHhUiSEoFYIYFSMxoIGxWDJZBUPY1iAQE?= X-IronPort-AV: E=Sophos;i="5.51,338,1526342400"; d="asc'?scan'208,217";a="5113602" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2018 17:53:30 +0000 Received: from [10.61.195.132] ([10.61.195.132]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w6BHrTnK023196; Wed, 11 Jul 2018 17:53:29 GMT To: Allison Mankin , "Rfcplusplus@ietf.org" References: From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <844ec8ff-26b9-4314-d71c-b75a00f3610f@cisco.com> Date: Wed, 11 Jul 2018 19:53:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Wjm5fkyMUa6VVTgSYzRJh3caLyjBNYran" Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 17:53:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Wjm5fkyMUa6VVTgSYzRJh3caLyjBNYran Content-Type: multipart/mixed; boundary="xrsMixa7H9p22vnoxZpubRsjDXxBNutc7"; protected-headers="v1" From: Eliot Lear To: Allison Mankin , "Rfcplusplus@ietf.org" Message-ID: <844ec8ff-26b9-4314-d71c-b75a00f3610f@cisco.com> Subject: Re: [Rfcplusplus] IRTF stream considerations References: In-Reply-To: --xrsMixa7H9p22vnoxZpubRsjDXxBNutc7 Content-Type: multipart/alternative; boundary="------------43D8CAF390CBEC040E29495E" Content-Language: en-US This is a multi-part message in MIME format. --------------43D8CAF390CBEC040E29495E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Allison and thanks.=C2=A0 I'd like to test you on one point: On 11.07.18 19:26, Allison Mankin wrote: > We in IRTF do have some work close to production, for example, CFRG > crypto recommendations. I would want to talk with IESG about > appropriate AD sponsorship when that would be the best context for a > draft.=C2=A0 > > Other work we would like to place into an IRTF stream with a new > brand. I expect us to start developing an open, academically reviewed > proceedings/journal soon, to best serve our researcher contributions. > It will focus on applied research and running code, similar to ANRW.=C2= =A0 > What would have been your preferred handling of the human rights considerations work?=C2=A0 Is that closer to a CFRG recommendation or a n= ew Thing?=C2=A0 Please keep in mind that many of us were comfortable with th= at document going out through the IRTF as it was, precisely because it WASN'T an IETF document. Eliot --------------43D8CAF390CBEC040E29495E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Allison and thanks.=C2=A0 I'd like to test you on one point:


On 11.07.18 19:26, Allison Mankin wrote:
We in I= RTF do have some work close to production, for example, CFRG crypto recommendations. I would want to talk with IESG about appropriate AD sponsorship when that would be the best context for a draft.=C2=A0

Other w= ork we would like to place into an IRTF stream with a new brand. I expect us to start developing an open, academically reviewed proceedings/journal soon, to best serve our researcher contributions. It will focus on applied research and running code, similar to ANRW.=C2=A0


What would have been your preferred handling of the human rights considerations work?=C2=A0 Is that closer to a CFRG recommendation or= a new Thing?=C2=A0 Please keep in mind that many of us were comfortable= with that document going out through the IRTF as it was, precisely because it WASN'T an IETF document.

Eliot
--------------43D8CAF390CBEC040E29495E-- --xrsMixa7H9p22vnoxZpubRsjDXxBNutc7-- --Wjm5fkyMUa6VVTgSYzRJh3caLyjBNYran Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltGRAoACgkQh7ZrRtnS ejNteQgAv07EY+qdevdbabuPzfIvBgpT/AlVwoId+nQzzoQCk3h7Zz9pr9c/bbrN h8QpDpA1gSEVI6jl3npmE8XcwYkiLffzqz7/pZhjncWcOm3dUzyIr96WwDJZkCGb 4XC0JufWJ6J4t/SqE6adwxjwGK3OisOS/yFRC3Yo2pYV5in5ygAM5B+QXvJ2viwY +caoapAKLAs2gJqI9ujEE5tWLndPcHuRITdmh+xKo6GdedILoQKgfPFC37naTJ+a NEWaRJevuB0FzWptFizluGdcp1hz8AJhHWgFV28PZRAYvK3CDeMzb0udZCMNIKL1 437HBhYrZZG6gDVowokDIXIxk+b1gQ== =zgqH -----END PGP SIGNATURE----- --Wjm5fkyMUa6VVTgSYzRJh3caLyjBNYran-- From nobody Wed Jul 11 11:02:23 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62BE130E4A for ; Wed, 11 Jul 2018 11:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonicacorp.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 BpiIu0JbVvHm for ; Wed, 11 Jul 2018 11:02:16 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30105.outbound.protection.outlook.com [40.107.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF1C130DF2 for ; Wed, 11 Jul 2018 11:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonicacorp.onmicrosoft.com; s=selector1-telefonica-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tKuHO6l7SLTSGEiagUUjMWK/2bQjbv8qnvf1ksw456g=; b=FZx+oqnWKGALneWOxNLgfGCs0m+wXOb1zvkqZgDEfjqbKf+TCM6oeKYSJBKjVVHI5uoD/eJlJDco4H2vyynomepxo3NzVKc6TGEmEUOcrD4hVsIEOR19DwQK7JYIl7Iau+7aHE735RFcrLEvt+eI+UV3UiNDvOX7uGA0rHbrwfY= Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com (52.134.70.148) by DB3PR0602MB3676.eurprd06.prod.outlook.com (52.134.73.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.19; Wed, 11 Jul 2018 18:02:13 +0000 Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::e8a7:c15c:d575:4c71]) by DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::e8a7:c15c:d575:4c71%4]) with mapi id 15.20.0930.016; Wed, 11 Jul 2018 18:02:13 +0000 From: "Diego R. Lopez" To: Aaron Falk , Kathleen Moriarty CC: "Heather Flanagan (RFC Series Editor)" , "rfcplusplus@ietf.org" Thread-Topic: [Rfcplusplus] Marketing, Branding, and Subject Matter Expertise Thread-Index: AQHUGL2oYrfimg84UkCLmeUi0vm8FKSJWyQAgAD8UYA= Date: Wed, 11 Jul 2018 18:02:09 +0000 Message-ID: <5AD14A9C-4E7B-4967-8A22-0C3FD932F80B@telefonica.com> References: <4444ba48-a52b-00c3-6770-e9cab66eacb2@rfc-editor.org> <31C349A4-5A87-40A8-B8E3-8B695688C0DD@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180701 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [87.235.190.32] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0602MB3676; 7:htM8BwWulkA+IILdJWwr+xex7D4HhgHny/Uir0gU+5oVIt/2Y85hRzvGnH+c7hx0AtsKVOFmufd96MmfSUM7J6WGUvZdrLA5A90251SPusv4cV5oiScYytFm64g7LsFbTBgBILAKrgZxpOa92G057367n3wGwcSp0lnqPc9cU1H90HRwx96c9JfJ/vk3YtnBGbXDsQ2SJY2pi4kK8QaNAFfqk3Vn1Aa6BcXs/BnYqPCa08mUJcjwJ1Rc8iUXsfSt x-ms-office365-filtering-correlation-id: adba2844-eae3-4850-9ed0-08d5e7586e38 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(40392960112811); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DB3PR0602MB3676; x-ms-traffictypediagnostic: DB3PR0602MB3676: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(40392960112811)(223705240517415)(85827821059158)(128460861657000)(21748063052155)(81160342030619); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DB3PR0602MB3676; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0602MB3676; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(39860400002)(366004)(396003)(346002)(53754006)(40134004)(252514010)(25724002)(199004)(189003)(53546011)(478600001)(256004)(36756003)(966005)(2900100001)(6436002)(4326008)(97736004)(6486002)(102836004)(186003)(316002)(8676002)(786003)(54906003)(6506007)(106356001)(7736002)(58126008)(236005)(8936002)(81166006)(82746002)(81156014)(105586002)(5660300001)(26005)(110136005)(45080400002)(6306002)(606006)(99286004)(486006)(3846002)(6116002)(476003)(68736007)(83716003)(14454004)(76176011)(66066001)(2616005)(33656002)(446003)(54896002)(53936002)(25786009)(6666003)(6512007)(229853002)(14444005)(6246003)(86362001)(5250100002)(11346002)(39060400002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR0602MB3676; H:DB3PR0602MB3788.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Bh/x9zky3kj07sg2mzskcE+Muo21J+u23Z6BY7iQMjYk2ndUekXmxcM2o4binzP5PXOcR3VZAxfzF13w3IWNDKys6lNzqPRMwClBEqcdfbSHmedWtBi6YmQivmFho9mGpBFQ5uADKpIruRwvFv9FuPUTjGEicQymz9GasSqMI2T9Sechvy0b6BMIDjm/K4NfEo49iu8XrTSONzVbhhcjhyT4ngHB+RrHgi0X1PC75KAxw5Co5fBBI5TdXQQ3TCfoaBLf4b5OHa/THoR+n1V6wB7dIZjx0/YYFuEr6kkaI53+E7vspbNHdS04RJhWw3kK8GM/OBimKy30UilNYFv5wWTefJ7uB3Y5/qeqBfZfAes= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5AD14A9C4E7B49678A220C3FD932F80Btelefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: adba2844-eae3-4850-9ed0-08d5e7586e38 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2018 18:02:09.9610 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0602MB3676 Archived-At: Subject: Re: [Rfcplusplus] Marketing, Branding, and Subject Matter Expertise X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:02:21 -0000 --_000_5AD14A9C4E7B49678A220C3FD932F80Btelefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gY291bGQgSSwgYW5kIEkgZ3Vlc3MgYSBidW5jaCBvZiBvdGhlcnMgd29ya2luZyBpbiBjb21w YW5pZXMgYXBwbHlpbmcgUkZDcyB0byBzdWNoIHRhc2tz4oCmDQoNCi0tDQoiRXN0YSB2ZXogbm8g ZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZv bmljYSBJK0QNCmh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9kcjJsb3Blei8NCg0KZS1tYWls OiBkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tPG1haWx0bzpkaWVnby5yLmxvcGV6QHRlbGVm b25pY2EuY29tPg0KVGVsOiAgICAgICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiAgKzM0IDY4 MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk9uIDExLzA3 LzIwMTgsIDA2OjIyLCAiUmZjcGx1c3BsdXMgb24gYmVoYWxmIG9mIEFhcm9uIEZhbGsiIDxyZmNw bHVzcGx1cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpyZmNwbHVzcGx1cy1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgYWFyb24uZmFsa0BnbWFpbC5jb208bWFpbHRvOmFhcm9uLmZhbGtA Z21haWwuY29tPj4gd3JvdGU6DQoNCkFzIGEgY29uY3JldGUgc3VnZ2VzdGlvbiBhbG9uZyB0aGVz ZSBsaW5lcywgaWYgdGhlcmUgd2VyZSBhIHdlbGwtY3JhZnRlZCBxdWVzdGlvbm5haXJlIG9uIGhv dyByZmNzIGFyZSBwZXJjZWl2ZWQgYW5kIHVzZWQsIEkgY291bGQgYmUgb3BlbiB0byBzaGVwaGVy ZGluZyBpdCB0aHJvdWdoIHZhcmlvdXMgZ3JvdXBzIGluIG15IGNvbXBhbnkgdGhhdCBzZWUgYW5k IGlzc3VlIFJGUHMsIGltcGxlbWVudCBwcm90b2NvbHMgZXRjLg0KDQpBYXJvbg0KDQoNCk9uIFR1 ZSwgSnVsIDEwLCAyMDE4IGF0IDIyOjE5IEthdGhsZWVuIE1vcmlhcnR5IDxrYXRobGVlbi5tb3Jp YXJ0eS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5j b20+PiB3cm90ZToNCkkgYWdyZWUuICBUaGUgcHJvYmxlbSBhbmQgc2NvcGUgbmVlZHMgdG8gYmUg bWFkZSBtb3JlIGNsZWFyLiAgVGhpcyBpcyBhIGNvbW1vbiB0aGVtZSBmcm9tIHBhcnRpY2lwYW50 cyBvbiB0aGUgbGlzdCB0aGF0IGFyZSBub3QgcHJvcG9uZW50cy4gIEkgZG8gaG9wZSB0aGF0IHRo aXMgZWZmb3J0IHN0ZXBzIGJhY2sgdG8gZGVmaW5lIHRoZSBwcm9ibGVtIGFuZCBzY29wZSBiZWZv cmUgaW5pdGlhdGluZyBhbnkgZXhwZXJpbWVudCBpbiBjYXNlIHRoZSBvbmUgaW4gbWluZCBmcm9t IHByb3BvbmVudHMgZG9lcyBub3Qgc29sdmUgdGhlIHByb2JsZW0ocykgdGhleSBjaXRlLg0KDQpF bmdhZ2luZyBleHBlcnRzIGFzIEhlYXRoZXIgc3VnZ2VzdHMgc291bmRzIGxpa2UgYSB2ZXJ5IHVz ZWZ1bCBleGVyY2lzZSBnaXZlbiB0aGUgcG9zc2libGUgaW1wYWN0IG9mIHByb3Bvc2FscyBkaXNj dXNzZWQgc28gZmFyLg0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0KDQpTZW50IGZyb20gbXkg bW9iaWxlIGRldmljZQ0KDQo+IE9uIEp1bCA5LCAyMDE4LCBhdCAxOjM2IFBNLCBIZWF0aGVyIEZs YW5hZ2FuIChSRkMgU2VyaWVzIEVkaXRvcikgPHJzZUByZmMtZWRpdG9yLm9yZzxtYWlsdG86cnNl QHJmYy1lZGl0b3Iub3JnPj4gd3JvdGU6DQo+DQo+IEhlbGxvIGFsbCwNCj4NCj4gRWFybHkgb24g aW4gdGhlIHByb2Nlc3MgdGhhdCBzcHVuIGludG8gdGhlIEJvRiwgYmVmb3JlIGl0IGJlY2FtZSBh IEJvRiwgSSBzdWdnZXN0ZWQgdGhhdCB0YWtpbmcgYSBzdGVwIGJhY2sgdG8gcHJvcGVybHkgcmV2 aWV3IGFuZCBjbGFyaWZ5IHRoZSBzY29wZSBvZiB0aGUgcHJvYmxlbSwgYW5kIHRvIGRldGVybWlu ZSB0aGUgdmFyeWluZyBvcHRpb25zIHdlIGhhZCAoYW5kIHdpbGwgaGF2ZSkgZm9yIHNvbHZpbmcg dGhlbSBtYWRlIG1vcmUgc2Vuc2UgdGhhbiB0aHJvd2luZyBhbiBpZGVhIGFnYWluc3QgdGhlIGZp Z3VyYXRpdmUgd2FsbCB0byBzZWUgaWYgaXQgd291bGQgc3RpY2suIEkgc3RpbGwgdGhpbmsgdGhh dCBpZGVhIGlzIGEgZ29vZCBvbmUsIGFuZCBzb21ldGhpbmcgdGhhdCBJIHNob3VsZCBiZSBoYW5k bGluZyBhcyBSU0UuIE9uZSBvZiB0aGUgdGhpbmdzIEkgd291bGQgbGlrZSB0byBkbyBpcyB0YWxr IHRvIHBlb3BsZSB3aG8gdW5kZXJzdGFuZCBtYXJrZXRpbmcgYW5kIGJyYW5kaW5nIGZvciBhIGxp dmluZy0tdGhlcmUgYXJlIHBlb3BsZSBhdCBJU09DIHRoYXQgaGF2ZSB0aGUgbGV2ZWwgb2YgZXhw ZXJpZW5jZSBJIHRoaW5rIHdlIG5lZWQtLXJhdGhlciB0aGFuIHdhdGNoIGlkZWFzIGFib3VuZCBm cm9tIHZlcnkgc21hcnQgZW5naW5lZXJzLg0KPg0KPiAtSGVhdGhlcg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSZmNwbHVzcGx1cyBtYWls aW5nIGxpc3QNCj4gUmZjcGx1c3BsdXNAaWV0Zi5vcmc8bWFpbHRvOlJmY3BsdXNwbHVzQGlldGYu b3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JmY3BsdXNwbHVz DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSZmNw bHVzcGx1cyBtYWlsaW5nIGxpc3QNClJmY3BsdXNwbHVzQGlldGYub3JnPG1haWx0bzpSZmNwbHVz cGx1c0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmZj cGx1c3BsdXMNCi0tDQotLSBhYXJvbiBTZW50IGZyb20gR21haWwgTW9iaWxlDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBz ZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5l ciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28g ZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVz dGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxh IGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3Jp emFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOz biB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dh bW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbD rWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNh dGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRy YW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSBy ZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0 aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNldXMg YW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBv ZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kg cGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBu w6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3Rp ZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3Ug Y8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBk YSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJv LCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEg bWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== --_000_5AD14A9C4E7B49678A220C3FD932F80Btelefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <091788D45D81614294DC63500A8165F1@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAzLjBjbSA3MC44NXB0IDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PlNvIGNvdWxkIEksIGFuZCBJIGd1ZXNzIGEgYnVuY2ggb2Ygb3RoZXJzIHdvcmtpbmcgaW4gY29t cGFuaWVzIGFwcGx5aW5nIFJGQ3MgdG8gc3VjaCB0YXNrc+KApjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mcXVvdDtFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8mcXVv dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkRyIERpZWdvIFIu IExvcGV6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRlbGVmb25pY2EgSSYjNDM7RDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij48YSBocmVmPSJodHRwczovL3d3dy5saW5rZWRpbi5jb20vaW4vZHIybG9wZXovIj48c3Bh biBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL2RyMmxv cGV6Lzwvc3Bhbj48L2E+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5lLW1haWw6Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+PGEgaHJlZj0ibWFpbHRvOmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5j b20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+PHNwYW4gbGFuZz0i RU4tVVMiPmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb208L3NwYW4+PC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+VGVsOiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JiM0MzszNCA5MTMgMTI5IDA0MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+TW9iaWxl OiAmbmJzcDsmIzQzOzM0IDY4MiAwNTEgMDkxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMTEvMDcv MjAxOCwgMDY6MjIsICZxdW90O1JmY3BsdXNwbHVzIG9uIGJlaGFsZiBvZiBBYXJvbiBGYWxrJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmZjcGx1c3BsdXMtYm91bmNlc0BpZXRmLm9yZyI+cmZj cGx1c3BsdXMtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWls dG86YWFyb24uZmFsa0BnbWFpbC5jb20iPmFhcm9uLmZhbGtAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPkFzIGEgY29uY3JldGUgc3VnZ2VzdGlvbiBhbG9uZyB0aGVzZSBsaW5lcywg aWYgdGhlcmUgd2VyZSBhIHdlbGwtY3JhZnRlZCBxdWVzdGlvbm5haXJlIG9uIGhvdyByZmNzIGFy ZSBwZXJjZWl2ZWQgYW5kIHVzZWQsIEkgY291bGQgYmUgb3BlbiB0byBzaGVwaGVyZGluZyBpdCB0 aHJvdWdoIHZhcmlvdXMgZ3JvdXBzIGluIG15IGNvbXBhbnkgdGhhdCBzZWUgYW5kIGlzc3VlDQog UkZQcywgaW1wbGVtZW50IHByb3RvY29scyBldGMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFhcm9uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPk9uIFR1ZSwgSnVsIDEwLCAyMDE4IGF0IDIyOjE5IEthdGhsZWVuIE1vcmlhcnR5 ICZsdDs8YSBocmVmPSJtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20iPmth dGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5JIGFncmVlLiZuYnNwOyBUaGUgcHJvYmxlbSBhbmQgc2NvcGUgbmVl ZHMgdG8gYmUgbWFkZSBtb3JlIGNsZWFyLiZuYnNwOyBUaGlzIGlzIGEgY29tbW9uIHRoZW1lIGZy b20gcGFydGljaXBhbnRzIG9uIHRoZSBsaXN0IHRoYXQgYXJlIG5vdCBwcm9wb25lbnRzLiZuYnNw OyBJIGRvIGhvcGUgdGhhdCB0aGlzIGVmZm9ydCBzdGVwcyBiYWNrIHRvIGRlZmluZSB0aGUgcHJv YmxlbSBhbmQgc2NvcGUNCiBiZWZvcmUgaW5pdGlhdGluZyBhbnkgZXhwZXJpbWVudCBpbiBjYXNl IHRoZSBvbmUgaW4gbWluZCBmcm9tIHByb3BvbmVudHMgZG9lcyBub3Qgc29sdmUgdGhlIHByb2Js ZW0ocykgdGhleSBjaXRlLjxicj4NCjxicj4NCkVuZ2FnaW5nIGV4cGVydHMgYXMgSGVhdGhlciBz dWdnZXN0cyBzb3VuZHMgbGlrZSBhIHZlcnkgdXNlZnVsIGV4ZXJjaXNlIGdpdmVuIHRoZSBwb3Nz aWJsZSBpbXBhY3Qgb2YgcHJvcG9zYWxzIGRpc2N1c3NlZCBzbyBmYXIuPGJyPg0KPGJyPg0KQmVz dCByZWdhcmRzLDxicj4NCkthdGhsZWVuIDxicj4NCjxicj4NClNlbnQgZnJvbSBteSBtb2JpbGUg ZGV2aWNlPGJyPg0KPGJyPg0KJmd0OyBPbiBKdWwgOSwgMjAxOCwgYXQgMTozNiBQTSwgSGVhdGhl ciBGbGFuYWdhbiAoUkZDIFNlcmllcyBFZGl0b3IpICZsdDs8YSBocmVmPSJtYWlsdG86cnNlQHJm Yy1lZGl0b3Iub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnNlQHJmYy1lZGl0b3Iub3JnPC9hPiZndDsg d3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhlbGxvIGFsbCw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgRWFybHkgb24gaW4gdGhlIHByb2Nlc3MgdGhhdCBzcHVuIGludG8gdGhlIEJvRiwgYmVmb3Jl IGl0IGJlY2FtZSBhIEJvRiwgSSBzdWdnZXN0ZWQgdGhhdCB0YWtpbmcgYSBzdGVwIGJhY2sgdG8g cHJvcGVybHkgcmV2aWV3IGFuZCBjbGFyaWZ5IHRoZSBzY29wZSBvZiB0aGUgcHJvYmxlbSwgYW5k IHRvIGRldGVybWluZSB0aGUgdmFyeWluZyBvcHRpb25zIHdlIGhhZCAoYW5kIHdpbGwgaGF2ZSkg Zm9yIHNvbHZpbmcgdGhlbSBtYWRlIG1vcmUgc2Vuc2UNCiB0aGFuIHRocm93aW5nIGFuIGlkZWEg YWdhaW5zdCB0aGUgZmlndXJhdGl2ZSB3YWxsIHRvIHNlZSBpZiBpdCB3b3VsZCBzdGljay4gSSBz dGlsbCB0aGluayB0aGF0IGlkZWEgaXMgYSBnb29kIG9uZSwgYW5kIHNvbWV0aGluZyB0aGF0IEkg c2hvdWxkIGJlIGhhbmRsaW5nIGFzIFJTRS4gT25lIG9mIHRoZSB0aGluZ3MgSSB3b3VsZCBsaWtl IHRvIGRvIGlzIHRhbGsgdG8gcGVvcGxlIHdobyB1bmRlcnN0YW5kIG1hcmtldGluZyBhbmQgYnJh bmRpbmcNCiBmb3IgYSBsaXZpbmctLXRoZXJlIGFyZSBwZW9wbGUgYXQgSVNPQyB0aGF0IGhhdmUg dGhlIGxldmVsIG9mIGV4cGVyaWVuY2UgSSB0aGluayB3ZSBuZWVkLS1yYXRoZXIgdGhhbiB3YXRj aCBpZGVhcyBhYm91bmQgZnJvbSB2ZXJ5IHNtYXJ0IGVuZ2luZWVycy48YnI+DQomZ3Q7IDxicj4N CiZndDsgLUhlYXRoZXI8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFJmY3BsdXNwbHVzIG1haWxpbmcg bGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOlJmY3BsdXNwbHVzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+UmZjcGx1c3BsdXNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JmY3BsdXNwbHVzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yZmNwbHVzcGx1 czwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NClJmY3BsdXNwbHVzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpSZmNwbHVzcGx1c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlJmY3BsdXNwbHVzQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcmZjcGx1c3BsdXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3JmY3BsdXNwbHVzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0tIGFhcm9uIFNlbnQgZnJvbSBHbWFpbCBNb2Jp bGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNl PSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPjxicj4NCkVzdGUgbWVuc2FqZSB5IHN1cyBh ZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVk ZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMg cGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNp IG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8g ZGUgcXVlIGxhDQogbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlh IHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEg bGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJy b3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVz dGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uPGJyPg0KPGJyPg0KVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2Vk IGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2Yg dGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVi eSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLA0KIGRpc3RyaWJ1dGlvbiBvciBjb3B5 aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQu IFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC48YnI+ DQo8YnI+DQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFt ZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZp bGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29h IG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0 aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGENCiBsZWl0dXJhLCB1 dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBw b2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNl IHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNv bXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEg ZGVzdHJ1acOnw6NvPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5AD14A9C4E7B49678A220C3FD932F80Btelefonicacom_-- From nobody Wed Jul 11 11:07:34 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B25130DF2 for ; Wed, 11 Jul 2018 11:07:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 wlRbv5f1dxpR for ; Wed, 11 Jul 2018 11:07:30 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 C41F0130E69 for ; Wed, 11 Jul 2018 11:07:27 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id v26-v6so24905214iog.5 for ; Wed, 11 Jul 2018 11:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=J94fA9WLx1xNhNFUombnq7iplajMef8ShtVmMU9a4ws=; b=aEdaUjKhroDAvNj8N0/SDJpL+pPQ22M6b/Tt70WALdn4PKohl/iOKz5aBHGExc6IaB wp1Bm93kMorzKC4FE6aN3wSCX28uxAWPLdlZw95Xy1tQ4n5toEIbowQzoWrFqh87U96i Wjb6ZJfIr2LIzTmPRTLPiPNiom1X3D2u53Jok= 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=J94fA9WLx1xNhNFUombnq7iplajMef8ShtVmMU9a4ws=; b=aJNQ2YaopKrKpDC2aqj9ynsKbDFPBVteYNPvxFGTEtlzx2Aae+4kYk+7QRz861Zmk+ N4p0eoLMwx/YmyMrMJ/6npsLwLtLeUCLuO45/cv4zDVr2qK3ezABmiFA3c/wxbNywOsn 8di+Om7WnTtdj1qCQ67UWhmO8wBQ2G26U2hsY2r/rZl+eKt9LvzSu0EhEV4XESOfP4Rn NzXOTXZlU00Nrhhe/FVMkJ9cBrKmtG3OfVzVXmAAR1P2jGIFT8i06W0HiAurDtDL2PxX 57QpQhrXUwt7npbXO7L158hLtayPLsH3ta6m3XMQgDwmh5YhVBRGGgzfisuDdrZEBxjS n0nA== X-Gm-Message-State: APt69E0uzZ75cLHOtVHkwvJaKHdknyy6nAYzyrSnRe7xXLj/tHoLR0Nq rX6bQaJnOCy9UE/ACVwFqa0NpQ== X-Google-Smtp-Source: AAOMgpebyuVokoZsl55SLpG793Ozvimar7TGfOgpxriETBqa8qiWG/TUBKjn2WbrRVzzRMXpwH7fKQ== X-Received: by 2002:a02:9936:: with SMTP id r51-v6mr25471054jaj.46.1531332447138; Wed, 11 Jul 2018 11:07:27 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id f8-v6sm11528265ioe.46.2018.07.11.11.07.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 11:07:26 -0700 (PDT) To: S Moonesamy , rfcplusplus@ietf.org References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> Date: Wed, 11 Jul 2018 12:07:25 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rkxNLfwvgZaMh4ZZKBTOPLQvHcxagqyJd" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:07:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rkxNLfwvgZaMh4ZZKBTOPLQvHcxagqyJd Content-Type: multipart/mixed; boundary="m95BGy3xmi69QF06KFaw43zlQojCuW0Bn"; protected-headers="v1" From: Peter Saint-Andre To: S Moonesamy , rfcplusplus@ietf.org Message-ID: <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> Subject: Re: [Rfcplusplus] Conversation as metaphor References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> In-Reply-To: <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> --m95BGy3xmi69QF06KFaw43zlQojCuW0Bn Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi SM! On 7/11/18 11:38 AM, S Moonesamy wrote: > Hi Peter, > At 09:24 AM 11-07-2018, Peter Saint-Andre wrote: >> We as a community seem to be confused about what level of "peer review= " >> we think is important, appropriate, necessary, or sufficient. We're >> engineers, not academics, so comparing our publications to academic >> journals might not be relevant. >=20 > Do IETF participants need a license [1] in the practice of engineering?= =20 s/engineers/technologists/ ;-) > There are academics who have authored RFCs in some of the Streams. Indeed. We could ask them what their goals were in doing so and what the results of RFC publication were for them. > There is an IAB RFC about citability of for scholarly publications.=C2=A0= Why > would academic journals not be relevant? Publishing an RFC is different from publishing a paper in an academic journal, so applying the same criteria might not be appropriate. As far as I can see we're not actively catering to an academic audience (either as authors or readers). > There has to be some level of review or else there wouldn't be any > quality control.=C2=A0 I agree that there is some confusion on the leve= l of > review which is required.=20 And different levels or kinds of review across the different streams. This returns to the question of audiences for the streams. Vendors and operators seem to differ quite a bit from researchers and academics (naturally there is always overlap). Peter --m95BGy3xmi69QF06KFaw43zlQojCuW0Bn-- --rkxNLfwvgZaMh4ZZKBTOPLQvHcxagqyJd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltGR10ACgkQZWGMGH9o FKnkehAA5cv6QvPyvyaHx4MPzwg7Fs6o5b87lEjI9kYp5uSWuTZHgdyYKHYh1wFm NhbFwCa2jr2cX4insuob/353FlqNfzabE294MZD9N9wTCwTTpUB8jFI2gcQYn2IT Rh0SfmyHDUhOF1nZGX3okbYzxVG/JC7CNKBU2gviokJHhbqvJh2JfdPkCZ0wh30n zj/VK+6ccNhFGqqc6bdOGKYR8V6X+U9M2mfZgEvZDMfHEkTIk+cwKY8gQyJ+MUJb v3l9CRvBu7SJgalxpgnfI2AZYCbHowMNwcpXfoHp/l+MC/4WlHGLj6Hb6cn9dDIn HBQL2wI7T68R7shoOGO9RFVAhiOnq9GLffRpkdzatRFV+Ml5GtIPRztOSGpJY/VE IDZ0wOI4XfwkQsi0za6dcSzm9i/hBa0+cwOAa0O4pEG2Kd9+zcPmA7YjIfPkEeQa TsCprMf8+14S6Ev077ZWN0aMdZX0HNK+3mdwLkDIjOvyaAE4GhXMZIIJEeoHM85c Lor9DDLwb5PUUf8/edGl5Jzam3S1L+edkZd1NDgCOe/fu3ZLss/7+hEx5SU4Yp8j ClMJQaz/QI1zNQ3mRXQCx6yd4HUCWSakl2F73m9A/CfTbfa2pCkstqkDd0qjWqjR gUKahxgxEW6G9BTmltWO2MmKmMaCUcaF6tRB8ntApU9QhVSCyQk= =5fgc -----END PGP SIGNATURE----- --rkxNLfwvgZaMh4ZZKBTOPLQvHcxagqyJd-- From nobody Wed Jul 11 11:09:17 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61020130E8A for ; Wed, 11 Jul 2018 11:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bs4Xa3nbCCHF for ; Wed, 11 Jul 2018 11:09:14 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D151C130DF2 for ; Wed, 11 Jul 2018 11:09:14 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id y8-v6so18914521pfm.10 for ; Wed, 11 Jul 2018 11:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wM9+hDoPYwJXeSwUtM7+6+ryXqAm7nUOMqyJxUn6NCU=; b=RE5KQKK35e4x4Uis9wYHC7svD+CY1G/xmLJZ/a2TfxFKKr98wd5AVImygC9Yp1y0sG TCbkvrYGVPJ5stA7ATwCl9Ewt5CudWA+zIWmQtiYH6mIB7lr8T3eCqDYHIsYhlEac7E3 kuH9Qq5SnayO5WRLc0un4lB2ApQD+Zf7GFnlbUP8zdj/zjrDRnVKFAFcebqMeObInMWI fRJTYzIr43JGtXhohn9pzEVJq9ERDQTR7MeXQnwSjC9mQOxcssAx+KBPN5i0Zz1y97wG Sx5mwk2KeKNTkDcUmb7khrGX67FMoTA5MtTrAXQ4/AJNA1sxJP2U7Enz4u9TBE8izmyy Y99w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wM9+hDoPYwJXeSwUtM7+6+ryXqAm7nUOMqyJxUn6NCU=; b=kk35SbySm7waDC60DWi7gE876ykJ6GLVqfVs1vVRDXrvQOmBxLy2BTNPLanfw0/cvc f2JPLo4vdJww/X9OQm/D85asIvvjMlMBQUVCunoA1E/GG2Y/+6uZJvAHP2yiFOSofWXY 9oe3JxLYeaMMPwpjt9bXwM2Gmz7oj+AbKPHLIs0CFf6rGrITFpTmVAwd++4uOwNKRnz7 MhY72td6mrpBcosbB5dW14IrX5tZARpbDW95Ith3JhRQ2aBqij9DNLBGMfwOUesFAuZp si/VeYXPATzpK2rML2jmgnOcvg9WOirNGicRYSw82vcwZIFvyLnwYB7bJQ7D9kJfnbf9 Xr+g== X-Gm-Message-State: APt69E0pv09FNl1cyO4+WEuJ1SJOQhQyRxa6pB84d2+DZ36kzFv93HfO b5Uzh0/vbZ3oZuYSG1T3/uwTT39nFDkHfqXLKsM= X-Google-Smtp-Source: AAOMgpe7/9ghAdEikVTHbeSRt3a9MEe5sWBg3ZzMLc/4bB/VygtEDyaS12w3XFxczzABZw67Voo2u+GCJQtEKXjRLS0= X-Received: by 2002:a62:5984:: with SMTP id k4-v6mr30832004pfj.116.1531332554415; Wed, 11 Jul 2018 11:09:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:ac18:0:0:0:0 with HTTP; Wed, 11 Jul 2018 11:09:13 -0700 (PDT) In-Reply-To: <844ec8ff-26b9-4314-d71c-b75a00f3610f@cisco.com> References: <844ec8ff-26b9-4314-d71c-b75a00f3610f@cisco.com> From: Allison Mankin Date: Wed, 11 Jul 2018 14:09:13 -0400 Message-ID: To: Eliot Lear Cc: "Rfcplusplus@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f061690570bd247e" Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:09:17 -0000 --000000000000f061690570bd247e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eliot, I see HRPC as a New Thing (though it need not be so forever). It mingles social/political science research with protocol research. There=E2=80=99s another angle on how we handled the HRPC research considera= tions document, as well, which is that IRTF can have more varied consenses. RG/IRSG consensus can be different in scope from the IETF-wide scope of IETF LC/IESG Evaluation. On Wednesday, 11 July 2018, Eliot Lear wrote: > Hi Allison and thanks. I'd like to test you on one point: > > On 11.07.18 19:26, Allison Mankin wrote: > > We in IRTF do have some work close to production, for example, CFRG crypt= o > recommendations. I would want to talk with IESG about appropriate AD > sponsorship when that would be the best context for a draft. > > Other work we would like to place into an IRTF stream with a new brand. I > expect us to start developing an open, academically reviewed > proceedings/journal soon, to best serve our researcher contributions. It > will focus on applied research and running code, similar to ANRW. > > > What would have been your preferred handling of the human rights > considerations work? Is that closer to a CFRG recommendation or a new > Thing? Please keep in mind that many of us were comfortable with that > document going out through the IRTF as it was, precisely because it WASN'= T > an IETF document. > > Eliot > --000000000000f061690570bd247e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eliot, I see HRPC as a New Thing (though it need not be so forever). It = mingles social/political science research with protocol research.=C2=A0
There=E2=80=99s another angle on how we handled the HRPC re= search considerations document, as well, which is that IRTF can have more v= aried consenses. RG/IRSG consensus can be different in scope from the IETF-= wide scope of IETF LC/IESG Evaluation.

On Wednesday, 11 July = 2018, Eliot Lear <lear@cisco.com&g= t; wrote:
=20 =20 =20

Hi Allison and thanks.=C2=A0 I'd like to test you on one point:<= br>


On 11.07.18 19:26, Allison Mankin wrote:
=20
We in IRT= F do have some work close to production, for example, CFRG crypto recommendations. I would want to talk with IESG about appropriate AD sponsorship when that would be the best context for a draft.=C2=A0

Other wor= k we would like to place into an IRTF stream with a new brand. I expect us to start developing an open, academically reviewed proceedings/journal soon, to best serve our researcher contributions. It will focus on applied research and running code, similar to ANRW.=C2=A0


What would have been your preferred handling of the human rights considerations work?=C2=A0 Is that closer to a CFRG recommendation or a new Thing?=C2=A0 Please keep in mind that many of us were comfortable with that document going out through the IRTF as it was, precisely because it WASN'T an IETF document.

Eliot
--000000000000f061690570bd247e-- From nobody Wed Jul 11 11:23:29 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5D9130E8A for ; Wed, 11 Jul 2018 11:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 m4RUo76rdEHB for ; Wed, 11 Jul 2018 11:23:23 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8A6130E69 for ; Wed, 11 Jul 2018 11:23:23 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id z8-v6so13392669qto.9 for ; Wed, 11 Jul 2018 11:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:embedded-html; bh=804pjxU8rBKdJATDTcMIxFSFEr7ZPN3W0MRExbB7gXM=; b=jnB9NHxhHLwz2vSV7zl/2ZaOKvMvyx1q+teqArLY/+UBVqVh+7efqueNJMuNQ1Tsy/ FACvOli1pA/O50hstpSS1yRtuMnhD3OFJQ3tsymUyF/+1+o9EKTn6/KhvkFKZKip1/sj KGqIsdAM60VAiUXIph8bYS0O5VfE+yPi+vcY6VmDIBzVf19dwgI/oZv7Gwe9PmzU3Bv4 C6sastfqP4/jW3VSIQBvdOAex3lA4lkZTXlFv/xwDmEQZCPrE2l0rcWpln0hBRSqBVJf XnQozm1O1KRnxcX8h/4UDVUTFSCroLLe4HzmA+grCBvnegNrSbpCFI3LR5JuphGhRvYm IFdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:embedded-html; bh=804pjxU8rBKdJATDTcMIxFSFEr7ZPN3W0MRExbB7gXM=; b=N/34omqbWCO76hoUGahTsCJ/dvTNOw/OHRRtLfOfoUh/lzZfq9RbnUgwq8yUFsRbfM Xcvr/BgRNGL2OXPxvzaecqsXgZerAsOuUAkzQrpp+aPwKdVjM07zl4bDcf9bShsmcph7 uEZe4eSSfoU0Sucu/4CKbNxqAuHO8hPZeY4fvQkMJs9MpI62keH34I0YR5rizEWNv1BZ qcEUOU2GblTeFUZhJSCzgN/oQLJvbXD1Z0UwNlwjHroiCTUWsJYy0YQCJ41WD/OJfLa1 FnsWuBdzk45P9+80KKdK9fipweeC9e28GcUgcdMUJaXqIBaN65/9Ri4O9k2jLLtOQjP5 lHFA== X-Gm-Message-State: AOUpUlHVLp2rZezVVOTNEOwMWpB8FNHjHJ2dSuOjDDgs89aGRtBF4pyU qXQv2nJCE4XJpdfNEIjh8xg= X-Google-Smtp-Source: AAOMgpeajhRQqX6Vt5v+3sA54vFnsLQe/esR6cpqPxfHO4BhtQfFma3Ml5EMDHPhHvV2XK0vyJtyRg== X-Received: by 2002:a0c:ae17:: with SMTP id y23-v6mr441786qvc.157.1531333402398; Wed, 11 Jul 2018 11:23:22 -0700 (PDT) Received: from [172.19.33.154] ([2001:4878:a000:3000:c4e6:6bd4:d487:2f5e]) by smtp.gmail.com with ESMTPSA id f17-v6sm12284587qtp.1.2018.07.11.11.23.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 11:23:21 -0700 (PDT) From: "Aaron Falk" To: "Allison Mankin" Cc: Rfcplusplus@ietf.org Date: Wed, 11 Jul 2018 14:23:19 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4C48F6BB-FD13-4695-9163-D90A10630670_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[777, 3842], "plain":[381, 1973], "uuid":"707A1A90-A169-474A-8168-B46B7F86D1FD"}] Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:23:27 -0000 --=_MailMate_4C48F6BB-FD13-4695-9163-D90A10630670_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Allison- Can you clarify whether you are proposing to end the IRTF RFC stream when this new series is created or supplementing it with another, more academically oriented stream? If the former, do you believe all IRTF documents can be published either as IETF RFCs or the new type? (I would find that surprising.) --aaron On 11 Jul 2018, at 13:26, Allison Mankin wrote: > (IRTF Chair hat on) > One of my goals as IRTF Chair is precisely to create a new, non-RFC > stream > for the IRTF. So, IRTF is very much an interested party in this BOF. > > The most common response I get during outreach into academia is that > RFCs > aren’t a good medium for most academics. This is despite > researchers’ wish > eventually to have ideas deployed. We’ve been exploring what work > product > will best serve the research community, and . this does include > distinguishing the work from the RFCs. I like Brian Trammell’s > discussion > in the “conversation†thread very much, btw; he has expressed how > academics > and pseudo-academics contribute very well. > > I notice there has been little call for data about IRTF and RFCs. I > think > it’s because RFC does mostly signify a production brand. I’d > encourage the > other streams to examine what makes them production-ready. > > We in IRTF do have some work close to production, for example, CFRG > crypto > recommendations. I would want to talk with IESG about appropriate AD > sponsorship when that would be the best context for a draft. > > Other work we would like to place into an IRTF stream with a new > brand. I > expect us to start developing an open, academically reviewed > proceedings/journal soon, to best serve our researcher contributions. > It > will focus on applied research and running code, similar to ANRW. > > In summary, IRTF is ready to start our part of an rfcplusplus > experiment. > We are a part of the IETF community and indeed a part of this BOF > (this > responds to Brian Carpenter’s comment quoted below). > > Allison > > ——————- > > Brian Carpenter wrote: > > Ted, > > It would be on topic if there was a proposal inside the IRTF to change > the > publication venue for IRTF output. But this is an IETF BOF so all we > can do > is discuss how IETF stream documents are published. > > I know this is an inconvenient truth for some people, but there it is. > > Brian > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --=_MailMate_4C48F6BB-FD13-4695-9163-D90A10630670_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Hi Allison-

Can you clarify whether you are proposing to end the IRTF= RFC stream when this new series is created or supplementing it with anot= her, more academically oriented stream? If the former, do you believe al= l IRTF documents can be published either as IETF RFCs or the new type? (= I would find that surprising.)

--aaron

On 11 Jul 2018, at 13:26, Allison Mankin wrote:

(IRTF Chair hat= on)
One of my goals as IRTF Chair is precisely to create a new, no= n-RFC stream for the IRTF. So, IRTF is very much an interested party in t= his BOF.=C2=A0

The most common response I get during out= reach into academia is that RFCs aren=E2=80=99t a good medium for most ac= ademics. This is despite researchers=E2=80=99 wish eventually to have ide= as deployed. We=E2=80=99ve been exploring what work product will best ser= ve the research community, and . this does include distinguishing the wor= k from the RFCs. I like Brian Trammell=E2=80=99s discussion in the =E2=80= =9Cconversation=E2=80=9D thread very much, btw; he has expressed how acad= emics and pseudo-academics contribute very well.
=
=
I notic= e there has been little call for data about IRTF and RFCs. I think it=E2=80= =99s because RFC does mostly signify a production brand. I=E2=80=99d enco= urage the other streams to examine what makes them production-ready.

We in IRTF do have some work close to production, for exampl= e, CFRG crypto recommendations. I would want to talk with IESG about appr= opriate AD sponsorship when that would be the best context for a draft.=C2= =A0

Other work we would like to place into an IRTF strea= m with a new brand. I expect us to start developing an open, academically= reviewed proceedings/journal soon, to best serve our researcher contribu= tions. It will focus on applied research and running code, similar to ANR= W.=C2=A0

In summary, IRTF is ready to start our part of = an rfcplusplus experiment. We are a part of the IETF community and indeed= a part of this BOF (this responds to Brian Carpenter=E2=80=99s comment q= uoted below).

= Allison=C2=A0

=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94-

<= /div>
Brian Carpen= ter wrote:

Ted,

It would be on topic if ther= e was a proposal inside the IRTF to change=C2=A0the publication venue for IRTF output. B= ut this is an IETF BOF so all=C2=A0we can do is discuss how IETF stream documents are pu= blished.

I know this is an inconvenient truth for some people, b= ut there it is.
=C2=A0=C2=A0=C2=A0Brian

______________________= _________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusplus

--=_MailMate_4C48F6BB-FD13-4695-9163-D90A10630670_=-- From nobody Wed Jul 11 11:25:34 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215B2130E91 for ; Wed, 11 Jul 2018 11:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 dHsqXYhJguXJ for ; Wed, 11 Jul 2018 11:25:30 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95CE130E69 for ; Wed, 11 Jul 2018 11:25:29 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id a5-v6so7377560qtp.2 for ; Wed, 11 Jul 2018 11:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:embedded-html; bh=d4gB1srrcBDUCi2/ZHJoSZoyLPIWtvzPGABqLS417aU=; b=mTsF0v9y2uFxoDsi2LbfJ7BcsIudxcCxKhrv5yeUrYVg7nAZ2nprjGa5t1bdo5MWlk 17I+R2dwF+VhoTr14s/9zaAlavtQMlnyfxvo14aJxyuDT1IiBUTe5p0R6aClXd6sDSOQ N5TOLlmREbua+lyygVJb4q9kMdnbAMh3+439krDnKMgUsa9R8yhbI3KXfeY/g8YXX3Dy yYCCNY16mzrp6BcIwjtaMmIxxoYwrMzJ4zPNcOtWHTbSViUOV4XpTOoKsTTGjVt2sp6U Wy1nJeTiUFWrdspHMvAl3MDSml8/ayuZ4ihFwF0nsFk5K7rnbcbbKJewN0Hl7uVGiW3A LKcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:embedded-html; bh=d4gB1srrcBDUCi2/ZHJoSZoyLPIWtvzPGABqLS417aU=; b=GHwy7L0SkXHG4p0+oIpM6ytdQrlMTIA92jxhJvcv7LtoLjxt43fmqwpSK1UCWveY6z cB09hrVoY/gDwTyqZMOPLW3sxJJdLJ6bu7DdwsTkUsZtl7W/O5Y2NQmxQbM8SLxI5I12 HnzUbXz8/SW27ZXM+GsPiv/9Ah0HsLYo3M85ufbl4fp9jm6yY+GaB3o3jOz120iPICH+ b2iCAHnlw7BdQKt+AWGiZPOHQvM4vZHpYrQ3zbQppNnSDnvQIeDA2uOUbhAFLhoDxGTX i16Kpz+J4h5C9PoLlIM/SMxZrwpBiIdql2UZxSsLWoy5M2nkFMwTB5IJNfWln5PvCd5g KZYw== X-Gm-Message-State: APt69E26bXcp5PaFJetQAw+3qi6eUJLpL3qJdFl83kyIJPKtvbmpMRzj l7/iqQeh9XfqHG9BlUzhv6c= X-Google-Smtp-Source: AAOMgpd0k2dSBZT4BveF9o8NARcbxNbAW0TM2XBM/eqwA85I+PI7Q51bo4wzfRz+zJ3Co2639W3B9A== X-Received: by 2002:ac8:1c28:: with SMTP id a37-v6mr28539169qtk.298.1531333528792; Wed, 11 Jul 2018 11:25:28 -0700 (PDT) Received: from [172.19.33.154] ([2001:4878:a000:3000:c4e6:6bd4:d487:2f5e]) by smtp.gmail.com with ESMTPSA id l7-v6sm15938084qtc.27.2018.07.11.11.25.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 11:25:27 -0700 (PDT) From: "Aaron Falk" To: "Allison Mankin" Cc: Rfcplusplus@ietf.org Date: Wed, 11 Jul 2018 14:25:26 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_8EA2C93E-B44E-49BD-A33C-89EFE652ED65_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[589, 5041], "plain":[210, 2568], "uuid":"4110A28D-78B5-4ECD-A904-F0B7A7C5D2CC"}] Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:25:32 -0000 --=_MailMate_8EA2C93E-B44E-49BD-A33C-89EFE652ED65_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sorry, I forgot to mention that I think a "open, academically reviewed proceedings/journal" is a great thing and will be good for the IRTF and the IETF. --aaron On 11 Jul 2018, at 14:23, Aaron Falk wrote: > Hi Allison- > > Can you clarify whether you are proposing to end the IRTF RFC stream > when this new series is created or supplementing it with another, more > academically oriented stream? If the former, do you believe all IRTF > documents can be published either as IETF RFCs or the new type? (I > would find that surprising.) > > --aaron > > On 11 Jul 2018, at 13:26, Allison Mankin wrote: > >> (IRTF Chair hat on) >> One of my goals as IRTF Chair is precisely to create a new, non-RFC >> stream >> for the IRTF. So, IRTF is very much an interested party in this BOF. >> >> The most common response I get during outreach into academia is that >> RFCs >> aren’t a good medium for most academics. This is despite >> researchers’ wish >> eventually to have ideas deployed. We’ve been exploring what work >> product >> will best serve the research community, and . this does include >> distinguishing the work from the RFCs. I like Brian Trammell’s >> discussion >> in the “conversation†thread very much, btw; he has expressed how >> academics >> and pseudo-academics contribute very well. >> >> I notice there has been little call for data about IRTF and RFCs. I >> think >> it’s because RFC does mostly signify a production brand. I’d >> encourage the >> other streams to examine what makes them production-ready. >> >> We in IRTF do have some work close to production, for example, CFRG >> crypto >> recommendations. I would want to talk with IESG about appropriate AD >> sponsorship when that would be the best context for a draft. >> >> Other work we would like to place into an IRTF stream with a new >> brand. I >> expect us to start developing an open, academically reviewed >> proceedings/journal soon, to best serve our researcher contributions. >> It >> will focus on applied research and running code, similar to ANRW. >> >> In summary, IRTF is ready to start our part of an rfcplusplus >> experiment. >> We are a part of the IETF community and indeed a part of this BOF >> (this >> responds to Brian Carpenter’s comment quoted below). >> >> Allison >> >> ——————- >> >> Brian Carpenter wrote: >> >> Ted, >> >> It would be on topic if there was a proposal inside the IRTF to >> change the >> publication venue for IRTF output. But this is an IETF BOF so all we >> can do >> is discuss how IETF stream documents are published. >> >> I know this is an inconvenient truth for some people, but there it >> is. >> >> Brian > > >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus --=_MailMate_8EA2C93E-B44E-49BD-A33C-89EFE652ED65_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Sorry, I forgot to mention that I think a "open, academica= lly reviewed proceedings/journal" is a great thing and will be good for t= he IRTF and the IETF.

--aaron

On 11 Jul 2018, at 14:23, Aaron Falk wrote:

<= p dir=3D"auto">Hi Allison-

Can you clarify whether you are proposing to end the IRTF= RFC stream when this new series is created or supplementing it with anot= her, more academically oriented stream? If the former, do you believe al= l IRTF documents can be published either as IETF RFCs or the new type? (= I would find that surprising.)

--aaron

On 11 Jul 2018, at 13:26, Allison Mankin wrote:

(IRTF Chair hat= on)
One of my goals as IRTF Chair is precisely to create a new, no= n-RFC stream for the IRTF. So, IRTF is very much an interested party in t= his BOF.=C2=A0

The most common response I get during out= reach into academia is that RFCs aren=E2=80=99t a good medium for most ac= ademics. This is despite researchers=E2=80=99 wish eventually to have ide= as deployed. We=E2=80=99ve been exploring what work product will best ser= ve the research community, and . this does include distinguishing the wor= k from the RFCs. I like Brian Trammell=E2=80=99s discussion in the =E2=80= =9Cconversation=E2=80=9D thread very much, btw; he has expressed how acad= emics and pseudo-academics contribute very well.
=
=
I notic= e there has been little call for data about IRTF and RFCs. I think it=E2=80= =99s because RFC does mostly signify a production brand. I=E2=80=99d enco= urage the other streams to examine what makes them production-ready.

We in IRTF do have some work close to production, for exampl= e, CFRG crypto recommendations. I would want to talk with IESG about appr= opriate AD sponsorship when that would be the best context for a draft.=C2= =A0

Other work we would like to place into an IRTF strea= m with a new brand. I expect us to start developing an open, academically= reviewed proceedings/journal soon, to best serve our researcher contribu= tions. It will focus on applied research and running code, similar to ANR= W.=C2=A0

In summary, IRTF is ready to start our part of = an rfcplusplus experiment. We are a part of the IETF community and indeed= a part of this BOF (this responds to Brian Carpenter=E2=80=99s comment q= uoted below).

= Allison=C2=A0

=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94-

<= /div>
Brian Carpen= ter wrote:

Ted,

It would be on topic if ther= e was a proposal inside the IRTF to change=C2=A0the publication venue for IRTF output. B= ut this is an IETF BOF so all=C2=A0we can do is discuss how IETF stream documents are pu= blished.

I know this is an inconvenient truth for some people, b= ut there it is.
=C2=A0=C2=A0=C2=A0Brian

______________________= _________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusplus

--=_MailMate_8EA2C93E-B44E-49BD-A33C-89EFE652ED65_=-- From nobody Wed Jul 11 11:25:50 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A8D130EB5 for ; Wed, 11 Jul 2018 11:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonicacorp.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 WfsBGov7sL_A for ; Wed, 11 Jul 2018 11:25:39 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10113.outbound.protection.outlook.com [40.107.1.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D48F130E69 for ; Wed, 11 Jul 2018 11:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonicacorp.onmicrosoft.com; s=selector1-telefonica-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PV1Gh4J375IEoGJE0UkVUAtnmbHT457sK8RRoJeXQy4=; b=z3nq0NxMykSZnq0W7DyDgkSNiWaPaGtssc6wZJBpBF34ab/D/x7fIC7YhhXGvBeVmFq0pks+kvRCte68/KtJPE61tSxc1mwlhhDfd0ZbJtAo9kkfti9f1DgPHOMOY9vTWYq3vdEH+5Tq1z4nsUo14D/GanP48oVnWHwZGVcjgg0= Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com (52.134.70.148) by DB3PR0602MB3724.eurprd06.prod.outlook.com (52.134.73.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.19; Wed, 11 Jul 2018 18:25:35 +0000 Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::e8a7:c15c:d575:4c71]) by DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::e8a7:c15c:d575:4c71%4]) with mapi id 15.20.0930.016; Wed, 11 Jul 2018 18:25:35 +0000 From: "Diego R. Lopez" To: Aaron Falk , Allison Mankin CC: "Rfcplusplus@ietf.org" Thread-Topic: [Rfcplusplus] IRTF stream considerations Thread-Index: AQHUGTxLx6gd/Dkh0kSKiNWESO+u8qSKVgOAgAAy6oA= Date: Wed, 11 Jul 2018 18:25:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180701 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [87.235.190.32] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0602MB3724; 7:t+zuvAI4M4HpYa+g5RNH1V5Cy9xoQ6YvU93f8AgxmvQZ2FAUZTiFoUwAOkTISzIO0zmt/+iJ4q/jmL+G/3MIy2OEMQ9IShNIMEy6qjOlyd8qgUh+IG5FVim2NvpadOqIjA2WWaFC1phS+BSCnd+1RiA6uuvEETmh2/GTdiw0WbUe4qv49sUadYBoXl87ztjIrXOABR+/F+xcUOvDLcKPfFryxigGMbBS7JKrwrolGxOS7kOK2ZpeTgBe72sV6Hfu x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 92bb7df3-f3d7-4e02-f6b0-08d5e75bb1b8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(40392960112811); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DB3PR0602MB3724; x-ms-traffictypediagnostic: DB3PR0602MB3724: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(40392960112811)(223705240517415)(85827821059158)(128460861657000)(21748063052155)(81160342030619)(17755550239193); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231311)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DB3PR0602MB3724; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0602MB3724; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(39860400002)(376002)(366004)(346002)(252514010)(40134004)(25724002)(189003)(199004)(53754006)(2900100001)(229853002)(7736002)(2906002)(53936002)(8936002)(99286004)(786003)(966005)(58126008)(316002)(33656002)(561944003)(478600001)(66066001)(4326008)(3846002)(36756003)(110136005)(39060400002)(14454004)(25786009)(68736007)(6246003)(606006)(486006)(83716003)(6306002)(54896002)(6512007)(26005)(106356001)(236005)(82746002)(6486002)(6116002)(105586002)(186003)(6436002)(446003)(97736004)(6506007)(8676002)(5250100002)(76176011)(45080400002)(11346002)(102836004)(2616005)(81156014)(53546011)(86362001)(81166006)(256004)(14444005)(5660300001)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR0602MB3724; H:DB3PR0602MB3788.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 22S+4mXREyBXkKckGhXkl1KupJeDJP509EjK7pmpBZFYxKnK2dXiekaRxCxDn3bsuDvftfrcQq23U44Aj1BlwdzEH+6yQD94G9XNmZFXpfe0spg3qey0bZE3NxwGOwYO2fobyzgcrhPFNjapk986rnZFx5CyKzFEq711rz9tjmCW5Qvh/ZqD/qSDy6cdIMfN7ptzcWXD69IZH1eV09pgHVrdT/Ds/8qpp20+8T+Zn3ycdK3PNr9ZvblplEPvnMU92Wx2oGRAGRlV8zdaQ5rXB4Fv2ETFbNae3cacLH47UrcUdyVdEyZhWE55+VGEirWgBjbVvLeawl1E5sxVficHwdiiAU6e0UFjxQP6hmbQVRE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D0D37CB1F06D4DE5A0B4D9374E8BEDC5telefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 92bb7df3-f3d7-4e02-f6b0-08d5e75bb1b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2018 18:25:35.1041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0602MB3724 Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:25:46 -0000 --_000_D0D37CB1F06D4DE5A0B4D9374E8BEDC5telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFuZCwgYXMgc2hlcGhlcmQgb2YgYW4gSVJURiBkb2N1bWVudCBhd2FpdGluZyBJRUcg cmV2aWV3LCB3aGF0IHdvdWxkIGJlIHRoZSBmYXRlIG9mIHRob3NlIGluIHRoZSBxdWV1ZT8NCg0K QmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5v Ig0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHBzOi8vd3d3Lmxpbmtl ZGluLmNvbS9pbi9kcjJsb3Blei8NCg0KZS1tYWlsOiBkaWVnby5yLmxvcGV6QHRlbGVmb25pY2Eu Y29tPG1haWx0bzpkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tPg0KVGVsOiAgICAgICAgICsz NCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiAgKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCk9uIDExLzA3LzIwMTgsIDIwOjIzLCAiUmZjcGx1c3BsdXMg b24gYmVoYWxmIG9mIEFhcm9uIEZhbGsiIDxyZmNwbHVzcGx1cy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpyZmNwbHVzcGx1cy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgYWFyb24uZmFs a0BnbWFpbC5jb208bWFpbHRvOmFhcm9uLmZhbGtAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KSGkg QWxsaXNvbi0NCg0KQ2FuIHlvdSBjbGFyaWZ5IHdoZXRoZXIgeW91IGFyZSBwcm9wb3NpbmcgdG8g ZW5kIHRoZSBJUlRGIFJGQyBzdHJlYW0gd2hlbiB0aGlzIG5ldyBzZXJpZXMgaXMgY3JlYXRlZCBv ciBzdXBwbGVtZW50aW5nIGl0IHdpdGggYW5vdGhlciwgbW9yZSBhY2FkZW1pY2FsbHkgb3JpZW50 ZWQgc3RyZWFtPyBJZiB0aGUgZm9ybWVyLCBkbyB5b3UgYmVsaWV2ZSBhbGwgSVJURiBkb2N1bWVu dHMgY2FuIGJlIHB1Ymxpc2hlZCBlaXRoZXIgYXMgSUVURiBSRkNzIG9yIHRoZSBuZXcgdHlwZT8g KEkgd291bGQgZmluZCB0aGF0IHN1cnByaXNpbmcuKQ0KDQotLWFhcm9uDQoNCk9uIDExIEp1bCAy MDE4LCBhdCAxMzoyNiwgQWxsaXNvbiBNYW5raW4gd3JvdGU6DQooSVJURiBDaGFpciBoYXQgb24p DQpPbmUgb2YgbXkgZ29hbHMgYXMgSVJURiBDaGFpciBpcyBwcmVjaXNlbHkgdG8gY3JlYXRlIGEg bmV3LCBub24tUkZDIHN0cmVhbSBmb3IgdGhlIElSVEYuIFNvLCBJUlRGIGlzIHZlcnkgbXVjaCBh biBpbnRlcmVzdGVkIHBhcnR5IGluIHRoaXMgQk9GLg0KDQpUaGUgbW9zdCBjb21tb24gcmVzcG9u c2UgSSBnZXQgZHVyaW5nIG91dHJlYWNoIGludG8gYWNhZGVtaWEgaXMgdGhhdCBSRkNzIGFyZW7i gJl0IGEgZ29vZCBtZWRpdW0gZm9yIG1vc3QgYWNhZGVtaWNzLiBUaGlzIGlzIGRlc3BpdGUgcmVz ZWFyY2hlcnPigJkgd2lzaCBldmVudHVhbGx5IHRvIGhhdmUgaWRlYXMgZGVwbG95ZWQuIFdl4oCZ dmUgYmVlbiBleHBsb3Jpbmcgd2hhdCB3b3JrIHByb2R1Y3Qgd2lsbCBiZXN0IHNlcnZlIHRoZSBy ZXNlYXJjaCBjb21tdW5pdHksIGFuZCAuIHRoaXMgZG9lcyBpbmNsdWRlIGRpc3Rpbmd1aXNoaW5n IHRoZSB3b3JrIGZyb20gdGhlIFJGQ3MuIEkgbGlrZSBCcmlhbiBUcmFtbWVsbOKAmXMgZGlzY3Vz c2lvbiBpbiB0aGUg4oCcY29udmVyc2F0aW9u4oCdIHRocmVhZCB2ZXJ5IG11Y2gsIGJ0dzsgaGUg aGFzIGV4cHJlc3NlZCBob3cgYWNhZGVtaWNzIGFuZCBwc2V1ZG8tYWNhZGVtaWNzIGNvbnRyaWJ1 dGUgdmVyeSB3ZWxsLg0KDQpJIG5vdGljZSB0aGVyZSBoYXMgYmVlbiBsaXR0bGUgY2FsbCBmb3Ig ZGF0YSBhYm91dCBJUlRGIGFuZCBSRkNzLiBJIHRoaW5rIGl04oCZcyBiZWNhdXNlIFJGQyBkb2Vz IG1vc3RseSBzaWduaWZ5IGEgcHJvZHVjdGlvbiBicmFuZC4gSeKAmWQgZW5jb3VyYWdlIHRoZSBv dGhlciBzdHJlYW1zIHRvIGV4YW1pbmUgd2hhdCBtYWtlcyB0aGVtIHByb2R1Y3Rpb24tcmVhZHku DQoNCldlIGluIElSVEYgZG8gaGF2ZSBzb21lIHdvcmsgY2xvc2UgdG8gcHJvZHVjdGlvbiwgZm9y IGV4YW1wbGUsIENGUkcgY3J5cHRvIHJlY29tbWVuZGF0aW9ucy4gSSB3b3VsZCB3YW50IHRvIHRh bGsgd2l0aCBJRVNHIGFib3V0IGFwcHJvcHJpYXRlIEFEIHNwb25zb3JzaGlwIHdoZW4gdGhhdCB3 b3VsZCBiZSB0aGUgYmVzdCBjb250ZXh0IGZvciBhIGRyYWZ0Lg0KDQpPdGhlciB3b3JrIHdlIHdv dWxkIGxpa2UgdG8gcGxhY2UgaW50byBhbiBJUlRGIHN0cmVhbSB3aXRoIGEgbmV3IGJyYW5kLiBJ IGV4cGVjdCB1cyB0byBzdGFydCBkZXZlbG9waW5nIGFuIG9wZW4sIGFjYWRlbWljYWxseSByZXZp ZXdlZCBwcm9jZWVkaW5ncy9qb3VybmFsIHNvb24sIHRvIGJlc3Qgc2VydmUgb3VyIHJlc2VhcmNo ZXIgY29udHJpYnV0aW9ucy4gSXQgd2lsbCBmb2N1cyBvbiBhcHBsaWVkIHJlc2VhcmNoIGFuZCBy dW5uaW5nIGNvZGUsIHNpbWlsYXIgdG8gQU5SVy4NCg0KSW4gc3VtbWFyeSwgSVJURiBpcyByZWFk eSB0byBzdGFydCBvdXIgcGFydCBvZiBhbiByZmNwbHVzcGx1cyBleHBlcmltZW50LiBXZSBhcmUg YSBwYXJ0IG9mIHRoZSBJRVRGIGNvbW11bml0eSBhbmQgaW5kZWVkIGEgcGFydCBvZiB0aGlzIEJP RiAodGhpcyByZXNwb25kcyB0byBCcmlhbiBDYXJwZW50ZXLigJlzIGNvbW1lbnQgcXVvdGVkIGJl bG93KS4NCg0KQWxsaXNvbg0KDQrigJTigJTigJTigJTigJTigJQtDQoNCkJyaWFuIENhcnBlbnRl ciB3cm90ZToNCg0KVGVkLA0KDQpJdCB3b3VsZCBiZSBvbiB0b3BpYyBpZiB0aGVyZSB3YXMgYSBw cm9wb3NhbCBpbnNpZGUgdGhlIElSVEYgdG8gY2hhbmdlIHRoZSBwdWJsaWNhdGlvbiB2ZW51ZSBm b3IgSVJURiBvdXRwdXQuIEJ1dCB0aGlzIGlzIGFuIElFVEYgQk9GIHNvIGFsbCB3ZSBjYW4gZG8g aXMgZGlzY3VzcyBob3cgSUVURiBzdHJlYW0gZG9jdW1lbnRzIGFyZSBwdWJsaXNoZWQuDQoNCkkg a25vdyB0aGlzIGlzIGFuIGluY29udmVuaWVudCB0cnV0aCBmb3Igc29tZSBwZW9wbGUsIGJ1dCB0 aGVyZSBpdCBpcy4NCg0KICAgQnJpYW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NClJmY3BsdXNwbHVzIG1haWxpbmcgbGlzdA0KUmZjcGx1c3BsdXNA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmZjcGx1c3Bs dXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHkg c3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8s IHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwg eSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGlu by4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZp Y2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNv cGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUg bGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3Ig ZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9y IGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQg Y29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMg bWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNl IGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpFc3RhIG1l bnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVz dGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25m aWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRl IGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGlj YWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1 bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlk YSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVu c2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFt ZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbw0K --_000_D0D37CB1F06D4DE5A0B4D9374E8BEDC5telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <865EAF4DE539BC4F910EF95B2869AED9@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAzLjBjbSA3MC44NXB0IDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij5BbmQsIGFzIHNoZXBoZXJkIG9mIGFuIElSVEYgZG9jdW1lbnQgYXdh aXRpbmcgSUVHIHJldmlldywgd2hhdCB3b3VsZCBiZSB0aGUgZmF0ZSBvZiB0aG9zZSBpbiB0aGUg cXVldWU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPkJlIGdvb2RlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4tLTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m cXVvdDtFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8mcXVvdDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkRyIERpZWdvIFIuIExvcGV6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPlRlbGVmb25pY2EgSSYjNDM7RDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YSBo cmVmPSJodHRwczovL3d3dy5saW5rZWRpbi5jb20vaW4vZHIybG9wZXovIj48c3BhbiBzdHlsZT0i Y29sb3I6IzA1NjNDMSI+aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL2RyMmxvcGV6Lzwvc3Bh bj48L2E+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5l LW1haWw6Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+PGEgaHJlZj0ibWFpbHRvOmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+PHNwYW4gbGFuZz0iRU4tVVMiPmRp ZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb208L3NwYW4+PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ VGVsOiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzszNCA5 MTMgMTI5IDA0MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+TW9iaWxlOiAmbmJzcDsm IzQzOzM0IDY4MiAwNTEgMDkxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMTEvMDcvMjAxOCwgMjA6 MjMsICZxdW90O1JmY3BsdXNwbHVzIG9uIGJlaGFsZiBvZiBBYXJvbiBGYWxrJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86cmZjcGx1c3BsdXMtYm91bmNlc0BpZXRmLm9yZyI+cmZjcGx1c3BsdXMt Ym91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86YWFyb24u ZmFsa0BnbWFpbC5jb20iPmFhcm9uLmZhbGtAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5IaSBBbGxpc29uLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5DYW4geW91IGNs YXJpZnkgd2hldGhlciB5b3UgYXJlIHByb3Bvc2luZyB0byBlbmQgdGhlIElSVEYgUkZDIHN0cmVh bSB3aGVuIHRoaXMgbmV3IHNlcmllcyBpcyBjcmVhdGVkIG9yIHN1cHBsZW1lbnRpbmcgaXQgd2l0 aCBhbm90aGVyLCBtb3JlIGFjYWRlbWljYWxseSBvcmllbnRlZCBzdHJlYW0/IElmIHRoZSBmb3Jt ZXIsDQogZG8geW91IGJlbGlldmUgYWxsIElSVEYgZG9jdW1lbnRzIGNhbiBiZSBwdWJsaXNoZWQg ZWl0aGVyIGFzIElFVEYgUkZDcyBvciB0aGUgbmV3IHR5cGU/IChJIHdvdWxkIGZpbmQgdGhhdCBz dXJwcmlzaW5nLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+LS1hYXJvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj5PbiAxMSBKdWwgMjAxOCwgYXQgMTM6MjYsIEFsbGlzb24gTWFua2luIHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICM3Nzc3NzcgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdDttYXJnaW4tbGVmdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjMuNzVw dCI+DQo8ZGl2IGlkPSI3MDdBMUE5MC1BMTY5LTQ3NEEtODE2OC1CNDZCN0Y4NkQxRkQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwN0IzNSI+KElSVEYgQ2hhaXIgaGF0IG9uKTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3 Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDdCMzUiPk9uZSBvZiBteSBnb2FscyBhcyBJUlRGIENoYWlyIGlzIHByZWNpc2VseSB0byBjcmVh dGUgYSBuZXcsIG5vbi1SRkMgc3RyZWFtIGZvciB0aGUgSVJURi4gU28sIElSVEYgaXMgdmVyeSBt dWNoIGFuIGludGVyZXN0ZWQgcGFydHkgaW4NCiB0aGlzIEJPRi4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3 Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3QjM1Ij5U aGUgbW9zdCBjb21tb24gcmVzcG9uc2UgSSBnZXQgZHVyaW5nIG91dHJlYWNoIGludG8gYWNhZGVt aWEgaXMgdGhhdCBSRkNzIGFyZW7igJl0IGEgZ29vZCBtZWRpdW0gZm9yIG1vc3QgYWNhZGVtaWNz LiBUaGlzIGlzIGRlc3BpdGUgcmVzZWFyY2hlcnPigJkNCiB3aXNoIGV2ZW50dWFsbHkgdG8gaGF2 ZSBpZGVhcyBkZXBsb3llZC4gV2XigJl2ZSBiZWVuIGV4cGxvcmluZyB3aGF0IHdvcmsgcHJvZHVj dCB3aWxsIGJlc3Qgc2VydmUgdGhlIHJlc2VhcmNoIGNvbW11bml0eSwgYW5kIC4gdGhpcyBkb2Vz IGluY2x1ZGUgZGlzdGluZ3Vpc2hpbmcgdGhlIHdvcmsgZnJvbSB0aGUgUkZDcy4gSSBsaWtlIEJy aWFuIFRyYW1tZWxs4oCZcyBkaXNjdXNzaW9uIGluIHRoZSDigJxjb252ZXJzYXRpb27igJ0gdGhy ZWFkIHZlcnkgbXVjaCwNCiBidHc7IGhlIGhhcyBleHByZXNzZWQgaG93IGFjYWRlbWljcyBhbmQg cHNldWRvLWFjYWRlbWljcyBjb250cmlidXRlIHZlcnkgd2VsbC48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3QjM1Ij5JIG5vdGlj ZSB0aGVyZSBoYXMgYmVlbiBsaXR0bGUgY2FsbCBmb3IgZGF0YSBhYm91dCBJUlRGIGFuZCBSRkNz LiBJIHRoaW5rIGl04oCZcyBiZWNhdXNlIFJGQyBkb2VzIG1vc3RseSBzaWduaWZ5IGEgcHJvZHVj dGlvbiBicmFuZC4gSeKAmWQNCiBlbmNvdXJhZ2UgdGhlIG90aGVyIHN0cmVhbXMgdG8gZXhhbWlu ZSB3aGF0IG1ha2VzIHRoZW0gcHJvZHVjdGlvbi1yZWFkeS48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3QjM1Ij5XZSBpbiBJUlRG IGRvIGhhdmUgc29tZSB3b3JrIGNsb3NlIHRvIHByb2R1Y3Rpb24sIGZvciBleGFtcGxlLCBDRlJH IGNyeXB0byByZWNvbW1lbmRhdGlvbnMuIEkgd291bGQgd2FudCB0byB0YWxrIHdpdGggSUVTRyBh Ym91dCBhcHByb3ByaWF0ZQ0KIEFEIHNwb25zb3JzaGlwIHdoZW4gdGhhdCB3b3VsZCBiZSB0aGUg YmVzdCBjb250ZXh0IGZvciBhIGRyYWZ0LiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDdCMzUiPk90aGVyIHdvcmsgd2Ug d291bGQgbGlrZSB0byBwbGFjZSBpbnRvIGFuIElSVEYgc3RyZWFtIHdpdGggYSBuZXcgYnJhbmQu IEkgZXhwZWN0IHVzIHRvIHN0YXJ0IGRldmVsb3BpbmcgYW4gb3BlbiwgYWNhZGVtaWNhbGx5IHJl dmlld2VkDQogcHJvY2VlZGluZ3Mvam91cm5hbCBzb29uLCB0byBiZXN0IHNlcnZlIG91ciByZXNl YXJjaGVyIGNvbnRyaWJ1dGlvbnMuIEl0IHdpbGwgZm9jdXMgb24gYXBwbGllZCByZXNlYXJjaCBh bmQgcnVubmluZyBjb2RlLCBzaW1pbGFyIHRvIEFOUlcuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzci PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwN0IzNSI+SW4gc3Vt bWFyeSwgSVJURiBpcyByZWFkeSB0byBzdGFydCBvdXIgcGFydCBvZiBhbiByZmNwbHVzcGx1cyBl eHBlcmltZW50LiBXZSBhcmUgYSBwYXJ0IG9mIHRoZSBJRVRGIGNvbW11bml0eSBhbmQgaW5kZWVk IGEgcGFydCBvZiB0aGlzDQogQk9GICh0aGlzIHJlc3BvbmRzIHRvIEJyaWFuIENhcnBlbnRlcuKA mXMgY29tbWVudCBxdW90ZWQgYmVsb3cpLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDdCMzUiPkFsbGlzb24mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3 QjM1Ij7igJTigJTigJTigJTigJTigJQtPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwN0IzNSI+QnJpYW4gQ2FycGVudGVyIHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwN0Iz NSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDdC MzUiPlRlZCw8YnI+DQo8YnI+DQpJdCB3b3VsZCBiZSBvbiB0b3BpYyBpZiB0aGVyZSB3YXMgYSBw cm9wb3NhbCBpbnNpZGUgdGhlIElSVEYgdG8gY2hhbmdlJm5ic3A7dGhlIHB1YmxpY2F0aW9uIHZl bnVlIGZvciBJUlRGIG91dHB1dC4gQnV0IHRoaXMgaXMgYW4gSUVURiBCT0Ygc28gYWxsJm5ic3A7 d2UgY2FuIGRvIGlzIGRpc2N1c3MgaG93IElFVEYgc3RyZWFtIGRvY3VtZW50cyBhcmUgcHVibGlz aGVkLjxicj4NCjxicj4NCkkga25vdyB0aGlzIGlzIGFuIGluY29udmVuaWVudCB0cnV0aCBmb3Ig c29tZSBwZW9wbGUsIGJ1dCB0aGVyZSBpdCBpcy48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJz cDtCcmlhbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgIzc3Nzc3NyAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21h cmdpbi1sZWZ0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxw IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUmZjcGx1c3BsdXMgbWFpbGluZyBs aXN0PGJyPg0KUmZjcGx1c3BsdXNAaWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JmY3BsdXNwbHVzIj48c3BhbiBzdHlsZT0iY29sb3I6 Izc3Nzc3NyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yZmNwbHVzcGx1 czwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJH cmF5IiBzaXplPSIxIj48YnI+DQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdl biBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3Jt YWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2 byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwg ZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYQ0KIGxlY3R1 cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOz biBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdl bnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1 ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBw cm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLjxicj4NCjxicj4NClRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFs IGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBh bnkgZGlzc2VtaW5hdGlvbiwNCiBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11 bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRl bHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVu aWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuPGJyPg0KPGJyPg0KRXN0YSBtZW5z YWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3Rp bmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlk ZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBk ZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2Fk bywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhDQogbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1 bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlk YSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVu c2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFt ZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbzxicj4N CjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D0D37CB1F06D4DE5A0B4D9374E8BEDC5telefonicacom_-- From nobody Wed Jul 11 11:26:44 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1791F130E91 for ; Wed, 11 Jul 2018 11:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 eiDEvpr74P9N for ; Wed, 11 Jul 2018 11:26:39 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273EA130E69 for ; Wed, 11 Jul 2018 11:26:39 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id l123-v6so18935946pfl.13 for ; Wed, 11 Jul 2018 11:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TmPIDgoKfzBh+RkE1YHFF39d6g95o7UpoovVK4qU8W0=; b=C50frdFL7pyPor7t2YuEm/E5fjafK4yayv7/YZ8QuzEhghmSS5JOmkbRCumxKpCRpS 1SbAVZvvv+E+21hqY+2mq158Cv6/mloc2U3YBN4zCSG8TNFAn1tr2LYcj7IIUxbs9BM5 Qjn/FVVRzNyyxT/8/5Vw8pWhsUcWQHtzBAo2YbYKKw561xy2BWaXoTW/5IZkzgmfUHAR pB4exC5UijCQ+XJgPagoG5dtV7cjlNaqjNEunkzsLnSOTI+a/xxwqEzYwRAitDGyxiyz LhQsfkPqdyVP07GwTU3Hwo9rlo+MM4s65hahvQMSWLBTEiuh1m7/k1OE7lHju5OZQuwh +Xcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TmPIDgoKfzBh+RkE1YHFF39d6g95o7UpoovVK4qU8W0=; b=NQv8j3oA2OXotqAiBn8dO2wq82v1Ljl6XrBxd4oOtgKmt6nMS7pYNlP8PgIKfV4HBp hThMi2GmCpwMm8Exhbjl/lsIYZ3A1/6W3Hi47kfUX7PJFe3nrkJP6nY+jg7TwnPw5Y+M bBb632ek1vy/IMfsBTpD3TFtgQ4mcRv+iPkQhx4jyzAOItBvQtqhkcBfC1YpPQ5YmX3T CpBMqjpGlP0qJ2lEpRSwpbACmAAp6z5N5OmU7pACAKcOXaHHMz0vVtO/l3IRwIxWERuG kLGiN67aivy+1aWydAVVMCHxMEEIAAqRtKpdOud60bn+l4LNYM+VyEyTQxG95UicOGQs KXSA== X-Gm-Message-State: APt69E1aEIZJsdyDJkoqd7cJc1My1lrhBnJGIbloX4N7qyYzq+vNObdx aQSBiHujwcE+XYhuSUkM1B9PcmpoJhGPLMQcXU3Qng== X-Google-Smtp-Source: AAOMgpcnxxi1SvfZQPHBRtk1hhPASkJAdr8m1338JlqRV2XrMUdaYEEU6+39vGdQ+tLZCcU6VGkAyXUh027Rh6WZ3Bs= X-Received: by 2002:a63:1063:: with SMTP id 35-v6mr26707624pgq.249.1531333598728; Wed, 11 Jul 2018 11:26:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:ac18:0:0:0:0 with HTTP; Wed, 11 Jul 2018 11:26:37 -0700 (PDT) In-Reply-To: References: From: Allison Mankin Date: Wed, 11 Jul 2018 14:26:37 -0400 Message-ID: To: Aaron Falk Cc: "Rfcplusplus@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002f583f0570bd63f0" Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:26:42 -0000 --0000000000002f583f0570bd63f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Aaron, What would be examples of the surprising? I don=E2=80=99t see an IRTF more academic stream as being in the strict mol= d of conferences and journals, if that is the issue. Allison On Wednesday, 11 July 2018, Aaron Falk wrote: > Hi Allison- > > Can you clarify whether you are proposing to end the IRTF RFC stream when > this new series is created or supplementing it with another, more > academically oriented stream? If the former, do you believe all IRTF > documents can be published either as IETF RFCs or the new type? (I would > find that surprising.) > > --aaron > > On 11 Jul 2018, at 13:26, Allison Mankin wrote: > > (IRTF Chair hat on) > One of my goals as IRTF Chair is precisely to create a new, non-RFC strea= m > for the IRTF. So, IRTF is very much an interested party in this BOF. > > The most common response I get during outreach into academia is that RFCs > aren=E2=80=99t a good medium for most academics. This is despite research= ers=E2=80=99 wish > eventually to have ideas deployed. We=E2=80=99ve been exploring what work= product > will best serve the research community, and . this does include > distinguishing the work from the RFCs. I like Brian Trammell=E2=80=99s di= scussion > in the =E2=80=9Cconversation=E2=80=9D thread very much, btw; he has expre= ssed how academics > and pseudo-academics contribute very well. > > I notice there has been little call for data about IRTF and RFCs. I think > it=E2=80=99s because RFC does mostly signify a production brand. I=E2=80= =99d encourage the > other streams to examine what makes them production-ready. > > We in IRTF do have some work close to production, for example, CFRG crypt= o > recommendations. I would want to talk with IESG about appropriate AD > sponsorship when that would be the best context for a draft. > > Other work we would like to place into an IRTF stream with a new brand. I > expect us to start developing an open, academically reviewed > proceedings/journal soon, to best serve our researcher contributions. It > will focus on applied research and running code, similar to ANRW. > > In summary, IRTF is ready to start our part of an rfcplusplus experiment. > We are a part of the IETF community and indeed a part of this BOF (this > responds to Brian Carpenter=E2=80=99s comment quoted below). > > Allison > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94- > > Brian Carpenter wrote: > > Ted, > > It would be on topic if there was a proposal inside the IRTF to change th= e > publication venue for IRTF output. But this is an IETF BOF so all we can > do is discuss how IETF stream documents are published. > > I know this is an inconvenient truth for some people, but there it is. > > Brian > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > > --0000000000002f583f0570bd63f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Aaron,

What would be examples of the surprising?=C2= =A0

I don=E2=80=99t see an IRTF more academic stre= am as being in the strict mold of conferences and journals, if that is the = issue.

Allison


On Wednesday, 11 = July 2018, Aaron Falk <aaron.fal= k@gmail.com> wrote:

Hi Allison-

Can you clarify whether you are proposing to end the IRTF R= FC stream when this new series is created or supplementing it with another,= more academically oriented stream? If the former, do you believe all IRTF= documents can be published either as IETF RFCs or the new type? (I would = find that surprising.)

--aaron

On 11 Jul 2018, at 13:26, Allison Mankin wrote:

(IRTF Chair hat on)
= One of my goals as IRTF Chair is precisely t= o create a new, non-RFC stream for the IRTF. So, IRTF is very much an inter= ested party in this BOF.=C2=A0

The most common response I get = during outreach into academia is that RFCs aren=E2=80=99t a good medium for= most academics. This is despite researchers=E2=80=99 wish eventually to ha= ve ideas deployed. We=E2=80=99ve been exploring what work product will best= serve the research community, and . this does include distinguishing the w= ork from the RFCs. I like Brian Trammell=E2=80=99s discussion in the =E2=80= =9Cconversation=E2=80=9D thread very much, btw; he has expressed how academ= ics and pseudo-academics contribute very well.

=
I notice there = has been little call for data about IRTF and RFCs. I think it=E2=80=99s bec= ause RFC does mostly signify a production brand. I=E2=80=99d encourage the = other streams to examine what makes them production-ready.

<= /font>
We = in IRTF do have some work close to production, for example, CFRG crypto rec= ommendations. I would want to talk with IESG about appropriate AD sponsorsh= ip when that would be the best context for a draft.=C2=A0

Othe= r work we would like to place into an IRTF stream with a new brand. I expec= t us to start developing an open, academically reviewed proceedings/journal= soon, to best serve our researcher contributions. It will focus on applied= research and running code, similar to ANRW.=C2=A0
=
In summary,= IRTF is ready to start our part of an rfcplusplus experiment. We are a par= t of the IETF community and indeed a part of this BOF (this responds to Bri= an Carpenter=E2=80=99s comment quoted below).

<= div>Allison=C2=A0

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94-

Brian Carpenter wrote:

Ted,

It would be on = topic if there was a proposal inside the IRTF to change=C2=A0the publication venue for IRTF = output. But this is an IETF BOF so all=C2=A0we can do is discuss how IETF stream documents a= re published.

I know this is an inconvenient truth for some people, bu= t there it is.

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

_____________________________= __________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplu= splus

--0000000000002f583f0570bd63f0-- From nobody Wed Jul 11 11:28:21 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3397130F2D for ; Wed, 11 Jul 2018 11:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 h7BdBSm3FCkD for ; Wed, 11 Jul 2018 11:28:14 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFE2130F3B for ; Wed, 11 Jul 2018 11:28:14 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id f4-v6so5326381plb.9 for ; Wed, 11 Jul 2018 11:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DRsWw8hPT5OOtfpBpyln91mY4jsFj4FUpnB/olvMtlI=; b=VKWfppPdmcYhME6/q3HjSjuGyEoiMnCp3UKTS+MOX/aI7iRJ6lQDeWQktU32TbErvF +Hy15Wkr0Fbl+Lw6dooaI7SEi4dVoR+BStdbFt0Vs35f43taPXq43YvtTRa7+5YSYOUY k9bAomoc6GDWTJe4RSb2y+jwf9jmcLfjZWRJ1oYX+7iIsTqLbLWO+mVIipbFsbs77wzB bsWShARreB2EFqDVZeRMCswOm/PSWT9nYoOccqqrr8vGzT/mqCcfmYaGW/l+01c+Hf13 0OrJ01iuw7jx1SKGvkLAoMO+6M2k2e2f/vDu1aqG3FXHV1xlkITjvBtYc/32EL0TvdVH XW4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DRsWw8hPT5OOtfpBpyln91mY4jsFj4FUpnB/olvMtlI=; b=qS4NsBE4JJiT5iHNj3QdAmTMWLEdSWt6rmTj4rtNeO84EqnHyLBPrZzYldsHw/fInw 4ZKphdBhIW1pL+7aCn/sfChaspZSK0w8By9IVl41uuwKUDqRAUMBYCVeal9NqJAM8/m/ bc86UM+NeYB/vcCYSSDDVh9QeJvzobfr+QaCjaouZnQu8dKc1KpeCnpjqgqpjp3DWHfA CjhREpefVpiGpiCWG1wtUAkndbDdDkJy3gx2AwZ1CWCgmX9mjSVLMo16L0GWAqNbbjZf yNTfCn+GjZKfDY2QafH5O1+wgCSs2nhisJTkiHePGjv7QuIB5nqzOGVzFG4xz9taLXWl GtMA== X-Gm-Message-State: APt69E2Pt9dP1It1BEsweJJYANAelMFwMwYNa7sQk7wpK2frtsxCKGpU tAb7WNV+vUQdG7Anmb0P/XV1ZT9qHWggMSpB+Vs= X-Google-Smtp-Source: AAOMgpe70QKciHQkULeDlG0UHcN2KrKlQDViUAqD9YqMa2TjVD3OYyFBK+e5YRRsbttQxu6/pg9g3KM2zR9PqhJ8qTk= X-Received: by 2002:a17:902:c85:: with SMTP id 5-v6mr29914306plt.126.1531333694350; Wed, 11 Jul 2018 11:28:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:ac18:0:0:0:0 with HTTP; Wed, 11 Jul 2018 11:28:13 -0700 (PDT) In-Reply-To: References: From: Allison Mankin Date: Wed, 11 Jul 2018 14:28:13 -0400 Message-ID: To: "Diego R. Lopez" Cc: Aaron Falk , "Rfcplusplus@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e268bd0570bd6886" Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:28:19 -0000 --000000000000e268bd0570bd6886 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Diego, That=E2=80=99s something I expect we=E2=80=99d resolve in the IRSG business= meetings. Allison On Wednesday, 11 July 2018, Diego R. Lopez wrote: > Hi, > > > > And, as shepherd of an IRTF document awaiting IEG review, what would be > the fate of those in the queue? > > > > Be goode, > > > > -- > > "Esta vez no fallaremos, Doctor Infierno" > > > > Dr Diego R. Lopez > > Telefonica I+D > > https://www.linkedin.com/in/dr2lopez/ > > > > e-mail: diego.r.lopez@telefonica.com > > Tel: +34 913 129 041 > > Mobile: +34 682 051 091 > > ---------------------------------- > > > > On 11/07/2018, 20:23, "Rfcplusplus on behalf of Aaron Falk" < > rfcplusplus-bounces@ietf.org on behalf of aaron.falk@gmail.com> wrote: > > > > Hi Allison- > > Can you clarify whether you are proposing to end the IRTF RFC stream when > this new series is created or supplementing it with another, more > academically oriented stream? If the former, do you believe all IRTF > documents can be published either as IETF RFCs or the new type? (I would > find that surprising.) > > --aaron > > On 11 Jul 2018, at 13:26, Allison Mankin wrote: > > (IRTF Chair hat on) > > One of my goals as IRTF Chair is precisely to create a new, non-RFC strea= m > for the IRTF. So, IRTF is very much an interested party in this BOF. > > > > The most common response I get during outreach into academia is that RFCs > aren=E2=80=99t a good medium for most academics. This is despite research= ers=E2=80=99 wish > eventually to have ideas deployed. We=E2=80=99ve been exploring what work= product > will best serve the research community, and . this does include > distinguishing the work from the RFCs. I like Brian Trammell=E2=80=99s di= scussion > in the =E2=80=9Cconversation=E2=80=9D thread very much, btw; he has expre= ssed how academics > and pseudo-academics contribute very well. > > > > I notice there has been little call for data about IRTF and RFCs. I think > it=E2=80=99s because RFC does mostly signify a production brand. I=E2=80= =99d encourage the > other streams to examine what makes them production-ready. > > > > We in IRTF do have some work close to production, for example, CFRG crypt= o > recommendations. I would want to talk with IESG about appropriate AD > sponsorship when that would be the best context for a draft. > > > > Other work we would like to place into an IRTF stream with a new brand. I > expect us to start developing an open, academically reviewed > proceedings/journal soon, to best serve our researcher contributions. It > will focus on applied research and running code, similar to ANRW. > > > > In summary, IRTF is ready to start our part of an rfcplusplus experiment. > We are a part of the IETF community and indeed a part of this BOF (this > responds to Brian Carpenter=E2=80=99s comment quoted below). > > > > Allison > > > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94- > > > > Brian Carpenter wrote: > > > > Ted, > > It would be on topic if there was a proposal inside the IRTF to change th= e > publication venue for IRTF output. But this is an IETF BOF so all we can = do > is discuss how IETF stream documents are published. > > I know this is an inconvenient truth for some people, but there it is. > > Brian > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > > > ------------------------------ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener informaci=C3=B3n privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilizaci=C3= =B3n, > divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en= virtud de > la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le ro= gamos > que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a s= u > destrucci=C3=B3n. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution o= r > copying of this communication is strictly prohibited. If you have receive= d > this transmission in error, do not read it. Please immediately reply to t= he > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3= =A1rio, > pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 pa= ra uso exclusivo > da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa senhoria o des= tinat=C3=A1rio > indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga= =C3=A7=C3=A3o e/ou > c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da le= gisla=C3=A7=C3=A3o vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o > --000000000000e268bd0570bd6886 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Diego,

That=E2=80=99s something I expect we=E2=80=99d re= solve in the IRSG business meetings.

Allison
=





=

On Wednesday, 11 July 2018, Diego R. Lopez <diego.r.lopez@telefonica.com> wrote:

Hi,<= u>

<= /u>=C2=A0

And,= as shepherd of an IRTF document awaiting IEG review, what would be the fat= e of those in the queue?

<= /u>=C2=A0

Be g= oode,

<= /u>=C2=A0

--

"Esta vez no f= allaremos, Doctor Infierno"

=C2=A0

Dr Diego R. Lopez

Telefonica I+D

https://www.linkedin.com/in/dr2lopez/=C2=A0

=C2=A0

e-mail:=C2=A0diego.r.lopez@telefonica.com

Tel:= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 +34 913 129 041

Mobi= le: =C2=A0+34 682 051 091

----= ------------------------------

<= /u>=C2=A0

On 11/07/2018, 20:23, &= quot;Rfcplusplus on behalf of Aaron Falk" <rfcplusplus-bounces@ietf.org = on behalf of aaron.falk@gmail.= com> wrote:

=C2=A0

Hi Allison-

Can you clarify whether you are proposing to end the IRTF RFC= stream when this new series is created or supplementing it with another, m= ore academically oriented stream? If the former, do you believe all IRTF documents can be published either as IETF RFCs or = the new type? (I would find that surprising.)

--aaron

On 11 Jul 2018, at 13:26, Allison Mankin wrote:=

(IRTF Chai= r hat on)

One of my = goals as IRTF Chair is precisely to create a new, non-RFC stream for the IR= TF. So, IRTF is very much an interested party in this BOF.=C2=A0

=C2=A0=

The most c= ommon response I get during outreach into academia is that RFCs aren=E2=80= =99t a good medium for most academics. This is despite researchers=E2=80=99 wish eventually to have ideas deployed. We=E2=80=99ve been exploring what = work product will best serve the research community, and . this does includ= e distinguishing the work from the RFCs. I like Brian Trammell=E2=80=99s di= scussion in the =E2=80=9Cconversation=E2=80=9D thread very much, btw; he has expressed how academics and pseudo-academics contribute very w= ell.

=C2=A0=

I notice t= here has been little call for data about IRTF and RFCs. I think it=E2=80=99= s because RFC does mostly signify a production brand. I=E2=80=99d encourage the other streams to examine what makes them production-ready.

=C2=A0=

We in IRTF= do have some work close to production, for example, CFRG crypto recommenda= tions. I would want to talk with IESG about appropriate AD sponsorship when that would be the best context for a draft.=C2=A0

=C2=A0=

Other work= we would like to place into an IRTF stream with a new brand. I expect us t= o start developing an open, academically reviewed proceedings/journal soon, to best serve our researcher contributions. It w= ill focus on applied research and running code, similar to ANRW.=C2=A0

=C2=A0=

In summary= , IRTF is ready to start our part of an rfcplusplus experiment. We are a pa= rt of the IETF community and indeed a part of this BOF (this responds to Brian Carpenter=E2=80=99s comment quoted below).<= u>

=C2=A0=

Allison=C2= =A0

=C2=A0=

=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94-

=C2=A0=

Brian Carp= enter wrote:

=C2= =A0

Ted,

It would be on topic if there was a proposal inside the IRTF to change=C2= =A0the publication venue for IRTF output. But this is an IETF BOF so all=C2= =A0we can do is discuss how IETF stream documents are published.

I know this is an inconvenient truth for some people, but there it is.

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

__________________________________________= _____
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listin= fo/rfcplusplus



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
--000000000000e268bd0570bd6886-- From nobody Wed Jul 11 11:28:51 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D104E130F58 for ; Wed, 11 Jul 2018 11:28:47 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 GxiT9lccHWi6 for ; Wed, 11 Jul 2018 11:28:43 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10B9130EF9 for ; Wed, 11 Jul 2018 11:28:42 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fdJqz-0008oO-CM; Wed, 11 Jul 2018 14:28:41 -0400 Date: Wed, 11 Jul 2018 14:28:35 -0400 From: John C Klensin To: Allison Mankin cc: Rfcplusplus@ietf.org Message-ID: <5F79ECCE7999F4FD4FFC00A3@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:28:49 -0000 --On Wednesday, July 11, 2018 13:26 -0400 Allison Mankin wrote: >... > Other work we would like to place into an IRTF stream with a > new brand. I expect us to start developing an open, > academically reviewed proceedings/journal soon, to best serve > our researcher contributions. It will focus on applied > research and running code, similar to ANRW. Allison, Three questions: How are ANRW papers published now? From a quick search, it looks as if at least one or two of the proceedings volumes were published by ACM via their usual methods and using their distribution methods. Is that generally true? Is the IRTF's plan to continue using the RFC Editor function for editing, archiving, and distribution or do you anticipate going off in some completely different direction? Have you done an analysis of the challenges associated with setting up a new academic journal, independent of known publishers of such things, and getting them accepted and into libraries, etc. Things have changed (and, from what I understand, gotten harder) but I was involved with trying to set one up via the UN some years ago and, after a lot of advice from key institutions and a lot of frustration, determined that we needed to "sell" the journal to an existing major academic journal publisher. I don't know if the same situation would exist with IRTF publications, but it seems to me that the question is worth asking. best, john From nobody Wed Jul 11 11:33:03 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B77130EA0 for ; Wed, 11 Jul 2018 11:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 8_wU8VVkf792 for ; Wed, 11 Jul 2018 11:32:59 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBB8130F3B for ; Wed, 11 Jul 2018 11:32:59 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id h4-v6so21923502qtj.7 for ; Wed, 11 Jul 2018 11:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:embedded-html; bh=iFQrh1JHLwT1F4XXyEJ/xe2xHbvThHbjjkUq6/8d6Qc=; b=uphqwzI/79jyVEFnEXpkxnuAZwibiDy0tH1Y17aNgn8f5oC07/gLZ1Q6Xlne53q8XM DXwWQfZ9o1JMIL1v89iSr5/ZB/tHu7w8X4vbHF53aAhQ44YD3Q9c5gFakCQzqV1jeAv9 n/0BSZyS2jQ1L197kugKwF6wjrJFYE7TVx023dP3Ww9hJ9YO7S4i+YyfqprkjEkNnVFF SEQQ6KV1obWbywBl7ofCatP/s6LLv5EdCRz7ITNESIhrPAcxsjAOX/5V7oi4E7VcfK1H fCKBpeZeHgkoPtWMUzANjh4UHcXZO2uzpbgkgVayEVaF/L/ZnrXn2j0dsFRqgogVsBdb /KhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:embedded-html; bh=iFQrh1JHLwT1F4XXyEJ/xe2xHbvThHbjjkUq6/8d6Qc=; b=d0cGMREZGcbEfFaWLl3oqaSIDlhu0ZdqqSPR/ymUcTDzdG8zpK1ps3Ui4+m8n39+i2 4qlMH9m2Pf2JbDMXhbnrwOa3MSghpp0bRCnXApA1jnyPDNhSgR7B3eUUDxKmh1QSOL1D FYmwmxarmmcJPTBNjvV1a57nyhhHEK3tevqjXOLfwvlSKyDpXCcJtLQMPidetj5MdAHK 4gH8pJX+wydEuUbLgrOwR6aGyzyDEfAbL1qsUGA3Bm9H73v7NgP5X17heOHyisnVr3FN bSZR2C5osZkKEiwu+XNrXCGbPStbUexv7+ONUj4m6CXhM1YFoSUeEpPwtDwr9FTHKI44 fXEA== X-Gm-Message-State: APt69E2Zi0+CuYNtCOd1bxB2m26obOkcqSRpfCh3IMLyiE8Y9t/7l/FY gNF0xL9Szeg4AdjKwHT0amU= X-Google-Smtp-Source: AAOMgpfFDWDFwg0d9vzzoYaOh7JhDsfiu+2iPIAsbrZE01fOxWBAHP+AF1fwVPKEpnTX4qN/mPeQIg== X-Received: by 2002:ac8:2374:: with SMTP id b49-v6mr11004888qtb.37.1531333978204; Wed, 11 Jul 2018 11:32:58 -0700 (PDT) Received: from [172.19.33.154] ([2001:4878:a000:3000:c4e6:6bd4:d487:2f5e]) by smtp.gmail.com with ESMTPSA id y21-v6sm7447164qtc.41.2018.07.11.11.32.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 11:32:57 -0700 (PDT) From: "Aaron Falk" To: "Allison Mankin" Cc: Rfcplusplus@ietf.org Date: Wed, 11 Jul 2018 14:32:56 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_7A265AD7-E440-4B78-8E24-5609CADA3D13_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[918, 5612], "plain":[539, 2867], "uuid":"288850CE-49AF-45C3-8D9A-5153A5338462"}] Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:33:02 -0000 --=_MailMate_7A265AD7-E440-4B78-8E24-5609CADA3D13_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Well, I'm not following any RGs so my view is slightly dated but there was a time when the ICCRG was evaluating congestion control proposals and making recommendations on safety before the TSV wgs could consider them. More generally, there's a tradition of the IRTF considering topics where it's not clear whether they are research or engineering having a home. I thought of the common publication format and venue as being rather helpful for migrating from one to the other. --aaron On 11 Jul 2018, at 14:26, Allison Mankin wrote: > Hi, Aaron, > > What would be examples of the surprising? > > I don’t see an IRTF more academic stream as being in the strict mold > of > conferences and journals, if that is the issue. > > Allison > > > On Wednesday, 11 July 2018, Aaron Falk wrote: > >> Hi Allison- >> >> Can you clarify whether you are proposing to end the IRTF RFC stream >> when >> this new series is created or supplementing it with another, more >> academically oriented stream? If the former, do you believe all IRTF >> documents can be published either as IETF RFCs or the new type? (I >> would >> find that surprising.) >> >> --aaron >> >> On 11 Jul 2018, at 13:26, Allison Mankin wrote: >> >> (IRTF Chair hat on) >> One of my goals as IRTF Chair is precisely to create a new, non-RFC >> stream >> for the IRTF. So, IRTF is very much an interested party in this BOF. >> >> The most common response I get during outreach into academia is that >> RFCs >> aren’t a good medium for most academics. This is despite >> researchers’ wish >> eventually to have ideas deployed. We’ve been exploring what work >> product >> will best serve the research community, and . this does include >> distinguishing the work from the RFCs. I like Brian Trammell’s >> discussion >> in the “conversation†thread very much, btw; he has expressed how >> academics >> and pseudo-academics contribute very well. >> >> I notice there has been little call for data about IRTF and RFCs. I >> think >> it’s because RFC does mostly signify a production brand. I’d >> encourage the >> other streams to examine what makes them production-ready. >> >> We in IRTF do have some work close to production, for example, CFRG >> crypto >> recommendations. I would want to talk with IESG about appropriate AD >> sponsorship when that would be the best context for a draft. >> >> Other work we would like to place into an IRTF stream with a new >> brand. I >> expect us to start developing an open, academically reviewed >> proceedings/journal soon, to best serve our researcher contributions. >> It >> will focus on applied research and running code, similar to ANRW. >> >> In summary, IRTF is ready to start our part of an rfcplusplus >> experiment. >> We are a part of the IETF community and indeed a part of this BOF >> (this >> responds to Brian Carpenter’s comment quoted below). >> >> Allison >> >> ——————- >> >> Brian Carpenter wrote: >> >> Ted, >> >> It would be on topic if there was a proposal inside the IRTF to >> change the >> publication venue for IRTF output. But this is an IETF BOF so all we >> can >> do is discuss how IETF stream documents are published. >> >> I know this is an inconvenient truth for some people, but there it >> is. >> >> Brian >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >> >> --=_MailMate_7A265AD7-E440-4B78-8E24-5609CADA3D13_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Well, I'm not following any RGs so my view is slightly dat= ed but there was a time when the ICCRG was evaluating congestion control = proposals and making recommendations on safety before the TSV wgs could c= onsider them. More generally, there's a tradition of the IRTF considerin= g topics where it's not clear whether they are research or engineering ha= ving a home. I thought of the common publication format and venue as bei= ng rather helpful for migrating from one to the other.

--aaron

On 11 Jul 2018, at 14:26, Allison Mankin wrote:

Hi= , Aaron,

What would be examples of the surprising?=C2=A0=

I don=E2=80=99t see an IRTF more academic strea= m as being in the strict mold of conferences and journals, if that is the= issue.

Allison


On Wednesday, = 11 July 2018, Aaron Falk <aaro= n.falk@gmail.com> wrote:
<= p dir=3D"auto">Hi Allison-

Can you clarify whether you are proposing to end the IRTF= RFC stream when this new series is created or supplementing it with anot= her, more academically oriented stream? If the former, do you believe al= l IRTF documents can be published either as IETF RFCs or the new type? (= I would find that surprising.)

--aaron

On 11 Jul 2018, at 13:26, Allison Mankin wrote:

(IRTF Chair hat on)
One of my goals as IRTF Chair is pre= cisely to create a new, non-RFC stream for the IRTF. So, IRTF is very muc= h an interested party in this BOF.=C2=A0

The most common= response I get during outreach into academia is that RFCs aren=E2=80=99t= a good medium for most academics. This is despite researchers=E2=80=99 w= ish eventually to have ideas deployed. We=E2=80=99ve been exploring what = work product will best serve the research community, and . this does incl= ude distinguishing the work from the RFCs. I like Brian Trammell=E2=80=99= s discussion in the =E2=80=9Cconversation=E2=80=9D thread very much, btw;= he has expressed how academics and pseudo-academics contribute very well= =2E

I notice there has been little call for data about I= RTF and RFCs. I think it=E2=80=99s because RFC does mostly signify a prod= uction brand. I=E2=80=99d encourage the other streams to examine what mak= es them production-ready.

We in IRTF do have some work clo= se to production, for example, CFRG crypto recommendations. I would want = to talk with IESG about appropriate AD sponsorship when that would be the= best context for a draft.=C2=A0

Other work we would lik= e to place into an IRTF stream with a new brand. I expect us to start dev= eloping an open, academically reviewed proceedings/journal soon, to best = serve our researcher contributions. It will focus on applied research and= running code, similar to ANRW.=C2=A0

= In summary, IRTF i= s ready to start our part of an rfcplusplus experiment. We are a part of = the IETF community and indeed a part of this BOF (this responds to Brian = Carpenter=E2=80=99s comment quoted below).

=
Allison=C2=A0=

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94-<= /span>

Brian Carpenter wrote:

Ted,
It would be on topic if there was a proposal inside the IRTF to change=C2= =A0the publicat= ion venue for IRTF output. But this is an IETF BOF so all=C2=A0we can do is discuss how = IETF stream documents are published.

I know this is an inconveni= ent truth for some people, but there it is.

=C2=A0=C2=A0=C2=A0Br= ian

_________________________= ______________________
Rfcplusplus mailing list
Rfcplusplus@iet= f.org
https://www.ietf.org/mailman/listinfo/rf= cplusplus

--=_MailMate_7A265AD7-E440-4B78-8E24-5609CADA3D13_=-- From nobody Wed Jul 11 11:55:43 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2EE130F67 for ; Wed, 11 Jul 2018 11:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 h1qW9-ENpVh6 for ; Wed, 11 Jul 2018 11:55:39 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BADB8130F62 for ; Wed, 11 Jul 2018 11:55:38 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id p129-v6so9550078ywg.7 for ; Wed, 11 Jul 2018 11:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=weDzLZ9qkQMrWP1AcWem6e3YcEZBtXnwQ6go5WtSSYE=; b=itfedaJQ7d+BbNhFGKg7B6jwngXlN57P2d1TmV9kxNWDTpq5euKNfxTXLRqS3ei/bf U8kFB3XEj7zGAD0pkgfbT2DtMmaFTgRji1fF0KBXpKrEZ12096FHLp0XGz255pw5urow jOnPwdjMG6GLzh9gcQyUvK+wKvK1WHTm3GLY4Y1atbfrRyAIUHVq/1qNU6fwZ0bcIhrl 8KvL0z+V6jNARWhkSFk6mi2voqA7r7yT269nBRST+5VdBBI5qVFnXoUafxR53lVJ2WAq b+VnEJF5hWvA68vBuXgODXdkpKCwZo1+WuMW9j+VgNkoNNj3I4oTCPYV6oWHgxYiF4gu 1/iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=weDzLZ9qkQMrWP1AcWem6e3YcEZBtXnwQ6go5WtSSYE=; b=PR3iC3ZyVIqGS2tTow5wL3AuWWtEcKio0pGKbfJtxtc4w9Xkn69DWo2eM0JlPyDCbV lq7sYfdtYZLVgZy4ul8WYiSjvC4yRX6OoB7dKckvwxIq0bKjrC7nd+SwbO1ATq9Vq812 wYZ9Z27cOiusc2i21i42FvATg5MiyUv+3ApdiP6v4+hgabNfUYMyRNad8sADQ8p0xP6c tCgDCuBwlhaSBj5kU2vz//mqwXbZSlXOSXo19m0v21sI8nRSINsXP+JIAVUXn097f7hI V5C1SwC4yblOyi5HVrHFdvF5zZYHSLg5jIuoJk1EYdqIDL2Bj9ax2p/z+8/i5KKhHVCe E3+Q== X-Gm-Message-State: APt69E00B0CLg5N3cuU3UWLFN+0X3UMf5otWUOa/I0tULlePkieCD5q9 LPmr8+TyCLxQjN3vTUB6tALN3dYmakmip6Wxxrts3g== X-Google-Smtp-Source: AAOMgpcD1QilJAzdzar3Ym/ggHtMcfqWB4me5koiqZ1bqhUVyW8sF7PZAkJzHk4ROzjX9pEV8gsfAe+YjnYaHT3zYkM= X-Received: by 2002:a81:3e02:: with SMTP id l2-v6mr15695119ywa.381.1531335337894; Wed, 11 Jul 2018 11:55:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 11:54:57 -0700 (PDT) In-Reply-To: <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> From: Eric Rescorla Date: Wed, 11 Jul 2018 11:54:57 -0700 Message-ID: To: Peter Saint-Andre Cc: S Moonesamy , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000d8f9930570bdca02" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:55:42 -0000 --000000000000d8f9930570bdca02 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 11, 2018 at 11:07 AM, Peter Saint-Andre wrote: > Hi SM! > > On 7/11/18 11:38 AM, S Moonesamy wrote: > > Hi Peter, > > At 09:24 AM 11-07-2018, Peter Saint-Andre wrote: > >> We as a community seem to be confused about what level of "peer review" > >> we think is important, appropriate, necessary, or sufficient. We're > >> engineers, not academics, so comparing our publications to academic > >> journals might not be relevant. > > > > Do IETF participants need a license [1] in the practice of engineering? > > s/engineers/technologists/ ;-) > > > There are academics who have authored RFCs in some of the Streams. > > Indeed. We could ask them what their goals were in doing so and what the > results of RFC publication were for them. > > > There is an IAB RFC about citability of for scholarly publications. Why > > would academic journals not be relevant? > > Publishing an RFC is different from publishing a paper in an academic > journal, so applying the same criteria might not be appropriate. Indeed. For instance, novelty is one of the first questions one asks about a scientific paper. And yet here at IETF we routinely publish documents with no new scientific content at all. Indeed, one might argue that it's better if they don't because you have more confidence it will work -Ekr As far > as I can see we're not actively catering to an academic audience (either > as authors or readers). > > > There has to be some level of review or else there wouldn't be any > > quality control. I agree that there is some confusion on the level of > > review which is required. > > And different levels or kinds of review across the different streams. > This returns to the question of audiences for the streams. Vendors and > operators seem to differ quite a bit from researchers and academics > (naturally there is always overlap). > > Peter > > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > > --000000000000d8f9930570bdca02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 11, 2018 at 11:07 AM, Peter Saint-Andre &= lt;stpeter@mozilla= .com> wrote:
Hi SM!

On 7/11/18 11:38 AM, S Moonesamy wrote:
> Hi Peter,
> At 09:24 AM 11-07-2018, Peter Saint-Andre wrote:
>> We as a community seem to be confused about what level of "pe= er review"
>> we think is important, appropriate, necessary, or sufficient. We&#= 39;re
>> engineers, not academics, so comparing our publications to academi= c
>> journals might not be relevant.
>
> Do IETF participants need a license [1] in the practice of engineering= ?

s/engineers/technologists/ ;-)

> There are academics who have authored RFCs in some of the Streams.

Indeed. We could ask them what their goals were in doing so and what= the
results of RFC publication were for them.

> There is an IAB RFC about citability of for scholarly publications.=C2= =A0 Why
> would academic journals not be relevant?

Publishing an RFC is different from publishing a paper in an academi= c
journal, so applying the same criteria might not be appropriate.

Indeed. For instance, novelty is one of the first qu= estions one asks about a scientific
paper. And yet here at IETF w= e routinely publish documents with no new scientific
content at a= ll. Indeed, one might argue that it's better if they don't because = you have
more confidence it will work

-Ekr

As far
as I can see we're not actively catering to an academic audience (eithe= r
as authors or readers).

> There has to be some level of review or else there wouldn't be any=
> quality control.=C2=A0 I agree that there is some confusion on the lev= el of
> review which is required.

And different levels or kinds of review across the different streams= .
This returns to the question of audiences for the streams. Vendors and
operators seem to differ quite a bit from researchers and academics
(naturally there is always overlap).

Peter



_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus


--000000000000d8f9930570bdca02-- From nobody Wed Jul 11 12:00:17 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4AD130FB4 for ; Wed, 11 Jul 2018 12:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 57t8UOT2-Rof for ; Wed, 11 Jul 2018 12:00:08 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 74552130FC7 for ; Wed, 11 Jul 2018 12:00:08 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id q129-v6so6759180ywg.8 for ; Wed, 11 Jul 2018 12:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QRbsysfkyzTfmbTD+Yqx+NCYmD3IY0DBAV0wasU7maQ=; b=lWn1JhRkqk8CvUTsrQsZmxRXxuhrbYpAUT+VFIC2GepNg1vfZWamoHu7Uy/X1UDIun v1sueXHuIsrHgfhUz2vyeEf9ctCvcg+0rtGSwA4AojJPozQtJyr4/VeMYQwwSJV40JoL RFt496cyH5ryv6k608Q1A4q5GZbVVE+uqe9WcuIcLmpXkLaIf+pQR2m0agWJ2a9ZfWK1 GlOzefY6xV6MA1B/HQPPz4pcZWI6BYVhOfvCpihdBXe+7Uh39cE7jaoGyngqQA5Uodta 16iskWin2HrAJOAHhWQfzM7KyE4uMQiNtjyfGxNjoPy3Sg4PbYr05bF98sBH2V8tOvLt LzUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QRbsysfkyzTfmbTD+Yqx+NCYmD3IY0DBAV0wasU7maQ=; b=qzItSJwoBXE+0TW8v9I1NYYgf5mNaNp+1TrJh04cwusYW2DoQUl1q+8lkx5nOImQax mq84u+YY+oA1YYuCQdEa4n42+Udu/+yENLJ/P2cGFwR1AYThHfN8k0F2XhWJukCxge6e ONk+9QyzmxvmfgA00ugXW71KQintlowdhqd2Fj1/dlYsRLxRrYvpwS3vGaHT77lBDeMA 1OqeklYt6Eqbks/ZmCqAIAnbiyQ+QzyGD822Oq+xqUuHNVvwi5vzERjaDpdP+R+NqK07 DCPglfOU5kCnyh8+wB3FeKJuGcZ2bM2tV9xej3Vn5U3nX01fpLdYY9IT0HZfjtC5LP53 minA== X-Gm-Message-State: APt69E0N7KfzdgQljk9JAUhmeWaw+BOoxQRX3NjiVURBz0bmtNExeBXk A4mIjIwv3vptEoV5oLRToVloXCitp/mFiwgl8KBvcw== X-Google-Smtp-Source: AAOMgpcHBJdA4eXd9RoLGk89RV4bnTcFr18B4ewCBwrHNi9Uo76acsBsAxgWiPImqd0J108FCxrYMu/bhP4wgHC+9gI= X-Received: by 2002:a81:b642:: with SMTP id h2-v6mr15100790ywk.102.1531335607741; Wed, 11 Jul 2018 12:00:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 11:59:27 -0700 (PDT) In-Reply-To: <5F79ECCE7999F4FD4FFC00A3@PSB> References: <5F79ECCE7999F4FD4FFC00A3@PSB> From: Eric Rescorla Date: Wed, 11 Jul 2018 11:59:27 -0700 Message-ID: To: John C Klensin Cc: Allison Mankin , Rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000ee84460570bdda7d" Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 19:00:15 -0000 --000000000000ee84460570bdda7d Content-Type: text/plain; charset="UTF-8" On Wed, Jul 11, 2018 at 11:28 AM, John C Klensin wrote: > > > --On Wednesday, July 11, 2018 13:26 -0400 Allison Mankin > wrote: > > >... > > Other work we would like to place into an IRTF stream with a > > new brand. I expect us to start developing an open, > > academically reviewed proceedings/journal soon, to best serve > > our researcher contributions. It will focus on applied > > research and running code, similar to ANRW. > > Allison, > > Three questions: > > How are ANRW papers published now? From a quick search, it > looks as if at least one or two of the proceedings volumes were > published by ACM via their usual methods and using their > distribution methods. Is that generally true? > Without taking a position on ANRW, ISOC already runs ISOC NDSS, so presumably cloning that wouldn't be particularly difficult. -Ekr --000000000000ee84460570bdda7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 11, 2018 at 11:28 AM, John C Klensin <= john-ietf@jck.com> wrote:


--On Wednesday, July 11, 2018 13:26 -0400 Allison Mankin
<allison.m= ankin@gmail.com> wrote:

>...
> Other work we would like to place into an IRTF stream with a
> new brand. I expect us to start developing an open,
> academically reviewed proceedings/journal soon, to best serve
> our researcher contributions. It will focus on applied
> research and running code, similar to ANRW.

Allison,

Three questions:

How are ANRW papers published now?=C2=A0 From a quick search, it
looks as if at least one or two of the proceedings volumes were
published by ACM via their usual methods and using their
distribution methods.=C2=A0 Is that generally true?
Without taking a position on ANRW, ISOC already runs ISOC NDSS= , so presumably cloning that wouldn't be particularly difficult.
<= div>
-Ekr


--000000000000ee84460570bdda7d-- From nobody Wed Jul 11 12:05:35 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B0A130F6D for ; Wed, 11 Jul 2018 12:05:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 xWUMGNvzz3TB for ; Wed, 11 Jul 2018 12:05:30 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 CA3E8130F70 for ; Wed, 11 Jul 2018 12:05:29 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id v71-v6so4143401itb.3 for ; Wed, 11 Jul 2018 12:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=Mchysyr9dH1ElixwMr8bDXedwVR2MozA30/0HVDMNCU=; b=bnr57aJoScy1uvJDihIq4EuW57zUTh3hrwZCZXqFeSBLjIxTR9nA7bY0JqtmT4oDF2 K42JohRyyk9pZLJc/bV4+I2g2J7VOAA++mqj+Fa3iqBqwLnlGlusgW1TRD/H/C8DBeFo xZzVpEFtWOyZFrn94v0kjnIc+5ZsMNZdm6aCo= 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=Mchysyr9dH1ElixwMr8bDXedwVR2MozA30/0HVDMNCU=; b=rpT1Dapq3uzj75+ynx28HL+W/vfsgeQZCFbog7xLJbe+3bJCBVRubh0LwLlxA1QRyl nQg+7q+pvwHzsWaAqp5VbbHYBk3jfkSwcBZVbQD7pPctwyDhyc0cgtBJTa8XfyRYctAV akuXYaLuI7+C1adzsDHPo3vVQp+3HQMTwT2xFHnBZvOJE74zCfFM2UCA+gw3FsWxipae FH1sPxek8Klw9LJJsY3G3GPDd0qLs9HHrfP8O+enRAfAaHz75d4Qf9gqfoYt8oVNB9k4 jDfgz+xU8JPCrZkN49a8+NLZQEueWKxA3b+/XrLd7LY0TEPbmzznXabOykAWbIY+ubfT EOVA== X-Gm-Message-State: APt69E1v1MyK5cxpBQo/MYc7wc4xHsINfot3Bkg1m1K1zQa7Lk/vKjRT Vk63NDORAiTO/0o5KT2MZ8RWtw== X-Google-Smtp-Source: AAOMgpePRq99g3poyIgoeTNTCwos3v5tlhqe+fXKVtkZb01Cy/jz3Onw23IOcYJA06f6JHGPjDtF5g== X-Received: by 2002:a02:687:: with SMTP id 129-v6mr24787126jav.59.1531335929025; Wed, 11 Jul 2018 12:05:29 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id x17-v6sm7709978iob.6.2018.07.11.12.05.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 12:05:28 -0700 (PDT) To: Aaron Falk , Allison Mankin Cc: Rfcplusplus@ietf.org References: From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <9690a162-b4fa-4857-f890-4fb3856273d5@mozilla.com> Date: Wed, 11 Jul 2018 13:05:27 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PdHtOJoZYMn9wg3OxZt79MGWGW4fjRaSz" Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 19:05:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PdHtOJoZYMn9wg3OxZt79MGWGW4fjRaSz Content-Type: multipart/mixed; boundary="RcK7Xyc25VLkI0BUJK0ybM7eklz3yRfKk"; protected-headers="v1" From: Peter Saint-Andre To: Aaron Falk , Allison Mankin Cc: Rfcplusplus@ietf.org Message-ID: <9690a162-b4fa-4857-f890-4fb3856273d5@mozilla.com> Subject: Re: [Rfcplusplus] IRTF stream considerations References: In-Reply-To: --RcK7Xyc25VLkI0BUJK0ybM7eklz3yRfKk Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable +1! On 7/11/18 12:25 PM, Aaron Falk wrote: > Sorry, I forgot to mention that I think a "open, academically reviewed > proceedings/journal" is a great thing and will be good for the IRTF and= > the IETF. >=20 > --aaron >=20 > On 11 Jul 2018, at 14:23, Aaron Falk wrote: >=20 > Hi Allison- >=20 > Can you clarify whether you are proposing to end the IRTF RFC strea= m > when this new series is created or supplementing it with another, > more academically oriented stream? If the former, do you believe al= l > IRTF documents can be published either as IETF RFCs or the new type= ? > (I would find that surprising.) >=20 > --aaron >=20 > On 11 Jul 2018, at 13:26, Allison Mankin wrote: >=20 > (IRTF Chair hat on) > One of my goals as IRTF Chair is precisely to create a new, > non-RFC stream for the IRTF. So, IRTF is very much an intereste= d > party in this BOF.=C2=A0 >=20 > The most common response I get during outreach into academia is= > that RFCs aren=E2=80=99t a good medium for most academics. This= is > despite researchers=E2=80=99 wish eventually to have ideas depl= oyed. > We=E2=80=99ve been exploring what work product will best serve = the > research community, and . this does include distinguishing the > work from the RFCs. I like Brian Trammell=E2=80=99s discussion = in the > =E2=80=9Cconversation=E2=80=9D thread very much, btw; he has ex= pressed how > academics and pseudo-academics contribute very well. >=20 > I notice there has been little call for data about IRTF and > RFCs. I think it=E2=80=99s because RFC does mostly signify a pr= oduction > brand. I=E2=80=99d encourage the other streams to examine what = makes > them production-ready. >=20 > We in IRTF do have some work close to production, for example, > CFRG crypto recommendations. I would want to talk with IESG > about appropriate AD sponsorship when that would be the best > context for a draft.=C2=A0 >=20 > Other work we would like to place into an IRTF stream with a ne= w > brand. I expect us to start developing an open, academically > reviewed proceedings/journal soon, to best serve our researcher= > contributions. It will focus on applied research and running > code, similar to ANRW.=C2=A0 >=20 > In summary, IRTF is ready to start our part of an rfcplusplus > experiment. We are a part of the IETF community and indeed a > part of this BOF (this responds to Brian Carpenter=E2=80=99s co= mment > quoted below). >=20 > Allison=C2=A0 >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94- >=20 > Brian Carpenter wrote: >=20 > Ted, >=20 > It would be on topic if there was a proposal inside the IRTF to= > change=C2=A0the publication venue for IRTF output. But this is = an > IETF BOF so all=C2=A0we can do is discuss how IETF stream docum= ents > are published. >=20 > I know this is an inconvenient truth for some people, but there= > it is. >=20 > =C2=A0=C2=A0=C2=A0Brian >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 --RcK7Xyc25VLkI0BUJK0ybM7eklz3yRfKk-- --PdHtOJoZYMn9wg3OxZt79MGWGW4fjRaSz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltGVPcACgkQZWGMGH9o FKkM9RAAx/D/0DWlg6deTKDji3y0GcTbrpaHMP++cbWseZQzAv4cWxvh+Nn8hz7r TU8cmdQwPLA3DL4F5EyyRIhPVKegp6VP6PyHCs3ZHO5nWwlUoJ1Aj8f2IIdfLAbk nUpSRojjZ1KqUoxhmwKuvIc+AQAaRqCgXcj5B6D2gle0aJrqx027e7741+p7Gmba VP1n4iKaA2tssmpax4OUknaU8pnlrBSU8AkFD8bjSIAyBq+K7CtA/YxEv2UJQ5wH vTxxZtSp3915/ewozFsu4u0PvJ7+4/4rXTKdXfNcMKGebAYVyeEaWeMCCf3GHBJS dECXr3vYQLl9n0KCQa3a4UZUuK8/mbEEGRaPX4akmWJuDe9KshqzxXmcDhVWUJux 2TCcAsetQzNhlWK9HawYae+HlcKdFFRnYjUFDal2h8o/6SlaoVRnG+Am4otruzF8 IfjnbBTupu+et1SXXjpRVKBrGmrLCrp9kb++B9FiSgjozqpSDFBw+rvKZxIZkN5k j8v2YdW0Z16vDEqkynxM/b7MQH1Pgc7qrBt6S+QcMYnG50DxQHuCBNiaCxvK60bh SGRmwOkM/9I5/z/36T2koC4MPjVsSOwsN4nHZgG+rzf3QEJpURWVfsJnvH7CrvE2 7MlxjMDOgbMOMEwwPJ53ABIh8S2IXQqkg2iowJk6k1XNsFQudR4= =a2CY -----END PGP SIGNATURE----- --PdHtOJoZYMn9wg3OxZt79MGWGW4fjRaSz-- From nobody Wed Jul 11 12:09:12 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC87130F72 for ; Wed, 11 Jul 2018 12:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0v1CCZnq_Vw for ; Wed, 11 Jul 2018 12:09:08 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DF5130F70 for ; Wed, 11 Jul 2018 12:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4713; q=dns/txt; s=iport; t=1531336148; x=1532545748; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=dvZunvCYNj0QQ6EcTpnRnMFBzjsogCpkfc5rtmn2jOo=; b=ENnoBvzTb4F2ZccntgnLj4flJoO4KDvxX9wPvAhUGmZ5BFurZmghcnOP kRny4Kz1RxyVlVhxBJuZ1OMg/CyRoUGA6SBd8yU4LBwloI9l+5uxWdcmb RXAXlb5iwvnyKJtxHngiFjvnsd2TzMZ0pinh2rQ6wOiiXZGmTzmosv+3l w=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPBQB9VEZb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUrhCKIY404CCSQJIcICAOEbAKCXjgUAQIBAQIBAQJtKEI?= =?us-ascii?q?BAQMJAoRlAQUjVhALBAEJCioCAlcGAQwIAQGDHAGBf6o4gS4fiVoPixSBNwy?= =?us-ascii?q?CXod8glUCmVcJg12BWYlrBogZhUiSEoFYIYFSMxoIGxWDJYIkF44ZPYYIE4d?= =?us-ascii?q?HAQE?= X-IronPort-AV: E=Sophos;i="5.51,338,1526342400"; d="asc'?scan'208,217";a="5053386" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2018 19:09:06 +0000 Received: from [10.61.195.132] ([10.61.195.132]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w6BJ95il004846; Wed, 11 Jul 2018 19:09:05 GMT To: Eric Rescorla , Peter Saint-Andre Cc: S Moonesamy , rfcplusplus@ietf.org References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Wed, 11 Jul 2018 21:08:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KIHjqrxBPvipsfuGgZ5lRh3dw7qpMRiMC" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 19:09:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KIHjqrxBPvipsfuGgZ5lRh3dw7qpMRiMC Content-Type: multipart/mixed; boundary="6A69dB3lHDK0kUFoDt11vQHdJxBZAWUK2"; protected-headers="v1" From: Eliot Lear To: Eric Rescorla , Peter Saint-Andre Cc: S Moonesamy , rfcplusplus@ietf.org Message-ID: Subject: Re: [Rfcplusplus] Conversation as metaphor References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> In-Reply-To: --6A69dB3lHDK0kUFoDt11vQHdJxBZAWUK2 Content-Type: multipart/alternative; boundary="------------623750CA00DF58AC6A80F782" Content-Language: en-US This is a multi-part message in MIME format. --------------623750CA00DF58AC6A80F782 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Eric, On 11.07.18 20:54, Eric Rescorla wrote: > > Indeed. For instance, novelty is one of the first questions one asks > about a scientific > paper. And yet here at IETF we routinely publish documents with no new > scientific > content at all. Indeed, one might argue that it's better if they don't > because you have > more confidence it will work I agree.=C2=A0 On projects I've worked on, we've generally made it a poin= t to *not* start at the IETF, precisely because we'd rather kink out the bugs elsewhere. Also, it's a pretty tough venue to get stuff through.=C2=A0 Th= at having been said, RFCs are excellent references for how things are supposed to work.=C2=A0 Those aren't scientific observations and interpretations, but rather engineering specifications. Eliot --------------623750CA00DF58AC6A80F782 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Eric,

On 11.07.18 20:54, Eric Rescorla wrote:

Indeed. For instance, novelty is one of the first questions one asks about a scientific
paper. And yet here at IETF we routinely publish documents with no new scientific
content at all. Indeed, one might argue that it's better if they don't because you have
more confidence it will work

I agree.=C2=A0 On projects I've worked on, we've generally made it a point to not start at the IETF, precisely because we'd rather kink out the bugs elsewhere. Also, it's a pretty tough venue to get stuff through.=C2=A0 That having been said, RFCs are excellent= references for how things are supposed to work.=C2=A0 Those aren't scientific observations and interpretations, but rather engineering specifications.

Eliot


--------------623750CA00DF58AC6A80F782-- --6A69dB3lHDK0kUFoDt11vQHdJxBZAWUK2-- --KIHjqrxBPvipsfuGgZ5lRh3dw7qpMRiMC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltGVb8ACgkQh7ZrRtnS ejMuQAgAl2E81txVSfM5MNivVFyYPdGt+V882pFNY/LHhyJJl6Wlm1AXyN3DlSzB pc9ExHBbu+UBdMC1G5DBJcUW1Syef7mlFTZsPwmlAAiZVdR04fKKxaiPVmfjLV1G rUyxB+LG3+jtjrOpfDt7D5+N/y3302kLuysSSklWQUSbHE4FZ+Wt2sf2oHcbGIWb Qd2V8htcQVB1khQyQ9ojo9ERvHvGjSe43jrSfzd5VasV7+BJH8ylL6Dn0VTbGyMP gR3E9wzIAQv51SsZZU7vjMw8kzytIst3hKylfXbBlc8TiFSa2rX2NqQyqCyEHm1b wXQ1ejnERVfj2H6djDQGkssHhDSyYA== =J1LC -----END PGP SIGNATURE----- --KIHjqrxBPvipsfuGgZ5lRh3dw7qpMRiMC-- From nobody Wed Jul 11 16:49:48 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E6C130E73 for ; Wed, 11 Jul 2018 16:49:46 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 F-f4iOwJF2yq for ; Wed, 11 Jul 2018 16:49:44 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43819124BE5 for ; Wed, 11 Jul 2018 16:49:44 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id x5-v6so3341674pgp.7 for ; Wed, 11 Jul 2018 16:49:44 -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=BYLoOmmWsh8/ykKU3x3HGsVD+g1m48NXO+dXqIu0oco=; b=n32b9+eOQussfA+8QDsuC5uW7Czu2Jy/vgHQUS+ZAgYk7qDRulSrzqC73Zfn9kEokR WTKvBD6LFNwvIBxuYAIw1Zj4S3lVqZZXlStA+KWmZrmbURGsrqMfcmWbWnLDhmtj0VZr kC3WlBL1UYj3X4DJF3vFk9hjGpYLj82O4Y1c41ISaFUsgKDDEJodKFL2glfPpFCFJF7r BQZq5mGolyLSmEDHAhLum7P/n4HfrVMuh6dru0ZTSNBW59ErfD5ae3Ue9PI/ShZcahiP SBIPSDwW4qkoltXIRu5+IF4l6I4R+JskmDOpRmWELGVBCtLKhXCqWXlAWD2gMXOVRYX0 KGhQ== 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=BYLoOmmWsh8/ykKU3x3HGsVD+g1m48NXO+dXqIu0oco=; b=WuUastcGxTyoEsYrpRKygaPMHinj46Kwx1ejYSKuUu2CAsGHg7CvLbJFQJXCdbOC+B W9xgbMOQvH9OewuUZstPFFQxs4V0X3LPByh5ew0WkM34oKvRjH/FBuZM4cxFHMRJdnqR XODtGq9QicqE3OLQrXIzsvT2K90YHFSIRDz1S+NjWaYpzLmO3GnTPefL9lCnafGfh0Bx KO4F8UA/dWEbYH3NJPQOS5GHccv0ERz1pO4AR0/IyglF7B6ZZtSsRfB2axMi8NdtuhL+ DRxdd3OZJBsidEZ3A4gQZ/ZoKKO6qBhLtarvNY/55r6DfawUrdsWRd5IvY5ea45Wk8sD Eylw== X-Gm-Message-State: AOUpUlFj2iL8HXIQj5m91wVTTsiKeUAINuQjK3Z+1mW5Lg1ndsUFWSmd yBVTj/iDdHNltSYNCi3rheiTug== X-Google-Smtp-Source: AAOMgpeoDrwpvU/GQirZLtP8zGeFegpYWN+O656bT7BppjMSofFmEhDk4dtBMa6nlxzo4HH/DqonZQ== X-Received: by 2002:a63:3f05:: with SMTP id m5-v6mr577423pga.51.1531352983403; Wed, 11 Jul 2018 16:49:43 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id t76-v6sm57707755pfe.109.2018.07.11.16.49.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 16:49:42 -0700 (PDT) To: Allison Mankin , "Rfcplusplus@ietf.org" References: From: Brian E Carpenter Message-ID: Date: Thu, 12 Jul 2018 11:49:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 23:49:47 -0000 Hi Allison, On 12/07/2018 05:26, Allison Mankin wrote: > (IRTF Chair hat on) > One of my goals as IRTF Chair is precisely to create a new, non-RFC str= eam > for the IRTF. So, IRTF is very much an interested party in this BOF. Well, that's good to hear, but nevertheless it is an IETF BOF and that limits its direct input to IESG decision making (certainly not its range of topics). What the IRTF decides to do is its own choice, of cours= e. Personally (IRTF participant hat on) I think this is a very good thing for the IRTF to discuss, and I look forward to the discussion when it's brought to the IRTF as a whole. (I'm assuming this is not something the IRSG believes it can decide on its own.) Others have mentioned some of the obvious questions about the boundary between this and the RFC series. > The most common response I get during outreach into academia is that RF= Cs > aren=E2=80=99t a good medium for most academics. This is despite resear= chers=E2=80=99 wish > eventually to have ideas deployed. We=E2=80=99ve been exploring what wo= rk product > will best serve the research community, and . this does include > distinguishing the work from the RFCs. I like Brian Trammell=E2=80=99s = discussion > in the =E2=80=9Cconversation=E2=80=9D thread very much, btw; he has exp= ressed how academics > and pseudo-academics contribute very well. Yes. In my mind there's a distinction between IRTF output that is indeed "just" research, and IRTF output that directly feeds into IETF follow-up.= Of course, where the line lies is a judgment call. =20 > I notice there has been little call for data about IRTF and RFCs. I thi= nk > it=E2=80=99s because RFC does mostly signify a production brand. I=E2=80= =99d encourage the > other streams to examine what makes them production-ready. >=20 > We in IRTF do have some work close to production, for example, CFRG cry= pto > recommendations. I would want to talk with IESG about appropriate AD > sponsorship when that would be the best context for a draft. >=20 > Other work we would like to place into an IRTF stream with a new brand.= I > expect us to start developing an open, academically reviewed > proceedings/journal soon, to best serve our researcher contributions. I= t > will focus on applied research and running code, similar to ANRW. >=20 > In summary, IRTF is ready to start our part of an rfcplusplus experimen= t. > We are a part of the IETF community and indeed a part of this BOF (this= > responds to Brian Carpenter=E2=80=99s comment quoted below). Since I haven't seen this discussed on IRTF lists, don't you mean that th= is is a likely proposal from the IRSG for discussion? Regards Brian >=20 > Allison >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94- >=20 > Brian Carpenter wrote: >=20 > Ted, >=20 > It would be on topic if there was a proposal inside the IRTF to change = the > publication venue for IRTF output. But this is an IETF BOF so all we ca= n do > is discuss how IETF stream documents are published. >=20 > I know this is an inconvenient truth for some people, but there it is. >=20 > Brian >=20 >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 From nobody Wed Jul 11 17:04:48 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1DA130E73 for ; Wed, 11 Jul 2018 17:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=GgdWn8Mx; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=sh7+Ig8d Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIiRiK_gmK0G for ; Wed, 11 Jul 2018 17:04:44 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FACB124BE5 for ; Wed, 11 Jul 2018 17:04:44 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.224.109.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id w6C04Vui014222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2018 17:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1531353883; x=1531440283; bh=tYAt9uOgqZx4BFEzxgAHfD3iPi0VPJ2/VkHDDOsgH/g=; h=Date:To:From:Subject:In-Reply-To:References; b=GgdWn8MxP2KnzJLPaXvyB5xLQgSMyVvTpq+TLfufZDptDed7yrSL0cWrt8nv6RhFb ui+46VGz8QhB06PEk2GhcN77wAMvnOZrVVcmc937Ors9xnAiaOPwMtzVw6T+A+hSG7 RVUTC2KRljHcz/QugBcgeNKEhdStVirLMgqSZelk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1531353883; x=1531440283; i=@elandsys.com; bh=tYAt9uOgqZx4BFEzxgAHfD3iPi0VPJ2/VkHDDOsgH/g=; h=Date:To:From:Subject:In-Reply-To:References; b=sh7+Ig8dDZHxIRgSTcEmaaLWxwrXodymO4y8KizgJSFyDBMLNhVaWcpXRWgy9xth5 QOPc6G0lh9AmbZ9hwtiIL37R5bnI/E7pziiITUwneIbB1EE7I7Ejybu+LqEb2xCKqJ OmHkG8bXRFHfpZ97cyNtAq1zGZLVli4n7mXOmTOQ= Message-Id: <6.2.5.6.2.20180711152805.07d07338@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jul 2018 17:04:05 -0700 To: Peter Saint-Andre , rfcplusplus@ietf.org From: S Moonesamy In-Reply-To: <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 00:04:46 -0000 Hi Peter, At 11:07 AM 11-07-2018, Peter Saint-Andre wrote: >s/engineers/technologists/ ;-) :-) >Indeed. We could ask them what their goals were in doing so and what the >results of RFC publication were for them. Yes. >Publishing an RFC is different from publishing a paper in an academic >journal, so applying the same criteria might not be appropriate. As far >as I can see we're not actively catering to an academic audience (either >as authors or readers). RFCs from the IETF Submissions Stream are relatively closer to the industry in comparison with an academic journal. >And different levels or kinds of review across the different streams. >This returns to the question of audiences for the streams. Vendors and >operators seem to differ quite a bit from researchers and academics >(naturally there is always overlap). The level of review is not apparent to the external reader. The breadth of review is subsumed in what the IETF describes as "consensus"; other Streams use a different "measure". The external reader is not interested in the review process. One of the intrinsic property of a RFC is availability. Another property, if I can describe it as such, is that a RFC may be viewed as authoritative. Regards, S. Moonesamy From nobody Wed Jul 11 17:20:29 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51EF130F0B for ; Wed, 11 Jul 2018 17:20:28 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 tzhBobxjPR2f for ; Wed, 11 Jul 2018 17:20:27 -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 4190F130EAE for ; Wed, 11 Jul 2018 17:20:27 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id y5-v6so3357041pgv.1 for ; Wed, 11 Jul 2018 17:20: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=m8YXKp3u/Qu73RlfRwms+oSFIA4tisV0l1etcLSy/zU=; b=Lo+f0SAAHtuzmHAzPL5+pMadpAtUJMv2Ewzgi951LQduqbhgdMwKiSbeLuqnJ30sqJ +a/JRqOiBz4vFdPVmUdx1eYY83CZDm9gos1MjPZZaJ5/mRrEZLOZqCYdxnjpQNE2xqfE qvqCyUvKkOPBYF80ZC1lSbgtVqTkkEvmLHt/J7AIE4rne+M0CrxtC0w5nIiJVKPq/mep 84L2QKEwUuTnfNRmBLBmbGHOh2tX5Dl/ZAhMb3I/FYOq9hjXOHRRDyUFu9MgYjR2iOxG thD52VxAzIpfEODK2S+814PsuvpRlC/cdLmfRopKf3q+msP6nd5PNwRzY7jYFhINsFxX 0bqw== 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=m8YXKp3u/Qu73RlfRwms+oSFIA4tisV0l1etcLSy/zU=; b=In9MHETRkbCjpfvnrvF3zTD06ftpSW0kAUfLOfFXQHO4h4IF9/xiXW9Egour87fsgB vZ16FJyq4NbEM4JHS1crrRg3Ff3dy5z9fA2K1NEoVs+bTjGeUslSxGGVCoh8a/Ht7qdt GuzBTEdXGLRNbnDKcSJNUjdCIGK6gFYJ83KDNkrigrZ5DQcjfu0Ou/2luVWv2ZWDREt5 WFMLSQtYFfKhXehoKvU+AwxVV4KaEAj2bC2qYq5elaIkkctkQt4qCD2p/fv8j+v0mjaz IZbhFuKjzM3h4wF+DvNelK3TTuyL7DtpaChiZhEMfedBZy20NUoWp6kuosODy9jIy7AI Cg3Q== X-Gm-Message-State: AOUpUlF6lg98jvyW2w/eLv0JZgEp60TNSPjaER4KnEDeD0tXzOphPiow ue+mvpV0QYblE/Vv5/K4CNJkzQ== X-Google-Smtp-Source: AAOMgpcSobLUiOP42wPctcW4oDiLn7NHnPmGtXILWC6B/Dc/wvJR2J6pMz4qPPxoYVfuNr1N9g3mLw== X-Received: by 2002:a62:5d55:: with SMTP id r82-v6mr53490pfb.150.1531354826217; Wed, 11 Jul 2018 17:20:26 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id j129-v6sm37009789pfb.113.2018.07.11.17.20.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 17:20:25 -0700 (PDT) To: S Moonesamy , Peter Saint-Andre , rfcplusplus@ietf.org References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> <6.2.5.6.2.20180711152805.07d07338@elandnews.com> From: Brian E Carpenter Message-ID: <35e8460f-7db7-98d7-7143-3aafff16b9fa@gmail.com> Date: Thu, 12 Jul 2018 12:20:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20180711152805.07d07338@elandnews.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 00:20:29 -0000 On 12/07/2018 12:04, S Moonesamy wrote: > reader is not interested in the review process. One of the intrinsic > property of a RFC is availability. Another property, if I can > describe it as such, is that a RFC may be viewed as authoritative. But falsely so, according to the boilerplate in many RFCs. However, I'm not sure this is different from academic articles: whether or not they are authoritative depends on many factors, and each reader has to make their own judgment. Being labelled "RFC", or being published in "IEEE Transactions", is only a starting point. Brian From nobody Wed Jul 11 17:47:09 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568EE130FA8 for ; Wed, 11 Jul 2018 17:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, 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 ukokilOfkRNt for ; Wed, 11 Jul 2018 17:47:05 -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 BA29E130E97 for ; Wed, 11 Jul 2018 17:47:05 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6C0l0Uf022153 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Jul 2018 19:47:02 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Brian E Carpenter , Allison Mankin , "Rfcplusplus@ietf.org" References: From: Adam Roach Message-ID: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> Date: Wed, 11 Jul 2018 19:46:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 00:47:08 -0000 On 7/11/18 6:49 PM, Brian E Carpenter wrote: > Well, that's good to hear, but nevertheless it is an IETF BOF and that > limits its direct input to IESG decision making (certainly not its > range of topics). This assertion (which you've raised before) doesn't seem to serve what I suspect your goals are very well. Based on this statement and similar statements you've made elsewhere, it looks like you're trying to assert that there is no existing venue in which the topic of multi-stream RFC governance can be discussed with the community, and so the conversation simply cannot happen. Given that the alternative would appear to be for the IAB to act without community input (or perhaps with the limited input provided by an IAB workshop), I'm not sure why you're pressing this point so hard. Not only would that kind of action set what I think would be bad precedent, but it would probably not have the outcome you desire. Or perhaps I've misunderstood: do you think that there is a venue in which multi-stream RFC governance topics can be discussed with the various stakeholders, and that this simply isn't it? /a From nobody Wed Jul 11 18:33:05 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00051130DE3 for ; Wed, 11 Jul 2018 18:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 9ZaVXQ9VPDhW for ; Wed, 11 Jul 2018 18:33:02 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB06130DD4 for ; Wed, 11 Jul 2018 18:33:00 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id j3-v6so19527636pfh.11 for ; Wed, 11 Jul 2018 18:33:00 -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=9Pgt19YtiWfrr+9c+6dtZjf9KVP1tL9wC6E7+AloVhM=; b=YxlVNPKzarMrFShHKiFHHW7YDdvRrNXa9AasatwSfzProLdqKVhV/9JtkthUQ010IJ pzX4Ai681YtFtup4GWwsw9DH1WLSnhFVE4uY8Ll5zS5841LWz2T3oo9+qLgC90ltcxTI /3BvkttlqJMIQjeA8YWoafm/gxl40AC/Ab+HcL2X5QFFQ2CkWeVa7mQ4rEDqR2feEXfF WCMLkZ1R/v28XjyxndZn80KNsbtzKsbAs/ZYF0YeCpxBnz2wbVHosjkhttZIb+IitB/A w4VeVcNX+MexREHbwlzZY1fx8Cphxt292tklX+oNCY5pB2R9d7tfRmuUP8wIQefKe7FK EUuQ== 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=9Pgt19YtiWfrr+9c+6dtZjf9KVP1tL9wC6E7+AloVhM=; b=sdaG/tFa3zZj9dYYtELXViKZhSe4Q0e+8pFkGwxIeQi8nEF9SNSPrErW1N9TqXLCuQ 7L1PZMcplcbpErwy3JIeAIDVwKbpo2rBBC3SqKzcmchONwzVFl06aZ4ILbtwdw3rcJol ByLd33O/DMmq46De97xW1I7Mi/nSQeBeXQ2CoUtaMBNp6GNdpL2mKPHX8Ivmu3dJJpwH u+9TodyC3FRQsv4R+Qvi8tHtnBMFmE3om2fdgaThcXiLEznrjfZj6Vqia5cE3jIzURjB qY84ll/WJ6jn6dpBM7Vok00j6L9JeHBFu7P1DYsq68o7CnZWZ4wSCRrl+zMVkMqN+2Rb +VBA== X-Gm-Message-State: AOUpUlFIeXeBLi011/875roWMHOtFbRbuZA2Yp061K0SpXuDSgRVfDOu C1vZP8VdpMyKxXPcz38EK+mBXA== X-Google-Smtp-Source: AAOMgpc3+9gIyEzb87c+0jbpsEldGfZ2dCMWpZGEA/Tyw4Lw51a8UT1SfxiL/7j4HDZOETn3eWgdzw== X-Received: by 2002:a63:2043:: with SMTP id r3-v6mr211257pgm.105.1531359179375; Wed, 11 Jul 2018 18:32:59 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id q28-v6sm41879142pfg.144.2018.07.11.18.32.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 18:32:58 -0700 (PDT) To: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> From: Brian E Carpenter Message-ID: <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> Date: Thu, 12 Jul 2018 13:33:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 01:33:05 -0000 On 12/07/2018 12:46, Adam Roach wrote: > On 7/11/18 6:49 PM, Brian E Carpenter wrote: >> Well, that's good to hear, but nevertheless it is an IETF BOF and that >> limits its direct input to IESG decision making (certainly not its >> range of topics). > > > This assertion (which you've raised before) doesn't seem to serve what I > suspect your goals are very well. > > Based on this statement and similar statements you've made elsewhere, it > looks like you're trying to assert that there is no existing venue in > which the topic of multi-stream RFC governance can be discussed with the > community, I'm saying that there's no clearly defined and announced venue for that, except possibly rfc-interest@rfc-editor.org. So if there are proposals that affect multiple streams or the series as a whole, there is some work to be done to ensure that all interested parties are involved. I'm not saying that's impossible, but it's more than convening an IETF BOF. > and so the conversation simply cannot happen. It can happen if planned that way. IMHO it has happened, for example, for the new RFC format, and clearly all the RFC streams were involved in formally setting up the streams some years ago. > Given that the > alternative would appear to be for the IAB to act without community > input (or perhaps with the limited input provided by an IAB workshop), > I'm not sure why you're pressing this point so hard. Not only would that > kind of action set what I think would be bad precedent, but it would > probably not have the outcome you desire. It wouldn't, because if a number of people felt that the IAB had exceeded its authority, the outcome would indeed be painful for everybody. > Or perhaps I've misunderstood: do you think that there is a venue in > which multi-stream RFC governance topics can be discussed with the > various stakeholders, and that this simply isn't it? That, yes. (Also, I don't understand why the RFC Series Oversight Committee isn't heavily involved in this discussion.) Brian From nobody Wed Jul 11 19:09:36 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC0A127332 for ; Wed, 11 Jul 2018 19:09:35 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 qMb8ZqE6Oki8 for ; Wed, 11 Jul 2018 19:09:33 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A5E130E7A for ; Wed, 11 Jul 2018 19:09:33 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id k81-v6so52933471oib.4 for ; Wed, 11 Jul 2018 19:09:33 -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=7Kjq9qXfuu4g5RCsyPCAumI+vwOxHu96Dt6OiwsIUo8=; b=hvM9PWMCw+uYj8XsF2dvBePCtCVc98bDN40+3xzYI1JMCKktY36uIHL9ZTsHNn7r4H O+Tw/eRCAnHNVtKUPwEtZwpBGpIc4ybA/0/VeoG5/9lQyEbPxGZkX1eLeIkxM/DlSDEz Zu/3fr8fafG6h3oGl9tg7RJakMNtU2S7SLo3ywmsPC4YxgHrDQnE6ssrGD1kiadcNxly Dbv+JdASIjEgOyMj1pCYW2S3oa5ZSvzQZfazif4+JQ8PWzDiT1NRWSEMcWof/ymytiro xr/kv4FJdxw9KlVNI6HEyK2Cms6ngfbL2dak7AxLhXBvps18VDdTa5REAr9+0+k7lhww BK4w== 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=7Kjq9qXfuu4g5RCsyPCAumI+vwOxHu96Dt6OiwsIUo8=; b=XQWBKIUST9KIXn4T2HVrrGMkCzxcWt2wNRTUREHmIEtdSTSU3xr5qxVPyNjkREaCKa aMW33rY/SWGw7gDyyf0KdvPzziUGnXQadASZjWkx505QFnSslFPfqDbmpTqV+Sk9ROaq PWEa4EFMwf6FBxTx6WXZbN5PnLuAAIze9P8dpEjbwku1PW/J6JvkT8anoN13QvodJQiu zhoxmMNCudDILNF0FxsTRyf9y4702eGB1FOEvkPuSA4PAChf6j5T2V0FYPaHI4j0khkV tXrfyrQloXX28BVyJEn/pRpgnlhUvw/rCQjD3S8QkA82pGlNLzvFMv09uQ1AFWSFNZHq LWPA== X-Gm-Message-State: AOUpUlGZKjxBGUkacjG/9mXCjoOLNR2afS1ozQbzqy4RIpN1fVCKFBZx 1qDlByiu/VSHpxtA22vyaeiuSrGJHs2TP9NGbL4= X-Google-Smtp-Source: AAOMgpfZuRk5aNITE5c/2RB3xLFeRSi/uEyL4fN2s81sLT6RgsNJFSbEgxIPHuOLaviEVZChiJ5UD0cZivI9sSz4gKc= X-Received: by 2002:aca:4e50:: with SMTP id c77-v6mr311046oib.254.1531361372661; Wed, 11 Jul 2018 19:09:32 -0700 (PDT) MIME-Version: 1.0 References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> <6.2.5.6.2.20180711152805.07d07338@elandnews.com> <35e8460f-7db7-98d7-7143-3aafff16b9fa@gmail.com> In-Reply-To: <35e8460f-7db7-98d7-7143-3aafff16b9fa@gmail.com> From: Martin Thomson Date: Thu, 12 Jul 2018 12:09:21 +1000 Message-ID: To: Brian E Carpenter Cc: S Moonesamy , stpeter@mozilla.com, rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 02:09:36 -0000 On Thu, Jul 12, 2018 at 10:20 AM Brian E Carpenter wrote: > On 12/07/2018 12:04, S Moonesamy wrote: > > reader is not interested in the review process. One of the intrinsic > > property of a RFC is availability. Another property, if I can > > describe it as such, is that a RFC may be viewed as authoritative. > > But falsely so, according to the boilerplate in many RFCs. However, > I'm not sure this is different from academic articles: whether or > not they are authoritative depends on many factors, and each reader > has to make their own judgment. Being labelled "RFC", or being published > in "IEEE Transactions", is only a starting point. I have come to a slightly different conclusion to this. The value of a thing that is primarily a specification derives largely from how closely it accurately describes reality. As Brian (T) observes, an academic publication might only be concerned with a superficial treatment of the subject and so there are plenty of cases where any reference will do (I theorize that this is what dramatically inflates citation counts on certain documents). For a document to be valuable beyond that simple purpose, it needs to describe reality accurately. To the extent that the IETF publishes documents that are valuable, their congruence with reality is the primary source of that value. In many cases, we don't really get to be sure about that until afterwards, because the documents are written as a promise. But one strength of our process is that the delivery on promises is pretty high. For many years, the value of certain specifications that I worked on was diminished by neglect. The draft said one thing, but practical constraints meant that you had to do something else completely. Whether that was to achieve interoperability, the expected level of security, or whatever the reason, that had the effect of undermining the credibility of those RFCs. I realize that I'm about to expand the problem scope further, but... We tend to hit more problems when we have aspirational protocol specifications. That is, protocols without a promise. We're not consistently able to distinguish between objectively good designs and designs that will be deployed, partly because that requires the use of time travel. We do better with protocols that deploy before publication, for example. This is something that discussions of the level of review don't really help with. I consider the value of the RFC series to derive primarily from its ability to accurately describe some part of the state of the Internet. Peer review in the sense of what an academic publication demands doesn't serve that goal. Current IETF processes and culture are somewhat geared toward that outcome, which is what I believe has produced this reputation. That's not necessary a shared goal across the streams. I suspect that the outcome here may depend more on whether you think that the RFC series is a venue or a descriptor. Conceived of as a journal or publication outlet, I can see how people would conclude there being no problem with the current situation. This is merely another place that you go to witness or participate in a discussion. However, as a label or descriptor, the current situation isn't ideal. From nobody Wed Jul 11 19:19:20 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDA0130E7F for ; Wed, 11 Jul 2018 19:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 iq-fmVBZachD for ; Wed, 11 Jul 2018 19:19: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 562FA130DE3 for ; Wed, 11 Jul 2018 19:19:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 432236C0BA7; Wed, 11 Jul 2018 19:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1531361956; bh=tbIufkyY1lqfeDz73HZFs/Vby1+a/x0YiTu2j5kqG/4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OMK4DbWDpI4jKg4e+w4Pn40NA/r65kiahZpGcWBeiwk+3jhsWFRceMw69iP2lkIJk ShQAA9q+5aA8kX9BA3u9MEhAsPdTACFxnVclIrhkhAm96u3QWPqPucMTrnqO/r6wJR 5vbZSiU0+UnXe7+mIiZazVr1mZAGwXOuq/T1Cu1M= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 92D106C0727; Wed, 11 Jul 2018 19:19:14 -0700 (PDT) To: Martin Thomson Cc: rfcplusplus@ietf.org, S Moonesamy , stpeter@mozilla.com References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> <6.2.5.6.2.20180711152805.07d07338@elandnews.com> <35e8460f-7db7-98d7-7143-3aafff16b9fa@gmail.com> From: "Joel M. Halpern" Message-ID: <618c78fa-c2c2-aa7d-f8e8-f0748609f438@joelhalpern.com> Date: Wed, 11 Jul 2018 22:19:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.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: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 02:19:19 -0000 At least in the areas I work in, RFCs when published describe protocols which have seen limited implementation or deployment. Even when we are revising widely deployed protocols, the revisions or enhancements have usually experienced limtitd implementation or deployment. We like to have some experience (IDR for example requires two implementations). We rarely have large numbers of vendors implementing, since most vendors wait for the document to stabilize and be published as an RFC before they implement. So I am very confused by your text describing RFCs that "describe reality". Yours, Joel On 7/11/18 10:09 PM, Martin Thomson wrote: > On Thu, Jul 12, 2018 at 10:20 AM Brian E Carpenter > wrote: >> On 12/07/2018 12:04, S Moonesamy wrote: >>> reader is not interested in the review process. One of the intrinsic >>> property of a RFC is availability. Another property, if I can >>> describe it as such, is that a RFC may be viewed as authoritative. >> >> But falsely so, according to the boilerplate in many RFCs. However, >> I'm not sure this is different from academic articles: whether or >> not they are authoritative depends on many factors, and each reader >> has to make their own judgment. Being labelled "RFC", or being published >> in "IEEE Transactions", is only a starting point. > > I have come to a slightly different conclusion to this. The value of > a thing that is primarily a specification derives largely from how > closely it accurately describes reality. As Brian (T) observes, an > academic publication might only be concerned with a superficial > treatment of the subject and so there are plenty of cases where any > reference will do (I theorize that this is what dramatically inflates > citation counts on certain documents). > > For a document to be valuable beyond that simple purpose, it needs to > describe reality accurately. To the extent that the IETF publishes > documents that are valuable, their congruence with reality is the > primary source of that value. In many cases, we don't really get to > be sure about that until afterwards, because the documents are written > as a promise. But one strength of our process is that the delivery on > promises is pretty high. > > For many years, the value of certain specifications that I worked on > was diminished by neglect. The draft said one thing, but practical > constraints meant that you had to do something else completely. > Whether that was to achieve interoperability, the expected level of > security, or whatever the reason, that had the effect of undermining > the credibility of those RFCs. > > I realize that I'm about to expand the problem scope further, but... > We tend to hit more problems when we have aspirational protocol > specifications. That is, protocols without a promise. We're not > consistently able to distinguish between objectively good designs and > designs that will be deployed, partly because that requires the use of > time travel. We do better with protocols that deploy before > publication, for example. > > This is something that discussions of the level of review don't really > help with. I consider the value of the RFC series to derive primarily > from its ability to accurately describe some part of the state of the > Internet. Peer review in the sense of what an academic publication > demands doesn't serve that goal. Current IETF processes and culture > are somewhat geared toward that outcome, which is what I believe has > produced this reputation. > > That's not necessary a shared goal across the streams. > > I suspect that the outcome here may depend more on whether you think > that the RFC series is a venue or a descriptor. Conceived of as a > journal or publication outlet, I can see how people would conclude > there being no problem with the current situation. This is merely > another place that you go to witness or participate in a discussion. > However, as a label or descriptor, the current situation isn't ideal. > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > From nobody Wed Jul 11 19:48:01 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3628A130EBD for ; Wed, 11 Jul 2018 19:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 H0sMlrx0o28T for ; Wed, 11 Jul 2018 19:47:57 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 6BB1812F1AB for ; Wed, 11 Jul 2018 19:47:57 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id 13-v6so53090194ois.1 for ; Wed, 11 Jul 2018 19:47:57 -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=61NMFlR3P5/JIFf48I53QP8NBUSUfVIIc50I9gh22cQ=; b=BAs4peNpFJdG+U8NFO3Z7EhRZSjXfxkThCVOVlXQ43Bf7nuZttDYV4sUF9DtByu8Fo 4KMWQCZ1pu2FAd8MXdpAXTH9qBvhKBk1vDpG3uHTVOwHo0pyTZfvsLqUN+n6gLupzCZo dCPCbJb98JCTG2Gymj05viFkutFVgzVNc3aGpLBDh7GjZ3d/TMdC3UUex2Tqf8rhOm0T +FrjQAjtbQoAwBqSutxjsPaENz2YC6FqChAPkAsM8l5QST9WYx/JpswUi2eNe2+xlsCm O/cFxSuR+U7G0Gj7jN4uxnN64zWS+jTPaJOWsLlJvCcDpnTJrXff6VfOtwVONfhSwbc/ qrqg== 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=61NMFlR3P5/JIFf48I53QP8NBUSUfVIIc50I9gh22cQ=; b=r0lJiyeha78TWQh7v5DZ99vdWEMC9eEVW2M1qfLtwT42tReFuf4U4ACULT96JKAH9Y 5SF91i0e0EJeKgUx3SBpOmXcc8iOHw59epAktZdYkE6IYpQ5tuelYTBRDTlg5oaZ+tdr Wzkqy2lxdD1bQCh+ik6FqJHR2GSlr0NVXZ7q/BqlCSpAegIhKQ2rxBBj9V1jL4GcJiZr Qjz+zaMF9uvplHpmGBxdzY/oMJYY7dK2/Rzp2+1KjZeDqV9x3y5KUd3hQQW6GMAkA4+Z H7awRibjHoMLXSKp2DBnpb1GZzsDkc28EHT7zzcct7J9EQiE7KYyPMY6AngXg2D/uknj Nakw== X-Gm-Message-State: AOUpUlEHYC4LI/q5USYDP/odaAqFTmsh80pipIZTvOPd5vmo6VfuIi/6 pKj8J58HN/Dk74vR30mtZFx0hhSNsXBnudy5dvM= X-Google-Smtp-Source: AAOMgpfMDP6YEBmjkO1rvKf/dOvJWGDr1U6HYjXectuhzChAppKw0ZPs9reDxOqYuXABnlnIvyViVX6FHaxCfDzwIFg= X-Received: by 2002:aca:5155:: with SMTP id f82-v6mr457343oib.272.1531363676753; Wed, 11 Jul 2018 19:47:56 -0700 (PDT) MIME-Version: 1.0 References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> <6.2.5.6.2.20180711152805.07d07338@elandnews.com> <35e8460f-7db7-98d7-7143-3aafff16b9fa@gmail.com> <618c78fa-c2c2-aa7d-f8e8-f0748609f438@joelhalpern.com> In-Reply-To: <618c78fa-c2c2-aa7d-f8e8-f0748609f438@joelhalpern.com> From: Martin Thomson Date: Thu, 12 Jul 2018 12:47:46 +1000 Message-ID: To: "Joel M. Halpern" Cc: rfcplusplus@ietf.org, S Moonesamy , stpeter@mozilla.com Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 02:48:00 -0000 On Thu, Jul 12, 2018 at 12:19 PM Joel M. Halpern wrote: > At least in the areas I work in, RFCs when published describe protocols > which have seen limited implementation or deployment. Even when we are > revising widely deployed protocols, the revisions or enhancements have > usually experienced limtitd implementation or deployment. We like to > have some experience (IDR for example requires two implementations). We > rarely have large numbers of vendors implementing, since most vendors > wait for the document to stabilize and be published as an RFC before > they implement. Yes, this is common. What we did with HTTP/2 and TLS is perhaps weird in that we deployed pretty widely well before the RFC was published. My point was that the ability for the RFC to predict and ultimately describe the reality of the Internet is grounded in either the actual deployment (ideal) or the strength of the commitment of those who participate in the process (the process you describe). That RFCs end up describing reality with a non-trivial proability means that we are moderately successful in identifying which protocols will be deployed. In other words, running code and all that. > So I am very confused by your text describing RFCs that "describe reality". From nobody Wed Jul 11 20:37:29 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97CB130EB2 for ; Wed, 11 Jul 2018 20:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZydVdGx8Wqqv for ; Wed, 11 Jul 2018 20:37:26 -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 AAEE6130EB1 for ; Wed, 11 Jul 2018 20:37:26 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6C3bN0q049178 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Jul 2018 22:37:24 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Brian E Carpenter , Allison Mankin , "Rfcplusplus@ietf.org" References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> From: Adam Roach Message-ID: Date: Wed, 11 Jul 2018 22:37:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 03:37:29 -0000 On 7/11/18 8:33 PM, Brian E Carpenter wrote: > On 12/07/2018 12:46, Adam Roach wrote: >> On 7/11/18 6:49 PM, Brian E Carpenter wrote: >>> Well, that's good to hear, but nevertheless it is an IETF BOF and that >>> limits its direct input to IESG decision making (certainly not its >>> range of topics). >> >> This assertion (which you've raised before) doesn't seem to serve what I >> suspect your goals are very well. >> >> Based on this statement and similar statements you've made elsewhere, it >> looks like you're trying to assert that there is no existing venue in >> which the topic of multi-stream RFC governance can be discussed with the >> community, > I'm saying that there's no clearly defined and announced venue for that, > except possibly rfc-interest@rfc-editor.org. The BOF was announced on that list (https://www.rfc-editor.org/pipermail/rfc-interest/2018-June/010237.html), and the IETF itself is a non-member organization, so any such interested parties are free to participate. You seem to be implying that some set of interested parties is being excluded from the conversation in some way, but I'm not sure evidence supports that position. ... > It can happen if planned that way. IMHO it has happened, for example, > for the new RFC format... The RFC format work was an IETF BOF too [1] (three, actually), and those specific BOFs resulted in input that went well beyond impacts on the IETF stream. I believe your original statement about the scope of discussions that can take place in such a venue is more refuted than supported by the precedent you cite. /a ____ [1] https://trac.tools.ietf.org/bof/trac/wiki/BofIETF83 From nobody Wed Jul 11 20:54:25 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9A5130EB7 for ; Wed, 11 Jul 2018 20:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 69WyKOrQEk_E for ; Wed, 11 Jul 2018 20:54:21 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 D0D5A130DE8 for ; Wed, 11 Jul 2018 20:54:21 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id k3-v6so3490959pgq.5 for ; Wed, 11 Jul 2018 20:54:21 -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=9LA5Zlgg6ujvL9rX6MUazMOSUAM0+8jqml0Vnq73oH0=; b=eiXpVE5Yp1QKNRmVSo5NFUw3nJVM9Yw7dEBWvot3c6P/4CvwCVWYnvnmrqYKBHQyfI VY+KhZdONi2VGX0jvi9YaPI2JO0972iuvnzi7qW4aWvNUz0Munw2WOt6R69Kg3Z7lmtg ZgTiCySHVP8PEdyabczi0q2Db3ynv9VFrEHBuBb8PN3sOSVVgLoP9C/rC+akTw9PGjKX forDJqGyiNRwT8ICUOKi5QrTHgepcIcj2xsXhSdmX1LOtjS75iWSwrd2/bRTlrdkudRm qaSqlsVp+G2feepW2Xnt4rqXCZZ4bfneCs58caaWqViS+vrLTV64ltBfSozPpX+fx4oH wR8w== 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=9LA5Zlgg6ujvL9rX6MUazMOSUAM0+8jqml0Vnq73oH0=; b=OYEuQ9Y2CLr/LZL5TIE3UWMwOAGEDHZfN80mxiu3V2rACoCeXnF+0EO0i09S44Uw+N /yKgNT4NJC036avTgS3O0CXkoYdcVU8QjjaaB+QTX/5g/0CKUl1GAGqw54llrOdOHYrD yxTpvi13etuaI/U1OReA9gMh56D8c+ZCcmWWU9geqvyv0U8Hak52q+R+PMuBoV6UI2Yt jQI6CzRT+h9waOwUl5mBSlOiZZdIaYzhVjb9iHim7d6wjG7tTaYgJvZ1Nylvq5Tz5uj+ uq8MxA0dt44ahxNWjT3r0F32mRFkb3xsQs2ulqhzZMmXsuhzENe3S6qhWF5e6IsxikOU 2UCw== X-Gm-Message-State: AOUpUlFu3dTUcRSFtWCpNQ5gIv5sqSbGQXLSXrseYKXZIjgbV4Juf2XX QemBhbkUR/ZWh/64HNEttPJmwA== X-Google-Smtp-Source: AAOMgpfUE6AKDaYozp4LOHmjnTg48J5RCYEMpD3/my8DJU+nGChUCLK43xDsqfotOQmLq/SzbK7WqQ== X-Received: by 2002:a65:6109:: with SMTP id z9-v6mr540109pgu.243.1531367661146; Wed, 11 Jul 2018 20:54:21 -0700 (PDT) Received: from [192.168.178.40] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id r188-v6sm39256942pgr.78.2018.07.11.20.54.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 20:54:20 -0700 (PDT) To: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> From: Brian E Carpenter Message-ID: <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> Date: Thu, 12 Jul 2018 15:54:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 03:54:25 -0000 On 12/07/2018 15:37, Adam Roach wrote: > On 7/11/18 8:33 PM, Brian E Carpenter wrote: >> On 12/07/2018 12:46, Adam Roach wrote: >>> On 7/11/18 6:49 PM, Brian E Carpenter wrote: >>>> Well, that's good to hear, but nevertheless it is an IETF BOF and that >>>> limits its direct input to IESG decision making (certainly not its >>>> range of topics). >>> >>> This assertion (which you've raised before) doesn't seem to serve what I >>> suspect your goals are very well. >>> >>> Based on this statement and similar statements you've made elsewhere, it >>> looks like you're trying to assert that there is no existing venue in >>> which the topic of multi-stream RFC governance can be discussed with the >>> community, >> I'm saying that there's no clearly defined and announced venue for that, >> except possibly rfc-interest@rfc-editor.org. > > The BOF was announced on that list > (https://www.rfc-editor.org/pipermail/rfc-interest/2018-June/010237.html), > and the IETF itself is a non-member organization, so any such interested > parties are free to participate. You seem to be implying that some set > of interested parties is being excluded from the conversation in some > way, but I'm not sure evidence supports that position. > > ... >> It can happen if planned that way. IMHO it has happened, for example, >> for the new RFC format... > > The RFC format work was an IETF BOF too [1] (three, actually), and those > specific BOFs resulted in input that went well beyond impacts on the > IETF stream. I believe your original statement about the scope of > discussions that can take place in such a venue is more refuted than > supported by the precedent you cite. There's a real difference, in my opinion, in that the definition of the streams was a codification of existing practice, and the format update was something people have been requesting for many years. Neither of them showed any signs of being fundamentally contentious. This time, we've seen a much more radical proposal which, if carried forward, would fundamentally change the series. In that case you can't duck the question of authority and who calls consensus. Brian From nobody Wed Jul 11 22:09:43 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE8D130E43 for ; Wed, 11 Jul 2018 22:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, 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 f4u9sjn3drmm for ; Wed, 11 Jul 2018 22:09:40 -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 7D1EB129C6A for ; Wed, 11 Jul 2018 22:09:40 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6C59cSo064292 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 12 Jul 2018 00:09:39 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Brian E Carpenter , Allison Mankin , "Rfcplusplus@ietf.org" References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> From: Adam Roach Message-ID: <77486708-e38d-03d3-f4d0-0f0b67797542@nostrum.com> Date: Thu, 12 Jul 2018 00:09:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 05:09:42 -0000 On 7/11/18 10:54 PM, Brian E Carpenter wrote: > On 12/07/2018 15:37, Adam Roach wrote: > ... >> The RFC format work was an IETF BOF too [1] (three, actually), and those >> specific BOFs resulted in input that went well beyond impacts on the >> IETF stream. I believe your original statement about the scope of >> discussions that can take place in such a venue is more refuted than >> supported by the precedent you cite. > There's a real difference, in my opinion, in that the definition of > the streams was a codification of existing practice, and the format > update was something people have been requesting for many years. > Neither of them showed any signs of being fundamentally contentious. Your understanding of the potential, in the IETF 83 timeframe, for controversy around the RFC format change is completely different than mine. I recall the issue coming up repeatedly at plenaries and in hallways with well more than a hint of contention surrounding it. We are free to disagree on our recollections here, of course, but if you check the minutes for the administrative plenary at IETF 79 -- a scant four meetings before the RFCFORM BOF -- Stewart Bryant used the phrase "this is a controversial subject" to describe this exact topic. The benefit of time between now and then may make it seem far less so in 2018, but that has little bearing on the fact that it *was* expected to be controversial by many at the time. > This time, we've seen a much more radical proposal which, if carried > forward, would fundamentally change the series. In that case you can't > duck the question of authority and who calls consensus. It feels like you're trying to move the goalposts. Your original statement was that this is "an IETF BOF and that limits its direct input to IESG decision making." If I carefully parse what you've written above, it seems that you want to amend that to only apply when some (potentially small) subset of the IETF population thinks it won't be contentious, but that doesn't seem quantifiable enough to be a rule. /a From nobody Wed Jul 11 22:40:54 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85BD131066 for ; Wed, 11 Jul 2018 22:40:51 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 2NN6U4DDdNiG for ; Wed, 11 Jul 2018 22:40:48 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 C83AB131072 for ; Wed, 11 Jul 2018 22:40:48 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id e6-v6so3570592pgv.2 for ; Wed, 11 Jul 2018 22:40: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=F6rz6fzCs+IaarMchzNZw82LUaZPBmbbHNbTgbwou74=; b=Potwy4OrsCCVOLRLaH3kvfbly2q5+hEwD01wE/BM7AFAek/Tq4pFf64+L51ZR8wxZ3 QlvFczuXIVcO/gJ1aO2u1yNLUhUlwFBUwFgd78bwLwIdZ18wH9Gl4Y3NVbg0/kwkxhtR BkAPge0E52NEcPz2JZF6uVTXvaNLObqGQM3OIXpb2L30FPmVeNizt1uCUBHrEa4AGciM lABRfnlYG3VW4qNstjdZ9xxGM2TffYTdyhNJ5Vu6OZ9lWlOcVTUCOaSjXDyvkHzf797Z t0/wHPjjVbOp4wf8sQ7YyiXf2n8jI/YrrHSfKOO67zqeJlaG+cSnLWybsDu424v66Eya dBsA== 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=F6rz6fzCs+IaarMchzNZw82LUaZPBmbbHNbTgbwou74=; b=SQdqn0SJYnDvfGgxyqXvhNTwbe7GagoF/xDevb6r0NgiRb30cN9fdyVdHJL6eUMNp7 xLJS/FlDN3Ye24+V6Yb2sST/Lu97IhwhpzYg8YiU+RAv+cw/J1GR7fHsztTuJASwv90i HyQPjezbyrrC7rAhUhv2wnV8iqZjSacWSUCsmbWiG4EggDlW1ooAql6I53kPUbcR6RLO hX4VTgTXrATDRD0f4WI6t7JMZFPLmRETeyTXB4wAOKkfbrhm/tWjYRv7pCRwT/pT3Tnx GjeCgOtIfb8EHgy3iUYk9lUuY1PtFrIAvdiOJ3Ga9Fjz7luDQXOXGpSx+eNSIgt0H0wY QJww== X-Gm-Message-State: AOUpUlFJDF5ykbb9s9uM/bIoUN+QtHrKQbUhmmELYDZP5W0BuHsSm2ag Q3uJ7Hz4KMjAYsl3a7fi/8Z36w== X-Google-Smtp-Source: AAOMgpfyzz4YCsHWWLMFjYo6dNi44sCHReNQfBpFZukvNt1ExgLvuixFKOXygDEX3zt+PWNeWxmX4A== X-Received: by 2002:a63:6e07:: with SMTP id j7-v6mr800052pgc.251.1531374048106; Wed, 11 Jul 2018 22:40:48 -0700 (PDT) Received: from [192.168.178.40] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id g15-v6sm28677649pfg.98.2018.07.11.22.40.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 22:40:47 -0700 (PDT) To: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> <77486708-e38d-03d3-f4d0-0f0b67797542@nostrum.com> From: Brian E Carpenter Message-ID: Date: Thu, 12 Jul 2018 17:40:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <77486708-e38d-03d3-f4d0-0f0b67797542@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 05:40:53 -0000 On 12/07/2018 17:09, Adam Roach wrote: > On 7/11/18 10:54 PM, Brian E Carpenter wrote: >> On 12/07/2018 15:37, Adam Roach wrote: >> ... >>> The RFC format work was an IETF BOF too [1] (three, actually), and those >>> specific BOFs resulted in input that went well beyond impacts on the >>> IETF stream. I believe your original statement about the scope of >>> discussions that can take place in such a venue is more refuted than >>> supported by the precedent you cite. >> There's a real difference, in my opinion, in that the definition of >> the streams was a codification of existing practice, and the format >> update was something people have been requesting for many years. >> Neither of them showed any signs of being fundamentally contentious. > > Your understanding of the potential, in the IETF 83 timeframe, for > controversy around the RFC format change is completely different than > mine. I recall the issue coming up repeatedly at plenaries and in > hallways with well more than a hint of contention surrounding it. > > We are free to disagree on our recollections here, of course, but if you > check the minutes for the administrative plenary at IETF 79 -- a scant > four meetings before the RFCFORM BOF -- Stewart Bryant used the phrase > "this is a controversial subject" to describe this exact topic. The > benefit of time between now and then may make it seem far less so in > 2018, but that has little bearing on the fact that it *was* expected to > be controversial by many at the time. The details, for sure, and I am 100% certain that when the new format and its tools are released there will be much noise too. But I really see this as a fundamentally different type of controversy and proposed change. If you don't agree, we'd better agree to differ. >> This time, we've seen a much more radical proposal which, if carried >> forward, would fundamentally change the series. In that case you can't >> duck the question of authority and who calls consensus. > > It feels like you're trying to move the goalposts. Your original > statement was that this is "an IETF BOF and that limits its direct input > to IESG decision making." If I carefully parse what you've written > above, it seems that you want to amend that to only apply when some > (potentially small) subset of the IETF population thinks it won't be > contentious, but that doesn't seem quantifiable enough to be a rule. No, I'm not trying to move goalposts (although where they are is still unclear to me). I'm trying to say that the IETF, and its leadership, if they reach a consensus that changes *non-IETF* usage of the RFC series, simply can't impose that. What the IETF could do, if such was the consensus, is take that consensus to the rest of the RFC-producing community and ask whether they agree, or have modifications to propose, or disagree totally. It seems to me that the goal posts for reaching consensus in the IETF are fairly well known, and some of us will end up in the rough as always. But for the RFC-producing community as whole, I currently have no idea where the goal posts are. To quote my draft "How to reach out to this community is in itself a big question." Regards Brian From nobody Wed Jul 11 23:26:19 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750CC131060 for ; Wed, 11 Jul 2018 23:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_U7-c8klkCI for ; Wed, 11 Jul 2018 23:26: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 DBD9E131066 for ; Wed, 11 Jul 2018 23:26:14 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6C6QC2Q076954 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 12 Jul 2018 01:26:12 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Brian E Carpenter , Allison Mankin , "Rfcplusplus@ietf.org" References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> <77486708-e38d-03d3-f4d0-0f0b67797542@nostrum.com> From: Adam Roach Message-ID: <3d659e94-8455-f7c4-98a8-405bfda728c6@nostrum.com> Date: Thu, 12 Jul 2018 01:26:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 06:26:18 -0000 On 7/12/18 12:40 AM, Brian E Carpenter wrote: > No, I'm not trying to move goalposts (although where they are is still > unclear to me). We appear to be talking past each other, and for that I apologize. I used non-literal language that assumed a shared cultural context, and that's bad form on my part. I meant the term "moving the goalposts" as a reference to the informal logical fallacy [1], not some metaphor regarding reaching consensus or finding interested participants. > But for the RFC-producing community as whole, I currently have no idea > where the goal posts are. To quote my draft "How to reach out to this > community is in itself a big question." It's not exactly tenable to hypothesize some unidentifiable group of uncontacted peoples with an interest in the topic and conclude that things must stay now just as they ever have been as a consequence. That rationale would have blocked the format work as well. We allowed the rfc-interest mailing list to stand in as a proxy for that community in that case -- it would be inconsistent to claim that we can't use it in this one. /a ____ [1] https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/129/Moving-the-Goalposts From nobody Wed Jul 11 23:26:44 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72969131062 for ; Wed, 11 Jul 2018 23:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VUv2Gp2HRcn for ; Wed, 11 Jul 2018 23:26:40 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C717A131060 for ; Wed, 11 Jul 2018 23:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5366; q=dns/txt; s=iport; t=1531376800; x=1532586400; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=9XG2gqCCXU/RTPQzgYFaXkx/m+Jy28C1C7RD2YJeUKo=; b=irbleSkJ2J9bS6/pjiXYWGfVYr7/1FC+/47PhyumWJoLbGa7PESilNPL WyNeOwM3R2p4mv96JbBejQaGAZIEHd7SXNtQFAzRDz5Y3wX9I2+AmbQ2Q cY92BomH6C3acj9tXaysu0Uuhpg9p9vxpJsW5xuydAYTP9mWEv5GplANC Y=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQBK80Zb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQsbRIog3qIY40/JHWWNwgDhGwCgl44FAECAQECAQECbSi?= =?us-ascii?q?FNgEBAQECASNWBQsLGCoCAlcGAQwGAgEBgxwBgXcIqWSBLoo1D4sUgRAnDII?= =?us-ascii?q?pNYRUgyiCVQKZVwmDXYFZiWsGiBmFSJISgVghgVIzGggbFYMkgiUXjhk9MIo?= =?us-ascii?q?egkgBAQ?= X-IronPort-AV: E=Sophos; i="5.51,341,1526342400"; d="asc'?scan'208"; a="5061617" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2018 06:26:37 +0000 Received: from [10.61.194.177] ([10.61.194.177]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w6C6QbTL029664; Thu, 12 Jul 2018 06:26:37 GMT To: Martin Thomson , "Joel M. Halpern" Cc: stpeter@mozilla.com, rfcplusplus@ietf.org, S Moonesamy References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> <6.2.5.6.2.20180711152805.07d07338@elandnews.com> <35e8460f-7db7-98d7-7143-3aafff16b9fa@gmail.com> <618c78fa-c2c2-aa7d-f8e8-f0748609f438@joelhalpern.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <920ccbac-dbd2-7956-fb51-287f757bc157@cisco.com> Date: Thu, 12 Jul 2018 08:26:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u9jtES2F8Gwno2H5CqsCm2ohQadSCcS3j" Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 06:26:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u9jtES2F8Gwno2H5CqsCm2ohQadSCcS3j Content-Type: multipart/mixed; boundary="JfKQJ1MVg3tz4RWYkG8nnr6UTM3b2FAUk"; protected-headers="v1" From: Eliot Lear To: Martin Thomson , "Joel M. Halpern" Cc: stpeter@mozilla.com, rfcplusplus@ietf.org, S Moonesamy Message-ID: <920ccbac-dbd2-7956-fb51-287f757bc157@cisco.com> Subject: Re: [Rfcplusplus] Conversation as metaphor References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> <6.2.5.6.2.20180711152805.07d07338@elandnews.com> <35e8460f-7db7-98d7-7143-3aafff16b9fa@gmail.com> <618c78fa-c2c2-aa7d-f8e8-f0748609f438@joelhalpern.com> In-Reply-To: --JfKQJ1MVg3tz4RWYkG8nnr6UTM3b2FAUk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 12.07.18 04:47, Martin Thomson wrote: > On Thu, Jul 12, 2018 at 12:19 PM Joel M. Halpern = wrote: >> At least in the areas I work in, RFCs when published describe protocol= s >> which have seen limited implementation or deployment. Even when we ar= e >> revising widely deployed protocols, the revisions or enhancements have= >> usually experienced limtitd implementation or deployment. We like to >> have some experience (IDR for example requires two implementations). = We >> rarely have large numbers of vendors implementing, since most vendors >> wait for the document to stabilize and be published as an RFC before >> they implement. > Yes, this is common. What we did with HTTP/2 and TLS is perhaps weird > in that we deployed pretty widely well before the RFC was published. In interdisciplinary work of some form, the standard is really a starting gun for implementation.=C2=A0 Also true when purchasing managers= are looking for a combination of interoperability and stability. > My point was that the ability for the RFC to predict and ultimately > describe the reality of the Internet is grounded in either the actual > deployment (ideal) or the strength of the commitment of those who > participate in the process (the process you describe). That RFCs end > up describing reality with a non-trivial proability means that we are > moderately successful in identifying which protocols will be deployed. Yes.=C2=A0 This goes to a rule that Brian Kantor of UCSD laid out very ea= rly on (1992ish) with the series: RFCs provide their greatest utility when they document existing practice (yes, he predated Clark on that).=C2=A0 I= would point out that value can be found in the independent stream and in what we label "Informational" documents that contain specifications perhaps as often as can be found in nascent standards.=C2=A0 Good example= s from the past include IAX, NFS, syslog, PGP, BGP4, and MPLS-VPNs.=C2=A0 Perhaps today Chacha20,=C2=A0=C2=A0 Arguably all of these were de facto s= tandards long before the IETF touched them (so was IPv4). At a cursory level that would argue for labeling not based on whether something has achieved rough consensus in the IETF, but rather based on how well fielded an approach is.=C2=A0 That would require two things: a measure of adoption, something we have greatly struggled with in the past, and relabeling from time to time.=C2=A0 Imagine for a moment, charg= ing the RFC Editor with establishing such a methodology for ALL documents.=C2= =A0 Now that would really get interesting ;-)=C2=A0 STD was *sort of* intende= d to cover this ground, but it is very coarse grain, and requires a very high bar, and to me has somewhat more political connotations for us than is any real signal to a market. Eliot --JfKQJ1MVg3tz4RWYkG8nnr6UTM3b2FAUk-- --u9jtES2F8Gwno2H5CqsCm2ohQadSCcS3j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltG9JwACgkQh7ZrRtnS ejOePggAzwFnUwYDWhn8QycwtD0rLpgXDuldxcWODMcEipo0b7lwOCdkL3ijjKNR JSkUEAfBx5GSZVCPuRKTuF7yc88uvjHajqzO0aGVIvW5Ic8hoDBAp3orCc3fndsF rEMiPCYpycsM9hqBNH/CGsChmpmPwxYAcrV5BTPut5kt3Tey6hVuu9W8uzFP+okN b8Z7eSc2vW9yn1QAnKps+wIpHTwbmnQHfaTgifIEMFqy43shBDkMpzrSTQOa9Rrs xTzl0XM0mdiCfVwWNhH1T1QMKfFZYsYhOR8bxSe0Un4xj39XiyE83twt0lIa4hzi YyUxXeFsDu7tBSrecUEzw68ZBExu8A== =yoxv -----END PGP SIGNATURE----- --u9jtES2F8Gwno2H5CqsCm2ohQadSCcS3j-- From nobody Thu Jul 12 02:13:46 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289B212F1A2 for ; Thu, 12 Jul 2018 02:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=uyvB/YCZ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=oHDcOgXC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6lZ8pdj7eJt for ; Thu, 12 Jul 2018 02:13:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D04130ECE for ; Thu, 12 Jul 2018 02:13:41 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.224.109.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id w6C9DRkx018557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2018 02:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1531386819; x=1531473219; bh=GfHLJ42G2S9+GoLyTYDpdi/LUucdZnwjbB2SaJ68vF0=; h=Date:To:From:Subject:In-Reply-To:References; b=uyvB/YCZTM19GkDttCLCuWMATSWLC8oDZUj/JI2AoBIoBhzrRLysI5hlJyhSMWOzT TX5UGMLHrVjlArBP6Fwxn3q7Ypk0JoNO0y2vyfw4QbbUa8RMkYO7rUwhVpj9c4M8SV ytCr85WyhsjorjBrVUUBvN7wroijGWhfL3jKhldc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1531386819; x=1531473219; i=@elandsys.com; bh=GfHLJ42G2S9+GoLyTYDpdi/LUucdZnwjbB2SaJ68vF0=; h=Date:To:From:Subject:In-Reply-To:References; b=oHDcOgXCFSRv6WiwrzcuXdW4EKLYbmkxo7ICJHGbXvdArhJbxNon7HKa+M2rdGzY+ dYN2MIhLUQs79FtQZzhwhXsxDONf4/Ml76v6FIVT6L642ArcWbSw74UCgsDzoQMB0T WRImR2RSXkGisIDC2STx4onLX2UGtyn354cHrv5E= Message-Id: <6.2.5.6.2.20180712014944.0b718b40@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Jul 2018 02:13:12 -0700 To: "Joel M. Halpern" , Martin Thomson , Peter Saint-Andre , rfcplusplus@ietf.org From: S Moonesamy In-Reply-To: <618c78fa-c2c2-aa7d-f8e8-f0748609f438@joelhalpern.com> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> <6.2.5.6.2.20180711152805.07d07338@elandnews.com> <35e8460f-7db7-98d7-7143-3aafff16b9fa@gmail.com> <618c78fa-c2c2-aa7d-f8e8-f0748609f438@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 09:13:45 -0000 Hi Joel, Martin, Peter, At 07:19 PM 11-07-2018, Joel M. Halpern wrote: >At least in the areas I work in, RFCs when published describe >protocols which have seen limited implementation or >deployment. Even when we are revising widely deployed protocols, >the revisions or enhancements have usually experienced limtitd >implementation or deployment. We like to have some experience (IDR >for example requires two implementations). We rarely have large >numbers of vendors implementing, since most vendors wait for the >document to stabilize and be published as an RFC before they implement. > >So I am very confused by your text describing RFCs that "describe reality". The conversation is getting back to what was known as (IETF) Proposed Standard. The audience (re. Peter's comments} is vendors which have not participated in the review process as they are better placed to determine whether the specification can be clearly understood. There is also the deployment angle, i.e. the practices are determined by the people running operations. Regards, S. Moonesamy From nobody Thu Jul 12 08:58:25 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2305130EA7 for ; Thu, 12 Jul 2018 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 Or1fDUWeG1jj for ; Thu, 12 Jul 2018 08:58:19 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98FF130DED for ; Thu, 12 Jul 2018 08:58:19 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id 13-v6so56729388ois.1 for ; Thu, 12 Jul 2018 08:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eGDQ1wzDxex2YnPbXwQq01ie6usqK3ArQsXn997ozEo=; b=qEP+owuOcw4+gbNq0Oc5K2d87tBS+IennKI5jBdz4SNk8OLOvWwhHQwp/IgZJtGDvW lNalDU8GHUs9MDlHGDzZtVv+pZ6LAe+B0t4Kts1rXH7s+2NWQhuTCLff0L+dOgGgKY2a TAeCXkbIb67kniw1mRxNMvG5ajf95Jt9aKikY5F0rC65otAeNk7A1QWDFVoCfczW/kcB Sr0sWlBmkWAKAo7earv0HyAMGdFlK9Bl2DLqKP4AM5YlosSL5pCrTvEL7TnIvVe3N5UW zCYuEe2j9ywmj1KQGAgd5Itvi2VzDo7+O05yGSO9KDJWC+iFpyc2OsoYXeB84eG7S8BI NURA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eGDQ1wzDxex2YnPbXwQq01ie6usqK3ArQsXn997ozEo=; b=IoPqnfNtLtMTkRsNTKsPCUlWSwlJiyedoJzJ8h5nzAORFu42+2oUUi9syaxa0X0iwj m5/lWsT8bvecZzJAvRAbtu5zj9XDHDODLFF5Bc3wAvLj8YLjoAily6/WyiqcGbYX9cFs bNVTkIk6Hjq3QxWIPEEhJl+K8+HptL4M0Pp2C0JXCi+6rV5ckn+8WyVdMi7CEnl+YoRn 2HJLatX9SIAkAo2pgFXisRo3AJ9fy5xZnqhci3zV0bmSzf31eoZJ+cnEhUQmiU60FN2x W445oS8KK+rS+iKeJ2FUwC3P7XO1cbYwaQUk0Rh5NfiIP1pLmf5tQW8YqA212C+FOYZA uI6A== X-Gm-Message-State: AOUpUlGy2hPTmKvJseh4tv9DOJCEMBOHK7syFBtiCvOevsKTFj0ZOo+/ 57Mt05iY8/gOxjqpwx/lWkoiji+HtsESYtdmIEQ= X-Google-Smtp-Source: AAOMgpdOnxqFiH7S+fgbpyyymhKdr8lXcBTg8SSiFQumXiYItfgXAZUgAci7sly8qwSouVtXIhzE0sC5BU3qGPzOiMI= X-Received: by 2002:aca:603:: with SMTP id 3-v6mr3108460oig.103.1531411098952; Thu, 12 Jul 2018 08:58:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 08:57:47 -0700 (PDT) In-Reply-To: <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> From: Ted Hardie Date: Thu, 12 Jul 2018 08:57:47 -0700 Message-ID: To: Brian E Carpenter Cc: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008eeb330570cf6ee1" Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 15:58:23 -0000 --0000000000008eeb330570cf6ee1 Content-Type: text/plain; charset="UTF-8" Slightly off-topic, but perhaps important On Wed, Jul 11, 2018 at 8:54 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > There's a real difference, in my opinion, in that the definition of > the streams was a codification of existing practice, and the format > update was something people have been requesting for many years. > Neither of them showed any signs of being fundamentally contentious. > I'm not sure what you mean by "fundamentally contentious", but both proposals had many months of discussions and, in some parts, quite serious opposition. Contentious would have been a word I would personally have used to describe the format update, for example, and I'm not sure why you would disagree. This time, we've seen a much more radical proposal which, if carried > forward, would fundamentally change the series. In that case you can't > duck the question of authority and who calls consensus. > > I'll note that the proposed experiment borrows many elements of the format discussion's process. While there is no question that the final format documents were published by the IAB, the face-to-face discussions were all hosted at IETF plenary meetings, for the same reason: it's the place where the largest number of stream contributors are together at the same place and the same time. It also borrows the rollback method inherent in the format proposal (double RFC publication, first with trial format, then with final format). If you have other methods in mind that would produce more transparent discussion or more opportunity to test the results as we go, I'd personally be interested in hearing them. But this BoF follows the pattern we have used recently, at least to my eyes. regards, Ted > Brian > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --0000000000008eeb330570cf6ee1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Slightly off-topic, but perhaps important
On Wed, Jul 11, 2018 at 8:54 = PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
There= 9;s a real difference, in my opinion, in that the definition of
the streams was a codification of existing practice, and the format
update was something people have been requesting for many years.
Neither of them showed any signs of being fundamentally contentious.

I'm not sure what you mean by "fundamenta= lly contentious", but both proposals had many months of discussions an= d, in some parts, quite serious opposition.=C2=A0 Contentious would have be= en a word I would personally have used to describe the format update, for e= xample, and I'm not sure why you would disagree.

This time, we've seen a much more radical proposal which, if carried forward, would fundamentally change the series. In that case you can't<= br> duck the question of authority and who calls consensus.


I'll note that the proposed experiment borrows m= any elements of the format discussion's process.=C2=A0 While there is n= o question that the final format documents were published by the IAB, the f= ace-to-face discussions were all hosted at IETF plenary meetings, for the s= ame reason:=C2=A0 it's the place where the largest number of stream con= tributors are together at the same place and the same time.=C2=A0 It also b= orrows the rollback method inherent in the format proposal (double RFC publ= ication, first with trial format, then with final format).=C2=A0 If you hav= e other methods in mind that would produce more transparent discussion or m= ore opportunity to test the results as we go, I'd personally be interes= ted in hearing them.=C2=A0 But this BoF follows the pattern we have used re= cently, at least to my eyes.

regards,
Ted


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

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus

--0000000000008eeb330570cf6ee1-- From nobody Thu Jul 12 09:45:16 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658F1130EE7 for ; Thu, 12 Jul 2018 09:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 cgo8_hnI6Ypi for ; Thu, 12 Jul 2018 09:45:11 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68BC0130E89 for ; Thu, 12 Jul 2018 09:45:11 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id u21-v6so15767485qku.2 for ; Thu, 12 Jul 2018 09:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=9QkbqjIRNUfg6Ce6QjcgeF34sLha+ROFpLH2RVmOEWo=; b=GQnY8i0eGzbIQoaAl34CC9UnuApn4zg9piMXhCKwjyzy3WSRC3bx7x6Cfs/+cw0n87 dFNZpVXncVowbI0Sk5kYSHv9cnEy7shSaLWZEwk5pH0dczzRjq4oOdNsDzHpP0WvZpYu KIU/n8d1tlB/uq3S4k5JKxDHCP+GsiS9OoVGhEQrFhX2U+Qd7+vZbMdYjQ720GEo2L/C U3/Czr1+U7Me8pk+FBsIDOvjjqJ3PC9giwXaqNffPcAD3zpHNqKZOjIUw4s/vEXGd6Bk jlqdPSbq1jtzeQlOPpVkwyok15GOlMOs5H6PmoJD8pN1BD1AcHYMvmYeDHMF1RJpS0ql xIOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=9QkbqjIRNUfg6Ce6QjcgeF34sLha+ROFpLH2RVmOEWo=; b=S1+G42Z3B32z8yGIVmmzm0i9lp1ANF4jVuyAZskJwBQRCmcyG70LWmnP9mzK4oNh/S pIsnd8sCVHgK3Za2FQjqMUdNvxPKueJs11teedwZIa2Xp5hZa0vaK0OcsPMGX2qCgSJW Syb0B0lhgAHX9gJ2BZhRIekZOj/wPM5zuwed0DqUAx4u4TCS1fFxgvuwGBlzvvSK4RdH IgfPGO8vMOScCq559EgOTBOcNSEHIrOzxplQMZLvES5uBEtVbg6LOClie1NkANd1pQxp MZqppuEauUxOQ+MCwjcExBYzDjBIhSaJ4a5B6Z7TXtGzAI6YdOIs4eDLWextTBJXjVm2 LWcA== X-Gm-Message-State: AOUpUlE4xqZtmdPuSjv9WcIENFNZvAqDti2z/2dbuOrTZdn1oLpZ1UPc A7/yRbY2Rdq9SGyn85y6mU+Pmm7r X-Google-Smtp-Source: AAOMgpdgMZBLUK7lLkyMqvWxyxp6gI1x1nAB8PNJhPBi6n2Uarvyovg1V+SiCsBRXiqAZw67dotnQA== X-Received: by 2002:a37:70c1:: with SMTP id l184-v6mr2577402qkc.86.1531413910367; Thu, 12 Jul 2018 09:45:10 -0700 (PDT) Received: from [172.19.37.142] ([2001:4878:a000:3000:1d92:69fa:2c62:7bf0]) by smtp.gmail.com with ESMTPSA id u10-v6sm19912250qki.6.2018.07.12.09.45.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 09:45:09 -0700 (PDT) From: "Aaron Falk" To: "Eliot Lear" Cc: "Martin Thomson" , "Joel M. Halpern" , rfcplusplus@ietf.org, "S Moonesamy" , stpeter@mozilla.com Date: Thu, 12 Jul 2018 12:44:45 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: <920ccbac-dbd2-7956-fb51-287f757bc157@cisco.com> References: <20180710192810.GQ20282@mx4.yitter.info> <0e127473-902a-2421-6b5d-73f9e7f83286@juniper.net> <20180710204512.GT20282@mx4.yitter.info> <3e8272be-50fb-113b-fd6f-a5850d668472@mozilla.com> <6.2.5.6.2.20180711100739.0bc10fe0@elandnews.com> <0e28a2e9-d20d-5946-405a-e5c508ab590b@mozilla.com> <6.2.5.6.2.20180711152805.07d07338@elandnews.com> <35e8460f-7db7-98d7-7143-3aafff16b9fa@gmail.com> <618c78fa-c2c2-aa7d-f8e8-f0748609f438@joelhalpern.com> <920ccbac-dbd2-7956-fb51-287f757bc157@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4FD7C1E3-422C-4BCA-8C14-74C57A4528E9_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfcplusplus] Conversation as metaphor X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 16:45:14 -0000 --=_MailMate_4FD7C1E3-422C-4BCA-8C14-74C57A4528E9_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 12 Jul 2018, at 2:26, Eliot Lear wrote: > At a cursory level that would argue for labeling not based on whether > something has achieved rough consensus in the IETF, but rather based > on > how well fielded an approach is.  That would require two things: a > measure of adoption, something we have greatly struggled with in the > past, and relabeling from time to time. Elliot! This seems to me to be very interesting, useful, and difficult. (YMMV, of course) MAPRG is touching on some aspects of this. --aaron --=_MailMate_4FD7C1E3-422C-4BCA-8C14-74C57A4528E9_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">On 12 Jul 2018, at 2:26, Eliot Lear wrote:

At a cursory level that would argue= for labeling not based on whether
something has achieved rough consensus in the IETF, but rather based on how well fielded an approach is.=C2=A0 That would require two things: a measure of adoption, something we have greatly struggled with in the
past, and relabeling from time to time.

Elliot! This seems to me to be very interest= ing, useful, and difficult. (YMMV, of course) MAPRG is touching on some = aspects of this.

--aaron

--=_MailMate_4FD7C1E3-422C-4BCA-8C14-74C57A4528E9_=-- From nobody Thu Jul 12 15:50:14 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523C41311F6 for ; Thu, 12 Jul 2018 15:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 qG-Jm-tk0hh8 for ; Thu, 12 Jul 2018 15:50:10 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246651311E7 for ; Thu, 12 Jul 2018 15:50:10 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id b17-v6so21438112pfi.0 for ; Thu, 12 Jul 2018 15:50: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=cVdQEVQY5VibQkIB1VdtHrGshWpKQaFxvKejAKyedmw=; b=buGVS4I51YkuA7JqkEfDIgQ0JAb5GGypAaRWcgp63yVJGLxmj83xkbuaI+FDhwkL4N chmyUiBqbSeAa/IScZKAzRl6fDjIffMo4bodhyq1kY2WJZUR81oibkGjIjtqeXQ5ml/d 0750JPI0hAnWk2xfWVdSAyb+qy31QLKDhnG0iVGMCJgG6iNf9zR0RqBH+JBO5tz6hj/C pwoIWnMxIVtmkVGvQvFC22yurqXsHXkIIqCQnbyAerreWOmjmsByHUc5FG+tcts4yJsj /I7ZrtB86IKbWtA9Vp8uO9061m17sJ2QvWkaPqLQ/I9mACrFH4K48mpfbUj45JNA+DmF IvUA== 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=cVdQEVQY5VibQkIB1VdtHrGshWpKQaFxvKejAKyedmw=; b=ATOEJtaGHndAzzEGwQPKhzObWMhlIy90pFShzFQ0nLrRwACTXPK8f7OV2VNT/UPZzI NUuLgsyltM2+uDsn5+1a1QTe7Iyw+GKGokgviOs4SypOftMP3Wpn3iYgoODMxw27RjiU vT41LsHkeHkS/WHnJryPaAC45UC227SHNkarTDZe5SsLfeOnM4z8zs2Y3Mldn+sPzf8e BLS8PzUpzsU5Sx/VGWHAPabahAgvFw5Sn7Dz0T/8OIFCTvsdHdh38ADGriERCODxdyH/ grLT9GBZUqLusamY5nhPxdLe+cbzEtMrvyxxcOhydpfvq4yR8T5MUjTO5324815h2piq OEaA== X-Gm-Message-State: AOUpUlH3I2aFDsBidxVBpZdO2GeAvctZzAiGFkaxfoou+eeEWaxyvCM1 mHlsSldAuPWJvFHrxDQH+n6mDA== X-Google-Smtp-Source: AAOMgpd6DAvhLCS2APvpZDvIM0NOCl3+L2xWgt0nge82fcftE7byaClTzu1pcTUfqNNQGNKdr/SAFA== X-Received: by 2002:a65:45cc:: with SMTP id m12-v6mr3755061pgr.160.1531435809261; Thu, 12 Jul 2018 15:50:09 -0700 (PDT) Received: from [192.168.178.40] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id e2-v6sm2940298pgo.92.2018.07.12.15.50.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 15:50:08 -0700 (PDT) To: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> <77486708-e38d-03d3-f4d0-0f0b67797542@nostrum.com> <3d659e94-8455-f7c4-98a8-405bfda728c6@nostrum.com> From: Brian E Carpenter Message-ID: <06ac0cc7-85e6-135d-1332-cd2e75d4640f@gmail.com> Date: Fri, 13 Jul 2018 10:50:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3d659e94-8455-f7c4-98a8-405bfda728c6@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 22:50:13 -0000 On 12/07/2018 18:26, Adam Roach wrote: > On 7/12/18 12:40 AM, Brian E Carpenter wrote: >> No, I'm not trying to move goalposts (although where they are is still >> unclear to me). > > We appear to be talking past each other, and for that I apologize. I > used non-literal language that assumed a shared cultural context, and > that's bad form on my part. I meant the term "moving the goalposts" as a > reference to the informal logical fallacy [1], not some metaphor > regarding reaching consensus or finding interested participants. Understood, but sometimes, when you reach an initial conclusion, another difficulty then appears. That isn't so much moving the goalposts as discovering new goalposts further along. >> But for the RFC-producing community as whole, I currently have no idea >> where the goal posts are. To quote my draft "How to reach out to this >> community is in itself a big question." > > It's not exactly tenable to hypothesize some unidentifiable group of > uncontacted peoples with an interest in the topic and conclude that > things must stay now just as they ever have been as a consequence. No, and that wasn't at all what I intended to imply. What I mean is that *if* the IETF decides, by its own process, that the IETF wants to make a change, *then* the next stage must be a serious effort to discuss it with the rest of the community. Currently, we don't have a clear method for that. (fwiw, I would like to see some changes - but not the one implied by draft-thomson-rfcplusplus-label-00). ((fwiw, I'm now very close to entering radio silence until I reach Monteal)) Brian > That > rationale would have blocked the format work as well. We allowed the > rfc-interest mailing list to stand in as a proxy for that community in > that case -- it would be inconsistent to claim that we can't use it in > this one. > > /a > > ____ > [1] > https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/129/Moving-the-Goalposts > > . > From nobody Thu Jul 12 16:00:52 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2118130FBD for ; Thu, 12 Jul 2018 16:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 WOXh5CIIVKNg for ; Thu, 12 Jul 2018 16:00:47 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84D11311FF for ; Thu, 12 Jul 2018 16:00:47 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id e6-v6so4338927pgv.2 for ; Thu, 12 Jul 2018 16:00:47 -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=xZLxKYDu97dxnj2AtLr98pj1IcJJ/kcroor0ywrlqWw=; b=n2NbG38uAwX/APiG9bDq3Efkd/rvwgILXWRHtojer0X01+3YlJsQgSjD+jC1yU9VC1 jl9XPDHl6E6sQHBJkAVNg0y4sgZcQkOgtOwhNIJygg+B4UL1Pe+2V+KLb48SE4Tn2sFe gCgaqLPPIaHW7ER7NOVEliQxsgvUvrUpgaLAyjQPkINPGrAbs6XoONliIVWakzu46hG0 +Zjrs4Fo+Aw1TN30m8kqnEW1SOluIakrIs8OfzHK9AlkHzpLt+TELEG6miKpDVxLoBQ7 +G10ZfrBIxxOY+fmAoy8b27RSpkSQMqSL/oeN2n6W+U+82hwlfpYxKUkJJllhfCQE1M8 VcSg== 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=xZLxKYDu97dxnj2AtLr98pj1IcJJ/kcroor0ywrlqWw=; b=saaz3CxfIXjrARhIXPpldIYmgbVZ5drGt6hegcLKOczqJ5NROfkUf9nVU8P3jSui4J XA8V6nLXYdIgWGZDvSddo03L1r+avhJn/hMXQOGyAOo3Oul4wL1DgbrX0PfVe9O98rwh GPPFesXz3ma27pgfY64VTDz4V1ROtyLvbwqW41iPCBULSHpcTOmoGw7W40I0oY1MzPHh tBNVWHsExlkxsuL2pTH8/ifJBMbARk5UgBFH0bngRFN3bCoIQqeC9wzB4zmSFeksIFA+ xfcUBN2EE6SxZAOGajXGy9aV5iOL8vchCnaKLU6G0Owzgrks4FBxmiMlq3hIkBftKRxS e/Ow== X-Gm-Message-State: AOUpUlE04SMRkY+n2hiyWpX+bnVhZGPtishonYQV9bYXE7L7rB0hc/XA dZjFhFBB6Bfl3za0LUio+VI53g== X-Google-Smtp-Source: AAOMgpc1im0lBYQbgqouIrV09KykmH7FHBaMvbWdSdVA4lbG2nkoBZAwDtXrvK8/lRdpjpRB7rF4bQ== X-Received: by 2002:a62:d39b:: with SMTP id z27-v6mr4405809pfk.182.1531436446918; Thu, 12 Jul 2018 16:00:46 -0700 (PDT) Received: from [192.168.178.40] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id p20-v6sm34750545pff.90.2018.07.12.16.00.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 16:00:46 -0700 (PDT) To: Ted Hardie Cc: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> From: Brian E Carpenter Message-ID: <0eefb84e-1a2b-4bbe-9e33-35a49b4db161@gmail.com> Date: Fri, 13 Jul 2018 11:00:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 23:00:51 -0000 Ted, > But this BoF follows the pattern we have used recently, at least to my eyes. Yes. The qualitative difference is that the proposal on the table amounts to *chucking out* several RFC streams, and that is (IMHO) so fundamental that a major and as yet undefined effort is needed to discover whether this is acceptable to the whole Internet technical community. The previous changes were administrative by comparison. Regards Brian Carpenter On 13/07/2018 03:57, Ted Hardie wrote: > Slightly off-topic, but perhaps important > On Wed, Jul 11, 2018 at 8:54 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> There's a real difference, in my opinion, in that the definition of >> the streams was a codification of existing practice, and the format >> update was something people have been requesting for many years. >> Neither of them showed any signs of being fundamentally contentious. >> > > I'm not sure what you mean by "fundamentally contentious", but both > proposals had many months of discussions and, in some parts, quite serious > opposition. Contentious would have been a word I would personally have > used to describe the format update, for example, and I'm not sure why you > would disagree. > > This time, we've seen a much more radical proposal which, if carried >> forward, would fundamentally change the series. In that case you can't >> duck the question of authority and who calls consensus. >> >> > I'll note that the proposed experiment borrows many elements of the format > discussion's process. While there is no question that the final format > documents were published by the IAB, the face-to-face discussions were all > hosted at IETF plenary meetings, for the same reason: it's the place where > the largest number of stream contributors are together at the same place > and the same time. It also borrows the rollback method inherent in the > format proposal (double RFC publication, first with trial format, then with > final format). If you have other methods in mind that would produce more > transparent discussion or more opportunity to test the results as we go, > I'd personally be interested in hearing them. But this BoF follows the > pattern we have used recently, at least to my eyes. > > regards, > > Ted > > > > >> Brian >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >> > From nobody Thu Jul 12 18:17:11 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4809130EAE for ; Thu, 12 Jul 2018 18:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 BveztADejCof for ; Thu, 12 Jul 2018 18:17:07 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 56CC5127333 for ; Thu, 12 Jul 2018 18:17:07 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id y207-v6so59323409oie.13 for ; Thu, 12 Jul 2018 18:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=swCuTEFVSQ05iuTud7uh0bf0P4wOzMtzIbxGf0kto+g=; b=qNIe6zs2eUiYuVN6uMpgOwcIdj7StPChKbQ2j4AZ+PyiKUh6Znwliyp2aipfyD7D2H 7RkX/dV8xZuk+KXrGX6+7XllBpDorjgg6RtzywxlFDrCKM8QX0pbwfyUweoMGptR6gPf vbj0sSqqWwZyP0bFEA+jFOyXl91QglwRaczlEWB6HCWn9mR7TuYhKmk2OHyVwmYIfYUJ uqGd4t1R+RdSjkudz27b8Y3WKJd+VLlvrWi0eGVS8A//lw5NwOEi5vyHnXRf+hRtsfOj LlqPZpvcbUeBwoQLJXRpD8OUeBXsV36zcBTvZt6bftYl7GMxQdcJafa36QnisOgTIru8 m4Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=swCuTEFVSQ05iuTud7uh0bf0P4wOzMtzIbxGf0kto+g=; b=X52RudCXgLOzqm6VZ7EXGwvC98hPtVtJt6MTyecz4crdxYv4f+mbalj+SM0z8rcP3v FWreLXzMSt9/vplq/6qDI0UKbFSorwF+1xrI5wQnHbjkSxBgDptUC0lIL54hcJLWT+Xd 6TMCJQLV8ZkOeKDAZ6eD5puaiSjKaXz9quC1lvguHjtwNEKGTjv5/AZ1F0/BVYfwKfVA Xz3qRLGj8g3TI5yvKKxkpq499Jjmmi6otA2TWydeTFeL0XN4WbZwkRXwyONgayBMKCdc 9sRO/xQy2tvMhs0fyJWsspW3K1mO5Ojdri/SHS7NzMc4GQOEt01Y41i2iTG/M7/dsTcn zcHA== X-Gm-Message-State: AOUpUlGtpDH12oES1ZwmSGoOUiGjFwsHz+m2yrgmtVcX2NDdbyx+4fac g9KJ4Jr82EkEN7/UpAoenI+/6m6ICHv3lUWmgXw= X-Google-Smtp-Source: AAOMgpcKG6Y9Pvv0niRScRu7toJZ/gnuDLvLddmtRWS4R5yAhKALPEAZWeLiQ1fKKvyGrglS8S4JBZHQ3zLqlOg7pVQ= X-Received: by 2002:aca:d015:: with SMTP id h21-v6mr5153158oig.142.1531444626395; Thu, 12 Jul 2018 18:17:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 18:16:35 -0700 (PDT) In-Reply-To: <0eefb84e-1a2b-4bbe-9e33-35a49b4db161@gmail.com> References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> <0eefb84e-1a2b-4bbe-9e33-35a49b4db161@gmail.com> From: Ted Hardie Date: Thu, 12 Jul 2018 18:16:35 -0700 Message-ID: To: Brian E Carpenter Cc: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f316830570d73c0c" Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 01:17:10 -0000 --000000000000f316830570d73c0c Content-Type: text/plain; charset="UTF-8" Brian, On Thu, Jul 12, 2018 at 4:00 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Ted, > > > But this BoF follows the pattern we have used recently, at least to my > eyes. > > Yes. The qualitative difference is that the proposal on the table amounts > to *chucking out* several RFC streams, Quite simply, that's not the proposal on the table, and it's not likely to be a proposal that emerges from the BoF. While I am not speaking for the IAB on this, it is my personal impression that the IAB is not only not likely to "chuck out" its own stream, but it has no interest in ending the financial and other support given to all the streams. This is a proposal to experimentally re-label the output, with a clear rollback if the experiment doesn't succeed. Critiquing the proposal is certainly a valid part of any BoF, and what emerges may be very different, but your characterization is simply not supported by the BoF proposal in any way. Ted > and that is (IMHO) so fundamental > that a major and as yet undefined effort is needed to discover whether > this is acceptable to the whole Internet technical community. > > The previous changes were administrative by comparison. > > Regards > Brian Carpenter > > On 13/07/2018 03:57, Ted Hardie wrote: > > Slightly off-topic, but perhaps important > > On Wed, Jul 11, 2018 at 8:54 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> There's a real difference, in my opinion, in that the definition of > >> the streams was a codification of existing practice, and the format > >> update was something people have been requesting for many years. > >> Neither of them showed any signs of being fundamentally contentious. > >> > > > > I'm not sure what you mean by "fundamentally contentious", but both > > proposals had many months of discussions and, in some parts, quite > serious > > opposition. Contentious would have been a word I would personally have > > used to describe the format update, for example, and I'm not sure why you > > would disagree. > > > > This time, we've seen a much more radical proposal which, if carried > >> forward, would fundamentally change the series. In that case you can't > >> duck the question of authority and who calls consensus. > >> > >> > > I'll note that the proposed experiment borrows many elements of the > format > > discussion's process. While there is no question that the final format > > documents were published by the IAB, the face-to-face discussions were > all > > hosted at IETF plenary meetings, for the same reason: it's the place > where > > the largest number of stream contributors are together at the same place > > and the same time. It also borrows the rollback method inherent in the > > format proposal (double RFC publication, first with trial format, then > with > > final format). If you have other methods in mind that would produce more > > transparent discussion or more opportunity to test the results as we go, > > I'd personally be interested in hearing them. But this BoF follows the > > pattern we have used recently, at least to my eyes. > > > > regards, > > > > Ted > > > > > > > > > >> Brian > >> > >> _______________________________________________ > >> Rfcplusplus mailing list > >> Rfcplusplus@ietf.org > >> https://www.ietf.org/mailman/listinfo/rfcplusplus > >> > > > --000000000000f316830570d73c0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian,

On Thu, Jul 12, 2018 at 4:00 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Ted,

> But this BoF follows the pattern we have used recently, at least to my= eyes.

Yes. The qualitative difference is that the proposal on the table am= ounts
to *chucking out* several RFC streams,

Qui= te simply, that's not the proposal on the table, and it's not likel= y to be a proposal that emerges from the BoF.=C2=A0 While I am not speaking= for the IAB on this, it is my personal impression that the IAB is not only= not likely to "chuck out" its own stream, but it has no interest= in ending the financial and other support given to all the streams.=C2=A0 =

This is a proposal to experimentally re-label= the output, with a clear rollback if the experiment doesn't succeed.= =C2=A0 Critiquing the proposal is certainly a valid part of any BoF, and wh= at emerges may be very different, but your characterization is simply not s= upported by the BoF proposal in any way.

Ted


=C2=A0
and that is (IMHO) so fundamental
that a major and as yet undefined effort is needed to discover whether
this is acceptable to the whole Internet technical community.

The previous changes were administrative by comparison.

Regards
=C2=A0 =C2=A0Brian Carpenter=

On 13/07/2018 03:57, Ted Hardie wrote:
> Slightly off-topic, but perhaps important
> On Wed, Jul 11, 2018 at 8:54 PM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>> There's a real difference, in my opinion, in that the definiti= on of
>> the streams was a codification of existing practice, and the forma= t
>> update was something people have been requesting for many years. >> Neither of them showed any signs of being fundamentally contentiou= s.
>>
>
> I'm not sure what you mean by "fundamentally contentious"= ;, but both
> proposals had many months of discussions and, in some parts, quite ser= ious
> opposition.=C2=A0 Contentious would have been a word I would personall= y have
> used to describe the format update, for example, and I'm not sure = why you
> would disagree.
>
> This time, we've seen a much more radical proposal which, if carri= ed
>> forward, would fundamentally change the series. In that case you c= an't
>> duck the question of authority and who calls consensus.
>>
>>
> I'll note that the proposed experiment borrows many elements of th= e format
> discussion's process.=C2=A0 While there is no question that the fi= nal format
> documents were published by the IAB, the face-to-face discussions were= all
> hosted at IETF plenary meetings, for the same reason:=C2=A0 it's t= he place where
> the largest number of stream contributors are together at the same pla= ce
> and the same time.=C2=A0 It also borrows the rollback method inherent = in the
> format proposal (double RFC publication, first with trial format, then= with
> final format).=C2=A0 If you have other methods in mind that would prod= uce more
> transparent discussion or more opportunity to test the results as we g= o,
> I'd personally be interested in hearing them.=C2=A0 But this BoF f= ollows the
> pattern we have used recently, at least to my eyes.
>
> regards,
>
> Ted
>
>
>
>
>>=C2=A0 =C2=A0 Brian
>>
>> _______________________________________________
>> Rfcplusplus mailing list
>> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinf= o/rfcplusplus
>>
>

--000000000000f316830570d73c0c-- From nobody Thu Jul 12 18:45:53 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB8C130EAC for ; Thu, 12 Jul 2018 18:45:51 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ICkID-NV6IPW for ; Thu, 12 Jul 2018 18:45:48 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F0F130DDC for ; Thu, 12 Jul 2018 18:45:48 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id i26-v6so10228534pfo.12 for ; Thu, 12 Jul 2018 18:45: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=NAvY97Ih5sh8ziHLskiwztzkB96k6gtziSvBaDNtLOs=; b=FLv5toU1wQ8aG61L9cAiP+bS8a19++zMnI3Hm5oUxYZgnNNFsSJfn3Lzyi/g/mFoNx VK15neKz+ES8tv2L0EMEAkGOV22AZcBpwjXiCtxKfRyXvnZ/qhaWNsOCPKNDQ5LR/iL9 F2bMUrmBpjvjcP6dgHAOGtvJC9nbwIpVxzWI76cTuxB7PudgYmFBq6MuETpe3y8cDPbI g0EXOE0TpVhq7voh3m7hmQMGCBLCIzzv35PSeEJBsABPmfAZz+IvG1J+a20NCBNRXfLN Q8QJS6iZG3d4LybfmueaF37THLg96MWuj14+W1ZCz12OiVBqS0GjMIL0Pn9UjEWa/Zg0 sRUw== 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=NAvY97Ih5sh8ziHLskiwztzkB96k6gtziSvBaDNtLOs=; b=Fod5X5u7Q9/8YULcBYdWZnLEd43PoUDUXhCc2OinbiAz59zwj6U6zK8J0eYe6tcG95 6n09Z6dVByPcOxCnStNvPnkOSqTDY9YHZbuPLNCnUR1kiOH4yvYYiTgp79uKH7pXpS+U tNkGkFLK7akpMTMP7eOjflVjCWAx1S6zkkv2a/EYenvnruIrdVvjmYwZ5QkiFtNkTV4Q 9sdgwbZMzFP6xMrCTtSUGhYuMRZPXJQKXtYcRWNiUS6TBKaWI1x0ZWXj5PjaLaQt4Fy/ X1QKh0XpVkYYrYH1T2UnwK/NxTr8bFg8J55x79z04hLv2Un0yc/SaSx6TFvDYk70Mb0w rrIQ== X-Gm-Message-State: AOUpUlHUXMO/8u9gENr/52nrWnHH6VU0vVAvh8UT+IEskj1PHQmrkMRe /OWfjRJQ93knaeiKgHm6sXERSg== X-Google-Smtp-Source: AAOMgpdju9SUZwLd3T5rtKZmYNTfYiEEHJizH91uGp4Fz5ZTcgWO6q6yn7qcYZkxSZjeCTS9pb3VMA== X-Received: by 2002:a63:1262:: with SMTP id 34-v6mr4301066pgs.154.1531446347801; Thu, 12 Jul 2018 18:45:47 -0700 (PDT) Received: from [192.168.178.40] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id b73-v6sm29813924pfl.152.2018.07.12.18.45.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 18:45:46 -0700 (PDT) To: Ted Hardie Cc: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> <0eefb84e-1a2b-4bbe-9e33-35a49b4db161@gmail.com> From: Brian E Carpenter Message-ID: <97585f4a-1761-762c-83d7-15284364e46e@gmail.com> Date: Fri, 13 Jul 2018 13:45:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 01:45:52 -0000 On 13/07/2018 13:16, Ted Hardie wrote: > Brian, > > On Thu, Jul 12, 2018 at 4:00 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Ted, >> >>> But this BoF follows the pattern we have used recently, at least to my >> eyes. >> >> Yes. The qualitative difference is that the proposal on the table amounts >> to *chucking out* several RFC streams, > > > Quite simply, that's not the proposal on the table, and it's not likely to > be a proposal that emerges from the BoF. While I am not speaking for the > IAB on this, it is my personal impression that the IAB is not only not > likely to "chuck out" its own stream, but it has no interest in ending the > financial and other support given to all the streams. > > This is a proposal to experimentally re-label the output, with a clear > rollback if the experiment doesn't succeed. Critiquing the proposal is > certainly a valid part of any BoF, and what emerges may be very different, > but your characterization is simply not supported by the BoF proposal in > any way. But the draft we are supposed to be discussing says: >> This documents proposes reserving the "RFC" label for those documents >> that are the product of the Internet Standards Process [RFC2026]. The BOF text in the wiki says: >> This would allow "RFC" to be reserved for standards-related documents, If that isn't "chucking out", I don't know what it is. (The theory that this is a reversible change is very dubious, as others have pointed out.) Now I really must pack a suitcase. Brian > Ted > > > > >> and that is (IMHO) so fundamental >> that a major and as yet undefined effort is needed to discover whether >> this is acceptable to the whole Internet technical community. >> >> The previous changes were administrative by comparison. >> >> Regards >> Brian Carpenter >> >> On 13/07/2018 03:57, Ted Hardie wrote: >>> Slightly off-topic, but perhaps important >>> On Wed, Jul 11, 2018 at 8:54 PM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> There's a real difference, in my opinion, in that the definition of >>>> the streams was a codification of existing practice, and the format >>>> update was something people have been requesting for many years. >>>> Neither of them showed any signs of being fundamentally contentious. >>>> >>> >>> I'm not sure what you mean by "fundamentally contentious", but both >>> proposals had many months of discussions and, in some parts, quite >> serious >>> opposition. Contentious would have been a word I would personally have >>> used to describe the format update, for example, and I'm not sure why you >>> would disagree. >>> >>> This time, we've seen a much more radical proposal which, if carried >>>> forward, would fundamentally change the series. In that case you can't >>>> duck the question of authority and who calls consensus. >>>> >>>> >>> I'll note that the proposed experiment borrows many elements of the >> format >>> discussion's process. While there is no question that the final format >>> documents were published by the IAB, the face-to-face discussions were >> all >>> hosted at IETF plenary meetings, for the same reason: it's the place >> where >>> the largest number of stream contributors are together at the same place >>> and the same time. It also borrows the rollback method inherent in the >>> format proposal (double RFC publication, first with trial format, then >> with >>> final format). If you have other methods in mind that would produce more >>> transparent discussion or more opportunity to test the results as we go, >>> I'd personally be interested in hearing them. But this BoF follows the >>> pattern we have used recently, at least to my eyes. >>> >>> regards, >>> >>> Ted >>> >>> >>> >>> >>>> Brian >>>> >>>> _______________________________________________ >>>> Rfcplusplus mailing list >>>> Rfcplusplus@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rfcplusplus >>>> >>> >> > From nobody Thu Jul 12 20:31:23 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CEE127148 for ; Thu, 12 Jul 2018 20:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 XF4PZwcUh_rB for ; Thu, 12 Jul 2018 20:31:15 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 5B2A2130FA8 for ; Thu, 12 Jul 2018 20:31:15 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id l10-v6so13034887oii.0 for ; Thu, 12 Jul 2018 20:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7lLCEy8EwwOJMUMnOBN1q7NyaI3kMmWRR0vb9dO3fsk=; b=OzpjuFM800N85+e1Q5ElfC3PDJ+KlfnRstFXCdG3h0hKsFCJ7BfPsnwCQBbF4VDuLa R/jd4xvelgMr8nyhiLW7ThUSWFLzi0EnSAbusUpWqF6bUkIKxqJRvSwJG82nPj/bSmG0 qLyNl/lqmEWhQj9EaoQtoW1U8K1ZptEWLDC9XUI4ZdMcU1mUTBpkQnFGZpq6l1aE3plH JVWul5OBN82lMazUo7kNNcXQ8bRtL+3bwzIUmMkvmbvv7CBL0CMZllCgU+YCRZnA2XAu N5OF3ysDSfiYmAlG3HbbDOBpYD3UMVSYj6m0VsJzGCGIEvWl8/GIgT/wZwtx7gbm7Pyb +76g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7lLCEy8EwwOJMUMnOBN1q7NyaI3kMmWRR0vb9dO3fsk=; b=bTSc51XRCN9ol/CLi5k9nCntetQuPRcDuCEC6VePaRcCCkPcJhYvqL19mK4zxZ9Ylj eSxSXDThqVUns7m00nORlKKhiZmJYAPYVbpMRnCslh6vRS78h77bZ6g2eJgMfvR+lHe/ MxLsjdVDa+10Ccdza3pa1rW/hEJa5W6DB+hWN/4bK+QLnTmj4DasC3mSASyOKVNk1cQg 81p5UEiMXLLamaP2xjbd8RD0JeScGIjbm55c2XqtctITzw39aps4AhMumKh/A0TRJHAV IY3xGNI3rgkbmuvjbH2Epy08Zr/KEryZHuvh2M/Rw4Du5wVCi+io7jjHR23m8HwHG+GQ pzyA== X-Gm-Message-State: AOUpUlH10iOwF9ve6vHFi+0i0rfI4FCXUe2G8DfSa+X1AQqCAuPWu+5h YZv780Cpr6+JmAYcJn2hzTqegCl891p+mQk4ytQ= X-Google-Smtp-Source: AAOMgpdeQY+Vli+Uq2XXywp9vYbvLbZ9zOzKsSbrd0Almv65T7Y6C6tsPCH1BhurYj6g2Shf7rb49tqu3WIzGhDBCEw= X-Received: by 2002:aca:d015:: with SMTP id h21-v6mr5509430oig.142.1531452674569; Thu, 12 Jul 2018 20:31:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 20:30:43 -0700 (PDT) In-Reply-To: <97585f4a-1761-762c-83d7-15284364e46e@gmail.com> References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> <0eefb84e-1a2b-4bbe-9e33-35a49b4db161@gmail.com> <97585f4a-1761-762c-83d7-15284364e46e@gmail.com> From: Ted Hardie Date: Thu, 12 Jul 2018 20:30:43 -0700 Message-ID: To: Brian E Carpenter Cc: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a87afe0570d91cbd" Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 03:31:20 -0000 --000000000000a87afe0570d91cbd Content-Type: text/plain; charset="UTF-8" On Thu, Jul 12, 2018 at 6:45 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > But the draft we are supposed to be discussing says: > > >> This documents proposes reserving the "RFC" label for those documents > >> that are the product of the Internet Standards Process [RFC2026]. > > The BOF text in the wiki says: > > >> This would allow "RFC" to be reserved for standards-related documents, > > If that isn't "chucking out", I don't know what it is. > > (The theory that this is a reversible change is very dubious, as > others have pointed out.) > > Describing the theory that it is reversible as doubtful is a fair comment. It may be difficult to roll back a change, and that's well worth discussing. But that's different from asserting that the proposal intends any stream to be "chucked out", in any of the meanings I find . They are not being closed, defunded, or sent off to other organizations; they continue to use the same facilities, represent the same streams, and carry on with the same managers. The proposed difference is in the label which is applied during the experiment, nothing more. Arguing against some other proposal comes close to either failing to credit your colleagues with the plain of their words or arguing against a strawman, neither of which I hope you intend. Now I really must pack a suitcase. > > Travel safely, and I look forward to seeing you in Montreal. Ted > Brian > > Ted > > > > > > > > > >> and that is (IMHO) so fundamental > >> that a major and as yet undefined effort is needed to discover whether > >> this is acceptable to the whole Internet technical community. > >> > >> The previous changes were administrative by comparison. > >> > >> Regards > >> Brian Carpenter > >> > >> On 13/07/2018 03:57, Ted Hardie wrote: > >>> Slightly off-topic, but perhaps important > >>> On Wed, Jul 11, 2018 at 8:54 PM, Brian E Carpenter < > >>> brian.e.carpenter@gmail.com> wrote: > >>> > >>>> There's a real difference, in my opinion, in that the definition of > >>>> the streams was a codification of existing practice, and the format > >>>> update was something people have been requesting for many years. > >>>> Neither of them showed any signs of being fundamentally contentious. > >>>> > >>> > >>> I'm not sure what you mean by "fundamentally contentious", but both > >>> proposals had many months of discussions and, in some parts, quite > >> serious > >>> opposition. Contentious would have been a word I would personally have > >>> used to describe the format update, for example, and I'm not sure why > you > >>> would disagree. > >>> > >>> This time, we've seen a much more radical proposal which, if carried > >>>> forward, would fundamentally change the series. In that case you can't > >>>> duck the question of authority and who calls consensus. > >>>> > >>>> > >>> I'll note that the proposed experiment borrows many elements of the > >> format > >>> discussion's process. While there is no question that the final format > >>> documents were published by the IAB, the face-to-face discussions were > >> all > >>> hosted at IETF plenary meetings, for the same reason: it's the place > >> where > >>> the largest number of stream contributors are together at the same > place > >>> and the same time. It also borrows the rollback method inherent in the > >>> format proposal (double RFC publication, first with trial format, then > >> with > >>> final format). If you have other methods in mind that would produce > more > >>> transparent discussion or more opportunity to test the results as we > go, > >>> I'd personally be interested in hearing them. But this BoF follows the > >>> pattern we have used recently, at least to my eyes. > >>> > >>> regards, > >>> > >>> Ted > >>> > >>> > >>> > >>> > >>>> Brian > >>>> > >>>> _______________________________________________ > >>>> Rfcplusplus mailing list > >>>> Rfcplusplus@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rfcplusplus > >>>> > >>> > >> > > > --000000000000a87afe0570d91cbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 12, 2018 at 6:45 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

But the draft we are supposed to be discussing says:

>>=C2=A0 =C2=A0 This documents proposes reserving the "RFC"= label for those documents
>>=C2=A0 =C2=A0 that are the product of the Internet Standards Proces= s [RFC2026].

The BOF text in the wiki says:

>> This would allow "RFC" to be reserved for standards-rela= ted documents,

If that isn't "chucking out", I don't know what it is.
(The theory that this is a reversible change is very dubious, as
others have pointed out.)


Describing the theory that it is rever= sible as doubtful is a fair comment.=C2=A0 It may be difficult to roll back= a change, and that's well worth discussing.=C2=A0 But that's diffe= rent from asserting that the proposal intends any stream to be "chucke= d out", = in any of the meanings I find.=C2=A0 They are not being closed, defunde= d, or sent off to other organizations; they continue to use the same facili= ties, represent the same streams, and carry on with the same managers. The = proposed difference is in the label which is applied during the experiment,= nothing more.=C2=A0

Arguing against some oth= er proposal comes close to either failing to credit your colleagues with th= e plain of their words or arguing against a strawman, neither of which I ho= pe you intend.

Now I really must pack a suitcase.

Travel safely, and I look forward to seeing you in Montreal.
<= div>
Ted
=C2=A0
=C2=A0 =C2=A0Brian
> Ted
>
>
>
>
>> and that is (IMHO) so fundamental
>> that a major and as yet undefined effort is needed to discover whe= ther
>> this is acceptable to the whole Internet technical community.
>>
>> The previous changes were administrative by comparison.
>>
>> Regards
>>=C2=A0 =C2=A0 Brian Carpenter
>>
>> On 13/07/2018 03:57, Ted Hardie wrote:
>>> Slightly off-topic, but perhaps important
>>> On Wed, Jul 11, 2018 at 8:54 PM, Brian E Carpenter <
>>> brian.e.carpent= er@gmail.com> wrote:
>>>
>>>> There's a real difference, in my opinion, in that the = definition of
>>>> the streams was a codification of existing practice, and t= he format
>>>> update was something people have been requesting for many = years.
>>>> Neither of them showed any signs of being fundamentally co= ntentious.
>>>>
>>>
>>> I'm not sure what you mean by "fundamentally contenti= ous", but both
>>> proposals had many months of discussions and, in some parts, q= uite
>> serious
>>> opposition.=C2=A0 Contentious would have been a word I would p= ersonally have
>>> used to describe the format update, for example, and I'm n= ot sure why you
>>> would disagree.
>>>
>>> This time, we've seen a much more radical proposal which, = if carried
>>>> forward, would fundamentally change the series. In that ca= se you can't
>>>> duck the question of authority and who calls consensus. >>>>
>>>>
>>> I'll note that the proposed experiment borrows many elemen= ts of the
>> format
>>> discussion's process.=C2=A0 While there is no question tha= t the final format
>>> documents were published by the IAB, the face-to-face discussi= ons were
>> all
>>> hosted at IETF plenary meetings, for the same reason:=C2=A0 it= 's the place
>> where
>>> the largest number of stream contributors are together at the = same place
>>> and the same time.=C2=A0 It also borrows the rollback method i= nherent in the
>>> format proposal (double RFC publication, first with trial form= at, then
>> with
>>> final format).=C2=A0 If you have other methods in mind that wo= uld produce more
>>> transparent discussion or more opportunity to test the results= as we go,
>>> I'd personally be interested in hearing them.=C2=A0 But th= is BoF follows the
>>> pattern we have used recently, at least to my eyes.
>>>
>>> regards,
>>>
>>> Ted
>>>
>>>
>>>
>>>
>>>>=C2=A0 =C2=A0 Brian
>>>>
>>>> _______________________________________________
>>>> Rfcplusplus mailing list
>>>> Rfcplusplus@ietf.o= rg
>>>> https://www.ietf.org/mailman/= listinfo/rfcplusplus
>>>>
>>>
>>
>

--000000000000a87afe0570d91cbd-- From nobody Thu Jul 12 22:12:29 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32986130DF0 for ; Thu, 12 Jul 2018 22:12:27 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 WzRib3pFNkjZ for ; Thu, 12 Jul 2018 22:12:24 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 6A27D1294D7 for ; Thu, 12 Jul 2018 22:12:24 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id q7-v6so20827397pff.2 for ; Thu, 12 Jul 2018 22:12:24 -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=1r5vaRBXeUNqZYjaSi6Pv9HGakD9ZNLs5J5FjoH3QkI=; b=n1AEkFMqghiCM8TmMMMpZ3nh3QAKLS4Bj08PrpS5oiD+VL+wjqT953SRW+KAlOOLwR mhF8aKu7PjeEvdYVYgv7/IsgB1b93S4H9vF5NZeN+kjpEn+V2qNxrhnTeWWNJ7ELz8CE xK4GVHDua7d9clUYPsBzGqXQDyhDSucSUPxVs8eY7iZK9Th4yJZ3uuO2kdZsh9yQ4pRO MqTTzEpk/lTSXygFZF8GPYeQME/IqY/Bwdbvml+jd0FyQZ809lkvg3/PnFnVMY7pPdLF KyJfIBoY+DVf/078jbB+fiTXpQI1aI/i68ZuBh86p2AVViTYZUeg2CzMd1AyRz7EclFH zLXg== 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=1r5vaRBXeUNqZYjaSi6Pv9HGakD9ZNLs5J5FjoH3QkI=; b=IKUe2tfBLcS3NRqkhxSwL7XddBSHdaRkEHsr6ANpyEJRulGio4lB68M4IXkj45qdoF bXKGPQrFXrin5PpXUX3Eh5pOSij/bTFCQ7vKXxcBlk9W7QW5v8EEMlK7SplVQkHnn2ZI 6nf4r51vIVZ3raN40AVmc2kXkU6V5uDZ35DGVXHpUMbVHmTc86sSxkt7KQOefgArC0g3 /LSqlGQM1gIIZMiDEdOVrztG9lPJSSpAimOulEvtKXTZTNxFuhmkpUgbxjjXl1k2TFsv jMt5ox7agDVKTyOxb/l0c1qXhGyqNKDnWwTNFel4vtuMiVCuzKEmDIi6CYexw5TJsuSy P7EA== X-Gm-Message-State: AOUpUlFpC1cjMIrAV+Dk/lBtJ4thGGxg1F4s9lan2J0Go3NzfgQfbIiP NpL5FYp56hvk7KDaDCh9/Fmutg== X-Google-Smtp-Source: AAOMgpf5eTu46ojV65B9AbVN1cYSoGIG4iWe2xMV8hGZqEqkeGyjZGs52C9FArUPB/Fm6gL1fCYNJg== X-Received: by 2002:a63:1d5e:: with SMTP id d30-v6mr4810999pgm.12.1531458743683; Thu, 12 Jul 2018 22:12:23 -0700 (PDT) Received: from [192.168.41.146] ([219.88.101.10]) by smtp.gmail.com with ESMTPSA id s12-v6sm36149443pfm.41.2018.07.12.22.12.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 22:12:22 -0700 (PDT) To: Ted Hardie Cc: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> <0eefb84e-1a2b-4bbe-9e33-35a49b4db161@gmail.com> <97585f4a-1761-762c-83d7-15284364e46e@gmail.com> From: Brian E Carpenter Message-ID: <47e90834-aa80-3325-920e-8bcc12c604d2@gmail.com> Date: Fri, 13 Jul 2018 17:12:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 05:12:28 -0000 > The proposed difference is in the label which is applied during > the experiment, nothing more. They would be denied the use of the abbreviation RFC and an RFC number in the series that was started in 1969, and presumably therefore of the ISSN number and a DOI in the same family. That is chucking out of the RFC series as far as I'm concerned. It couldn't be plainer. Regards Brian On 13/07/2018 15:30, Ted Hardie wrote: > On Thu, Jul 12, 2018 at 6:45 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> >> But the draft we are supposed to be discussing says: >> >>>> This documents proposes reserving the "RFC" label for those documents >>>> that are the product of the Internet Standards Process [RFC2026]. >> >> The BOF text in the wiki says: >> >>>> This would allow "RFC" to be reserved for standards-related documents, >> >> If that isn't "chucking out", I don't know what it is. >> >> (The theory that this is a reversible change is very dubious, as >> others have pointed out.) >> >> > Describing the theory that it is reversible as doubtful is a fair comment. > It may be difficult to roll back a change, and that's well worth > discussing. But that's different from asserting that the proposal intends > any stream to be "chucked out", in any of the meanings I find > . They are not being > closed, defunded, or sent off to other organizations; they continue to use > the same facilities, represent the same streams, and carry on with the same > managers. The proposed difference is in the label which is applied during > the experiment, nothing more. > > Arguing against some other proposal comes close to either failing to credit > your colleagues with the plain of their words or arguing against a > strawman, neither of which I hope you intend. > > Now I really must pack a suitcase. >> >> Travel safely, and I look forward to seeing you in Montreal. > > Ted > > >> Brian >>> Ted >>> >>> >>> >>> >>>> and that is (IMHO) so fundamental >>>> that a major and as yet undefined effort is needed to discover whether >>>> this is acceptable to the whole Internet technical community. >>>> >>>> The previous changes were administrative by comparison. >>>> >>>> Regards >>>> Brian Carpenter >>>> >>>> On 13/07/2018 03:57, Ted Hardie wrote: >>>>> Slightly off-topic, but perhaps important >>>>> On Wed, Jul 11, 2018 at 8:54 PM, Brian E Carpenter < >>>>> brian.e.carpenter@gmail.com> wrote: >>>>> >>>>>> There's a real difference, in my opinion, in that the definition of >>>>>> the streams was a codification of existing practice, and the format >>>>>> update was something people have been requesting for many years. >>>>>> Neither of them showed any signs of being fundamentally contentious. >>>>>> >>>>> >>>>> I'm not sure what you mean by "fundamentally contentious", but both >>>>> proposals had many months of discussions and, in some parts, quite >>>> serious >>>>> opposition. Contentious would have been a word I would personally have >>>>> used to describe the format update, for example, and I'm not sure why >> you >>>>> would disagree. >>>>> >>>>> This time, we've seen a much more radical proposal which, if carried >>>>>> forward, would fundamentally change the series. In that case you can't >>>>>> duck the question of authority and who calls consensus. >>>>>> >>>>>> >>>>> I'll note that the proposed experiment borrows many elements of the >>>> format >>>>> discussion's process. While there is no question that the final format >>>>> documents were published by the IAB, the face-to-face discussions were >>>> all >>>>> hosted at IETF plenary meetings, for the same reason: it's the place >>>> where >>>>> the largest number of stream contributors are together at the same >> place >>>>> and the same time. It also borrows the rollback method inherent in the >>>>> format proposal (double RFC publication, first with trial format, then >>>> with >>>>> final format). If you have other methods in mind that would produce >> more >>>>> transparent discussion or more opportunity to test the results as we >> go, >>>>> I'd personally be interested in hearing them. But this BoF follows the >>>>> pattern we have used recently, at least to my eyes. >>>>> >>>>> regards, >>>>> >>>>> Ted >>>>> >>>>> >>>>> >>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> Rfcplusplus mailing list >>>>>> Rfcplusplus@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rfcplusplus >>>>>> >>>>> >>>> >>> >> > From nobody Fri Jul 13 07:35:19 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31EF130F12 for ; Fri, 13 Jul 2018 07:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 6gIm9cPzzmDe for ; Fri, 13 Jul 2018 07:34:54 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2827130E75 for ; Fri, 13 Jul 2018 07:34:54 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id i12-v6so62603726oik.2 for ; Fri, 13 Jul 2018 07:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dNSLnAwhhrJ/8TUt0YThjKLVxskXGgeTRoYkxhNkKvs=; b=SwJjsYepBSMsmXqHq+FhDbeLOplE7CResdja7jyeKulwFfpkdY0J9ValTZ5d7pe0qz w6Pw65PLGjbzBW/f8LTm929Fr9TOuAWUkfsOQrtFNr+Z4LoENEuEaclpq03SfbVlk7Zo 2on/dk3oHgSz/RdNanT0NWjppECgi3pTIkoXx7hYRxBzt8VjZXby/zxak/ikwRMMLbk8 5RDih/1gbbc18emcPPhQlykmr7/prZgdu0z6OWSOgc2EW/jMCg0qcgTe48SiIYGCiWxg 7L7jT0Ansu9AyoEF1MUYozcmzVUsVEiuWPFDCtpUmuoU8Ed/kEkhnLizV/qHRbU26tBg 9y0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dNSLnAwhhrJ/8TUt0YThjKLVxskXGgeTRoYkxhNkKvs=; b=UO+D9W3zGjO5/x6G4eWIv7jigYD5AkBHxcqJAHwoO9DTai2myhaehh8VKX+Bk9Jyhe 2kj0ddtYWX6kz5k3ww8tmhmFcmptGjjgaRJeFcPsaIkJLp3/JQ4encTr9uTG2k0WlMyo 4Q8X1SWmbSfeb9+hfWmd7laqbwDRy9CHydwCdlAKH9Kc+PvwVn8T4wJTQhqMZR8RVy7G GXk0kbfxbNbs+4MXYUY7ZqnZwxMEpgpipxl2GSlqq2obiEcgcD9hwzc0VyLg1ogw19Eg ceb+QsStESqhP55bIXHshO0a60PMcFnWeF7HhDrTMD8PH5xpR6Ep+ot7zhE3qJ/N+Y3o oRtg== X-Gm-Message-State: AOUpUlHnpNHFuA5Zw/clxHh/veR21sNjF6ErqeyHaZc1MSO4GbZTmr0l 9IhNvLmxUSnL1jC/JOnaCI8Rr1Giz5GRp5chrrE= X-Google-Smtp-Source: AAOMgpdxKizpp+EdA1XAI5e0J6SQVzzy718HRNdDa0GtGTqWxV5xkx7NeZL5OA1yplY3KVvkjqKVdu6YKNVvim6ybK8= X-Received: by 2002:aca:e450:: with SMTP id b77-v6mr7796570oih.0.1531492493647; Fri, 13 Jul 2018 07:34:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 07:34:22 -0700 (PDT) In-Reply-To: <47e90834-aa80-3325-920e-8bcc12c604d2@gmail.com> References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> <0eefb84e-1a2b-4bbe-9e33-35a49b4db161@gmail.com> <97585f4a-1761-762c-83d7-15284364e46e@gmail.com> <47e90834-aa80-3325-920e-8bcc12c604d2@gmail.com> From: Ted Hardie Date: Fri, 13 Jul 2018 07:34:22 -0700 Message-ID: To: Brian E Carpenter Cc: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000f67300570e262bd" Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 14:35:09 -0000 --0000000000000f67300570e262bd Content-Type: text/plain; charset="UTF-8" Howdy, On Thu, Jul 12, 2018 at 10:12 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > The proposed difference is in the label which is applied during > > the experiment, nothing more. > > They would be denied the use of the abbreviation RFC and an RFC number > in the series that was started in 1969, and presumably therefore > of the ISSN number and a DOI in the same family. > > That is chucking out of the RFC series as far as I'm concerned. It > couldn't be plainer. > > Regards > Brian > Well, language is a funny thing, and it may well evolve to where this meaning is common. Who knows? It may even evolve to the point where the barkeeps in Westerns have the bouncers experimentally relabel bad guys through plate glass windows for comic effect.* In the mean time, I must disagree with this characterization. As an author of a document recently adopted by one of the relevant streams, I don't think relabeling the document would chuck me out of the conversation, and, even if it has the effect of muting my voice, the aim of the experiment is to rollback the status of any documents which experience that impact. regards, Ted *At the time of writing the Urban Dictionary had no direct entry for "chucking out", so there is the opportunity to enter "experimentally relabel" there, if you care to. At the worst, it would mean you could buy a mug with your definition on it. --0000000000000f67300570e262bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Thu, Jul 12, 2018 at 10:12 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> The proposed difference is in the labe= l which is applied during
> the experiment, nothing more.

They would be denied the use of the abbreviation RFC and an RFC numb= er
in the series that was started in 1969, and presumably therefore
of the ISSN number and a DOI in the same family.

That is chucking out of the RFC series as far as I'm concerned. It
couldn't be plainer.

Regards
=C2=A0 =C2=A0Brian

Well, language is = a funny thing, and it may well evolve to where this meaning is common.=C2= =A0 Who knows?=C2=A0 It may even evolve to the point where the barkeeps in = Westerns have the bouncers experimentally relabel bad guys through plate gl= ass windows for comic effect.*=C2=A0

In the m= ean time, I must disagree with this characterization.=C2=A0 As an author of= a document recently adopted by one of the relevant streams, I don't th= ink relabeling the document would chuck me out of the conversation, and, ev= en if it has the effect of muting my voice, the aim of the experiment is to= rollback the status of any documents which experience that impact.

regards,

Ted

*At the time of writing the Urban Dictionary had no direct entry for = "chucking out", so there is the opportunity to enter "experi= mentally relabel" there, if you care to.=C2=A0 At the worst, it would = mean you could buy a mug with your definition on it.


--0000000000000f67300570e262bd-- From nobody Fri Jul 13 13:52:44 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61623130E17 for ; Fri, 13 Jul 2018 13:52:42 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 fN54GxaCG4FX for ; Fri, 13 Jul 2018 13:52:40 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBDC130EDB for ; Fri, 13 Jul 2018 13:52:27 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fe53C-000GGX-EX; Fri, 13 Jul 2018 16:52:26 -0400 Date: Fri, 13 Jul 2018 16:52:20 -0400 From: John C Klensin To: Allison Mankin cc: Rfcplusplus@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations (really) X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 20:52:43 -0000 --On Wednesday, July 11, 2018 13:26 -0400 Allison Mankin wrote: > (IRTF Chair hat on) > One of my goals as IRTF Chair is precisely to create a new, > non-RFC stream for the IRTF. So, IRTF is very much an > interested party in this BOF. > > The most common response I get during outreach into academia > is that RFCs aren't a good medium for most academics. This > is despite researchers' wish eventually to have ideas > deployed. We've been exploring what work product will best > serve the research community, and . this does include > distinguishing the work from the RFCs. >... Allison, I'd like to suggest a slightly different way to think about this, one that might make things easier for you and the IRTF and that might slightly reduce the complexity of the BOF discussion. I have no skin in the IRTF or its situation -- this is just an attempt to be constructive. As far as I can tell, nothing prevents, or has ever prevented, the IRTF, or individual IRTF participants, from publishing a document wherever would best suit the purposes and content of the document and their personal and professional goals (either individually or in groups). If you decide the best way to accomplish that is to create a new journal, I don't know whose permission you would need, but I'd hope that the IAB, IASA, and ISOC would all be supportive. Having been a bit involved some years ago with a journal that had gotten a poor reputation and whose management tried to re-label it in the hope of fixing that, many of the people who make decisions about academic credibility and impact are fairly smart and a completely new journal is more likely to be effective in a reasonable period of time than trying to relaunch part of the RFC Series under different labels while carrying around some artifacts from the old series, but that is your call, not mine. It seems to me that none of that is a problem for the BOF - you should just do your thing, presumably with the support of the relevant community. Where there is an overlap (and maybe an issue for the BOF) is when Research Groups want to publish documents that are, as others have suggested, much more of the character of engineering work that is pre-IETF or about ready to be pushing into the IETF. It isn't clear you would want that material in a significantly more academic journal or that trying to hold such work to a high academic journal standard would benefit either the work or the journal. But, with the understanding that I have very little idea about what has been going on in the last several years, my recollection is that RGs doing work like that were typically developed in conjunction with the IESG and, indeed, could often be said to be doing work that was more or less commissioned by the IETF. In those situations, tie importance of a clear distinction between an Informational document providing a description of preliminary, or problem-space-defining, work produced by an RG or an IETF WG may be relatively small and creating a document-labeling distinction might actually be more misleading and confusing than simply publishing the documents in the same series with appropriate notes. Indeed, if RGs of that sort were to be told that, because they were RGs, they couldn't publish alongside the work that would presumably follow based on the work they had done, I have to wonder if we would see an upswing in requests for AD-Sponsored publication of documents that really came out of those RGs (AFAIK, we have no rules that would prevent such requests). Or those RGs might seek to recharacterize themselves as IETF WGs with a problem exploration agenda -- the boundary between the two was often, at least when I was closer to the situation, always a little vague. Be that is a may, it seems to me that the key question becomes whether there are RGs whose output is not suitable for publication in a high-quality academic journal (whether run by "us"or by others and is still not suitable as direct input to present or future IETF efforts. If they exist, how would you characterize them and would the effort of trying to do so inform the distinctions you are trying to make. best, john From nobody Sat Jul 14 06:35:33 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1951130FD1 for ; Sat, 14 Jul 2018 06:35:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 nyu5NjDHMQ11 for ; Sat, 14 Jul 2018 06:35:30 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4983130FD6 for ; Sat, 14 Jul 2018 06:35:29 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id y5-v6so29430962qti.12 for ; Sat, 14 Jul 2018 06:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=mX1dU4GiuzYkN7iU+wgcUoyv+7Xhl72FkPCvDS7BMkM=; b=OdxiBoA6hOHG9yMUDHklul2/VZ4CJU9dtninYVkYba8ssYTB61h2bOr1z3Ja3ojTaM UNbqQ3l6X2Mu09z+M7Gl5Im5cLyLJW+QDMRipEJGiXN2z3Y56EDhsi9ri12PCb91GESx 1y/gVeY44zavLZlMN+VupFqYJj64JPFoWszKI= 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:message-id:date:to; bh=mX1dU4GiuzYkN7iU+wgcUoyv+7Xhl72FkPCvDS7BMkM=; b=ob7DkS2/1vKcdAdp/7tW1nuhRQX04U0L98Aan5ky+T4OkQa6ymuep8ls/ttvxWrR4Y MM7NdzSoeQceL2OFPueez87TGWb2B/PevBhISKGvNFXI1Xs0XzhqqPR1AfaQxmeHcWq0 1LdAkJr2tyO2JqAWl+iTYDzrXnsZUQ91sPXscaWGj0vu0c6qFBpH2gQ/sk25CMId3qsl VIaab82p7qvL9v5mHIYj7QqAfR9Aojc3tuZ1N//drZgD9Xc2dIbdPFpMTzI+qgUPytlf 2lbDCHb3LxOzIT+zfSMl2woMRANrUTWLNbjaLIsZQVMsp6FIffJ1KyyAHnQezf/xphTz vpHg== X-Gm-Message-State: AOUpUlENQr/X3liZp3xSdxpvGrNdd8HphC9OaDHLIHo7cSolBeJGYhtM lbavXw6KTHRBKt8n3ZXpWehaaS2OhLE= X-Google-Smtp-Source: AAOMgpdur/bTG1zqm6aczOkREwK+vO6F+R1Cxv5jx96sYwvILpkgXL1YeTO61NLugWT1S5MJ4R6yQg== X-Received: by 2002:ac8:3209:: with SMTP id x9-v6mr9432968qta.128.1531575328725; Sat, 14 Jul 2018 06:35:28 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id m4-v6sm22320616qtm.79.2018.07.14.06.35.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jul 2018 06:35:27 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Sat, 14 Jul 2018 09:35:26 -0400 To: rfcplusplus@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Rfcplusplus] RFC++@IETF 102 agenda posted X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 13:35:32 -0000 All, we have finally posted the agenda for the RFC++ BOF scheduled for Monday = from 1810-1940 in the Laurier room. Apologies for being tardy with the = agenda, but the ongoing discussions have been helpful while pulling our = thoughts together about how we would like to organize the BOF. As you = will notice, the chairs are doing most of the presenting prior to the = discussion. We felt this would yield the best results because both = chairs are going to be neutral and not drive an agenda, i.e., we are = just facilitating the discussion. Our plan is to do the typical = administrativa, provide some background for those who might not be so = steeped in IETF processes, and finally ask some questions that hopefully = bound the discussion. We are sure that we will not capture every subtle = nuance the way every BOF participant would want it presented, but that = is what the mic line is for. We do however want to thank those who offered to present. Cheers, Gonzalo and Sean= From nobody Sat Jul 14 07:02:39 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BFE130ED2 for ; Sat, 14 Jul 2018 07:02:37 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 ZIxa-CUy7aHM for ; Sat, 14 Jul 2018 07:02:36 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D34130DBE for ; Sat, 14 Jul 2018 07:02:36 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1feL86-000J6i-RF for Rfcplusplus@ietf.org; Sat, 14 Jul 2018 10:02:34 -0400 Date: Sat, 14 Jul 2018 10:02:28 -0400 From: John C Klensin To: Rfcplusplus@ietf.org Message-ID: <1986638168567223C132B119@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Rfcplusplus] draft-klensin-rfcplusplus-alternatives-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 14:02:38 -0000 Hi. As suggested by one of my comments to the list several days ago and in the hope that it will help with the discussions, I've put together an Internet Draft that attempts to summarize some major categories of proposals so far. The draft largely sets the issues of problem statement and whether there is a problem work solving aside and looks at possible solutions (including one very radical one not explicitly proposed yet, at least in any message I've seen). Alissa agreed to allowing it to be posted between the cutoff and Monday if I sent it to her. I did that at around 19:48 UTC yesterday. It apparently has not been posted yet, I assume because of the very busy schedule of the IETF Chair. If she continues to not have time, I'll post it to this list late afternoon Montreal time today and then just go through the normal procedure for the repository. I hope at least a few people find it helpful. best, john From nobody Sat Jul 14 08:24:22 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202AB1310EF for ; Sat, 14 Jul 2018 08:24:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=sn3rd.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 m7hvnY5hGrre for ; Sat, 14 Jul 2018 08:24:12 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609C41310E8 for ; Sat, 14 Jul 2018 08:24:11 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id h4-v6so29585646qtj.7 for ; Sat, 14 Jul 2018 08:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=n3jLwXIchCh8cThFBjnJWX2BKPELB/IMn5mvV2hYqcY=; b=Ryl6q2LXnAOGATAex3awLiTL+VW1YuhFlY2OAdpCH+9IByWh5s+mZJQuNJ+QQmnqSM qVDTX+5OxXsF737h2JSbqGU9cZWPVL2vhf1qg4vwyb6ZXHLd6ktjfH9DjuCugLjq842M TKe7GX76k23t902w9Un0HOq4ZVIUjN3x0AgBs= 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:references:to:in-reply-to:message-id; bh=n3jLwXIchCh8cThFBjnJWX2BKPELB/IMn5mvV2hYqcY=; b=Lky5/IPU4/8XHsQNSdn6qHrcvq41ltZ7/8Vp04p9HuKjjOXfrAyQGw9gK0mmmY0d9S SnFuWFUcdL6wOEz9PopYCN3PzhPJDUO2jKYxEiRWOd7spr6j/BK9oEswNQnl+wz85O1S chvxQxJrUxibKuroGEHhtr6+QHsVSz14Is1GDaYcQliL8bbjACwBu9A1Icaw6dS31NRY 5PiQDNvKFGTfK2j6wm2L5tPw18AkUxc1TILdtqPhpGs5hjfffib9UKL9mB0XJRlbOpCD TMPkv1D+dKrDRpuO2zLYNQxZW1gCqzJaXFfuwj+ozC7IHRDggPgUvJJsgeeGDnadNNsF +yBg== X-Gm-Message-State: AOUpUlESF/AilNR4SMPUfqloTw9kwmmj/vKuolCH+BHk1UwasIlhICRT ZsRzw9hehifBfq/4JNfbE2YM4DWqN5o= X-Google-Smtp-Source: AAOMgpe7WXQZmHcIFEV113cFD3j2PG6FJfLD9VO0mmmdmgVEN5jOn7eYgdpYTl9BJ7Fcgdf0+wyuHw== X-Received: by 2002:ac8:3885:: with SMTP id f5-v6mr9685572qtc.337.1531581850423; Sat, 14 Jul 2018 08:24:10 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id z1-v6sm5840908qta.19.2018.07.14.08.24.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jul 2018 08:24:09 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 14 Jul 2018 11:24:07 -0400 References: To: rfcplusplus@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Rfcplusplus] RFC++@IETF 102 agenda posted X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 15:24:20 -0000 The agenda and material, when it is uploaded, will be available here: https://datatracker.ietf.org/wg/rfcplusplus/meetings/ spt > On Jul 14, 2018, at 09:35, Sean Turner wrote: >=20 > All, >=20 > we have finally posted the agenda for the RFC++ BOF scheduled for = Monday from 1810-1940 in the Laurier room. Apologies for being tardy = with the agenda, but the ongoing discussions have been helpful while = pulling our thoughts together about how we would like to organize the = BOF. As you will notice, the chairs are doing most of the presenting = prior to the discussion. We felt this would yield the best results = because both chairs are going to be neutral and not drive an agenda, = i.e., we are just facilitating the discussion. Our plan is to do the = typical administrativa, provide some background for those who might not = be so steeped in IETF processes, and finally ask some questions that = hopefully bound the discussion. We are sure that we will not capture = every subtle nuance the way every BOF participant would want it = presented, but that is what the mic line is for. >=20 > We do however want to thank those who offered to present. >=20 > Cheers, >=20 > Gonzalo and Sean From nobody Sat Jul 14 08:28:21 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1078130EF9 for ; Sat, 14 Jul 2018 08:28:19 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 NugwvFwmcJU5 for ; Sat, 14 Jul 2018 08:28:18 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 3F151130E12 for ; Sat, 14 Jul 2018 08:28:18 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 188-v6so15318693ita.5 for ; Sat, 14 Jul 2018 08:28:18 -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=POpCJ3dKy/NYEZQp63K1nxKZYs2QWlKSVr0oafqNEQ8=; b=egwEj78QWXXal1+WUWsZ1FKwuM4HKiKER50RqgiAJzeNHHMxDwtbVBGagmu1jl8Xcm 4UEZNBT3pXRqop9o8iW38fkNSgx2Q5pDgCmo8KOgW9FlxYN3fwlpD7xCMol8eGN7m/VQ oLrBNKNo+Cm979ESARFVA1zL65tt51/FeF/u2+kfIk/zUwLFaLy1lGEOuNwaGJEdms8i aY/G5vsOULFUvzKBKnc5DTgO6gPeUkAjvSFdNEX50ndwzS/2Oj+yMP7xsc2/g132sRJ5 smq4K4Oq3s7vxwPW0EMRoREKJ3R/U13i3QQnWBook40/Ok+Dw8S7cYpTTgFV3TRkm4l4 dJgQ== 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=POpCJ3dKy/NYEZQp63K1nxKZYs2QWlKSVr0oafqNEQ8=; b=T8fKecZ1t/wOtJ+dSz7LQir5BXqEVDvm8jftHgrnKb+VbP9IdUKUceZjmTy5uis3Pk 8i9AwF/2vI7/h86ADEaIJ6YNn7XW/e7MOVC4H01+z7hd6YoI6SmSLfOWssev+Vfi11bF GBaO+/1cYKdq92srKhMi3r5KD3P58WtNJWJkVfMXb3oVD1/7o34946P/7XjnceSY5zbN 2HGXe3Ek6f8Osy+pK9H2s+wWTaeet/ufAxJwo7Yyff7FskN3Gq6KZPTmGX/HoguvbNDH tXyXIQ8cWrV517FzGhBrTv4EF9pPNnsaJ00OMPQ15WiugcOfQcnWno3T+QEXND3GrL/l nBHA== X-Gm-Message-State: AOUpUlHY/HNxaybZBnulkbU7CIZn4xq2cdKYG9+B4sUAhNfA2VOGmiEW 0Dm5zYLtdCvDHRqABcbjSxcwMQ== X-Google-Smtp-Source: AAOMgpeak43CQuHIrQ+5q8X2hpN/mMdx9ZaiE7ADp6CXOT1cc9T9psCwIDhT/kEz6qE/fHd8/1qJVQ== X-Received: by 2002:a02:8895:: with SMTP id n21-v6mr8920384jaj.21.1531582097433; Sat, 14 Jul 2018 08:28:17 -0700 (PDT) Received: from [10.255.239.101] ([207.164.22.51]) by smtp.gmail.com with ESMTPSA id q5-v6sm8204399iop.12.2018.07.14.08.28.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jul 2018 08:28:16 -0700 (PDT) To: Ted Hardie Cc: Adam Roach , Allison Mankin , "Rfcplusplus@ietf.org" References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> <0eefb84e-1a2b-4bbe-9e33-35a49b4db161@gmail.com> <97585f4a-1761-762c-83d7-15284364e46e@gmail.com> <47e90834-aa80-3325-920e-8bcc12c604d2@gmail.com> From: Brian E Carpenter Message-ID: Date: Sun, 15 Jul 2018 03:28:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 15:28:20 -0000 Well, in British, chucking out is what the bouncer does to you when you a= nnoy the other drinkers in a pub. I don't think it's a bad analogy. Anywa= y, let's aim at a polite and productive discussion Monday afternoon. Regards Brian On 14/07/2018 02:34, Ted Hardie wrote: > Howdy, >=20 > On Thu, Jul 12, 2018 at 10:12 PM, Brian E Carpenter > wrote: >=20 > > The proposed difference is in the label which is applied during > > the experiment, nothing more. >=20 > They would be denied the use of the abbreviation RFC and an RFC num= ber > in the series that was started in 1969, and presumably therefore > of the ISSN number and a DOI in the same family. >=20 > That is chucking out of the RFC series as far as I'm concerned. It > couldn't be plainer. >=20 > Regards > =C2=A0 =C2=A0Brian >=20 >=20 > Well, language is a funny thing, and it may well evolve to where this m= eaning is common.=C2=A0 Who knows?=C2=A0 It may even evolve to the point = where the barkeeps in Westerns have the bouncers experimentally relabel b= ad guys through plate glass windows for comic effect.*=C2=A0 >=20 > In the mean time, I must disagree with this characterization.=C2=A0 As = an author of a document recently adopted by one of the relevant streams, = I don't think relabeling the document would chuck me out of the conversat= ion, and, even if it has the effect of muting my voice, the aim of the ex= periment is to rollback the status of any documents which experience that= impact. >=20 > regards, >=20 > Ted >=20 > *At the time of writing the Urban Dictionary had no direct entry for "c= hucking out", so there is the opportunity to enter "experimentally relabe= l" there, if you care to.=C2=A0 At the worst, it would mean you could buy= a mug with your definition on it. >=20 >=20 From nobody Sat Jul 14 09:52:36 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8216130E08 for ; Sat, 14 Jul 2018 09:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 dsKI6F5iE7XD for ; Sat, 14 Jul 2018 09:52:32 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5595130DD0 for ; Sat, 14 Jul 2018 09:52:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 0FEB61C907C; Sat, 14 Jul 2018 09:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3wadqF3GfUq; Sat, 14 Jul 2018 09:52:24 -0700 (PDT) Received: from [10.119.75.38] (unknown [23.81.209.167]) by c8a.amsl.com (Postfix) with ESMTPSA id CC7711C6632; Sat, 14 Jul 2018 09:52:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Heather Flanagan X-Mailer: iPad Mail (15G77) In-Reply-To: <1986638168567223C132B119@PSB> Date: Sat, 14 Jul 2018 12:52:30 -0400 Cc: Rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4F906BDF-CDD4-488A-B057-BCBCE877E48B@rfc-editor.org> References: <1986638168567223C132B119@PSB> To: John C Klensin Archived-At: Subject: Re: [Rfcplusplus] draft-klensin-rfcplusplus-alternatives-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 16:52:35 -0000 > On Jul 14, 2018, at 10:02, John C Klensin wrote: > ... >=20 > Alissa agreed to allowing it to be posted between the cutoff and > Monday if I sent it to her. I did that at around 19:48 UTC > yesterday. It apparently has not been posted yet, I assume > because of the very busy schedule of the IETF Chair. If she > continues to not have time, I'll post it to this list late > afternoon Montreal time today and then just go through the > normal procedure for the repository. >=20 FYI, I just saw Alissa. She=E2=80=99s sent the draft on to the Secretariat f= or posting.=20 -Heather > I hope at least a few people find it helpful. >=20 > best, > john >=20 >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 From nobody Sat Jul 14 10:28:11 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F88D130E00 for ; Sat, 14 Jul 2018 10:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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=cooperw.in header.b=luoAlVLC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QRDoM2QQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZE9RuO_xDUO for ; Sat, 14 Jul 2018 10:28:06 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA6D128CF3 for ; Sat, 14 Jul 2018 10:28:05 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 26D9820365; Sat, 14 Jul 2018 13:28:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sat, 14 Jul 2018 13:28:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=KH1J8LUX6YrbnBvK7vSinU0r5nA5u EI8RqVM/kBR/VQ=; b=luoAlVLCKEDkTyHWZjJpCBAP4Y9mHba23vHBzMDo/vYik Q2NkDdHknaOTc595sSVKZjt2RtkvXU3xPOVEpNP9IsiQlyDwLnEg/2Z4bD6HA72L CBVo0T4DY9+Ae4SEIa0Xj6boVaJmGhVacXRXllv9ap94flVgrnzhM4MLbBFDxP4p hLbyZHNfKe4KWwNN/NqByMoAPBYfhAPZSLx3sxLfYo4wf1aGL1OnzGnBRXUk7q2P jVyGK2j4hsHq92/4g7nNbEHqL049ONuQpSiPv4TNJb4ABDHONOj3Qjjj2paaBmJ7 YGn/6kNGnmkKLx4/lgnB4x9iS+ZCI20ifAvIt9YeA== 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=KH1J8L UX6YrbnBvK7vSinU0r5nA5uEI8RqVM/kBR/VQ=; b=QRDoM2QQT61wUfsnq2QOTV v1Y+kKhfl+o97u90KGvb7AFj/OkBUE4LjvRyHPPHIzB96ltgVFtLdAr2xti7kdvc WMor+DlveBUug1ZUEv/3JgjoDHfz5hhx1lJs+gVCwm7gDZTd335cTqAo70yoCsjG QrAK28MXB9x4Gm+abLHPVN28pwphXSXcYkjU0gMFie2/5VLsdS5/9HHxWH+WeJJk Xh24/guwqsfOxPl5kYEBE4GgY0OiufElRA0OqReTrrv0YoPFY2EHqJO3UcKiD6Tg zCNWIr6/T2fQOkIlWYmL7NXopFGoiifiID3hoU4FEqBuJclngCadyT8EGdlFgf/A == X-ME-Proxy: X-ME-Sender: Received: from rtp-vpn1-1641.cisco.com (unknown [173.38.117.92]) by mail.messagingengine.com (Postfix) with ESMTPA id 32289E4072; Sat, 14 Jul 2018 13:28:04 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <4F906BDF-CDD4-488A-B057-BCBCE877E48B@rfc-editor.org> Date: Sat, 14 Jul 2018 13:28:02 -0400 Cc: John C Klensin , Rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5183324A-E8CD-4D68-B18A-654231D7FAB5@cooperw.in> References: <1986638168567223C132B119@PSB> <4F906BDF-CDD4-488A-B057-BCBCE877E48B@rfc-editor.org> To: Heather Flanagan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Rfcplusplus] draft-klensin-rfcplusplus-alternatives-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 17:28:09 -0000 > On Jul 14, 2018, at 12:52 PM, Heather Flanagan = wrote: >=20 >=20 >=20 >> On Jul 14, 2018, at 10:02, John C Klensin wrote: >> ... >>=20 >> Alissa agreed to allowing it to be posted between the cutoff and >> Monday if I sent it to her. I did that at around 19:48 UTC >> yesterday. It apparently has not been posted yet, I assume >> because of the very busy schedule of the IETF Chair. If she >> continues to not have time, I'll post it to this list late >> afternoon Montreal time today and then just go through the >> normal procedure for the repository. >>=20 >=20 > FYI, I just saw Alissa. She=E2=80=99s sent the draft on to the = Secretariat for posting.=20 Yep sent it yesterday and just checked with them and they will get it = posted. Alissa >=20 > -Heather >=20 >> I hope at least a few people find it helpful. >>=20 >> best, >> john >>=20 >>=20 >>=20 >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >>=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Sat Jul 14 10:37:26 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ACD130E60 for ; Sat, 14 Jul 2018 10:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 8O2dnJwp7CKR for ; Sat, 14 Jul 2018 10:37:22 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24DE9130E1A for ; Sat, 14 Jul 2018 10:37:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 551841C92B8; Sat, 14 Jul 2018 10:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h35Inq32_pH9; Sat, 14 Jul 2018 10:37:14 -0700 (PDT) Received: from [10.119.75.38] (unknown [23.81.209.167]) by c8a.amsl.com (Postfix) with ESMTPSA id F26C11C6632; Sat, 14 Jul 2018 10:37:13 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0D35BB37-4437-44AC-97A5-D32A28FEABE6 Mime-Version: 1.0 (1.0) From: Heather Flanagan X-Mailer: iPad Mail (15G77) In-Reply-To: <5183324A-E8CD-4D68-B18A-654231D7FAB5@cooperw.in> Date: Sat, 14 Jul 2018 13:37:20 -0400 Cc: John C Klensin , Rfcplusplus@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <218C0EB6-E458-4742-B99D-654C0C8EEF23@rfc-editor.org> References: <1986638168567223C132B119@PSB> <4F906BDF-CDD4-488A-B057-BCBCE877E48B@rfc-editor.org> <5183324A-E8CD-4D68-B18A-654231D7FAB5@cooperw.in> To: Alissa Cooper Archived-At: Subject: Re: [Rfcplusplus] draft-klensin-rfcplusplus-alternatives-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 17:37:25 -0000 --Apple-Mail-0D35BB37-4437-44AC-97A5-D32A28FEABE6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable https://datatracker.ietf.org/doc/draft-klensin-rfcplusplus-alternatives/?inc= lude_text=3D1 Sent from my iPad > On Jul 14, 2018, at 13:28, Alissa Cooper wrote: >=20 >=20 >=20 >> On Jul 14, 2018, at 12:52 PM, Heather Flanagan wrote= : >>=20 >>=20 >>=20 >>> On Jul 14, 2018, at 10:02, John C Klensin wrote: >>> ... >>>=20 >>> Alissa agreed to allowing it to be posted between the cutoff and >>> Monday if I sent it to her. I did that at around 19:48 UTC >>> yesterday. It apparently has not been posted yet, I assume >>> because of the very busy schedule of the IETF Chair. If she >>> continues to not have time, I'll post it to this list late >>> afternoon Montreal time today and then just go through the >>> normal procedure for the repository. >>>=20 >>=20 >> FYI, I just saw Alissa. She=E2=80=99s sent the draft on to the Secretaria= t for posting.=20 >=20 > Yep sent it yesterday and just checked with them and they will get it post= ed. >=20 > Alissa >=20 >>=20 >> -Heather >>=20 >>> I hope at least a few people find it helpful. >>>=20 >>> best, >>> john >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Rfcplusplus mailing list >>> Rfcplusplus@ietf.org >>> https://www.ietf.org/mailman/listinfo/rfcplusplus >>>=20 >>=20 >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 --Apple-Mail-0D35BB37-4437-44AC-97A5-D32A28FEABE6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable https://datatrack= er.ietf.org/doc/draft-klensin-rfcplusplus-alternatives/?include_text=3D1=

Sent from my iPad

On Ju= l 14, 2018, at 13:28, Alissa Cooper <alissa@cooperw.in> wrote:



On Jul 1= 4, 2018, at 12:52 PM, Heather Flanagan <rse@rfc-editor.org> wrote:



On Jul 14, 2018,= at 10:02, John C Klensin <john-ietf= @jck.com> wrote:
...

<= /blockquote>
Alissa agreed to allowing it to be posted between the cutoff and
Monday if I sent it to her.  I did that at around 19:48 UT= C
yesterday.  It apparently has not been posted yet, I= assume
because of the very busy schedule of the IETF Chai= r.  If she
continues to not have time, I'll post it t= o this list late
afternoon Montreal time today and then ju= st go through the
normal procedure for the repository.

=
FYI, I just sa= w Alissa. She=E2=80=99s sent the draft on to the Secretariat for posting.

Yep sent it yesterday and just c= hecked with them and they will get it posted.

Alissa

=
-Heather

I hope at least a few people find= it helpful.
<= blockquote type=3D"cite">
best,
&= nbsp;john


_______________________________________________
R= fcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfc= plusplus
<= blockquote type=3D"cite">

_______________________________________________
<= blockquote type=3D"cite">Rfcplusplus mailing list
R= fcplusplus@ietf.org
https://www= .ietf.org/mailman/listinfo/rfcplusplus

= --Apple-Mail-0D35BB37-4437-44AC-97A5-D32A28FEABE6-- From nobody Sat Jul 14 10:53:26 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B29B130EA6 for ; Sat, 14 Jul 2018 10:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 E0lEr3CmzJQY for ; Sat, 14 Jul 2018 10:53:21 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 A00E3130E96 for ; Sat, 14 Jul 2018 10:53:21 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id k12-v6so67788721oiw.8 for ; Sat, 14 Jul 2018 10:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8LSCRoGFO7tLPmfif3f1xa5mPcVaUiLRhmpnBnfyGog=; b=CiqgAnml1yV5Vcg8uVR1rBgFKyXmKdfGQpjkjaUL3JmOa5XSvzYMQr/CyjePvHWNU7 EYzuggzr+8dUp4qucQ+0q2/yvvCljqo5ahLM+mbt62OlV92l+fcrIqYeLcjr337OVUDO HZvsSRqZL16ufYp450dzVchl3aqlMf7M/DWbyM62EEOQ9rZ6hQRNb47Skk26LgJxrXCj Ib8i9Eio2T+nDWyJqMeUxz/8UNGDMOmt01NJcMT/fie0CvoWllBbORXPkuTN/ab75wXK KlQsVIkC7sAwQLVbxQG5lm0MJAilxKGKzJn6kVkjjPEFZoRWY6n6c0HuEiyyIzZpQvZ+ hJ1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8LSCRoGFO7tLPmfif3f1xa5mPcVaUiLRhmpnBnfyGog=; b=WLYVDxvCrmnRtWtbf4qp8J2SozrSfDaoe8jFTDy+FNRWhCnsvnEk+tFQHeUFJepBuo /nvO6jCD4jA1VJPEybDZrFzX6ELyN8XVsWGpZspPWACZ8XKedTZI9c5gxOz8wcBTyWaz rjjF+Ou/4jUM6TdVlRLLdYQpM3oWMO4znKR/z7KA2nQ3awx9EH4I+JM65My4uA2H5OFn xbwRBxqg+P9Gg+K6LHa0Ss0ksuGW1qJpmxS4tjN/Za7EYkfnuuCv3vCA8I+TEljt/JbY C8aG+r0BlstO+Ec/0s9U3Ve81SqV3OKcbQdSsh4KjRuMzc6gBZN3GgOadoH6/XUgefNm TkNg== X-Gm-Message-State: AOUpUlFHN+Fjp8KoRdFXTtltxzEnBYmpcmMeUqQ7fo4Bg0TPcB2C3Tu0 NyDpACGgEKOfmxSo5zyBpZLjio3/5OjxSbhZqgU= X-Google-Smtp-Source: AAOMgpdC53atNHyw+iRPMXbwt4IoS8Lfc4zns5WYhz6juol/5txpyX5IBsJoO82gFkkm3Y00vQkkbZeGg0yHGQjj4Ds= X-Received: by 2002:aca:ddd4:: with SMTP id u203-v6mr12441147oig.204.1531590800972; Sat, 14 Jul 2018 10:53:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c2:0:0:0:0:0 with HTTP; Sat, 14 Jul 2018 10:53:00 -0700 (PDT) In-Reply-To: <1986638168567223C132B119@PSB> References: <1986638168567223C132B119@PSB> From: "Andrew G. Malis" Date: Sat, 14 Jul 2018 13:53:00 -0400 Message-ID: To: John C Klensin Cc: Rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000a225b70570f94581" Archived-At: Subject: Re: [Rfcplusplus] draft-klensin-rfcplusplus-alternatives-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 17:53:24 -0000 --000000000000a225b70570f94581 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable John, Thanks, I just read the draft. It=E2=80=99s a nice enumeration of possible solutions assuming the IETF agrees that there=E2=80=99s a problem. Given th= at whatever solutoin is chosen is intended to be a limited-time experiement, each of the solutions should include the way to back out of it at the conclusion of the experiment, and also criteria to detemine whether or not the experiment was a succsss or failure. If backing out is impossible, that should be mentioned (as you did in sections 2 and 6). Cheers, Andy On Sat, Jul 14, 2018 at 10:02 AM, John C Klensin wrote: > Hi. > > As suggested by one of my comments to the list several days ago > and in the hope that it will help with the discussions, I've put > together an Internet Draft that attempts to summarize some major > categories of proposals so far. The draft largely sets the > issues of problem statement and whether there is a problem work > solving aside and looks at possible solutions (including one > very radical one not explicitly proposed yet, at least in any > message I've seen). > > Alissa agreed to allowing it to be posted between the cutoff and > Monday if I sent it to her. I did that at around 19:48 UTC > yesterday. It apparently has not been posted yet, I assume > because of the very busy schedule of the IETF Chair. If she > continues to not have time, I'll post it to this list late > afternoon Montreal time today and then just go through the > normal procedure for the repository. > > I hope at least a few people find it helpful. > > best, > john > > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --000000000000a225b70570f94581 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
John,

Thanks, I just read the draft. It= =E2=80=99s a nice enumeration of possible solutions assuming the IETF agree= s that there=E2=80=99s a problem. Given that whatever solutoin is chosen is= intended to be a limited-time experiement, each of the solutions should in= clude the way to back out of it at the conclusion of the experiment, and al= so criteria to detemine whether or not the experiment was a succsss or fail= ure. If backing out is impossible, that should be mentioned (as you did in = sections 2 and 6).=C2=A0

Cheers,
Andy


On Sat, Jul 14, 2018 at 10:02 AM, John C Klensin &= lt;john-ietf@jck.com= > wrote:
Hi.

As suggested by one of my comments to the list several days ago
and in the hope that it will help with the discussions, I've put
together an Internet Draft that attempts to summarize some major
categories of proposals so far.=C2=A0 The draft largely sets the
issues of problem statement and whether there is a problem work
solving aside and looks at possible solutions (including one
very radical one not explicitly proposed yet, at least in any
message I've seen).

Alissa agreed to allowing it to be posted between the cutoff and
Monday if I sent it to her.=C2=A0 I did that at around 19:48 UTC
yesterday.=C2=A0 It apparently has not been posted yet, I assume
because of the very busy schedule of the IETF Chair.=C2=A0 If she
continues to not have time, I'll post it to this list late
afternoon Montreal time today and then just go through the
normal procedure for the repository.

I hope at least a few people find it helpful.

best,
=C2=A0 =C2=A0 john



_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus

--000000000000a225b70570f94581-- From nobody Sat Jul 14 11:55:51 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387E4130E6A for ; Sat, 14 Jul 2018 11:55:50 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 tPEMNWF5XLBg for ; Sat, 14 Jul 2018 11:55:48 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6B2130DC2 for ; Sat, 14 Jul 2018 11:55:48 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fePhq-000JZy-SE; Sat, 14 Jul 2018 14:55:46 -0400 Date: Sat, 14 Jul 2018 14:55:40 -0400 From: John C Klensin To: "Andrew G. Malis" cc: Rfcplusplus@ietf.org Message-ID: <3999518B904EE0C559977E18@PSB> In-Reply-To: References: <1986638168567223C132B119@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfcplusplus] draft-klensin-rfcplusplus-alternatives-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 18:55:50 -0000 --On Saturday, July 14, 2018 13:53 -0400 "Andrew G. Malis" wrote: > John, > > Thanks, I just read the draft. It's a nice enumeration of > possible solutions assuming the IETF agrees that there's a > problem. Given that whatever solutoin is chosen is intended to > be a limited-time experiement, each of the solutions should > include the way to back out of it at the conclusion of the > experiment, and also criteria to detemine whether or not the > experiment was a succsss or failure. If backing out is > impossible, that should be mentioned (as you did in sections 2 > and 6). Andy, Thanks for the kind words. Agreed about back out strategies. >From my point of view, there are three elements to a decision to actually do anything here: (1) Determining that there is actually a problem that is significant enough to need a fix. I quite explicitly avoided going there, not because it isn't important but because I'm not at all convinced (and, as I at least hinted in the document, I specifically believe that trying to reason forward from RFC 1796 without a careful analysis of the effects of relatively recent boilerplate changes doesn't hold water) and hence not the person to identify, much less advocate for, the perceived problems. (2) Sorting through possible solutions to see both if they have a good chance of solving those problems and to understand the costs of deploying and/or experimenting with them. The document was intended to help with at least parts of that. (3) Actually designing any experiments so we have a clear understanding of the back out strategy, its costs, and any residual damage. I see Brian's qualifier suffixes as the least complex to back away from of things that have been proposed, but even it is not cost or risk-free, especially when one considers citations to documents from well outside our community and the amount of planning and ongoing effort it will take to keep such citations or links working. Again, the draft addresses parts of that, but only slightly. The draft took more time than I had but was still a fairly hasty piece of work (which is one reason why some of the issues are better covered for some possibilities than others). One topic I hope we can discuss post-BoF is whether a revised version of it is likely to have lasting value (in which case I'll be looking for collaborators/ co-authors) or whether it will have served its purpose by then and we can move on. best, john From nobody Sat Jul 14 22:11:27 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46B3130F3F for ; Sat, 14 Jul 2018 22:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 g9uDEHksWtUB for ; Sat, 14 Jul 2018 22:11:22 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0120.outbound.protection.outlook.com [104.47.92.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613F5130F32 for ; Sat, 14 Jul 2018 22:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CY/c+2b8k65S1L3CcgixuNNTEUqtZPROQA/p80iNfpI=; b=H7kgNrJaXNscyca2VJ0Xezp4wgx9APnzjpsEWhxbPQ2KEqGVROR72eFZfZRGNK/4uDBihuOkXRmhKgpXM4euM95ocptAlWPMcRRfdSNwtDK4m3tR7Js2pJbMujnJoA0dMRPBFmKaEu9Nd2gySCCMz235KAlXTjae3N4dvdZyjJw= Received: from [133.2.210.64] (133.2.210.64) by TYXPR01MB1550.jpnprd01.prod.outlook.com (2603:1096:403:d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.17; Sun, 15 Jul 2018 05:11:20 +0000 To: Sean Turner , rfcplusplus@ietf.org References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <52f5ccfb-c2d8-b612-474c-2ee4f83bb32f@it.aoyama.ac.jp> Date: Sun, 15 Jul 2018 14:11:15 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0120.jpnprd01.prod.outlook.com (2603:1096:602::14) To TYXPR01MB1550.jpnprd01.prod.outlook.com (2603:1096:403:d::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a5e6af54-d527-4816-ac3e-08d5ea1166e5 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600053)(711020)(2017052603328)(7153060)(7193020); SRVR:TYXPR01MB1550; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB1550; 3:FE6yLva8rQ4XLCgX50j0nV4R4PXh6JgfduqW7auxLB52aaI/cICCmVdAULD5Qq+aL0o7FcGuZvxNaSAboF1oo8uomQ8DFsLnwapBjTJha3EQNzxAQ8hMlvlPYhwmcLm85rXewk8qs2PZJxEKyxhd744Xgij/nbKgwHaqo4xhu7jlr+ioBUAv1+/QKA/Fo7C4ElqOl6fAT8AI55oeIR12/+YxEW6ETwhEuDNxLnSD7wPmhCxO3SZvjJKVcwaMdX7t; 25:fRcBIHUl43jx3ubjPU0RViKw2PfmDSm0DmEdXeLQCB0a+1bf0ZFyT8D/seNdAsQt59JcdjEfSLwG1n4PY2gZHjSGWUsNIiwAFic6xpR2sPqOBkVkPtDoRQlogRheY5ZFdPL3coUD/aLM5vMkXOKVyo2hmoiw6eTJnOmeVa0QAB7/8MuWra/JFdQX0mvjHxS1NiSDxuujmXWSRWu5rRpk/a8ZxPFu4kfl1de3qw8HaSkc3v+pNzYaqefOelbKQVircVa4mrjjrPDgdv4SXYERxff+sjmXdVVFSTRt1uolUuv3e/RMh4MPJfLUK9GHUkzr1iFpr7Khp2leo2UYXV+6tA==; 31:mUC7tzg6mFn1kO9sliPSddfBZrgXGlyU2jbF83pCiYMqeCn3lKqTUo8ZwWO4dXwiJxlrwHO76dYviyQXDNRekMcOWFP4dKTs04zARnPHbXhjhHHJ3JGxSLddCmI8RE2RloPSJAk8KGknZvCDQQPUFpod4Vj55+TpRhaJA7DXkeczvgIALGW//xZjEedbOqpI2a0hOyNaBcGyNW4QOI268ECKCvYyIs4wZLRmq51penw= X-MS-TrafficTypeDiagnostic: TYXPR01MB1550: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:TYXPR01MB1550; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB1550; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB1550; 4:PUpPFaUFrNb+7g2yBZabyXUEzxzGdaw4os8MxRbwdPFPHIovZaWcFx1S+aqtDnHjQE7xoMORBA3Mf9SpmWS6IFjRs3Ry7QSsA5cLl86OChyBiMEiBzBeJ37k3cUffUW5IJXiWbw4FR5UMCuZtzAx83PFFOaJUn3if9NkxeGVO6EIfpBfQE7ifbXzrd44Z8UKIbgadLGl3/0qAHcx+tSZABrhFAn7bqXPebYMAxOVRuflfWETbaDU/39UyIQe+qkK7oAkOAJdINpQ1UqAJPG2xztTKpyvq2gXMcds/2K20iTicrJvdbmkq11xAvx2PPMm X-Forefront-PRVS: 07349BFAD2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(346002)(136003)(376002)(366004)(396003)(39830400003)(199004)(189003)(6116002)(3846002)(956004)(2616005)(476003)(11346002)(5660300001)(478600001)(446003)(486006)(6486002)(31686004)(64126003)(97736004)(229853002)(86362001)(47776003)(31696002)(6666003)(6306002)(68736007)(14444005)(786003)(53546011)(52146003)(16576012)(53936002)(8936002)(81166006)(25786009)(67846002)(81156014)(49976009)(74482002)(316002)(76176011)(23676004)(36916002)(52116002)(2906002)(186003)(26005)(16526019)(65826007)(6246003)(66066001)(2486003)(65806001)(65956001)(305945005)(7736002)(106356001)(50466002)(8676002)(966005)(58126008)(105586002)(2870700001)(386003)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB1550; H:[133.2.210.64]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIxNTUwOzIzOk5rbXVqVSsveXUwSjFIVURQcjRNWTU1NlFz?= =?utf-8?B?Ukg3cE1hN3k1K2FvS2VPSkRCRk85TWZZUW83M1I3MDI5NFFrNjhGSGZBM1l2?= =?utf-8?B?cVNsUUZaVU8xbTVFOHdTdm5SZDlMTnNSbUlpNnFPSUxadWVkMUpMVGc3Smt6?= =?utf-8?B?TzM4angxWVZOWEYzRllrc2owWEJUU2hTUldpVzlHRzY0MFZjWGtDNFZHV3dZ?= =?utf-8?B?akdxSmR1bXNDSDhGOXFXRUdGN0FCVmFlT1JENk5ST25KVW05VkxiK1NrMzhS?= =?utf-8?B?am53SFFYMkl0K0h5NExsQ0NnaDErZWd6QTQwcit2eGN2Z0taQU1HaDBJaEp1?= =?utf-8?B?Z2VpcG1Pekx1UGJERFRwSDRVeFFSR2UwKzhQMi9MUFZEa1VuUW5zU3ZtalpW?= =?utf-8?B?eVpZdnBkOVFZZzNtSUJLcHc2MytiUnNnL3Q5alpXRGg4YmMrelFQajQwWFNL?= =?utf-8?B?MkVqK1M3YWVPbktBTE1mNlJoWUpmVGRKc0FYUWlIL1g3MW1OUVhaRjlaaWk2?= =?utf-8?B?NjN5dEtWUFZLSkc0dDRERUl3RFBkRUdBS0RCREtlSTY1TDRhNkFhdDNDdngr?= =?utf-8?B?bFdnRGpWU1U3Z29CbW16bFFqYlpydkl1QzYzYWZES1FQNEVIT1JpOW0zU0s3?= =?utf-8?B?VHNCQkUyckpNOVZTcHl5bTUyMW1XVHNOMk5FNFlRNnFuT2VJWnJuRFRyU3Vn?= =?utf-8?B?Yk0zQU5IdUh0WWx5SHJpOEQ4RTVEVkJWUFVJdzZVdWw2OUUrNmszYUV2UWJh?= =?utf-8?B?NkMrUVRrVWlUQ0RTTTBQRHhNMHFIRTZIckpaeVYwSWJUSVhJK3picTc0ckxv?= =?utf-8?B?NnVWQnI5WEZlbjgwZTVNNUxMWGt4eXJhZTNQakNiUEtKVGQ5SkkraDFsbGYx?= =?utf-8?B?WlMwZ0xlRmVVUEZ3OVlCV3JtQUFmV3NMTVMzR2NqYlZoUE1zNkkwOUtqVTAx?= =?utf-8?B?SGRvRUt2QzMrczBCWFN6VW1pNUtqVnF0YkE1aHlKU1dPSEljb0xlSTQxZ0Vh?= =?utf-8?B?R0F3cWJvenhpTDFzMnFycHlhd2dWUm5MbjhCSGN4VjdtTDVodVhsUHBvV1pY?= =?utf-8?B?cm9pZEo5L09rM1RHVVFXYlRQTXcvSTdvbDVxQStmYzRMUm1WUW9CVHBRY2tp?= =?utf-8?B?SHhST29CU0ZCUHNvQ1FGNUx5cm1uK1IwWmdSakU1UGlOQnVJN0JIOWpFcmRl?= =?utf-8?B?K2ZoNlM3TEFib3JPZ0NFWXRHanE5NDk2Vkl4M1IvVlpOK1p2L3RTM0pFU1ZW?= =?utf-8?B?b3pxWGFZWXBpWWUrTjdORU9YWUY5Yk1QNEdERXdwY28vdUJGNitTL0lvTUVi?= =?utf-8?B?c0ExVmdnTW44Z2tnSTh3a1dVbEZYOFNsRTFaZ2ZsaDRBcWlHUC9GMk0wemlI?= =?utf-8?B?UHhGMUd6UHZBdnFtZFlnYWxuMThGVkN4UllsdC9PNzVXMWZFU3EyRW95Z29w?= =?utf-8?B?c24yaE1yY1dMdERQOHkxbG44eTdVOXBrNzhaZXpSaExhcFJtenN6c2RRdmVs?= =?utf-8?B?eVFwVnJPWm54TVhwemJnRFpqT25IY2gxcE0xSmp0Tjg0TFMxb1I2czNoR3Jk?= =?utf-8?B?Y1BicTRka3VVSkN0RWtjSlUrYmxGOFRydDdPSHdOQ3RENTNGakZEcm00WW9m?= =?utf-8?B?RU0wV3E1b0luVTBaenhKK3F1bXJwWFdNeTVOdndVNUZ4VVhHaHhKbGlNQ1ZU?= =?utf-8?B?TnhwemF2WVpjL1JXYzMzcU9RYWpreUNmV0VlSGMvaDZBd1c2MnhNbzBnQnJs?= =?utf-8?B?cmFDQkN6WUF0TEdaenlUZDk5YVhHZFJPTUR3V3NXc1ZRY2g0M3c4Wm1XcUU4?= =?utf-8?B?dzl5YmlMZXo1Y3BvVndVVHVLVFlndWxJR1NFZmpXZk9VM1hydDE2VnZqWk42?= =?utf-8?B?K0JlSTZuTFFicmcvQjZ2bVJUTVpkRzY1Um5NZk1qelQ1K3U3ZS8yc0FuOTEw?= =?utf-8?B?QS9LZ2RGdlJKaG9HWURaMUp1WXVlcDIySEY4Vjk2U2pCcGV5TDYxNEZZeWpQ?= =?utf-8?B?enFIbFNreGlYc0tUeGxNOVloQ0pDeitIUy9YSm84V1RLa05wWHdqN05NMjlS?= =?utf-8?Q?Eh/M=3D?= X-Microsoft-Antispam-Message-Info: U+TA8Svc3JYTqX1jXuGsRnFoDcZ7k4klrpQxq7p6KRrqg49xKOVzBawlRy15k4PtCLASQa5hgPDSZah26wjFF3ypmgzQ/bI+w1zrfh5kj+NAgp0aPAadT73TK1M7ku7eEi6Z26MvlpGMTOHfQ59bqxmXjDowjA3Vbbbr7gEfjtspRMU5gqHMlIm9rsXfbJDCk/wl3pe6i6v/83MESp4LX2IOBjKv38T0EUGRWXFXGD2XtK/SRf4eXr5NJXzX+hYGQEwtntMFF0GH007Q5h05RYCw+Q3Nb67oWynXO7Yz7BRHxQ8hmYZyYVLxIjJPUXMKZ4p2V8J2oj4CPSyKvl8mXAt43JwzgRiBXS8Gc5+UkdM= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB1550; 6:UFIgDNZasjwcfKdRi/RxpDqwu1btcfv0AQcNU76vnv8DPwfyxrNWLAWy0lGM9WESS8O+GKAAW7ou/KCq3h+8a4ApRTVeXhGd2GbKgbcIahiC+Y+YTllS1WQCZHjFb/2AnzFDRnclcZqgae9M/htV+c4MdpM6Ja1mObpYnDAhN2sdzQG0ZwtqrONAedHXVbyBhc4Pswsf7QIKRZkESps2xkbGgZm9/q8cdIgDe12hEDgysuj8ZMRm5cT/T6JZzhKgvdZErbz+qW7//hTdVbnJHJVkHIesmuOx2fFKqg6vf0qkrwcY4btysm/JG3lYDunWgQnWSxDj+zlLckpMHGKh2yibBArMXSBHmudFGxTt6mkTTqA3CEbVpv/9naPRzI3W7fFEUVoMmGQw/5wq9BNJXr5BOix6CikRTdsk9K5wQrWObJgfKn2eMK80anxkEadlYmONszsul2LoSxXtXmcVGg==; 5:hzgpWWLlqiuaRaxAwrhmx2OrcDO9OLfYePMoOk3L9OPkK5SH6zFTep587Y7lxTX5QowJTqaMqcvqbHcB4gGxyvHSBt8Wk5ILzJVleYGgnXAQUaJ7Kd4GUlZy6+bLY1EXlmyFvyzO2ybtSYLQM3kzRCwv8cCRtq1to+xqHZG+WVE=; 24:D1LNA4HE42C6P1xlEw8+HESIVg4lLgA2b4H+AluxBgQ/PDunCgUuw23HxD4cUBvszFBzCiaU5+Ap/I9W4MlIfXyacAzT0EkYE4g3brwlR2w= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB1550; 7:Jm9ytaD8wFdu4ID737xq/XDJmDtp6mN1njr8MmsD3+FATz+ZtJNw724e56MR+0GXyRyeBO5kKvoJr12H6rAhFysqBExHx7OozI4oOKGhtQxY4UsW9qje6zYuFZegzjpCRNcftTT9h/D8F2MoBQjlCdNYaPaIg+EMWgYXHqF0XHgZzDVPOTFas/+QHD3sx4gXC94Vhh5PBnCsobFD0VugJ/BVMNN9nbxqbwD2osMU58+Y346MnWrQp8V6/3pTwtv0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2018 05:11:20.0972 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a5e6af54-d527-4816-ac3e-08d5ea1166e5 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB1550 Archived-At: Subject: Re: [Rfcplusplus] RFC++@IETF 102 agenda posted X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 05:11:26 -0000 Hello Sean, On 2018/07/15 00:24, Sean Turner wrote: > The agenda and material, when it is uploaded, will be available here: > https://datatracker.ietf.org/wg/rfcplusplus/meetings/ When I follow the agenda link from there, I get to https://datatracker.ietf.org/doc/agenda-102-rfcplusplus/ where I see: >>>> Time: Monday - 8:10-19:40 Place: Laurier 10min administrivia - chairs 15min questions - chairs 50min discussion - all 10min wrap-up - chairs >>>> Is that what you submitted? (It doesn't match extremely well with your description below, but it might be just very rough.) If it's not, would you mind sending the agenda here, so that we all can get a look at it? (I thought that was what mail was for.) I hope the BOF can be shortened a bit :-(. Regards, Martin. > spt > >> On Jul 14, 2018, at 09:35, Sean Turner wrote: >> >> All, >> >> we have finally posted the agenda for the RFC++ BOF scheduled for Monday from 1810-1940 in the Laurier room. Apologies for being tardy with the agenda, but the ongoing discussions have been helpful while pulling our thoughts together about how we would like to organize the BOF. As you will notice, the chairs are doing most of the presenting prior to the discussion. We felt this would yield the best results because both chairs are going to be neutral and not drive an agenda, i.e., we are just facilitating the discussion. Our plan is to do the typical administrativa, provide some background for those who might not be so steeped in IETF processes, and finally ask some questions that hopefully bound the discussion. We are sure that we will not capture every subtle nuance the way every BOF participant would want it presented, but that is what the mic line is for. >> >> We do however want to thank those who offered to present. >> >> Cheers, >> >> Gonzalo and Sean > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > . > -- 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 Sun Jul 15 02:10:56 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693F6130E54 for ; Sun, 15 Jul 2018 02:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=QbV4DtKd; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=n4xqJSpq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FBQXhb-0ZUN for ; Sun, 15 Jul 2018 02:10:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 642A81277C8 for ; Sun, 15 Jul 2018 02:10:53 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.225.246.174]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id w6F9Aejn019829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2018 02:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1531645852; x=1531732252; bh=jZTthjqDmjY2yyYeIv288GsewEs4KxoPfpBixMIgA9Q=; h=Date:To:From:Subject:In-Reply-To:References; b=QbV4DtKd9mIjCpIcSl6iTHO4Miv9iT/MTXgto/CvMyg5OmfGgIE/TxYMpuTOaSrQM PEB9DzJrA0RyzOC35H18KWYEfqsPFkkrKtD8ibQukAT0mtcy0BwTgM+wHw+0U9OhoE yzOM2VgGoVF3JVSH8I0i2gp33khxQC+u/d5Fw1LE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1531645852; x=1531732252; i=@elandsys.com; bh=jZTthjqDmjY2yyYeIv288GsewEs4KxoPfpBixMIgA9Q=; h=Date:To:From:Subject:In-Reply-To:References; b=n4xqJSpqMDDLOz2sHXy9lqKnX2TONwhPHX0HXpykTVitiGWBT8JVLY07Lo0KxSs9d N9NW0MXj6oJk6G4p6MJr7Kd3cT5Lg3oGHAKAhbiMRQ5hZyNt8f6ikDkaR+vypOHgg2 1Coo9blEvcc5jEMYwhA7PCmKXHNobqAB0W/xg1LI= Message-Id: <6.2.5.6.2.20180715020005.0b9fdb10@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 15 Jul 2018 02:10:07 -0700 To: Sean Turner , rfcplusplus@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfcplusplus] RFC++@IETF 102 agenda posted X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 09:10:55 -0000 Hi Sean, At 08:24 AM 14-07-2018, Sean Turner wrote: >The agenda and material, when it is uploaded, will be available here: >https://datatracker.ietf.org/wg/rfcplusplus/meetings/ The agenda says "questions, discussions, wrap-up". Is there a list of questions and items to be discussed? Regards, S. Moonesamy From nobody Sun Jul 15 10:27:41 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CEF130E74 for ; Sun, 15 Jul 2018 10:27:39 -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] 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 uYkKOrUZcWIP for ; Sun, 15 Jul 2018 10:27:37 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 296511294D0 for ; Sun, 15 Jul 2018 10:27:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DADAE660187; Sun, 15 Jul 2018 20:27:35 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9frujBhd4zz; Sun, 15 Jul 2018 20:27:34 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 1714C66012A; Sun, 15 Jul 2018 20:27:33 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <3999518B904EE0C559977E18@PSB> Date: Sun, 15 Jul 2018 13:27:32 -0400 Cc: Rfcplusplus@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <4677A31C-2466-4E9B-A891-33130150F4DA@piuha.net> References: <1986638168567223C132B119@PSB> <3999518B904EE0C559977E18@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] draft-klensin-rfcplusplus-alternatives-00 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 17:27:40 -0000 > https://tools.ietf.org/html/draft-klensin-rfcplusplus-alternatives-00 Thanks for writing this, John, I found it a good enumeration of options. Also, I found this process reasonable: > (1) Determining that there is actually a problem > (2) Sorting through possible solutions > (3) Actually designing any experiments Jari From nobody Mon Jul 16 04:57:48 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B38130E04 for ; Mon, 16 Jul 2018 04:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 tJSFaSwR1inP for ; Mon, 16 Jul 2018 04:57:44 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0127.outbound.protection.outlook.com [104.47.93.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78EF130F63 for ; Mon, 16 Jul 2018 04:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n4N9cLaOyUyUVouSY7VXE5IXYNSGveSnk2cEXwRktWA=; b=RewQ1+Zt1lf4cOe6claWB76y0YcezqORhTd0NPD8bsFrach2bzhXmnTJPATQ2KvhNN3NjucVKYmJEPl/UjhgIVXhE5wLwbUjQbeiZWDplOfYzGcUkCG0WzXRzBCowJNjAwpLzIEG24B8mD9ipdQZOnYoG5ZMtpGoxAMssS4so2A= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB1548.jpnprd01.prod.outlook.com (2603:1096:403:4::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.18; Mon, 16 Jul 2018 11:57:41 +0000 To: rfcplusplus@ietf.org From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Mon, 16 Jul 2018 20:57:38 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OSAPR01CA0211.jpnprd01.prod.outlook.com (2603:1096:603:36::31) To TY1PR01MB1548.jpnprd01.prod.outlook.com (2603:1096:403:4::15) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fd2fa183-d7ae-4675-c88d-08d5eb1355d8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:TY1PR01MB1548; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB1548; 3:UV5qmGi/fZyHOdjhXxdgGD1hh++xRDAr9DTAwX232N30CcpKSW6Ff3UuW9EPar9CiqGcSTNE2BCNi4XuG92+qT9/6aCIREdrJuYBuZhM1WG4+KApxxallRmZz7OqhroDRePX0mk1H/nvwREH/3N0gfDeu9WYItEs6WDVL/QH9Yr53AnXjhf/8aIIbdkiUl0Kt8YdwuQsNoY68w2yZWtKsnliLoWuslviarPSE0pttA9OIMxIMTGsz+yMIj9qFWB/; 25:KS1ZDl9Jj6QUDbsE7ZpaWfYkyl5IL3MFRUkDZ8ZDjkrNAWDfmj73tKt+sLyvZ0+kOcvbbvuSTlcD/xzHs+KNdeMwm3JwXYwsf9Xy2Br6oAbdmo056tOCdfW3OeskfjS0g7+gTvAqP4A22LUqPZjl8XdaAKkeTSgtsx/rHSeg3e99W6+4BnX2pgjojHZD+Y1wDiXfZxJqEpDpRGOmq3eHOleR9BJovCNUln/B8XnsLi8ZbhrRT7Gh+iTgxTANgRJAXaPqG3x8TWexgV+YZpaczDyvsJ9LGE7xu7MSuNNDsbCwlVUSec4C/rDM2nxVXRB813zLTwnoeEOdyTTKjMdp+w==; 31:AUiP0hHgXE0C1JzPqUmH7fRTXgTJkwDh7qvCRnZumQXIEzQiIwbcnyWw6u2V5x0QsbGddfHmPHhyajCqvwXsY4/NbnFM52vcFNd79bnRcShZjOPa++DUfJ7TWBPOOge3KQcWHNL3/B/4q4U6cj7lrK4ixQnmbNOrLyFK3Sb49kktAdLbSAL5JJK1v3qPHrJ60UVLiQwSNbtH3KCMnDPbhU9b02QoeIdViwKue1GFRk4= X-MS-TrafficTypeDiagnostic: TY1PR01MB1548: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:TY1PR01MB1548; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB1548; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB1548; 4:dJ8V08RabGvS2TADCgGwIc4ArymsITCy4mvQRHjPRELWfgzsnjKIrStoUJpmCFXf41JrzKWKqshTupzxzK1DFjIF2rw3SZh4InsonEjHMU0QnHThsaWOPnYFZI7WH8hDDQjiK7aqN1YGGUncIeHZGcH97Us8HkwBkRn0KF6+4wYAIUotDmp1G6beElt5VDYNW0lf/sf5MiO4ogAbY/uDOO9aZpZd5Y91v+L7W47B2zagdLqrxUFwcECSyzg+gpjE4CuyATrn3bnpPpAntn2EIAf/ynPyXrTvKS+onTCTetmCI4Jm2X3s701GkWMbSlqn X-Forefront-PRVS: 073515755F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(346002)(39830400003)(136003)(396003)(366004)(53754006)(199004)(189003)(52146003)(6916009)(68736007)(65826007)(23676004)(478600001)(65806001)(81166006)(8676002)(86362001)(305945005)(52116002)(316002)(5660300001)(6666003)(106356001)(65956001)(66066001)(16576012)(50466002)(97736004)(8936002)(81156014)(64126003)(3846002)(6116002)(786003)(36916002)(2486003)(67846002)(31696002)(47776003)(58126008)(7736002)(476003)(16526019)(956004)(49976009)(25786009)(186003)(53936002)(486006)(230700001)(2361001)(6486002)(2351001)(2616005)(2906002)(31686004)(26005)(74482002)(386003)(105586002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB1548; H:[133.2.210.64]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIxNTQ4OzIzOkZwa0krSm9RZEVGWTlXNGNWUmdPYTU1VmVJ?= =?utf-8?B?cDFVRWh2cU9QZGU5SjIyTnc2ZjNCQ0Y3VkV2UEpQQndrZWNNSUhMaFhGTWUr?= =?utf-8?B?M2dPSkhGbm51VW9uSWs0djFrbk9OUk5jSDVrcitwdXBsUEQzc2docXdpc2E0?= =?utf-8?B?aGVNa3A2Nmh3NGxPd1hDSytzbTZnV3d3anFmaXVhaktvSjhYcXFDNWZkZVBP?= =?utf-8?B?bXYxM2EzMGhaeEtrVk54citTZ3FMeHhWcnBDZnMveS9TQXlBbmZDbUZyOFc0?= =?utf-8?B?bC9hMDhzV2lsS1lyK0Y1VU9rUUJUaFNreUQ1T2lnd21BaFRZRDBEQnJQeEla?= =?utf-8?B?MUozMkFjSk1nYUpHYnRiellEaTYxcXkxcVZYOXVOSVR5MTkwV0hXQTl4bEEx?= =?utf-8?B?dDZIb0JJS1RJdGJaWEx3RXRYdlRzQ3FVRDc1eEhyVWF5cmN4aFdsejJEYjkw?= =?utf-8?B?SWNOa1E2ZU5vVnduMDRzTjN3Si92cmxMMEppQlNLSm5wSDhCZlA5Ly92WVNl?= =?utf-8?B?WUJJMkkrZ2tkeXpFOVEvcDE2R1YxOFp6YlBEUE1DclBuYmlUOE13em82NWI2?= =?utf-8?B?UVJLT0FaWFlDOEZRa3pPZ2NnUnZwYXlzZ2RPRXJpTDR5NGkyUUxvRWlzamFH?= =?utf-8?B?Nk1pbXg4NHU2ZWJ5YlVxMU1MRWRRSFpVMC9BZU5Oem5PZ2lIcmxsQ2lCVHJR?= =?utf-8?B?OHE0ZWdnekVqZTZmUk1aNCthZnh1T3pnSUozd0RrR3FubG8zL3pmQWF1UWo1?= =?utf-8?B?M1NhQ3dVUWtydWxDV05YdUYvSnRzZ1NUaEk4anNmdDArcVk3MzlVak5JZVJk?= =?utf-8?B?SGZ2MjBtN1Fad0N0aUcwUnF1MkRDR3Y3cDJVK25QU2xmU2ZRMWllNUFmNTIr?= =?utf-8?B?SzI4bDI5akZnWUc5bjBoVTYvNE50VkJsTzZ1OHVjUVVlaW01a20yeVRDWjUr?= =?utf-8?B?OUdiaVcxNXZWN3lzZEV6WjlVZTFhTDgweWw3VEpORjRwai9LTmlYdGlKUnNo?= =?utf-8?B?SGFaQ0VXOE5QcU1lTk5DTTdsdHJKbnRSVllIT3VXc2JDNS9QelgzbE12Z3Va?= =?utf-8?B?SXNITTFRR1Z1QVJmVUpMaiszVjBFUldBYWJFNmVTaldZSGVFVmxiSUJURGZO?= =?utf-8?B?MXRhdEszakhjOWdmS1Q2Z1JWODRDOGFEUVFlelB1V3FhV1h4dGZxL0IwcHVM?= =?utf-8?B?dmFXaS9abUoxYU1McWppaGdjYmYxZkM0UXJwblhkajAybmQ0dW0zTlFyTmR1?= =?utf-8?B?blRhTm1ldVp0ZlAxS1JsM2UyTTNGK0xFUit4YWRKWW5KTjlkaEwyY3pZbEtu?= =?utf-8?B?SzMyRVBSeUh2Q1NWdXVXUjJneFZQblNsNVRXZTFKdU1ra2hmMWpuaXNCeXZs?= =?utf-8?B?VzRPK2dwbUkySVVwY0ppMmxOZis4ZEVXckJoWDhhMFhqaGNtKy9kWHMwVzRC?= =?utf-8?B?VVNBVlI4citXazc4S0hqL3pCdFR5VCtweE5wcEJxTE1iWklDT1g4bXZuVnY2?= =?utf-8?B?TERJM3NKSTNiQmdhd0QzU1NEQ0VnSkdOY2JobC8wMCsyNDBDODFyK2VGeGZ6?= =?utf-8?B?Y2kyb0NWbTdLSnhCT2hkbTVPUXdaa0FrVjl4Z1luMzVaWW5DQmY2UFVmRHl3?= =?utf-8?B?WEpKUlJIbXEwbTl1Zk11elphSDduZWZoY1BxVTMvcHRZeE1oWUVjQytlZDA4?= =?utf-8?B?MjUwNlkwcWZpcmMxU0RFZHdOd2xKb2laQjFEWW0rWHR6OStJcUZtVENMUXJo?= =?utf-8?B?WVpPbys1Wkh2ZjRFVll0TVVkYmprMmx5WldRRDg1NHk2T1lZaGZzT2ttNUhr?= =?utf-8?B?SlpjQ1FzZGEzQXdYZVpoNVVoU3pSSjZVUm5QZ2RpREVyZHplcm1sbXU4R0hV?= =?utf-8?Q?b9OCt0AkuWGISizqd8KEeqHu+yZBzLIa?= X-Microsoft-Antispam-Message-Info: 9IxRjwEgkEog7kYujW0uLxo5V+gCoxGeNTJ4gPOl5jNxNGnOGm+1AMmhX0Xu7vTCzKHSoQhoMF+KTMKHRtch8q3OzRzTfs4tZJVtpV51N4lfgJESCaSrasYTynsVvF+wXhHgcZJb6HYf4oi1ZOpi+0Fcm1MEaO1ka0IxdGdOXbU4Ca10Y7CEY1cnbbT6RHKf8CgA2jbTqDst8TdKf/GPQ1Cu8qDAwgYr5BnX72z0PnsTtRAHn60AtVU+1ZIioet15DxiGoGORRn1KsOzfWgqPxuPH3Nnh4PBYFaQfmk3ri2JLuut8KBzTICmIGWoRVKNW79/+nBkTCZcnExc5u06kP9fVcL7AHuquOdHFG1OS6A= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB1548; 6:RBZx50N7KH2PlEjdZdq3TuvyprAyVS+IWj+mVriJJ0TEQ9cQB5FtoKhZ+rY4nV75o2lrx/WNLt1PJvf51QfcwhjNZ/QKj9j0HOSb9RMwO2fxopy5oj6Z79k3gsC6uQ9Qhweqf+kR8vh3Y6cF1hbZ5V7EWBqrJIDgilVX4te+T0MsWc2RZBwOMlUF4yiYsbfN50gnCADWIE4VvMZLsL8mKmbelpIsqZXo11oKQzELloljQJO30jA0EMtAQAgV2eLiKZjMpTvjexv/PTNXh6D46MZHR55czK+nb8QouDJ1D6I52x2FR0OiUh0dkRKFuOfiO1uA/DeFFvJjRYewbCuc2mqoDkBu4TOqEhYxliA/jH88ab85KIOEZ+fnG+9gWFlTj6+dDGGckAj1pqRA+hXOeP4BD6YMSPIqi14a2AKo24m+pGuBFodgEK5w35aid/9nLQWG+v7B7iz02BTCvLRT7Q==; 5:iFRLBRMJBBsG8+lKKbFLrUKDo5oN/FDmTHZkRrO6PAHJx30MjZZXM3P5UFgo85r2Wl6W5Yd7Vmoi8lEnO6o1tEmAcqY+JmUHcITyKdoA88TeTlF7Ijdnygsd7VtKHNCYBFpCQWRU3XM71NK3GpkVBTxYLYuV5w1y9O3vuOoUJLg=; 24:ySQRXTani7jXS/O4Sz6ZDnNcPDoDwdW1fmqAdFZdSCRV3j6zykVwk69xugOmQvVoEa6khqGKEGcYvVoAbyGK/lBEm0JK7eEiZ0CDJtoMIoE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB1548; 7:Wbpys/aG57mFZviiMvxK+OWCN1r/DtcSop1XEucAZdcPij+hr0RMLFNOzw1MuFcnfxJJmvZWyjYvzlLwPF4M9UkNLrWJ2yVN4ykOs/bF2zS7W36APQ/RwuKCTP3D4XTQhcyqQEHf1IYj2Ws3iqdTgH5uu20CRIYm7r1DEv9tgMUAJ+NsGtrirtvavOt4X8O6r9nirJEwg9DBVu2XGIKKMqmYn+gzsQgpe6bqYZREy6hJwyILQfPYx29NMxZZrTnE X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jul 2018 11:57:41.9032 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fd2fa183-d7ae-4675-c88d-08d5eb1355d8 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB1548 Archived-At: Subject: [Rfcplusplus] Every standards organization has the same problems, but the IETF is proud to be different X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 11:57:47 -0000 Hello everybody, I have tried to follow the ongoing debate, but I'm apologizing if I have missed some of the contributions. This is a very rough writeup of my current thoughts, mostly centering on things that I haven't seen mentioned much. I hope it can give some additional input into the BOF, which I won't be able to attend, not even remotely, because of time zone differences. I have to admit that I'm an IETF old-timer (involved since about 1994) and also have been quite a bit involved in other standards organizations (in particular W3C as a team member from 1997 to 2005). One main thing that I think hasn't been mentioned too much is that virtually every standards organization struggles with explaining what exactly their different document categories mean, and how these relate (or don't relate) to their process. Even the best labeling cannot avoid that need for explanations, and changing labels isn't going to help that much, because it creates additional confusion. (If we introduce additional labels, and reserve "RFC" for IETF standards track documents, we will still have to explain the old usages, in addition to the new ones. And it gets even worse in case the "experiment" is canceled.) Another point is that I always saw the fact that everybody can post an Internet-Draft, and many things can become RFCs (of one category or another) as linked to the way the IETF (in the widest sense) and the Internet work. In some ways, it looks like a corollary to "We reject kings, presidents and voting. We believe in rough consensus and running code". I'm not sure I have expressed myself well, but I hope you get the ghist of it. Wishing everybody a successful BOF and a successful IETF overall (wish I could be there). Regards, Martin. From nobody Mon Jul 16 12:26:57 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DBA1311FE for ; Mon, 16 Jul 2018 12:26:47 -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] 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 cua_vDQ2FfJz for ; Mon, 16 Jul 2018 12:26:41 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id CDD781311F1 for ; Mon, 16 Jul 2018 12:26:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DDF8A660131; Mon, 16 Jul 2018 22:26:39 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWLvKpFA5KJt; Mon, 16 Jul 2018 22:26:38 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id E2DC766012A; Mon, 16 Jul 2018 22:26:37 +0300 (EEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <06ac0cc7-85e6-135d-1332-cd2e75d4640f@gmail.com> Date: Mon, 16 Jul 2018 15:26:36 -0400 Cc: "Rfcplusplus@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com> <77486708-e38d-03d3-f4d0-0f0b67797542@nostrum.com> <3d659e94-8455-f7c4-98a8-405bfda728c6@nostrum.com> <06ac0cc7-85e6-135d-1332-cd2e75d4640f@gmail.com> To: Brian E Carpenter , Allison Mankin X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] IRTF stream considerations X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:26:48 -0000 First, on the primary topic of this thread, I believe thinking what would be the best publication approach for the IRTF would be a welcome activity, to optimise the channel(s) that they best serve the researchers participating in IRTF. Then on some other topics: Brian wrote: > What I mean is > that *if* the IETF decides, by its own process, that the IETF wants > to make a change, *then* the next stage must be a serious effort to > discuss it with the rest of the community. Currently, we don't have a > clear method for that. I agree. But want to note that discussion on rfc-interest list, discussions at BOFs during IETF meetings, the plenary, and the like have=20 traditionally been tools that we use when topics related to the=20 RFC series are being discussed. Obviously, an effort should be made to reach as far as possible when there=E2=80=99s a topic for discussion. And as we know, a BOF or other gathering at an IETF is not the final decision place, no matter what gets discussed we=E2=80=99ll have to continue online for some more. Many people talked about: > controversial changes FWIW, my perception of some of the past discussions is that there was at least some level of controversy. You could perhaps argue whether that was lower or higher level than on current topic, but people seem to care about the RFC series and don=E2=80=99t always have the same opinions. Which is a good thing :-) Jari From nobody Mon Jul 16 14:03:50 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB871311CA for ; Mon, 16 Jul 2018 14:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thinkingcat.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 dHQ9zwrHBbcS for ; Mon, 16 Jul 2018 14:03:37 -0700 (PDT) Received: from pdx1-sub0-mail-a17.g.dreamhost.com (smtp15.dreamhost.com [64.90.62.184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E42713120E for ; Mon, 16 Jul 2018 14:03:37 -0700 (PDT) Received: from pdx1-sub0-mail-a17.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTP id D22427FC5E; Mon, 16 Jul 2018 14:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=thinkingcat.com; bh=facfaTp2QXHqcP SldGOqq8EbSMU=; b=PUzcYzv5FAmMZt3/1muulNOD+KPXoXFeen7m/Qr+D7RXXJ a8r0XypLho5inGJ1MZw1Dl0vkm846WDJFdT10zezGYUyuERDQNQYZXeVfLIiplOJ Afax+fctX7ltxYD+Mtyn5znaYFbMXcbqXYk9CSvQe/dBNGjASYyt7Vc5vvyJo= Received: from [31.133.144.130] (dhcp-9082.meeting.ietf.org [31.133.144.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTPSA id 233437FBF0; Mon, 16 Jul 2018 14:03:35 -0700 (PDT) From: "Leslie Daigle" To: rfcplusplus@ietf.org Date: Mon, 16 Jul 2018 17:03:26 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_96009F74-AE23-4AF5-AEE1-4212E891FB26_=" Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfcplusplus] Issues with RFCPlusPlus X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:03:48 -0000 --=_MailMate_96009F74-AE23-4AF5-AEE1-4212E891FB26_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable As someone who has her name on a number of RFCs, not the least of which=20 is RFC4844 (=E2=80=9CThe RFC Series and RFC Editor=E2=80=9D), I wanted to= share a=20 few observations. Sadly, I am not expecting to be able to make it to=20 the BoF itself, as oddly-scheduled as it is, I have competing=20 commitments. Here are the things that I think are important to consider in discussing=20 this topic, as presented: 1/ The numbers given illustrate that there is no real problem. 92% of=20 the RFCs published are from the IETF, so at a maximum, 8% of the RFCs=20 published are gaming for brand (the notional problem to be solved). 2/ If there is a real =E2=80=9Cbranding=E2=80=9D problem, then the legacy= situation=20 must be addressed as well. Solution: change the names of everything. =20 No more RFCs, just some other name for IETF-flavoured documents, and a=20 different other name for non-IETF documents. If you can=E2=80=99t discus= s=20 this proposal seriously, then the real problem you are trying to address=20 is IETF-domination, not label-branding conflation. And, the RFC Series is not the IETF=E2=80=99s: it is independent. 3/ The IAB is the shepherd of the RFC Series =E2=80=94 explicitly so that= =20 non-IETF streams have a champion that isn=E2=80=99t the IESG. Martin=20 Thomson=E2=80=99s document does not reflect that posture. There=E2=80=99= s an=20 opportunity for the IAB to review its responsibilities here. 4/ On a scale of =E2=80=9CThere are a few clouds on the horizon, perhaps = I=20 should pack an umbrella=E2=80=9D, to =E2=80=9Cthe entire IETF organizatio= n is in=20 danger of imploding because years of navel-gazing, cliquish control of=20 access to resources and alienating operators and new industry=20 players=E2=80=9D, it seems to me that this issue (if it=E2=80=99s even a = problem)=20 fits rather more to the start of the spectrum. It would honestly be helpful if the IAB would expend its creative=20 efforts on addressing the scope and focus, and, ah, architecture=20 questions facing our work: we have actual issues that are closer to the=20 rougher end of the spectrum. 5/ Why is the ISOC Board Chair co-chairing this BoF? (Hint: there=20 might be a reasonable answer, but many answers are in fact not in the=20 least bit reasonable). Leslie. --=20 ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- --=_MailMate_96009F74-AE23-4AF5-AEE1-4212E891FB26_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

As someone who has her name on a number of RFCs, not the = least of which is RFC4844 (=E2=80=9CThe RFC Series and RFC Editor=E2=80=9D= ), I wanted to share a few observations. Sadly, I am not expecting to be= able to make it to the BoF itself, as oddly-scheduled as it is, I have c= ompeting commitments.

Here are the things that I think are important to conside= r in discussing this topic, as presented:

1/ The numbers given illustrate that there is no real pro= blem. 92% of the RFCs published are from the IETF, so at a maximum, 8% of= the RFCs published are gaming for brand (the notional problem to be solv= ed).

2/ If there is a real =E2=80=9Cbranding=E2=80=9D problem,= then the legacy situation must be addressed as well. Solution: change = the names of everything. No more RFCs, just some other name for IETF-fla= voured documents, and a different other name for non-IETF documents. If = you can=E2=80=99t discuss this proposal seriously, then the real problem = you are trying to address is IETF-domination, not label-branding conflati= on.

And, the RFC Series is not the IETF=E2=80=99s: it is ind= ependent.

3/ The IAB is the shepherd of the RFC Series =E2=80=94 ex= plicitly so that non-IETF streams have a champion that isn=E2=80=99t the = IESG. Martin Thomson=E2=80=99s document does not reflect that posture. = There=E2=80=99s an opportunity for the IAB to review its responsibilitie= s here.

4/ On a scale of =E2=80=9CThere are a few clouds on the h= orizon, perhaps I should pack an umbrella=E2=80=9D, to =E2=80=9Cthe entir= e IETF organization is in danger of imploding because years of navel-gazi= ng, cliquish control of access to resources and alienating operators and = new industry players=E2=80=9D, it seems to me that this issue (if it=E2=80= =99s even a problem) fits rather more to the start of the spectrum.

=

It would honestly be helpful if the IAB would expend its = creative efforts on addressing the scope and focus, and, ah, architecture= questions facing our work: we have actual issues that are closer to the= rougher end of the spectrum.

5/ Why is the ISOC Board Chair co-chairing this BoF? (Hi= nt: there might be a reasonable answer, but many answers are in fact not= in the least bit reasonable).

Leslie.

--

Leslie Daigle
Principal, ThinkingCat Enterprises

ldaigle@thinkingcat.com

--=_MailMate_96009F74-AE23-4AF5-AEE1-4212E891FB26_=-- From nobody Mon Jul 16 15:02:12 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D24130E1E for ; Mon, 16 Jul 2018 15:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 qhHkWlNoyBDp for ; Mon, 16 Jul 2018 15:01:59 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176B5130E00 for ; Mon, 16 Jul 2018 15:01:59 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id c135-v6so14764707ywa.0 for ; Mon, 16 Jul 2018 15:01:59 -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=DgYheBPZRahgB32mhTIqfgpGArSS6UH8If0BqyLPBEc=; b=Ketnh4oFGwzq8W10MlF3J5BwJ52AOOi1EGk3eme99XttfuL3+1QDXxVmbOcR3E1kGd yRGRBynBo1tpIwN/mkaQC/BuULnA0VUJz1BuddU7W4kz1TixMj/VM6M9ROnDVMv6Eb1G cNWJ4f5Wc/V/BL4x9IjOiAvzHHzrAkR4wOPeFxH+lc1WmpzlJVizmYFT2MDKUfHX/LoS 3TyvCAj5ihMUtOGI9XARw6hB71U97tbjudTNpR3DmFK2bUBGQFhLKwiFjMmac3hkghts jfL1xG/5WVdVxl3KHuBV/zwGvoPiDH2TsFjTieZX7YBy5uA1Oy6xwI7CnF4N8dC5q4q6 hVWQ== 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=DgYheBPZRahgB32mhTIqfgpGArSS6UH8If0BqyLPBEc=; b=GeVZzqrQjCmmUq6br+XDc5GBQ75awTAWMSzLHADeB/BqtNIfnRjpdlH7mZoSSW7FZP JR5ZZPSRW/s9UiaGIkX0FwtQPQAI7mWvgLUqE2sHnZJBMkOL1u66NiNMFwGvXzu4mOrZ C5Ci55+P2Yl5W9UygiOdXpnea5e5Yf5uyT5s5V8H7MRSn4inVjGyhDKcFaJwujML0bQp 5iNYNSckZkuKZJfAVHJrYrDNoC76eeMbwLTh0zXxNpxkq9Am7G68KGmz7vbNYmbAWaol C753BM/01RpTF9P45Nc1XOVnIVtIYlkIg1e6xlpl30DTprXxNZhScmiQwFqGNzdguTBo gClA== X-Gm-Message-State: AOUpUlHmKVhJIEHHJRDsWRO2tvZeAU66SKI3CbmZFlpxgw2VbJL9AUgW Gb533rwuWmZkmhauz9y0Mh9nLCozkQnhB43ep/4= X-Google-Smtp-Source: AAOMgpeFdfu/z0ADwcVh0SvhZEDMzN8D6ZJ1oVC+8jBrM02v4knlPsKoscHglHgLIwZYfHFvffLHK2c9a9xPOS4mvPg= X-Received: by 2002:a0d:f481:: with SMTP id d123-v6mr9112764ywf.27.1531778518134; Mon, 16 Jul 2018 15:01:58 -0700 (PDT) MIME-Version: 1.0 References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> <2D7B9C1B-22D0-4B9B-BAC5-FE11AD29041B@gmail.com> In-Reply-To: <2D7B9C1B-22D0-4B9B-BAC5-FE11AD29041B@gmail.com> From: Spencer Dawkins at IETF Date: Mon, 16 Jul 2018 17:01:44 -0500 Message-ID: To: Kathleen Moriarty Cc: Eric Rescorla , John C Klensin , Alissa Cooper , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000072b5f9057124fa2b" Archived-At: Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment] X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 22:02:05 -0000 --00000000000072b5f9057124fa2b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable File under "your mileage may vary" ... On Mon, Jul 9, 2018 at 9:04 AM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > Sent from my mobile device > > On Jul 9, 2018, at 9:45 AM, Eric Rescorla wrote: > > Responding on a narrow point. > > On Mon, Jul 9, 2018 at 1:01 AM, John C Klensin wrote: > >> >> By contrast, recent years have shown us several examples of WGs >> with small numbers of active participants, all or almost all >> from the same cooperating cluster of companies and more than a >> few AD-sponsored documents that have made it through the system >> with substantially no substantive community input on IETF Last >> Call and then get through the IESG with the minimum number of >> "yes" votes and many "no objections", presumably deferring to >> the AD who made the decision to sponsor the document. >> > > I certainly wouldn't argue with the claim that many poor quality document= s > get through the IETF with minimal review, etc. However, I would be wary o= f > drawing that conclusion based on the IETF ballots.. Once a ballot is on t= he > agenda, it almost always has a Yes from the AD who put it there (whether = it > is a WG document or AD-sponsored), and so the actual effect of "Yes" and > "No-objection" is the same [0].. For that reason, I almost always ballot > No-Objection, rather than try to distinguish between the cases where I > think it's good and I just don't care [1]. My sense is that balloting > procedures vary within the IESG, but I don't think I'm unique in this > respect.. I suppose one could argue that I'm (we're) Doing It Wrong and > that the ballot procedures ought to be clarified/improved, but in any cas= e > it's not a signal that I'm just deferring to the AD. > > > For non-sponsoring ADs, a YES means they believe in the work strongly > enough that they would also be happy to sponsor it. That=E2=80=99s come = up as > important as ADs roll off. I=E2=80=99ve used no objection in a similar wa= y, but > purposefully used YES on documents as well. For no objection, it means I > trust the AD (person balloting didn=E2=80=99t have enough time), my parts= are ok > (no major security issues), or I read the document thoroughly and only ha= ve > comment level suggestions and am fine publishing it anyway. That maps we= ll > to the Alternate ballot procedure where no objection is the same as yes - > it=E2=80=99s fine to publish this. > Keeping in mind that I served on the IESG with Kathleen for four years ... I've balloted Yes on documents I wasn't responsible for, - when I thought the drafts were really the right thing to do, enough to have sponsored them if asked, - and usually, when I think I understand the document well enough to have been responsible for it (AD Evaluation, Last Call and Review Team comments, IESG Evaluation resolution ballots, and stuff like that). Someone on the first IESG I served on suggested that mindset to me, and I have no idea who that would have been now. Practice varies between ADs, at least a bit. Of course, literally the first RFC I was "responsible" for, was at Adrian Farrel's request, because he had a doc that basically everyone even marginally involved with the document was sponsored in some way by the same company, and I wasn't, so I had to ballot Yes while marginally understanding the draft, and under no delusion that I was a RTG AD or likely to be one on this planet. The details are at https://datatracker.ietf.org/doc/rfc7026/ballot/. It was ... short. Spencer --00000000000072b5f9057124fa2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
File under "your mileage may vary" ...

<= div class=3D"gmail_quote">
On Mon, Jul 9, 2018 at 9:04 AM K= athleen Moriarty <ka= thleen.moriarty.ietf@gmail.com> wrote:


Sent from my mobile device

On Jul 9, 2018, at 9:45 AM, Eric Rescorla <ekr@rtfm.com> wrote:

Responding on a narrow point.

On Mon, Jul 9,= 2018 at 1:01 AM, John C Klensin <john-ietf@jck.com> wrote:<= br>

By contrast, recent years have shown us several examples of WGs
with small numbers of active participants, all or almost all
from the same cooperating cluster of companies and more than a
few AD-sponsored documents that have made it through the system
with substantially no substantive community input on IETF Last
Call and then get through the IESG with the minimum number of
"yes" votes and many "no objections", presumably deferr= ing to
the AD who made the decision to sponsor the document.=C2=A0

I certainly wouldn't argue with the claim that ma= ny poor quality documents get through the IETF with minimal review, etc. Ho= wever, I would be wary of drawing that conclusion based on the IETF ballots= .. Once a ballot is on the agenda, it almost always has a Yes from the AD w= ho put it there (whether it is a WG document or AD-sponsored), and so the a= ctual effect of "Yes" and "No-objection" is the same [0= ].. For that reason, I almost always ballot No-Objection, rather than try t= o distinguish between the cases where I think it's good and I just don&= #39;t care [1]. My sense is that balloting procedures vary within the IESG,= but I don't think I'm unique in this respect.. I suppose one could= argue that I'm (we're)=C2=A0 Doing It Wrong and that the ballot pr= ocedures ought to be clarified/improved, but in any case it's not a sig= nal that I'm just deferring to the AD.

For non-sponsoring ADs, a YES means the= y believe in the work strongly enough that they would also be happy to spon= sor it.=C2=A0 That=E2=80=99s come up as important as ADs roll off. I=E2=80= =99ve used no objection in a similar way, but purposefully used YES on docu= ments as well. For no objection, it means I trust the AD (person balloting = didn=E2=80=99t have enough time), my parts are ok (no major security issues= ), or I read the document thoroughly and only have comment level suggestion= s and am fine publishing it anyway.=C2=A0 That maps well to the Alternate b= allot procedure where no objection is the same as yes - it=E2=80=99s fine t= o publish this.

Keeping in mind that = I served on the IESG with Kathleen for four years ...=C2=A0

<= /div>
I've balloted Yes on documents I wasn't responsible for,= =C2=A0
  • when I thought the drafts were really the right th= ing to do, enough to have sponsored them if asked,=C2=A0
  • and usuall= y, when I think I understand the document well enough to have been responsi= ble for it (AD Evaluation, Last Call and Review Team comments, IESG Evaluat= ion resolution ballots, and stuff like that).=C2=A0
Someone on the= first IESG I served on suggested that mindset to me, and I have no idea wh= o that would have been now. Practice varies between ADs, at least a bit.=C2= =A0

Of course, literally the first RFC I was &= quot;responsible" for, was at Adrian Farrel's request, because he = had a doc that basically everyone even marginally involved with the documen= t was sponsored in some way by the same company, and I wasn't, so I had= to ballot Yes while marginally understanding the draft, and under no delus= ion that I was a RTG AD or likely to be one on this planet.=C2=A0


--00000000000072b5f9057124fa2b-- From nobody Tue Jul 17 06:02:10 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8689C130DF5 for ; Tue, 17 Jul 2018 06:02:08 -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, 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 W6W43UCyj6w7 for ; Tue, 17 Jul 2018 06:02:07 -0700 (PDT) Received: from bgp.nu (bgp.nu [147.28.0.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6D0130F6F for ; Tue, 17 Jul 2018 06:02:00 -0700 (PDT) Received: from [31.133.148.87] (dhcp-9457.meeting.ietf.org [31.133.148.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTPSA id 1FD68206EC50 for ; Tue, 17 Jul 2018 09:01:59 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 From: "John G. Scudder" Mime-Version: 1.0 (1.0) Message-Id: Date: Tue, 17 Jul 2018 09:01:57 -0400 To: rfcplusplus@ietf.org X-Mailer: iPad Mail (15G77) Archived-At: Subject: [Rfcplusplus] Rfcplusplus BOF next steps? X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 13:02:09 -0000 At the very end of the meeting I heard Gonzalo say =E2=80=9Cwe have next ste= ps=E2=80=9D or similar. I was waiting for him to say what those next steps a= re, in specific, but instead he closed the meeting.=20 Whether I missed it, or whether they actually weren=E2=80=99t listed, Gonzal= o, would you mind repeating what those next steps are? Thanks. =E2=80=94John= From nobody Tue Jul 17 12:44:40 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F5D130E21 for ; Tue, 17 Jul 2018 12:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=PrffTow6; dkim=pass (1024-bit key) header.d=ericsson.com header.b=gRhg4lpg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqNQOl5tqls3 for ; Tue, 17 Jul 2018 12:44:35 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 15D65124BE5 for ; Tue, 17 Jul 2018 12:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531856673; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+wusCQXqiVlu5UqgFo2RGc8450SARx4ea8su2VtRWZ8=; b=PrffTow6qNmwKONEGuPNmZrBDg6rfkjW7TkLQ1XYfTYwBMgGHbNskO7tfclBQYSR ORkcS0w0ldDAqrkUP5doRcvU1rOZ62o+uppAOFXD+5TkOiRrLJsX8+QFEzLWllI5 bJRl87xM8a0fUiq5nN/lFBy0CpojEjlU02Bcb90JVVM=; X-AuditID: c1b4fb2d-5ecb19c0000055ff-7e-5b4e4721d9cb Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F7.2E.22015.1274E4B5; Tue, 17 Jul 2018 21:44:33 +0200 (CEST) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 17 Jul 2018 21:43:53 +0200 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 17 Jul 2018 21:43:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YlHfhjbSDle2QRN/U7OQDDwmnElMgcLgIsmMVjJiDOs=; b=gRhg4lpg/K+yz2jBYh6njlLUvuxFysceA9rBj4iMzD+/gnXePT7doaQAzwgztijyV38fgH3E8cIjzDwpjry3JPhZDZzun9XDl5hlAaVasQXsgDWKgXus3vb4gKIdfKB0hCK8g/AlpVjy+w28muuLvC4UnfX0gnxhY7s4OeO8UJw= Received: from [IPv6:2001:67c:1232:144:dd41:edb6:afe2:a8a3] (2001:67c:1232:144:dd41:edb6:afe2:a8a3) by VI1PR0701MB2109.eurprd07.prod.outlook.com (2603:10a6:800:2f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Tue, 17 Jul 2018 19:43:52 +0000 To: "John G. Scudder" , References: From: Gonzalo Camarillo Message-ID: <082365f7-3daa-1174-dc33-c4d31b76476d@ericsson.com> Date: Tue, 17 Jul 2018 15:43:38 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [2001:67c:1232:144:dd41:edb6:afe2:a8a3] X-ClientProxiedBy: DM5PR13CA0030.namprd13.prod.outlook.com (2603:10b6:3:7b::16) To VI1PR0701MB2109.eurprd07.prod.outlook.com (2603:10a6:800:2f::24) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f884f1f2-8812-470a-0e89-08d5ec1da01a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2109; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2109; 3:rc6QB4z6UZmHfDRV/ZVo0s8ESnR4KmJ5PXGyH35IGM5rup0SkWl3IlcojAOnKv6WchSriy/0EjjfO1M67PlvKqT7zi/rRU6lhufErXXe/IlPAPvVOZ90rVa3EuEYVsOr/14NL58TJGtNIbW2uZOkMpEbPaTkqxI79ngXUaOiNlceeBYTFCpTEwnrwRaDlJs6Ky+WpT8O9wL28zeRJZgrDheRkDYvjb9f4zksMxYF+7H3F5Jrfy4hIyObKDjPqQmV; 25:gmiAXqo0R2haq3xzyqJOwVgQ52lDH9Y5AnRObItyAYaznOYqGOikBjQekl3Aw8wd1WcwYAFse8/FwPO6QTx3kI0nNcT3qBpG+ogTOAKokfFxMPbx7tih/Lv3VwZtSzhWbuCxcZZrjkir969SLswRlzJMjjGIc4ivVqC34SkuBRc+FMksSa+OeC/Tltbz8DOMRqOWmVn4nBbQpy/AyaFMJWMG+s7KgZwhMjYkIkOhI0Gz0EP1MlswyR9y/p8VN2F5LLimUwKFdeNQ8c74fjttRIk0qAzhHlFm1DVFei8plRaQZH0j3EVyoKWA/usLpxfonEhsrYcITwn5gnL/SToOWA==; 31:fSjUJ5zJssm+zvNkg1qRPsW2eRUKTUUk+QW8PO+LS8SWF6aSv7Gz16ZitNtJqEc4nwu0/w3WewQsVjfkK4umNpU4zKvoHpuJeJ36HJuizfxiLVyXvmnt7m2ueV04mx3t8Vqz7hb5ThoklG6aa+XQ/3sEzuSBdffKxMxbRG2Fe8wNUSXVINF4dICXMibzaZunRmP6C1XLSGaJr3FW6yI/GSmrW9497yrnnbo2LRaFX1E= X-MS-TrafficTypeDiagnostic: VI1PR0701MB2109: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2109; 20:kUy+T3EA+HB4IQq3Ei6KRR82+7EE9vEGE86HoOJujkRo7YTWJdU0WhDUuaPlaPSFW2ZkCDahUfojzfGSWp3cb3NQPOAliv38X9R4985XEZ6xHl5j+GCQoN76rcARd1s1Zapb0wek641i23NuY2q96mkpTgp6d7toZIBe3UxCbIebFKxNwKYWomF1e8khRLH//0rCCQ3baOF6GzBUwWNH8eQ1Skkml50l9PN6BSE2ZqgplwV16Bqg71EKPWbrWB1QrMEotfclsLM+Lf7dDapazIlblZcBatw2JoSRx6XnAFfwo0RzXlTiZtIdc4pl2yA2Anp8NFaxhZ8gcWJ/xAwunpN4JKZeAHeDhkI3j05YccS7amnmAfc1nnMeXCA4hEXgDB4iItOuhMkEmeAPdO32j/z3r9Nctr4jFf5VXdeBFNhfB++XOGbafoN8/AF3XiTuqAK3qIANEkLHWLCVrM+p6Vm5muvxnz2xqz0s5pK2AS8fnT32UvsA6Ej1jRypRVhe; 4:ZthFtUCsSY1gi1Jlx/frNiRTyj8WeVdgdG+FNKpqkx3v4cQDIp2XTEO79tm3w6bTBO0gGNZN+MxrnhKJaypfnxybfiIXNveoI3uaNnFUQJ+4dAW7HfXlesn27d7ZU3qoiAX0WZ5yKMaKQmMsZ4smsqCloL0sgS/GVoSHtE1cHMilf6ri/ji96cCzu5NXdpwJAJxBRKXyBSBouYP93eUetsSta+01CRQnCxNV74vd0+dII6Erm8QNSQBzYAspUGA04BvEFcN1gw3vpyxPV2jv9Q== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0701MB2109; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2109; X-Forefront-PRVS: 073631BD3D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(346002)(39860400002)(396003)(189003)(199004)(81166006)(6486002)(305945005)(8676002)(7736002)(65826007)(5660300001)(65956001)(65806001)(8936002)(81156014)(86362001)(31696002)(97736004)(6666003)(25786009)(53936002)(68736007)(229853002)(1706002)(6246003)(6116002)(76176011)(386003)(476003)(186003)(16526019)(486006)(11346002)(446003)(2486003)(52146003)(106356001)(23676004)(2616005)(52396003)(52116002)(64126003)(2870700001)(105586002)(316002)(46003)(47776003)(50466002)(58126008)(36756003)(478600001)(2906002)(31686004)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2109; H:[IPv6:2001:67c:1232:144:dd41:edb6:afe2:a8a3]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjIxMDk7MjM6U2o0ajR1K3FxM2E2ZkJKMmprY3h4dmZH?= =?utf-8?B?cW9EdW1VSVhwRjF0ek5ITmhiVHV2QnZ2Wnp1L0UvRmE4c1VoeEo4MkJJbUtS?= =?utf-8?B?bi9zMTAvODRaWXJ0Y05ROTFBbmFVMzB6S3B5Z3JncFE4OVhUMWRzKzFIbW1G?= =?utf-8?B?N2xpRFVvTkFqTTNFdk82NlkxN1VDaU9zUTVUT2djOFNUSUw4SWU5dVBwb2dV?= =?utf-8?B?OThjblZyZE9GdkZlNzJIYmpMd3ZJQVB6UEpBNzRpUFJpOGJJUkg3eVpVbkw2?= =?utf-8?B?d1RzYTZQTGgrSlg2b2NnQTBWYUhjQ2ppUkx4cTVhN2V6TkZBTTZJOEVXSjQ1?= =?utf-8?B?UFlJK2VuZnRpTW5mS2pQUEkyNEZiakdUQ1JudUpvNk9uUTdDMEZCeDl0ZDFr?= =?utf-8?B?S1BhZ1NpSU9LYXlwcHZHR2h6Y1dlYU5KQWIwcFRLL3ozRWZ6SEUreU9QbDNE?= =?utf-8?B?bjRuR1dsZVN5T2g0L3J5TGZ4M0RKeTBrKzV2UDdNQ1lmQkRXajdLS3loRkM0?= =?utf-8?B?R0daMFNUWGU0eGFqTjJjMkhlOVFwdW5GOXBtcXh5RkJLdXliajdod25PQk1N?= =?utf-8?B?allKU0c1YWYrZkNHeWh0Mzc5dVc2V1ZqTmwzVjdtYldFM2QrZDF6RHBKekZN?= =?utf-8?B?Y0Y0WHhkc3FpQ0tKeXRsd053d0JJRW10bnV4U3FkeDVzM2hKSjlmak8wbDc5?= =?utf-8?B?VzRjYnFrMVVTcmM1MTZXYUNxTWI5bko2ZEFYa3V5eHhhNHNKL1liQ1U2bFRZ?= =?utf-8?B?L2tJTDdjY2lSQldkMFZ6SVl1MUU3bGpWbEo1MkV1aXl2bHZCR2JsakpFWEw4?= =?utf-8?B?MWVYdGdLZ0c0cmFUYndlYVVBN0ZSQ3V4NEFUbEZMNXBBT3pObTl4ZzhwWk1E?= =?utf-8?B?eHJBcEg2NElxWlYySzlQaE1xVjBOb20xR1o4Yk9sRG0rZ0xBTUM4SG1mY0Ju?= =?utf-8?B?aWpRNWN3Nld2bnVvbmhRODdJVDRYOWlSTTk2ZkJHK1FTNEVUUDZVbnN6aG42?= =?utf-8?B?QVlEaXZ4bkpkejVweFo1c3YzYjJ1WkJXTDVQT3g2YlBjWWRxNi9vR2hDemx5?= =?utf-8?B?OEVGRU51TCs0eEREZ1JaaEt1UGY1dXVLcGs1R0MyVjh3RHgvb3h3dzNNM2JZ?= =?utf-8?B?L2wrcGQ3Z2RadnZIT3RFdEtyN3VIcTNaOFJQOUpNbmpzbU5rREhhU1Y3YmFH?= =?utf-8?B?TCtuOWVDUkJvQXR6NUR2eldUWEFwK3NYZ21QcEFqTXVDU3dhNG9VREFBRWE4?= =?utf-8?B?VzdGd3FGcFdaUmdrc0ozUStUTkJNeXpYeUlHaXVjeEdYUExKbEduTy8rM1du?= =?utf-8?B?TUs3L3JRcDNqOG9jYjlCUW14RXNodnZCbGYyZGJ5VDJxemxDdHVlNUxURTF2?= =?utf-8?B?em8zZFlNb1dJeDRHZVBYV0pUb1RaOE1RSVRMUExJdEtVbEhINXAwY0lLdTJU?= =?utf-8?B?RGhVTmZxc1M2QWF4aHlQNVdwOUhyTUQ0TVd0Nm1aWldaQ0ZqNUVLS3krWmtx?= =?utf-8?B?RnRhSzdmeWF3eW05d0JlZ1lGWW8xTldaSStkUGtDemUvaVBHN0hKS1ZrRUdy?= =?utf-8?B?a2JvQVo5NWZkNGJvem1IVVRVbEJndW80STNrZjdwZ05oNzhmak9GZndpeTRD?= =?utf-8?B?UHpaTEx4WUo2MGRqbkpqUjd0VGQ5Z25nUHVOSEJicldQQ2JkcWxGcElwY0R2?= =?utf-8?B?V2k4M1Z0QThqUGZQbFA0ZzhBZlY3ekZaRHZ5VE9rSUs1Qnk2am41K1Z2cGVG?= =?utf-8?B?RWRyT01teUhrU0ozOHdDd01BPT0=?= X-Microsoft-Antispam-Message-Info: uzooDq823AeF9acL+6caLO9EL8Y0fk1DwoF0E3NKB6nq6t5Z1u+btuYeE5Ox1mlsHLnBUm9nlY1/DffTk7m9TMJX4p564ngHFdfunONWQ7RSogB3CLpcG8zIz2QpWFyLzdzORV2a8qY4MkrAPaT5cl5Hkhil5AAOevCMMmVG/UzB5W/FEzoSSQtElDAFt1cC31eybF1rHdFqqHdA+6sTYCVIWywwy1kkgHeHYXUtVsChUkhRG9w2KHL/Sd2/1PsbNHfzc3z62ACvqaOe/CB2I4vJPhiXBdB2FlftSjxFag8Qf6QiUp/tITfm9qv9hX5z1AfBxIpXp50jTwcwYgOvA48mfg4B3hn0OtQzQYIBuKQ= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2109; 6:ITTmDvB7UWH8mNW200oW3N4FOvo2hI7lizi+5ovko/F1sR7tRwhZLhXhyeIEjuiSZRlDFekipjummb7ewDS5hi65285UpJhlDXregOUFntJRRgEgt+TfTVFBrmGqdBdIYR1vWUI3yDV3oqdRkM+bRk12eqm9ydIGfpbsNnfPCDh6T+d4iWMoxXg1Q+7fZZ3iLeAmFBYokdvx6N4OWGqAPsS81uSosyyCnClcBbZbZA06TxIQMZm7gSJPU2s8qwfFkCOVbE1SORlC8UVWpKQpwHYqX1iLHJr0efvrErmYSOTzcXoNA/lGPVq8kouHM3zerv05N17ot9bdwrgIuzSu/e5dQa9iZ7kXC/1yE9zELjnY8jRmzLS6KizqYepM9vUwAXpOpxx3ZF9BgxkCe79iG/Ba9VAZQTTy4Bzwahv/A1itrDJ3aSJJXUn7GTd6qFAaTr9FK4FCln2oV/t4Hs3d7A==; 5:wJ0NSDEgL7vm0+8X74rheH6liuunxFarwIGr+6H6a7FA85084mmvijk5Mg/7KpWkqDF8ZnmYlbDCi3R6Fu9OOCwbKH3JlCPKntaRS9/fmXCGTB72LHg//1Cb1Oom2qa8Lk4xEGWWcQsiHqu7Gaiyvgwi/edpBE8HxHOz/MCNY+M=; 7:mUINJIe4OOHLCCYZgJ1mimGldJt93WmmRxKd4TLt1dHcqnIC/zkG7wFwvi79PMR5X01i8UO0YRQ7bJfw8KxPpwr26CcEwODNVAK0B3zIQ4jBzYGWBLvZudeVMUQqcUbfXB7Ot2kZV6vaazLUFhlYmUTRMAHVQ6owycms9KymKB3wHEgvo0ABHuntdJqvXUiB5aFtRuCoHSz+Hz8iZTR6bIwsVWNKsxAXbuxvl8YHyesTvaHPCHKuZnOqoqVuODkc SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2018 19:43:52.0386 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f884f1f2-8812-470a-0e89-08d5ec1da01a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2109 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42KZGbG9SFfR3S/aYPF3MYuN/3ewW7zcXufA 5LGk+z2QWPKTKYApissmJTUnsyy1SN8ugStj0SHFgm8cFQtfXmFvYGxn72Lk5JAQMJF433CF FcQWEjjKKDFpLncXIxeQ/Y1R4u2unywQzhImiYM/7jCDOCwCE5gl3k05yAqR2cMksWwzxCxh ATOJXTMXsoDYIgJWEo+bH7FBzLWUmDnlJFicTcBCYsut+2A2r4C9xKlJV5hAbBYBVYkvzZ+Y QWxRgRiJo5Nb2CBqBCVOznwCVs8JNPPszhawGmYBdYk/8y5B2eISt57MZ4Kw5SWat85mhvjN UuLRmx9sIIdKCExnlOj4/hfqUW2JzWtOMUIUyUocPTuHBcL2lTh2fBETRMMlRonbt9czQzhN 7BJ3ey5Cg0xH4l7jE7AVjAKJEn/vvWWDiF9ik7h53g/Czpe43zYTaqqWxLqrH6FOkpM41XsO asMhZokjx88yTWDUm4Xk1VlI3puF5L1ZSN5bwMiyilG0OLW4ODfdyFgvtSgzubg4P08vL7Vk EyMwcRzc8lt3B+Pq146HGAU4GJV4eD+b+UULsSaWFVfmHmKU4GBWEuE9+sE3Wog3JbGyKrUo P76oNCe1+BCjNAeLkjiv3qo9UUIC6YklqdmpqQWpRTBZJg5OqQbG1sia7585erL/rf53XvNC fuY1G1Zu1Zlf0oN27Aw7kfTRe67qvSOL5rto68luTzmpeM30uP3/11YRujHnLur8f5vmd/bP tosGU6Xlc50N7mooi85XfLh0ziQuHrV3d2Q2Cse18uQtfMR76UZkdPkaqwzTP1MyJXLiP2ul qj6c1rLj2MonF0N2K7EUZyQaajEXFScCAMxzFXQYAwAA Archived-At: Subject: Re: [Rfcplusplus] Rfcplusplus BOF next steps? X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 19:44:37 -0000 Hi John, during the BoF (and before the BoF on this list), we got good feedback and input from the community on a set of topics related to the RFC series. All that information will be useful for the RFC Editor, the RSOC, and the IAB to identify, if needed, more-concrete improvement areas in their respective areas of responsibility and potentially come up with action plans, which may involve further conversations with the community around certain issues. So, from our point of view as BoF chairs, the next step is for them to analyze the input from this BoF and take it from there. Defining more-concrete next steps is up to the RFC Editor, RSOC, and the IAB (as opposed to us BoF chairs). Cheers, Gonzalo On 17/07/2018 9:01 AM, John G. Scudder wrote: > At the very end of the meeting I heard Gonzalo say “we have next steps†or similar. I was waiting for him to say what those next steps are, in specific, but instead he closed the meeting. > > Whether I missed it, or whether they actually weren’t listed, Gonzalo, would you mind repeating what those next steps are? > > Thanks. > > —John > From nobody Tue Jul 17 13:50:38 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E426B130DEB for ; Tue, 17 Jul 2018 13:50:22 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 2Lh8GM5MldBV for ; Tue, 17 Jul 2018 13:50:16 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 3B9E1131007 for ; Tue, 17 Jul 2018 13:50:00 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id j185-v6so1123805ite.1 for ; Tue, 17 Jul 2018 13:50:00 -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=JpLrOTlN9hNguEeU+RxTgW+0fM0zldbsNAYTIbx+kQ8=; b=saPkD4pFu+D3SoEuPRCov5lw/IJ4IYquomQ+fG4RJDMRzLuBesMPD0q2Y+YfIYPXAs nsyqYezlNT4POsY05CdbQ9+55UjgTWMrghwSuIzM6/lOCNOP8f8BsCtQJsZr19Zy9ZIj H2d+XjKYuz9Pt4l+i+wh6XyouGHmZ9AbDuoG3Z7wPNrkyHfe/o4uatyvlVIHZfKKeK5X J2n79FFawUcmQ7b5+p4EhwaNLQQA1Kk4q+L0yCpUAQXEvoRK7wHyD+rcYkMlIdqhY4yx /y+eyFYsV7ZQKXsEFe/dKl5AkZ0VWvtxaSEa5X4hX3Z8OJnQPI1VTRfOnKjoKR2zmU0B x2RQ== 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=JpLrOTlN9hNguEeU+RxTgW+0fM0zldbsNAYTIbx+kQ8=; b=KYTNhq8S/ZRLwMJ8dhyzcM9lVTs86TB/FV6ZS+A28CdpjFmuCYUN/UYuxsMx1xtdSF aCRu4ihhpz0uOlkxchSfbH6G4eIUmaBpcndLfN3pCevHVDLlSmNtWUZ1WNGz9d71B0AQ RY7rY/XSv2DSiIcWJGttMu2Xx+IU9tUqJQtT5Je9KSi8ooWRFOehvUL+Wo09oJ19gG4V qQ5IR6apCFG2eDtyk5pXd3soJhYRPPXT1+2EiPzzxE2FtA4NEZtvQ5Pc/Wdxj+p2jHUV iXy17m99Ya3UgpWAy9seU4GI9NkGUbMVfCzNiNrC6n11qUZIwY/uGrCP5JKGTjS0Gqoa U4jg== X-Gm-Message-State: AOUpUlHdC1YTe9O2MGVFMspvpzNGXz/F+zV1vk8BFGd2UkmKLHsiL7AN vpMn0EYNF4Thefxue4l09JnKJg== X-Google-Smtp-Source: AAOMgpeJ+dd8EPdIzWadssPF4gM12QKRcHi7BNTOWhUQOIo4mA/vKlyk11hxC4xHG7/HWIQZ08J5Vw== X-Received: by 2002:a24:ad45:: with SMTP id a5-v6mr2979100itj.0.1531860599379; Tue, 17 Jul 2018 13:49:59 -0700 (PDT) Received: from [31.133.141.87] (dhcp-8d57.meeting.ietf.org. [31.133.141.87]) by smtp.gmail.com with ESMTPSA id e11-v6sm851656iog.56.2018.07.17.13.49.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 13:49:58 -0700 (PDT) To: Gonzalo Camarillo , "John G. Scudder" , rfcplusplus@ietf.org References: <082365f7-3daa-1174-dc33-c4d31b76476d@ericsson.com> From: Brian E Carpenter Message-ID: Date: Wed, 18 Jul 2018 08:49:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <082365f7-3daa-1174-dc33-c4d31b76476d@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfcplusplus] Rfcplusplus BOF next steps? X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:50:23 -0000 Gonzalo, I don't suppose the minutes are available yet, but my (and others') understanding was the baton was passed first to the RSE to analyse the issues raised; after all, the normal process is for her to propose any changes to the series, first for discussion in the RSOC and then for any proposed general policy changes to be sent to the IAB per https://tools.ietf.org/html/rfc2850#page-3 . It would be extremely chaotic for the RFC Editor, the RSOC, and the IAB to work on this in parallel. Your reply could be understood that way, but I suppose that isn't what you meant. Regards Brian On 18/07/2018 07:43, Gonzalo Camarillo wrote: > Hi John, >=20 > during the BoF (and before the BoF on this list), we got good feedback > and input from the community on a set of topics related to the RFC > series. All that information will be useful for the RFC Editor, the > RSOC, and the IAB to identify, if needed, more-concrete improvement > areas in their respective areas of responsibility and potentially come > up with action plans, which may involve further conversations with the > community around certain issues. >=20 > So, from our point of view as BoF chairs, the next step is for them to > analyze the input from this BoF and take it from there. Defining > more-concrete next steps is up to the RFC Editor, RSOC, and the IAB (as= > opposed to us BoF chairs). >=20 > Cheers, >=20 > Gonzalo >=20 > On 17/07/2018 9:01 AM, John G. Scudder wrote: >> At the very end of the meeting I heard Gonzalo say =E2=80=9Cwe have ne= xt steps=E2=80=9D or similar. I was waiting for him to say what those nex= t steps are, in specific, but instead he closed the meeting.=20 >> >> Whether I missed it, or whether they actually weren=E2=80=99t listed, = Gonzalo, would you mind repeating what those next steps are? >> >> Thanks. >> >> =E2=80=94John >> >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 From nobody Tue Jul 17 13:54:17 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E79D130E46 for ; Tue, 17 Jul 2018 13:54:02 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 6dLZR57v9f9w for ; Tue, 17 Jul 2018 13:53:54 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDA2129C6B for ; Tue, 17 Jul 2018 13:53:50 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id s9-v6so663638wmh.3 for ; Tue, 17 Jul 2018 13:53:50 -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=tilTrsj78Ksgrkj0umMdJo+7Uw1/0eBnSL0SxeoG+3o=; b=VjHEXhpeyaG2fXrnChUfhelNhKX0u6JG/rOntpxse/nLq4cb3FBPzzss0n5PQ8zE/T XZufdz1Jd+00eeckX/MK9hc0kJp9n1tfU/k3zPzpBGMyuH9b6IlG7OZEnaOxUy/XhIPW sEGkdMOqIo7BtbKAz2TdyXFozI/o7Wr0BNoldtSOxcCsa3Z6hkw2M43Saj1WHqf9xJSK jNjBya6FpnJml+dJWP18P7ypdjfDJD2JqOxbrqCJyO3wvQ9tPIKo8XMcZj7FGx32tBAp hRmvfSTCF0zn3pePp89knM6H+qmmw7SrAyeDAVE5tOYM8ikV5KsNeD5dzG32Mf3pzo1K RjUw== 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=tilTrsj78Ksgrkj0umMdJo+7Uw1/0eBnSL0SxeoG+3o=; b=ZC6sjIGRMR2W7yLTBX0h04jyKHY0UmCCotm91RDkGqi990SBzFxlsDMsAOCRYmBTQ9 qMiOSe8AfeiuP4jHZVYv1JiSg6nbJ2e/xC9R/Og0DsJ69w9NWn9h1cai68fEcs16plbo fGPn12Q4JwQJdgyfSYUt3S0ucWXE9bccMFsb6x+GzSn/WCb7lY2rDeA3PUaWTKVmuDX9 5Ou1V2u/jJI1XYiYyKmBcrv6bWb2PF4w7/rapZJVh09HP8iNxmSIoDHERkZ3o9fyDL9W C8AwT2DjBA9wzRZ8TZiUOSYieN88vZ/t+PYLOBKueszXXhL78z2cI0WwK7SHjpfxTmHz X9mQ== X-Gm-Message-State: AOUpUlHKz9XMHExE+PIgDjs35Tml8J0Qg7Og+YU4Gkb8RacheXM/y3ZQ 8X2ASLr/RcTLUS/sCm7dOPo= X-Google-Smtp-Source: AAOMgpd80E5L46NqZNXE1iTuEEd4s116fNy/UZ+xpMcN5337+/PEAcc4itfv1taBK8RKptvFIEaYBg== X-Received: by 2002:a1c:1a02:: with SMTP id a2-v6mr2522949wma.52.1531860828860; Tue, 17 Jul 2018 13:53:48 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:3962:4a1b:9e9e:eeb3? ([2001:67c:1232:144:3962:4a1b:9e9e:eeb3]) by smtp.gmail.com with ESMTPSA id 14-v6sm1147399wmg.0.2018.07.17.13.53.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 13:53:47 -0700 (PDT) From: Bob Hinden Message-Id: <1BBB5C21-8B1A-41A5-8C77-F8012733BBD2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_058C2F99-B1B2-43C5-8959-1ED77CA8F752"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 17 Jul 2018 16:53:45 -0400 In-Reply-To: <082365f7-3daa-1174-dc33-c4d31b76476d@ericsson.com> Cc: Bob Hinden , "John G. Scudder" , rfcplusplus@ietf.org To: Gonzalo Camarillo References: <082365f7-3daa-1174-dc33-c4d31b76476d@ericsson.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] Rfcplusplus BOF next steps? X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:54:03 -0000 --Apple-Mail=_058C2F99-B1B2-43C5-8959-1ED77CA8F752 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Gonzalo, > On Jul 17, 2018, at 3:43 PM, Gonzalo Camarillo = wrote: >=20 > Hi John, >=20 > during the BoF (and before the BoF on this list), we got good feedback > and input from the community on a set of topics related to the RFC > series. All that information will be useful for the RFC Editor, the > RSOC, and the IAB to identify, if needed, more-concrete improvement > areas in their respective areas of responsibility and potentially come > up with action plans, which may involve further conversations with the > community around certain issues. I think it would be useful if the chairs would summarize the discussion = and the sense of the room. Thanks, Bob >=20 > So, from our point of view as BoF chairs, the next step is for them to > analyze the input from this BoF and take it from there. Defining > more-concrete next steps is up to the RFC Editor, RSOC, and the IAB = (as > opposed to us BoF chairs). >=20 > Cheers, >=20 > Gonzalo >=20 > On 17/07/2018 9:01 AM, John G. Scudder wrote: >> At the very end of the meeting I heard Gonzalo say =E2=80=9Cwe have = next steps=E2=80=9D or similar. I was waiting for him to say what those = next steps are, in specific, but instead he closed the meeting. >>=20 >> Whether I missed it, or whether they actually weren=E2=80=99t listed, = Gonzalo, would you mind repeating what those next steps are? >>=20 >> Thanks. >>=20 >> =E2=80=94John >>=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --Apple-Mail=_058C2F99-B1B2-43C5-8959-1ED77CA8F752 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAltOV1kACgkQrut0EXfn u6hQAQgAsfa6N4+MX0dRC3On3miNn3VR4QlvWFvKwoUtp8PJbVOUBkBlhnX/KgPJ zkzvfeRHDJce9TYmOcAiEJ4jefqGIwrfHKdiJdyKaQXyuaiNzElWqfoyrHw+kmUd 1hx8GSZoomJ+PIl7q8ShuQhqDdZfeiMwQQVSUSUH9nVRm5lDStuBMR4i7SbeDjDQ 4HZUycpDPiMc0X7OB1pe5fNaiRU9u8oJfrRMcCAUIrWiVo5zsJwnF8gQ3HjbeOhS fxhLOGckBKRj5g7FuQJQuzLZJJc1nHmfKQnm5fPh54E4BNJgIfgredqU/lKx2lV5 +kAG6SFDY2i0avWz8CQrhvKt7W+3jQ== =pDVQ -----END PGP SIGNATURE----- --Apple-Mail=_058C2F99-B1B2-43C5-8959-1ED77CA8F752-- From nobody Tue Jul 17 15:22:50 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3012F130E7E for ; Tue, 17 Jul 2018 15:22:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 OH79f_wuqfQN for ; Tue, 17 Jul 2018 15:22:46 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC31E130E41 for ; Tue, 17 Jul 2018 15:22:46 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id w16-v6so1415488ita.0 for ; Tue, 17 Jul 2018 15:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version; bh=mKhHPZJlso2Jcuv1GyWygbRL/9OvhBBBxi5ZwYyLrPA=; b=AuSiSUBu6APdE4upX++4NTt8d/QQh29g6QTs5mqIiQ66Nk+l5zmSFByIRwTIFB/OkO UEg3Pfwx1VhD5JQE9gy9hVUcuqhVZjDSZFyTljVxPIwVMKk6ZSs2WsmfXMwSKosgeBXW yNHm8VrVZbXPr3/pfOli3hHr1cbJUIAYo6A2A= 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:openpgp:autocrypt:message-id :date:user-agent:mime-version; bh=mKhHPZJlso2Jcuv1GyWygbRL/9OvhBBBxi5ZwYyLrPA=; b=LTI33VtzoWcrTVygc5deNLgmaRbPr3mCBBpGSH5pgnrrbEF4M7nwfcRQnqBDgisKe5 vkWePQrJWDZvLXwXjgeg/3KoFEmB97Qg1XUuN5jUWdiuKgI1Ahx5tLOXzQvqnUKwNZV4 Hrc/GlT46tUCSo/pIXdI73DtMgdtjLkng/geAbc/OC8tDVTXUbxrd7hetRILfnTlGKIn moNhc1vBJoI8vROGxnu+mnoXNRM9znc/S8dObxW/mToWHU6w2sNGKaHtUZawGzZzdLat O65l83rypVaFuJgZWqS0lXpQEIXkyQqYL3rMv/njo5yJI1aEw8EY+Fr6yYo6DKCKrfOG 9Z1Q== X-Gm-Message-State: AOUpUlEIZTg+e5QqASZyJHnAu/Iq9PyTBV2Qu5UlaII6p+8xobmwYO2c jaLQZsQB4aRCo+EvY1onoH/cfA== X-Google-Smtp-Source: AAOMgpddoL8gKceQNO47yzB2a4SzCCKWaLg+gfBoQrIK6fSatW+OFFw7PsegXVpDD/pozgwc9jtGGg== X-Received: by 2002:a02:89fc:: with SMTP id e57-v6mr3309904jak.44.1531866166103; Tue, 17 Jul 2018 15:22:46 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id d9-v6sm346524itj.10.2018.07.17.15.22.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 15:22:45 -0700 (PDT) To: rfcplusplus@ietf.org From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <75c8b019-2c05-bf82-1f95-5300f56ca569@mozilla.com> Date: Tue, 17 Jul 2018 16:22:44 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I01yQQvBaVg3cSwXFoh4rMjqebbWeLIo4" Archived-At: Subject: [Rfcplusplus] venue for follow-up discussion X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 22:22:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I01yQQvBaVg3cSwXFoh4rMjqebbWeLIo4 Content-Type: multipart/mixed; boundary="FwrQ6wwr4eIWckWPR3DLrYu0l3RxEjiKe"; protected-headers="v1" From: Peter Saint-Andre To: rfcplusplus@ietf.org Message-ID: <75c8b019-2c05-bf82-1f95-5300f56ca569@mozilla.com> Subject: venue for follow-up discussion --FwrQ6wwr4eIWckWPR3DLrYu0l3RxEjiKe Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Now that the BoF has passed, what is the most appropriate venue for follow-up discussion? Would that be this list or rfc-interest [1] or something else? Peter [1] https://www.rfc-editor.org/mailman/listinfo/rfc-interest --FwrQ6wwr4eIWckWPR3DLrYu0l3RxEjiKe-- --I01yQQvBaVg3cSwXFoh4rMjqebbWeLIo4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltObDQACgkQZWGMGH9o FKmeGxAA6gPVQ/E9FAuxfuBnOKeOJ2qimI9fX9P/anIEshMOWZTlR1VUX3/XZV/I /2ioovrNSvlDYIY1/YFEkH48b5ZNpCdivql2GfTzfMjIYrc4DkfB5YNE8AUl33Jp 0KD+qWECFIMy17cZNorywWd34lfZBHMOnDAtz5ZuhiyC+qcZYVvtfJBmFRfzTTGW sBxd9TH12KgpVsVxlGzHfSzPANPPHZXjByuksaw1Bhx9Fm7yiejKw5pMa0Re7ng0 EN9ZPoU1xZ2/5ZjHJgeuwqNhBcVFgsCs6Mv6/EhEQTjvv2OoSS57ANg7DF9+Q116 zqv1bdBHaM4r1uMIF0HXgxPZ34zOMDUUig7o9JHz4/U+prg7GkgJLeEjMPRZ/KfM hE5GgTqsedlnvaV6o2BDct3r/R3fPoOCvnv8uYePTBc9n5f+5lSrafpPYu5UOB4P 3bbQODFhoa4/t95UZi/8Y+HaWEwGimOZaO8RETlyxhp+M8ZVp9DCvcZJB/g8xZH3 OPIt85X52WqSsuuShwN5nAX+na0g1iDT4KW661MuceRZfhuzGhoT77d0fyD4I1ln gGuQ9k66AZWZHAl2emiQjPjTbwwmTq4YaZG1ajVW4dNCX/XRP09+75ZAmVVetLtP 9A9aD4I6EDUupAx5pT+OT4QjmNDflFzxWHXXnPKuy9i0pxqaUlo= =0t7q -----END PGP SIGNATURE----- --I01yQQvBaVg3cSwXFoh4rMjqebbWeLIo4-- From nobody Tue Jul 17 18:31:10 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C993813102C for ; Tue, 17 Jul 2018 18:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 FbKOjyL40u-8 for ; Tue, 17 Jul 2018 18:31:07 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD484130E18 for ; Tue, 17 Jul 2018 18:31:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 00CA21C92FA; Tue, 17 Jul 2018 18:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr65sUpdLd_d; Tue, 17 Jul 2018 18:30:54 -0700 (PDT) Received: from [100.110.214.145] (237.sub-174-206-38.myvzw.com [174.206.38.237]) by c8a.amsl.com (Postfix) with ESMTPSA id B3CA31C92B8; Tue, 17 Jul 2018 18:30:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Heather Flanagan X-Mailer: iPhone Mail (15G77) In-Reply-To: <75c8b019-2c05-bf82-1f95-5300f56ca569@mozilla.com> Date: Tue, 17 Jul 2018 21:31:03 -0400 Cc: rfcplusplus@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <75c8b019-2c05-bf82-1f95-5300f56ca569@mozilla.com> To: Peter Saint-Andre Archived-At: Subject: Re: [Rfcplusplus] venue for follow-up discussion X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 01:31:10 -0000 Hi Peter, Great question! I would recommend the discussion move over to rfc-interest. I= think the mono-focus of the BoF list has served its purpose.=20 Thanks, Heather Sent from my iPhone > On Jul 17, 2018, at 6:22 PM, Peter Saint-Andre wrote= : >=20 > Now that the BoF has passed, what is the most appropriate venue for > follow-up discussion? Would that be this list or rfc-interest [1] or > something else? >=20 > Peter >=20 > [1] https://www.rfc-editor.org/mailman/listinfo/rfc-interest >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Wed Jul 18 10:32:00 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0B9130E27; Wed, 18 Jul 2018 10:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=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 fmOIsk6UkguD; Wed, 18 Jul 2018 10:31:54 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5682127AC2; Wed, 18 Jul 2018 10:31:53 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id k81-v6so10298215oib.4; Wed, 18 Jul 2018 10:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XYT86FllIM+RF2YJsCAxgRbceNdtPGm0LlfNFqeM0Ds=; b=scheluS7uWmn5zDZNjfdX2bRKSGcdk8Oe/3TNBbQ804ik/3iKxYjlKKTTZ5oJK+lot nKOsjMenAGjz0Q3q7AtIhJgPO3qDEBk4PmFlF7mzJmq0DprjNyYZmwQV6b3Ttm9nz7nH /7LhD1AfetACAhB+Whnp3iiid4DSWsUlTUiLfodtR/Mr9RgNoZ62sMV8Hc/y3wvnaXTx MXpE/7g6Uu4dhlJPFsbgbw3KtyS6x60xrGpDsL5p2aGj6jzqnM7uKVIL+K+khV5BDclB zQp/jO1It48ptbThXtUaojdmdtxMjMKAPShwjTKB3kL+CoccEFVrS4c6UfrLE51FpKXb s4TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XYT86FllIM+RF2YJsCAxgRbceNdtPGm0LlfNFqeM0Ds=; b=P9D8i+YFkzl0bHufYB+HT9uiLr3j/0uZu2+RX+GpOAbdb2NUjjYo+pfwOE/twws9Qb VJpbysftWRCn5atfyHy1q7ZHZnyUNR5JZkIt11XTqalhEJ5NLe+185HGqLZ4nVlMgiLt QfKdWVjG5Kw412zL2ro9CJAJriggtC6nJBQsYIbmYaM8M5/CSqRV5x7jwk8aSXni+shX uF8C4+WRISTxkg8AhSG+uFYYr5KGoxf9LoCLUtoFSOdZ4D06MckjCEy9idTslTy4vW9G L2YhgzTXUmiu3R0ynmO4AfRswApEkggewMWe5HgfJmc8OKSMGno4jUbMsxm7qTQctYrE PUBg== X-Gm-Message-State: AOUpUlEmAdXxtvyiVhubDyDveZYzEBL6lD1jUwudCWVApZxmdWfe9DK1 VuVJhKdrO/QnP21PCb3XwrRxxbFblYPiq7kac0WWlQ== X-Google-Smtp-Source: AAOMgpejgE39NutbMUWant1z2os8tr2vqo20AucfZcylVUc4CI/taaQjk1bMDTuCDCaAA0oPrkIOq5w6yO2A35iJgSQ= X-Received: by 2002:aca:4782:: with SMTP id u124-v6mr7644842oia.45.1531935112752; Wed, 18 Jul 2018 10:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 10:31:22 -0700 (PDT) From: Ted Hardie Date: Wed, 18 Jul 2018 13:31:22 -0400 Message-ID: To: rfcplusplus@ietf.org, IETF Content-Type: multipart/alternative; boundary="00000000000036f51d0571497079" Archived-At: Subject: [Rfcplusplus] A note on tonight's plenary X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 17:31:58 -0000 --00000000000036f51d0571497079 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greetings, The IESG and IAB understand that there are significant questions about the RFC++ BoF likely to come up during the plenary. Given the IAB's role as a shepherd of the RFC series, we anticipate questions during the IAB portion of the open mic. As context, below are some thoughts on the BoF from the IAB. First, some of this is the result of tired people working to a deadline. That rushed effort tried to capture a set of discussions, some of which go back before the current IAB (RFC 1796 , potential adoption of BCOPs , possible new IRTF publication stream), and some of which started at this year=E2=80=99s IESG and IAB retreats. Second, while the experiment in the= BoF proposal did not have IAB consensus, the IAB strongly believed that we needed to hold the related discussions in a public forum. Holding that discussion only within the IAB or even with the RSOC and RSE did not seem to us to match the need for transparency for a set of issues of this importance to the community. The proponents brought the discussion to the IAB and IESG in the context of a BoF because the basic function of a "birds of a feather" session is to hold a public meeting for folks interested in a common topic or issue. While our usual BoFs are about working group formation, that core meaning is why the proponents took that route to reach the community. We made some mistakes in that: - The context built up by the IESG and IAB at their retreat and in other discussions did not translate into the BoF description, even for those w= ho read all the listed background material. - Some of the folks already involved in the RFC processes were not part of early coordination. - The problem statement was not sufficiently articulated, and the discussion on the list did not start early enough to help. - The use of the BoF term and the location of the meeting at an IETF caused some concern that other parts of the Internet technical community were being deliberately ignored. - Engaging folks who were not deeply familiar with the IETF process did not work, despite some folks putting in significant effort to do so. - The proposed experiment also did not resonate at all well with the community, and the IAB has heard that feedback loud and clear. - The early discussion on the list also caused the chairs to reshape the agenda; while that had some positive effects in moving the discussion up= a level, some folks found removing all mention of the experiment confusing= . On the positive side, the BoF did give folks a forum to share both their concerns about the issue of confusion and for members of the community to give clear feedback on their perception of the risks inherent in making changes to address the issue. It also gave clear feedback that Heather, as RFC Series Editor, sees gathering data about market perception of the RFC Series as in her bailiwick under the terms of RFC 6635. She noted at the BoF that she will bump it up her priority stack. We'll take that into account in understanding where she's spending her time, and we'll make sure the RSOC will do so too. The IAB confirms that any data she brings to us on that topic will be made public and that any discussion of next steps will similarly be public. That won=E2=80=99t use a BoF format, given the feedback, but it will be as = open as we can manage. We also heard questions about how the IAB spends its time. You can see the IAB report to the community, sent earlier, on the IAB website . Further input on what our priorities should be is always welcome at iab@iab.org or architecture-discuss@iab.org. See you at the plenary, Ted Hardie For the IAB --00000000000036f51d0571497079 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Greetings,

=

The IESG and IAB understand tha= t there are significant questions about the RFC++ BoF likely to come up dur= ing the plenary.=C2=A0 Given the IAB's role as a shepherd of the RFC se= ries, we anticipate questions during the IAB portion of the open mic.


As context, = below are some thoughts on the BoF from the IAB.


<= /span>

First, some of this is the result= of tired people working to a deadline. That rushed effort tried to capture= a set of discussions, some of which go back before the current IAB (RFC 1796, potential adoption of BCOPs= , possible new IRTF publication = stream), and some of which started at this year=E2=80=99s IESG and IAB retr= eats. =C2=A0=C2=A0Second, while the experiment in the BoF proposal did not = have IAB consensus, the IAB strongly believed that we needed to hold the re= lated discussions in a public forum.=C2=A0 Holding that discussion only wit= hin the IAB or even with the RSOC and RSE did not seem to us to match the= need for transparency for a set of issues of this importance to the commun= ity.


<= /span>

The proponents brought the di= scussion to the IAB and IESG in the context of a BoF because the basic func= tion of a "birds of a feather" session is to hold a public meetin= g for folks interested in a common topic or issue.=C2=A0 While our usual Bo= Fs are about working group formation, that core meaning is why the proponen= ts took that route to reach the community.


We made some mistakes in that: =C2=A0=


  • The context built up by the IESG and IAB at their r= etreat and in other discussions did not translate into the BoF description,= even for those who read all the listed background material. =

  • <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= font size=3D"2">Some of the folks already involved in the RFC p= rocesses were not part of early coordination.

    • =

  • = The problem statement was not sufficiently articulated, and the= discussion on the list did not start early enough to help. =C2=A0

  • The use of the BoF term and the location o= f the meeting at an IETF caused some concern that other parts of the Intern= et technical community were being deliberately ignored. =C2=A0

  • =

    = Engaging folks who were not deeply familiar wi= th the IETF process did not work, despite some folks putting in significant= effort to do so. =C2=A0

  • The propo= sed experiment also did not resonate at all well with the community, and th= e IAB has heard that feedback loud and clear. =C2=A0

  • The early discussion on the list also caused the chair= s to reshape the agenda; while that had some positive effects in moving the= discussion up a level, some folks found removing all mention of the experi= ment confusing. =C2=A0

<= span style=3D"font-family:arial,helvetica,sans-serif">

On the positive side, the BoF did give folks a fo= rum to share both their concerns about the issue of confusion and for membe= rs of the community to give clear feedback on their perception of the risks= inherent in making changes to address the issue.=C2=A0 It also gave clear = feedback that Heather, as RFC Series Editor, sees gathering data about mark= et perception of the RFC Series as in her bailiwick under the terms of RFC = 6635. She noted at the BoF that she will bump it up her priority stack. W= e'll take that into account in understanding where she's spending h= er time, and we'll make sure the RSOC will do so too.


The IAB confirms that an= y data she brings to us on that topic will be made public and that any disc= ussion of next steps will similarly be public.=C2=A0 That won=E2=80=99t use= a BoF format, given the feedback, but it will be as open as we can manage.=


We al= so heard questions about how the IAB spends its time.=C2=A0 You can see the= IAB report to the community, sent earlier, on the I= AB website. Further input on wha= t our priorities should be is always welcome at iab@iab.org or arch= itecture-discuss@iab.org.=

See you at the plenary,


Ted Hardie<= /span>

For the IAB










--00000000000036f51d0571497079-- From nobody Wed Jul 18 10:59:44 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC42131012; Wed, 18 Jul 2018 10:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=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 VkmjUfP_YNr0; Wed, 18 Jul 2018 10:59:27 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 D6257130F7E; Wed, 18 Jul 2018 10:59:26 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id k12-v6so10449073oiw.8; Wed, 18 Jul 2018 10:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lawQ+j3d8A+OJwDPT+RQqZx0n1r+SGOilj9dWhAI9oQ=; b=Cs0DXMgYqz6z2UEct3Yh4OCpLuRR+iGDvSoCcJu8aoBzE/WXa+sCWGyxxOmszWCxkR hCLGxFXfEa4GrBufi0vydEwkHMKFIC6LXBW0W//zUckFKk4kxw7r2X+5GUr8JPEHDsPG eIM0xkxngRA8405o7pSZgE8jkCGpKuaBEOYabvqItU7fBxM82/koadaGKbOe/xrxfpWK EXMZeYPQ8EzvZxslo0VmnpPxJ9X9mjQ/GogTOBKgH3fF18DNc27uNezKu9uoXdzHlYeA NiujMt6Jv+n+2Q2TNZF2MRWwc6mMMdme4MxFbOhDbfgTxwz7SpympBVs8UiKOwjP8atN MbWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lawQ+j3d8A+OJwDPT+RQqZx0n1r+SGOilj9dWhAI9oQ=; b=QWlsaD4ztzLvY28Mw/u1PkSNZtuk7X7E68pIqqJoek2g2kbwqDxyEeZQ9YoszFtcAj dxprKQFNZfPH2+jzUaipP4V4PHcoICwnva1i4/gzhr36k94CM2oyLddGR1vpd69HUk+q jazY9KteI8X2owL1LCx+mgrXTzNl6Mu2rFgY0QbDxRI6OygqKvwECBW8OQfA+h/aJLFP iewJlTmXpWSYbSBP2y7j74JwJmfrprHtaA6BWf7FFs14ysVPeDIkmaCTUlQq1pE1+3HK puzSfXQFn9310gSrSRgkB/TL/MBCsNEO+ouddQFWNPI5aszTR6PkgOZfaDyT1m9wFb1R oynQ== X-Gm-Message-State: AOUpUlHOxq+QB2row3MyW/bJWd1AwlzkJ2fPJmm2EGcw1MHeJoM/LyrE pTxzqTrnHP2HxnEtPIVsRHch9wc8DmRaLXFz9dA= X-Google-Smtp-Source: AAOMgpe0MVquwdYMzmtGHQN7xDCmMyqxusOv/hzWTYjdhQK00x1YjbgIhVcH6k8mOlD29pIJ7wSJXNVflS7xSfaajXM= X-Received: by 2002:aca:ddd4:: with SMTP id u203-v6mr7863930oig.204.1531936766070; Wed, 18 Jul 2018 10:59:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c2:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 10:59:05 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Wed, 18 Jul 2018 13:59:05 -0400 Message-ID: To: Ted Hardie Cc: rfcplusplus@ietf.org, IETF Content-Type: multipart/alternative; boundary="000000000000c2956f057149d2b6" Archived-At: Subject: Re: [Rfcplusplus] A note on tonight's plenary X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 17:59:38 -0000 --000000000000c2956f057149d2b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ted, Thank you for your clear summarization of the IAB=E2=80=99s thoughts. To make the next step clear, would that be for the RSE to analyze the issues discussed during the BOF and to gather data on market perception, and then report the results to the community? Thanks, Andy On Wed, Jul 18, 2018 at 1:31 PM, Ted Hardie wrote: > Greetings, > > The IESG and IAB understand that there are significant questions about th= e > RFC++ BoF likely to come up during the plenary. Given the IAB's role as = a > shepherd of the RFC series, we anticipate questions during the IAB portio= n > of the open mic. > > As context, below are some thoughts on the BoF from the IAB. > > First, some of this is the result of tired people working to a deadline. > That rushed effort tried to capture a set of discussions, some of which g= o > back before the current IAB (RFC 1796 , > potential adoption of BCOPs > , > possible new IRTF publication stream), and some of which started at this > year=E2=80=99s IESG and IAB retreats. Second, while the experiment in t= he BoF > proposal did not have IAB consensus, the IAB strongly believed that we > needed to hold the related discussions in a public forum. Holding that > discussion only within the IAB or even with the RSOC and RSE did not seem > to us to match the need for transparency for a set of issues of this > importance to the community. > > > The proponents brought the discussion to the IAB and IESG in the context > of a BoF because the basic function of a "birds of a feather" session is = to > hold a public meeting for folks interested in a common topic or issue. > While our usual BoFs are about working group formation, that core meaning > is why the proponents took that route to reach the community. > > We made some mistakes in that: > > > - > > The context built up by the IESG and IAB at their retreat and in other > discussions did not translate into the BoF description, even for those= who > read all the listed background material. > - > > Some of the folks already involved in the RFC processes were not part > of early coordination. > - > > The problem statement was not sufficiently articulated, and the > discussion on the list did not start early enough to help. > - > > The use of the BoF term and the location of the meeting at an IETF > caused some concern that other parts of the Internet technical communi= ty > were being deliberately ignored. > - > > Engaging folks who were not deeply familiar with the IETF process did > not work, despite some folks putting in significant effort to do so. > - > > The proposed experiment also did not resonate at all well with the > community, and the IAB has heard that feedback loud and clear. > - > > The early discussion on the list also caused the chairs to reshape the > agenda; while that had some positive effects in moving the discussion = up a > level, some folks found removing all mention of the experiment confusi= ng. > > > On the positive side, the BoF did give folks a forum to share both their > concerns about the issue of confusion and for members of the community to > give clear feedback on their perception of the risks inherent in making > changes to address the issue. It also gave clear feedback that Heather, = as > RFC Series Editor, sees gathering data about market perception of the RFC > Series as in her bailiwick under the terms of RFC 6635. She noted at the > BoF that she will bump it up her priority stack. We'll take that into > account in understanding where she's spending her time, and we'll make su= re > the RSOC will do so too. > > The IAB confirms that any data she brings to us on that topic will be mad= e > public and that any discussion of next steps will similarly be public. > That won=E2=80=99t use a BoF format, given the feedback, but it will be a= s open as > we can manage. > > We also heard questions about how the IAB spends its time. You can see > the IAB report to the community, sent earlier, on the IAB website > . > Further input on what our priorities should be is always welcome at > iab@iab.org or architecture-discuss@iab.org. > > See you at the plenary, > > Ted Hardie > > For the IAB > > > > > > > > > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > > --000000000000c2956f057149d2b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ted,

Thank you for your clear summariza= tion of the IAB=E2=80=99s thoughts.

To make the ne= xt step clear, would that be for the RSE to analyze the issues discussed du= ring the BOF and to gather data on market perception, and then report the r= esults to the community?

Thanks,
Andy


On Wed, Jul 18, 2018 at 1:31 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

Greetings,<= /p>=

The IESG and IAB understand = that there are significant questions about the RFC++ BoF likely to come up = during the plenary.=C2=A0 Given the IAB's role as a shepherd of the RFC= series, we anticipate questions during the IAB portion of the open mic.


As contex= t, below are some thoughts on the BoF from the IAB.

First, some of this is the res= ult of tired people working to a deadline. That rushed effort tried to capt= ure a set of discussions, some of which go back before the current IAB (RFC 1796, potential adoption of BCOPs, possible new IRTF publication stream), and some of which started a= t this year=E2=80=99s IESG and IAB retreats. =C2=A0=C2=A0Second, while the = experiment in the BoF proposal did not have IAB consensus, the IAB strongly= believed that we needed to hold the related discussions in a public forum.= =C2=A0 Holding that discussion only within the IAB or even with the RSOC a= nd RSE did not seem to us to match the need for transparency for a set of = issues of this importance to the community.


The proponents brought the discussion to the IAB and IESG in the = context of a BoF because the basic function of a "birds of a feather&q= uot; session is to hold a public meeting for folks interested in a common t= opic or issue.=C2=A0 While our usual BoFs are about working group formation= , that core meaning is why the proponents took that route to reach the comm= unity.


We made some mistakes in that: =C2=A0


  • The = context built up by the IESG and IAB at their retreat and in other discussi= ons did not translate into the BoF description, even for those who read all= the listed background material.

  • Some of the folks already involved in the RFC processes were not part = of early coordination.

  • The = problem statement was not sufficiently articulated, and the discussion on t= he list did not start early enough to help. =C2=A0

    =

  • The use of the BoF term and the location of the meet= ing at an IETF caused some concern that other parts of the Internet technic= al community were being deliberately ignored. =C2=A0

  • Engaging folks who were not deeply familiar with th= e IETF process did not work, despite some folks putting in significant effo= rt to do so. =C2=A0

  • The propo= sed experiment also did not resonate at all well with the community, and th= e IAB has heard that feedback loud and clear. =C2=A0

  • The early discussion on the list also caused the ch= airs to reshape the agenda; while that had some positive effects in moving = the discussion up a level, some folks found removing all mention of the exp= eriment confusing. =C2=A0


=

= On the positive side, the BoF did give folks a= forum to share both their concerns about the issue of confusion and for me= mbers of the community to give clear feedback on their perception of the ri= sks inherent in making changes to address the issue.=C2=A0 It also gave cle= ar feedback that Heather, as RFC Series Editor, sees gathering data about m= arket perception of the RFC Series as in her bailiwick under the terms of R= FC 6635. She noted at the BoF that she will bump it up her priority stack.= We'll take that into account in understanding where she's spendin= g her time, and we'll make sure the RSOC will do so too.<= /font>


The IAB confirms that= any data she brings to us on that topic will be made public and that any d= iscussion of next steps will similarly be public.=C2=A0 That won=E2=80=99t = use a BoF format, given the feedback, but it will be as open as we can mana= ge.


We= also heard questions about how the IAB spends its time.=C2=A0 You can see = the IAB report to the community, sent earlier, on the IAB website.= Further input on what our priorities should be is always welcome at iab@iab.org or architecture-discuss@i= ab.org.

=

= See you at the plenary,<= br>

Ted Hardie

For the IAB










_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus


--000000000000c2956f057149d2b6-- From nobody Wed Jul 18 11:17:28 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8F1130E8B; Wed, 18 Jul 2018 11:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=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 5JxDc3jVO1jJ; Wed, 18 Jul 2018 11:17:23 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6A4130E8A; Wed, 18 Jul 2018 11:17:22 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id i12-v6so10586263oik.2; Wed, 18 Jul 2018 11:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gZD/sLITvUtdTCxAt5icTq6gNGrofDtOcw3pAfyqKV0=; b=j/cGkGgNTh6TXVvJQQEsW+zPhJoPZzT7PuBrVa8Ut5cDPydU+2AeJ1ar7rCydUtu7W zQSBg0JcxMLMm14arT36NPdanm3l1nmgEwO4d3/DDBobU5lNIMqjHNUT9LmtGN96oSNy QjufvCcx03pXTSSkw4+Oq63h5Kq7F4ViOvHZAIW++nkfye8LHWwwQq1KjM4O599pZ+nm HAbnmXJbHa4n76zDscxEkd2FfF8sxLGH7boNk3TlSYLWZGJdhoCdst6AZTbLK2bC5IiO iZYeXgkktm+pRhGBf0OFzKWFFFupCInHPydZ+CwhED5nrf3cO6tjOgkk81fEGysSVsYV FPAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gZD/sLITvUtdTCxAt5icTq6gNGrofDtOcw3pAfyqKV0=; b=XRHjbg68Dz3GWZuh3nVQyJtTfdLuUfo+MQ7MddMLxB+I+H/MLTd/5Lgx0e+t9EoNPi m8wpgG/Z1gLoq41Lh4cYxp72o0mkGQSvYJ2ZrmqGkKqC5vah49LuI07jRdfbN7aN9ktE VOCE1uT1NMdCtiYjB2LJ/NL5jG+Cf+QYcHTu43Mu+/1KCAkgN4UzWJ14BhglFESDqtWN vVEelLSKm9UG5lHMcErBSqLG2JkyAR5AlLPyvSbkXuYvjc52NFTRGVm8pp4OcpWRlSsp rfWTUmCILyRguGo8zPGIfcDZJEdrORXGzW4pa8ZTGk4SjgE+EqM/44Kqo0i3T7jcazqB jcqg== X-Gm-Message-State: AOUpUlGblT6UuctvBtqKGCtlr+HSJAA+y/cgg1XqDu6MstIcF4FRZRc1 SIPF+GM5equmDT8G8uUZFfJUQK74LQ7xLpuDV74= X-Google-Smtp-Source: AAOMgpcLbY1Mpx34q4FuVQSGavSl976v87heJJb7oyuFVCVf/YUUCbLgp2BjzdVKm5KdczGSsFCmvfapVyQxeBAf8fs= X-Received: by 2002:aca:2c83:: with SMTP id s125-v6mr3913198ois.103.1531937842020; Wed, 18 Jul 2018 11:17:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 11:16:51 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Wed, 18 Jul 2018 14:16:51 -0400 Message-ID: To: "Andrew G. Malis" , "Heather Flanagan (RFC Series Editor)" Cc: rfcplusplus@ietf.org, IETF Content-Type: multipart/alternative; boundary="000000000000e4471905714a12d5" Archived-At: Subject: Re: [Rfcplusplus] A note on tonight's plenary X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 18:17:27 -0000 --000000000000e4471905714a12d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2018 at 1:59 PM, Andrew G. Malis wrote: > Ted, > > Thank you for your clear summarization of the IAB=E2=80=99s thoughts. > > To make the next step clear, would that be for the RSE to analyze the > issues discussed during the BOF and to gather data on market perception, > and then report the results to the community? > > I've copied Heather explicitly here, in case she has not yet seen your question. I think there is likely to be more than one next step, but I believe among them will be Heather gathering data on market perception of the RFC series. Note, however, that she only committed at the BoF to moving it up the priority stack; she and the RSOC are very busy with the final stretch on the format work at the moment. She may be able to comment further, regards, Ted > Thanks, > Andy > > > On Wed, Jul 18, 2018 at 1:31 PM, Ted Hardie wrote: > >> Greetings, >> >> The IESG and IAB understand that there are significant questions about >> the RFC++ BoF likely to come up during the plenary. Given the IAB's rol= e >> as a shepherd of the RFC series, we anticipate questions during the IAB >> portion of the open mic. >> >> As context, below are some thoughts on the BoF from the IAB. >> >> First, some of this is the result of tired people working to a deadline. >> That rushed effort tried to capture a set of discussions, some of which = go >> back before the current IAB (RFC 1796 >> , potential adoption of BCOPs >> , >> possible new IRTF publication stream), and some of which started at this >> year=E2=80=99s IESG and IAB retreats. Second, while the experiment in = the BoF >> proposal did not have IAB consensus, the IAB strongly believed that we >> needed to hold the related discussions in a public forum. Holding that >> discussion only within the IAB or even with the RSOC and RSE did not see= m >> to us to match the need for transparency for a set of issues of this >> importance to the community. >> >> >> The proponents brought the discussion to the IAB and IESG in the context >> of a BoF because the basic function of a "birds of a feather" session is= to >> hold a public meeting for folks interested in a common topic or issue. >> While our usual BoFs are about working group formation, that core meanin= g >> is why the proponents took that route to reach the community. >> >> We made some mistakes in that: >> >> >> - >> >> The context built up by the IESG and IAB at their retreat and in >> other discussions did not translate into the BoF description, even fo= r >> those who read all the listed background material. >> - >> >> Some of the folks already involved in the RFC processes were not part >> of early coordination. >> - >> >> The problem statement was not sufficiently articulated, and the >> discussion on the list did not start early enough to help. >> - >> >> The use of the BoF term and the location of the meeting at an IETF >> caused some concern that other parts of the Internet technical commun= ity >> were being deliberately ignored. >> - >> >> Engaging folks who were not deeply familiar with the IETF process did >> not work, despite some folks putting in significant effort to do so. >> - >> >> The proposed experiment also did not resonate at all well with the >> community, and the IAB has heard that feedback loud and clear. >> - >> >> The early discussion on the list also caused the chairs to reshape >> the agenda; while that had some positive effects in moving the discus= sion >> up a level, some folks found removing all mention of the experiment >> confusing. >> >> >> On the positive side, the BoF did give folks a forum to share both their >> concerns about the issue of confusion and for members of the community t= o >> give clear feedback on their perception of the risks inherent in making >> changes to address the issue. It also gave clear feedback that Heather,= as >> RFC Series Editor, sees gathering data about market perception of the RF= C >> Series as in her bailiwick under the terms of RFC 6635. She noted at the >> BoF that she will bump it up her priority stack. We'll take that into >> account in understanding where she's spending her time, and we'll make s= ure >> the RSOC will do so too. >> >> The IAB confirms that any data she brings to us on that topic will be >> made public and that any discussion of next steps will similarly be >> public. That won=E2=80=99t use a BoF format, given the feedback, but it= will be as >> open as we can manage. >> >> We also heard questions about how the IAB spends its time. You can see >> the IAB report to the community, sent earlier, on the IAB website >> . >> Further input on what our priorities should be is always welcome at >> iab@iab.org or architecture-discuss@iab.org. >> >> See you at the plenary, >> >> Ted Hardie >> >> For the IAB >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >> >> > --000000000000e4471905714a12d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 18, 2018 at 1:59 PM, Andrew G. Malis <agmalis= @gmail.com> wrote:
Ted,
<= br>
Thank you for your clear summarization of the IAB=E2=80=99s t= houghts.

To make the next step clear, would that b= e for the RSE to analyze the issues discussed during the BOF and to gather = data on market perception, and then report the results to the community?


I've copied He= ather explicitly here, in case she has not yet seen your question.

I think there is likely to be more than one next step, but= I believe among them will be Heather gathering data on market perception o= f the RFC series. Note, however, that she only committed at the BoF to movi= ng it up the priority stack; she and the RSOC are very busy with the final = stretch on the format work at the moment.=C2=A0

She may be able to comment further,

regards,

Ted

=C2=A0
Thanks,
Andy
=


On Wed, Jul 18, 2018 at 1:31 PM, Ted Hardie <t= ed.ietf@gmail.com> wrote:

Greetings,<= br>

The IESG and IAB understand t= hat there are significant questions about the RFC++ BoF likely to come up d= uring the plenary.=C2=A0 Given the IAB's role as a shepherd of the RFC = series, we anticipate questions during the IAB portion of the open mic.


As context= , below are some thoughts on the BoF from the IAB.

=

First, some of this is the resu= lt of tired people working to a deadline. That rushed effort tried to captu= re a set of discussions, some of which go back before the current IAB (RFC 1796, potential adoption of BCOPs, possible new IRTF publication stream), and some of which started at= this year=E2=80=99s IESG and IAB retreats. =C2=A0=C2=A0Second, while the e= xperiment in the BoF proposal did not have IAB consensus, the IAB strongly = believed that we needed to hold the related discussions in a public forum.= =C2=A0 Holding that discussion only within the IAB or even with the RSOC a= nd RSE did not seem to us to match the need for transparency for a set of = issues of this importance to the community.


The proponents brought the discussion to the IAB and IESG in the = context of a BoF because the basic function of a "birds of a feather&q= uot; session is to hold a public meeting for folks interested in a common t= opic or issue.=C2=A0 While our usual BoFs are about working group formation= , that core meaning is why the proponents took that route to reach the comm= unity.


We made some mistakes in that: =C2=A0


  • The = context built up by the IESG and IAB at their retreat and in other discussi= ons did not translate into the BoF description, even for those who read all= the listed background material.

  • Some of the folks already involved in the RFC processes were not part = of early coordination.

  • The = problem statement was not sufficiently articulated, and the discussion on t= he list did not start early enough to help. =C2=A0

    =

  • The use of the BoF term and the location of the meet= ing at an IETF caused some concern that other parts of the Internet technic= al community were being deliberately ignored. =C2=A0

  • Engaging folks who were not deeply familiar with th= e IETF process did not work, despite some folks putting in significant effo= rt to do so. =C2=A0

  • The propo= sed experiment also did not resonate at all well with the community, and th= e IAB has heard that feedback loud and clear. =C2=A0

  • The early discussion on the list also caused the ch= airs to reshape the agenda; while that had some positive effects in moving = the discussion up a level, some folks found removing all mention of the exp= eriment confusing. =C2=A0


=

= On the positive side, the BoF did give folks a= forum to share both their concerns about the issue of confusion and for me= mbers of the community to give clear feedback on their perception of the ri= sks inherent in making changes to address the issue.=C2=A0 It also gave cle= ar feedback that Heather, as RFC Series Editor, sees gathering data about m= arket perception of the RFC Series as in her bailiwick under the terms of R= FC 6635. She noted at the BoF that she will bump it up her priority stack.= We'll take that into account in understanding where she's spendin= g her time, and we'll make sure the RSOC will do so too.<= /font>


The IAB confirms that= any data she brings to us on that topic will be made public and that any d= iscussion of next steps will similarly be public.=C2=A0 That won=E2=80=99t = use a BoF format, given the feedback, but it will be as open as we can mana= ge.


We= also heard questions about how the IAB spends its time.=C2=A0 You can see = the IAB report to the community, sent earlier, on the IAB website.= Further input on what our priorities should be is always welcome at iab@iab.org or architecture-discuss@i= ab.org.

=

= See you at the plenary,<= br>

Ted Hardie

For the IAB










_____________________________________= __________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus



--000000000000e4471905714a12d5-- From nobody Wed Jul 18 11:23:07 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F64130EEA; Wed, 18 Jul 2018 11:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 LH6l4-HCfjzg; Wed, 18 Jul 2018 11:23:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 EBEDE130F12; Wed, 18 Jul 2018 11:23:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ffr6I-0008Ml-Qr; Wed, 18 Jul 2018 18:22:58 +0000 Date: Wed, 18 Jul 2018 14:22:58 -0400 Message-ID: From: Randy Bush To: Ted Hardie Cc: "Andrew G. Malis" , "Heather Flanagan (RFC Series Editor)" , rfcplusplus@ietf.org, IETF In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Rfcplusplus] A note on tonight's plenary X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 18:23:06 -0000 does the iab micro-manage everything it touches? if so, perhaps there is some adjustment needed. i was there for kobe-1. rsndy From nobody Wed Jul 18 12:34:53 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AEF130FB8; Wed, 18 Jul 2018 12:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KoK_45itkFk; Wed, 18 Jul 2018 12:34:44 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E929130F7F; Wed, 18 Jul 2018 12:34:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 803A11D1B84; Wed, 18 Jul 2018 12:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgqNRMyQSjOh; Wed, 18 Jul 2018 12:34:30 -0700 (PDT) Received: from [IPv6:2001:67c:1232:144:ad6e:4a50:8493:fe3a] (unknown [IPv6:2001:67c:1232:144:ad6e:4a50:8493:fe3a]) by c8a.amsl.com (Postfix) with ESMTPSA id 33AC61D1B83; Wed, 18 Jul 2018 12:34:30 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0F466588-2D20-418C-B72D-EB73E8316665 Mime-Version: 1.0 (1.0) From: Heather Flanagan X-Mailer: iPad Mail (15G77) In-Reply-To: Date: Wed, 18 Jul 2018 15:34:39 -0400 Cc: "Andrew G. Malis" , rfcplusplus@ietf.org, IETF Content-Transfer-Encoding: 7bit Message-Id: References: To: Ted Hardie Archived-At: Subject: Re: [Rfcplusplus] A note on tonight's plenary X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 19:34:47 -0000 --Apple-Mail-0F466588-2D20-418C-B72D-EB73E8316665 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jul 18, 2018, at 14:16, Ted Hardie wrote: >=20 >> On Wed, Jul 18, 2018 at 1:59 PM, Andrew G. Malis wrot= e: >> Ted, >>=20 >> Thank you for your clear summarization of the IAB=E2=80=99s thoughts. >>=20 >> To make the next step clear, would that be for the RSE to analyze the iss= ues discussed during the BOF and to gather data on market perception, and th= en report the results to the community? >>=20 >=20 > I've copied Heather explicitly here, in case she has not yet seen your que= stion. >=20 > I think there is likely to be more than one next step, but I believe among= them will be Heather gathering data on market perception of the RFC series.= Note, however, that she only committed at the BoF to moving it up the prior= ity stack; she and the RSOC are very busy with the final stretch on the form= at work at the moment. =20 >=20 > She may be able to comment further, Indeed she can! I=E2=80=99m not quite sure how much detail you all are looki= ng for, but I=E2=80=99ll give you a quick outline. I=E2=80=99ll also note th= at I=E2=80=99m always open to feedback if people think I might be missing an= area to explore.=20 My most immediate next steps involve talking to a wide variety of people, bo= th within the SDO universe and some a bit farther afield. For example, I hav= e set up time to talk to a few people at the Internet Society about how they= generally go about doing market research; I=E2=80=99d like to know what res= ources within this area of expertise are immediately available. =46rom ther= e, I will be reaching out to several of my contacts within the scholarly and= technical publishing community to get some ideas of what they do when they e= ncounter a journal that might need to be broken out into separate entities. (= Note: I don=E2=80=99t know that we=E2=80=99re ever going to want to do that,= but the information on the process from folks who do this kind of thing rel= atively frequently will be useful.) I also plan on collecting (perhaps commi= serating) with contacts at the W3C, IEEE, NISO, and possibly ISO to get a be= tter understanding of what they do, what they wish they had done, and what (= if any) changes we make would do to their workflow and reference material.=20= The IETF community can also expect me to be reaching out to see if I can fin= d contacts within some of the big companies that reference our documents to s= ee what they know (or think they know) about RFCs and how they would expect t= o find out about changes to the series. But honestly, I don=E2=80=99t expect= to get to this step for a while. I need to have clearly formed questions fi= rst. What happens after all that information gathering largely depends on what I f= ind out. As always, I=E2=80=99ll try to keep people updated via my RSE repor= ts, discussions on rfc-interest, hallway conversations, bar conversations, R= FC Editor desk conversations, airplane boarding queue conversations, and any= other ways I can think of that might be useful.=20 I hope that helps clarify what I=E2=80=99m going to do next in with this top= ic. As Ted pointed out, my priority is to get the format project in producti= on. I=E2=80=99d also like to spend some quality time determining how to impr= ove the quality of metadata for RFCs, explore the possibility of a sandbox s= pace to experiment with things like web annotations, work with the RPC to se= e how their tools and workflow can be improved, and several other things.=20= Thanks for all the feedback this week! As always, contact me if you have any= questions, ideas, concerns, or other feedback you=E2=80=99d like to offer. -Heather Flanagan, RSE= --Apple-Mail-0F466588-2D20-418C-B72D-EB73E8316665 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Jul 18, 2018, at 14:16, Ted= Hardie <ted.ietf@gmail.com>= wrote:

On Wed,= Jul 18, 2018 at 1:59 PM, Andrew G. Malis <agmalis@gmail.com> w= rote:
Ted,

Thank you for your= clear summarization of the IAB=E2=80=99s thoughts.

To make the next step clear, would that be for the RSE to analyze the issue= s discussed during the BOF and to gather data on market perception, and then= report the results to the community?


I've copied Heather explicitly here, in case she has no= t yet seen your question.

I think there is likely t= o be more than one next step, but I believe among them will be Heather gathe= ring data on market perception of the RFC series. Note, however, that she on= ly committed at the BoF to moving it up the priority stack; she and the RSOC= are very busy with the final stretch on the format work at the moment. = ;

She may be able to comment further,

Indeed she can! I=E2=80=99m not quite sure how m= uch detail you all are looking for, but I=E2=80=99ll give you a quick outlin= e. I=E2=80=99ll also note that I=E2=80=99m always open to feedback if people= think I might be missing an area to explore. 

My most immediate next steps involve talking to a wide variety of people, b= oth within the SDO universe and some a bit farther afield. For example, I ha= ve set up time to talk to a few people at the Internet Society about how the= y generally go about doing market research; I=E2=80=99d like to know what re= sources within this area of expertise are immediately available.  =46rom= there, I will be reaching out to several of my contacts within the scholarl= y and technical publishing community to get some ideas of what they do when t= hey encounter a journal that might need to be broken out into separate entit= ies. (Note: I don=E2=80=99t know that we=E2=80=99re ever going to want to do= that, but the information on the process from folks who do this kind of thi= ng relatively frequently will be useful.) I also plan on collecting (perhaps= commiserating) with contacts at the W3C, IEEE, NISO, and possibly ISO to ge= t a better understanding of what they do, what they wish they had done, and w= hat (if any) changes we make would do to their workflow and reference materi= al. 

The IETF community can also expect me to b= e reaching out to see if I can find contacts within some of the big companie= s that reference our documents to see what they know (or think they know) ab= out RFCs and how they would expect to find out about changes to the series. B= ut honestly, I don=E2=80=99t expect to get to this step for a while. I need t= o have clearly formed questions first.

What happens= after all that information gathering largely depends on what I find out. As= always, I=E2=80=99ll try to keep people updated via my RSE reports, discuss= ions on rfc-interest, hallway conversations, bar conversations, RFC Editor d= esk conversations, airplane boarding queue conversations, and any other ways= I can think of that might be useful. 

I hope t= hat helps clarify what I=E2=80=99m going to do next in with this topic. As T= ed pointed out, my priority is to get the format project in production. I=E2= =80=99d also like to spend some quality time determining how to improve the q= uality of metadata for RFCs, explore the possibility of a sandbox space to e= xperiment with things like web annotations, work with the RPC to see how the= ir tools and workflow can be improved, and several other things. 
=

Thanks for all the feedback this week! As always, contac= t me if you have any questions, ideas, concerns, or other feedback you=E2=80= =99d like to offer.

-Heather Flanagan, RSE
= --Apple-Mail-0F466588-2D20-418C-B72D-EB73E8316665-- From nobody Wed Jul 18 13:06:19 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E691130FF8; Wed, 18 Jul 2018 13:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, 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 vc5GaXg6ZlNa; Wed, 18 Jul 2018 13:06:15 -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 928CF130FDF; Wed, 18 Jul 2018 13:06:15 -0700 (PDT) Received: from dhcp-8743.meeting.ietf.org (dhcp-8743.meeting.ietf.org [31.133.135.67]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6IK6B04059606 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 Jul 2018 15:06:12 -0500 (CDT) (envelope-from adam@nostrum.com) To: Heather Flanagan , Ted Hardie Cc: "Andrew G. Malis" , rfcplusplus@ietf.org, IETF References: From: Adam Roach Message-ID: Date: Wed, 18 Jul 2018 16:06:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] A note on tonight's plenary X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:06:18 -0000 Thanks for the detailed outline, Heather! I have one bit of feedback. On 7/18/18 15:34, Heather Flanagan wrote: > The IETF community can also expect me to be reaching out to see if I > can find contacts within some of the big companies that reference our > documents to see what they know (or think they know) about RFCs and > how they would expect to find out about changes to the series. In the interest of completeness, I would suggest that such an effort needs to include reaching out to the communities associated with open-source projects as well. /a From nobody Wed Jul 18 13:13:25 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB734130FDF; Wed, 18 Jul 2018 13:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 WtcROQu_0Gaf; Wed, 18 Jul 2018 13:13:20 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BF4130EC8; Wed, 18 Jul 2018 13:13:20 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id v71-v6so6119929itb.3; Wed, 18 Jul 2018 13:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DE9Up3pjRkiLm3179QYdbuUZ+A6iF6sKz57YYowrm1Q=; b=TADCORxy2I8U47HspwQ8HKH6LexEN5J39sjg3AHvXSpVsYsbr1kfa2pqbbwYHzbTvV BDTzPwX5VlGJQnlqklz1rGRc8OEJDqdn5VSOS7ruGGAl9eGoTZ6w1erIRpeIWqXnZMSr fr3Kk7kvlNiXdnB8s/nMRTDYMhGd9LZ2DcgB8rDU6VFF+ALesGFBT1U20aTfA70e3fIf OSIdE1bcjb6dTOpwYUU0DLRQPobYNjThesaIT4Eg8RrCerawejVyb7xQwJMPQMDAEXGX 1CafSLx/Hb2s9zyFJtUmGctBxdYi7uxyFohPB7mbni3G6S2b26OlxGeLghQfNVaD9Lnn NQ6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DE9Up3pjRkiLm3179QYdbuUZ+A6iF6sKz57YYowrm1Q=; b=qeSxyofoRk1vzVkg0lN0TxYzHd47BadT91Px/9NPBjOiOWeoz12yoAtIq/xmDqjo7x EyLjIPDIxtYqJSPXiw/RR+xeQaanTgJxsG7iMvRfGPELKXpF7SaZq4PlLDW1SU8SC3Z0 qIID7Vf0kv2dVSukjSO7MreEJdVUqpQPQhL+xvC0GfHMc9zFSlim1xMuJviaR8iwDrFX QbahkarG7D4r0baRKpKpvG8Y5mSk1o9RcmPOGLW+fJsa32E3Nl4epP7Lr/aofV8gpSg1 E43FPtLA0IoIiY4krBnCDCdnNnEpgVI++uGwr9ZCuPFlfUO+1tDjMVMshiWvdSJfeyl7 9+FQ== X-Gm-Message-State: AOUpUlGePMZSWw/Ptvj5sRUnKNSkC2/YkCRaWSHq4B+BCjtm/WbQH5OK eZU0qYGtOQJ8phD4oiPU3+g= X-Google-Smtp-Source: AAOMgpfqTyx/5iIMjV9RkD0cTjNJA44JWH9VFoHxVDvP8CfnGZImyu7Q983S64NEGSD0nA0UCbJskQ== X-Received: by 2002:a02:970a:: with SMTP id x10-v6mr6885291jai.137.1531944800075; Wed, 18 Jul 2018 13:13:20 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:b568:48b0:f7f3:d8f8? ([2001:67c:370:128:b568:48b0:f7f3:d8f8]) by smtp.gmail.com with ESMTPSA id b15-v6sm1909302itb.25.2018.07.18.13.13.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 13:13:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: heather flanagan X-Mailer: iPad Mail (15G77) In-Reply-To: Date: Wed, 18 Jul 2018 16:13:18 -0400 Cc: Heather Flanagan , Ted Hardie , rfcplusplus@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <38356279-C4B7-4322-AAFC-06E4FE8982F8@gmail.com> References: To: Adam Roach Archived-At: Subject: Re: [Rfcplusplus] A note on tonight's plenary X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:13:23 -0000 > On Jul 18, 2018, at 16:06, Adam Roach wrote: >=20 > Thanks for the detailed outline, Heather! I have one bit of feedback. >=20 >=20 >> On 7/18/18 15:34, Heather Flanagan wrote: >> The IETF community can also expect me to be reaching out to see if I can f= ind contacts within some of the big companies that reference our documents t= o see what they know (or think they know) about RFCs and how they would expe= ct to find out about changes to the series. >=20 > In the interest of completeness, I would suggest that such an effort needs= to include reaching out to the communities associated with open-source proj= ects as well. >=20 ooooh, excellent idea! Thanks! If you have any particular communities and/or= contacts in mind, please drop me a note off list. It occurs to me, as I continue to think about this, that groups like the NOG= s, the RIRs, and other operator groups should be on the list, too. -Heather > /a >=20 From nobody Wed Jul 18 13:40:35 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93053130E44 for ; Wed, 18 Jul 2018 13:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=ericsson.com header.b=dA4OC39Y; dkim=pass (1024-bit key) header.d=ericsson.com header.b=fOstwzjx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIKjADnFrIXQ for ; Wed, 18 Jul 2018 13:40:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 8ABCE130E21 for ; Wed, 18 Jul 2018 13:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531946428; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7UUOU6LvenuHvcE4HTrH8oK299RUafeiQVtknIdrAhQ=; b=dA4OC39YUQk12T1nh/y4j+YB+G16KSjiiqy81hJcUXuLidwUBIf1xWLpkUC1OtJL LvxdhZKEctV+uKRQo5lbsQbLAHRf2K43iput+no5SbbIRaKgSk7wE/DpOng8DDo+ ywh+FRAHSD/IeFW7/Fh2Krq/aZvJGk8FR6Yjrnx6Prc=; X-AuditID: c1b4fb2d-223ff700000055ff-6a-5b4fa5bc415c Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.E5.22015.CB5AF4B5; Wed, 18 Jul 2018 22:40:28 +0200 (CEST) Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 18 Jul 2018 22:40:28 +0200 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 18 Jul 2018 22:40:28 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7UUOU6LvenuHvcE4HTrH8oK299RUafeiQVtknIdrAhQ=; b=fOstwzjxMEUkJTTs27sSW0ktjuB2EXM4uTEbbdd3HNbjRjk+dYm0qkfsooGByb54L/9I5MG45pMOYnpWuc6Tms9B+Z9pffpQ9i0h++eWn/0igiY34Jmza+SnIoiG0k5E6ZUbvlAXousGkjuxbKkOewPe0J3IcN8WgLgjGwWI2k8= Received: from [IPv6:2001:67c:1232:144:d921:d110:6aeb:a1a1] (2001:67c:1232:144:d921:d110:6aeb:a1a1) by HE1PR0701MB2108.eurprd07.prod.outlook.com (2603:10a6:3:2a::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Wed, 18 Jul 2018 20:40:26 +0000 To: From: Gonzalo Camarillo Message-ID: <6d8fcaa0-713d-f3b8-1a02-cba42cbe0ab5@ericsson.com> Date: Wed, 18 Jul 2018 16:40:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [2001:67c:1232:144:d921:d110:6aeb:a1a1] X-ClientProxiedBy: MWHPR08CA0040.namprd08.prod.outlook.com (2603:10b6:300:c0::14) To HE1PR0701MB2108.eurprd07.prod.outlook.com (2603:10a6:3:2a::27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 218750fc-510f-4053-403f-08d5eceeb1cb X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2108; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2108; 3:qx7k89eq49mrEx2UlppkrTbOb66GIWu16eBuNFDL4qflndw6unbiUPb/BJTpaWd+bKAetlIQQOwxFj1GpJIjW9TrTH1aepa4gegYuAgfuvEUOuE2HrXH49evmnpDBY1+dYiYV90zp9m+/tssbg70Kc/BeOH6v3hQsaEBX9T9Pu/TH9B/jQvtgXTlVe4NXhVp5cocuRxAi9aKCqlfFGK9BuKRcsYgMi7rtURqYdj5CXgbHjmNtHJHK9d7xCzEJBiP; 25:sCXDGvBj+r+MO+V3VnQuSCiae5a+jmfRS3YMMhd2ggqATVwwwLdD+pChWRG37ZOlqYf10gi6+pCPwXU7vDZjYt78NsbfLXYoSRdmvwxnLhbwHvSm6NjqiXeTu95y3Xb0CJmC3LOTjoZ9IxD2/EKGGBE9hz+XBEHtSQMSxJjSfn3ufnNqpGJSJ3utyuzasJlFvJw24mFgi2XZD9HFxI7yPu9r2FoYbKi/nxyDTtX3zJty4Ii19YXz5hhLmD/PvVRFFXV2xFyroYInPp/8IhrLZf57Bpt2ecvzKXb6tzyDeHffbi8JetSXuBRQ4zVf5pqXqykPhTa/yRb2b3HCPmcK0w==; 31:oeUeEL8uVDiWRhgG4EA+MkbYO4RPHnz7qb74AgOcDljUGGaIB7FYtSYSL/wVaG0n7RpkdJQADayKdpnLkfwaZvuqeN666Hawg6QgTMT33DOM3jGixVIxDJj8opu906C9/wO8EhGHb+BOo+8J8jJJXhnrZg6jlYZHm0+eC+JSk7Q+3YCaSiGsoKFuZt32qdDtNBSvPDD2X+QujFCWMKSo+tRLrzyq6fpznYOmK5nKW94= X-MS-TrafficTypeDiagnostic: HE1PR0701MB2108: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2108; 20:IpbTH7Kp4ex1F/oK8YQB93+WeDb4KJ+7fDIux1Wdi8kCvCP5MUk/Vs5yELC7fj2ycbMMiIEy40ULxDekcKwwS4WsI4qXaxGO5ksM321QMMC+LbHfbg+SY1XZCEcU330bxOwBHhbo/JwgE/bZLqjlK5WwDyXbJYtY63jhyt0jOnUfU2Z4l0uGVaHyBEzxi9xS7Jmvz5Qg3r693JArdhlCBlCYWQ8lkoGZaOL98vRRJ7zcdchHxf0P35D908OcJcH2XNq14H4f98JhLt0irRAzHJgul1xQHRUUdliIaWNXp8forZpcpDhsuf7tnD95NuFFEkWCxxF1ThFwkWlPwDWxPJtaPGwNbXeWKkLvLB1ZvSFJLCtb11cB4FLbTu9TFu8nVFKyUCRBdb/yY6z0BA43dMMOwv1d88IPt6BpVeyWxMbtjr/TLWg2LbdEzyHFTFQLdQ+llFty3PrssxJnmI6W9epbz0vmQuoQJTzvny8lJLnj+UqMDVvqTqSPoDnnlaT3; 4:tKEyKO/tVz6XX9zDmZLdrX6BLO2/dUzWJsi2VK2r2Fv1BHy61mbTDcDWJ82L+K6eIvTXP07BD7XkPT6TYyxjrEqgVjanKKfYyZurOBvSBVC3lxIUvimsNuh1fVLxwpgqpGhntD+X0AhsWrNPP5/ZUBod71QxQLj4Rits5cIfyp3Zph8atqovO/KlPrvoINnzvBokOC8IU3Y5zqMHsRQIGoX4hQGJLhyq+SSBN9jDhx4+qsPLqC9P5ioroZiOscjT8C/vzy7dPz8z55hdhhvD8LuX7UAb+7t4ue+VL29HmutMEcqDDPmWSIRnmBqLJCHH X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:HE1PR0701MB2108; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2108; X-Forefront-PRVS: 0737B96801 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(136003)(346002)(366004)(376002)(396003)(39860400002)(199004)(189003)(36756003)(53936002)(386003)(230700001)(2486003)(23676004)(47776003)(31696002)(65806001)(52146003)(1706002)(25786009)(65956001)(558084003)(6916009)(52396003)(6486002)(2616005)(486006)(478600001)(97736004)(64126003)(476003)(86362001)(81166006)(6116002)(81156014)(305945005)(46003)(52116002)(186003)(16526019)(8936002)(6666003)(31686004)(966005)(7736002)(8676002)(65826007)(68736007)(2906002)(106356001)(2361001)(105586002)(5660300001)(50466002)(2351001)(316002)(6306002)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2108; H:[IPv6:2001:67c:1232:144:d921:d110:6aeb:a1a1]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjIxMDg7MjM6Yzh0ckdTWjRQNi95RzdhVGZxd2I2K24w?= =?utf-8?B?cnBDTWxmQmRqWmZaRFNGZUIrcUZ6azlkQ0xlcXhsOFhRNmg1M3NRTUV2Rmsw?= =?utf-8?B?YlYwT3gzZzlZMXhQZHBkWmFVWmxMVk1DZ3J1dmpXck8rZjNQRkdpUnQ3L1ZJ?= =?utf-8?B?a3BTRUpRSmZWVU9pbDdwZDB0VG9EYlFCdktlanRERkFKaWsrcUJPWHM2NU1o?= =?utf-8?B?MXY0MER0RDk4SkRaZnllbHNPQlUxVWdHNWh0ejRER3B6SVN0K0lFWTNaQmJC?= =?utf-8?B?TUVBU0hISlZEWVFvYk9nRHBkeTNhaWwxc0pOaXYxNzM2aXF4ZE4yS1pEeUd0?= =?utf-8?B?OTRHN01yNzJHdkJvWXNnR1ZOZUYwc3ExOC9JN0N2QjF3aElUbmdNUkp4QUln?= =?utf-8?B?NEpOTzI2VGVHSnFxMS8zNWZ0Q3ZMS2dRbi92U1N6Y05LZSsxTndYZ0NqcWRm?= =?utf-8?B?RDM1SFA3b0dOTVdub3pUZjhpYzBEaTBjMXVwRWdzTis5MWpGWk5WMzB2QmFw?= =?utf-8?B?bEp2MUZTbURORGt5QTl4aU1xbHU5Mm9DTXMxdUMzeGdwRitMVy8xWHFyY3Fj?= =?utf-8?B?cEEwcXNGZ01iRWl1dGRPQ1RyRWszMG1kOEM2T1hXem15RlVKQjh5L0J4ZERV?= =?utf-8?B?d0xDOXNQTkFzZlRxd3NjZXR1UGhXRERadTZZRlJQWWJpL0lDc1hDekVrZGYv?= =?utf-8?B?U2FrdGlHWkN6UmJqaUxCem9YV3VGbk8vTTZDYVRQUTRXb0NNcnAzR2oxNzlW?= =?utf-8?B?R1E1Z2xOQ0hPY1RFYXJYT1VpbmdXVVNZMW4rSS92dnlIdFVCeUpYZ3V2cjJN?= =?utf-8?B?K3FtZU91WTU5eXFyVUthRmRQMkpRV3RCd1RDY2tldVRFKytOcFZycGp2cmp6?= =?utf-8?B?SEt4YnFWREVSNHhsL05uNFZJUlM5aWNSejJyNlhhRXBVOE9BalBTa0FFeE9T?= =?utf-8?B?aWgwQ2FDSFdGN2tqdkQwZHdLSzlsODc4VWkzT25CbXM5bFFvYnVRZjRDb29G?= =?utf-8?B?MHJta0hoQmY0TTc3L0taK3liRzlHamdrNmIrdmN4YWdaZkFWeXkxNEorenBX?= =?utf-8?B?dTY2TVlTcXNBdGxpdXNlbnFwYzFJUkxMY1dSOHdVaHluYU1OWlpnT1JkZkJ2?= =?utf-8?B?R0JCdlNQSzFRbkJyL1oxQmRVcWJXdkRsTGZWV2k0cnl6dVB5cHJMNkh4Wmto?= =?utf-8?B?T3laQnVzbmFJWFV3MkFEVTZpVlV4c3Z4dDJrWXhlVU1XRjFlczFOZ1Rid25H?= =?utf-8?B?WVF1QVhaWDVhU0pHQ09IcWtjRUdwbkcvMTd0UzlwU0lPT3RrbjlGamJCWThZ?= =?utf-8?B?TEN1dVBmaUcydEhPYVhKK2tTM2lmclpET2p4VXJXeTRuSGN1ejNPaU4ydHJG?= =?utf-8?B?UmdNcXh3Wml2b3pHMHpOQzQvQ3dHVk5jTkhxc0JOS0V2MWFNSnhyQWt3ZWJv?= =?utf-8?B?UTRWRjZRS3lwWXBrWGlvZXZ0NGUwN2FVaUJRRHhBeWlEbm9PR0Zzc2U2NjhP?= =?utf-8?B?bE5WNkg1b3lPYXUzR2NsMlJ1eFhVc1RIeGxONUE3dFF2YzRyQ1NjZks1UzBI?= =?utf-8?B?VG1XaXNSZDdjb3A0aU1WbVhOSGo5Z09nd3Erd0k0TGY4OTJ1NDBBR1hRR0c4?= =?utf-8?B?aG5XNVAxWE9naUI1Rk5jc0ZmTm4vNHpWZ3duR2E4c0hWYUgwbXNEMGszc0Jl?= =?utf-8?B?R3BZZDJhVVloM2tvaDlDRy9FMzJsNUx4aTdpQkkwbWFObmVuTWhiU1NjOUZz?= =?utf-8?B?MjF3WXlTMzVUM1N0cTZVa09nPT0=?= X-Microsoft-Antispam-Message-Info: ToRiM6plS+nYwzxP/TP9UyjVJ+ImSlqFwXZc9oW44FVlH86vxuo0nmBJYvYFUrxnQ7R7R8yZ9we+lvK2pC+JRHxtoq5GNxn1NdGYcnoMubn9PPToIZIx62gsw4yz4LVbTDSHIYxaroqF8dJQrKKCp8QVd48jsi17wuGC3TD8RY7P+BRX4bgPAGfoJyGcGELv9kKpb3+I+AS4lRo3N9nqIECbYvluDYVVp1V+1AAsWmxOZ1gYbc9EXp3e1L0rsEHEqVbHVPDx0EI8Hfn2ldattktz1ZzoOgjkq2k/tc+qjAf5LF2EDjQ/WfFK+lMK9ts353QsTzY0BUEAh3hAZekCqudlHtDNu9WhzTSxvOqRCaE= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2108; 6:6/+A76NOb1SiSGra9E3p3jPK7Wrs8yvN8soBzFBCwm7CPVxviBI0UARVVd9Rdz4XZ3Xwp/sXR4sxXFX5B2ZzxORkH4cQYoxwl/+R/aKYk0fnbTMC8XKSqQ3VR+nqfD2qEWeYSdPofZez/+mROkoOrEgnGAsGMyCS9Y3OdAlyGTOeAIoYbgc6SKsitDyEeQqo5e5LHc+js+cG8l3T1/AuQR6W7uy2wV+CA3mcZ43jjAjD2iMVCwbRkwxtpnBUxbp+Xn/US1gZ11OUKNNOaxg4hEXxGxHyIlOCQhmZveIquaeGN47uZ4p6beWk5tH5ACDrqNQL1nagiZpuGMiYzO+bYpy/hJ1bjZEE4MufSbQEQHrTfti4ig2YOih6Aw9MgYnTIjHrneTlqR9LO3gjy4jak8YfC5Xc8d0zdWOEJJMAzeZvssDmk3/S9/Wfi10wkHpAnkyjIph4bXQSrDpJ1XX/0A==; 5:GCZ+m4snXTkb4zpbpiYEyzeyiDkBRDEQcZncXQPYTFpcJUZPFF0pwO4c1zo8hOwqVo7ZC61pd31KktXWU3y1eNaG2QEkYkX7tfOhl7v5JBgFuHGIXQi52F8de7yOkyxNuMgH7AWnBhPaTHj3j+2xdnj7iY7Q7y/5CK+U0FV3aNY=; 7:ci8r/sIIA4urT1fZfWoMTf5FcFZI8mTNoQVsh8K65qWoViYQoUe81AMnpKMVWErwTnZ560Bb1wt5zodVveScfnSJejtnHPwZeaNjbXKXwN7xcV17Ys76CbUZGoyhttfRWp4WfaAe2LRPtvClXAzv14zWo3bL0zKR+szl+VwBUEqNFzJg54hsnW9/lfrxx5JdGtpkWvInCLwf2TZrH9veODpg/daiI/Jv4lFtOQwmnSYe68cNVcZZOBuGf4Hbixy7 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jul 2018 20:40:26.2208 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 218750fc-510f-4053-403f-08d5eceeb1cb X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2108 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUyM2J7me6epf7RBvd2m1m83F7nwOixZMlP pgDGKC6blNSczLLUIn27BK6MDXNXMRbsYqyY83UqUwPjXMYuRk4OCQETiZ7PX5m6GLk4hASO Mkos/LSXGcL5xijx4MxXKGcJk8TsfRcZQRwWgQnMEi3ndrBBZHYwSay59oYZZJiIgJTExC8N TCA2m4CFxJZb91lAbGEBfYk7X26wgti8AvYSj14eZgOxWQRUJQ7v2wZWIyoQI3F0cgsbRI2g xMmZT8DizALqEn/mXWKGsMUlbj2ZzwRhy0tsfzuHGeIJS4md90B2cQHZ0xklelongzULCWhL bF5zCupTWYmjZ+ewQNi+EmdOTWCFaDjJKPHxxleo7iZ2iePXzzNBVOlIdCybzQ5iMwokSvy9 95YNougXm8TCtWegdudL3H+5AmqFtcSpLROh4nISp3rPMUE0HAKG2OInUFNlJNq/74FKPGWV WLHiGuMERp1ZSB6fheTxWUgen4Xk8QWMLKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxApPF wS2/dXcwrn7teIhRgINRiYc3YZJ/tBBrYllxZe4hRgkOZiUR3oPv/aKFeFMSK6tSi/Lji0pz UosPMUpzsCiJ8+qt2hMlJJCeWJKanZpakFoEk2Xi4JRqYLReJb/mV4l+gHyW7Ok815L5XKG3 +hL9/3oI76yOkTEynWzxo1tpLnMTx47syY5GEh6bbl9kXyGjqKPPyjktwMbkBMONC9IzXazX ry3U0ZXau3LBl8erH1lFPVqzc2GI3WuPosiC06+3rc/kerlWM2up7oUisRXfnzPsZzm48lCN ZVaJ/H6uh0osxRmJhlrMRcWJANg8y7cSAwAA Archived-At: Subject: [Rfcplusplus] Draft minutes of the RFC++ BoF session X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:40:34 -0000 Folks, please, find the draft minutes of the session under the following link: https://datatracker.ietf.org/meeting/102/materials/minutes-102-rfcplusplus-00 Cheers, Gonzalo From nobody Wed Jul 18 13:48:12 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5584713103B for ; Wed, 18 Jul 2018 13:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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=cooperw.in header.b=WlOMYtco; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r38RRAUF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVBBdCBhO2L0 for ; Wed, 18 Jul 2018 13:47:55 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CE213103A for ; Wed, 18 Jul 2018 13:47:55 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5DE0F21AC1 for ; Wed, 18 Jul 2018 16:47:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 18 Jul 2018 16:47:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=Zn4TlkvK1MYcDRhTbBlFXmH3d+CFXnhQgvfOkxCgwik=; b=WlOMYtco AZTG2i4dR2yQzHjW1LYqRVljUC5nK4dpe9yGg0eYgFMTEQw3UVzgFQ0SuTJaqmin jT3IQZAUnVHVT5VunfTSVl/vzSzJuGtVTczu2eJRCcbasSwYJTAe0YP3b8Uc34Ih 2kQIoPrxCdvHhhtSnUMtfUMIdOgr9Zw9fUWGw9Pa01q+CBdBRodT4Sjbu8IhpG8V h8JjVqXbzhzkM558XYykkEHFg1eB//PkKiOAUZ/HRwVtYOfTHTDzS5A0rtSayB/W fiPcYwqMHU1/3AnD4aJVcg+bPAxx7Nw6CDzWaZrwbFY1jPG4mVjzAI9ldNRUTZXl Dn4W4pXLsxgdCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=Zn4TlkvK1MYcDRhTbBlFXmH3d+CFX nhQgvfOkxCgwik=; b=r38RRAUFrFRZ5Ap9Cdl0+pEI4sYUg/oWYmVDbuC7TSHsx 48MKuUdiOBzM/zOXLwHtawQIWRYlamKR8Z8c/ad2KHLerI+ySRCLqv+tUeoqOkr6 psWgtQC7rnPZkb4gf0sIVP3Wi93U0yf7UZn0Eq1/XeOK5DSvZxL/bTvG5eDPJARr FW1AWduyrPD/+NZ4u64edKMDyHJ9mqoRGWICgIT/S1JVvQFIsM+KQm3UG6nSq5om YEENVdZQYMYvDQmel/1mlVIruU7bGTDPzBK/PW7yjfXi8oElF2FWBcKUSvyLgXC4 cwgdbY76NFWFVT3Dg9kLulLXUwfHqc9gz6f2FYn8Q== X-ME-Proxy: X-ME-Sender: Received: from [31.133.144.141] (dhcp-908d.meeting.ietf.org [31.133.144.141]) by mail.messagingengine.com (Postfix) with ESMTPA id 00C10E454E for ; Wed, 18 Jul 2018 16:47:54 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Wed, 18 Jul 2018 16:47:50 -0400 Message-Id: <414E1C53-F259-42FE-8AD4-A3C5FEFFEEE4@cooperw.in> To: rfcplusplus@ietf.org X-Mailer: iPhone Mail (15F79) Archived-At: Subject: [Rfcplusplus] Closing this list X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:48:10 -0000 Now that the BOF minutes have been posted I will be asking the secretariat t= o close down this mailing list. Thanks to everyone for your engagement durin= g and prior to the BOF. Per Heather=E2=80=99s note, discussions appropriate for rfc-interest@ietf.or= g should continue to take place there. Alissa= From nobody Wed Jul 18 13:49:39 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F43130E44 for ; Wed, 18 Jul 2018 13:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 v5_MZOo2QZAQ for ; Wed, 18 Jul 2018 13:49:34 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 6F4591271FF for ; Wed, 18 Jul 2018 13:49:34 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id o22-v6so4180345ioh.6 for ; Wed, 18 Jul 2018 13:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zaczYgq5cZjR1aS6JJNiV7BrKOjaDBg6pepnY77zg68=; b=CVXHtMaYhl4SKvC8YQ9AOQV7fsObRwi0P0CvhE7Je3R/1TWx15SdCelryR3pUIzXWx S9GxkDNLYXeTSDZ0A6nZC+JPNQRSojKBN3Abh8pmv8ylhrDLYhro+iqIM2z6O3TLKUS/ BHiTGirXIECoUzZ+hP6+ZmDuJ7XTsveShWA3K19u5ydDhvCcyS3+B7iiGIaq5l99DOSE kzvQQzb7raHqihptUfDbrIKpAUT6NRibYENJ3SJZxoIhwo0jKTjGDfzBRi11YHBE6t87 mK533Ht9eVJDz7umjhJj3/PQ52R+YEFgXl33iYxf62d3O4s7y9FjxBiIjMZShsxiI5BJ 85Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zaczYgq5cZjR1aS6JJNiV7BrKOjaDBg6pepnY77zg68=; b=fZOImScupi1CUGRNe6Pwgh71yLRLKd4EF84dst3G9Hfa/CrTeZ80dyVswsijF1Hn7M GT/fPg808LxEXQLBkBDma/wU/OdSL2PWgK5LSgfmhnv/OBGivYEXUxX0nJujgvSAR47i 09gwzSqLQIhr0pmDPqr+EEbPDw70AIFBmLmurDHoSnQU9kIMogUk8eE/MFXT53mytwO9 BpTT2MkOjU1Rx013iRR1Ib22waXQCAwSwicqgf4lQiLYKVoOtd43yNJkwl6WAg9I6gur vSWPIYUggHL5iKoFfJVyFJ1sU2C/VPPVgFyKM40in6CBBz6v3RrW+EEovogXrS6w0fNk x67w== X-Gm-Message-State: AOUpUlH6b3UOf3quipD/ZzeoxdKFQ+GNSE422yvwct7Jg679pYSW3TG1 95DUX3PboqjDU9VwO8N/Kvef8w== X-Google-Smtp-Source: AAOMgpfFakhAP3WKJAAYg4xiMHNzFU6+xzFp5j6bn1aSg02FImE/gnxJvsa/z0QADja9aNMkTlexdw== X-Received: by 2002:a6b:4a15:: with SMTP id w21-v6mr5916180iob.277.1531946973583; Wed, 18 Jul 2018 13:49:33 -0700 (PDT) Received: from [31.133.150.114] (dhcp-9672.meeting.ietf.org. [31.133.150.114]) by smtp.gmail.com with ESMTPSA id m7-v6sm1903210iog.30.2018.07.18.13.49.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 13:49:32 -0700 (PDT) To: Gonzalo Camarillo , rfcplusplus@ietf.org References: <6d8fcaa0-713d-f3b8-1a02-cba42cbe0ab5@ericsson.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <8694e7c8-5c7f-6280-781d-79db05a38c05@gmail.com> Date: Thu, 19 Jul 2018 08:49:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <6d8fcaa0-713d-f3b8-1a02-cba42cbe0ab5@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Draft minutes of the RFC++ BoF session X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:49:37 -0000 Hi Gonzalo, I don't quite see the one clear conclusion, which has already been followed up, that the problem analysis should be carried forward by the RFC Series Editor. Regards Brian On 19/07/2018 08:40, Gonzalo Camarillo wrote: > Folks, > > please, find the draft minutes of the session under the following link: > > https://datatracker.ietf.org/meeting/102/materials/minutes-102-rfcplusplus-00 > > Cheers, > > Gonzalo > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus >