Subject: [Rfced-future] Scope and IETF 108 proposals

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Jun 2020 11:43:55 -0400

Hello all

First of all, I am honored and delighted that the IAB chose me to co-chair this group.  I think this work is critical to the IETF, and I look forward to working with you all to make it successful.  

Eliot and I have been talking about scope.  I’m a believer in limiting scope as a primary way to make sure we can finish in a reasonable time: unlimited scope projects finish in infinite time.  Of course, the converse is not always true, but the narrower the scope generally helps to focus effort and get projects finished in reasonable time.

We would like to propose that we, for now, limit our scope to the RSE role, process and oversight, and not consider the RFC series itself in scope.  That means accepting the reality that things like what the series is for, and who owns it remain undefined.  We’ve managed to work with that ambiguity for a long time, and we think we can define the RSE role, process and oversight well enough without fixing those issues.  

We don’t propose that this scope limit is necessarily permanent: if it gets in our way, we can revisit it, and if we finish the RSE issues quickly enough and there is desire to work on series issues, we can do that.  But for now, we propose to limit our scope. As we complete the structural work, we can choose to delegate the evolution of the series or portions of it to that structure, or we can take up that work here ourselves.

This is a proposal.  We’ll look for consensus on this proposal.  If we don’t have consensus, we’ll deal with the wider scope.  Your comments would be appreciated.

We have also been discussing what our agenda for IETF 108 should be.  We would like to have a series of questions that focus our discussions at the meeting.  In some cases we could have consensus on answers, but in most, we just hope to get a sense of where the workgroup is a the present time.

Our list of questions is:
1. Should the RSE be a hired employee or a contracted entity?
2. Who hires/contracts the RSE?
3. For the purposes of day to day management, to whom does the RSE report?
4. Is there some group that oversees the RSE?
5. If the answer to 4 is yes, how is the board constituted?
6. Who defines the process that the RSE follows?  This group?  The Board?  The RSE defines it themselves?
7. Can the RSE decide to not publish a document one of the stream editors forwards to it?  If so,  on what grounds?

We want to know from you is: are these the right questions?  Are there work group members who would be willing to make straw-man proposals that could be presented and discussed at the meeting?

Brian

---

From: Michael StJohns <[email-masked]>
Date: Mon, 22 Jun 2020 12:12:31 -0400

Hi Brian - welcome.   Comments in line.

> 1. Should the RSE be a hired employee or a contracted entity?

Trivial question.  Either is a reasonable approach, but hired employee 
generally means some sort of full time engagement.  In this case, the 
RSE has generally been a 1/2 time commitment.  Its unclear if this will 
change anytime soon.

> 2. Who hires/contracts the RSE?

Default: LLC board or a business organization under the LLC board.  I 
think any argument to the contrary would have to be exceedingly strong.  
If we move this to a much more independent organization with a broader 
focus, then going back to ISOC as the hiring entity might be a good choice.

> 3. For the purposes of day to day management, to whom does the RSE report?
The RSE reports to themselves on an day-to-day basis.  This is not a 
position that requires managerial injection on other than the big things 
- e.g. contract formation and contractual compliance.   In other words, 
the question assumes that the RSE requires day to day oversight, and 
that's a push-poll formulation.
> 4. Is there some group that oversees the RSE?
See above, but the answer as asked is no.  There is some group that 
works WITH the RSE to oversee the RFC series.  That group does not have 
management oversight over the RSE contract or the RSE.
> 5. If the answer to 4 is yes, how is the board constituted?
As I suggested - stream managers plus some number of community selected 
folks who are acceptable to the RSE (e.g. actually have something useful 
in the publication space to say ).
> 6. Who defines the process that the RSE follows?  This group?  The Board?  The RSE defines it themselves?

Poorly framed.    In the final analysis, the process is what the RSE 
contract says - it legally can't be any other way.   The input to the 
contract may include (directly or indirectly) community input, LLC 
input, board (5) input, or stream manager either through discussion, or 
the promulgation of RFCs that change the standards for what the RFC 
series is and how RFCs are published. Continuing that - the general 
formulation for contractors in the US is that you can tell them what to 
do, but not how to do it. That translates into specifying what we want 
as a result, and letting the RSE figure out how (e.g. the "process" or 
at least one piece of the process) to get us there.

> 7. Can the RSE decide to not publish a document one of the stream editors forwards to it?  If so,  on what grounds?

AIRC, there is only one stream editor - the ISE.  The rest are stream 
managers.  E.g. the others don't execute any editorial control over the 
content they forward - all that happens in the WGs and LC process.

In any event, the answer is yes, and the ISE gave the best example - a 
document that requires too much editing by the RPC to bring it to 
publication standards.  The ISE case was a non-native English author and 
syntax and structure that was non-standard English.   There may be other 
reasons.  In any event, this is not a "never publish the document" but 
"this document in its current state does not meet the standards of the 
series".  As I suggested previously, this may be better handled as an 
RSE recommending and the RFC Editorial Board deciding rather than just 
the RSE doing this unilaterally.

> We want to know from you is: are these the right questions?  Are there work group members who would be willing to make straw-man proposals that could be presented and discussed at the meeting?

Already done.    I was told it was too early to be coming up with 
proposals for how the management worked.   Maybe we're there now?

One possibly important question:  What do we want the RSE to do?   I 
*think* that's a key question.   For me "husband and evolve the RFC 
series as an internationally relevant series of publications of 
technology and standards" or something along those lines.   Very high 
level statement of what we (I) want vs "publish 1000 RFCs a year".

Later, Mike

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Jun 2020 18:18:29 +0200

> On 22 Jun 2020, at 18:12, Michael StJohns <[email-masked]> wrote:
> 
> AIRC, there is only one stream editor - the ISE.  The rest are stream managers.  

Good catch.  s/stream editor/stream managers/

Sorry about that.

Eliot

---

From: Bob Hinden <[email-masked]>
Date: Mon, 22 Jun 2020 10:36:41 -0700

Brian,

Thanks for taking on this role.

My answer to your questions below.

Bob

> 1. Should the RSE be a hired employee or a contracted entity?

I don’t think that is the right question.    There are two parts, should the RSE be an individual or say a group, and how should they be employed.

I think the RSE should be an individual, not a group.

How they are employed is a separate question and will depend on the person.  The LLC could hire them as a full or part time employee, or the LLC could hire them as a contractor.

> 2. Who hires/contracts the RSE?

LLC.  No other group in the IETF has the ability to hire/contract, as far as I can tell.

> 3. For the purposes of day to day management, to whom does the RSE report?

It’s a senior leadership position, so essentially they report to the community.   Like other senior IETF roles.

> 4. Is there some group that oversees the RSE?

What Mike St.Johns said.  I think that is about right.

> 5. If the answer to 4 is yes, how is the board constituted?

ditto

> 6. Who defines the process that the RSE follows?  This group?  The Board?  The RSE defines it themselves?

I think the start point is RFC 8728 and RFC 8729.   Perhaps the question should be what needs to change.

> 7. Can the RSE decide to not publish a document one of the stream editors forwards to it?  If so,  on what grounds?

Yes, if there are serious problems with a document.   But I like the idea Mike St. Johns proposed about having the RFC Editorial Board be involved in this and not having the RSE doing it in isolation.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 22 Jun 2020 18:44:48 +0100

> LLC.  No other group in the IETF has the ability to hire/contract,

Which might mean that this was the wrong question, too.

It could be "Who recruits/interviews/selects/appoints the RSE?"

Cheers,
Adrian

---

From: Christian Huitema <[email-masked]>
Date: Mon, 22 Jun 2020 10:57:19 -0700

> 6. Who defines the process that the RSE follows?  This group?  The Board?  The RSE defines it themselves?

I think that particular question is not well framed, but I also think
there is a need for some oversight. Nobody should be set up as some kind
of king.

Take the example of evolving the format of the RFC series, which falls
neatly into the RFC responsibility. The experience shows that such
changes affect how the RFC are produced and how they are consumed.
Suppose that the RFC editor proposes a change that makes RFC harder to
write, because in his or her opinion it will make them easier to read by
some of the target audience. There are bound to be a variety of opinions
about whether the change is right or not. How do we achieve consensus?
How do we gauge consensus? Is there an appeals process?

If that's the kind of questions that you have in mind by stating
"process that the RFC follows", then yes I believe it is in scope. But
maybe we need to clarify a bit.

> We want to know from you is: are these the right questions?  Are there work group members who would be willing to make straw-man proposals that could be presented and discussed at the meeting?
-- Christian Huitema

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 23 Jun 2020 21:49:10 +1000

> that's a push-poll formulation.

This is a very narrow definition of "management" that pretty much reads as "the RSE doesn't need micro-management so they don't need management". A manager is also someone who advocates for their managees and provides a human connection which is somewhat important here. If we treat management as purely "contractual compliance" of the "you hit the RSE with a stick when they don't meet their SLA" variety, that's not a very good management structure.

