Subject: Re: IESG Statement on surprised authors

From: Toerless Eckert <[email-masked]>
Date: Fri, 29 May 2015 15:10:45 -0700

This is the same problem as with domain names:

When you want to highlight through a fake list of authors on a
draft widespread support for it, its really hard to come up
with an expert sounding randomn name that has not already been
taken up by some physically existing person that also happens
to work in the IETF. So you get unintended collisions and concerns.

This problem really needs to be solved through extensions of RFC6761.

Eg: "Strong the 3rd Supporter @ example.com" or the like.
"Rocky [email-masked]", etc. pp/.

Cheers
    Toerless

[C'mon, it's friday! A joke a month keeps the anger away.]

On Fri, May 29, 2015 at 01:55:51PM -0700, IESG Secretary 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: John C Klensin <[email-masked]>
Date: Fri, 29 May 2015 18:24:14 -0400

--On Friday, May 29, 2015 13:55 -0700 IESG Secretary
<[email-masked]> wrote:

> 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:
> 

Hi.

I hope this does not turn into a long discussion, but I believe
the parenthetical note about "surprised acknowledgment" either
needs to be removed (since this statement isn't really about it
and does not provide a remedy, default or otherwise) or
clarified.   Acknowledgments raise several issues that have
caused controversy in the past.  In summary, our IPR policies
are usually interpreted as requiring acknowledgment when someone
has made a significant Contribution to a document [1].  Those
policies are about Contributions, not about whether someone
agrees with all, part, or none of the resulting document.
Certainly an acknowledgment should not claim endorsement or
support for a document that the person involved does not
support, but the presumed requirement to acknowledge
Contributions may not allow a Contributor to opt out entirely
from being acknowledged.

My sense is that we have not been consistent about resolution of
cases in which people have objected to having their
Contributions acknowledged in a document that they do not
support.  If this statement is going to address the "surprised"
acknowledgment issue [2], it is going to be necessary to
establish policy in that area, policy that may require opening
and either clarifying our fundamental IPR policies and the RFC
Editor's interpretation of them or trying to produce a detailed
policy on acknowledgments [3].

best,
    john

[1] There have also been controversies associated with people
not being acknowledged who think they should be.  Those
controversies and associated questions do not appear to interact
with this proposed statement.

[2]  I believe that "surprised acknowledgments" are
indistinguishable in practice from "unwanted" ones.  With both
acknowledgments and authorship, if actual editors notify the
offended party in advance about what they are going to do and
that party objects, the same issues exist whether there is
actual surprise or not.

[3] Personally, I would discourage the latter in favor of
continued reliance on author discretion, discussion within WGs,
etc., and application of courtesy and good sense.   Trying to
formulate a specific policy would probably take us on a tour of
ratholes and special cases and end up satisfying no one and
leaving other cases unresolved.

---

From: Jari Arkko <[email-masked]>
Date: Sat, 30 May 2015 02:03:13 +0300

John,

> needs to be removed 

FWIW, after seeing your note I do agree that it could be misinterpreted.
I’m fine with removing it. But I make no claims about the preferences
of my fellow IESG members regarding such removal :-)

Jari

---

From: joel jaeggli <[email-masked]>
Date: Fri, 29 May 2015 16:25:28 -0700

Afaik from our discussion that led to this statement, and the recent
appeal on the subject, The contents of the acknowledges section is
largely at the discretion of the editors/authors.

I liked our words on the subject at the time.

Writing acknowledgments sections is largely a matter of editorial
discretion, where good sense and general attribution practices are the
primary guidelines, although RFC 2026 Section 10.3.1 has some specific
rules regarding acknowledgment of major contributors, copyright, and IPR.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 May 2015 12:02:48 +1200

I believe John is correct. Whether or not they are surprises,
involuntary acknowledgements may be highly desirable in some
circumstances.

But wait... there's a draft about this since three minutes ago:
https://tools.ietf.org/html/draft-carpenter-whats-an-author-01

Regards
   Brian

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 May 2015 20:44:27 -0400

Brian,

I think your draft is helpful and I think Joel's text, possibly
(eventually) with a pointer to that draft addresses the issue.
My only concern is that the introduction of a comment about
acknowledgments as a parenthetical note, without further
qualification, in the draft IETF statement could unnecessarily
open a can of worms.  I'm mostly indifferent to whether the
problem is fixed by adding more words to this statement or by
removing the text and treating the acknowledgments question as a
separate topic, discussed and documented elsewhere (or some
combination of the two).

    john

