Re: [spring] Dispute process (Was: Resignation request)

Pete Resnick <resnick@episteme.net> Wed, 11 March 2020 18:26 UTC

Return-Path: <resnick@episteme.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04093A10CC; Wed, 11 Mar 2020 11:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 k4LL0Ddz4oNm; Wed, 11 Mar 2020 11:26:38 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191443A10D2; Wed, 11 Mar 2020 11:26:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 2E0F3A342E85; Wed, 11 Mar 2020 13:26:37 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV2aKYiQnKGm; Wed, 11 Mar 2020 13:26:36 -0500 (CDT)
Received: from [172.16.1.18] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 3C96AA342E7C; Wed, 11 Mar 2020 13:26:36 -0500 (CDT)
From: Pete Resnick <resnick@episteme.net>
To: Nico Williams <nico@cryptonector.com>
Cc: Paul Wouters <paul@nohats.ca>, Alex Bogdanov <bogdanov=40google.com@dmarc.ietf.org>, IETF <ietf@ietf.org>, SPRING WG List <spring@ietf.org>
Date: Wed, 11 Mar 2020 13:26:35 -0500
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <0D0D273B-345D-457D-B2B9-9B43C780191A@episteme.net>
In-Reply-To: <20200310233442.GZ18021@localhost>
References: <20200310184518.GY18021@localhost> <EB49F5CB-1FD1-4FB1-867B-886233E33B38@nohats.ca> <20200310233442.GZ18021@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/H199Haqo5xB-0lAIeRBauEV5SeA>
Subject: Re: [spring] Dispute process (Was: Resignation request)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2020 18:26:40 -0000

On 10 Mar 2020, at 18:34, Nico Williams wrote:

> On Tue, Mar 10, 2020 at 03:07:53PM -0400, Paul Wouters wrote:
>> On Mar 10, 2020, at 14:45, Nico Williams <nico@cryptonector.com> 
>> wrote:
>>> What I've encountered is that at the limit you have to appeal or 
>>> give
>>> up, and how well things go before you get to that stage depends on 
>>> how
>>> willing WG chairs and responsible AD are to actively mediate dispute
>>> resolution.
>>>
>>> The case I felt went really badly was the TLS DNSSEC extension.
>>
>> I agree and while that case was bad, what’s worse is that no
>> post-mortem was done here. I don’t think the IETF as an 
>> organization
>> will take any lesson from this, and that in itself makes it likely 
>> the
>> same mistakes will be made again.
>
> +1.
>
> Perhaps we need a procedure for lodging complaints that aren't 
> appeals,
> and which result in a review and report.

Adding a "report back" step to the less formal part of RFC 2026 6.5.1 
would probably be a good practice. I know I did do this when an issue 
was "semi-formally" brought to my attention some years ago.

>>> So there was no question of appeal, really.
>>
>> I think also because in the appeal some of the same actors would 
>> appear.
>
> The whole point of an appeal is to get the IETF chair, or the IAB, to
> step in.  The route to appeal was mooted by the WG's choice to abandon
> the work item.

Again, remember that there's a less formal part, before the chair, whole 
IESG, or IAB step into the picture. That might have been the appropriate 
move in this case.

> (A cynic might wonder if that choice was not purposeful, precisely to
> allow the original work to continue unimpeded [perhaps] on the ISE 
> track
> with an appeal mooted.  I do not believe that was the case.)

As Paul alluded to, it all assume that the ISE accepts the documents. If 
not, more fun may occur.

>> Going back to this thread, when I read the subject of resignation and
>> the first email, it seemed like I just stumbled across a hallway 
>> fight
>> - people that demand unreasonable things. I don’t know how this
>> conflict went from nothing to asking for someone’s resignation but
>> clearly more people should have been involved earlier to de-escalate
>> this. maybe that was tried and just not visible here? It would be 
>> good
>> if there had been some kind of log that could have been referenced so
>> we could determine why this failed to de-escalate.
>
> +1

Yep.

> I wouldn't want to drag the ombudsman into this, but maybe that's the
> next best step.

I would refer you to RFC 7776. I don't think this would be in the 
ombudsteam's purview. (Not trying to get out of work, really!)

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best