Subject: Re: IESG Statement on surprised authors

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 1 Jun 2015 23:18:21 +0000

Hi John,

I had thought about the added time it would take to post a draft, which
could be nerve wracking when posting at the deadline, but I figured this
is the price we "pay" for added security (like taking our shoes off for
airport security).  If you can't get your authors to approve in time, you
can always post with less authors and update it again after the meeting
submission lockout expires.

As for posting with fake email addresses, having a submitter do this shows
an even more blatant attempt at fraud and I would submit a harsher
"penalty"
should be applied for this behavior.  However, you are correct that the
tool would not be foolproof and you would still need a procedure for fraud
investigation and handling.

You are right that authors are notified when a new draft is posted, but
unfortunately it is after the fact with little recourse for winding back
the clock, especially for those who filter their IETF email into a folder
for catching up on much later.

 - Larry

On 5/31/15 10:04 AM, "John Levine" <[email-masked]> wrote:

>>Isn't one way to deal with this to build additional mechanisms into the
>>draft submittal confirmation procedure?
>
>When I suggested this a couple of weeks ago, people pointed out that
>there are too many ways that the obvious approach, require all new
>draft authors to approve posting, has its problems.  It can interfere
>with legitimate drafts (on meeting cutoff day one author stays at the
>office to finish the draft, the others take off for the weekend) and
>it's trivial to circumvent (use plausible fake webmail addresses.)
>
>We do automatically notify authors when new drafts are posted, which
>should usually alert surprised authors to the problem.
>
>R's,
>John

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 1 Jun 2015 23:21:18 +0000

Hi Brian,

I agree that there will always be exceptions (we have them now), that will
need to be handled manually, but I don't think that is a reason not to try
to handle 80% of the cases.

On your question about withdrawal, no I don't see why other authors should
have any say in whether an author withdraws or not.  It this somehow
related
to the "right to be forgotten" law? :-)

 - Larry

On 5/31/15 1:03 PM, "Brian E Carpenter" <[email-masked]>
wrote:

>Larry,
>
>The tools could do pretty much whatever we want, if we know what we
>want, which is the tricky bit. But (as my draft points out) there
>will always be exceptions, so the tools have to allow for them too.
>
>Here's one that isn't even in my draft. Sometimes an author wants to
>withdraw. Does that need approval from the co-authors?
>
>Regards
>   Brian
>
>On 30/05/2015 10:07, Larry Kreeger (kreeger) wrote:
>> Hi Brian and Benoit,
>> 
>> If authors are added purposefully to a draft without their consent, it
>>is
>> indeed disturbing, but I hate to see IETF cycles spent dealing with
>> investigations if they can be avoided in an automated manner.
>> 
>> draft submittal confirmation procedure?  I believe that currently, only
>> one of the author's needs to approve submission/update.  If this were
>> changed to require all authors to confirm the original submission, then
>>it
>> would save people-hours investigating and dealing with this.  When
>> submitting an updated draft, only a single author would need to approve
>>if
>> the author list didn't change.  Of course, newly added authors would
>>need
>> to approve as well if the updated draft included a new author.
>> 
>> Thanks, Larry
>> 
>> On 5/29/15 1:55 PM, "IESG Secretary" <[email-masked]> wrote:
>> 
>>> IETF community,
>>>
>>> The IESG is planning to publish an IESG statement concerning the
>>> authorship of Internet drafts. This statement is only focused on the
>>> situation where an IETF participant feels he/she has been erroneously
>>> listed as an author on a draft. The statement can be seen here:
>>>
>>> http://trac.tools.ietf.org/group/iesg/trac/wiki/SurprisedAuthors
>>>
>>> We are seeking community feedback on this statement and welcome input
>>> that will help encourage proper behavior. Please provide any feedback
>>> by June 10, 2015 to either [email-masked] or the IESG directly at
>>> [email-masked].
>>>
>>> Regards,
>>> Brian and Benoit (on behalf of the IESG)
>>>
>> 
>>

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 1 Jun 2015 23:22:12 +0000

On 5/31/15 3:11 PM, "Ted Lemon" <[email-masked]> wrote:

>On May 31, 2015, at 1:04 PM, John Levine <[email-masked]> wrote:
>At this point the damage is already done: the surprised author now has to
>publicly accuse the other author(s) of surprising them, which is really
>burdensome and which said surprise author kit find completely unpalatable
>for any number of reasons. This is not a solution.

I agree with Ted on this. - Larry

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 1 Jun 2015 23:32:14 +0000