--On Saturday, May 30, 2015 12:02 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> Afaik from our discussion that led to this statement, and the
>> recent appeal on the subject, The contents of the
>> acknowledges section is largely at the discretion of the
>> editors/authors.
>> 
>> Writing acknowledgments sections is largely a matter of
>> editorial discretion, where good sense and general
>> attribution practices are the primary guidelines, although
>> RFC 2026 Section 10.3.1 has some specific rules regarding
>> acknowledgment of major contributors, copyright, and IPR.
>> 
>> 
>>>> I hope this does not turn into a long discussion, but I
>>>> believe the parenthetical note about "surprised
>>>> acknowledgment" either needs to be removed 
>>> 
>>> FWIW, after seeing your note I do agree that it could be
>>> misinterpreted. I'm fine with removing it. But I make no
>>> claims about the preferences of my fellow IESG members
>>> regarding such removal :-)
>>> 
>>> Jari
>>> 
>> 
>> 
>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 30 May 2015 08:48:51 +0200

I like this draft, but I suggest that it apply to ALL RFCs (not just the
IETF stream).

Eliot

---

From: Benoit Claise <[email-masked]>
Date: Sat, 30 May 2015 08:54:36 +0200

John,

One reason why a pointer to the surprised acknowledgment was added is 
for statements such as

    Thanks to <insert names> for their valuable comments and support on
    the initial idea of this document

Regards, Benoit
> .

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 30 May 2015 08:58:04 +0200

One could write this sentence in the introduction or any other place in the document.
This appears not to be about the acknowledgement section (which I would really like to keep clear of red tape), but about lying in documents.  That should, indeed, be frowned upon.

Grüße, Carsten

On 30 May 2015 at 08:54:57, Benoit Claise ([email-masked]) wrote:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 30 May 2015 01:59:32 -0500

Coherent text is hard ...

I believe the "surprised acknowledgments" phrase came up during a
discussion of a case where someone put up a "look how many people (from how
many companies, but that's another rathole) support our proposal", when
upon investigation, at least some of the folks didn't actually support the
proposal.

So, we weren't talking about acknowledgements in drafts at the time.

I'm happy to pull that phrase. So, at least a few members of the IESG
agrees with that suggestion.

Spencer

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 May 2015 05:03:33 -0400

--On Saturday, May 30, 2015 08:54 +0200 Benoit Claise
<[email-masked]> wrote:

> One reason why a pointer to the surprised acknowledgment was
> added is for statements such as
> 

Benoit,

Understood and I had guessed at that cause and intent.  The
difficulty is that we have at least four other cases, only one
of which I don't believe has actually occurred.  Yet.:

	(i) Joe Blow Contributes large blocks of text to a
	document.  The IPR rules, at least as some of us
	understand them, require that his Contribution be
	acknowledged.  Joe doesn't like some or all of the
	resulting document, which still includes his text, and
	insists that he is surprised and that his name should be
	removed.
	
	(ii) Sally Bloggs says some things on the WG mailing
	list that are sufficiently confused and/or outrageous
	that the WG concludes the document needs considerable
	clarification.  While Sally does not provide the
	clarifying text, she does make comments on it.  Sally is
	still in the rough relative to WG and IETF consensus.
	The authors conclude that Sally's comments resulted in
	considerable improvements to the document that would not
	have occurred otherwise and choose to acknowledge it.
	Sally would like her name removed.
	
	(iii) The authors include a broad acknowledgment of the
	WG instead of, or in addition to, listing particular
	names.  Consensus in the WG was very rough and remains
	controversial and some of those who are in the rough
	insist that the WG acknowledgment be removed,
	drastically rewritten, or that they be excluded by name.
	
	(iv) Someone mouthed off on the WG list or during Last
	Call and then insists that they were surprised to not be
	acknowledged and insist that their names be added.

Coming back to your example, note the huge difference between it
and 

	Thanks to <insert names> for their valuable comments and
	support during the development of this document even
	though they did not fully agree with the WG's conclusion

That may or may not be appropriate, but it is much less likely
to be deliberately misleading.

As Carsten noted, there is clearly a principle that one should
not lie in documents.  I don't know whether the overall text
would be improved by saying that explicitly.  But, as far as the
acknowledgments are concerned and very much unlike the "false
claim of authorship" situation, there are many cases and a lot
of them involve judgment calls.  I suggest that the IESG should
either remove the comment (and address the issues elsewhere as
needed) or put in more language, either opening and exploring
the can of worms or making sure that the acknowledgment case
being referred to is appropriately clearly-defined and narrow.
I also suggest that either of the latter two will be
time-consuming so, if the IESG is anxious to get this out
quickly, the pragmatic solution may be to remove the
parenthetical note and, if desired, include a forward-pointing
statement or reference about the acknowledgment cases.

