Re: [Rfced-future] Model proposal

Martin Thomson <mt@lowentropy.net> Sun, 12 July 2020 23:16 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7E83A09A5 for <rfced-future@ietfa.amsl.com>; Sun, 12 Jul 2020 16:16:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.22
X-Spam-Level:
X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=YtNHNW+l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=l4EQLUrl
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 8n74MFcB9mB9 for <rfced-future@ietfa.amsl.com>; Sun, 12 Jul 2020 16:16:55 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4443A099B for <rfced-future@iab.org>; Sun, 12 Jul 2020 16:16:55 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 7AFCD2DD for <rfced-future@iab.org>; Sun, 12 Jul 2020 19:16:54 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Sun, 12 Jul 2020 19:16:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=dFQyNBnRlT0Qj2d9Nr5rFaGUIDnvtSq u0WAKsfd+Pjg=; b=YtNHNW+lSMNTn2i0YIs0B1mrisHov5fNmlBE550OXGTidzz 0F2dP7uux7Y+vlE6xFnSPKd6r6/IKZGJDRroTE87ZO2HhBabKhJIe/2h7/aXEAc1 kREoGqx5QHJ3kmmX47A2uhhWCN12LOB9H03g1GPcyxMjdkKWpAc3JKC79LmcMIYA S3zloiDd3ohztY9zDYxLnjufnGzce9/uHrw9dHzta3UiVwT/gVyMLjLc7u5t91DO d7P231iTpWtfEzfuc155M15A4ggnjZrxQnI9jtw5dYQw7TATepuNcV4BXvlET5Bi UZErgn/k25QEUxtFDJtJFzZFBl1/yJGZ/Taqj9g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=dFQyNB nRlT0Qj2d9Nr5rFaGUIDnvtSqu0WAKsfd+Pjg=; b=l4EQLUrlG1LSw5DiQQ45Wu cjmy7LbmHB5ZDbgHd0jO74nBFb+qHrkdUDWQG9TRBCSN/Qz2RihDFiU/uSRp5n5X wCNWbTz5SSb09unWhIBya7WlseyuAYj4Z4P0RBht4vr6ueEXM59N80qKWJqJCO8z w/03wljWQZJ6+68vWGP3z+MXkte0rBjAjFIGzkEpmZdQn/55Qg48o2vWaLc2Ku+n QUrTThPKGbrqnfrbmhG6MsImtYAGPqG/n1S5iacwSrhgnPCCW8qG8Q9Ksw3Jt2Ok AjUFoTnExni82NsPqPXnUb1ikQt3RcFjNEHELJ/r9p2PN1O4KHuRMrMvg3HjtohA ==
X-ME-Sender: <xms:5ZkLX5CgkYnJO0vMPMpCyU_Xrm954lIZmnYDCOiwO7VFsDcvfqDQ6Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdejgddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:5ZkLX3jZ-JWusqksz5C-bJodYMl7lZoDLBCTCr-rthDqcOQueR1xFQ> <xmx:5ZkLX0nAVvAwSrGmpAbzClzCz2RX9-C1cHmxIvtdsDjJo9nGfQuGeg> <xmx:5ZkLXzzh4BvPxCIY7icOMP-CDykt9yBVIiy6Vu_Dulv7O0t3rfB49A> <xmx:5pkLX8DjAPObU7BG48-VDQRmWclFTM1q_yw0vR9PS-rYrDWQujAgFg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C39C8E00B3; Sun, 12 Jul 2020 19:16:53 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e
Mime-Version: 1.0
Message-Id: <9d390288-1056-4997-a540-96510e19a099@www.fastmail.com>
In-Reply-To: <14ef71ed-8f2f-22f4-edf0-ca22b004ec7c@gmail.com>
References: <d4d1cd2d-6df2-4cb4-b63a-f9bba45b48c0@www.fastmail.com> <51b72823-f2a2-29bd-bd88-f63e13522387@gmail.com> <d1f33279-0656-4caa-81e7-aa665d3a4acb@www.fastmail.com> <098fb5bf-f65c-d741-5fa7-baa6ae2c8358@nostrum.com> <F30FBA82-510C-4DC1-8535-FFA30345CEA7@kuehlewind.net> <DE2B2759-03FF-4D2C-B765-3C7C9AFA0955@vigilsec.com> <2A7C36D3-62CD-4BA0-88BE-F19A06D991DB@sobco.com> <48E30FDD-24B1-4602-9740-BB4DA2A4A7C1@sobco.com> <9A6E6D1C-FD14-4285-92A2-2483D9452CE9@vigilsec.com> <14ef71ed-8f2f-22f4-edf0-ca22b004ec7c@gmail.com>
Date: Mon, 13 Jul 2020 09:16:34 +1000
From: Martin Thomson <mt@lowentropy.net>
To: rfced-future@iab.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/ZaCM5BE8LpVvHHvfAw0upX2huMc>
Subject: Re: [Rfced-future] Model proposal
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jul 2020 23:16:57 -0000

On Sat, Jul 11, 2020, at 06:57, Brian E Carpenter wrote:
> > The overall point remains, does RFC 2026 apply here? If not, the the only appeal body would seem to be the IAB.
> 
> It will be what we define it to be at the end of this discussion. 

Yes.

FWIW, Russ' characterization missed program leads.  But talking to chairs and any AD/lead, while codified in 2026, happens before the truly formal part of the process.  It's an important piece for a couple of reasons, so I will amend the proposal to recognize that.

The structure of the appeals chain is informal (chair, AD), formal (IESG), in event of process failure (IAB), in event of the process itself being wrong (ISOC Board).  The structure I proposed covered the formal piece, but neglected the informal piece and did not provide safeguards for the process pieces, mostly because I hadn't thought the whole thing through.

I stand by the formal piece.  My logic is that we should not create a new body for this process.  Of the bodies we have, the IAB is most suitable.

I haven't any firm stance on what to do about a process backstop for the IAB.

> I'd certainly be inclined to put the ISOC Board at the end of any 
> appeal chain, but it's a new thing, not part of the IETF standards 
> process.

I'd be reluctant to ask the ISOC Board to participate in this process any more than they would in the IETF.  Keeping their involvement to arbitration of disputes over the process itself seems appropriate.