Re: [urn] listed authors

Alfred Hönes <ah@TR-Sys.de> Wed, 04 July 2012 18:21 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AC221F872A for <urn@ietfa.amsl.com>; Wed, 4 Jul 2012 11:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.579
X-Spam-Level:
X-Spam-Status: No, score=-98.579 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMfmNgZHvT6X for <urn@ietfa.amsl.com>; Wed, 4 Jul 2012 11:21:30 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 76B6621F86EC for <urn@ietf.org>; Wed, 4 Jul 2012 11:21:29 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA158875997; Wed, 4 Jul 2012 20:19:57 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA04031; Wed, 4 Jul 2012 20:19:56 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201207041819.UAA04031@TR-Sys.de>
To: barryleiba@computer.org
Date: Wed, 04 Jul 2012 20:19:55 +0200
In-Reply-To: <CAC4RtVBB=uPxnXB_0eFJUfxGTfBeewX+-Sud+fVjD40w9c=3nw@mail.gmail.com> from Barry Leiba at Jul "4, " 2012 "09:47:37" am
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org
Subject: Re: [urn] listed authors
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2012 18:21:31 -0000

Barry,
speaking as the acting editor of multiple URNbis WG documents,
I fully share your point of view.

The IETF is not academia where formal authorship is sought for
visibility, to increase publication counts, even if the actual
contribution to the work leading to a publication is more at
the spiritual level than at the actual craftmanship in preparing
the document on behalf of a working group.  In the IETF, authors
grant the IETF the right to prepare any kind of derivative work
(and they have always done so); of course, previous work needs
to be fully acknowledged, and that's what the (mandatory)
Acknowledgements and (optional) Contributors sections in RFCs
are for.

This all is backed by the RFC Editor's
"Instructions for Request for Comments (RFC) Authors"
(instructions2authors.txt, aka draft-rfc-editor-rfc2223bis-08.txt),
which say:

* in Section 2 (1st para):

|                                                   [...]  RFC authors
|  should obtain the latest RFC editorial policy statements from the RFC
|  Editor web page [RFCed].

where the Normative Reference is:

   [RFCed]   RFC Editor web page, "http://www.rfc-editor.org".

* in Section 2.12, "Authors Listed on RFC":

|     The IESG and IETF have ratified a policy of limiting the number of
|     authors listed in the first page header of an RFC.  The specific
|     policy is as follows:
|
|     (1)  A small set of author names, with affiliations, may appear on
|          the front page header.  These should be the lead author(s)
|          who are most responsible for the actual text.  When there are
|          many contributors, the best choice will be to list the person
|          or (few) persons who acted as document editor(s) (e.g.,"Tom
|          Smith, Editor").
|
|          There is no rigid limit on the size of this set, but there is
|          likely to be a discussion if the set exceeds five authors, in
|          which case the right answer is probably to list one editor.
|
|          The RFC Editor will hold all the people listed on the front
|          page equally responsible for the final form and content of
|          the published RFC.  In particular, the "Author's 48 Hours"
|          final approval period will require signoff from all listed
|          authors.
|
|     (2)  An RFC may include a Contributors section, listing those
|          contributors who deserve significant credit for the document
|          contents.  The Contributors section is intended to provide a
|          level of recognition greater than an acknowledgment and
|          nearly equal to listing on the front page.  The choice of
|          either, both, or none of Contributor and Acknowledgment
|          sections in a particular RFC depends upon the circumstance.
|
|     (3)  The body of an RFC may include an Acknowledgements section,
|          in addition to or instead of a Contributors section.  An
|          Acknowledgments section may be lengthy, and it may explain
|          scope and nature of contributions.  It may also specify
|          affiliations.
|
|          [...]


Barry,
I assume that in item 3 below you intended to refer to the
"Acknowledgements" or "Contributors" section as described above.


All versions of both the rfc2141bis and the rfc3406bis I-Ds
contained explicit verbiage to acknowledge previous authors and
contributors, in accordance with these instructions.

The primary target should be a smooth process when during IESG
review and RFC Editor AUTH48 stage authors are required to be
responsive.  After the discussion on the list around IETF in Paris,
I've considered adding Leslie Daigle to the authors list of the
3406bis I-D, hoping for her to agree to participate in the process
-- just as you say in item 3 below.

I have observed working groups with strict policy that only actual
"working" authors can be listed on the front page of their documents;
OTOH, in some cases I have seen documents stuck for years since
it had been decided to keep authors of previous work on the authors
list while they did not interact with the process.
I also recall a case where an I-D has been stuck in AUTH48 for more
than a year because an author was irresponsive, and the IESG or the
responsible AD were very hesitant to declare an overriding exception.

The individual drafts for rfc2141bis, rfc3187bis and rfc3188bis
were in extended existence before the installation of the WG,
and these have been adopted as a WG draft by the WG charter.
Therefore, the present WG drafts all have simply followed the same
author list policy as these I-Ds.
If the WG now prefers to list previous authors in a "Contributors"
section, then of course I have no problem with accommodating that
in the upcoming next draft revisions.

Kind regards,
  Alfred.




Barry Leiba wrote:

[[ PSA said: ]]
>> I have mentioned this in the past, and I'll mention it again: I
>> think the new bis specs need to include the authors of the original
>> documents, with the new authors shown as editors. So, for instance,
>> draft-ietf-urnbis-2141bis would have the following in the header:
>>
>> A. Hoenes, Ed.
>> R. Moats
>>
>> Simply ripping the old authors out of the specs is disrespectful.
>
> Well, yes and no -- it's not that simple.
>
> First, I agree that the complete removal of the name of someone who
> contributed substantially to a document in any phase of its life
> (including a prior edition) would, indeed, be disrespectful... and
> unethical.
>
> But:
>
> 1. 2141bis (for example) is a product of the urnbis working group, and
> the chairs have complete control over who is listed at the top of the
> document.  They can remove someone's name for any defensible reason
> (subject, of course, to appeal), including that the person is no
> longer participating in the document's development.
>
> 2. Everyone who appears at the top of the document has to be reachable
> and responsive during AUTH48.  An AD can override that, but we prefer
> to avoid that and to list only those who we *do* expect to handle the
> AUTH48 process promptly.
>
> 3. An "Authors" section can and should be added to recognize the
> contributions of those who are or were authors of some version of the
> document, but who are no longer listed at the top.  This is where we
> can give due respect to a former author who is no longer active.
>
> Of course, as Juha says, it would be reasonable to ask the authors of
> prior versions how they would like to be recognized (and, I'll add,
> whether they will be available to review the final version and sign
> off during AUTH48).  That can certainly be input to the chairs'
> decision.  And anyway, if contacting a former author might bring more
> experienced eyes on the document and get more reviews and input,
> that's a good thing.  If we specifically think a former author will
> disapprove of where we've gone, that is NOT a reason to exclude him...
> in fact, it's that much more of a reason to get the input for
> consideration.
>
> Also, in this case, we have the odd situation that one of the chairs
> is far more active as a document editor than is usual, leaving it
> solely to the other chair to make these decisions.
>
> Barry
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn