Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62

Eliot Lear <lear@lear.ch> Wed, 25 August 2021 04:47 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 A9D2D3A080E for <rfced-future@ietfa.amsl.com>; Tue, 24 Aug 2021 21:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.891
X-Spam-Level:
X-Spam-Status: No, score=-0.891 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_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 25t-Vkew6OJM for <rfced-future@ietfa.amsl.com>; Tue, 24 Aug 2021 21:46:54 -0700 (PDT)
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 E8BE43A080B for <rfced-future@iab.org>; Tue, 24 Aug 2021 21:46:51 -0700 (PDT)
Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:90a8:e80e:64e6:f9a8]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17P4kkmA216222 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 25 Aug 2021 06:46:46 +0200
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=1629866807; bh=6eyvKou5Ks5YiwCBMaapU+3e+kkFSoyq7045LYSDEqI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qskF+63jTf5Qd0tnqDxybryVZxA+YkT5V64zbsZdHvkIi3fXtXeK8DeNnZnDmVbzl vHkGn1Wc8b30bj8mofKb3YxIk+fEBlH6R0PvACkU5Ni3jfOox7zNICgK+WVxz95V0m Tq7n6Y5v638lfkCWF3ifr1a3bn15TYhIbIpKEfM8=
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Michael StJohns <msj@nthpermutation.com>, Eric Rescorla <ekr@rtfm.com>
Cc: rfced-future@iab.org
References: <C6116522-4988-4ED5-BCA7-9B36D701B99A@kuehlewind.net> <2B46402F-5268-46B7-890F-7C5CA159EF13@ietf.org> <25FCCF71-ED00-48CA-8A15-4BB63B632F73@kuehlewind.net> <f587a45c-14be-3495-01a0-858a2b4b7bb2@lear.ch> <cc7fda08-dabb-0c44-6890-0b4fd05d79d5@joelhalpern.com> <9F88E9DAC50B257953403E71@PSB> <6c544af8-b60c-1f4a-8730-3c923196eab6@joelhalpern.com> <cba4beb7-f364-bf47-86fe-d336494ca846@nthpermutation.com> <CABcZeBNtgzH3gYmUQ=9H5iM3ACffp9Uhvo1wp8DubyONQWVmnQ@mail.gmail.com> <7ce1368a-7bd2-73e3-5410-0e951f40fa00@nthpermutation.com> <CABcZeBMB4Ei0Ro01S1R8eJLDHWUFS-ePB5AGN0kC14AG-a4FSg@mail.gmail.com> <761bf2d8-759e-72e1-4c92-7419cea693bb@nthpermutation.com> <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com>
From: Eliot Lear <lear@lear.ch>
Message-ID: <589efbbe-7804-acf0-191a-2f9206c9c18e@lear.ch>
Date: Wed, 25 Aug 2021 06:46:42 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <1148ee5c-11da-6979-1056-2d7464ade5af@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="R6UJcEbuDtXQTn6q7RfIC2gg6J8ZlnkwH"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/MnB7uzYAUtoWE_t9yRyBhccV_7Y>
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
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: Wed, 25 Aug 2021 04:47:01 -0000

Just one point below:

On 25.08.21 05:15, Brian E Carpenter wrote:
> Front posting for cause:
>
> I think Mike's concern about Eliot's text derives from the way it starts.
> So I'd suggest:
>
> OLD:
> Publication of RFCs shall continue to be handled by the RFC Production Center (RPC) function in accordance with high-level policies that have been
> specified through the RSWG/RSAB process.  [[The RPC shall implement the policies specified by the RSWG/RSAB process reflecting the priorities of the community.]]
>
> NEW:
> Publication of RFCs shall continue to be handled by the RFC Production Center (RPC) function under direction from the IETF LLC, in accordance with
> high-level policies that have been specified through the RSWG/RSAB process, and subject to the IETF LLC providing the necessary resources.
>
> I wouldn't want to lose the text that discusses the RPC consulting directly with and reporting directly to the community.

