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

John C Klensin <john-ietf@jck.com> Sat, 12 March 2022 02:20 UTC

Return-Path: <john-ietf@jck.com>
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 ADA233A0E84; Fri, 11 Mar 2022 18:20:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham 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 zY6p-cEOKBy1; Fri, 11 Mar 2022 18:19:57 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C8D3A0E67; Fri, 11 Mar 2022 18:19:57 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1nSrMG-000J9K-MF; Fri, 11 Mar 2022 21:19:52 -0500
Date: Fri, 11 Mar 2022 21:19:45 -0500
From: John C Klensin <john-ietf@jck.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Peter Saint-Andre <stpeter@stpeter.im>
cc: rfced-future@iab.org, IAB <iab@iab.org>, The IESG <iesg@ietf.org>, Eliot Lear <lear@lear.ch>
Message-ID: <D205B42CD433DB5510492CA8@PSB>
In-Reply-To: <20220310214041.GD22457@mit.edu>
References: <20220310060016.GV22457@mit.edu> <1e5d1934-806d-2689-4483-c3296e334e69@lear.ch> <20220310071251.GZ22457@mit.edu> <18a9ed03-1be6-5993-750a-5dccf7f21bdb@lear.ch> <0eaf0a63-91c2-9480-b361-e5d1554aaf3e@stpeter.im> <20220310214041.GD22457@mit.edu>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/mvS3UmrQq1hSXMFBj9CvG_ak3Ks>
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: Sat, 12 Mar 2022 02:20:01 -0000


--On Thursday, March 10, 2022 13:40 -0800 Benjamin Kaduk
<kaduk@mit.edu> wrote:

>> > "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.
> 
> That does remove the bits I was confused about, but to me it
> also seems to change the semantics somewhat.  Namely, now the
> RPC is just consuming things produced by IANA, which could be
> seen as removing the possibility to coordinate on which
> allocations are actually to be made, from what range(s), etc.,
> that the previous text seems to have implied.  I think I have
> seen the RPC notice things in editing that would affect what
> IANA does, and thus am not confident that describing this as a
> unidirectional flow would be entirely accurate.  (Whether such
> coordination could occur between RPC and IANA in an informal
> manner so as to get the right thing to happen anyway, is
> another question.)

In practice, it has always been a two-way flow, even when the
RFC Editor and IANA held discussions by looking into a mirror.
And even with that level of coordination, it has often been a
bit of a dance because of the long-standing principle that RFCs
do not direct IANA to assign, or even request, particular code
points.  So please try to write the text along the lines Ben
suggests, e.g., as something more like "Coordinate with IANA as
necessary to ensure that any registry value assignments that
actually appear RFCs are consistent with the registries."

   john