Who does the RSE tell that they're sick and taking a couple of days off to recover? Who do they check in with when they have an issue or dispute with someone else in the organisation, and want support or even just a second opinion?

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 23 Jun 2020 21:54:55 +1000

Yikes - I find myself replying to this a second time!

> RSE has generally been a 1/2 time commitment. Its unclear if this will 

Hiring part time employees is totally a thing everwhere I've been. 2 days/week, 3 days/week, whatever. I don't think the idea that it's not a 100% FTE role excludes it from being an employee role.

But... clearly this is not a trivial question because...

> at least one piece of the process) to get us there.

You clearly pre-suppose the answer to question 1 in your answer to question 7!

This question can be raised up a level to "we don't have a contract yet, who's gonna set the terms".

I can see the argument for: if the answer to 1 is contractor, then the answer is "whoever writes the contract", which then makes this question: "Who decides what's in the contract? This group? The Board? The RSE writes it themselves?". It's still a necessary question in that framing.

Bron.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 23 Jun 2020 11:36:13 -0400

On 6/23/2020 7:49 AM, Bron Gondwana wrote:
> This is a very narrow definition of "management" that pretty much 
> reads as "the RSE doesn't need micro-management so they don't need 
> management".  A manager is also someone who advocates for their 
> managees and provides a human connection which is somewhat important 
> here.  If we treat management as purely "contractual compliance" of 
> the "you hit the RSE with a stick when they don't meet their SLA" 
> variety, that's not a very good management structure..
>
> Who does the RSE tell that they're sick and taking a couple of days 
> off to recover?  Who do they check in with when they have an issue or 
> dispute with someone else in the organisation, and want support or 
> even just a second opinion?

Contractor vs employee differences.   The RSE generally has tasks and 
the contract spells out things like what happens in "unforeseeable 
circumstances" such as getting sick.  Since the RSE has in the past been 
about 50% FTE, sliding things a few days or even a week is rarely going 
to be a critical hit to the process.

Contractors don't have managers in the same way that employees do.  They 
have points of contact, and an entity that holds the other end of the 
contract.  At one point in my career, I held something north of 30 
contracts and I *never* ever felt the need to call up one of my 
contractors and explain what they needed to do that day.   Had I tried, 
the contracting officer and the contract POC would have been within 
their rights to slap me down hard.

The RSE has to be thinking about more than a single person's  (or even a 
designated small group's) opinion and paying attention to broader things 
than "a [single] human connection".  I'm not sure if you've ever met any 
of the former RSEs, but I was honored to be a friend and colleague to 
each of them (and in one case was their "contracting entity" for a 
period of time).  None of them ever had a problem connecting with the 
IETF collectively or individually, nor did any of them require anyone to 
advocate for them - they were perfectly capable of doing that for 
themselves with very good results.

If all you want is a task rabbit in the RSE role, you could make a case 
along the lines you've sketched, but I think hiring plug replaceable 
RSEs would be a Bad Idea (tm).

Later, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Jun 2020 10:48:44 +1200

Hi,

Welcome Brian R.

I've intentionally answered below without reading the resulting thread. (I will shortly proceed to read the thread.)

> First of all, I am honored and delighted that the IAB chose me to co-chair this group.  I think this work is critical to the IETF, and I look forward to working with you all to make it successful.  

...critical to the IRTF and the RFC-consuming community too. This is not just an IETF effort.

> We would like to propose that we, for now, limit our scope to the RSE role, process and oversight, and not consider the RFC series itself in scope.  That means accepting the reality that things lik…

I fully understand the desire to limit the scope. I do however still believe that without having a common view of the underlying principles of the series, we'll have trouble reaching a common view of the RSE role. Hence, section 3.1 of https://tools.ietf.org/html/draft-carpenter-rfc-principles-01, which is of course open to comments and disagreements.

> 1. Should the RSE be a hired employee or a contracted entity?

It's a detail. The important aspect IMHO is what section 3.2 of my draft says:

       The RFC Series Editor, while paid to serve the community, is a
       member of the same professional peer group as IAB members, IESG
       members, IETF and IRTF group chairs, and other experienced
       members of the technical community, each with their own distinct
       professional skills.

> 2. Who hires/contracts the RSE?

Again, it should be a detail, but I think we should argue the pros and cons of 3 options:
   -  ISOC (because this isn't an IETF function)
   -  IETF LLC (because they are handy and own the RPC contracts)
   -  NewOrg (a dedicated entity for the RFC Series)

> 3. For the purposes of day to day management, to whom does the RSE report?

I think the answer is nobody, except for whatever is legally and financially required as a result of the answer to the previous question.

> 4. Is there some group that oversees the RSE?

I believe that our experience with the IAOC and RSOC has shown our incompetence at "oversight" (where "our" means the pool of engineers we usually call on for such jobs). But we must have some form of community responsibility. So yes.

> 5. If the answer to 4 is yes, how is the board constituted?

To a first approximation, a board such as Mike St Johns proposed seems correct.

> 6. Who defines the process that the RSE follows?  This group?  The Board?  The RSE defines it themselves?

As today, the RSE defines general policy, subject to Board approval. Only the Board should no longer be the IAB, but the one in point 5. The IAB Charter will need an update.

The RSE should define their own process details autonomously. But of course, as today, the RSE may choose to appoint an advisory group.

> 7. Can the RSE decide to not publish a document one of the stream editors forwards to it?  If so,  on what grounds?

I think we already discussed that enough to see that there's a split of opinion. My personal opninion is no, the stream manager can insist, but in such a case the RSE may include a disclaimer of their own choice.

Missing question:

8. To what extent does the RSE have direct control over the RPC and RFC Publisher entities, which are under contract to the LLC?

I can see a wide range of answers to this, ranging from simple persuasion to full control, somewhat linked to question 2 above.

> We want to know from you is: are these the right questions?  Are there work group members who would be willing to make straw-man proposals that could be presented and discussed at the meeting?

I'm willing to update the relevant bits of draft-carpenter-rfc-principles, or hand them over to this group as a separate draft, if preferred. I don't plan to attend the meeting if it's in the Madrid timezone.

Regards
     Brian C

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Jun 2020 11:15:04 +1200

below...

On 24-Jun-20 03:36, Michael StJohns wrote:
>> This is a very narrow definition of "management" that pretty much reads as "the RSE doesn't need micro-management so they don't need management".  A manager is also someone who advocates for their managees and provides a human connection which is somewhat important here.  If we treat management as purely "contractual compliance" of the "you hit the RSE with a stick when they don't meet their SLA" variety, that's not a very good management structure..
>>
> Contractor vs employee differences.   The RSE generally has tasks and the contract spells out things like what happens in "unforeseeable circumstances" such as getting sick.  Since the RSE has in the past been about 50% FTE, sliding things a few days or even a week is rarely going to be a critical hit to the process.
> 
> Contractors don't have managers in the same way that employees do.  They have points of contact, and an entity that holds the other end of the contract.  At one point in my career, I held something north of 30 contracts and I *never* ever felt the need to call up one of my contractors and explain what they needed to do that day.   Had I tried, the contracting officer and the contract POC would have been within their rights to slap me down hard.
> 
> The RSE has to be thinking about more than a single person's  (or even a designated small group's) opinion and paying attention to broader things than "a [single] human connection".  I'm not sure if you've ever met any of the former RSEs, but I was honored to be a friend and colleague to each of them (and in one case was their "contracting entity" for a period of time).  None of them ever had a problem connecting with the IETF collectively or individually, nor did any of them require anyone to advocate for them - they were perfectly capable of doing that for themselves with very good results. 
> 
> If all you want is a task rabbit in the RSE role, you could make a case along the lines you've sketched, but I think hiring plug replaceable RSEs would be a Bad Idea (tm).

Right. That's why I suspect that legally speaking this will be a contracted role rather than an at-will employee role, and it will not be a role where counting hours per week or PTO will be appropriate. You cannot buy RSE services by the square cubit. But as Mike originally said, and so did I, it's a detail. It does seem to me that the RSOC got this wrong and we must avoid making the same mistake. Let's get the bigger questions settled - what is the RSE role and how does the RSE answer to the community as a whole?

Regards
   Brian C

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Jun 2020 16:19:00 -0700

> 3. For the purposes of day to day management, to whom does the RSE report?