best,
    john

---

From: Benoit Claise <[email-masked]>
Date: Sat, 30 May 2015 13:23:38 +0200

Hi John,

Yes indeed, there are many different (corner) cases, specifically 
related to the acknowledgment section.
An IESG statement must be concise, which makes it impossible to take 
into account all potential situations.
You are right that, in the end, it's a judgment call.

Removing the acknowledgment parentheses can be done, but this would 
dilute the "misleading in terms of support" message.

Regards, Benoit
>> support on

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 May 2015 09:21:27 -0400

--On Saturday, May 30, 2015 13:23 +0200 Benoit Claise
<[email-masked]> wrote:

> Yes indeed, there are many different (corner) cases,
> specifically related to the acknowledgment section.
> An IESG statement must be concise, which makes it impossible
> to take into account all potential situations.
> Removing the acknowledgment parentheses can be done, but this
> would dilute the "misleading in terms of support" message.

But the message is not "misleading in terms of support".   Its
title and the entire text other than that parenthetical note are
about misrepresentation and false claims of authorship.   If you
really want it to be about "misrepresentation in terms of
support", then I think there is a lot of rewriting to be done,
including, e.g., addressing the question of whether or not an
author should list an organizational affiliation (without
disclaimers) when her organization has given her permission to
develop the I-D but is either opposed to, or has taken no
position on, the protocol.   If one is worried about
misrepresentations of support that is an equally important issue
because, e.g., a reader might plausibly assume that Cisco
supports anything you write that including a Cisco email and/or
physical address (and that assumption would be correct for some
companies).

One could argue that the opposite is also true -- that, when I
company is strongly pushing for a particular protocol or choices
about a protocol, employees of that company (or those sponsored
by it) are obligated to disclose that affiliation and the
company's position.   We've never insisted on that, but perhaps
we should.  In any event, it is another opportunity to open and
discuss some rather complex issues.

Suggestion, if you don't want to embark on a complete rewrite:

(1) Remove the parenthetical note

(2) Insert a comment early in the document, following Carsten's
lead, that says, more or less, "It is inappropriate to lie in
documents and, in particular, to make statements that are
inaccurate or deceptive about participation and/or support",
mentioning that issues can arise with authorship, affiliations,
acknowledgments, and Contributions, as well as and in other
areas and that there are circumstances in which omitting a name
or disclosure that is significant can be as deceptive as
including a misleading one.

(3) Then indicate that the authorship issue is a particularly
important case and make the rest of the statement about it, as
it is now.

    john

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 30 May 2015 15:24:30 +0200

Since I believe that IESG statements are useful for documenting what the
IESG thinks it will do in specific sitiuations, I like them to be as
precise as possible, and as free as possible from text that:

- Doesn't help identifying which case it is talking about
- Doesn't help specifying what the IESG thinks it will do.

This statement is about "surprised authors". (I like the phrase, it's
memorable.)
Acknowledgements sections are a different matter, and thus the
parenthetical remark about them falls clearly under the scope of
"removable material" above.

Let's get rid of it. If the IESG wants to say something about
acknowledgements sections, let them write another note.

(And: Thanks to the IESG for getting a statement out!)

---

From: David Farmer <[email-masked]>
Date: Sat, 30 May 2015 10:14:32 -0500

> On May 30, 2015, at 01:48, Eliot Lear <[email-masked]> wrote:
> 

Sorry but I disagree. Not ALL RFCs, to exemplify why, I think the use of a humorous nom de plume or a sarcastic acknowledgement would be perfectly legitimate for RFCs published on a particular day in the spring.

Authorship, contribution, and acknowledgement are serious and important issues, but that is no reason to completely abandon or exclude humor and sarcasm in appropriate doses.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 May 2015 12:54:59 -0400

--On Saturday, May 30, 2015 10:14 -0500 David Farmer
<[email-masked]> wrote:

>> I like this draft, but I suggest that it apply to ALL RFCs
>> (not just the IETF stream).
>...

