Re: IESG Statement on surprised authors

John C Klensin <john-ietf@jck.com> Sun, 31 May 2015 19:29 UTC

Return-Path: <john-ietf@jck.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 262D01A899A for <ietf@ietfa.amsl.com>; Sun, 31 May 2015 12:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 dIkYo3g7jV9T for <ietf@ietfa.amsl.com>; Sun, 31 May 2015 12:29:39 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36EA1A8992 for <ietf@ietf.org>; Sun, 31 May 2015 12:29:39 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Yz8vS-000OXY-3b; Sun, 31 May 2015 15:29:38 -0400
Date: Sun, 31 May 2015 15:29:33 -0400
From: John C Klensin <john-ietf@jck.com>
To: Melinda Shore <melinda.shore@gmail.com>, ietf@ietf.org
Subject: Re: IESG Statement on surprised authors
Message-ID: <F7BD3E4838B3CC6A47EF5423@JcK-HP8200.jck.com>
In-Reply-To: <556B4233.8020806@gmail.com>
References: <20150531170415.24384.qmail@ary.lan> <556B4233.8020806@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/UGeH9WBibp3E2VPKzK3wFw44VlA>
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: Sun, 31 May 2015 19:29:41 -0000


--On Sunday, May 31, 2015 09:17 -0800 Melinda Shore
<melinda.shore@gmail.com> wrote:

> On 5/31/15 9:04 AM, John Levine wrote:
>> We do automatically notify authors when new drafts are
>> posted, which 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.

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