[no hats, since I haven't asked what others think about this subject]

One additional detail that I'd love to hear about related to the above
three questions: what are we going to do about contract temporal terms,
renewals, etc?  The discussions about the above are great, but
regardless of the model chosen: there will always the need to specify an
appointment length and what renewal terms might be (with the caveat that
an appointment length "until death or they quit", like the U.S. supreme
court may remove the need for a renewal clause).  Since this issue is
one of the reasons why this group was formed, it sure seems like it
should be on the agenda (again: IMHO).

-- 
Wes Hardaker
USC/ISI

---

From: "John Levine" <[email-masked]>
Date: 23 Jun 2020 19:27:42 -0400

>Hiring part time employees is totally a thing everwhere I've been. 2 days/week, 3 days/week,
>whatever. I don't think the idea that it's not a 100% FTE role excludes it from being an employee
>role.

Agreed. I'm a contractor but I were hired for a larger role without a
definite end-date, I'd think about being an employee.  Half-time employees
certainly are common here in the U.S.

I suggest we strike this question as a detail the LLC can deal with if
and when it arises.

-- 
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: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jun 2020 00:48:04 +0100

Hiya,

Not just answering John, but more generally...

> I suggest we strike this question as a detail the LLC can deal with if

I don't think this is the first thing to try figure
out, but... I do not like the idea of the RSE being
an employee. I'm convinced it would be a bad plan if
we decided that in general it is better for the RSE to
be an employee. Deciding that the RSE can never be an
employee would be almost as bad.

Where I live, an RSE-as-employee would mean that, were
the RSE re-appointed twice to the role, then that person
would have the job indefinitely, until the job role is
done away with via redundancy. IMO that's a fine bit of
labour law, but not what we want for this role.

And in case it's not clear, the problem is: if we did
decide that the RSE has to be an employee, then we would
be restricting our choices to people who live in places
with (what I perceive to be) less desirable labour
laws.

I think this means we ought not try answer this question
now. First decide who picks and why, then do that, and
only then figure out what kind of contract makes sense.

Perhaps the one bit of this question we could answer now
might be to conclude: "we do not want to limit the kind
of contractual arrangement between the LLC and RSE - the
LLC ought figure out whatever kind of contract meets the
needs of the community." (Or something like that.)

Cheers,
S.

PS: I'm also kind of allergic to the LLC building up it's
headcount - that ought not be a goal.

---

From: Jay Daley <[email-masked]>
Date: Wed, 24 Jun 2020 13:30:44 +1200

Brian

> On 23/06/2020, at 3:43 AM, Brian Rosen <[email-masked]> wrote:
> 
> Hello all
> 

Unless I’ve missed it, I don’t believe there has been any clear problem statement, which I would suggest should be a pre-requisite before moving to design a framework for the solution.

My summary of the high-level problem statement is

1.  We do not have a strategy for the RFC series.

2.  We do not have a process for creating a strategy for the RFC series.  

3.  We do not have a "process for determining how well the series is meeting its objectives and serving the wide variety of audiences it is intended to serve" [1]

Point 2 seems to be the one that all of the proposed solutions revolve around.  It is clearly within the purview of the RSE to establish the process for creating a strategy [2] but unfortunately my involvement began too late to analyse why that either didn’t happen or did happen but was unsuccessful.  While this is a sensitive topic, it needs to be tackled without getting personal to only pull out the elements necessary to understand if there is a structural issue that requires a structural solution or something else

Jay

[1]  https://mailarchive.ietf.org/arch/msg/rfced-future/2PpDfGNyICpimKbpaLIsBQwYbrc/
[2]  https://tools.ietf.org/html/rfc8728#section-2.1

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Jun 2020 21:46:34 -0400

Point 3 seems to imply that there is some “we” that could have consensus on where the series is meeting its objectives. This might sound like a nit, but I suspect there is a wide diversity of opinion on this topic. 

> On Jun 23, 2020, at 21:30, Jay Daley <[email-masked]> wrote:
> 
> Brian
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Jun 2020 15:11:26 +1200

On 24-Jun-20 13:30, Jay Daley wrote:
> Brian
> 
>> On 23/06/2020, at 3:43 AM, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hello all
>>

That's really why I started on draft-carpenter-rfc-principles. I don't see it as a problem statement, though. The RFC Series doesn't have an existential problem; what it has is a lack of clearly written principles.

> 3.  We do not have a "process for determining how well the series is meeting its objectives and serving the wide variety of audiences it is intended to serve" [1]

Sure. But that has always been assumed to be part of the RSE's job. Our job here, as I understand it, is to define the RSE's role and how they are appointed.

> Point 2 seems to be the one that all of the proposed solutions revolve around.  It is clearly within the purview of the RSE to establish the process for creating a strategy [2] but unfortunately my…

IMNSHO the main challenges were (a) the job of overseeing the xml2rfcv3 introduction became rather all-consuming; (b) the RSOC fell into the same micro-management trap as the IAOC did; and possibly (c) the IAB didn't act like the kind of advisory board that the RSE (like any series editor) needs.

Regards
   Brian C

>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Jun 2020 15:17:42 +1200

> needs of the community." (Or something like that.)

Indeed. The universe of possibilities is wider than just employee
versus contractor. Just to invent another one, imagine that a
large university decides it would be a Good Thing to have
a faculty member do the job, for a few years, as long as the
university is compensated accordingly. That isn't far-fetched,
but it really is a detail in the big picture.

    Brian C

---

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Jun 2020 23:50:54 -0700

Hi Brian,
At 08:43 AM 22-06-2020, Brian Rosen wrote:
>First of all, I am honored and delighted that the IAB chose me to 
>co-chair this group.  I think this work is critical to the IETF, and 
>I look forward to working with you all to make it successful.

I would like to congratulate you on your appointment.

>We have also been discussing what our agenda for IETF 108 should 
>be.  We would like to have a series of questions that focus our 
>discussions at the meeting.  In some cases we could have consensus 
>on answers, but in most, we just hope to get a sense of where the 
>workgroup is a the present time.
>

Question 3 is about "day to day management".  In general, an 
employee/contracted entity is not managed on a day to day basis if 
he/she is not in a junior position.  I suggest removing the first 
part in that question.

Regards,
S. Moonesamy

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 24 Jun 2020 17:54:01 +1000

> 1. Should the RSE be a hired employee or a contracted entity?

I have a third option, inspired in part by Jay's abstraction (paraphrased: "we need a process for setting RFC Series strategy").  This is the same comment I made at one of the recent interim meetings.  I also owe part of this insight to the RSOC who had the insight to separate the strategic and operational functions of the RSE role.

We don't need a single person (or contracted entity, if that includes more than one person) to be given the task of determining strategy.  If we need a strategy to serve our community, then maybe that community should setting and owning that strategy.  Not indirectly, via an appointed custodian, but directly.

I've watched the discussion here and observed that there is a lot of depth when it comes to questions at the strategic level.  I think that we've all be consciously holding back, but when I look at things like draft-carpenter-rfc-principles I can't help but see an attempt to formulate strategy (as opposed to process for strategy).  FWIW, I think that's OK, because the shape of a process has an effect on strategy.

Setting strategy is different than execution of the same.  I've thoughts on that, but they are less well formed.  That is a place where expert outside help might be good.

There are likely areas in which we develop strategic blind spots as a result of developing strategy in this way.  I would contend that this is more readily identified when open participation is permitted than when a single individual is given exclusive responsibility for the task.  There are likely other adjustments required to compensate for the effect of the wisdom of crowds as well.

I just wanted to float this.  I know that it probably opens up a whole bunch of different questions than those that our chairs have provided us.  But after I recognized that I was assuming the RSE to be a single entity, I just can't stop seeing how pervasive that assumption is.  We don't have to accept that assumption into our design.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 24 Jun 2020 11:17:38 -0400

We appreciate all the thoughtful comments we have seen so far.

Skipping, for the moment, the scope proposal and concentrating on the questions:
1. Should the RSE be a hired employee or a contracted entity?
Many commenters think this is a detail, but needs to be decided.  We can likely wrap this up quickly, and probably on-list.  There are those who just say “contract”, some that say “oh, part time employee is fine” and others that say, “just leave it up to the entity in question 2”.  Please offer your thoughts on this if you haven’t already.  

2. Who hires/contracts the RSE?
Also seems like we can likely wrap this up quickly on-list.  I sense the current direction is the LLC.  Brian offered some options.  If you think it should be some entity other than the LLC, please speak up.

3. For the purposes of day to day management, to whom does the RSE report?
Most commenters seem to think this is not a good question because the answer is: they don’t need day to day management.  Bron thought everyone needs “some” management even if it’s “I’m sick and won’t be working for a few days”.  Whatever the answer to 2 is, there is some management there, but probably there is more to be considered.  Let’s keep discussing this a bit.

4. Is there some group that oversees the RSE?
This seems to be answered in the affirmative.  If you disagree, please speak up.

5. If the answer to 4 is yes, how is the board constituted?
Most commenters liked Michael’s suggestion.  If you disagree, please speak up.

6. Who defines the process that the RSE follows?  This group?  The Board?  The RSE defines it themselves?
Here we have a lot of different opinions, and we probably need to spend some time at the meeting discussing this.  The question of strategy before process came up which we also need to figure out.

7. Can the RSE decide to not publish a document one of the stream editors forwards to it?  If so,  on what grounds?
I sense that we’re close on this, but details matter.  I sense that there is support to allow the RSE to hold up a document if the RSE doesn’t feel that it is readable, but that that control is fairly limited.   

There were a couple of other suggested questions:
A. What do we want the RSE to do?   
B. Is the RSE an individual or a group?
C. Who recruits/interviews/selects/appoints the RSE?
D. What should the appointment length/renewal terms be?

Several commenters said things along the lines of “poorly worded question”.  Other than the above, please suggest actual rewrites of the question that would be better in your opinion.

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Jun 2020 08:52:33 +1200

On 25-Jun-20 03:17, Brian Rosen wrote:
...
> 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. So I think the consensus position is more like:

The RSE is responsible to the community, and there is a community group to which the RSE answers.

   Brian C

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Jun 2020 08:59:28 +1200

On 25-Jun-20 03:17, Brian Rosen wrote:

> Many commenters think this is a detail, but needs to be decided.  

I think it should *not* be decided in advance. I think it should be decided according to the individual circumstances of a particular nominee for the job. So yes, see next question...

> We can likely wrap this up quickly, and probably on-list.  There are those who just say “contract”, some that say “oh, part time employee is fine” and others that say, “just leave it up to the entity in question 2”.  Please offer your thoughts on this if you haven’t already.  
> 

By default, it would be the LLC, certainly. A much wider question would be whether a new entity should be considered, let's call it the RFC Foundation for the sake of argument, but I think that is clearly out of scope for this group.

   Brian C

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Jun 2020 09:09:59 +1200

> We don't need a single person (or contracted entity, if that includes more than one person) to be given the task of determining strategy.  If we need a strategy to serve our community, then maybe t…

I don't understand how that would work in the absence of a group and a group leader to determine what the community is (since it's not the IETF) and what the community's rough consensus is. Who would they be? In my book, the RSE and the RFC Series Board.

