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

[Brian E Carpenter <[e-mail]>]

On 26-Aug-21 08:38, Michael StJohns wrote:
> On 8/24/2021 11:15 PM, 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:
> 
> Hi Brian -
> 
> If I thought that was the problem I would have provided changes to your 

> text rather than new text.  I'm too lazy to write if I don't have to.
> 
> WRT to your text, I really need it to not link the RPC with the 
> RSWG/RSAB and instead link it to the documents.  While this group has 
> finally gotten the point that the RPC does not "report to" those groups, 
> nor can those groups command the RPC, what I'm afraid of is 3-5 years 
> down the road where someone uses the text to justify the RSWG giving 
> operational directions to the RPC.
> 
> I also want to get the point made that the RPC works with the RSWG as it 
> tries to form strategic policy and that the RSWG is the primary place 
> for the RPC interaction rather than - as your text seems to imply - the 

> RPC is responsible for interacting with all comer directly on matters of 
> strategy.
> 
> None of the above is meant to imply that the RPC doesn't work with 
> authors on their documents - but that's not the thrust of the text you 
> and Mirja crafted and I think is handled elsewhere?  If not, a simple 
> line that indicates that set of interactions would be useful.
> 
> The RPC has both a role in the strategic process (e.g. sanity checks on 

> whether things will work, or the costs of doing new things as specified 

> by the Editorial series - e.g. with the RSWG), and the tactical process 

> (publishing documents while adhering to the aforesaid Editorial series 
> documents - with the RSCE and RSAB I would expect).  Those need to 
be 
> teased apart and specified separately and the RPC interaction with the 
> community on strategy ideally given a single specified place to happen.  
> That will help both the LLC and RPC scope the tasking required to 
> support the strategic process.
> 
> By the way - I'm not sure how you would have come to the conclusion you 

> came given the text I wrote.  Could you explain how you got there?

Simply because the thrust of your text was to say that the line of
command was policy --> IETF LLC --> RPC and Eliot's text seemed
to dilute that. Whereas yours seemed to emphasise that and dilute
the RPC's ability to interact widely with the community as well as
with authors. (I don't dispute that RSWG is the *primary* place
for such interaction.)

   Brian

> 
> Thanks, Mike
> 
> 
> 
>>
>> 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.
>>
>> 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 <[e-mail] <mailto:[e-mail]>> 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
>>>>
>>>>
>>>>
>>>
>