Hi John,

Please see my responses inline below.

 - Larry

On 5/31/15 8:51 AM, "John C Klensin" <[email-masked]> wrote:

>
>
>--On Friday, May 29, 2015 22:07 +0000 "Larry Kreeger (kreeger)"
><[email-masked]> wrote:
>
>> Hi Brian and Benoit,
>> 
>> If authors are added purposefully to a draft without their
>> consent, it is indeed disturbing, but I hate to see IETF
>> cycles spent dealing with investigations if they can be
>> avoided in an automated manner.
>> 
>> Isn't one way to deal with this to build additional mechanisms
>> into the draft submittal confirmation procedure?  I believe
>> that currently, only one of the author's needs to approve
>> submission/update.  If this were changed to require all
>> authors to confirm the original submission, then it would save
>> people-hours investigating and dealing with this.  When
>> submitting an updated draft, only a single author would need
>> to approve if the author list didn't change.  Of course, newly
>> added authors would need to approve as well if the updated
>> draft included a new author.
>
>Larry,
>
>In principle this is very attractive (and has been suggested
>before).  In practice, it illustrates how much trouble we get
>into when we start making very specific rules and then
>incorporating them into even more specific tools.  Consider, for
>example, a draft that is actually a revision of an existing RFC,
>changing a few details, perhaps adding a critical explanatory
>paragraph, but leaving virtually all of the original text (and
>perhaps all of an original protocol specification) intact.   Our
>existing guidelines, usual practices, and
>draft-carpenter-whats-an-author-01 all suggest leaving the
>original author as an author on the revised version.  After all,
>she is that one who, in the words of Brian's draft, made "a
>substantial creative contribution to the document", indeed may
>have written most of it.  But suppose that author has dropped
>out of the IETF and cannot be easily reached?

In case it wasn¹t clear, I was proposing that only original and
new authors would need to approve a submission.  So, an update
(whether large or small) that doesn't add to the author list
doesn't require any additional approvals.

>Suppose that
>author, if reached, had a significant objection to the changes,
>the idea of a revision [1], or the author of the new text?

If they really don't like it and which to withdraw themselves as
an author, I think that should be allowed with no additional
approvals except from the withdrawing author.

>I have an opinion about how situations like that should be
>handled, but it involves subjective elements, edge cases, etc.
>It won't work well with a tool.  Could your idea be made to work
>with a "manual posting by secretariat" exception?  Yes, but then
>we would have be punishing the people who are behaving well with
>delays at least and maybe creating the need for the Secretariat
>or IESG to do an investigation.

Yes, delays for additional approvals to be made are inevitable. I
suppose the judgement call comes down to. 1) How often is this
happening? 2) How bad is it to deal with when it does happen?
If it very rare, and the consequences to dealing with it are not
burdensome, then I agree, don't burden the submission/update tool
with additional approvals.  I have no idea how wide spread the
problem is.

>
>Perhaps that would be the best opinion anyway (these cases are
>not common although they may become more so as authors age), but
>my point is that this sort of problem is more complicated than
>one at which simplistic tools can be thrown without creating
>other problems.
>
>    john
>
>p.s. Brian, your draft really needs to address I-Ds that are
>revisions of existing RFCs even if all you say is "more
>complicated".
>
>
>[1] The IPR rules do not permit the authors of an RFC in the
>IETF Stream to block publication of an IETF Stream revision or
>update of that document.  The current discussion seems to
>suggest that they should be able to insist on having their names
>removed as authors, which is fine.  The question of whether, if
>they wrote most of the original (and retained) text, they can
>also insist on not being acknowledged seems to me to be fairly
>clear (and clearly "no") in the IPR rules although the issues
>such a request raises are examples of why I object to wading
>into the Acknowledgment swamp with a parenthetical note.   But,
>if their wishes cannot be reliably obtained... well, we better
>not have a restrictive rule or tool that assumes that reliably
>obtaining those wishes is easy and straightforward in all cases.
>

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 02 Jun 2015 16:12:50 +0100

On 2 Jun 2015, at 0:18, Larry Kreeger (kreeger) wrote:

> airport security).

I don't think that taking off your shoes at airport security does 
anything to improve airport security. But I do think it's a good analogy 
in this case, since it certainly adds inconvenience for no discernible 
purpose.

Joe

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 2 Jun 2015 13:39:35 -0700

Larry Kreeger wrote:

> >At this point the damage is already done: the surprised author now has
> >to publicly accuse the other author(s) of surprising them, which is
> >really burdensome and which said surprise author kit find completely
> >unpalatable for any number of reasons. This is not a solution.
> 