But yes, there are two roles here, if not three:

1. The policy/strategy lead, including determining community consensus.
2. The technical lead, at least until the v3 transition is truly complete.
3?. Operations lead, in so far as that isn't the LLC's job.

> I've watched the discussion here and observed that there is a lot of depth when it comes to questions at the strategic level.  I think that we've all be consciously holding back, but when I look at…

Sure, but that draft is just me waffling as background for defining the RSE role.

> Setting strategy is different than execution of the same.  

Absolutely. We should certainly discuss whether we expect one person to handle all these roles.

   Brian C

> I've thoughts on that, but they are less well formed.  That is a place where expert outside help might be good.
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 24 Jun 2020 15:21:26 -0600

[ no hats ]

On 6/24/20 2:52 PM, Brian E Carpenter wrote:
> ....
> 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?

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Jun 2020 11:14:48 +1200

> 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.)

Regards
   Brian

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 25 Jun 2020 09:43:04 +1000

On Thu, Jun 25, 2020, at 07:09, Brian E Carpenter wrote:
> I don't understand how that would work in the absence of a group and a 
> group leader to determine what the community is (since it's not the 
> IETF) and what the community's rough consensus is. Who would they be? 
> In my book, the RSE and the RFC Series Board.

I don't think that is necessarily the case.

The process that we're following has the same requirements and challenges.  It has leadership.  Two leaders in fact, which is more than twice as good as relying on a single person.  It has open participation.  (I don't know what RFC Series Board is, but it implies a closed group, just as RSE implies an individual.)

Speaking strictly about strategy, the structure of what we have here is just about as good as we will get in all the ways that matter.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 25 Jun 2020 09:27:03 +0100

[As an individual]

> On 24 Jun 2020, at 16:17, Brian Rosen <[email-masked]> wrote:
> 

I’m not sure I have sufficient knowledge of employment law around the world to state an opinion. Certainly the implications of the different choices seem to vary depending where the RSE is located. That suggests that the right answer might depend on circumstances.

> Also seems like we can likely wrap this up quickly on-list.  I sense the current direction is the LLC.  Brian offered some options.  If you think it should be some entity other than the LLC, please…

I agree the employment/contracting relationship should be with the LLC.

The question of who interviews/appoints the RSE is much harder, and perhaps more interesting.

> Most commenters seem to think this is not a good question because the answer is: they don’t need day to day management.  Bron thought everyone needs “some” management even if it’s “I’m sick and won…

The RSE should be considered a reasonably senior role, so close day-to-day supervision seems unnecessary. Most senior roles have some management and reporting chain though, and I expect the same would be true of the RSE.

> This seems to be answered in the affirmative.  If you disagree, please speak up.

I agree there should be some oversight.

> Most commenters liked Michael’s suggestion.  If you disagree, please speak up.

Michael summarised his proposal as "stream managers plus some number of community selected folks who are acceptable to the RSE”. I agree that giving the stream managers a role makes sense. I also agree that having community selected members is a good idea, but I don’t agree that being "acceptable to the RSE” should be a criteria. Having person being overseen approve members of the oversight committee does not lead to effective oversight.

What sort of oversight is envisaged will likely affect the structure of the board, and whether a new board is needed or if the oversight can be conducted by an existing body. 

> Here we have a lot of different opinions, and we probably need to spend some time at the meeting discussing this.  The question of strategy before process came up which we also need to figure out.

I’m not sure this is a well-defined question, since it assumes there’s a singular process. 

> I sense that we’re close on this, but details matter.  I sense that there is support to allow the RSE to hold up a document if the RSE doesn’t feel that it is readable, but that that control is fai…

I’d argue that the RSE should be able to push back, perhaps quite strongly, and say “this is too poorly written to publish”, but ultimately the RSE should not have a veto on editorial grounds.

I’d argue that the RSE does not have the right to veto publication on technical grounds. If they object on such grounds they can comment, and appeal against publication, in the same way as any other member of the community, but have no special right as RFC Editor.

I’d argue that there should be a policy defining what is inappropriate content for the RFC series (e.g., hate speech, obscenity, indecency, etc.), how it should be handled, and when/if the RSE can refuse publication on such grounds. That seems like something to be agreed between the RSE and the community in some consensus document.

There will certainly be legal restrictions on what the RFC series can publish. The community needs to understand those. 

-- 
Colin Perkins
https://csperkins.org/

---

From: Eliot Lear <[email-masked]>
Date: Thu, 25 Jun 2020 10:30:08 +0200

Hi Colin

> On 25 Jun 2020, at 10:27, Colin Perkins <[email-masked]> wrote:
> 

I am going to hazard a guess, and Mike should feel free to correct me, that he did not mean for the RSE to choose those who would themselves oversee the role.  I would agree with you that that seems somewhat circular.

Eliot

---

From: Colin Perkins <[email-masked]>
Date: Thu, 25 Jun 2020 09:43:58 +0100

> On 25 Jun 2020, at 09:30, Eliot Lear <[email-masked]> wrote:
>> On 25 Jun 2020, at 10:27, Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
>> 

I expect so – I agree Mike's more detailed proposal is clearer than his summary here.

Having re-read the detailed proposal, there are many aspects I disagree with, along with some potentially good ideas. At this stage, though, it doesn’t seem that we have agreement on what type of oversight is needed, or what are the problems with the existing oversight mechanism, so it seems premature to be designing an alternative.

-- 
Colin Perkins
https://csperkins.org/

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Jun 2020 02:18:11 -0700

Hi Brian, Peter,
At 04:14 PM 24-06-2020, Brian E Carpenter wrote:
>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.)

The IAOC membership included the following:

   IETF Chair
   IAB Chair,
   Internet Society CEO

If what Brian mentioned is correct, it would mean that the persons in 
those positions did not understand the meaning of overseeing the 
execution of the IASA work.  If the RSOC did not do its work 
correctly, it would mean that the IAB appointed the wrong 
people.  One of the differences between the [IA,RS]OC and the LLC 
Board is that the latter is a legal entity.  I doubt that setting up 
a legal entity would solve a "meddling" problem.

Peter asked for evidence.  There isn't any information to 
substantiate an assertion that the RSOC were not fulfilling the role 
it was assigned.  However, there is one matter; it is usually known 
as soft skills.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Jun 2020 11:44:46 +1200

On 25-Jun-20 20:27, Colin Perkins wrote:
...
> I’d argue that the RSE should be able to push back, perhaps quite strongly, and say “this is too poorly written to publish”, but ultimately the RSE should not have a veto on editorial grounds.

I think it's a bit more subtle. The pushback, when it happens, is more like "this is too poorly written for the RPC to be able to copy-edit it effectively". In other words, the authors need to get it turned into comprehensible, if faulty, English. It's a case that amounts to a failure by the stream manager - such a draft should never have got near the RFC Editor in the first place. So this really is an RPC issue, not an RSE issue.
 
> I’d argue that the RSE does not have the right to veto publication on technical grounds. If they object on such grounds they can comment, and appeal against publication, in the same way as any othe…

