Subject: RE: Allocating RFC numbers at time of approval

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 20 Sep 2005 16:10:14 +0200

Inline

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]]
> Sent: Tuesday, September 20, 2005 14:51
> To: Wijnen, Bert (Bert)
> Cc: Geoff Huston; [email-masked]; [email-masked]
> Subject: Re: Allocating RFC numbers at time of approval
> 
> 
> Wijnen, Bert (Bert) wrote:
> 
> >W.r.t.
> >  
> >
> >>3 - there is no way for the editor to 'spit it back' as being 
> >>    not ready for publication as it is awaiting some other
> >>    event that is beyond the rfc editor's control.
> >>    i.e. the queue is actually two queues - documents
> >>    that are awaiting processing, and documents that have
> >>    failed some step in the publication process and are now
> >>    awaiting some external action beyond the Editor's control.
> >>
> >>    
> >>
> >
> >For example, if a document has normative references to another I-D
> >that has not yet passed the IESG and so is not yet in the RFC-Ed queue.
> >
> >Would WGs be OK with a rule that would say that an I-D can 
> >only be IETF Last Called if all the normative references (to I-Ds)
> >are also being IETF Last Called at the same time?
> >  
> >
> I don't like this proposed change at all - it is better WG 
> last call the document while it is fresh in
> eveyone's mind. Also, it's hard enough to move these 
> documents forward with out adding the
> additional constraint that they have to be progressed in lock step.
> 

Well... but the other problem is that when the rfc-to-be finally gets 
into AUTH48 (after some normative ref finally shows up, we've
seen cases where that is more than a year later), then the authors
may not be present anymore to review the AUTH48... and so we
have ended up with docs in multiple-months of AUTH48 state.

You can't win them all you know.

> >It would put the burdon with the WG/authors to ensure and pressure
> >others (WGs, individuals) that the other documents actually DO get
> >worked on and DO move forward.
> >
> >Just wondering. I just see too often that a doc (I-D) gets approved
> >by IESG with a normative ref to some other I-D that than 
> >easily expires and never gets moving again.
> >  
> >
> At some point, the diliquent normative reference must be dealt with. 
> That is independent of
> whether or not the referring document has been WG last called.
> 

And if that is a year and umpty revisions of the normative doc later,
then who guarantees that the referenced doc is still in sync with
the one that makes the reference?

Bert
> >Bert

---

From: Acee Lindem <[email-masked]>
Date: Tue, 20 Sep 2005 10:19:41 -0400

Inline.

>have ended up with docs in multiple-months of AUTH48 state.
The tracker seems to keep them in the RFC editor's queue rather than 
AUTH48 hours
state. This is still preferable.  I still think trying to assure that 
all documents that reference
one another go forward is a bad, bad, bad idea.

>the one that makes the reference?
I guess hypothetically documents could get out of sync and contradict 
one another - can you
cite an example?

Acee

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Sep 2005 16:37:56 +0200

I just want to underline a point Bert is making.

When a WG is developing a set of linked drafts,
sending them for IESG review as a package is (when it's
possible) a Good Thing. It allows everybody who reviews
them to do so as a package, it allows issues to be resolved
as a package, and it minimizes reference dependencies
blocking the RFC Editor. And it may even allow them to have
consecutive RFC numbers.

     Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 22 Sep 2005 16:12:15 +0200

> You can't win them all you know.

AUTH48 is another kind-of-silly-state.
At the moment, I understand that the RFC Editor will not let a document 
through until all the authors have signed off.

I think this process would go faster if we could "kick the approval up" - 
by making a process decision that when the author has not replied in 48 
hours, the WG chair and/or the AD can say "This document is good enough" 
without waiting for the author any more.

Coupled with a tool (another tool!) that allows the WG chair and the AD to 
see exactly *which* authors haven't given their approval (or request for 
change) yet, I think we can avoid the "months-long 48-hours" silly state.

                 Harald

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Sep 2005 12:37:09 -0700

