Re: IESG Statement on surprised authors

"Larry Kreeger (kreeger)" <kreeger@cisco.com> Mon, 01 June 2015 23:32 UTC

Return-Path: <kreeger@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC851A1BA3 for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 16:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7twpD6anm8NM for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 16:32:16 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1EC91A1B9C for <ietf@ietf.org>; Mon, 1 Jun 2015 16:32:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4723; q=dns/txt; s=iport; t=1433201536; x=1434411136; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mA5q9DvtwbNsD0GRJvYatHkMGnrhN9Wi/StdRyfLcN0=; b=VhGI6T1/mk4jfbMa/magnipieuUxdcbeFuuMjXcNu4xce1kAKj2a/27Y AIH5IyLMhOenkYFjgk8YiTbx7eF848twSXfYpAxHEmWlPkWF/ztDoqXnJ m6t31G3fGXxD3td9JsNt7N5L7pfaKFxoCYQCLwgpldJS/IMvKdwKahkTv I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AkBACK6mxV/51dJa1cgxCBMga+VgmHUQKBOTgUAQEBAQEBAYEKhCMBAQSBCQIBCBguMiUCBBOILdh1AQEBAQEBBAEBAQEeikGBAoUNhC0FjAyHBIsWgSuDc4o4hAmDWSNhgxdvgUaBAQEBAQ
X-IronPort-AV: E=Sophos;i="5.13,535,1427760000"; d="scan'208";a="155452770"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jun 2015 23:32:15 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t51NWFOH002329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <ietf@ietf.org>; Mon, 1 Jun 2015 23:32:15 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.61]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 1 Jun 2015 18:32:15 -0500
From: "Larry Kreeger (kreeger)" <kreeger@cisco.com>
To: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: IESG Statement on surprised authors
Thread-Topic: IESG Statement on surprised authors
Thread-Index: AQHQmlHrteXwgLU5d0ylk2ZEyn/PgJ2TYbKAgAMwsQCAAZ3oAA==
Date: Mon, 01 Jun 2015 23:32:14 +0000
Message-ID: <D192377C.1498BD%kreeger@cisco.com>
References: <20150529205551.22495.73800.idtracker@ietfa.amsl.com> <D18E2F33.14965E%kreeger@cisco.com> <003FB1C709725C8BDD35C916@JcK-HP8200.jck.com>
In-Reply-To: <003FB1C709725C8BDD35C916@JcK-HP8200.jck.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [10.155.166.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <167379CF6EA7774FB5FB7DC340DE27BE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/BKHyqPDojK5mSlvkwVJPdfSFgk0>
X-Mailman-Approved-At: Tue, 02 Jun 2015 08:03:01 -0700
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2015 23:32:18 -0000

Hi John,

Please see my responses inline below.

 - Larry

On 5/31/15 8:51 AM, "John C Klensin" <john-ietf@jck.com> wrote:

>
>
>--On Friday, May 29, 2015 22:07 +0000 "Larry Kreeger (kreeger)"
><kreeger@cisco.com> 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.
>