Agreed. Except possibly the right to include a disclaimer. 

> I’d argue that there should be a policy defining what is inappropriate content for the RFC series (e.g., hate speech, obscenity, indecency, etc.), how it should be handled, and when/if the RSE can…

Sure, so not an issue for this group, except to note it.

> There will certainly be legal restrictions on what the RFC series can publish. The community needs to understand those.

Ditto.

Regards
    Brian C

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Jun 2020 12:02:13 +1200

On 25-Jun-20 21:18, S Moonesamy wrote:
> execution of the IASA work.

I think we very quickly started suffering from the problems that the LLC
structure was designed to solve, but at the time the priority was to get
the work of the IETF Secretariat under the IETF's own control. If that
meant getting directly involved, so be it. Before the IAD was employed,
the IETF Chair was effectively acting as line manager for the Secretariat
staff, and believe me, the IAOC/IAD structure was a major improvement
on that within a couple of weeks. All the same, you are correct, right
from the start the IAOC did not limit itself to oversight. As I said,
engineers love to meddle.

> If the RSOC did not do its work 
> people. 

No, I think the problem was that we set up a two-headed management
structure, with both the RSOC and the RSE believing they were in
charge. We need to avoid that problem this time around.

> One of the differences between the [IA,RS]OC and the LLC 

I think we have running code proof that it has already done so.
I see things working more smoothly than before, and the LLC Board
is sticking to its role.

> it was assigned.  However, there is one matter; it is usually known 

Sure. But even that can't help when there is real ambiguity about
the chain of responsibility.

Regards
   Brian C

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Jun 2020 10:24:32 +0300

On 2020-6-26, at 2:44, Brian E Carpenter <[email-masked]> wrote:
> The pushback, when it happens, is more like "this is too poorly written for the RPC to be able to copy-edit it effectively". In other words, the authors need to get it turned into comprehensible, if faulty, English. It's a case that amounts to a failure by the stream manager - such a draft should never have got near the RFC Editor in the first place. So this really is an RPC issue, not an RSE issue.

+1

I was only stream manager for six years or so, but I cannot recall *ever* hearing of such a case, on any stream. That puts this into the "can be dealt with by sane people if it should ever occur" bucket, in other words, I don't think it's worthwhile to come up with policy here.

Lars

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Jun 2020 09:43:51 -0400

> On Jun 25, 2020, at 7:44 PM, Brian E Carpenter <[email-masked]> wrote:
> 

My understanding is that the PRC is very reluctant to send back documents.  In my opinion, the RSE needs to help set the expectations for both the stream managers and the RPC.

> Agreed. Except possibly the right to include a disclaimer. 

This overlaps with the above point.  The distinction between editorial and technical can be blurred if one is trying to block a document.

+1

+1

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Jun 2020 09:46:06 -0400

> On Jun 26, 2020, at 3:24 AM, Lars Eggert <[email-masked]> wrote:
> 

Yes, this has happened.  It is infrequent, but we have seen a few documents where the list of questions from the RPC was longer than the Internet-Draft.

Russ

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Jun 2020 20:37:03 +0300

Your memory is better than mine :-)

But was there ever any contention as to what the right thing to do would be?

My meta point is that I see this effort drifting in a direction where super-detailed “guidance” is desired/proposed, which I am not sure is going to be all that helpful down the road.

This particular discussion is an example of that. Even without an explicit veto right, an RSE can escalate to “if you make me publish this, I will walk”. On the flip side, if an RSE uses an explicit veto right and the broader community disapproves, they can get that RSE fired.

There are implicit checks and balances in place that force everyone to find mutual agreeable solutions, without us defining an awful lot of detailed policy.

-- 
Sent from a mobile device; please excuse typos.

> On Jun 26, 2020, at 16:46, Russ Housley <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jun 2020 08:11:17 +1200

> My understanding is that the PRC is very reluctant to send back documents.  In my opinion, the RSE needs to help set the expectations for both the stream managers and the RPC.

Yes, certainly. We don't want the RPC to be put in such a situation.

> This overlaps with the above point.  The distinction between editorial and technical can be blurred if one is trying to block a document.

It can be. But there is a big difference between the RFC Editor saying "we cannot determine whether this text means 1 or 0, please clarify" and "we think this text means 0 and we think it should mean 1". The former is editorial but the latter is an attempt to override the stream.

    Brian

> .

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Jun 2020 16:18:58 -0400

> On Jun 26, 2020, at 4:11 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I understand the point, and I agree with it.  Content should fall squarely on the shoulders of stream managers.

Russ

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 26 Jun 2020 16:32:20 -0400

> It can be. But there is a big difference between the RFC Editor saying "we cannot determine whether this text means 1 or 0, please clarify" and "we think this text means 0 and we think it should me…

of course, this is coming that Jon did - but it is not all that likely that the IETF (or whomever) will hire another Jon
to take this role

Scott

---

From: Larry Masinter <[email-masked]>
Date: Fri, 26 Jun 2020 14:09:10 -0700

I think if you're trying to come up with a job description for the RSE,
and you want it to be someone you can hire, the more skills and tasks and decision responsibilities you add, the harder it will be to find someone who would take such a job or contract.

>From that perspective, having the ability to resign in disgust  is not a job perquisite.

So what if the relationship between the RSE and the various streams were to change,
To reduce the complexity of the task to either saying "Yes, this meets the RFC Editor
publication guidelines" or "No, it does not", with some but not necessarily exhaustive
reasons why.  It could even be a TL;DR kind of review; specs that are hundreds
of pages are impossible to review. 

Call this the RED: RFC Editor Decision.

Streams can submit documents and request "No RED" and have their document published
as an RFC with a disclaimer written by the RFC editor inserted.

Otherwise, the RFC will get published as is or sent back to the stream.

This moves the task so that it is clear that the RFC editor doesn't
have a place for technical decisions, that the responsibility
for insuring clarity of the ideas goes to the streams and not the
RFC Editor.

More like technical journal publishing and less like book
or magazine publishing.

It avoids the situation where the RFC editor corrects something that
seems grammatical, but winds up choosing the wrong fix.

Might need to have an automated step to handle "Note to RFC Editor" text.

--
https://LarryMasinter.net https://going-remote.info

---

From: Nevil Brownlee <[email-masked]>
Date: Sat, 27 Jun 2020 15:01:09 +1200

Hi Martin:
I've updated my Internet Draft to include a suggestion of what an RSEB (RFC
Series Editorial Board) could be structured.  Take a look at
https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html

Of course, any suggestions for changes/improvements/etc to that draft are
welcome :-)

Cheers, Nevil

On Thu, Jun 25, 2020 at 11:43 AM Martin Thomson <[email-masked]> wrote:

> > > We don't need a single person (or contracted entity, if that includes
> more than one person) to be given the task of determining strategy.  If we
> need a strategy to serve our community, then maybe that community should
> setting and owning that strategy.  Not indirectly, via an appointed
> custodian, but directly.
> >
> The process that we're following has the same requirements and
> challenges.  It has leadership.  Two leaders in fact, which is more than
> twice as good as relying on a single person.  It has open participation.
> (I don't know what RFC Series Board is, but it implies a closed group, just
> as RSE implies an individual.)
>
> Speaking strictly about strategy, the structure of what we have here is
> just about as good as we will get in all the ways that matter.
>
> --

-- 
-----------------------------------
Nevil Brownlee, Taupo, NZ

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jun 2020 16:22:24 +1200

Hi Nevil, I noticed a few places where you typed "RSEB" instead of "RSAB". Apart from that I'm in general agreement with the proposal.

Maybe it's too specific to define the community discussion venue as "the rfc-interest list". For the breadth of community the RSAB would need to reach, other methods of discussion may also be needed.

Regards
   Brian

On 27-Jun-20 15:01, Nevil Brownlee wrote:
> Hi Martin:
> I've updated my Internet Draft to include a suggestion of what an RSEB (RFC Series Editorial Board) could be structured.  Take a look at https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html
> 
> Of course, any suggestions for changes/improvements/etc to that draft are welcome :-)
> 
> Cheers, Nevil
> 
> On Thu, Jun 25, 2020 at 11:43 AM Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > > We don't need a single person (or contracted entity, if that includes more than one person) to be given the task of determining strategy..  If we need a strategy to serve our community, then maybe that community should setting and owning that strategy.  Not indirectly, via an appointed custodian, but directly.
>     >

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 29 Jun 2020 09:47:08 +1000

On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote:
> I've updated my Internet Draft to include a suggestion of what an RSEB 
> (RFC Series Editorial Board) could be structured. Take a look at 

This is very much not what I had in mind.  We should not insist on having a role that depends on finding an individual with a rare and difficult combination of attributes.  And I don't think that you can support that function by taking a program with open participation and consensus processes and reduce that to 5 people (+stream manager ex officio) who are responsible for approving strategy.

