Re: To "lose the argument in the WG"

"Pete Resnick" <presnick@qti.qualcomm.com> Tue, 14 February 2017 23:12 UTC

Return-Path: <presnick@qti.qualcomm.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2261296EE for <ietf@ietfa.amsl.com>; Tue, 14 Feb 2017 15:12:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.022
X-Spam-Level:
X-Spam-Status: No, score=-7.022 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
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 GE3wrDecq1nu for <ietf@ietfa.amsl.com>; Tue, 14 Feb 2017 15:12:34 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE89A129407 for <ietf@ietf.org>; Tue, 14 Feb 2017 15:12:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1487113954; x=1518649954; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=N/mj9RhnkDVWbeVPSCvezaimkmxqyZmq6h4Y6+eBf7o=; b=rAsxBrvx3GA6PuM9HxD0U06bJ2jfabJcORAqBabexxx++5y58dASBGpY YrMGPwcTeJFMP3mFQd0sw6IIF7CQYOWPUqlQLZaNbTjcdRsTOCO+OTuzs RnWF1SbI+3eK8Vf2FUk71uT/0TXThUowgOYLzATlM3dAhj2ZKJvc3/yQf U=;
X-IronPort-AV: E=Sophos;i="5.35,163,1484035200"; d="scan'208";a="358262163"
Received: from unknown (HELO Ironmsg03-L.qualcomm.com) ([10.53.140.110]) by wolverine02.qualcomm.com with ESMTP; 14 Feb 2017 15:12:34 -0800
X-IronPort-AV: E=McAfee;i="5800,7501,8439"; a="1313690643"
Received: from unknown (HELO [10.64.121.67]) ([10.64.121.67]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Feb 2017 15:12:33 -0800
From: Pete Resnick <presnick@qti.qualcomm.com>
To: dcrocker@bbiw.net
Subject: Re: To "lose the argument in the WG"
Date: Tue, 14 Feb 2017 15:01:31 -0800
Message-ID: <84E813AE-6BD6-4EC3-A8CD-8AB24C9857D2@qti.qualcomm.com>
In-Reply-To: <76d4aff3-760c-b258-a4e5-426ba69923f7@dcrocker.net>
References: <66A86016-0382-4B2C-B9E8-30638237CB68@qti.qualcomm.com> <00e13499-7cea-a79a-7de1-dd9bad4bc530@dcrocker.net> <20170214060156.73B32639AEDF@rock.dv.isc.org> <0A3B2FF0-8F1C-430E-B4ED-DFA4CDB1FDB3@gmail.com> <0FB75520-E0BA-453C-8CF6-9F2D05B95FD6@fugue.com> <76d4aff3-760c-b258-a4e5-426ba69923f7@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5344)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/hLbMTFvAMvI2PfzlHidZzdBRoCE>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 14 Feb 2017 23:12:36 -0000

On 14 Feb 2017, at 9:05, Dave Crocker wrote:

> The IETF's formal process document on standards:
>
>    The Internet Standards Process -- Revision 3
>    https://www.ietf.org/rfc/rfc2026.txt
>
> says nothing about Last Call.

Well, of course, except for defining it in section 14:

    Last-Call - A public comment period used to gage the level of
       consensus about the reasonableness of a proposed standards 
action.

> So the formal IETF specification for the role of Last Call is in:
>
>      IETF Working Group Guidelines and Procedures
>      https://tools.ietf.org/html/rfc2418
>
>
>>    This Last Call will announce the intention of
>>    the IESG to consider the document, and it will solicit final 
>> comments
>>    from the IETF within a period of two weeks.  It is important to 
>> note
>>    that a Last-Call is intended as a brief, final check with the
>>    Internet community, to make sure that no important concerns have 
>> been
>>    missed or misunderstood. The Last-Call should not serve as a more
>>    general, in-depth review.

Indeed. If Last Call results in an issue that requires a more general, 
in-depth review, I think the presumption of that text is that it's time 
to send it back to the WG.

> What folks are doing is spontaneously changing the role of this step, 
> ignoring the considerable costs and detriments, while relying on a 
> theory of benefit that is very, very, very rarely actually 
> demonstrated.

I think you've conflated two things: Yes, Last Call should serve as a 
brief final check, not to have a long re-hashed technical discussion. 
But that doesn't mean the outcome of that brief final check is always 
brief and final: When Last Call identifies an issue that was missed or 
mis-evaluated by the WG (perhaps due to JCK's observation about WGs that 
remain homogeneous and insulated), considerable cost and detriment 
should be expected, and is probably appropriate. We have all seen 
efforts that have gone completely off the rails, perhaps due to bad 
management choices, and it is a sign of pathology if that's only noticed 
at Last Call time. Yes, it should probably have been handled during the 
WG process or by interim appeals, but if Last Call is where it's finally 
dealt with, deal with it we must.

Someone described it in private email to me this way: Last Call 
shouldn't be used to argue for a choice where the only consequence is 
"flavor"; it should only be used when the WG has made a choice this is 
"jumping-off-the-cliff". I agree with that in general (allowing that 
people's judgement of how close to the cliff one is might differ), and 
it's the responsibility of everyone to keep their comments to things in 
the latter category.

My main complaint is that people are treating this as a game, with 
points that are "won" or "lost". Telling people that they "lost" or that 
"it's just sour grapes" is obnoxious and has no place in the discussion. 
If someone is abusing the process by bringing up previously 
well-considered topics, of course the person running the Last Call has 
to shut that down. I can even tolerate the occasional random participant 
saying, "Pete, you know this issue was discussed at length, and you 
didn't even bother to fairly say why you think the WG came to the wrong 
conclusion, so this is really just rehashing." Challenging folks to come 
up with why this is not just a "flavor preference" is reasonable: Where 
is the cliff? But just dismissing them with, "Sorry, you were ruled a 
loser" is not how this is supposed to go.

(Speaking for myself: It appears to me that the 2460bis discussion did 
identify a point that is appropriate for the larger community to weigh 
in on. On the other hand, I have yet to be convinced that the major 
point brought up on the SLIM is other than a "flavor preference". In 
neither case should anyone be yelling "sour grapes". That's impugning 
motives and simply ad hominem.)

> To Ted's point, indulging folk who 'did not have time' to participate 
> earlier is frankly abusive of all those who did.

Yeah, I don't find Ted's point at all convincing either. On the other 
hand, if the WG didn't seek out required expertise and someone does 
notice a showstopper, that's not abusive. The WG screwed up.

(I don't think Dave and I centrally disagree on this.)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478