At this point, neither "AUTH" nor "48" are true, and that is a good thing.

The step could instead be called "checking for errors introduced by 
the RFC Editor", and that can be done by many people. It should be 
done by all the authors who care about the draft. It should be done 
by WG chairs for WG-initiated RFCs. It could be done by concerned ADs 
in their copious free time. There is no reason for it not to be done 
by concerned IETFers who are good at catching grammatical and 
formatting errors.

If some of the document authors cannot respond within a reasonable 
amount of time (two weeks seems reasonable), the RFC Editor can 
choose others not within the RFC Editor group they think are good at 
"checking for errors introduced by the RFC Editor".

Note that this all falls apart in the case which is now becoming 
common where authors add changes during what is supposed to be a 
cycle of "checking for errors introduced by the RFC Editor". This 
part of the process, which is completely hidden from the WG and the 
IETF in general, needs to be fixed.

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Duerst <[email-masked]>
Date: Sun, 25 Sep 2005 21:41:12 +0900

>At this point, neither "AUTH" nor "48" are true, and that is a good thing.

Yes indeed.

 >The step could instead be called "checking for errors introduced by the 
RFC Editor",

Very much so. In my recent experience, that was the main thing
I had to do. Here is a list of the types of stuff I got:

- Edits where I was one way or another being able to see the intention,
   but which where totally botched in execution (e.g. trying to replace
   one word with another, but in the end not deleting the word that
   was there).

- Edits that were well intended but didn't work because the meaning
   got changed.

- Edits that tried to change something throughout the document in
   a consistent way, but missed numerous cases.

- Slight stylistic changes of wording. Mostly 'six or half a dozen'
   in my view. Having a list of 'to avoid' and 'preferred' beforehand
   would have reduced work on both sides.

- A fair percentage of cases where my instructions for fixing
   (done in the form that the RFC editor says they want it in) weren't
   executed correctly and had to be re-corrected.

Overall, my impression of what the RFC Editor was doing was
"less would be more". I'd of course be glad to hear if your
milage differs.

 >and that can be done by many people.

Yes. Actually, it should be done by at least two.
Four eyes just see more than two,..., especially for this kind of work.

 >It should be done by all the authors who care about the draft. It should 
be done by WG chairs for WG-initiated RFCs. It could be done by concerned 
ADs in their copious free time. There is no reason for it not to be done by 
concerned IETFers who are good at catching grammatical and formatting errors.

 >If some of the document authors cannot respond within a reasonable amount 
of time (two weeks seems reasonable), the RFC Editor can choose others not 
within the RFC Editor group they think are good at "checking for errors 
introduced by the RFC Editor".

I don't think it should be the RFC Editor who does that, better WG chairs
or ADs or so. (finding/assigning people is what WG chairs and ADs are
(supposed to be) good at, and they are closer to the subject area
and know the right people).

Also, I think that every effort should be made to get the authors.
With every document I have been involved in, although a lot of people
have (ideally) read the document (sooner or later), and a lot of
people have contributed text, and so on, it's really only the authors
who pretty much know why each word of the document is the way it is.
There may be edits that may look harmless to everybody else except
the author (and with multiple authors, that often just applies to
the main, acting, author).

 >Note that this all falls apart in the case which is now becoming common 
where authors add changes during what is supposed to be a cycle of 
"checking for errors introduced by the RFC Editor". This part of the 
process, which is completely hidden from the WG and the IETF in general, 
needs to be fixed.

My guess is that quite a bit of that would get fixed if the turnaround
at the RFC Editor were faster. First, less 'fixes' would accumulate, and
Second, it would be easier to tell those trying to introduce these kinds
of changes to go back to the IESG or the AD or whoever.

Regards,    Martin.

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 25 Sep 2005 15:45:04 +0200

My 2 cents:

>    one word with another, but in the end not deleting the word that

Have not seen so much of this.

Yes indeed.

>    a consistent way, but missed numerous cases.

Yup, that too.

