Subject: [Rfced-future] Issue 13: new text

From: Eliot Lear <[email-masked]>
Date: Mon, 4 Jan 2021 17:55:46 +0100

Coming back to this, I believe we are now up to the following text:

> All strategic body meetings are open to the public.  At body's initial formation, all discussions are to take place on open mailing lists, and anyone is welcome to comment / discuss.  The strategic body may decide by rough consensus to use additional forms of communication that are consistent with [RFC2418].

The purpose of the change is to accommodate the discussion between Joel and EKR, and to address Brian’s point.  I have removed references to “issues” because that made it sound like each issue must be initiated in email (EKR’s point, and my poor wording earlier).  Rather, we will leave it til later for the group to decide best how to operate, so long as they remain within the confines of RFC 2418 (Brian’s point).

I am hoping we can move off of this issue, but given the discussion, we’ll do another consensus call after people have had an opportunity to comment on the above.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Jan 2021 09:08:02 -0800

On Mon, Jan 4, 2021 at 8:56 AM Eliot Lear <lear=[email-masked]>
wrote:

> All strategic body meetings are open to the public.  *At body's initial
> formation,* all discussions *are to* take place on open mailing lists,
> and anyone is welcome to comment / discuss.  The strategic body may
> decide *by rough consensus* to use additional forms of communication that
> are consistent with [RFC2418].
>
>
> The purpose of the change is to accommodate the discussion between Joel
> and EKR, and to address Brian’s point.  I have removed references to
> “issues” because that made it sound like each issue must be initiated in
> email (EKR’s point, and my poor wording earlier).  Rather, we will leave it
> til later for the group to decide best how to operate, so long as they
> remain within the confines of RFC 2418 (Brian’s point).
>

I'd like to see a citation to 8874 here to make clear that we're not saying
that that's not permitted.

For instance, at the end "such as those described in RFC 8874"

-Ekr

> I am hoping we can move off of this issue, but given the discussion, we’ll
> do another consensus call after people have had an opportunity to comment
> on the above.
>

>
> Eliot
> --
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 4 Jan 2021 20:04:51 -0500

Reposting this as it seems to have gotten ignored:

> Instead:
>
>
> "All strategic bodies are open to the public.  All strategic issue 
> discussions will take place on open mailing lists, and anyone is 
> welcome to comment/discuss.  On a document by document basis, the 
> strategic body may decide by rough consensus, and with the assent of 
> the designated editors, to use additional forms of communication 
> consistent with [RFC2418] for the production of a given document.  Use 
> of those forms of communication does not replace the responsibility of 
> the editors to bring major strategic issues with the document to the 
> mailing list."
>
>
> Github is pretty much the worst way to have a discussion such as we're 
> currently having and I expect that things like writing an SOW or even 
> deciding what the charter might be needs to be kept on the mailing 
> list.  It may make sense for a given document for the editing of 
> various content, but not for the day to day operation of the group.
>
> Later, Mike

