Re: [Rfced-future] RFC Principles - long delayed

Mark Nottingham <mnot@mnot.net> Fri, 12 November 2021 02:37 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D90E3A1076 for <rfced-future@ietfa.amsl.com>; Thu, 11 Nov 2021 18:37:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZDqyb4dR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=meQGSu/r
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uoh0PRYi3xxW for <rfced-future@ietfa.amsl.com>; Thu, 11 Nov 2021 18:37:03 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D273A1070 for <rfced-future@iab.org>; Thu, 11 Nov 2021 18:37:02 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A96975C01EF; Thu, 11 Nov 2021 21:37:01 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 11 Nov 2021 21:37:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=j e09K8NEOXI70JxM1LgRY+kquqs/LOGoKf8qcL2OmUs=; b=ZDqyb4dRGxXlUN471 rAUliqtVSFnB8Qctcj3lfLlL50ecTG8b8vfgAuYKRF/tzWkPTceLssXEONSv+QTx tT+jWsAoU4A0oLNMjE8IyqKSjZsW/GQbMQgHQeDEqz1/d0iRznHSwcShcqOT4AiQ hiI62jbqwX9HYGIUqEIfNvxJYGw6twrErrzHgW837KXSnikpM5vvSHkJ3wVVm9v7 UgfbHPKlr7QguZhuuBPtbKN3YytNyi4TsfRbtIADEsEaASZ+6WswyVxfqjSpS4nw 0aPQFxjFCImjMV9AoA/iC1NTgG8F0YIbvbPE7YAemc+N0hbdepje/gNbVVvpu21M GEQMQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=je09K8NEOXI70JxM1LgRY+kquqs/LOGoKf8qcL2Om Us=; b=meQGSu/rGv78QgSMv9iWi/maMOEZ82I7qhbTmA9wK8VcrMuPM83bzsXFn bfqOZx3aTASKiDw4MdeYP+2Yn6LEEk+RIMzw7VsT049u7n9BAdwAHDnPlj44f8UZ pJDnYAnSVksvxlw12OIJVU9k9PSjZzld0ql2wdbj5MZUiZzRL5V8KUreOC3xI0Ru ML3yiAqReEjBKHyij5D9ZMu2JSDZz40wGwKNMvUSnFH4NyKst3NUv1jBQF06/fE5 KN6EmlJgO0gD+NnghFdQ6RgbBL9FC8M1dz5U9evKqPRrnnLYjdsQqimum9oGis4o j+Dimok/t8r+2Wf0EV1JBhzjZmBQg==
X-ME-Sender: <xms:TdONYQcptEYrthQsJn_KaZ2cgKs4ugOHh6URZDugGsyXgX_v511RXg> <xme:TdONYSPe-yOiolecIyipVzZ1vfzjGNtaHrkWSSh2DvIRnB0pTWni7bkvFf9zaCF1L 4_GlrtwJ0ZfLHJ65w>
X-ME-Received: <xmr:TdONYRhfdbUALGh43cgr36F5zoCsrjcFOiFtRdHpcKkMlPYR9u6VSotc2QS0bFLpjLdt8jXwb0EzG9d2eJmrFMqwdv5atc06dgNTi3V3QSeFea2fttEAcrPr>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrvddvgdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeeiteduuddvudfftedtuddvgeehtdeuhe ehjeegledtleekvefgffehfefffeffgfenucffohhmrghinhepihgvthhfrdhorhhgpdhi rggsrdhorhhgpdhmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:TdONYV95bHWxYIrvLAteP-T_4BBtKJvDiMFAKkaXAE7a_XBd5NyTig> <xmx:TdONYcvLEvYFqFT9dAL3qMG4-r583LhzwaTgkgQDDtK4YflEEhJK4Q> <xmx:TdONYcHDIxPwpVgQIyf-acbW8wqSA8ZD00Yuc8I-Pc_oqtPehe3rgQ> <xmx:TdONYYKAvr16876Qw-2ojiQBjq4CY_jK8SYYVM-aaxGIK4OGQ2yydQ>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 11 Nov 2021 21:37:00 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <79d32c80-dd1d-daf4-ae8e-5064a7d41dba@nthpermutation.com>
Date: Fri, 12 Nov 2021 13:36:58 +1100
Cc: "rfced-future@iab.org" <rfced-future@iab.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EAAF1215-A904-4003-A967-A5DE168BF88A@mnot.net>
References: <79d32c80-dd1d-daf4-ae8e-5064a7d41dba@nthpermutation.com>
To: Michael StJohns <msj@nthpermutation.com>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/I_EQ-Cc039OWV627W1lFeKz9PVM>
Subject: Re: [Rfced-future] RFC Principles - long delayed
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Nov 2021 02:37:09 -0000