>    would have reduced work on both sides.

A bit of this.

>    executed correctly and had to be re-corrected.

Way too much of this :-(

This one, which could be *so* easily automated, is to my mind the least
forgivable.  Why waste their time and my time with manually finding (or
failing to find) the changes in a replacement text, manually inserting
it, and failing to get it right, when a tool could do it consistently
correctly and leave time and brainpower to review text???

> "less would be more". I'd of course be glad to hear if your

I think the RFC Editor editing is needed, a little of it in some cases
and more in others.  I understand that they are now training new people,
who will of course not be perfect in the beginning.  To simply dispense
with the RFC Editor language review would probably be too little.

But there are some things that could be improved.

	Henrik

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Sep 2005 12:43:58 +0200

I think the real answer here is to move to an "egoless RFC"
model for RFCs that are full IETF Contributions - i.e.
deem that they belong to the IETF, not to the authors.
Then this problem can indeed be resolved by a timeout.

This can be done for any RFC where the "derivative works"
copyright applies, I think.

     Brian

Harald Tveit Alvestrand wrote:
> I think this process would go faster if we could "kick the approval up" 
> - by making a process decision that when the author has not replied in 
> 48 hours, the WG chair and/or the AD can say "This document is good 
> enough" without waiting for the author any more.
> 
> Coupled with a tool (another tool!) that allows the WG chair and the AD 
> to see exactly *which* authors haven't given their approval (or request 
> for change) yet, I think we can avoid the "months-long 48-hours" silly 
> state.
> 
>                 Harald
> 
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Sep 2005 11:59:49 +0100

>> At the moment, I understand that the RFC Editor will not let a 
>> document through until all the authors have signed off.
>>
>> I think this process would go faster if we could "kick the approval 
>> up" - by making a process decision that when the author has not 
>> replied in 48 hours, the WG chair and/or the AD can say "This document 
>> is good enough" without waiting for the author any more.
>>
>> Coupled with a tool (another tool!) that allows the WG chair and the 
>> AD to see exactly *which* authors haven't given their approval (or 
>> request for change) yet, I think we can avoid the "months-long 
>> 48-hours" silly state.

Whilst I think that we need to do something about "48hrs that last months"
48hrs is to short a timeout to invoke the default. There are just
too many work and personal things that take an author off line for
a couple of weeks let alone 48 hrs.

A more reasonable time would be to hand over to the AD/Chair after say
four weeks - i.e. a summer vacation plus some time to clear the mail backlog,
plus some time to do the review.

- Stewart

---

From: Fred Baker <[email-masked]>
Date: Mon, 26 Sep 2005 16:37:10 +0200

agreed. I think this requires some sort of permission to so transfer  
the document, but such permission can be made a condition of making  
the document a WG document (regardless of status), which I should  
think is the class of documents you're talking about.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Sep 2005 08:47:50 +0300

>> Then this problem can indeed be resolved by a timeout.
I think one of the good things of the IETF process is that
we actually do have some level of "personal ownership"
in our documents, including designated editors/authors.
This tends to ensure people care more about the
content and quality of their documents, imho.

But I think you meant that the WG (or some entity other than
the editors) has overriding say in the document content, even
at AUTH48. Yes, I think this should be case. In fact,
I'm a bit surprised its not so already.

Just a few data points from my perspective. I've
seen a number of troubled AUTH48s. In one case
one of the authors declared that he longer likes
the document and did not want to be an author.
After some consideration it was decided that his
name would be dropped from the author list
(he did not want to pursue the issues on the WG
either), and no significant delay was introduced.

In other cases one of the authors have started an
argument, in some cases opposing the other
authors and the WG. In the IETF we aren't always
good at dealing with controversy (perhaps we try
too hard to get absolute consensus, even if its
just a question of one person vs. others). This
resulted in a lot of delay and discussion.

In yet another case a very detailed review
caused the document to change too much while it
was in RFC Editor queue. The document had to
be pulled out and re-WGLCed and re-approved
at IESG. A lot of delay.

