[Rfced-future] What do we need/want?

Martin Thomson <mt@lowentropy.net> Thu, 02 April 2020 04:40 UTC

Return-Path: <mt@lowentropy.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 E1A033A0C27 for <rfced-future@ietfa.amsl.com>; Wed, 1 Apr 2020 21:40:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ZlJWlPZ/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Bs4HmcT9
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ggdXPVMKcsC for <rfced-future@ietfa.amsl.com>; Wed, 1 Apr 2020 21:40:48 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F033A0C26 for <rfced-future@iab.org>; Wed, 1 Apr 2020 21:40:48 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 7D40C693 for <rfced-future@iab.org>; Thu, 2 Apr 2020 00:40:46 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 02 Apr 2020 00:40:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=AqPEyB7rtFuhqJ5MDiQYtHbG3WMkxqruC7OjdzWnkmY=; b=ZlJWlPZ/ RTjcCIF51cRuuYV4TF/EAUtLObHeVTF0RPUuJt/0BYNxb1vxEVnDkRzzZhIxWb74 EXTux6DEyMloIbKl6rYCbKgzZUAcn6O4ZWaw5Tj9RN2+7BZ+KRWoEH22nIHqxHNH WTh2IFcFwAKaK/kRu5mmzmhBtDzlH43mwW8efQoeU2aOFFM3NeV7WKY7LLMXoEvd 3ykygfa5PNEDDnSmrBxx6UMD0pL0Vv6zZOZcshI5XjacHh6IUU5XsLyX6w61cA9m amxp9aL/caAec1keVK+hJTamM/lbXv2jH2tzhLaRME5HHiTJdzAdrcQFpX4B1XOC Dpg0qlIUtRUUag==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=AqPEyB7rtFuhqJ5MDiQYtHbG3WMkx qruC7OjdzWnkmY=; b=Bs4HmcT9Oirgl6AnoF5VJ3saWuSa+zZ+jDDohVkB5NfSr st0jbig4jD3+Ki2jjCRGicy5zrfH9Lx8Sti0Z3TmrW/SRzA4riMWnQrMDAJBjQbI DD18sn6XgJdqet8a719jrUkTFxr5/i8VsvMuSC1MLd76kcx0m2qyORgkBY9WFmHg A7LUAi9piMTEdnpSV04iJnIShufACdev62gH9iJCG7m3HdCsxGnG+cdTOTMaXiyA bW/FHIlu4TfqCTJ3f/NXzuDLqyfA1bKT26Rp7P5KIERjUxgtp72VEpfKiF9z68yf MGXRHPhx8W8OAQE+tb0GY+xY+U0NVPdzXAwAfod4g==
X-ME-Sender: <xms:zWyFXll4E-cP2NkXMgUgP9-ikYeSdZBXtasyf_DWTrMJxZnAvoytyg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdefgdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhho phihrdhnvght
X-ME-Proxy: <xmx:zWyFXvcnJnKc4lIJhq9FbP2tNGlNltAGYbbJ3hr7Bci3R873g0-5BQ> <xmx:zWyFXrR9lTA3CakGUsEtvU0ASGtGy0a4CH1d08YRaT6f2VSQ988bbA> <xmx:zWyFXryeD3m5d4e305ZSvZrrpCC65wTh1GGho9DjowgHpfrMwxecmQ> <xmx:zmyFXsKLIYk4l_3SDEWVxnQWvkDJEqrTzjjloVrbpHRyhstHQrgtZw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id ABA0EE00A6; Thu, 2 Apr 2020 00:40:45 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-1079-ga710375-fmstable-20200402v4
Mime-Version: 1.0
Message-Id: <eec2eaa1-5577-4efd-870e-ae43cdd0ed8d@www.fastmail.com>
Date: Thu, 02 Apr 2020 15:40:25 +1100
From: Martin Thomson <mt@lowentropy.net>
To: rfced-future@iab.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/U6LNEOu3ZfEmfULFKuw74D4dpOw>
Subject: [Rfced-future] What do we need/want?
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: Thu, 02 Apr 2020 04:40:50 -0000

I appreciate Brian's attempt to avoid blame in trying to look for problems.

I think that we also need to ask what this community needs and wants from this function.  Maybe that's a little out of scope, but I think that it matters a great deal.

https://iaoc.ietf.org/documents/RSE-descr-2016-r6-Clean.pdf contains a recent statement of work.  RFC 8728 defines what the RFC editor *is*.  Plus the other stuff Eliot shared.  But in terms of the structure in which the function sits, what is truly important?

In terms of over-arching goals, I have heard "good enough to support the series for another 50 years if the content is up to snuff", paraphrasing Stephen (hopefully accurately), which might be good as an abstract mission statement, even if it is a bit of a mouthful.  That last clause about the quality of content does a lot more work than I'd like there as well.  This does imply some unspecified strategic decisions; you don't have a hope of operating on that timescale without a lot of forethought.

Worrying about a legacy over very long periods is not worth the effort that might be expended on it.  You could examine the system we have - one that clearly exhibits survivor bias - with the hope that you might learn something relevant, but we could instead concentrate on doing the best we can over periods that are more relevant.  5 years is a solid length of time to plan for, if not 10-15.

The other meta-goal I routinely hear "keep the RFCs coming".  That might lead to ignoring or downplaying the challenges we might need to anticipate.  I happen to think that this is highly relevant, if not the totality of the overall goal.  The format change has not been good in that regard.  I had a simple, standalone document that was relatively time-sensitive sit in queue for almost 4 months after approval.  At the other extreme, I also have another document that is still being processed after almost 4 years in queue.  My understanding is that the RSE is responsible for anticipating and working to avoid systemic or structural problems of that nature.  To use the words the RSOC used: that's an important, but tactical function.

To me, the series exists to serve a community of people who benefit from creating a record of their agreements (and disagreements if you like).  That we use a bespoke and user-hostile format is not a feature, but a bug.  That we depend on extensive and expensive copy-editing is more bug than feature, as much as I appreciate the improved quality of the result.  That we insist on these artifacts being immutable is a bug.  And many other things that I'm sure will elicit much disagreement.  However, those are not important characteristics of the series; the content - and often the agreements that the content codifies - is what matters.  And besides that, those questions aren't in scope for this effort.

Our goal is to work out how we might designate responsibility for leadership on those - and other matters - to a role that fits within our organizational structure.  Again, I'm tempted to ignore that scope and ask why we need that leadership to be so delegated, but I will try to keep on target.

We have, for the longest time, had a single figurehead to shepherd those aspects of the series that matter least. I don't see any editorial control being exercised over content, with the exception of the Independent Submissions Stream, where ISE discretion is the entire purpose of the stream.  What has been achieved there in to my knowledge has been largely tactical.  Yes, it matters that we have DOIs on documents and that we can use real names, those are changes with long-term value.  Archival agreements and rescuing data from old bits of paper is similarly good, but not really strategic. Assigning responsibility to anticipate and address problems like that is important, but it does not require someone with the stature of previous RSEs.

Meanwhile, valuable content continues to be published in RFCs.  And other SDOs produce work with far less pomp and circumstance.  So while we have created a role to which great gravitas has accrued, maybe we don't need that and a little more employee and less venerated elder is in order.  For the leadership part, maybe we should look to the community.