So to balance this, I will disagree, and point out that this exposes the
flaw in this entire thread. 
"Internet-Drafts are draft documents valid for a maximum of six months ..."
So  there is an opportunity for a surprise author to alert the IESG & RFC
editor. There is no reason to burden the I-D submission process with
verification. People have been added and removed from various I-D sets for
all kinds of reasons, and years later nobody is even aware it happened
unless they search an archive. 

While I agree with Brian's draft, the statement 
"It goes without saying that normally nobody should be listed as author,
contributor or editor against their will."
is clearly misworded since this entire thread and that document are about
SAYING exactly that. 

Tony

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jun 2015 17:42:10 -0400

On Jun 2, 2015, at 4:39 PM, Tony Hain <[email-masked]> wrote:
> editor.
Yes, there is a chance to publicly humiliate the submitter. I would not want to do that, so your proposed solution doesn't address my need.

---

From: "John Levine" <[email-masked]>
Date: 2 Jun 2015 21:57:47 -0000

>Yes, there is a chance to publicly humiliate the submitter. I would not want to do that, so your proposed solution doesn't address my need. 

Considering that most of these situations appear to be mistakes, why
should correcting this mistake be more humiliating than correcting the
zillions of other mistakes fixed from one version of an I-D to the
next?

R's,
John

PS: If it's not clear, this is a real question.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 2 Jun 2015 15:31:24 -0700

John Levine wrote:

> >> So  there is an opportunity for a surprise author to alert the IESG &
> >> RFC editor.
> >Yes, there is a chance to publicly humiliate the submitter. I would not want
> to do that, so your proposed solution doesn't address my need.
> 
> zillions of other mistakes fixed from one version of an I-D to the next?
> 
> R's,
> John
> 

The other real question is why this has to be public at all? So you name appears on -0n and not on -0n+1, the only people that need to know why are the "surprised" and the submitter. If the submitter refuses to take it off, alerting the IESG and RFC-editor (still not a public humiliation) should be enough. The only case where one might  consider "going public" is if an I-D is in last call and you still can't get the acknowledgment removed. If the IESG has decided against you already though, it is likely there is a reason you should not be dropped from the contributors list, so public complaining is likely to be more humiliating for the complainer. 

Tony

---

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Jun 2015 18:34:19 -0400

>>Yes, there is a chance to publicly humiliate the submitter. I would not want to do that, so your proposed solution doesn't address my need.

Why not?
There are many things that we do where we self police and train people
into more appropriate behavior by pointing out where they are being
anti-social. We try and do this privately, but if that doesn't work,
we often do it in a more public venue.
For example, I remember an instance where I was having a side
conversation in the middle of a working group meeting and you
(rightly) poked me and asked me to shut up or take it outside. If I
had continued to do this, I would have expected you to ask more loudly
and / or ask the chairs to request that I shut up.
There are many places where we act the way that we do simply because
of social convention, which is arrived at by communicating what is
appropriate and what isn't - for example, I walk the extra few steps
to throw away my chewing gum in the trash receptacle  instead of
simply sticking it on your laptop. If I were to smear it all over your
keyboard, I'd expect you to object -- and if I did it repeatedly I'd
expect you to object in a more and more public manner, until I learnt
what is, and what isn't appropriate.

If you are walking down the road an a pickpocket grabs your wallet and
runs off, would you feel uncomfortable shouting "Stop! Thief!!!"
because it may humiliate him?

> zillions of other mistakes fixed from one version of an I-D to the