Finally, in some cases we've truly learned new
things - deployment experience, new attacks
from the security community, etc, and are left
wondering what we should do at AUTH48.

There are a few root causes in these situations.
One issue is that the chairs need to be very, very
strict in dealing with new input during RFC editor
queuing, or with author's opinions during AUTH48.
(I know I have learned my lesson now!)

The second root cause is the long queue times.
World moves on. We learn new things. People change
opinions. Pressure builds to change documents.
But most of the time the right answer would be to
publish as-is and create new documents if necessary.
AUTH48 is not your change to do a "bis" version of the
spec!

The right action for the second root cause would
be to reduce the queing times. Actually,
I'm not quite sure why the RFC Editor
queue times are so long. I see a lot of value in
the editing performed by the RFC Editor in some
cases, but I see also a lot of drafts where the
added value is small. Someone suggested that we
could create two queues, one for WG documents that
already have "OK" english and that exist as XML;
the only things that you'd have to do for these
is to run an RFC Editor version of the xml2rfc tool
and fill in IANA values. The other queue would
be for documents that actually do need copy
editing.

--Jari

P.S. I see that in this thread people have reported
many RFC-editor introduced problems. I haven't actually
noticed too many, but maybe that's because my native
language is not English...

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 27 Sep 2005 09:35:24 -0400

Brian,

IMO there are no humans without ego.  By giving a constructive, 
condoned way for authors to take pride in their work, we can funnel 
that ego productively.  If we remove this outlet, the ego will still be 
there and will show up in much less benign ways.  I also feel that the 
authorship/editorship on documents encourages most to take more care in 
their documents.

thanks,
-rohan

On Sep 26, 2005, at 6:43, Brian E Carpenter wrote:
>> replied in 48 hours, the WG chair and/or the AD can say "This 
>> document is good enough" without waiting for the author any more.

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 27 Sep 2005 10:47:47 -0400

Hi,

The discussion of RFC# allocation is drifting way off-topic, so I've
changed the subject line.  

Not to be negative, but I've seen "authors" contribute very little to
the documents with their names on them; all some care about is getting
their names on the documents for ego reasons or for corporate
marketing reasons, not the quality of the work. Some simply make a
commitment of time and effort they cannot honor, but their name is
never removed from the document.

Now, when I'm primary editor or chair, I try to establish conditions
up front for front-page author/editor credit: 
1) Names don't get put on the documents until *after* the person has
contributed substantial useable text for the document. 
2) "Authors" must contribute ~20+% of the (non-boilerplate) text in
the final document (which limits the list of authors to five or less).

3) All front-page Editors must be very involved in the integration
work being done plus the shepherding of the document. 
40 Most acknowledgements require specific contributions or detailed
reviews. 

Typically, if you've contributed 20+% of the text, you will care about
the quality of the document, and should get credit for your work.

David Harrington
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rohan Mahy
> Sent: Tuesday, September 27, 2005 9:35 AM
> To: Brian E Carpenter
> Cc: [email-masked]; Wijnen, Bert (Bert)
> Subject: Re: AUTH48 (RE: Allocating RFC numbers at time of approval)
> 
> Brian,
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Sep 2005 17:10:23 +0200

Hi,

> never removed from the document.

this problem should be worked out between the active author(s) or  
contributor(s) and the WG chairs. It may create some tension (nobody  
likes to be bumped off the authors list), but usually inactive  
authors agree when approached nicely.

> 40 Most acknowledgements require specific contributions or detailed

These are mostly good guidelines; I tend to use similar ones.

> the quality of the document, and should get credit for your work.

Lars
--
Lars Eggert                                     NEC Network Laboratories

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 Sep 2005 11:05:00 -0700 (PDT)

> the quality of the document, and should get credit for your work.

