Subject: [urn] listed authors

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 Jul 2012 13:43:29 -0600

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.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: mike amundsen <[email-masked]>
Date: Tue, 3 Jul 2012 15:46:59 -0400

+1

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Tue, Jul 3, 2012 at 3:43 PM, Peter Saint-Andre <[email-masked]>wrote:

> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

---

From: SM <[email-masked]>
Date: Tue, 03 Jul 2012 13:37:36 -0700

Hi Peter,
>Simply ripping the old authors out of the specs is disrespectful.

I don't like not listing previous authors as they deserve credit for 
most of the work.  There is an acknowledgement in 
draft-ietf-urnbis-rfc2141bis-urn-02.  One of the questions which 
would have to be answered is how to get sign-off during AUTH48 (I am 
aware of the exception clause).

I suggest contacting the previous authors instead of adding their 
names.  There was an issue (unrelated to URN) when an author was 
listed without his approval.

Regards,
-sm

P.S. The unrelated question is about providing the motivation to get work done.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 04 Jul 2012 09:38:51 +0900

I agree.    Regards,   Martin.

---

From: Juha Hakala <[email-masked]>
Date: Wed, 04 Jul 2012 08:00:50 +0300

Hello

+1, except that "editor" gives a wrong idea of Alfred Hoenes' role, his 
contribution is more important than that. Much of what was there in 
RFC2141 has been deleted or significantly modifed, and the document has 
been extended a lot. I recommend

A. Hoenes
R. Moats

We must ask Ryan Moats if he still wants to be listed as an author.  He 
might not approve some of the new things that have been incorporated in 
the rfc2141bis.

I will contact Hartmut Walravens (the second author of rfc3187) and ask 
if he wants to be listed as one of the authors of rfc3187bis.

Best regards,

Juha

On 3.7.2012 22:46, mike amundsen wrote:
> On Tue, Jul 3, 2012 at 3:43 PM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678

---

From: Barry Leiba <[email-masked]>
Date: Wed, 4 Jul 2012 09:47:37 -0400

> 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

---

From: SM <[email-masked]>
Date: Wed, 04 Jul 2012 09:13:52 -0700

Hi Barry,

[Cc to ietf@ as the question is pertinent to other working groups too]

>Well, yes and no -- it's not that simple.

Agreed.

>(including a prior edition) would, indeed, be disrespectful... and

There was a message from Fred Baker on December 12, 2011 to ietf@ 
about a similar question:

  "Checking the acknowledgements, you'll see that I listed Warren and his
   professor as co-authors, although to be honest they at most made a few
   comments on the actual paper. Why? It is a variation on his original idea,
   and I'm giving him full credit for the idea. Tim and his student get
   mentioned as making a suggestion, because they did some work and it was a
   good suggestion. Others are listed as commenting, because they did."

We could diff a -bis document to determine whether the change is 
substantial or not.  That's more of a measure than an assessment of 
an idea.  Long-standing authors tend to "give credit where credit is 
due" whereas new authors tend to look at it in terms of lines of text provided.

>longer participating in the document's development.

There is a subtlety here.  The chairs have complete control on the 
selection of the document editor.  The document editor has editorial 
discretion.  I'll argue that the individual also has a say in keeping 
the name of the author of the previous version of the document.

>to avoid that and to list only those who we *do* expect to handle the

Yes.

>can give due respect to a former author who is no longer active.

You may have meant "Contributors" here.  There are RFC Editor 
guidelines about that ( http://www.rfc-editor.org/policy.html ).

>in fact, it's that much more of a reason to get the input for

The IETF has formal processes for listed authors due to IPR.  Given 
that I will not be provided any assistance when things go wrong, I 
prefer to follow the cautious path where I only add a person's name 
with their agreement.  There was a case where a listed author asked 
to have his name removed as author.  This may come as a surprise to 
some participants; some people prefer not to have their name attached 
to a bad idea as they consider that as more important than having a 
name on a RFC.

It's up to each and anyone to see whether it is worthwhile to make 
that good faith effort to contact the former author and have them 
involved in the work to update a specification.  It's better to do 
that early instead of having a "fait accompli" where the former 
author is not given much latitude to disapprove.

It is up to the author to assess whether getting more review and 
input is important.  Having a working group does not mean that the 
work will get adequate review.  Soliciting comments does not 
necessarily make it happen.  If everyone is listed as author, the 
question that comes to mind is who is going to review the work.

Regards,
-sm

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 4 Jul 2012 20:19:55 +0200 (MESZ)

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,

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 11 Jul 2012 21:17:58 -0400

Hi,

In the general case, indeed, there are many potential complexities.

In these particular cases, most of them don't apply.

The "new" documents are largely the same as the old ones:  they are not 
rewritten from the ground up.  Instead, they have been updated to 
reflect particular points this group is discussing as changes to the 
spec -- not all of which may be kept for this WG's final version of the 
document.

I, as one implicated author, and as chair of the original WG that 
produced these documents, would indeed find it very disrespectful to 
fail to acknowledge that properly in the updated documents.   And, I 
don't think it's reasonable to suggest that the IETF should support a WG 
rewriting that holus bolus as part of its process.

I think it's quite reasonable to list the current folks working on the 
documents as authors if they are authoring.

I think it's quite reasonable to see if the original authors are willing 
and able to continue to be listed (and responsive, eg during AUTH48) and 
responsible for document content.

I'm happy to help try to reach the various authors at current addresses. 
(Since they've already been asking _me_ about the outcome of this issue...).

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------