Perhaps you can start by explaining why you think we need to have an individual perform these functions.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 28 Jun 2020 19:50:35 -0400

In my view, the reason we need a person to do this is that leadership by 
committee is essential equivalent to a recipe for disaster.  And I do 
think we want leadership.

Yours,
joel

---

From: Michael StJohns <[email-masked]>
Date: Sun, 28 Jun 2020 20:14:37 -0400

On 6/28/2020 7:50 PM, Joel M. Halpern wrote:
> In my view, the reason we need a person to do this is that leadership 
> by committee is essential equivalent to a recipe for disaster. And I 
> do think we want leadership.
>
> Yours,
> joel

Strong +1 here.   One of the reasons for having a senior person in this 
role is so that the attention paid to the strategic evolution of the 
series does not wax and wane based on the current hobbyhorses of the 
leadership or their companies,  or upon other loud voices.   I have no 
problems with those voices influencing strategy, but I have strong 
problems with those voices directing strategy - especially if they 
change directions every 6 months or a year.

We've had at least 4 people with the "rare and difficult" [Aside: 
difficult?] combination of attributes so I'm not sure where Martin is 
coming from here.   It may be that he doesn't agree that those are the 
right attributes for the role, but that's a whole other discussion.  I 
would expect with some luck, and with an IETF that _*respects*_ what an 
expert can bring to the role, we will be able to find someone who won't 
run screaming into the night after they meet us.

Mike

>> This is very much not what I had in mind.  We should not insist on 
>> having a role that depends on finding an individual with a rare and 
>> difficult combination of attributes.  And I don't think that you can 
>> support that function by taking a program with open participation and 
>> consensus processes and reduce that to 5 people (+stream manager ex 
>> officio) who are responsible for approving strategy.
>>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Jun 2020 10:23:42 +1000

The suggestion was to have more than one more specialised role, not to promote 'leadership by committee.' This has been discussed a number of times previously, due to the very high bar created by the combination of requirements we current place on the position (as Martin mentioned).

> On 29 Jun 2020, at 10:14 am, Michael StJohns <[email-masked]> wrote:
> 
>> In my view, the reason we need a person to do this is that leadership by committee is essential equivalent to a recipe for disaster.  And I do think we want leadership. 
>> 
>> Yours, 
>> joel 
> Strong +1 here.   One of the reasons for having a senior person in this role is so that the attention paid to the strategic evolution of the series does not wax and wane based on the current hobbyhorses of the leadership or their companies,  or upon other loud voices.   I have no problems with those voices influencing strategy, but I have strong problems with those voices directing strategy - especially if they change directions every 6 months or a year.   
> 
> We've had at least 4 people with the "rare and difficult" [Aside: difficult?] combination of attributes so I'm not sure where Martin is coming from here.   It may be that he doesn't agree that those are the right attributes for the role, but that's a whole other discussion.  I would expect with some luck, and with an IETF that respects what an expert can bring to the role, we will be able to find someone who won't run screaming into the night after they meet us.
> 
> Mike
> 
> 
> 

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

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 29 Jun 2020 10:28:12 +1000

On Mon, Jun 29, 2020, at 10:14, Michael StJohns wrote:
> difficult?] 

Sorry, I meant to say "difficult to source".

I said that because I understand that the number of people who have applied for the position in the past have been very small.  And if you rule out those who happened to define the role, the number is very, very small.

The great person theory of leadership is certainly appealing, but I want to be pragmatic.  How much do we really need a permanent position for strategist here?  And why is it that we think that a single person, complete with their own biases and bugaboos, is a necessary remedy for the problems we have?

There is ample evidence that there is disagreement in the community on some relevant topics.  You might think that a stern authoritative hand is what is needed to provide guidance and direction so that progress might be made.  But now you are asking to add "benevolent dictator" to the set of already challenging attributes that such an individual might bring.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Jun 2020 10:39:20 +1000

Belatedly giving my comments:

> On 25 Jun 2020, at 1:17 am, Brian Rosen <[email-masked]> wrote:
> 

I think that this is something we should leave up to the LLC.

> Also seems like we can likely wrap this up quickly on-list.  I sense the current direction is the LLC.  Brian offered some options.  If you think it should be some entity other than the LLC, please…

Clearly, it's the LLC writing the contract. Who advises them (and who they're required to listen to) when selecting one is a different question, and one we need to explore (see C).

> Most commenters seem to think this is not a good question because the answer is: they don’t need day to day management.  Bron thought everyone needs “some” management even if it’s “I’m sick and won…

The inclusion of "day to day" in this question has become distracting. I think it's better to state this as an aspect of oversight in question 5.

> This seems to be answered in the affirmative.  If you disagree, please speak up.

Affirmative.

> Most commenters liked Michael’s suggestion.  If you disagree, please speak up.

Link? This seems to be one of our major tasks, so we should make this decision deliberately.

> Here we have a lot of different opinions, and we probably need to spend some time at the meeting discussing this.  The question of strategy before process came up which we also need to figure out.

I think the output of this group should specify guidelines regarding how the RSE takes input from the community and determines its consensus. This might involve creating new WG-like bodies or other mechanisms. Their primary characteristic should be openness and accountability -- i.e. *not* a closed body of 'advisors' or the like.

> I sense that we’re close on this, but details matter.  I sense that there is support to allow the RSE to hold up a document if the RSE doesn’t feel that it is readable, but that that control is fai…

I think that the RSE can query a document's publication to assure that what they perceive as an inaccuracy, mistake or other issue is intentional. Once that's clarified, they cannot block publication.

> A. What do we want the RSE to do?   

8. What authorities and responsibilities does the RSE have?

> B. Is the RSE an individual or a group?

9. How do we map the identifies roles of the RSE into one or more positions? 

> D. What should the appointment length/renewal terms be?

These seem pretty self-explanatory; why are they considered not well-formed?

---

From: Jay Daley <[email-masked]>
Date: Mon, 29 Jun 2020 12:56:52 +1200

> On 27/06/2020, at 3:01 PM, Nevil Brownlee <[email-masked]> wrote:
> 
> Hi Martin:
> I've updated my Internet Draft to include a suggestion of what an RSEB (RFC Series Editorial Board) could be structured.  Take a look at https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html <https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html>
> 

Some questions:

Conceptually there are the following layers at which the RSE needs to operate:

a.  the long-term strategic level of where the series goes
b.  the medium-term managerial level of what tools are used, whether the SVG implementation is rethought, what performance is expected of the RPC, what the minimum standards are for a document to be accepted for processing, etc
c.  the short-term operational level of whether X change should be made the vocabulary, how Y should be rendered

It is not clear to me what role you see for the RSE/RSEB at each of these levels, specifically:

q1.  Am I correct in assuming from section 2 "RSE Responsibilities" that you still see the role of the RSE as convening and managing the community process that agrees the long-term strategy?
q2.  If so then is the only role of the RSEB to assist in calling consensus or does the RSEB have a role in representing the community view? 
q3.  How do you see the discussions/decisions for the managerial level working between the RSE/RSEB/Community?  (i.e. it’s not clear to me from your document what role, if any, the community has in this)
q4.  Does the RSEB have any role at all in the operational level or is that left to the RSE, working with whatever team/process they determine is appropriate?

It may be easier to answer those questions with your own definition of the levels.

thanks
Jay

> https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
> 
> 
> -- 

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Jun 2020 18:05:17 -0700

On Sun, Jun 28, 2020 at 5:23 PM Mark Nottingham <[email-masked]> wrote:

> The suggestion was to have more than one more specialised role, not to
> promote 'leadership by committee.' This has been discussed a number of
> times previously, due to the very high bar created by the combination of
> requirements we current place on the position (as Martin mentioned).
>

This aside, I don't really understand the "leadership by committee"
argument here. Here at the IETF we design protocols which will run on
billions of nodes using a collaborative consensus-based process. I find it
surprising that people think we can't use this process for the much lower
stakes question of how our documents ought to be shaped.
-Ekr

> by committee is essential equivalent to a recipe for disaster.  And I do
> role is so that the attention paid to the strategic evolution of the series
> does not wax and wane based on the current hobbyhorses of the leadership or
> their companies,  or upon other loud voices.   I have no problems with
> those voices influencing strategy, but I have strong problems with those
> voices directing strategy - especially if they change directions every 6
> months or a year.
> >
> would expect with some luck, and with an IETF that respects what an expert
> can bring to the role, we will be able to find someone who won't run
> screaming into the night after they meet us.
> >
> > Mike
> >
> >
> >

---

From: "John Levine" <[email-masked]>
Date: 28 Jun 2020 21:56:01 -0400

>stakes question of how our documents ought to be shaped.

The hard bit is finding people who understand the publishing and
archival issues and also understand the very unusual culture of the
IETF.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Jun 2020 14:00:55 +1200

> The suggestion was to have more than one more specialised role, not to promote 'leadership by committee.' This has been discussed a number of times previously, due to the very high bar created by t…