It's also more likely that an author meeting these criteria will respond 
in a timely way to AUTH48 requests.  We have seen cases where "Ghost" 
authors either do not respond in a timely way to these requests, or not 
having kept up with the evolution of the document, reread it and submit 
substantial change requests, forcing the document to go back to the WG.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Sep 2005 14:22:46 -0400

What does one do about the case where a 'bis' edition is being produced 
and the original authors have nothing to do with it?  Leave the original 
authors or put new ones?

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 27 Sep 2005 14:27:20 -0400

I recommend putting them into the acknowledgements section.

dbh 

> From: Tom-PT Taylor [mailto:[email-masked]] 
> Sent: Tuesday, September 27, 2005 2:23 PM
> To: Bernard Aboba
> Cc: David B Harrington; [email-masked]
> Subject: Re: Egoless documents
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Sep 2005 23:50:16 +0300

Tom-PT Taylor wrote:

> What does one do about the case where a 'bis' edition is being 
> produced and the original authors have nothing to do with it?  Leave 
> the original authors or put new ones?

Depends on case. Did bis version change 1% or 80%?
Was it a major invention that you now maintain for
clearer language? Or are you adding a lot of new functions?
Maybe also depends on the number of authors. Are
the authors still interested and reachable?

Most of the documents that I have seen retain the original
author list.

--Jari

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Tue, 27 Sep 2005 14:01:26 -0700 (PDT)

In the ldapbis WG the authors/editors of the revisions are listed as such, 
and the authors/editors of the prior versions are listed in 
acknowledgements.

If you followed the previously suggested "at least 20%" rule for 
authorship, I suppose in the case of "bis" version it would be "20% of the 
changes" rather than 20% of the total text.  I can't see that it makes any 
sense to list someone as an author of a "bis" document if they are not 
actively involved with the revision, regardless of whether they were an 
author of the prior version.

  - RL "Bob"

On Tue, 27 Sep 2005, Jari Arkko wrote:

> Tom-PT Taylor wrote:
>
>> What does one do about the case where a 'bis' edition is being produced and 
>> the original authors have nothing to do with it?  Leave the original 
>> authors or put new ones?
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Sep 2005 19:04:42 +0200

> changed the subject line.  

Thanks.

> never removed from the document.

True, although Rohan is correct that authorship is a source of
motivation. I wouldn't take away authorship from serious contributors.
But an absentee author mustn't become a blocking factor for editing
and publication.

     Brian