We say that slightly differently- instead of reporting to the community, 
providing reports to the community.

Eliot


> (
>
> Regards
>     Brian Carpenter
>
> On 25-Aug-21 07:32, Michael StJohns wrote:
>> On 8/24/2021 2:38 PM, Eric Rescorla wrote:
>>>
>>> On Tue, Aug 24, 2021 at 11:34 AM Michael StJohns <msj@nthpermutation.com <mailto:msj@nthpermutation.com>> wrote:
>>>
>>>      On 8/24/2021 2:13 PM, Eric Rescorla wrote:
>>>>          ## Relationship between the RPC and the RSAB or RSWG
>>>>
>>>>          Neither the RSAB nor the RSWG has any oversight, monitoring, or directive relationship with respect to the RPC.  The RSAB and RSCE have an advisory relationship with the RPC as described above.
>>>>
>>>>
>>>>      This seems incorrect to me just as a matter of fact. When the RSWG and RSAB publish an RFC describing how the RPC ought to behave, then this is in fact directive.
>>>>
>>>>      -Ekr
>>>>
>>>      I believe you're missing the difference between the noun "directive" (e.g. the RFC is a policy directive which describes the operation of the RPC) which has the meaning:
>>>
>>>      "an official or authoritative instruction".
>>>
>>>      And the adjective "directive" (e.g. the RSWG has no directive relationship with the RPC) which has the meaning:
>>>
>>>      "involving the management or guidance of operations" -
>>>
>>>      To put it another way, your state executive or legislature may issue a directive (or a law) with respect to the wearing of masks, but the state does not have a directive relationship with you unless you actually work for the state.   I am personally subject to 1000s of directives of various forms, but since I work for myself, I am not the subject
> of a directive relationship in the meaning above.
>>>
>>> It seems to me that if we are having to refer to this kind of dictionary-based interpretation, then a rewrite is in order.
>> I referred to a dictionary only for your convenience.  But "directive" in conjunction with "relationship"  is the appropriate term here.  I guess you could use governing, or  control as replacements with some work, but those aren't as clear.
>>
>>>      I believe we've agreed that the RSAB and RSWG don't get to directly tell the RPC or the RSCE what to do - e.g. they may NOT direct either of those entities to perform specific work - all they can do is publish the RFCs and then ask the LLC to craft a contract or engagement agreement reflecting those RFCs.
>>>
>>> I think you're drawing too sharp a distinction.
>>>
>>> Suppose that the RSAWG were to publish an RFC saying that heretoforth authors should be listed in alphabetical order. I would expect the RPC to
> comply with that without some new contractual term from the LLC. Do you disagree?
>>
>> The other section has this:
>>
>>
>>> Publication of RFCs shall continue to be handled by the RFC Production  Center (RPC) function in accordance with policies described in the
> Editorial series of RFCs, and consistent with the engagement agreement(s)
> between the RPC and the LLC.
>> Assuming that the change in the RFC's does not require a change in the costs, or impose more work and where the change is consistent with the agreement between the RPC and the LLC, then there is no requirement to change the contract.   And actually, if this requires a tooling change (not saying it will, but who knows), it might require LLC approval to
> spend the money so... it may not be a contract change, but it may require
> LLC (or IED) buy in.  That seems something that a) the RPC would hopefully bring up during the RFC creation, b) the LLC would analyze before RFC approval, and c) the LLC would be proactive in working with the RPC to implement the new RFC policies.   Or d) the LLC would say - we're not payinf for this.
>> The counter example is that you write a new RFC that says that the RPC shall maintain a GIT instance tracking all of the changes made between submission and publication of an RFC candidate and that wasn't part of the contract, then yes it requires a change.
>>
>> So the general answer to the more general question: "Will Editorial stream RFCs published by RSAB/RSWG require contract changes to the RPC?" is "It depends" which I think you probably already knew.
>>
>> Later, Mike
>>
>>
>>
>>> -Ekr
>>>
>>>      Later, Mike
>>>
>>>
>>>
>>