> Sorry but I disagree. Not ALL RFCs, to exemplify why, I think
> the use of a humorous nom de plume or a sarcastic
> acknowledgement would be perfectly legitimate for RFCs
> published on a particular day in the spring.
> 
> Authorship, contribution, and acknowledgement are serious and
> important issues, but that is no reason to completely abandon
> or exclude humor and sarcasm in appropriate doses.

Indeed.  In addition, I think the principle that each stream
should have the option of following the IETF's lead but
modifying it for local circumstances or striking out on its own
is an important one to preserve for all sorts of reasons.  There
are also bits in the draft that I'd expect the RFC Editor might
adopt as general policy, but, again, the principle that the RFC
Editor and not the IESG, makes those decisions is important.

   john

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 May 2015 08:05:56 +1200

> Editor and not the IESG, makes those decisions is important.

Yes. Maybe the draft could do a better job of separating issues
that are general ethical issues from those that are specific to
the IETF way of doing things.

I'm very open minded on what happens to the draft: possibly it should
just be added to the Tao, for example. The RFC Editor is welcome
to cherry-pick the text.

    Brian

P.S. Eagle eyes may have noticed that I plain forgot to include
an acknowledgement to John Klensin, who sent me some very helpful
comments on the -00 draft.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 30 May 2015 18:19:39 -0500

More broadly than just to John ...

On May 30, 2015 09:55, "John C Klensin" <[email-masked]> wrote:
> is an important one to preserve for all sorts of reasons.

That's certainly the current IESG view as I understand it. I don't speak
for the IESG, of course.

> There

The IESG gets that (we know what the IETF stream does, and YMMV in other
streams).

To slightly complicate things, the IESG is hearing complaints about
documents at the Internet-Draft stage within the IETF stream. I'm not sure
what the concerns would look like for other streams (and I don't think I'm
supposed to, as an AD).

The Lovely Heather Flanagan was in the room when this was discussed in the
IESG, with at least four or five IAB folk present, and we're talking to
Lars. I'm not the one sending all the email for the IESG, but if the ISE
hasn't seen this yet, I'm sure he will soon.

Spencer

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 May 2015 21:38:29 -0400

> More broadly than just to John ...

And my note was a little bit of an over-specific response to
Eliot and David.  To be clear, modulo the quibble about putting
one toe into the Acknowledgments swamp, rather than either
keeping it out or jumping in all the way, I think the IESG's
handling of this is, AFAICT, just right and shows sensitivity to
all of the right issues.   I am also reasonably confident that,
if the IESG does not assert authority I don't think it has or
should have, the other streams and the RSE can (and likely will)
take care of themselves.  I didn't see any signs of such
assertions before in this situation; your note provides
reassurance that I didn't just miss them :-)

    john

---

From: Eliot Lear <[email-masked]>
Date: Sun, 31 May 2015 10:48:23 +0200

There's a basic principle at stake: don't lie and don't mislead, either
directly, indirectly, or through omission.  We make an exception for
April 1 RFCs, which may do all three.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 31 May 2015 10:52:49 +0200

Whereas I take issue with the IESG (and IAB) making statements that
should be handled (a) through our normative processes and document
series; and (b) where there should be certain standards across our
document series, and this is one of them.

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 31 May 2015 12:39:25 +0200

Den 31. mai 2015 10:52, skrev Eliot Lear:
> Whereas I take issue with the IESG (and IAB) making statements
> that should be handled (a) through our normative processes and
> document series; and (b) where there should be certain standards
> across our document series, and this is one of them.

Now this statement is about Internet-Drafts, not about the RFC series
or any substream thereof.

If we figured out who is in charge of the Internet Drafts mechanism as
a whole, that body might be the right one to make pronouncements for
the whole whatever-it-is. (I don't think we've ever called the
Internet drafts a document series...)

I don't think we've figured out that yet. And it's a separate topic.

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 29 May 2015 22:07:53 +0000

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.

Thanks, Larry

---

From: Eliot Lear <[email-masked]>
Date: Sun, 31 May 2015 17:20:48 +0200

...
> I don't think we've figured out that yet. And it's a separate topic.

I think there's a pretty simple answer to this question, but perhaps
you're right that it should be dealt with separately.  But it should be
dealt with - and not just by the IESG.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Sun, 31 May 2015 11:26:13 -0400

--On Sunday, May 31, 2015 12:39 +0200 Harald Alvestrand
<[email-masked]> wrote:

>...
> Now this statement is about Internet-Drafts, not about the RFC
> series or any substream thereof.
> 
> If we figured out who is in charge of the Internet Drafts
> mechanism as a whole, that body might be the right one to make
> pronouncements for the whole whatever-it-is. (I don't think
> we've ever called the Internet drafts a document series...)

Actually we've carefully avoided that.  It clearly was not the
case when I-D actually expired and disappeared from
IETF-maintained repositories.

> I don't think we've figured out that yet. And it's a separate

IIR, we actually discussed that at some length years ago, about
the time we decided that all proposed RFCs except the 1 April
ones should be posted as I-Ds first (long before streams were
formalized) and perhaps more recently.  The conclusion then was
that I-Ds really were an IETF issue (otherwise we might, e.g.,
end up with different expiration policies for different types of
documents) but that the IESG should exercise good sense and not
try to make policies that would unreasonably constrain non-IETF
documents.  It was clear at the time that the RFC Editor could
make other policies and create other draft posting mechanisms if
they were needed (and, indeed, April 1st remains a case of that)
but that it would be an inefficiency to be avoided if needed.  

We've more or less revisited the topic with IPR policies: there
are per-stream rules for RFCs but, in principle, the same rules
for all I-Ds.  However, the IESG has, again IIR, decided that
I-Ds with highly restricted copyright statements will not be
processed on the standards track and perhaps not in the IETF
stream at all (don't remember).

So I'd suggest that we have discussed the issue.  The
discussions have been completely consistent with your
conclusions: it is a separate issue and we don't make
pronouncements for the series as a whole without very strong
justification and then we try to keep those pronouncements
narrow and flexible.

I would welcome having the other streams make statements of
agreement in principle about whatever the IESG has to say about
the IETF stream if the leadership/management of those streams
thought that appropriate.  I'd certain think it would be ok for
the other streams, the RFC Editor, the IETF Trust, and ISOC to
affirm the principle that lying or misrepresenting authorship,
support, or anything else is never appropriate, although it
would sadden me if we really concluded that was necessary rather
than obvious.   However, I don't see it as help for the IESG to
tell non-IETF entities what to do.

    john

---

From: John C Klensin <[email-masked]>
Date: Sun, 31 May 2015 11:51:06 -0400

--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?  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?  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.

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: "John Levine" <[email-masked]>
Date: 31 May 2015 17:04:15 -0000

>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: Melinda Shore <[email-masked]>
Date: Sun, 31 May 2015 09:17:39 -0800

> should usually alert surprised authors to the problem.

It's probably worth noting that alerting people suffers from
one of the same weaknesses as requiring approval from all authors,
which is that it's easy to create throwaway or spoofed email
addresses.  That said, I think this is the best approach.  If it
eventually turn out that bogus email addresses are being used
to work around the notifications, that can be dealt with.  But
for the time being notification can at least allows someone
to object if they receive a notice that a draft has been published
with their name on it.

Melinda

---

From: John C Klensin <[email-masked]>
Date: Sun, 31 May 2015 15:29:33 -0400

--On Sunday, May 31, 2015 09:17 -0800 Melinda Shore
<[email-masked]> wrote:

>> We do automatically notify authors when new drafts are
>> posted, which should usually alert surprised authors to the
>> problem.
> 
> one of the same weaknesses as requiring approval from all
> authors, which is that it's easy to create throwaway or
> spoofed email addresses.  That said, I think this is the best
> approach.  If it eventually turn out that bogus email
> addresses are being used to work around the notifications,
> that can be dealt with.  But for the time being notification
> can at least allows someone to object if they receive a notice
> that a draft has been published with their name on it.

Yes.  Listing someone as an author who didn't want to be so
listed could conceivably be a misunderstanding rather than a
malicious act.  It may be reasonable to treat it as such (as the
draft statement and default "tombstone" remedy, IMO, essentially
does).  

While we've never discussed what to do about the more extreme
cases and I hope we never have to, at the point that someone
starts creating bogus email addresses or otherwise does things
whose only purpose could be to frustrate notification
mechanisms, it will usually be quite clear that deliberately
deceitful behavior was intended.  Should such practices occur
often enough to be of concern, the IETF would be justified in
treating the behavior more harshly than "merely" taking a
document down.  For example, it might be in order to modify RFC
3683 to deny I-D posting rights or otherwise remove a person
from the IETF whose behavior was a threat to the community.
But, again, I hope we never have to reach the point where that
discussion is necessary.

    john

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 31 May 2015 12:36:48 -0700

> draft statement and default "tombstone" remedy, IMO, essentially

The more I hear about the cases I know about, the more most sound like
misunderstandings.

So, yes.

---

From: Melinda Shore <[email-masked]>
Date: Sun, 31 May 2015 11:46:01 -0800

> The more I hear about the cases I know about, the more most sound like

I think this is clearly the case, but it's probably worth mentioning
that sometimes that misunderstanding is not whether or not a given
individual has participated in a meaningful way, but rather a
misunderstanding of the IETF, in which people promoting a piece of
work feel that it's advantageous to show orchestrated support for
a draft by trying to develop an author list for political reasons
rather than technical ones.  Because this happens from time to time
I'm grateful to Heather for her clear policy statement on this from
the RFC Editor side, and to Brian for his work on developing an IETF
statement clarifying what authorship actually entails.

Melinda

---

From: Randy Bush <[email-masked]>
Date: Sun, 31 May 2015 12:49:23 -0700

> The more I hear about the cases I know about, the more most sound like

does this imply that we need a 25 page bcp which defines 'misunderstanding'
in exacting detail?

http://www.cafepress.com/mf/65741561/ietf-process_tshirt?shop=RandyBush&productId=999689784

randy

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 31 May 2015 12:55:24 -0700

> does this imply that we need a 25 page bcp which defines
'misunderstanding'

Well, I ain't sponsoring it!

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Jun 2015 08:03:28 +1200

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

---

From: "John Levine" <[email-masked]>
Date: 31 May 2015 20:15:04 -0000

>does this imply that we need a 25 page bcp which defines 'misunderstanding'

It's the same as misunderestimating, only shorter.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Sun, 31 May 2015 18:11:12 -0400

> should usually alert surprised authors to the problem.

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.

---

From: "John R Levine" <[email-masked]>
Date: 31 May 2015 18:33:21 -0400

> 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 think it's as much of a solution as we can afford.  For all the heat 
this topic has provoked, the large majority of drafts with multiple 
authors are sent in with the consent of all the authors.  Anything that 
makes it harder to surprise an author also makes it harder to be a 
legitimate co-author.  Given the amount of work already required to move 
an idea from -00 draft to RFC it seems to me inadvisable to add another 
hoop to jump through.

>From the discussion so far, it appears that most surprised authors are due 
to misunderstandings, not malice.  So in the rare event that someone 
disclaims authorship, the usual response would be oh, sorry, I'll resubmit 
without you and that should be that.  If it becomes a pattern or otherwise 
shows malice, that would be a problem but it doesn't seem like one we have 
to solve now, if ever.

Also, for better or worse the IETF has never tried to identify people 
online beyond their e-mail addresses.  I'm reasonably sure I know who you 
are because I've talked to you at meetings, but there are plenty of people 
who've don't come to meetings and contribute anyway, so all we have to go 
on is the address.  Since any e-mail verification can be trivially 
circumvented with a fake address, it doesn't seem wise to build yet 
another steel door on a cardboard box.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Jun 2015 01:42:39 +0200

> https://tools.ietf.org/html/draft-carpenter-whats-an-author-01

This reads good.

It should also tell the main author how to decide whether or not someone 
is an author, by answering a few questions:

- a person who provides corrective text is a co-author or not.

- a person who provides new text is a co-author or not.  What
   percentage of lines should qualify.

- a person who introduces a valuable idea that the main author
   reformulates into draft text is a co-author or not.

- a person who receives an invitation to contribute text and
   affiliation and provides only one is a co-author or not.

- a person who is reputed by other means to be an authority in this
   draft's field is an author or not.

- a person who was the first to write this idea in a draft X years ago
   is an author or not.

And, non-authors should have a means to identify themselves as such.

Alex

---

From: S Moonesamy <[email-masked]>
Date: Sun, 31 May 2015 17:35:40 -0700

>rules regarding acknowledgment of major contributors, copyright, and IPR.

That section in RFC 2026 is no longer applicable.  The above might be 
covered by the following text in a BCP:

    "The Contribution properly acknowledges all Contributors, including
     Indirect Contributors."

The proposed "surprised authorship" statement covers:

   (a) Authorship

   (b) Acknowledgements

   (c) Contributor

   (d) Indirect Contributor

   (e) Ethics

   (f) IPR

It's better to withdraw a problematic Internet-Draft as if one of the 
listed authors has not agreed to "enter into [the] legally-binding 
agreement".  I suggest not issuing an IESG statement about this 
matter as it is not a document which the IETF will be publishing.  If 
the IESG would like to have a statement it might have to figure out 
whether it is a good idea to cover (a) to (f) in a statement.

Regards,
S. Moonesamy