>>>>>Well... but the other problem is that when the rfc-to-be 
>>
>>finally gets
>>
>>>>>seen cases where that is more than a year later), then the
> 
> authors
> 
>>>>I think this process would go faster if we could "kick the 
>>
>>approval 
>>
>>>>Coupled with a tool (another tool!) that allows the WG 
>>
>>chair and the 
>>
>>>>AD to see exactly *which* authors haven't given their approval
> 
> (or 
>

---

From: Martin Duerst <[email-masked]>
Date: Wed, 28 Sep 2005 18:48:25 +0900

At 06:01 05/09/28, RL 'Bob' Morgan wrote:
 >
 >In the ldapbis WG the authors/editors of the revisions are listed as 
such, and the authors/editors of the prior versions are listed in 
acknowledgements.

I guess I disagree with the above, and agree with Jari:
If the overall changes for the bis document are 10%, there
could be five new authors with 2% actual contribution each,
and it would be very unfair to kick out the original authors
(e.g. two with 50% each, of which 45% each are remaining).

It also depends on whether the original authors mainly
served as editors for the WG or whether the ideas came
from them. Even if the number of lines written is the same,
the amount of contribution is different. Occasionally, there
is also the case that original authors don't want to be
associated with the document anymore, for a variety of
reasons. Also, a lot of revisions get done without a WG.

Regards,   Martin.

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 29 Sep 2005 07:55:03 -0700 (PDT)

I suppose that our thinking in ldapbis was influenced by the history of 
LDAP and X.500, where many versions of these technologies have been 
produced over the years, so we have an understanding that the current docs 
are just the latest in a long series that have been contributed to by 
countless people (and of course the ITU docs don't list individual 
authors, which I suppose is a better definition of "egoless").  Plus these 
are WG products, so have been contributed to by many people.  So it's 
natural to list as authors/editors only those who actually prepared the 
current doc for publication, and acknowledge as many of the others as 
possible in the text.

That said, the notion that it is "unfair to kick out the original authors" 
seems profoundly misguided to me.  The question of whether authors of a 
prior version should be involved in producing a revision is like any other 
question of who produces IETF material, and is based on the interests and 
energy and output quality of those authors and any prospective new 
authors, needs of the WG (or community), etc.  Sometimes this involves 
"kicking out", but this is a question that is settled by the time the 
document is published.

Surely it has to be the case that the only people listed as 
authors/editors of a document are those who actively contributed to its 
production.  If I write doc X, and you incorporate some or all of it into 
doc Y, and don't involve me in the production of doc Y, and list me as an 
author of doc Y, then I can't come to any other conclusion than that you 
are misreprenting the work (aka "lying").  Just as in the real world, I 
might write a commentary on some work, and quote large parts of it, 
perhaps even the majority of the eventual text; but the author of the 
commentary is me, not the author of the original work.  Or, if I edit a 
work with chapters provided by many authors, I am the editor of the 
complete work, even though my contribution to its overall text may be 
minimal.

  - RL "Bob"

On Wed, 28 Sep 2005, Martin Duerst wrote:

> and the authors/editors of the prior versions are listed in acknowledgements.
>>
>> If you followed the previously suggested "at least 20%" rule for authorship, 
> I suppose in the case of "bis" version it would be "20% of the changes" 
> rather than 20% of the total text.  I can't see that it makes any sense to 
> list someone as an author of a "bis" document if they are not actively 
> involved with the revision, regardless of whether they were an author of the 
> prior version.
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 29 Sep 2005 11:23:02 -0400

I have a couple of interesting examples with which I have been 
personally associated.  One is the rewrite of RFC 2833.  One of the 
original authors is reachable, but I have never heard a word from him in 
the years I've been working on this document.  On the other hand, he 
invested enormous energy in persuading the industry to take the 
direction of encoding DTMF tones in a new payload type and leaving them 
in the media stream rather than sending them via the signalling path. 
It was very controversial at the time.  I feel it would be a historical 
crime to remove his name from the front page.

The other case is the second version of the Megaco protocol, more 
properly known these days as H.248.1.  This was originally jointly 
developed by the ITU-T and the IETF.  However, the ITU-T owns the 
standard now, and has taken it to its second and (and lately third) 
version.  Some of the changes have come about as a result of discussion 
on the Megaco list, but many bypassed the IETF completely. 
Nevertheless, the ITU-T would like to see the new version published as 
an RFC.

My work as "Editor" consisted in transcribing from MS Word to IETF ASCII 
and tacking on a lengthy analysis of changes from version 1.  It's hard 
to know whether the front page credit should go to the ITU-T editor, the 
ITU-T Rapporteur, or remain with the people who made the original 
contributions.  I did write a very lengthy Acknowledgements section 
giving the history of the protocol.

RL 'Bob' Morgan wrote:
> produced over the years, so we have an understanding that the current 
> docs are just the latest in a long series that have been contributed to 
> by countless people (and of course the ITU docs don't list individual 
> authors, which I suppose is a better definition of "egoless").  Plus 
> these are WG products, so have been contributed to by many people.  So 
> it's natural to list as authors/editors only those who actually prepared 
> the current doc for publication, and acknowledge as many of the others 
> as possible in the text.
> 
> That said, the notion that it is "unfair to kick out the original 
> authors" seems profoundly misguided to me.  The question of whether 
> authors of a prior version should be involved in producing a revision is 
> like any other question of who produces IETF material, and is based on 
> the interests and energy and output quality of those authors and any 
> prospective new authors, needs of the WG (or community), etc.  Sometimes 
> this involves "kicking out", but this is a question that is settled by 
> the time the document is published.
> 
> production.  If I write doc X, and you incorporate some or all of it 
> into doc Y, and don't involve me in the production of doc Y, and list me 
> as an author of doc Y, then I can't come to any other conclusion than 
> that you are misreprenting the work (aka "lying").  Just as in the real 
> world, I might write a commentary on some work, and quote large parts of 
> it, perhaps even the majority of the eventual text; but the author of 
> the commentary is me, not the author of the original work.  Or, if I 
> edit a work with chapters provided by many authors, I am the editor of 
> the complete work, even though my contribution to its overall text may 
> be minimal.
> 
>  - RL "Bob"
> 
...

---

From: Martin Duerst <[email-masked]>
Date: Fri, 30 Sep 2005 15:46:15 +0900

LDAP and X.500, where many versions of these technologies have been 
produced over the years, so we have an understanding that the current docs 
are just the latest in a long series that have been contributed to by 
countless people (and of course the ITU docs don't list individual authors, 
which I suppose is a better definition of "egoless").

It definitely is a better definition. The ISO also does it that way.
There are some advantages to that, but overall, I don't like it,
because it tries to give the impression of absoluteness and total
neutrality which never actually is true. The Japanese ISO equivalent
has an interesting solution, in that they list the WG members involved
in an appendix. That appendix also contains background information to
the standard, e.g. explanations of why some solutions were preferred to
some others, and so on. Extremely useful (if you can read it).
Overall, I prefer when standards have faces.

 >Plus these are WG products, so have been contributed to by many people. 
So it's natural to list as authors/editors only those who actually prepared 
the current doc for publication, and acknowledge as many of the others as 
possible in the text.

I agree that each technology and WG has its history and context,
and that this influences a lot of what's going on.

 >That said, the notion that it is "unfair to kick out the original 
authors" seems profoundly misguided to me.

In some cases, it may be misguided, in some cases, it may be very
clearly unfair.

 >The question of whether authors of a prior version should be involved in 
producing a revision is like any other question of who produces IETF 
material, and is based on the interests and energy and output quality of 
those authors and any prospective new authors, needs of the WG (or 
community), etc.  Sometimes this involves "kicking out", but this is a 
question that is settled by the time the document is published.

Agreed.

production.

In principle, I agree. But 'actively contributed to its production'
may involve many things.

 >If I write doc X, and you incorporate some or all of it into doc Y, and 
don't involve me in the production of doc Y, and list me as an author of 
doc Y, then I can't come to any other conclusion than that you are 
misreprenting the work (aka "lying").

If you get listed wihout being asked, then that's a problem, but
lying isn't the main problem in that case. On the other hand, if
you don't get listed, but somebody is literally ripping off your
work and putting on his/her own name, in many cases that's considered
stealing. Of course in the IETF the authors/editors transfer their
copyright, so legally it's not a problem, but that's not the only
issue. If the new editor doesn't at least make a reasonable attempt
to contact you, and offer you to be an author of the revision even
if your contribution to the revision itself is minimal (the revision
itself may be minimal in the first place), I think that's bad practice.

 >Just as in the real world, I might write a commentary on some work, and 
quote large parts of it, perhaps even the majority of the eventual text; 
but the author of the commentary is me, not the author of the original work.

Well, if you cite the majority of the original work, then it's probably
no longer 'fair use' under copyright. Also, if you commentary is smaller
than what you cite, you should probably make a better effort to provide
something real. And please note that what we are speaking about in
general in this thread is updated versions of documents, which is
aking to a second edition of a book, and not critical work commenting
on an existing document.

 >Or, if I edit a work with chapters provided by many authors, I am the 
editor of the complete work, even though my contribution to its overall 
text may be minimal.

Yes. But if your work consists just of updating a few things and
fixing a few errors, you are more like a copy editor. These don't
get listed as authors/editors usually.

Again, of course, it all depends on the situation and the circumstances.

Regards,    Martin.