Certainly splitting the IT project management role (a.k.a. xml2rfcv3) from the Series Editor role is very desirable. A no-brainer, in fact.

But anyone with experience (even as an author) with journal publishing knows that the role of an Editor, aided by an editorial board, is essential. If we want the RFC Series to be more than a copy shop, we need such a person. The board may well be small, as Nevil suggests, but part of its role is to consult the community. We have lots of running code proof that the community on its own doesn't produce consensus; we need some focus point to extract a consensus, and the editorial board seems like a good solution for that.

Regards
   Brian

---

From: Christian Huitema <[email-masked]>
Date: Sun, 28 Jun 2020 22:55:39 -0700

On 6/28/2020 7:00 PM, Brian E Carpenter wrote:
> But anyone with experience (even as an author) with journal publishing knows that the role of an Editor, aided by an editorial board, is essential. 
I think that's a very flawed analogy. The RSE does not operate as "an
Editor, aided by an editorial board". Most of the classic editor
function are delegated to the stream managers, and the discussion has
pretty much established that the RSE has no say on the matter. In fact,
it might be better to drop the E from the title, and call for something
like an RFC Series Manager.
> If we want the RFC Series to be more than a copy shop, we need such a person. The board may well be small, as Nevil suggests, but part of its role is to consult the community. We have lots of running code proof that the community on its own doesn't produce consensus; we need some focus point to extract a consensus, and the editorial board seems like a good solution for that.

We have yet to see conclusive attempts at defining this community. There
may well be a need to gather feedback from the readers of the RFC, with
an eye towards making the standards more "readable". But it takes a leap
of faith to believe that a board will actually do that. If in fact the
the standards are so hard to read that people don't use them or don't
implement them, that seems a problem that the IETF itself must solve. If
it did not, the IETF products would slowly become irrelevant, and the
discussion of the future of the RFC series would become quite academic.

-- Christian Huitema

---

From: S Moonesamy <[email-masked]>
Date: Mon, 29 Jun 2020 00:59:17 -0700

Hi Martin,
At 04:47 PM 28-06-2020, Martin Thomson wrote:
>difficult combination of attributes.

It is difficult to fill a role which require a rare combination of 
skills/expertise.  The body might find a suitable candidate 
today.  However, it might not be able to find a replacement.  That is 
similar to the current situation.

Regards,
S. Moonesamy

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 29 Jun 2020 18:29:27 +0900

Hello everybody,

>> difficult combination of attributes.

It's very good to have different ideas. Can you be more specific, maybe 
even with a (short) draft?

> skills/expertise.  The body might find a suitable candidate today.  

Positions on the IESG and on the IAB (and some others) also require 
quite some combination of (of course different) skills. It's often not 
easy to find enough good candidates. And yet we have managed so far, 
with quite some success overall.

> However, it might not be able to find a replacement.  That is similar to 
> the current situation.

Yes indeed. With this in mind, we should try to make sure we do a better 
job than last time with respect to a very qualified holder of the 
position. I think to a large extent, that's what many of us are trying 
to achieve in this group.

Regards,   Martin.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 29 Jun 2020 03:18:01 -0700

Hi Martin,
At 02:29 AM 29-06-2020, Martin wrote:
>It's very good to have different ideas. Can you be more specific, 
>maybe even with a (short) draft?

I probably won't get around to write a short draft within the next 
two weeks as there is current an issue which I have to focus on.

Someone mentioned "specialized" in the thread.  The role would 
probably need a person with experience and expertise in technical 
publishing.  Combining that with "good understanding of the IETF" is 
difficult unless there is an assumption that the candidates are 
already involved in the IETF/AMS.

>quite some combination of (of course different) skills. It's often 
>not easy to find enough good candidates. And yet we have managed so 
>far, with quite some success overall.

The persons appointed for the IAB/IESG positions are from within the 
IETF.  That was not the case for the ex-RSE.  The RSE is a paid 
position.  The unique expertise/experience combination will have an 
impact on costs; that is not the case for IAB/IESG positions.

Regards,
S. Moonesamy

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 29 Jun 2020 20:01:14 +0900

On 29/06/2020 19:18, S Moonesamy wrote:
> I probably won't get around to write a short draft within the next two 
> weeks as there is current an issue which I have to focus on.

Sorry, that comment was directed to Martin (Thomson).

Regards,   Martin.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Jun 2020 06:05:11 -0700

On Sun, Jun 28, 2020 at 7:01 PM Brian E Carpenter <
[email-masked]> wrote:

> Certainly splitting the IT project management role (a.k.a. xml2rfcv3) from
> the Series Editor role is very desirable. A no-brainer, in fact.
>
> But anyone with experience (even as an author) with journal publishing
> knows that the role of an Editor, aided by an editorial board, is essential.

Well, as it happens, I have journal publishing experience as an author, and
I'm not sure I agree with this.

Moreover, the function of Editor of a journal is really much more like the
function of Program Committee chair in a conference. I.e., to select the
material to be published. That is not the case here.

If we want the RFC Series to be more than a copy shop, we need such a
> person.

Well, this seems like the place to start: what do we want the RFC Series to
be. As I said earlier, I see the primary purpose to be publishing technical
specifications. The requirements for the RFC Series to successfully fulfill
that functin seem relatively modest.

The board may well be small, as Nevil suggests, but part of its role is to
> consult the community. We have lots of running code proof that the
> community on its own doesn't produce consensus; we need some focus point to
> extract a consensus,

And yet, as I said, we have mechanisms for getting consensus on far more
weighty decisions. The reason I might be in favor of having some kind of
board is actually to *delegate* small decisions, not as a form of getting
consensus. But that naturally produces a division of labor in which the
board makes small decisions and the community makes big ones.

-Ekr

and the editorial board seems like a good solution for that.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Jun 2020 06:07:05 -0700

On Sun, Jun 28, 2020 at 6:56 PM John Levine <[email-masked]> wrote:

> In article <CABcZeBN57B409GY0uNOOSpn6v=
> [email-masked]> you write:

I've heard that said, but it's not clear to me it's true. It would perhaps
be useful to start by stating what the unique archival and publishing
issues/requirements *are*.

-Ekr

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 29 Jun 2020 06:46:32 -0700

On Mon, Jun 29, 2020, at 6:05 AM, Eric Rescorla wrote:
> 
> 
> On Sun, Jun 28, 2020 at 7:01 PM Brian E Carpenter 
> <[email-masked]> wrote:
> Well, as it happens, I have journal publishing experience as an author, 
> and I'm not sure I agree with this.
> 
> Moreover, the function of Editor of a journal is really much more like 
> the function of Program Committee chair in a conference. I..e., to 
> select the material to be published. That is not the case here.

+1 -- this matches my experience as a journal author, too. 

Best,
Chris

> >  If we want the RFC Series to be more than a copy shop, we need such a person. 
> 
> Well, this seems like the place to start: what do we want the RFC 
> Series to be. As I said earlier, I see the primary purpose to be 
> publishing technical specifications. The requirements for the RFC 
> Series to successfully fulfill that functin seem relatively modest.
> 
> 
> > The board may well be small, as Nevil suggests, but part of its role is to consult the community. We have lots of running code proof that the community on its own doesn't produce consensus; we need some focus point to extract a consensus, 
> 
> And yet, as I said, we have mechanisms for getting consensus on far 
> more weighty decisions. The reason I might be in favor of having some 
> kind of board is actually to *delegate* small decisions, not as a form 
> of getting consensus. But that naturally produces a division of labor 
> in which the board makes small decisions and the community makes big 
> ones.
> 
> -Ekr
> 
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 29 Jun 2020 16:07:27 +0200

Hi Eric,

> Moreover, the function of Editor of a journal is really much more like the function of Program Committee chair in a conference. I..e., to select the material to be published. That is not the case here.

I observe that there are at least two distinct visions for the role of RSE.  I am hearing that some people want not much more than someone who reports to the LLC, and that any changes should be initiated and managed by the community or a committee, while others believe that the role involves leadership and expertise. (There are other visions as well, I’m sure).

I think it would advance this group’s efforts if we all acknowledged some facts on the ground.  

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.

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.

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.

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.

Eliot

[*] Indeed the scale of work increased enough that the RSE requested and was given an increase in hours at least once in recent history.

---

From: "John Levine" <[email-masked]>
Date: 29 Jun 2020 10:29:10 -0400

>+1 -- this matches my experience as a journal author, too. 

There's a lot of different kind of editors. I've probably published at
least as many books as anyone else here, and I've had acquisition
editors, development editors, series editors, copy editors, and tech
editors, often all of those for a single book.

The RSE is somewhat like a series editor and development editor. In
our scheme, the WG more or less maps onto the acquisition and
devlopment editors, the RPC is the copy editors, and WG and IETF last
call are the tech editors.