The key problem here is that there's a big difference between how you do 
the strategic discussions of the WG and the actual work for a given 
document and that's not being captured by the text below.    This is NOT 
an IETF WG and is not going to be producing implementable specifications 
(please don't quibble about what I mean here).   To be honest, I don't 
actually think that anyone but the RSE is going to be producing 
documents (and very few of those!) and I'd really like to avoid placing 
the RSE in a straight jacket requiring them to use a system that adds to 
their work without actually improving the end product.

  Later, Mike

On 1/4/2021 11:55 AM, Eliot Lear wrote:
>> |All strategic body meetings are open to the public. *At body's 
>> initial formation,* all discussions *are to* take place on open 
>> mailing lists, and anyone is welcome to comment / discuss. ||The 
>> |strategic body may decide *by rough consensus* to use additional 
>> forms of communication that are consistent with [RFC2418].
> *
> *
> The purpose of the change is to accommodate the discussion between 
> Joel and EKR, and to address Brian’s point.  I have removed references 
> to “issues” because that made it sound like each issue must be 
> initiated in email (EKR’s point, and my poor wording earlier). 
>  Rather, we will leave it til later for the group to decide best how 
> to operate, so long as they remain within the confines of RFC 2418 
> (Brian’s point).
>
> I am hoping we can move off of this issue, but given the discussion, 
> we’ll do another consensus call after people have had an opportunity 
> to comment on the above.
>
> Eliot
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 5 Jan 2021 07:24:48 +0100

I saw it but could not imagine there would be rough consensus for text that requires a working methods discussion for every document.

Eliot

> On 5 Jan 2021, at 02:04, Michael StJohns <[email-masked]> wrote:
> 
>> "All strategic bodies are open to the public.  All strategic issue discussions will take place on open mailing lists, and anyone is welcome to comment/discuss.  On a document by document basis, the strategic body may decide by rough consensus, and with the assent of the designated editors, to use additional forms of communication consistent with [RFC2418] for the production of a given document.  Use of those forms of communication does not replace the responsibility of the editors to bring major strategic issues with the document to the mailing list."
>> 
>> 
>> 
>> Github is pretty much the worst way to have a discussion such as we're currently having and I expect that things like writing an SOW or even deciding what the charter might be needs to be kept on the mailing list.  It may make sense for a given document for the editing of various content, but not for the day to day operation of the group.
>> 
>> Later, Mike
> 
> 
> The key problem here is that there's a big difference between how you do the strategic discussions of the WG and the actual work for a given document and that's not being captured by the text below.    This is NOT an IETF WG and is not going to be producing implementable specifications (please don't quibble about what I mean here).   To be honest, I don't actually think that anyone but the RSE is going to be producing documents (and very few of those!) and I'd really like to avoid placing the RSE in a straight jacket requiring them to use a system that adds to their work without actually improving the end product.
> 
>  Later, Mike
> 
> 
> 
> 
> 
> 
>

---

From: Michael StJohns <[email-masked]>
Date: Tue, 5 Jan 2021 14:01:15 -0500

Hmm... I didn't realize the role of the chair included ignoring 
submissions?  If you disagreed with what I proposed, then say so and 
why, rather than just passing over it.

In any event, it's not the chair's role to imagine consensus, rather the 
role requires you to actively seek it.

I could see something like GIT being used for a document such as the XML 
vocabulary which might benefit from a fast iteration 
(propose/implement/test/approve or remove) model.   However, reviewing 
the documents that had Heather as the author  or editor,  I think for 
the most part they benefited from the slow iteration model of publish 
draft/receive comments/revise draft.

Or more bluntly, forcing the development of all documents into one model 
with many micro authors may actively harm or substantially delay the 
production of some documents necessary to evolve the series.  cf RFC8153 
for an example of a document which might have been harmed or delayed.

I see the proposed language here as an attempt to allow for the later 
imposition of a model which will always micromanage the authors by 
random participants and I just don't think that's sustainable or useful.

Later, Mike

On 1/5/2021 1:24 AM, Eliot Lear wrote:
> I saw it but could not imagine there would be rough consensus for text 
> that requires a working methods discussion for every document.
>
> Eliot
>
>> On 5 Jan 2021, at 02:04, Michael StJohns <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> consistent with [RFC2418] for the production of a given document.  
>>> Use of those forms of communication does not replace the 
>>> responsibility of the editors to bring major strategic issues with 
>>> the document to the mailing list."
>>>
>>>
>>> Github is pretty much the worst way to have a discussion such as 
>>> we're currently having and I expect that things like writing an SOW 
>>> or even deciding what the charter might be needs to be kept on the 
>>> mailing list.  It may make sense for a given document for the 
>>> editing of various content, but not for the day to day operation of 
>>> the group.
>>>
>>> Later, Mike
>>
>> The key problem here is that there's a big difference between how you 
>> do the strategic discussions of the WG and the actual work for a 
>> given document and that's not being captured by the text below.    
>> This is NOT an IETF WG and is not going to be producing implementable 
>> specifications (please don't quibble about what I mean here).   To be 
>> honest, I don't actually think that anyone but the RSE is going to be 
>> producing documents (and very few of those!) and I'd really like to 
>> avoid placing the RSE in a straight jacket requiring them to use a 
>> system that adds to their work without actually improving the end 
>> product.
>>
>>  Later, Mike
>>
>>
>>
>>
>>
>>
>>> Joel and EKR, and to address Brian’s point.  I have removed 
>>> references to “issues” because that made it sound like each issue 
>>> must be initiated in email (EKR’s point, and my poor wording 
>>> earlier).  Rather, we will leave it til later for the group to 
>>> decide best how to operate, so long as they remain within the 
>>> confines of RFC 2418 (Brian’s point).
>>>
>> [email-masked] <mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Jan 2021 08:46:08 +1300

Hmm. I really think the issue of whether it's document-by-document or not doesn't need to be decided as a matter of principle; that is the power of simply invoking RFC2418, with or without mentioning RFC 8874 as ekr suggested. FWIW, RFC 8874 itself gives primacy to email. ("A working group chair MUST consult the working group mailing list for any issue that is potentially contentious.")

[That said, Eliot, absence of comment on Mike's message doesn't really indicate consensus either way, especially during the holiday period.]

Regards
   Brian Carpenter

On 05-Jan-21 19:24, Eliot Lear wrote:
>> On 5 Jan 2021, at 02:04, Michael StJohns <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>> |All strategic body meetings are open to the public.  *At body's initial formation,* all discussions *are to* take place on open mailing lists, and anyone is welcome to comment / discuss.  ||The |strategic body may decide *by rough consensus* to use additional forms of communication that are consistent with [RFC2418].
>>> *
>>> *

---

From: Eliot Lear <[email-masked]>
Date: Wed, 6 Jan 2021 10:11:54 +0100

> On 5 Jan 2021, at 20:01, Michael StJohns <[email-masked]> wrote:
> 
> Hmm... I didn't realize the role of the chair included ignoring submissions?  If you disagreed with what I proposed, then say so and why, rather than just passing over it.
> 
> In any event, it's not the chair's role to imagine consensus, rather the role requires you to actively seek it.

Not your job to tell the chairs what the chair's job is in this forum.  If you have a complaint, take it up the chairs privately or with the IAB.

> 
> I could see something like GIT being used for a document such as the XML vocabulary which might benefit from a fast iteration (propose/implement/test/approve or remove) model.   However, reviewing the documents that had Heather as the author  or editor,  I think for the most part they benefited from the slow iteration model of publish draft/receive comments/revise draft.
> 
> Or more bluntly, forcing the development of all documents into one model with many micro authors may actively harm or substantially delay the production of some documents necessary to evolve the series.  cf RFC8153 for an example of a document which might have been harmed or delayed.

See Brian’s response, but your proposal runs counter to the compromise that Joel and EKR were aiming toward, and would require folks like EKR and Mark to drag the entire WG into a per document debate which I don’t for a moment believe there would garner their or others’ approval.  However, I am happy to be proven wrong.

> I see the proposed language here as an attempt to allow for the later imposition of a model which will always micromanage the authors by random participants and I just don't think that's sustainable or useful.

Where do you see that imposition being made?  What the text says is that the WG will decide on its communication methods based on rough consensus.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Wed, 6 Jan 2021 18:26:48 -0500

Inline

On 1/6/2021 4:11 AM, Eliot Lear wrote:
>
>
>> On 5 Jan 2021, at 20:01, Michael StJohns <[email-masked] 
>> In any event, it's not the chair's role to imagine consensus, rather 
>> the role requires you to actively seek it.
>
> Not your job to tell the chairs what the chair's job is in this forum. 
>  If you have a complaint, take it up the chairs privately or with the IAB.

That's your take away?  Do you actually disagree on your role here?  You 
made the dismissive comment on the list - it seems to me that the list 
is the right place to respond.

>
>>
>> I could see something like GIT being used for a document such as the 
>> XML vocabulary which might benefit from a fast iteration 
>> Or more bluntly, forcing the development of all documents into one 
>> model with many micro authors may actively harm or substantially 
>> delay the production of some documents necessary to evolve the 
>> series.  cf RFC8153 for an example of a document which might have 
>> been harmed or delayed.
>
> See Brian’s response, but your proposal runs counter to the compromise 
> that Joel and EKR were aiming toward, and would *require* folks like 
> EKR and Mark to drag the entire WG into a per document debate which I 
> don’t for a moment believe there would garner their or others’ 
> approval.  However, I am happy to be proven wrong.

The fact that I went in a different direction than Joel and Brian does 
not render my comments invalid.   As I understand it, once there's a 
consensus, it takes a new consensus to change.  Lack of consensus leads 
to the status quo.  Which means that it might be hard to change back 
once we go down a particular path.  Changing this to a per document 
discussion prevents that and avoids treating all documents as requiring 
the same during the development process.   Just saying "initially" just 
kicks the can down the road for a decision that may materially affect 
the negotiation of the RSE contract.  See below.

> Where do you see that imposition being made?  What the text says is 
> that the WG will decide on its communication methods based on rough 
> consensus.

You again avoided addressing the second clause of my proposal - to wit 
that it requires the concurrence of the designated author/editor to 
impose a given editorial process on a given document. _*I anticipate 
that most of the documents in this stream will be authored  or edited by 
the hired expert.*_ I've not seen convincing discussion to the 
contrary.  Unlike a normal WG where an author who is faced with the 
prospect of having to edit via GITHUB can simply decline to offer their 
volunteer services, I would expect that the RSE would not have that option.

I note with interest the discussions taking place on the IETF list on 
the subject line "Old directions in social media" that is spot on this 
topic.

Or put it another way - do we expect the SOW will require the expert to 
have skills related to Github?   If the WG changes its "consensus" after 
the SOW is let or the expert is hired, will we expect the expert to 
conform to the WG consensus and learn a new tool set?

Later, Mike

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Jan 2021 15:32:52 -0800

On Wed, Jan 6, 2021 at 3:27 PM Michael StJohns <[email-masked]>
wrote:

> that it requires the concurrence of the designated author/editor to impose
> a given editorial process on a given document.  *I anticipate that most
> of the documents in this stream will be authored  or edited by the hired
> expert.*  I've not seen convincing discussion to the contrary.
>
I don't know what you would find convincing, but I don't anticipate this
nor do I think it's desirable.

-Ekr

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 06 Jan 2021 15:48:50 -0800

I'd like to point out (without quoting the conversation) that the goal
of this group is to get consensus by gather the opinions and thoughts of
everyone.  No thought should be left on the cutting room floor unless
there is consensus to do so.  However, to achieve consensus it does
require statements of affirmation or disagreement otherwise a statement
or suggestion by just 1 person does not a consensus make.

I do believe that anyone can create a pull request or an issue (unless
I've missed a WG direction somewhere), which is also a way to ensure
something doesn't get dropped.

-- 
Wes Hardaker
USC/ISI

---

From: Eliot Lear <[email-masked]>
Date: Thu, 7 Jan 2021 07:50:30 +0100

> On 7 Jan 2021, at 00:26, Michael StJohns <[email-masked]> wrote:
> 
> Inline
> 
>>> On 5 Jan 2021, at 20:01, Michael StJohns <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> That's your take away?  Do you actually disagree on your role here?  You made the dismissive comment on the list - it seems to me that the list is the right place to respond.
> 

If you have a problem with a chair’s behavior, take that up with the chairs or with their overseers. That’s what we tell people to do in a working group.  That’s what you should do here.

On being dismissive, my apologies for that.  What you proposed had just been objected to by EKR.  That is, he objected to text that would have stated a default position that required case-by-case decisions on how to use tooling.  The text you saw from me was an attempt to record the resolution to EKR’s concern that he and Joel found common ground on.  And as a reminder, it is proposed text.
> The fact that I went in a different direction than Joel and Brian does not render my comments invalid.   As I understand it, once there's a consensus, it takes a new consensus to change.  Lack of consensus leads to the status quo.  Which means that it might be hard to change back once we go down a particular path.  Changing this to a per document discussion prevents that and avoids treating all documents as requiring the same during the development process.   Just saying "initially" just kicks the can down the road for a decision that may materially affect the negotiation of the RSE contract.  See below.
> 

Thank you for commenting on the current proposed text. This group can comment on the substance of what you wrote, but so far, I see you in the rough as the only person objecting to the current proposed text, modulo whether we add an informational reference to RFC 8874.  Again, that is subject to others commenting.

> You again avoided addressing the second clause of my proposal - to wit that it requires the concurrence of the designated author/editor to impose a given editorial process on a given document.
> 

That presumes a case-by-case assessment, and this is not a simple editorial process, but how the group communicates.

> I anticipate that most of the documents in this stream will be authored  or edited by the hired expert.  I've not seen convincing discussion to the contrary.  Unlike a normal WG where an author who is faced with the prospect of having to edit via GITHUB can simply decline to offer their volunteer services, I would expect that the RSE would not have that option.
> 
> I note with interest the discussions taking place on the IETF list on the subject line "Old directions in social media" that is spot on this topic.
> 
> Or put it another way - do we expect the SOW will require the expert to have skills related to Github?   If the WG changes its "consensus" after the SOW is let or the expert is hired, will we expect the expert to conform to the WG consensus and learn a new tool set?
> 
> 
> 
The group can comment on the rest of this.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Sat, 9 Jan 2021 19:08:05 -0500

On 1/6/2021 6:32 PM, Eric Rescorla wrote:
>
>
> On Wed, Jan 6, 2021 at 3:27 PM Michael StJohns <[email-masked] 
>     You again avoided addressing the second clause of my proposal - to
>     wit that it requires the concurrence of the designated
>     author/editor to impose a given editorial process on a given
>     document. _*I anticipate that most of the documents in this stream
>     will be authored  or edited by the hired expert.*_ I've not seen
>     convincing discussion to the contrary.
>
> I don't know what you would find convincing, but I don't anticipate 
> this nor do I think it's desirable.
>
> -Ekr
>
Hi Ekr -

You should have no objection to my text as you think it will never come 
into play.  If you're right, it's an ignorable clause.

Basically, I'm trying to ensure that we don't try and micromanage a 
hired expert.

  * If the expert is just making pronouncements from the Mount rather
    than doing most of the document work, then your approach will work.
  * If the expert is doing most of the work, then forcing them into a
    document production model that they're not familiar with, that adds
    to their workload and adds to our costs should mostly be avoided.
  * If there's some balance,  forcing the hired person to adopt a
    particular work model is comes up against "a contractor decides how
    to accomplish an assignment" vs the model of an employee who can be
    told exactly how to accomplish an assignment and will definitely
    affect the contract negotiation (and may adversely affect the set of
    people willing to do the job).

For your question, what I would find convincing is a specific commitment 
from several volunteers with backing from their employers for some level 
of effort over the next 4 or so years adding up to at least 25% FTE 
cumulative.   I don't actually expect that level of commitment, nor for 
that matter much normal IETF participant interest in this set of 
problems once we complete this set of discussions.   It doesn't make 
anyone money and it doesn't directly impact shipment of products.

I could be wrong - but history suggests I'm not.

Later, Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 10 Jan 2021 08:00:00 -0800

On Sat, Jan 9, 2021 at 4:08 PM Michael StJohns <[email-masked]>
wrote:

> Basically, I'm trying to ensure that we don't try and micromanage a hired
> expert.
>
>    - If the expert is just making pronouncements from the Mount rather
>    - If the expert is doing most of the work, then forcing them into a
>    document production model that they're not familiar with, that adds to
>    their workload and adds to our costs should mostly be avoided.
>
> This is where I don't agree. The needs of the WG are more important than
the needs of the RSE, and if that adds to our costs, then so be it.

FWIW, to the extent to which we are concerned about unfamiliar production
models, I suspect that our bespoke production tools are a far greater
obstacle than Github.

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Sun, 10 Jan 2021 16:51:17 -0500

On 1/10/2021 11:00 AM, Eric Rescorla wrote:
>
>
> On Sat, Jan 9, 2021 at 4:08 PM Michael StJohns <[email-masked] 
>>     On Wed, Jan 6, 2021 at 3:27 PM Michael StJohns
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>         You again avoided addressing the second clause of my proposal
>>         - to wit that it requires the concurrence of the designated
>>         document. _*I anticipate that most of the documents in this
>>         stream will be authored  or edited by the hired expert.*_ 
>>         I've not seen convincing discussion to the contrary.
>>
>>     I don't know what you would find convincing, but I don't
>>     anticipate this nor do I think it's desirable.
>>
>>     -Ekr
>>
>     Hi Ekr -
>
>     You should have no objection to my text as you think it will never
>     come into play.  If you're right, it's an ignorable clause.
>
>     Basically, I'm trying to ensure that we don't try and micromanage
>     a hired expert.
>
>       * If the expert is just making pronouncements from the Mount
>         rather than doing most of the document work, then your
>         approach will work.
>       * If the expert is doing most of the work, then forcing them
>         into a document production model that they're not familiar
>         with, that adds to their workload and adds to our costs should
>         mostly be avoided.
>
> This is where I don't agree. The needs of the WG are more important 
> than the needs of the RSE, and if that adds to our costs, then so be it.

So what you're saying is that a random self-selected collection of IETF 
participants can not only tell a contractor what to do, but how to do 
it?  I note that the RSOC tried this, it wasn't a random self-selected 
collection,  and it didn't go well.    I don't believe this is viable.  
I also don't believe its in keeping with the discussions we've already had.

I any event, it's not the "needs of the WG" that are more important, but 
that the long term needs of the community should guide the WG and the 
RSE rather than the ephemeral demands of a few participants at a given time.

>
> FWIW, to the extent to which we are concerned about unfamiliar 
> production models, I suspect that our bespoke production tools are a 
> far greater obstacle than Github.

Not really.  I edit in Emacs XML mode, PHB (I think) has a tool to 
convert MS Word, you've got a Kramdown to XML tool.  I'm sure there are 
at least 3 or 4 others.    There's a great difference between "you must 
deliver documents that are in the form described by <xml2rfc etc>" vs 
"you must do all of your document production using Github and <pick a 
tool>  AND produce documents that are .... ".

Or horrors - "you must do all of your document production via Microsoft 
Teams and Word and must open an issue for each and every change you make 
to the document"

I actually think that whoever we get is not going to have all that much 
problem producing useful XML by whatever means.  Its also possible you 
can convince them that Github (or whatever flavor of the month we've 
moved on to in a few years) is a useful approach.   Who knows?  But 
let's avoid legislating this.

Later, Mike

---

From: Christian Huitema <[email-masked]>
Date: Sun, 10 Jan 2021 18:48:41 -0800

On 1/10/2021 1:51 PM, Michael StJohns wrote:
> So what you're saying is that a random self-selected collection of 
> IETF participants can not only tell a contractor what to do, but how 
> to do it?  I note that the RSOC tried this, it wasn't a random 
> self-selected collection,  and it didn't go well.    I don't believe 
> this is viable.  I also don't believe its in keeping with the 
> discussions we've already had.

As a matter of fact, the RSOC did *NOT* try to tell the RSE what to do.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jan 2021 16:29:21 +1300

> As a matter of fact, the RSOC did *NOT* try to tell the RSE what to do.

I think my best suggestion for this line of discussion is to stop it
as being rather unproductive. We have a lot of running code that tells
us that over-thinking procedures in advance leads to more harm than good.
I am bit at a loss to see what's wrong with saying "follow RFC 2418"
and leaving it to the people involved to take detailed procedural
decisions *when they need to be taken*. Who knows whether GitHub will
still be flavour of the month 5 years from now?

   Brian C

---

From: Michael StJohns <[email-masked]>
Date: Mon, 11 Jan 2021 18:32:15 -0500

> still be flavour of the month 5 years from now?

Hi Brian - the problem is that this isn't actually going to look much 
like a WG looks.  It probably won't have an WG style charter (with 
defined documents and an end date), it will need to last indefinitely, 
and it won't be homed to the IESG IRTF or IAB, and it will probably have 
the oversight body embedded in it (e.g. the stream managers plus a few 
others).  Among other things, we're going to have IETF funded 
participants (RSE and RPC and perhaps Jay), with defined 
responsibilities that may or may not collide with what the WG is doing.  
So saying just follow 2418 is going to require a bit of surgery on that 
document to make it apply to this process.

If all of you were willing to basically say that none of the WG process 
stuff applied to the RSE and RPC unless they agreed it did, I'd be fine 
with the compromise text.  And there must not be blowback if they decline.

But Ekr made it clear that he views the WG as having the ability to 
circumscribe and direct the RSE through consensus in ways that I think 
are problematic.

If you'd actually address the amount of authority you expect WG 
consensus to have over a contracted for individual or organization, and 
how that authority would interact with the contract oversight, we might 
be able to progress here.

Later - Mike

ps - I've got an appointment that conflicts with the call tomorrow.  I 
hope to catch the latter end of the call, but don't count on my attendance.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Jan 2021 14:15:41 +0100

Hi Mike,

Just on this point:

> On 12 Jan 2021, at 00:32, Michael StJohns <[email-masked]> wrote:
> 
> If you'd actually address the amount of authority you expect WG consensus to have over a contracted for individual or organization, and how that authority would interact with the contract oversight, we might be able to progress here.

The group has agreed (memorialized in Issue 4) that the LLC is legally & financially responsible for all contracts, but that doesn’t go quite so far as to address your point.  So let’s pull text from your draft:

   The search committee is responsible for creating the RFP and
   Statement of Work (SOW) documentation to fill the position of RSE,
   and for seeking the approval for the search to proceed from the LLC
   board.  Any proposed SOW is expected to consistent with the documents
   that set out the roles and responsibilities of the RSE.

Under the model we are now discussing, it is unclear who takes on this responsibility, and it is clear that we need to resolve the question.  I’ve opened Issue 25 on this point.

Eliot