Re: [Rfced-future] Model proposal

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 07 July 2020 17:27 UTC

Return-Path: <jmh@joelhalpern.com>
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 04A473A1164 for <rfced-future@ietfa.amsl.com>; Tue, 7 Jul 2020 10:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 KxTmyYICh0U8 for <rfced-future@ietfa.amsl.com>; Tue, 7 Jul 2020 10:27:21 -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 567EF3A0F43 for <rfced-future@iab.org>; Tue, 7 Jul 2020 10:27:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4B1Ts51FK9z6GD3f; Tue, 7 Jul 2020 10:27:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1594142841; bh=lWd40QBHwuyooLdUOMdHp9HfhRzo8b6djRCxhVd7jhU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JfZXKawQ4cfHdvq4wOKHJAF/0ll4EEfwuJud6l3s+RQZqK9vEv6M7WHPs30OY5hOG jgme6RjLOufU0LqCAY4lh/U+KeaE7kZO1hBz1UUBcMhrCeYEc22kUYh3CWkXfEvsZ3 DAVOf6V/Jj61WalBpbRSk6lOX2eYs9+Nx1z3+0h4=
X-Quarantine-ID: <gpjV6UaxaR4p>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (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 4B1Ts44pMqz6GCnp; Tue, 7 Jul 2020 10:27:20 -0700 (PDT)
To: Eric Rescorla <ekr@rtfm.com>
Cc: rfced-future@iab.org
References: <d4d1cd2d-6df2-4cb4-b63a-f9bba45b48c0@www.fastmail.com> <51b72823-f2a2-29bd-bd88-f63e13522387@gmail.com> <d1f33279-0656-4caa-81e7-aa665d3a4acb@www.fastmail.com> <CABcZeBMdrfjy+kqQ20MS_1fZrNddff+ycwau5VdC5qAFQN2qVA@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <7eb9cdfc-c295-8de8-cba5-a5a1ca6ff6f7@joelhalpern.com>
Date: Tue, 07 Jul 2020 13:27:19 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBMdrfjy+kqQ20MS_1fZrNddff+ycwau5VdC5qAFQN2qVA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/0_PI8DePq_vxjLYS4aOKSEm6NhA>
Subject: Re: [Rfced-future] Model proposal
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: Tue, 07 Jul 2020 17:27:23 -0000

I understand that other communities handle authorship differently, and 
that we may (collectively) decide to handle it differently for the RFC 
series than we currently do.

However, if we few it as a single series (which we currently do, with 
subdivisions) we have taken the few that I think is appropriate that we 
want a single approach to general appearence, etc.  As such, having 
drastically different authorship policies for different sub-sets of RFCs 
would seem a drastic change.

Yours,
Joel

On 7/7/2020 1:04 PM, Eric Rescorla wrote:
> 
> 
> On Mon, Jul 6, 2020 at 9:19 PM Martin Thomson <mt@lowentropy.net 
> <mailto:mt@lowentropy.net>> wrote:
> 
>     I do recall several lengthy discussions about the number of authors
>     on a document, but as these were recurrent and inconclusive, I am of
>     the view that these are perfect for a working group to strategize on.
> 
> 
> I'd like to focus in on this example for a moment, as it also consumed
> a fair amount of IESG time, and I think it shows some of the
> complexity here.
> 
> Authorship conventions vary fairly significantly even within
> genres. For instance, in computer security alone, I am familiar
> with at least three primary author ordering rules:
> 
> - Students first, ranked from most to least contribution, followed by
>    professors (sometimes ranked loosely from least to most
>    supervision/engagement). [a lot of Security]
> 
> - Students first, but loosely ranked by increasing need to find a job
>    as well as contribution, then professors as above
>    [Systems-influenced Security]
> 
> - Alphabetical [Crypto]
> 
> If you go outside computer science into broader paper publishing
> you will also see the following (among others):
> 
> - Giant author lists [especitally particle physics [0]]
> 
> - Detailed taxonomies of what contributors/authors did
>    [medicine [1]]
> 
> 
> My point here is that authorship policies depend on what values the
> community in question is trying to promote (recognizing people's
> contributions, advancing their careers, precisely delimiting what
> everyone has done, having a single point of contact, etc.). And when
> we discussed these topics in the IESG, we discussed similar
> considerations. Thus, while these discussions certainly do benefit
> from understanding the perspectives of other communities deciding on
> the right policies is more about community objectives than it is about
> publishing expertise.  Indeed, it seems possible that we might develop
> different policies for different streams depending on which objectives
> are most important to those streams.
> 
> -Ekr
> 
> 
> [0] 
> https://www.nature.com/news/physics-paper-sets-record-with-more-than-5-000-authors-1.17567
> 
> [1] 
> https://www.elsevier.com/authors/journal-authors/policies-and-ethics/credit-author-statement 
> 
> 
>