Re: [Rfced-future] Comments on draft-iab-rfcefdp-rfced-model-12

Eliot Lear <lear@lear.ch> Thu, 10 March 2022 08:28 UTC

Return-Path: <lear@lear.ch>
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 1B1EC3A112A; Thu, 10 Mar 2022 00:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 kEPiVZCW7vIo; Thu, 10 Mar 2022 00:28:19 -0800 (PST)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE903A111F; Thu, 10 Mar 2022 00:28:16 -0800 (PST)
Received: from [IPV6:2001:420:c0c0:1011::b] ([IPv6:2001:420:c0c0:1011:0:0:0:b]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 22A8SBMD661996 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 10 Mar 2022 09:28:12 +0100
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1646900893; bh=O7tk8vtmSl+JCqzlYbGZzt/udfelaPnmbU6yvnQu9Zs=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=PcYvIECBWs4PgbVPAn7/0nwDgzVkJIXfz1uZWjfpaxQaYdE34Chfrz9/GwDX7Wyei WfY6Vpg0pdkhtyOpi3QGUaO/YUNnjYYz4z3SKBZJuqhmBc4VVkzDL3pc8p7ybQfR2g pnPuRyFVcuPdkh2Xlaa8o6jBwaaLS2sg/AaYT5mI=
Message-ID: <18a9ed03-1be6-5993-750a-5dccf7f21bdb@lear.ch>
Date: Thu, 10 Mar 2022 09:28:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.2
Content-Language: en-US
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "rfced-future@iab.org" <rfced-future@iab.org>, IAB <iab@iab.org>, The IESG <iesg@ietf.org>, "stpeter@stpeter.im" <stpeter@stpeter.im>
References: <20220310060016.GV22457@mit.edu> <1e5d1934-806d-2689-4483-c3296e334e69@lear.ch> <20220310071251.GZ22457@mit.edu>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <20220310071251.GZ22457@mit.edu>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------BQXbWm9Z1Nz6wAWDe4HXisFO"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/J0mNJrXBM0SVL8LgDB4ypuxOKvU>
Subject: Re: [Rfced-future] Comments on draft-iab-rfcefdp-rfced-model-12
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: Thu, 10 Mar 2022 08:28:25 -0000

Hi Ben,

I'm only addressing points on which I have a view here:

On 10.03.22 08:12, Benjamin Kaduk wrote:
> I just mention it as a potential route to process deadlock.  Can the RSAB
> function with no chair?  I would like to assume that streams would pull and
> replace their reps that behave badly, but when designing systems try to
> remove classes of failure scenarios by construction, when possible.

It's really not necessary to worry about this.  Because the streams 
themselves require the proper functioning of the RFC editor, they're not 
likely to argue much over this, and just pick someone. The RSAB chair 
function is relatively weak, it's primary function being to convene 
meetings.  I would worry more about the IESG selecting someone to serve, 
quite frankly.


> It's getting late here, so maybe I'm just missing things, but while this
> does seem to be an improvement, it still seems to have somewhat of a
> mismatch with §4.3's depiction.  If I understand correctly, the RPC only
> cares about value assignments insamuch as the values being assigned get
> recorded in the RFCs being produced, and your new proposal doesn't mention
> documents/RFCs (other than this one) at all.

"This document requires that the RPC document registry value
assignments made by IANA."

>
>>> My understanding is that the current preference is to use the term
>>> "disabilities" rather than "special needs".
> Please don't forget this one.

I leave it to Peter to address this point.  I have no special knowledge 
or wisdom here.

> I was trying to say that 8730 is currently listed as only an informative
> reference, but it seems like it would be more properly classified as a
> normative reference.
>
> Thanks for the super-fast and comprehensive response!

Ah!  Ok.

Eliot