Subject: Re: [Rfced-future] "oversees" [was Scope and IETF 108 proposals]

From: Brian E Carpenter <[email-masked]>
Date: Thu, 2 Jul 2020 10:10:28 +1200

> The LLC board should figure out who is to manage the RSE.

I think that's what philosophers call a 'category mistake'.

Obviously, if there is a formal contract for services between the LLC and the RSE, that contract will be administered by the LLC. But if the RSE is responsive to the community in one way or another, the LLC will not "manage" the RSE like a staff member or like an operational contractor. The RSE is a colleague, not a servant.

Regards
   Brian Carpenter

On 01-Jul-20 17:34, Nico Williams wrote:
> On Thu, Jun 25, 2020 at 11:14:48AM +1200, Brian E Carpenter wrote:
>> On 25-Jun-20 09:21, Peter Saint-Andre wrote:
>>> On 6/24/20 2:52 PM, Brian E Carpenter wrote:
>>>> On 25-Jun-20 03:17, Brian Rosen wrote:
>>>> ....
>>>>> 4. Is there some group that oversees the RSE?
>>>>> This seems to be answered in the affirmative.  If you disagree, please speak up.
>>>>
>>>> I'm allergic to "oversees" and "oversight" since we have running
>>>> code proof that we are incompetent at it, and our attempts have
>>>> decayed into micro-management. 
>>>
>>> I've seen this claim several times; can you provide evidence for it?
>>
>> Just the entire history of IASA version 1 and the IAOC doing the work
>> itself instead of overseeing the execution of the work. So far, the
>> LLC Board is doing much better, because it's constituted as a Board.
>> Also of course the recent history of the RSOC that led to Heather's
>> resignation. Engineers are bad at overseeing non-engineering
>> activities; we meddle in things we are no good at. (I don't except
>> myself from that statement, since I was IETF Chair at the time that
>> IASA was set up, and I know that I got far too interested in stuff
>> that shouldn't have been my business.)
> 
> This entire list's traffic feels like engineers doing things we're not
> good at.
> 
> Judging by just some of the posts I've read, we're having trouble:
> 
>  - defining the community the RSE is to be responsive to
>    (this feels surprising, but then it's not)
> 
>  - defining the business relationship between the RSE and the LLC
>    (employee vs contractor)
> 
>  - defining the management structure for the RSE
>    (who do they report to)
> 
> Perhaps we should step back a bit.
> 
> Regarding the business issues, can the LLC make a proposal in I-D form
> that we can review and debate?  Would that help?
> 
> FWIW, I believe that the employment nature of the RSE is not for us to
> decide, but for the LLC to decide, possibly based on the circumstances
> surrounding the individual selected as RSE (someone else stated a
> similar opinion, and I agree with them).  The LLC board should figure
> out who is to manage the RSE.
> 
> Definitely, *we* (IETF/IRTF/IAB) should define the community that the
> RSE is responsive to, though I agree it's difficult to define a
> community of RFC consumers who do not participate here.  Perhaps we need
> to make it easier for users to give us (or the RSE) feedback -- if
> mailing lists won't do, then maybe we need to find a better way for our
> users to communicate with us.
> 
> Looking at RFC5620's definition of the RSE role, I wonder how many of
> the RSE's responsibilities can be completed, then needing only
> maintenance.  E.g., the RFC Style Manual, can it be "done", and how much
> maintenance does it require?  Is the RSE a full-time job, or a part-time
> one?  If part-time, what eventualities might cause it to become a
> full-time one?  If we couldn't get an RSE appointed for a year or two,
> what would break, go wrong, or go undone?  Might we eventually not need
> an RSE, or might we find more responsibilities for the RSE?
> 
> The ISE role feels much more like a full-time role in the long term than
> the RSE.
> 
> FYI, I've stayed out of a lot of this, so I'm probably out of my depth
> here; it probably shows, and if so, well, sorry for the noise.
> 
> Nico
>

---

From: Jay Daley <[email-masked]>
Date: Thu, 2 Jul 2020 10:24:35 +1200

> On 2/07/2020, at 10:10 AM, Brian E Carpenter <[email-masked]> wrote:
> 

Without commenting on the appropriate role for the LLC (because that is for the community to decide) I must say that words such as "servant" are unnecessarily emotive and create a false dichotomy between any form of management and complete independence.  Everyone in any compensated IETF role has some form of "management" but it varies in style depending on the role, and what seems important here is to agree the style not reject the concept entirely.

Jay

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

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Jul 2020 18:07:42 -0500

On Thu, Jul 02, 2020 at 10:10:28AM +1200, Brian E Carpenter wrote:
> Obviously, if there is a formal contract for services between the LLC
> and the RSE, that contract will be administered by the LLC. But if the
> RSE is responsive to the community in one way or another, the LLC will
> not "manage" the RSE like a staff member or like an operational
> contractor. The RSE is a colleague, not a servant.

Perhaps, but if not the LLC there not many other choices.  You've
already said that the IETF/IRTF/IAB are not appropriate, and the RSOC
already failed (perhaps next time they wouldn't fail?).  Perhaps there's
only two real choices left:

 - don't have an RSE at all

 - make the RSE quite independent

The second choice would involve a mechanism for removal by the community
(and thence replacement), but otherwise the RSE would self-manage.

Hmmm, independence might work.

Implied in independence is continuity: as long as the RSE is not
screwing up they get to stay RSE as long as they want to.  I thought
Heather Flanagan was a very good RSE.  Continuity a year ago would have
served us well.

Nico
--

---

From: Christian Huitema <[email-masked]>
Date: Wed, 1 Jul 2020 18:00:53 -0700

> Obviously, if there is a formal contract for services between the LLC and the RSE, that contract will be administered by the LLC. But if the RSE is responsive to the community in one way or another…

Speaking of colleagues and servants is bringing in this debate an
emotional load that is perhaps unnecessary. People who report to
managers are still colleagues, accountability does not turn them into
servants.

Maybe we need to first agree on the future RSE role before defining
management structure. Listening to the discussion, I hear several
visions, with different scopes and different accountability requirements.

-- Christian Huitema

---

From: Michael StJohns <[email-masked]>
Date: Wed, 1 Jul 2020 22:00:01 -0400

On 7/1/2020 9:00 PM, Christian Huitema wrote:
> accountability does not turn them into servants

Hi Christian -

One of the problems is that I keep reading various discussions of 
"accountability" that seem to conflate that term with "control" or at 
least could be read that way.  So yes "servant".

As I've mentioned countless (sure - go ahead and count them...) times, 
my view of the role of RSE is one that's accountable to the community 
(and through the various payment and contract mechanisms, to whoever is 
paying them to the extent the contract or employment agreement or blood 
oath allows) for the role we set them, but is not under the day to day 
control (management/oversight/whining) of the community, nor the 
IAB/RSOC/IESG/IETF or for that matter the LLC.     E.g. someone like a 
CEO, Chief Scientist, CTO, Editor in Chief, Publisher, IAB chair, IETF 
Chair, IRTF Chair, IAD?

Maybe you can give a concise definition of what you mean by 
"accountability" that doesn't include the "control" aspect?

Later, Mike

---

From: Christian Huitema <[email-masked]>
Date: Wed, 1 Jul 2020 21:41:45 -0700

On 7/1/2020 7:00 PM, Michael StJohns wrote:
> (and through the various payment and contract mechanisms, to whoever
> is paying them to the extent the contract or employment agreement or
> blood oath allows) for the role we set them, but is not under the day
> to day control (management/oversight/whining) of the community, nor
> the IAB/RSOC/IESG/IETF or for that matter the LLC.     E.g. someone
> like a CEO, Chief Scientist, CTO, Editor in Chief, Publisher, IAB
> chair, IETF Chair, IRTF Chair, IAD?

Mike,

I understand that this is your vision. Not everyone agrees.

> "accountability" that doesn't include the "control" aspect?

A lot of what the RSE actually does amounts to project management, such
as for example "managing the deployment of the new RFC format".
Accountability here should be the classic accountability for project
management.

-- Christian Huitema

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Jul 2020 23:47:07 -0500

> visions, with different scopes and different accountability requirements.

RFC5620 defines the role of the RSE.  Agreeing on any change to that
else will require updating it.  Just sayin'.

My take, after Brian's response to my earlier post, is that we should
make the RSE independent, providing only a mechanism for the community
to remove the RSE, but not an RSOC, nor any manager or other management
structure.  The mechanism should not be too difficult to execute.  We
can probably debate such mechanisms for a while and reach consensus on
one.

RSE independence would have been very helpful a year ago.

An RSOC might still have a role to play advising the RSE, and if so,
too, as an initiator of RSE removal proceedings.

If Jon Postel is the model we want for an RSE, then we should want
independence, and continuity.  And if we can re-hire Heather, great!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Jul 2020 23:51:18 -0500

> as for example "managing the deployment of the new RFC format".

But that is practically on autopilot by now, isn't it?

> Accountability here should be the classic accountability for project

A mechanism for setting particular goals (update RFC 5620) and for
removing the RSE, should suffice.  That would give the RSE a great deal
of independence.  We're at this juncture because we didn't give the
previous RSE that independence.

Nico
--

---

From: Christian Huitema <[email-masked]>
Date: Wed, 1 Jul 2020 22:44:35 -0700

> previous RSE that independence.

My take is that we are at this juncture because the loose definition of
the role created mismatched expectations, and thus lots of frustrations.

I also do not believe that appointing someone on some kind of life
tenure matches the culture of the IETF. Mike compares the position to
other positions like IAB chair, IETF Chair, IRTF Chair, or IAD. These
are all volunteer positions. All are appointed for limited terms by the
nomcom, or in the case of the IRTF chair by the IAB. Adopting a similar
model for the future RSE might make sense. Anointing someone for life,
in my opinion, would just set us for conflicts and failure.

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Thu, 2 Jul 2020 11:26:49 +0200

Good evening, Mark,

> On 30 Jun 2020, at 03:46, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> The role that we are discussing is more that of the publisher than of the editor you describe.  A publisher sets standards for how copy appears, provides for distribution channels, insures appropriate cataloging, archiving, and similar services.  The RSE has had a role in all of the above over the past few years, under the auspices of RFC 8728’s predecessors.  Each of those aspects is likely to evolve over time.
> 
> I think the analogies we're using have reached the end of their usefulness; it would be better to make a clean break from them, and talk about the concrete responsibilities at hand.

Indeed, which is why I gave examples of concrete responsibilities that the RSE has taken on in the past.  It is not intended to be an exhaustive list.

> 
>> This group could decide to hardcode all of those aspects.  However, that would require returning to the community for changes whose implications we as a community may not be competent to understand.  Along these same lines, by way of example, do we want the RSE to have to come to the community for an RFC to approve a web site redesign?  I will hazard a guess: probably not.  None of us are UX people.
> 
> You're presuming a lot about the breadth of the community there. And, even if a particular skill is relatively rare in our community, it doesn't mean that we should design things to shut out their input.

I’m not entirely sure which presumption you think I’m making, so I will tell you ;-) I assert that our community largely does not consist of people with the requisite skills to perform the tasks I mentioned above.  Some of us may be able to oversee those who do have those skills.  To me, that is why we are here.  Let’s figure out the oversight.

>> While the RSE is one person or two might be an interesting question, here is another one: might that change over time based on the scale of the work?[*]  If that is the case, I suggest that the entity ultimately responsible for the series is the one who will be suited over time to make that call, and will need appropriate authority to do so.  I don’t think this group wants to hard code that but I am willing to be proved wrong.
> 
> To me, that suggests that we want the 'top' entity to be someone who's responsible, but willing to delegate; i.e., a position that is likely elected (or otherwise community selected) and NOT compensated. They can then source the expertise which needs to be compensated as appropriate.

My reading of the group was that the entity ultimately responsible for the series would not be the RSE, but whatever body to whom RSE is accountable.   Do I have that wrong?  This is why Brian asked some of the questions he did, about whether we agree that there is such a body.  It is true that we typically do not remunerate such groups.

> 
>> Let us also acknowledge the tussle here.  At the end of the day, the people in this room have to decide how much of their vision to encode now versus how much to entrust to some representation, either in the form of the RSE or the entities overseeing the RSE.  Recognize that the more we hard code now, the more will require review over time to keep current.
>> 
>> If you agree with the above, then we have but to create a structure to manage evolving visions over time, and highlight a handful of points that we wish to keep as invariants.
> 
> Agreed. We really need to stop fixating on the minutia of the series and look at the big picture here.

Yep.

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Thu, 02 Jul 2020 04:38:49 -0700

Hi Christian, Brian,
At 06:00 PM 01-07-2020, Christian Huitema wrote:
>>Obviously, if there is a formal contract for services between the 
>>LLC and the RSE, that contract will be administered by the LLC. But 
>>if the RSE is responsive to the community in one way or another, 
>>the LLC will not "manage" the RSE like a staff member or like an 
>>operational contractor. The RSE is a colleague, not a servant.
>
>managers are still colleagues, accountability does not turn them into servants.

If I am not mistaken, the term "emotional load" (which I was not 
familiar with) is when someone feels the need to suppress their own 
emotions.  My reading of Brian's message is that it is to illustrate 
a point, i.e. what is a colleague.

In general, a person who is being paid over $100,000 does not to be 
told what to do on a daily basis.  The person can either report back 
on a regular basis or else the entity he/she reports to can wait 
until the end of the contract to evaluate the results of the 
work.  Which alternative would you recommend?

Regards,
S. Moonesamy

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Jul 2020 05:09:39 -0700

On Thu, Jul 2, 2020 at 2:27 AM Eliot Lear <lear=[email-masked]>
wrote:

> I’m not entirely sure which presumption you think I’m making, so I will
> tell you ;-) I assert that our community largely does *not* consist of
> people with the requisite skills to perform the tasks I mentioned above.
> Some of us may be able to oversee those who do have those skills.  To me,
> that is why we are here.  Let’s figure out the oversight.
>

I don't agree with this.

1. I'm not sure I agree that this is the right set of tasks. The mere fact
that they have been done in the past does not make them right. That's why
I've been asking about requirements.
2. Just because our community largely does not consist of people able to
perform task X does *not* mean that the community as a whole is not able to
perform them. For instance, our community largely does not consist of
people able to design audio codecs or security protocols, and yet we were
able to deliver Opus and TLS.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Jul 2020 05:10:34 -0700

> least could be read that way.  So yes "servant".

Hmm.... Most people have employers and managers who determine their job
responsibilities, but I don't generally consider that anyone who does is a
"servant".

     E.g. someone like a
> CEO, Chief Scientist, CTO, Editor in Chief, Publisher, IAB chair, IETF

This is a pretty varied list of job functions. But generally, I would
expect a CTO or a Chief Scientist to have a manager who they are ultimately
accountable to. Senior people like that usually have a fair amount of
freedom about how to perform their job functions, of course, but that
doesn't mean they're not subject to management.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Thu, 2 Jul 2020 15:12:21 +0200

Eric:

> On 2 Jul 2020, at 14:09, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Thu, Jul 2, 2020 at 2:27 AM Eliot Lear <lear=[email-masked] <mailto:[email-masked]>> wrote:
> 1. I'm not sure I agree that this is the right set of tasks. The mere fact that they have been done in the past does not make them right. That's why I've been asking about requirements.

Which would you not have had the RSE do?  And, perhaps more importantly, do you believe you had the opportunity to say so at the time?  And perhaps even more importantly, how would you like to have the opportunity provide that input in the future, and how would you like your input processed?

> 2. Just because our community largely does not consist of people able to perform task X does *not* mean that the community as a whole is not able to perform them. For instance, our community largely does not consist of people able to design audio codecs or security protocols, and yet we were able to deliver Opus and TLS.

The E in IETF is Engineering and not Editing.  We attract engineers to standardize specifications.  In what way do you believe we attract people from the world of editing/publishing to incur the expense of participating?*

And you yourself did put forth a model under which you bring in expertise.  Remember your lawyer example.  At the risk of chasing analogies into the ground, do we want a general counsel version of an editor or someone who is attached to specific cases?  I think you want more of the latter.  Others want more of the former.

And most importantly, should we decide in this room what sort of expertise we need, or is a discussion that a standing committee should decide on an ongoing basis.  Do you have some feel for where that line should be?

Eliot

*I do indeed know of two publishers who each once attended an IETF meeting.  One was William Randolph Hearst III(**).  The other was the publisher of a magazine about the Internet that went bust.  So it’s happened.  I just don’t think it’s the norm.

**This is a very funny story, but more bar room material.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Jul 2020 11:23:17 +1200

Replying to two of Christian's points:

> On 7/1/2020 7:00 PM, Michael StJohns wrote:
...
> Accountability here should be the classic accountability for project

Yes, and I think we have learnt from the xml2rfcv3 project that
the publisher/editor skill set does not necessarily contain IT project
management. I would prefer that IT project management is *not* part of
the future RSE role.

On 02-Jul-20 17:44, Christian Huitema wrote:
...
> My take is that we are at this juncture because the loose definition of the role created mismatched expectations, and thus lots of frustrations.
> 
> I also do not believe that appointing someone on some kind of life tenure matches the culture of the IETF. Mike compares the position to other positions like IAB chair, IETF Chair, IRTF Chair, or IAD. These are all volunteer positions. All are appointed for limited terms by the nomcom, or in the case of the IRTF chair by the IAB. Adopting a similar model for the future RSE might make sense. Anointing someone for life, in my opinion, would just set us for conflicts and failure.

Agreed. Either the person is under contract (employee or consultant) or
it is like other I* leadership roles with a defined term. I wouldn't
exclude it being a volunteer role, assuming we do remove the IT project
management part. But in any case, it isn't for life.

Regards
   Brian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Jul 2020 11:49:17 +1000

> On 2 Jul 2020, at 11:12 pm, Eliot Lear <lear=[email-masked]> wrote:
> 

As discussed ad nauseam, our peer bodies (e.g., the W3C, WHATWG) don't have any 'people from the world of editing/publishing' involved in producing specifications, and yet they do just fine. Even if we do continue to need copy editors, it's not at all clear that we need 'people from the world of editing/publishing' to manage them, provide them guidance, or oversee the strategy of the series.

So I reject the premise that it's necessary to attract "people from the world of editing/publishing" to get our work done, or that they are so special / unique that they have to be both compensated and yet effectively unaccountable (which is the practical reading of 'independent').

> And you yourself did put forth a model under which you bring in expertise.  Remember your lawyer example.  At the risk of chasing analogies into the ground, do we want a general counsel version of…

This is an interesting analogy. Good counsel gives advice about the law and lets the client make the decision. Then, they represent the client's interests -- as instructed by that client -- vigorously. If the client is unhappy for any reason, they can get new counsel. There's also a ton of precedent around counsel that acted without sufficiently informing or consulting their client.

*If* we decide to bring in external resources, we should of course treat them as a professional, but we should also hold them accountable for doing their job.

Any professional I know would not mind that; they'd expect and appreciate it, provided that it was done in a well-defined and equitable way. Figuring out how that works is the task we have at hand.

> And most importantly, should we decide in this room what sort of expertise we need, or is a discussion that a standing committee should decide on an ongoing basis.  Do you have some feel for where…

I think that many have formed fairly strong antibodies towards standing committees that are closed. I keep coming back to the thought of having a standing pseudo-WG that allows the RSE (or whatever we call the person who fills the top role here) to consult with the community -- provided we can address the 'shape of community' problem adequately. Proposals for changes to the series can go through there, as can problems that require community attention. 

The point is to introduce some daylight -- upon the actions of the RSE role, those who act as oversight, and the community at large. If these interactions happen in public, I think we're much less likely to have the friction we've encountered in the past. 

The person filling that top role obviously needs to know how to effectively work with the defined community and its norms. Whether or not they need the much-discussed publishing expertise is not as obvious; if we do need it, it could be contracted and reporting into this person. Given that, I'd say we should define the position to be NOMCOM-selected with strong guidance to find someone able to build consensus in the (broader) community, and let them start a process to decide what resources are necessary.

Since such a role would be uncompensated, we'd need to pare off some of the responsibilities, but we have a good template -- the temporary role that John is currently filling could be turned into a standing contract.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 03 Jul 2020 11:59:09 +1000

On Thu, Jul 2, 2020, at 23:12, Eliot Lear wrote:
> The E in IETF is Engineering and not Editing. We attract engineers to 
> standardize specifications. In what way do you believe we attract 
> people from the world of editing/publishing to incur the expense of 
> participating?*

Given what I've been doing for the past N years, I'm not sure that I find the stark binary characterization here very flattering.

But I think that the "editor" label is another thing that is doing us a disservice in this discussion.  There are many meanings we are talking about:

* My contributions as "editor" of a specification are exactly the sorts of contributions that we expect people in the community to provide.

* The contributions of the RPC in finishing a document are exactly the sorts of contributions that we should expect to pay for.  That includes the copy-editing pieces and all the publication pieces.

* The point on which I think we have disagreement is regarding "editorial control" akin to the roles taken on by lead editors in journals or news publications.  That is, choices regarding content: what content to fund, what content to publish, and what content to promote.

Regarding this last one, I believe that Ekr's argument is that this function is largely done for us by the streams and not any RSE.  That being the case, I thoroughly agree.  Assuming [1] is an accurate reflection of the Nevil and Brian's views, then I think that this view has fairly wide support, aside from perhaps Mike, who has expressed support for an entity with greater control over content.

[1] Section 5 of Nevil's proposal here: https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html#name-independence-of-the-rse

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Jul 2020 15:13:48 +1200

Hi,

I wanted to answer Martin's message below and Mark's immediately previous one together:

Yes, the technical and copy editing functions are performed for us by the RFC production service. Nobody has suggested that the "RSE" does any of that, beyond setting strategy and editorial guidelines. (Technical and copy editors work within whatever guidelines the publisher gives them.)

Yes, as far as technical content goes, the streams are pretty good at what they do, and we've already apparently reached a rough consensus that the "RSE" has no veto on technical content.

But that's not all that the RFC series is. Like it or not, it's been around for 50 years and is not just a collection of technical specs. It also contains, and I hope will continue to contain, opinion pieces, operational observations and analyses, research results, dissents, roadmaps and more. It has, you might say, a life of its own.

The analogy with W3C or WHATWG publications seems to me to be just as false as those with newspapers or academic journals. It might apply to the IETF stream, but not to RFCs as a whole.

I think that the series needs a guide who is indeed independent of all the streams. Whether that guide is an individual, an individual supported by a Board, or a stand-alone NewOrg of some kind is secondary. Whether the guide is known as the RFC Series Editor or something else is secondary. But if we don't have such a guide, we'll end up with Brownian motion.

Regards
   Brian Carpenter

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 03 Jul 2020 14:56:57 +1000

On Fri, Jul 3, 2020, at 13:13, Brian E Carpenter wrote:
> But that's not all that the RFC series is. Like it or not, it's been 
> around for 50 years and is not just a collection of technical specs. It 
> also contains, and I hope will continue to contain, opinion pieces, 
> operational observations and analyses, research results, dissents, 
> roadmaps and more. It has, you might say, a life of its own.

Where is this diversity coming from, if not the streams?

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jul 2020 07:19:05 +0200

On 2020-07-03, at 03:59, Martin Thomson <[email-masked]> wrote:
> 
> But I think that the "editor" label is another thing that is doing us a disservice in this discussion. 

Yep.  German has the beautiful word “Herausgeber” (literally “forthgiver”).  

This is probably best translated as “publisher”, which unfortunately is not as selective a term (it is also used for the publishing house, so people use “editor” for the Herausgeber of a Journal etc.).

I would surmise that, since Germans tend to be familiar with the German term, they also have much less confusion about the role that we call “RSE” right now than English language speakers.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Fri, 3 Jul 2020 09:05:43 +0200

> Regarding this last one, I believe that Ekr's argument is that this function is largely done for us by the streams and not any RSE.  That being the case, I thoroughly agree.  Assuming [1] is an acc…

The chairs discussed this last week.  There is a very strong consensus (far better than rough) that people do not want the RSE to have final authority on whether a document may be published as an RFC, that problematic documents should be addressed informally or through the development process within a stream.

That consensus does not necessarily extend to other questions.  We have a lot of work to do, and that work will require imagination and cooperation amongst everyone to find more common ground.

Eliot

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jul 2020 10:25:31 +0200

On 2020-07-03, at 09:05, Eliot Lear <lear=[email-masked]> wrote:
> 
> There is a very strong consensus (far better than rough) that people do not want the RSE to have final authority on whether a document may be published as an RFC, that problematic documents should be addressed informally or through the development process within a stream.

Count me in the rough then.

Bad decisions based on group-think happen (1992).  Having a few places where people can simply say no can help against that.  Yes, having to do this because all formal and informal channels are exhausted will be a once-in-a-lifetime event then.

(Note the word “should” in the above statement: my position is not based on what should happen — it is easy to argue that it should never happen -, but what actually does happen in real-life organizations.)

Grüße, Carsten

---

From: Brian Rosen <[email-masked]>
Date: Fri, 3 Jul 2020 10:22:31 -0400

ISTM that we’re hearing the stream managers do this rather than the RSE.

Do you think that won’t work?  Why?

Brian

> On Jul 3, 2020, at 4:25 AM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jul 2020 17:45:43 +0200

> Do you think that won’t work?  Why?

Stream managers may be part of that group-think.

In the constitution of Germany, we have the position of a Bundespräsident that has been designed to be kept out of day-to-day political debates.  The main job, apart from representation, is signing documents into law.  If the Bundespräsident has a severe problem with a law (process or content), they don’t sign it.  That happens approximately once every decade.  In one case that I can remember, the Bundestag (parliament) had a majority (but no constitution-changing majority) that wanted to push through a law that would have been unconstitutional.  Now the courts likely would eventually have caught that, but the Bundespräsident saved us a lot of embarrassment and instability.  (The courts would also be used to fix an obstinate president, who also can be impeached.  None of this has ever happened.  What has happened, once, is that the constitution was changed with the necessary qualified majority and on that basis the previously questionable document was then signed into law by the president.  15 years later, that changed constitution helped the then president stop another ill-considered law...)

I don’t think we as an organization really have a good grasp of such once-a-decade events (1992 maybe is an exception, but mainly because it wasn’t solved within the “constitution” of the time but by a revolution).  Also, the sheer fact that a veto power exists tends to make certain events much less likely, so it may seem the veto power is not needed (“prevention paradox”).

Grüße, Carsten

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Jul 2020 12:03:51 -0400

On Jul 3, 2020, at 11:45 AM, Carsten Bormann <[email-masked]> wrote:
> If the Bundespräsident has a severe problem with a law (process or content), they don’t sign it.  That happens approximately once every decade.  In one case that I can remember, the Bundestag (parliament) had a majority (but no constitution-changing majority) that wanted to push through a law that would have been unconstitutional.

What would be an example of an RFC, approved for publication, which would be the analog of an unconstitutional law?

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 3 Jul 2020 17:07:31 +0100

Disclosure: I am a Stream Manager.

I would like some consistency across the streams. I would like a single point that at least coordinates, probably advises, and maybe acts to assure such consistency.

I would also like someone to stand behind the RPC when they express any concerns about the quality or publishability of a document so that it is not the RPC who has to handle any political or strenuous debate on the issue.

Cheers,
Adrian

-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of Brian Rosen
Sent: 03 July 2020 15:23
To: Carsten Bormann <[email-masked]>
Cc: [email-masked]; Eliot Lear <lear=[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: [Rfced-future] Scope and IETF 108 proposals

Brian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jul 2020 18:31:40 +0200

> What would be an example of an RFC, approved for publication, which would be the analog of an unconstitutional law?

Since we don’t have a constitution, that analogy is leaky.
We have pieces of foundational documents, e.g., for one aspect of the technology development we do, we have:

RFC 1984
RFC 3365 Section 6
RFC 7258
<draft-iab-for-the-users-04.txt> (not yet consensus)

These documents are all flawed and might have process issues (do we really have consensus?).  I probably should add RFC 1925, which doesn’t even purport to be a serious document.  On a more technical level, we also actively revisit some of our most deeply entrenched principles, say draft-iab-protocol-maintenance (and we don’t always succeed in writing up the newly emerging consensus).

So it seems we can’t hold the person with the veto power accountable to a specific document or set of documents.  That limits the value of the analogy.  But the fact that documents that the Bundespräsident considers unconstitutional (in process or content) do get approved by the Bundestag shows that these things happen even in much more formally controlled environments.

Grüße, Carsten

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Jul 2020 12:36:55 -0400

> These documents are all flawed and might have process issues (do we really have consensus?).  I probably should add RFC 1925, which doesn’t even purport to be a serious document.  On a more technic…

It sounds like you’re expecting the RSE to be able to decide whether or not a new document is consistent with these foundational documents. I suppose I wouldn’t mind if the RSE cried foul if the IETF consensus was to override e.g. RFC 1984, but it’s hard to see how a core responsibility of this sort could generalize.  E.g., what if the IETF wants to publish a document saying that IPv6 addresses are henceforth 64 bits instead of 128? Is the RSE the one who is supposed to say “no” when that happens?

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jul 2020 18:44:21 +0200

> It sounds like you’re expecting the RSE to be able to decide whether or not a new document is consistent with these foundational documents. I suppose I wouldn’t mind if the RSE cried foul if the IE…

I don’t know, and I think even the RSE wouldn’t know today.
But the RSE can talk to people, do their own judgment of what is going on in the community, and assess whether the damage of publication would far exceed the damage of non-publication.  It is hard to think your example to conclusion, because something must have mightily jammed before such a document comes out of the IESG, and it would become the job of the veto holder to do their own investigation how it came to that.

I’m sorry if this is a “I know it when I see it” definition, but such a backstop mechanism can’t be mechanical.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Fri, 3 Jul 2020 18:48:20 +0200

Two points:

First, I think we should close debate on this matter soon, unless Carsten finds a whole lot of support.

For the second, see below:

> On 3 Jul 2020, at 18:36, Ted Lemon <[email-masked]> wrote:
> 
> On Jul 3, 2020, at 12:31 PM, Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:

That is precisely what happened in 1992 or so, when Jon created a huge uproar when he dinked with a counter size in the ETHERNET-MIB.  It is true that all the intermediate checks failed at that point in time.  I will point out that it took someone with a large amount of technical expertise, experience, and probably no small amount of time to spot the error.  Would such a Bundespräsident be expected to be one person?

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Jul 2020 12:48:35 -0400

> I’m sorry if this is a “I know it when I see it” definition, but such a backstop mechanism can’t be mechanical.

Okay, then the “unconstitutional” analogy isn’t merely flawed, but actually wrong. What you are proposing here is more analogous to the Bundespräsident talking to representatives in the Bundestag and making a decision based on the urgings of the members with whom ze agrees.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jul 2020 18:57:36 +0200

> Okay, then the “unconstitutional” analogy isn’t merely flawed, but actually wrong. What you are proposing here is more analogous to the Bundespräsident talking to representatives in the Bundestag a…

I think you are underestimating the amount of interpretation that is needed to operate a constitution.

But, yes, wouldn’t it be nice if we had a firmer ground of testing things against the organization DNA.

Re Eliot:  I’m not sure I understand the example.  Veto power does not mean that it is mandatory to exercise it.  If the person wielding that is asleep at the wheel, has no way to gain insight at the level of atrocity being committed, is not told by people whose life will become miserable by it, the veto won’t happen.
If the entire world is deluded about something (historical example: ATM?), the veto power is not going to help.  A fresh look does, though.
(And, yes, the Bundespräsident does have staff that help them in that.  After all, this is a whole country.)

I only tried to announce that I’m in the rough; I didn’t want to relitigate the decision (and I apologize not having paid enough attention when the consensus apparently emerged).  So we will rely more on the appropriateness of certain group  decisions, then.  Let’s make education about group-think and “inevitable” decisions a part of our DNA.

Grüße, Carsten

---

From: Christian Huitema <[email-masked]>
Date: Fri, 3 Jul 2020 11:00:18 -0700

> So it seems we can’t hold the person with the veto power accountable to a specific document or set of documents.  That limits the value of the analogy.  But the fact that documents that the Bundesp…

Carsten,

The concerns that you raise were very much taken into account in the
1992 revisions of the process, and refined further since. The analogy to
laws applies mostly to IETF consensus publications, and to IAB
publications, and we have a controlled process for that in large part to
address concerns like yours. We have layers of approval before the
publication of IETF documents: working group last calls, IETF last
calls, IESG approval. We also have a review process for IAB documents,
and the appeal process happens there too. We do have an appeal chain,
all the way to the ISOC board of trustees. Inserting the RSE in that
process would be very disruptive, which explains the consensus against
that idea.

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jul 2020 11:13:42 -0700

On Fri, Jul 3, 2020 at 11:00 AM Christian Huitema <[email-masked]>
wrote:

> On 2020-07-03, at 18:03, Ted Lemon <[email-masked]> <[email-masked]> wrote:
>
> The concerns that you raise were very much taken into account in the 1992
> revisions of the process, and refined further since. The analogy to laws
> applies mostly to IETF consensus publications, and to IAB publications, and
> we have a controlled process for that in large part to address concerns
> like yours. We have layers of approval before the publication of IETF
> documents: working group last calls, IETF last calls, IESG approval. We
> also have a review process for IAB documents, and the appeal process
> happens there too. We do have an appeal chain, all the way to the ISOC
> board of trustees. Inserting the RSE in that process would be very
> disruptive, which explains the consensus against that idea.
>
I too find the enthusiasm for this idea somewhat surprising. The IETF
standards process has a set of mechanisms that at least in theory confer
legitimacy on those standards. To have the publishing venue somehow able to
veto those decisions would place us in the very odd position where the IETF
had consensus on a standard but it was not publishable as an RFC. To
continue with the government analogy, that would be like the US Congress
passing a bill, the President signing it, and the Government Publishing
Office refusing to publish it.

-Ekr

---

From: Jay Daley <[email-masked]>
Date: Sat, 4 Jul 2020 09:06:41 +1200

> On 4/07/2020, at 4:07 AM, Adrian Farrel <[email-masked]> wrote:
> 

This is an important point that I don’t want lost.  From a contractual perspective, the RPC role is that of a professional service organisation, which excludes any political or strenuous debate, and so if authors refuse to address RPC concerns then a third-party managed resolution process is needed. 

Jay

-- 
Jay Daley
IETF Executive Director

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 3 Jul 2020 22:47:43 +0100

Thanks Jay,

Historically, of course, the stream managers or their delegates (specifically shepherding ADs) have nearly always stepped up to champion what the RPC has said. But also, there has always been the RSE as a back stop, and I think (but we might need to get it confirmed) there has always been a free flow of consultation between the RPC and RSE to ensure the right things were said to the right people.

A

From: Jay Daley <[email-masked]> 
Sent: 03 July 2020 22:07
To: [email-masked]
Cc: [email-masked]
Subject: Standing behind the RPC (was: Scope and IETF 108 proposals)

On 4/07/2020, at 4:07 AM, Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Jay

-- 

Jay Daley
IETF Executive Director

---

From: "John Levine" <[email-masked]>
Date: 3 Jul 2020 18:17:42 -0400

In article <[email-masked]> you write:
>> The E in IETF is Engineering and not Editing.  We attract engineers to standardize specifications.  In
>what way do you believe we attract people from the world of editing/publishing to incur the expense of
>participating?*
>
>As discussed ad nauseam, our peer bodies (e.g., the W3C, WHATWG) don't have any 'people from the world of
>editing/publishing' involved in producing specifications, and yet they do just fine.

I think that WHATWG and W3C are as strange in their way as we are in ours.

I can assure you the IEEE and ANSI and pretty much any other standards
group you can think of has professional publishing staff involved in
their standards processes.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Jul 2020 11:15:11 +1200

Yes. I think this in and of itself is enough to justify the existence of an independent Series Editor supported by a Board that can use the wider community as a sounding board.

Regards
   Brian

On 04-Jul-20 09:47, Adrian Farrel wrote:
> *From:*Jay Daley <[email-masked]>
> *Sent:* 03 July 2020 22:07
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Standing behind the RPC (was: Scope and IETF 108 proposals)
> 
>  
> 
>  
> 
>     On 4/07/2020, at 4:07 AM, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Jul 2020 11:36:01 +1200

> Where is this diversity coming from, if not the streams?

Indeed, and where does editorial consistency across the streams come
from, if not from a Series Editor?

Note: That has nothing to do with a technical veto power. But it
does have to do with professionalism in an area that IETF engineers
are not qualified for.

> their standards processes.

Exactly. "publishing" not just copy-editing.

   Brian C

---

From: Jay Daley <[email-masked]>
Date: Sat, 4 Jul 2020 13:19:28 +1200

> On 4/07/2020, at 9:47 AM, Adrian Farrel <[email-masked]> wrote:
> 
> 
> Thanks Jay,
>  
> Historically, of course, the stream managers or their delegates (specifically shepherding ADs) have nearly always stepped up to champion what the RPC has said.

Does that include championing those parts of the overall publishing process that sit exclusively with the RSE/RPC, such as formatting or which xml tag to use?

> But also, there has always been the RSE as a back stop,

That’s sounds as if the stream managers are the main resolution mechanism with the RSE as the final escalation point - is that correct?

And one more question if I may, do the stream managers ever exert authority when championing the RPC ( ie “if you don’t do what the RPC asks then .your document doesn’t get approved”) or is that not possible, presumably because the stream manager has approved the document by that point and so has no levers to pull?

Jay

-- 
Jay Daley
IETF Executive Director

> and I think (but we might need to get it confirmed) there has always been a free flow of consultation between the RPC and RSE to ensure the right things were said to the right people.
>  
> A
>

---

From: Larry Masinter <[email-masked]>
Date: Fri, 3 Jul 2020 19:23:40 -0700

Brian C wrote
> Note: That has nothing to do with a technical veto power. But it does have
to
> do with professionalism in an area that IETF engineers are not qualified
for.

I disagree with the assessment that IETF engineers are not qualified 
to serve as RSE.  The ability to specify technical requirements that
can be translated by other engineers into implementations that meet
the specification is a key engineering skill. It isn't a skill you would
look for in the publishing industry or even technical journal editors.
 
However, certainly you'd look for someone who has read and
understood multiple RFCs, even if in coursework
https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-82
9-computer-networks-fall-2002/ 
https://online.stanford.edu/courses/soe-ynetworking-sp-introduction-computer
-networking 

Mark had some useful points about problems reading RFCs

https://www.mnot.net/blog/2018/07/31/read_rfc

which seem like opportunities for product improvement.

> Exactly. "publishing" not just copy-editing.

It points to a source of non-IETFers who might have more relevant experience

(not "professional publishing" experience but rather professional
staff involved in their standards publishing processes.)

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Jul 2020 14:39:19 +1200

On 04-Jul-20 14:23, Larry Masinter wrote:
> the specification is a key engineering skill. 

Larry, what makes you think that is part of the RSE's job? That's what happens
inside each stream, as far as I can see. That is emphatically not what the
Series Editor does, even under the existing RFCs.

    Brian

It isn't a skill you would

---

From: Eliot Lear <[email-masked]>
Date: Sat, 4 Jul 2020 08:13:33 +0200

> On 4 Jul 2020, at 03:19, Jay Daley <[email-masked]> wrote:
> 
> 
> 
>> On 4/07/2020, at 9:47 AM, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> Thanks Jay,
>>  

To my knowledge, it hasn’t come to that since the creation of the ISE.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 5 Jul 2020 12:08:14 +0100

Answering Jay while being a little puzzled that Brian and Eliot both mentioned the ISE in this discussion.

>> Historically, of course, the stream managers or their delegates
>> (specifically shepherding ADs) have nearly always stepped up to
>> champion what the RPC has said. 
>
> Does that include championing those parts of the overall publishing
> process that sit exclusively with the RSE/RPC, such as formatting or
> which xml tag to use?

I think that it does, although that issue typically doesn't come up much and when it dos the RPC is very flexible. (An example here might be the positioning of diagrams on paginated renderings of documents.)

The way that the "championing" works (should work) is that the stream head or delegate can say to the author, "Look, these people know what they are doing and are making good changes for the right reasons. Please cooperate to get the document published." I've seen that plenty of times, most often when someone's memory of the English they learned at school diverges from the RPC's style guide.

> That’s sounds as if the stream managers are the main resolution
> mechanism with the RSE as the final escalation point - is that correct?

Yes (he says, hesitantly).
We are mainly working as a group of professionals with a common aim, so issues are resolved through polite email conversations and formal escalation paths don't come into it.
You might say:
- RPC talks with authors
- Document shepherd or shepherding AD comes into discussion
- RSE comes into conversation

I think we have so rarely invoked a firm decision-making rule set beyond this open exchange of opinions, that it is hard to state precisely what those rules have been. (It would be easy to make up such a set of rules, but that is a different thing.)

> And one more question if I may, do the stream managers ever exert
> authority when championing the RPC ( ie “if you don’t do what the
> RPC asks then .your document doesn’t get approved”) or is that not
> possible, presumably because the stream manager has approved the
> document by that point and so has no levers to pull?

Well, s/approved/published/ in your quote, and then, yes.

For example, the shepherding AD has authority over changes made to an IETF stream document that are beyond style, layout, or simple editorial (and in particular, changes that modify the technical content). At the point where an author is complaining, the change has stepped outside those constraints. But, note that the author of an IETF stream document is the pen-holder, and has responsibility for carrying the consensus opinion into the document: they do not own the document.

The Independent Stream is slightly different in that the ISE has the role otherwise filled by the shepherding AD. Furthermore, the ISE chooses what is published on the stream.

Best,
Adrian

---

From: Eliot Lear <[email-masked]>
Date: Sun, 5 Jul 2020 15:00:19 +0200

Hi Adrian,

> On 5 Jul 2020, at 13:08, Adrian Farrel <[email-masked]> wrote:
> 

I put this in the context of the ISE because prior to the ISE existing, the RFC Editor *did* exert control as a function of the role, including the tweaking of at least one IETF stream RFC.  Since the the creation of the ISE, I have seen no indication that the RSE has ever attempted to exercise any sort of veto over any document coming from a stream.  Perhaps others have had different experiences since then.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 5 Jul 2020 14:39:54 +0100

Correlation is not causation?

-----Original Message-----
From: Eliot Lear <[email-masked]> 
Sent: 05 July 2020 14:00
To: [email-masked]
Cc: Jay Daley <[email-masked]>; [email-masked]
Subject: Re: [Rfced-future] Standing behind the RPC (was: Scope and IETF 108
proposals)

Hi Adrian,

> Answering Jay while being a little puzzled that Brian and Eliot both
mentioned the ISE in this discussion.

I put this in the context of the ISE because prior to the ISE existing, the
RFC Editor *did* exert control as a function of the role, including the
tweaking of at least one IETF stream RFC.  Since the the creation of the
ISE, I have seen no indication that the RSE has ever attempted to exercise
any sort of veto over any document coming from a stream.  Perhaps others
have had different experiences since then.

Eliot

---

From: "John Levine" <[email-masked]>
Date: 5 Jul 2020 12:14:40 -0400

>> process that sit exclusively with the RSE/RPC, such as formatting or

They talk to me about it all the time.

Generally it's clear what the desired result is and the question is what
is the best way to express it.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 Jul 2020 08:36:09 +1200

> I put this in the context of the ISE because prior to the ISE existing, the RFC Editor *did* exert control as a function of the role, including the tweaking of at least one IETF stream RFC.  Since…

I think that's right. Labelling the Independent stream rather than having a rather vague category of "stuff that doesn't fit anywhere else" was IMHO an important clarification and allowed a separation of some of the roles that wasn't possible before. Specifically, it created a category where there clearly is a single decision taker (the ISE) who is clearly distinct from the editing and publishing team. And by implication, that took away the single decision taker role from the RSE.

Regards
    Brian C

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 06 Jul 2020 11:15:00 +1000

On Sat, Jul 4, 2020, at 09:15, Brian E Carpenter wrote:
> Yes. I think this in and of itself is enough to justify the existence 
> of an independent Series Editor supported by a Board that can use the 
> wider community as a sounding board.

I think that it argues for having a supervisory role for the RPC empowered to negotiate with stream managers, but nothing more.

Let's say that someone working at the RPC had a conflict with an individual author that the two were unable to resolve.  I would expect the RPC management to provide their staff with support that they can rely on in these cases.  At places I've worked, if you have a recalcitrant customer, you talk to your manager and they either help you resolve the issue or they escalate with the customer's management.  In that case, this is the stream manager.  If management can't work something out, there is something seriously wrong [1].

So - at least to me - this doesn't imply anything about an RSE.  Unless you assume that an RPC won't be able to rely on having management.

The situation we have right now almost seems [2] like one where management is provided to the RPC.  And that is - at least in my experience - a little odd.  Having management of the supplier supplied by the customer is just strange.  While it is often the case that an organization tasks a specific person with oversight of an important supplier, that person still ultimately serves the customer's needs.  The way our current arrangement works has some very odd implications regarding who the person ultimately serves.

I understand the desire to have someone above all of this, but that person won't be a person the RPC can stand behind, because that person will hold other interests at a higher priority than those of the RPC.

Cheers,
Martin

[1] The ultimate recourse is, of course, termination of contract, which we might as well acknowledge.  It's painful and very much worth avoiding.
[2] I don't have a lot of visibility into the actual dynamics here, but I don't think that this characterization is entirely correct.  But this is what it looks like from my recent interactions.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Jul 2020 04:25:46 -0700

On Sun, Jul 5, 2020 at 6:15 PM Martin Thomson <[email-masked]> wrote:

> I think that it argues for having a supervisory role for the RPC empowered
> to negotiate with stream managers, but nothing more.
>
> Let's say that someone working at the RPC had a conflict with an
> individual author that the two were unable to resolve.  I would expect the
> RPC management to provide their staff with support that they can rely on in
> these cases.  At places I've worked, if you have a recalcitrant customer,
> you talk to your manager and they either help you resolve the issue or they
> escalate with the customer's management.  In that case, this is the stream
> manager.  If management can't work something out, there is something
> seriously wrong [1].
>

Indeed. Consider that in the present setting we already have Secretariat
staff (who at present work for the same company!) who have an opportunity
to interact with the IETF community and in fact arguably have more
opportunities for conflict. And yet we all expect the Secretariat to be
clearly subordinate to the LLC.

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Mon, 6 Jul 2020 13:13:45 -0400

On 7/6/2020 7:25 AM, Eric Rescorla wrote:
>
>
> On Sun, Jul 5, 2020 at 6:15 PM Martin Thomson <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I think that it argues for having a supervisory role for the RPC
>     empowered to negotiate with stream managers, but nothing more.
>
>     individual author that the two were unable to resolve.  I would
>     expect the RPC management to provide their staff with support that
>     they can rely on in these cases.  At places I've worked, if you
>     have a recalcitrant customer, you talk to your manager and they
>     either help you resolve the issue or they escalate with the
>     customer's management.  In that case, this is the stream manager. 
>     If management can't work something out, there is something
>     seriously wrong [1].
>
>
> Indeed. Consider that in the present setting we already have 
> Secretariat staff (who at present work for the same company!) who have 
> an opportunity to interact with the IETF community and in fact 
> arguably have more opportunities for conflict. And yet we all expect 
> the Secretariat to be clearly subordinate to the LLC.

Not exactly.   They contract to the IETF LLC as an organization, and 
they have both supervisors within the organization, and a point of 
contact/contract manager who works for the LLC (e.g. Jay).    
Contractors are not subordinate to those they contract with, neither 
"lower in rank or position" nor here "under the control or authority" of 
the LLC or IETF.    The relationship here is a partnership where the 
terms of that partnership are controlled by the terms of the 
contract.     The secretariat is not under the control  of the LLC, 
except to the extent that the LLC may choose to change the organization 
providing secretariat services or renegotiate the contract which 
describes how those services are provided.  Treating contractors as 
subordinates is somewhat how we got to this place.

I've had true subordinates (other military placed under my direction), 
employees (subordinate to the extent of company policy and HR 
directives), and contractors (~100s over many years).  None of the 
latter - which included Jon, Bob and Joyce at times - were ever 
"subordinate" to me or even to the US Government.

Martin's approach above might be useful, but it a) might require a 
contract change, and b) might cost $$ as the cost for a POC as he 
describes would necessarily be borne by the contract.  Right now, those 
costs are accounted for under the RSE contract.  I'd also note that for 
the legal purposes, the stream managers currently have no special 
standing.  That's not to say the RPC should ignore them, but they have 
no more authority over RPC direction than any random IETF participant.

Later, Mike

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Jul 2020 11:05:25 -0700

On Mon, Jul 6, 2020 at 10:13 AM Michael StJohns <[email-masked]>
wrote:

> Not exactly.   They contract to the IETF LLC as an organization, and they
> have both supervisors within the organization, and a point of
> contact/contract manager who works for the LLC (e.g. Jay).    Contractors
> are not subordinate to those they contract with, neither "lower in rank or
> position" nor here "under the control or authority" of the LLC or IETF.
> The relationship here is a partnership where the terms of that partnership
> are controlled by the terms of the contract.
>
I can see you objecting to the term "subordinate", and while I think you're
wrong here, I don't think we need to overindex on it.

However "partnership" is also wrong. The Secretariat is a vendor and the
LLC is a customer. And while the terms of that relationship are set out
under the terms of the contract, the details of the performance necessarily
involve a fair amount of detailed direction from the LLC and the IESG. For
example, see the sections of the contract around Administrative Manager
service (2 and 3), which lists general duties but in practice the way those
duties is performed will be determined by the customer (even before you get
to "escape hatch" clauses like 2(b)(ii)14.

-Ekr

---

From: Jay Daley <[email-masked]>
Date: Tue, 7 Jul 2020 07:24:27 +1200

> On 7/07/2020, at 6:05 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Mon, Jul 6, 2020 at 10:13 AM Michael StJohns <msj@nthpermutation..com <mailto:[email-masked]>> wrote:
>> On Sun, Jul 5, 2020 at 6:15 PM Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
>> Indeed. Consider that in the present setting we already have Secretariat staff (who at present work for the same company!) who have an opportunity to interact with the IETF community and in fact arguably have more opportunities for conflict. And yet we all expect the Secretariat to be clearly subordinate to the LLC.
> Not exactly.   They contract to the IETF LLC as an organization, and they have both supervisors within the organization, and a point of contact/contract manager who works for the LLC (e.g. Jay).    Contractors are not subordinate to those they contract with, neither "lower in rank or position" nor here "under the control or authority" of the LLC or IETF.    The relationship here is a partnership where the terms of that partnership are controlled by the terms of the contract.  
> 
> I can see you objecting to the term "subordinate", and while I think you're wrong here, I don't think we need to overindex on it. 
> 
> However "partnership" is also wrong. The Secretariat is a vendor and the LLC is a customer. And while the terms of that relationship are set out under the terms of the contract, the details of the performance necessarily involve a fair amount of detailed direction from the LLC and the IESG. For example, see the sections of the contract around Administrative Manager service (2 and 3), which lists general duties but in practice the way those duties is performed will be determined by the customer (even before you get to "escape hatch" clauses like 2(b)(ii)14.

That is spot on.  The work of the Secretariat is wide ranging and the interaction between the LLC/IESG and Secretariat is across the full spectrum from high-level low-touch to low-level high-touch. The latter is because the LLC is deliberately lightweight with only two staffers and so the Secretariat provides the admin support that would otherwise be provided by a staffer.

I personally think the  word 'contractor' is key here as that is very well understood (at least in the US context) to mean a person/organisation that is instructed on "what to do" but not "how to do it".

Jay

> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Jul 2020 14:39:37 +1200

On 07-Jul-20 07:24, Jay Daley wrote:
> 
> 
>> On 7/07/2020, at 6:05 AM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>

Yes. And that's clearly exactly what we expect for the RPC. I think the difficulty we have here is about how the RSE role can be defined with the right blend of independence and a defined "what to do" while also staying out of the RPC contract management path. Stated like that, it's almost consultancy.

    Brian