[Cc to ietf@ as the question is pertinent to other working groups too]
At 06:47 04-07-2012, Barry Leiba wrote:
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
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.
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.
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.
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.
You may have meant "Contributors" here. There are RFC Editor
guidelines about that ( http://www.rfc-editor.org/policy.html ).
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
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.