Yup - if this is an accident / mistake then mentioning it publicly it
need not humiliate anyone[0] - and if it done maliciously then I think
it is perfectly appropriate to call it out publicly to get the
behavior changed. You could always email the authors privately first
and expect them to do the right thing - if I'd (mistakenly) added you
as an author to a draft I'm writing, I'd immediately release a new
version without you listed, and post a note to the list (and probably
put an editor's note at the top of the document) saying something like
"Sorry all. I'd mistakenly listed Ted as an author on version -xx of
this document. I'd thought he'd agreed to be an author and contribute
text, but it seems I misunderstood". If this was an honest mistake I
wouldn't be humiliated -- and if this sort of thing *did* make me feel
shame, I'd simply make very sure that everyone who I listed as an
author had agreed to be one.

When used maliciously this tactic only has any value because it
creates the perception of support - by removing this incentive the
tactic becomes valueless.

W
[0]: Especially if done with tact - coming out and saying "Bob is a
big doo-doo head. He added me to this without my permission and so is
scum" isn't. Mentioning that you don't remember having contributed to
this document or having agreed to author, and asking Bob to release a
new version without you listed should be fine. I've been on both sides
of this - I've added people who I thought had agreed to contribute
(and then discovered that they hadn't meant to give that impression),
and also been surprised to be added. In at least one case I've stood
at the mic and said "I think that's a great idea...", only to discover
that I was an author :-)[1]. In all cases it was settled peaceably,
and without drama - but if it had been done maliciously I would feel
no guilt calling people out on it.

[1]: Actually, in this particular case I had contributed significantly
to the document, it was just being discussed in a manner where I
didn't recognize which document it was...

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jun 2015 18:57:30 -0400

> zillions of other mistakes fixed from one version of an I-D to the

How can one possibly add an author accidentally?

---

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Jun 2015 19:25:10 -0400

> How can one possibly add an author accidentally?

I've done it -- I was chatting with someone -- let's call him Bob. We
were discussing something over dinner, and came up with a great
solution to a problem. We spent many hours discussing how to implement
it, etc.  I said "We should *so* write this up as a draft. What do you
think?". Bob says "Yes, that's a great idea". So, I go back to my
hotel room, open an editor, bang out the document and post it. Bob
says "Whoa! What the hell?". Apparently when I said "We should write
this..." he thought I was meaning the "royal we" (or, me and someone
else), when I was actually meaning "Warren and Bob". Anyway, after I
apologized to him and explained that it was a misunderstanding he
decided he really wanted to be an author, and ended up writing much of
the rest of the document.

Sure, I could /  should have sent him the -00 and asked if he
approved, but, well, I wanted to submit before the next set of
meetings, I was overly excited (we've met, yes? :-)), etc.

W

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 03 Jun 2015 10:52:53 +0100

> How can one possibly add an author accidentally?
Well there can be a cut and paste error in the document?

I am sure many drafts start life as the re-incarnation of
an earlier work, in which case such oversight is easy. Certainly
all my drafts are traceable to one I wrote many years ago.

Then there is the possibility of mistaken identity or memory
failure in trying to remember who was in the huddle
at IETF when it was agreed that a draft would be written.

- Stewart

---

From: Loa Andersson <[email-masked]>
Date: Wed, 03 Jun 2015 12:17:40 +0200

Stewart,

> at IETF when it was agreed that a draft would be written.

I can understand about the cut-n-past, but I don't understand why this
is not captured very early in the process, e.g. when first posting the
draft. At least some steps, e.g. posting the first version of the wg
draft sends mail to all authors, also changing state in the data
tracker do that.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "John Levine" <[email-masked]>
Date: 3 Jun 2015 15:21:45 -0000

>draft sends mail to all authors, also changing state in the data

As far as I know, it is.

It is evident from the discussion to date that while some of us find
it a problem to ask to be taken off a draft, others don't.  So here's
a proposed code sprint hack.

Add a new database table of surprise-averse authors.  Allow people to
register their addresses, with the usual confirmation click through
mail.  Now when an I-D is posted, if it has a surprise-averse author
listed and that author isn't on an earlier version of the same I-D,
that author has to confirm the draft before it's posted.  (If there
are also non-averse authors, they can confirm it too but there's no
point since it doesn't move forward until the averse authors do.)

This doesn't seem terribly hard, it doesn't require that anyone change
the way they work if they don't want to.  It doesn't solve the
possible problem of drafts with fake addresses, but nothing's going to
prevent that without totally changing our processes.

R's,
John

PS: I have about four addresses I use in IETF correspondence, only one
of which I use in I-D's, so I might list the other ones.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Jun 2015 12:26:30 -0400

> point since it doesn't move forward until the averse authors do.)

WFM!

---

From: Warren Kumari <[email-masked]>
Date: Wed, 03 Jun 2015 17:57:49 +0000

Yup. This seems like a really nice compromise -- folk who want to can opt
in to this system, and those who don't, well, don't.

<Warren tips hat to John>

I do not participate in the code sprint (busy NOCing at that time), but
otherwise I'd be willing to try add this... although you probably don't
want me anywhere near the codebase :-P

W

---

From: "John R Levine" <[email-masked]>
Date: 3 Jun 2015 14:01:07 -0400

> <Warren tips hat to John>

Gee, thanks.

> want me anywhere near the codebase :-P

I won't be going to Prague, too many I* meetings in too few months.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.