I largely agree with EKR here -- these may be perfectly appropriate principles, but the proper place to agree to them is in the RSWG process itself, not here. 

I.e., this is out of scope for this program.

Cheers,


> On 12 Nov 2021, at 4:20 am, Michael StJohns <msj@nthpermutation.com> wrote:
> 
> I apologize for the delay in providing the following.  This is the aftermath of Stephen's question/comment about heritage and it morphed into a document that attempts to describe current RFC series principles.  I've passed this by 1/2dz or so folk and this incorporates their comments.
> 
> 
> 
> 
> # Principles for the RFC Editor Series
> 
> The following principles provide some guidance as to the scope of
> documents that the RSWG may propose and the RSAB may approve.
> Documents or proposals which suggest modifications of any of the
> principles shall require additional approvals past that of the
> RSWG/RSAB, specifically consent from the IAB, IESG and the LLC and
> such approvals shall be granted only after gaining strong community
> consensus for such a change.
> 
> 
> ## Availability
> 
> The RFC series documents have been freely available digitally for more
> than 35 years.  No change shall be made to the model which would
> introduce fees for access to any or all of the RFC series documents.
> Distribution of RFCs shall continue to be subject to the Trust
> license<<REF:
> https://trustee.ietf.org/documents/trust-legal-provisions/>>.
> 
> ## Accessibility
> 
> There is a general goal to make the RFC series documents as accessible
> as possible to communities that have special needs - e.g. seeing
> impaired. Proposals that might negatively impact accessibility shall
> require the approvals of the IESG, IAB and LLC in addition to that of
> the RSAB.
> 
> ## Publication Language
> 
> The publication language of the series is, and shall remain, English.
> No action shall be taken which will prohibit the publication of
> translations of the RFC series in other languages, but the normative
> content language of an RFC shall remain English.
> 
> 
> ## Commonality of Purpose
> 
> The RFC series is the general publication system for information
> related to the Internet, networking technology, and community
> discussions on those topics.  Neither an expansion nor contraction of
> that scope is desired.
> 
> 
> ## Diversity of Interests
> 
> The RFC series has published thought experiments, speculative ideas,
> research papers, histories, humor [RFC1149, RFC2549], and even
> eulogies [RFC2468].  And, more recently, Internet standards.  Each of
> these RFCs and their communities have contributed to the rich history
> of the RFC series, and to its somewhat human-centric take on networking.
> If we did not acknowledge this and attempt to conserve the means of
> such expression we would probably be poorer for it.
> 
> As the Independent Stream and IRTF Stream are the primary places that
> non-standards related conversations take place, and with a desire to
> maintain diversity of interests in the system, neither of these
> streams may be disestablished except by the approval of the IESG, IAB,
> LLC Board, and with strong community consensus.
> 
> The RFC brand shall not be reserved at any time now or in the future
> solely to apply to a single community of interest i.e., IETF
> publications.
> 
> 
> ## Breadth of Expression
> 
> While the RFC series has its own brand and style, the series is
> expected to account for individual expression where possible.
> 
> ## Archival Quality
> 
> Paraphrasing from the introduction to [RFC8153]:
> 
> The RFC Editor System provides both publication and archival services
> for the RFC Series, although there is nothing prohibiting those roles
> being split apart. In the archival role the main goal is to preserve
> both the information described and the documents themselves for the
> indefinite future.  To meet both publication and archival needs, the
> RFC Editor System must find the necessary balance between the
> publication needs of today and the archival needs of tomorrow, while
> acknowledging a finite set of resources to complete both aspects of
> the RFC Editor System functions.
> 
> As there may be legal implications related to changes in archive
> policy, changes in the applicability of RFC8153 to the RFC Series, and/or
> changes to RFC8153 shall require the approvals of the IAB, IESG and
> LLC in addition to RSAB approval.
> 
> 
> ## World-class Publication
> 
> As a world-class publication, quality, readability and accuracy are
> key to the success of the RFC Series. The publication process is
> designed in part to enhance those characteristics.  Unfortunately,
> those ideals are sometimes at odds with a desire for an increase in
> speed of publication.  Any RSWG proposals that promote speed at the
> expense of quality, readability or accuracy shall require the
> approvals of the IESG, IAB and LLC in addition to that of the RSAB.
> 
> -- 
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--
Mark Nottingham   https://www.mnot.net/