Our processes are quite unusual and I don't think it's very useful to
try to look for close analogies in different kinds of processing.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jun 2020 09:11:47 +1200

On 29-Jun-20 17:55, Christian Huitema wrote:
> I think that's a very flawed analogy. The RSE does not operate as "an Editor, aided by an editorial board". 

True, the analogy is more with an Editor-in-Chief, with separate Editors in charge of different topics. I know people didn't like my analogy with a major newspaper, but actually a major newspaper has a Sports Editor, a Business Editor, a Local News Editor, an International News Editor, etc., all coordinated by the Editor-in-Chief.

> Most of the classic editor function are delegated to the stream managers, and the discussion has pretty much established that the RSE has no say on the matter. In fact, it might be better to drop the E from the title, and call for something like an RFC Series Manager.

There I disagree profoundly. If the RFC Series is to have overall consistency, it needs an Editor-in-Chief. It may also need a Production Manager and we've already seen that it needs an IT Manager.

> We have yet to see conclusive attempts at defining this community. 

You keep saying that, but we have defined it already: those who write RFCs plus those who use them (read them and implement them). How to *reach* that whole community is a real challenge, but not for this group IMHO.

> There may well be a need to gather feedback from the readers of the RFC, with an eye towards making the standards more "readable". But it takes a leap of faith to believe that a board will actually do that. 

At the moment, nobody is clearly charged with that job. We can change that.

> If in fact the the standards are so hard to read that people don't use them or don't implement them, that seems a problem that the IETF itself must solve. If it did not, the IETF products would slowly become irrelevant, and the discussion of the future of the RFC series would become quite academic.

I agree that the IETF needs to solve that problem, but we are not here as part of the IETF.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jun 2020 09:13:46 +1200

On 30-Jun-20 01:07, Eric Rescorla wrote:
> 
> 
> On Sun, Jun 28, 2020 at 6:56 PM John Levine <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     In article <CABcZeBN57B409GY0uNOOSpn6v=[email-masked] <mailto:[email-masked]>> you write:
> I've heard that said, but it's not clear to me it's true. It would perhaps be useful to start by stating what the unique archival and publishing issues/requirements *are*.

We had an expert on that topic until she resigned.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jun 2020 09:20:02 +1200

> try to look for close analogies in different kinds of processing.

Agreed. There are no exact parallels. But it seems to me (somewhat as
Eliot said) that there are two schools of thought here: people who think
that the RFC Series is just a copy shop for whatever each stream wants
to publish, or it is a genuine publishing house with consistent goals,
standards and policies across the streams.

And there are at least three distinct roles too: Editor-in-Chief/Publisher,
IT Manager, Production Manager.

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Jun 2020 14:26:46 -0700

On Mon, Jun 29, 2020 at 2:13 PM Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:
> [email-masked]>> you write:
> > I've heard that said, but it's not clear to me it's true. It would
> perhaps be useful to start by stating what the unique archival and
> publishing issues/requirements *are*.
>

Perhaps you have misunderstood me, but I am not talking about the details
but rather about the overall requirements. For instance "this document
needs to be readable for period X with technology cost Y". Those are areas
which are informed by expertise perhaps but are requirements that we as a
community need to set, not that can be deferred to experts. For instance,
we might decide we don't care at all about documents being readable beyond
3 years from now (I think this would be foolish) in which case the
situation would be simpler.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jun 2020 10:01:27 +1200

On 30-Jun-20 09:26, Eric Rescorla wrote:
> 
> 
> On Mon, Jun 29, 2020 at 2:13 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > On Sun, Jun 28, 2020 at 6:56 PM John Levine <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     In article <CABcZeBN57B409GY0uNOOSpn6v=[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> you write:
>     >     >billions of nodes using a collaborative consensus-based process. I find it
>     >     >surprising that people think we can't use this process for the much lower
>     >     >stakes question of how our documents ought to be shaped.
>     >
> Perhaps you have misunderstood me, but I am not talking about the details but rather about the overall requirements. For instance "this document needs to be readable for period X with technology cost Y". Those are areas which are informed by expertise perhaps but are requirements that we as a community need to set, not that can be deferred to experts. For instance, we might decide we don't care at all about documents being readable beyond 3 years from now (I think this would be foolish) in which case the situation would be simpler.

Sure, of course the community has to establish requirements. But translating that into archiving requirements as understood by archivists, national libraries, etc. is a different matter. And of course somebody has to run the community process.

    Brian

---

From: Larry Masinter <[email-masked]>
Date: Mon, 29 Jun 2020 15:41:16 -0700

Ekr wrote:

*	I am not talking about the details but rather about the overall requirements. For instance "this document needs to be readable for period X with technology cost Y". Those are areas which are informed by expertise perhaps but are requirements that we as a community need to set, not that can be deferred to experts. For instance, we might decide we don't care at all about documents being readable beyond 3 years from now (I think this would be foolish) in which case the situation would be simpler.

The archive requirements for RFCs are not so different than the archive requirements for any other documents: avoid single points of failure, and commit to detect and repair them over the lifetime of the series.

For document formats, choose those for which there are open, wide availability of documentation and have multiple, independent, interoperable implementations  of every feature used. 

Documents also need to be self-contained, in that their interpretation and use shouldn’t depend on external resources not part of the document, 

Text or XML with obscure Unicode used in normative segments, some non-tiny SVG features, non-PDF/A features would be areas of concern 

--

 <https://larrymasinter.net/> https://LarryMasinter.net

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Jun 2020 18:48:53 -0400

Actually, the archive requirements that we strove to meet were much 
stricter than that.  Whether that was strictly the requirement, or 
merely the understanding of the RSE, the RSOC, and the RSAG, I leave to 
others to deal with.

Yours,
Joel

On 6/29/2020 6:41 PM, Larry Masinter wrote:
> Ekr wrote:
> 
>   * I am not talking about the details but rather about the overall
>     requirements. For instance "this document needs to be readable for
>     period X with technology cost Y". Those are areas which are informed
>     by expertise perhaps but are requirements that we as a community
>     need to set, not that can be deferred to experts. For instance, we
>     might decide we don't care at all about documents being readable
>     beyond 3 years from now (I think this would be foolish) in which
>     case the situation would be simpler.
> 
> The archive requirements for RFCs are not so different than the archive 
> requirements for any other documents: avoid single points of failure, 
> and commit to detect and repair them over the lifetime of the series.
> 
> For document formats, choose those for which there are open, wide 
> availability of documentation and have multiple, independent, 
> interoperable implementations  of every feature used.
> 
> Documents also need to be self-contained, in that their interpretation 
> and use shouldn’t depend on external resources not part of the document,
> 
> Text or XML with obscure Unicode used in normative segments, some 
> non-tiny SVG features, non-PDF/A features would be areas of concern
> 
> --
> 
> https://LarryMasinter.net <https://larrymasinter.net/>
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Jun 2020 16:16:50 -0700

On Mon, Jun 29, 2020 at 3:01 PM Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     > On Sun, Jun 28, 2020 at 6:56 PM John Levine <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> wrote:
> >     >
> [email-masked]> <mailto:
> [email-masked]>>> you write:
> > Perhaps you have misunderstood me, but I am not talking about the
> details but rather about the overall requirements. For instance "this
> document needs to be readable for period X with technology cost Y". Those
> are areas which are informed by expertise perhaps but are requirements that
> we as a community need to set, not that can be deferred to experts. For
> instance, we might decide we don't care at all about documents being
> readable beyond 3 years from now (I think this would be foolish) in which
> Sure, of course the community has to establish requirements. But
> translating that into archiving requirements as understood by archivists,
> national libraries, etc. is a different matter.

Sure. But we first need to understand what those requirements are and then
we will understand the extent to which they in fact need to be translated
into requirements which are understood by archivists, national libraries,
etc.

> And of course somebody has to run the community process.
>

Yes. In other context we call that a WG chair.

-Ekr

---

From: "John R. Levine" <[email-masked]>
Date: 29 Jun 2020 21:12:26 -0400

>> publishing issues/requirements *are*.

We went through a rather long process to come up with RFC 7990 which 
describes the current plan for XML and output formats and such.  We still 
have some work to do to get to the place that 7990 describes but I think 
this particular part of the ocean does not need reboiling.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Jun 2020 11:46:48 +1000

Hi Eliot,

> On 30 Jun 2020, at 12:07 am, Eliot Lear <lear=[email-masked]> wrote:
> 
> Hi Eric,
> 

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.

> 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…

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.

> 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 ent…

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.

> 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 Jul 2020 15:03:20 +1200

> 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.

Agreed. My strawman is at
https://tools.ietf.org/id/draft-carpenter-rfc-principles-01.html#name-the-rfc-series-editor

   Brian

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Jul 2020 00:34:39 -0500

On Thu, Jun 25, 2020 at 11:14:48AM +1200, Brian E Carpenter wrote:
> >> 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. 
> > 
> 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
--