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

Peter Saint-Andre <stpeter@stpeter.im> Thu, 10 March 2022 21:36 UTC

Return-Path: <stpeter@stpeter.im>
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 A18D33A1C34; Thu, 10 Mar 2022 13:36:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=HbF+NdLG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZzBGr7lx
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 Mokv6P6_H4F1; Thu, 10 Mar 2022 13:36:26 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916E33A1D4E; Thu, 10 Mar 2022 13:36:04 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id A3B1F3200AF3; Thu, 10 Mar 2022 16:36:03 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 10 Mar 2022 16:36:04 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=A2o3blqFkANbp3 f+e3fnqEsPrCTroZgKyV5Ca2b8UXc=; b=HbF+NdLG8BZ2iCoXL4rX7EI7M2VPWz 7QizYmOnDGvCnA9/cKuBduPVT8bERSiBFjN97aIYHj0BlBhljsWGg5bcHcVv+Aqa C3mpf3rdAOJ/7oAY6jKQCgO/7WVaomSLMQZum7i7ribNwCtpyWO6En+zrhTmE/wP aymvz6XBxiGuD4VOGbq+glEZVinx0gv3meeYEyh04m+VE0W1mHZLUWjE+ros3JZh +/JxkYNgdgHlBnZCZdujAwallkAt/gNtg4htTvHnBgv/SMKFpbUrJlb6wl/QWgx0 aJFzIIHFtRPQFnkj2rBaNchbPonTwuwX6JxbE4FIGYRapvGOnoUsMNcw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=A2o3blqFkANbp3f+e3fnqEsPrCTroZgKyV5Ca2b8U Xc=; b=ZzBGr7lxGusAmwcX8KJULu5Z9pzFqv4rjQHAFlClquXVauRLQNuQtBREv H9+/VdFXU8iuofe4m3xl+dTJ/eSaP3BH58TqkhbKF+V92I9MYcgYzup6K2dHYVlb UFFzkDleNmVIu8x4RgN1b7ZvMrwwdRgd1b9dok/TeNuQcrmif6yrFqxbEx/j3yQN eC2OpRBel0LFaYaI3Sz8hJChg076OQajemJl2lMCNNXLni/R0e0zYL8mhurQB2yK 9rQmTRgVT6h2ir+yN2jPa/ZPTXYGam+KrFw17h320ZlKGP1ApK0v3q0aJ+JreIO8 UrpUyyxz0D8H0e+CwxaXJXRzsAAJw==
X-ME-Sender: <xms:Qm8qYk1yiUSo2SGsye3GETm1bsabBJk2-ctinJLbDj350-ws_4Rukg> <xme:Qm8qYvH0KBjKi-nKY7Ds1BCh6rOzkF68SUpdMVWx9cjPsaaCm6Yd6-ivAtwnXIQYN S9oCQ04IYs0mq8W-A>
X-ME-Received: <xmr:Qm8qYs4oDdmQgChNhiXChtpy7gt4W-p3bM2cLCDPD4X5SPLRNNwwRIdcVRu7lgIuZEPvDmN-jOY1-0jl-iqk5x_PKwDC2ueFxwryWFE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddvtddgudehudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfvfhfhufgjtgfgsehtkeertddtfeejnecuhfhrohhmpefrvght vghrucfurghinhhtqdetnhgurhgvuceoshhtphgvthgvrhesshhtphgvthgvrhdrihhmqe enucggtffrrghtthgvrhhnpefgueegfedvkeetfeegkeekgefggfeuteetheegvdfgffev geekgfelhedtgeetfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehsthhpvghtvghrsehsthhpvghtvghrrdhimh
X-ME-Proxy: <xmx:Q28qYt3fDsSWfnKPInzkZVR9MbhB_jhCXHX5vJw8JYiHafti4w3yRw> <xmx:Q28qYnGjdRlX0KQcOOjKD1B7pU3RhtfYMM47K7ti55-8Q2e0YOTwNQ> <xmx:Q28qYm-5ALMq576KCCHWmh--VnDbwI6-KpR7ZlWV8Rlzwo27EWF3FQ> <xmx:Q28qYrievhHfWQPLSElKAGBKx7Es2KROZ6Qx7zsz_uEE_KPdE-dAqA>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Mar 2022 16:36:02 -0500 (EST)
Message-ID: <0eaf0a63-91c2-9480-b361-e5d1554aaf3e@stpeter.im>
Date: Thu, 10 Mar 2022 14:35:58 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1
Content-Language: en-US
To: Eliot Lear <lear@lear.ch>, Benjamin Kaduk <kaduk@mit.edu>
Cc: "rfced-future@iab.org" <rfced-future@iab.org>, IAB <iab@iab.org>, The IESG <iesg@ietf.org>
References: <20220310060016.GV22457@mit.edu> <1e5d1934-806d-2689-4483-c3296e334e69@lear.ch> <20220310071251.GZ22457@mit.edu> <18a9ed03-1be6-5993-750a-5dccf7f21bdb@lear.ch>
From: Peter Saint-Andre <stpeter@stpeter.im>
In-Reply-To: <18a9ed03-1be6-5993-750a-5dccf7f21bdb@lear.ch>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/YlOS0VLX5HIs7eRMstfVi7S19q8>
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 21:36:31 -0000

Working my way from the end of the thread to the beginning...

On 3/10/22 1:28 AM, Eliot Lear wrote:
> 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?

Probably. As Eliot says, the RSAB chair mainly coordinates meetings of 
the RSAB.

>> 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. 

Agreed.

>> 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."

That's pretty much what it said before, no? ;-)

I suggest this in the "RPC Responsibilities" section:

14. Ensuring that RFCs accurately document registry value assignments
     made by IANA.

For the avoidance of doubt, we could also say the same thing under the 
IANA considerations.

>>>> 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.

Further research indicates to me that "people with disabilities" is 
indeed the term of art these days.

>> 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.

I'll move RFC 8730 from informative to normative.

Peter