Subject: [Rfced-future] Work plan and next steps for this group

From: Eliot Lear <[email-masked]>
Date: Tue, 14 Apr 2020 16:44:17 +0200

Hi everyone,

As there were no objections to the work program, it is adopted.  It is, of course, subject to change, and I’m sure it will as we need to get more detailed.  But here it is for now:
Open up “the floor” for short problem statements that people think we need to address. We should be clear on what we see as problems and their scope.
See if we can get agreement on those.
Open up “the floor” for proposals on how to solve those problems.
See if we can get agreement on those.
We’re now in step 1.  Now is your opportunity to put forth a view in a form such as  “here’s what good looks like" statement or “here are the problems I am seeking to solve”, or in some way you believe will advance the discussion, but focusing on your goals for this effort.

There is no set time to move beyond this stage.  Once we have a few people’s visions, then I think we can worry about dates.  Again, I plan to schedule some roundtable discussions in May.  It would be desirable to have views from people in advance, but it is not required.  Again, those discussions are just an opportunity to share views and ask questions, as a means toward getting passed step 2 over time.

So.. what’s your vision?

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Apr 2020 17:43:03 +1000

Hi Eliot,

> On 15 Apr 2020, at 12:44 am, Eliot Lear <lear=[email-masked]> wrote:
> 

With no particular ordering, problems:

* The RSE currently has no direct input or insight into budgeting for the RPC, and yet the RSE has oversight of and ultimate responsibility for their work. This can result in mismatch between allocated resources and needs, as well as waste of resources. Also, it's not fair to the RSE.

* We currently spend approximately US$200/page of published RFC on the RFC Editor function, and there is no obvious mechanism to determine whether this money is well-spent, or to control the overall cost. For comparison, market rates for technical editing seem to range between US$10-35/page (which is not a fair comparison, but the difference _is_ eye-opening).

* There is no back pressure mechanism on drafts that need extensive amounts of editing or preparatory work. Note that this could be addressed outside of the RSE's purview, but it does have a strong influence on how we describe the role of the RFC Editor overall.

* The methods that the RSE has available to the make decisions (of various sorts) are ill-defined, to the point where it can be untenable for both them and the community. To me, this is the heart of the matter.

* The RFC Series has come to serve a wide variety of audiences, and the perceptions about their needs often compete. For example, "lower-layer" technical specifications often have a relatively small, specialised implementer and academic audience, where "higher-layer" application protocols sometimes have extremely broad, more casual audiences with less attention to give to minutia. As a result, some people feel that navigability of the series is an existential threat, while others perceive it as a minor annoyance (and that's just one example). This is a set of potential problems that could be addressed by an RSE, but designing the role and its interface with the community -- or really, communities -- needs to take it into account.

... and what good might look like (note again that these are not the results of _this_ program, but of its output):

* We are able to get to a documented agreement as a community (however defined) about a strategy for the RFC Series

* We're able to execute on that strategy

* Over time, the RFC Series -- in some form -- becomes an even more useful and well-understood resource for an increasing portion of the technical community

* The RFCs continue to flow

Not that I'm not including things like "the RFC series needs to be a continuously updated Web site" or "the RFC series must remain completely archival", or even "the RFC series must use blue links." None of that is in scope for this group, as I understand it, even if everyone has strong opinions about many of these issues.

Finally - I can't help but notice, again, that the functions of the RSE are carried out elsewhere (e.g.,the W3C, OASIS, etc.) without a publicly designated, autonomous figurehead. I understand there's history here, but I feel strongly that history should inform our choices, not bind them. As such, I'd really like to focus on what outcomes we want for our chosen community (see my first take above), and then figure out how to reach them, rather than pre-supposing a particular role ready for filling. We may very well end up with an RSE-like role, but I'd challenge us to justify doing so.

Cheers,

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

---

From: "John Levine" <[email-masked]>
Date: 16 Apr 2020 18:13:53 -0400

In article <[email-masked]> you write:
>* We currently spend approximately US$200/page of published RFC on the RFC Editor function, and there is no
>obvious mechanism to determine whether this money is well-spent, or to control the overall cost. For
>comparison, market rates for technical editing seem to range between US$10-35/page (which is not a fair
>comparison, but the difference _is_ eye-opening).

My wife does tech editing, and the kind of stuff that she does is only
a very small part of what the RPC does.

There is no spec for what the RPC does beyond "what the RPC does."
Back in 2006 when we put it out for bid, I believe that every bidder
talked to the existing key employees to be sure they could keep them
on, since otherwise we would have to invent a whole lot from scratch.
(I was involved in one of the losing bids.)

I think that AMS and its employees are doing a good job, and I expect
they will continue to do so, but it's a significant risk if some of
them were to quit or get sick.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Apr 2020 09:06:39 +1000

> On 17 Apr 2020, at 8:13 am, John Levine <[email-masked]> wrote:
> 

I do too. But not having what the RPC does written down seems pretty broken.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Apr 2020 09:43:13 +0200

> * The methods that the RSE has available to the make decisions (of various sorts) are ill-defined, to the point where it can be untenable for both them and the community. To me, this is the heart o…

Since this is an important issue for you, would you care to elaborate a bit more about what sort of decisions the RSE makes, their impact, and what you think good looks like at a high level?

Eliot

---

From: Russ Housley <[email-masked]>
Date: Fri, 17 Apr 2020 11:41:30 -0400

Mark:

I agree with many of your thoughts, but I want to share some thoughts that came to me as I read your message.  They are not in order.

> * Over time, the RFC Series -- in some form -- becomes an even more useful and well-understood resource for an increasing portion of the technical community

Yes, indeed.  The influence of the RFC series over the last 50 years is quite amazing.

> * There is no back pressure mechanism on drafts that need extensive amounts of editing or preparatory work. Note that this could be addressed outside of the RSE's purview, but it does have a strong…

There ought to be a straightforward mechanism for the RFC Editor to say that a document is not written well enough tor admittance to the queue.  The should shame the approving stream.  Today, the RFC Editor is reluctant to send documents back.  I would like to see the stream manager hold the authors to a higher bar.  Too often I hear, "That's okay, the RFC Editor will fix it."

> * The methods that the RSE has available to the make decisions (of various sorts) are ill-defined, to the point where it can be untenable for both them and the community. To me, this is the heart o…

I do not know if it is the hear of the matter, but it certainly overlaps with the above.

> * The RFC Series has come to serve a wide variety of audiences, and the perceptions about their needs often compete. For example, "lower-layer" technical specifications often have a relatively smal…

In the broadest terms, the audience is the implementer.  That said, the characteristics of the routing protocol implementer are somewhat different than the characteristics of the codec implementer and so on.  I am not sure there would be a huge value in enumerating those characteristics.  They are not static.

Russ

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 17 Apr 2020 15:02:09 -0400

On Fri, Apr 17, 2020 at 11:41 AM Russ Housley <[email-masked]> wrote:

>
>
> There ought to be a straightforward mechanism for the RFC Editor to say
> that a document is not written well enough tor admittance to the queue.
> The should shame the approving stream.  Today, the RFC Editor is reluctant
> to send documents back.  I would like to see the stream manager hold the
> authors to a higher bar.  Too often I hear, "That's okay, the RFC Editor
> will fix it."
>
>
I've always felt that one of the jobs I have as a working group
chair/shepherd is to hand over the best possible document to the IESG and
the RFC Editor.  The better the document is, the better the IESG
understands it, and the easier it is for the RFC Editor to get it
published. I would welcome feedback from the RFC editor on our WG
documents, as I think it can be done in a way to improve the quality of our
product.

These type of discussions on document quality, etc should be part of the
new working chair re-education orientation process.

tim

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Apr 2020 08:55:04 +1200

On 18-Apr-20 07:02, Tim Wicinski wrote:
> 
> 
> On Fri, Apr 17, 2020 at 11:41 AM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
> I've always felt that one of the jobs I have as a working group chair/shepherd is to hand over the best possible document to the IESG and the RFC Editor.  The better the document is, the better the IESG understands it, and the easier it is for the RFC Editor to get it published. I would welcome feedback from the RFC editor on our WG documents, as I think it can be done in a way to improve the quality of our product.
> 
> These type of discussions on document quality, etc should be part of the new working chair re-education orientation process. 

Nevertheless, there's a gap today. We have (and this is a good thing) many authors, WG chairs and document shepherds who are not of English mother tongue. Often they simply *cannot* detect errors in the English, and certainly cannot fix them. Are we willing to pay to fix this earlier in the process, rather than paying the RFC Editor to fix it after document approval?

I'm trying to imagine drafting an RFC in French, a language that I can read and speak quite well, if the IETF's publication language was French. The result would be horrible, and my writing speed would be at least 10 times slower.

    Brian

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 17 Apr 2020 16:59:10 -0400

I agree on the language barriers, but those can be worked with by pairing
folks up.

perhaps we can have a method to engage the RFC editor earlier in the
process much we do
for area reviews and IANA ?  Some guidance on perhaps organization, etc
could save a
lot of pain down the road.

On Fri, Apr 17, 2020 at 4:55 PM Brian E Carpenter <
[email-masked]> wrote:

> >     There ought to be a straightforward mechanism for the RFC Editor to
> say that a document is not written well enough tor admittance to the
> queue.  The should shame the approving stream.  Today, the RFC Editor is
> reluctant to send documents back.  I would like to see the stream manager
> hold the authors to a higher bar.  Too often I hear, "That's okay, the RFC
> Editor will fix it."
> >
> >
> Nevertheless, there's a gap today. We have (and this is a good thing) many
> authors, WG chairs and document shepherds who are not of English mother
> tongue. Often they simply *cannot* detect errors in the English, and
> certainly cannot fix them. Are we willing to pay to fix this earlier in the
> process, rather than paying the RFC Editor to fix it after document
> approval?
>
> I'm trying to imagine drafting an RFC in French, a language that I can
> read and speak quite well, if the IETF's publication language was French.
> The result would be horrible, and my writing speed would be at least 10
> times slower.
>
>     Brian
>
>

---

From: Michael StJohns <[email-masked]>
Date: Fri, 17 Apr 2020 17:22:12 -0400

On 4/17/2020 4:59 PM, Tim Wicinski wrote:
> I agree on the language barriers, but those can be worked with by 
> pairing folks up.
>
> for area reviews and IANA ?  Some guidance on perhaps organization, 
> etc could save a
It may be worthwhile to have John L (as Temp RFC Program guy) chime in 
with sort of a summary of what things get fixed by the RPC/RFC 
Editor/ISE and in which proportions.  Maybe there's a simple fix?

Generally, I don't see the editing team getting into the process earlier 
than they already are unless there's a specific cost savings to the 
process for doing so.  (And yes, I'm ignoring the author/doc editor time 
here).  Maybe we get them to do an adjunct to the "how to write an RFC" 
tutorials entitled "How not to get your RFC rejected by the Editors"?

Mike

>
> On Fri, Apr 17, 2020 at 4:55 PM Brian E Carpenter 
> <[email-masked] <mailto:brian.e.carpenter@gmail..com>> wrote:
>
>     > On Fri, Apr 17, 2020 at 11:41 AM Russ Housley
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >
>     >
>     >     There ought to be a straightforward mechanism for the RFC
>     Editor to say that a document is not written well enough tor
>     admittance to the queue.  The should shame the approving stream. 
>     Today, the RFC Editor is reluctant to send documents back.  I
>     would like to see the stream manager hold the authors to a higher
>     bar.  Too often I hear, "That's okay, the RFC Editor will fix it."
>     >
>     >
>     chair/shepherd is to hand over the best possible document to the
>     IESG and the RFC Editor.  The better the document is, the better
>     the IESG understands it, and the easier it is for the RFC Editor
>     to get it published. I would welcome feedback from the RFC editor
>     on our WG documents, as I think it can be done in a way to improve
>     the quality of our product.
>     >
>     > These type of discussions on document quality, etc should be
>     part of the new working chair re-education orientation process.
>
>     Nevertheless, there's a gap today. We have (and this is a good
>     thing) many authors, WG chairs and document shepherds who are not
>     of English mother tongue. Often they simply *cannot* detect errors
>     in the English, and certainly cannot fix them. Are we willing to
>     pay to fix this earlier in the process, rather than paying the RFC
>     Editor to fix it after document approval?
>
>     I'm trying to imagine drafting an RFC in French, a language that I
>     can read and speak quite well, if the IETF's publication language
>     was French. The result would be horrible, and my writing speed
>     would be at least 10 times slower.
>
>         Brian
>
>

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 17 Apr 2020 17:30:18 -0400

On Fri, Apr 17, 2020 at 5:23 PM Michael StJohns <[email-masked]>
wrote:

> with sort of a summary of what things get fixed by the RPC/RFC Editor/ISE
> and in which proportions.  Maybe there's a simple fix?
>
> than they already are unless there's a specific cost savings to the process
> for doing so.  (And yes, I'm ignoring the author/doc editor time here).
> Maybe we get them to do an adjunct to the "how to write an RFC" tutorials
> entitled "How not to get your RFC rejected by the Editors"?
>
> Mike
>
>
>
All valid points Michael and much more coherent than mine.

>From checking, it seems I've shepherded over 2 dozen document (yikes!) and
we have some editing work, but it's never felt excessive.
Though now I would not mind a review to find out if I can do better.

tim

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Apr 2020 11:23:14 +1200

I agree that it would be useful to have some estimates from the editors about the prevalence of seriously bad English.

I have just grepped the ~200 GenART Last Call reviews that I've made since 2007. A bit surprisingly, there are only about 15 where I logged serious editorial concerns, above the level of nits. That's a random sample, since the reviews are assigned by round-robin.

Of course, the RFC Editor is more strict and follows the Chicago Manual of Style.

Regards
   Brian

On 18-Apr-20 08:59, Tim Wicinski wrote:
> I agree on the language barriers, but those can be worked with by pairing folks up.
> 
> perhaps we can have a method to engage the RFC editor earlier in the process much we do 
> for area reviews and IANA ?  Some guidance on perhaps organization, etc could save a
> On Fri, Apr 17, 2020 at 4:55 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > On Fri, Apr 17, 2020 at 11:41 AM Russ Housley <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >
>     >

---

From: Eliot Lear <[email-masked]>
Date: Sat, 18 Apr 2020 11:34:32 +0200

> On 18 Apr 2020, at 01:23, Brian E Carpenter <[email-masked]> wrote:
> 

Before I ask Jay or John for these I would like to understand the answer would impact this group’s decision making.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Apr 2020 21:51:27 +1200

> Before I ask Jay or John for these I would like to understand the answer would impact this group’s decision making.

I'm not sure that it would. I think it would be worth knowing in terms of the IETF's own housekeeping, but that's not what this list is about, is it?

   Brian

---

From: "John Levine" <[email-masked]>
Date: 18 Apr 2020 18:39:26 -0400

>Before I ask Jay or John for these I would like to understand the answer would impact this group’s decision making.

At the moment I can tell you I have no idea.  I can easily ask the RPC for an informal estimate if you want.

R's,
John

---

From: Michael StJohns <[email-masked]>
Date: Sat, 18 Apr 2020 18:41:13 -0400

> Before I ask Jay or John for these I would like to understand the answer would impact this group’s decision making.

Hi Eliot - I'm sure you didn't mean to imply that we had to have your 
approval to ask Jay or John for information as the language above seems 
to indicate?  My understanding of your role is that of moderator, not 
mediator or have I got that wrong?

In any event,  while it may seem off topic, knowing what types of things 
are taking up the RPC's time in the documents could help to scope the 
general remit for the RSE.  So far I've heard anecdotally that the RPC 
has been reluctant to push back on authors for basic editorial issues 
and authors and WG chairs have in some cases said "let the RFC editors 
fix it".   I don't know how prevalent that is, getting the information 
about types of problems and interactions with the WGs might give us a 
better handle on whether to scope the job as "well defined, do what your 
told" or "RFC editor has discretion on what it accepts and has the right 
to hold the IETF inbound documents to a higher standard" or some range 
between.

It also may mean that we need to add some explicit add-on support for NN 
English to Standard English editing  in the RFC process which may 
fragment the RSE's job slightly.  It may also be the case that we can 
ask for community support from various language communities to enable 
something like that.

I don't think he information pull is an immediate need, but not all of 
us are completely familiar with how the current RFC tasks are broken up 
and what the current contracts consider in and out of scope.  I expect 
other questions of the form "Please explain x" will need to be answered 
by the RPC or John during this process.

Later, Mike

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 19 Apr 2020 10:47:46 +0100

It may be worthwhile to have John L (as Temp RFC Program guy) chime in with sort of a summary of what things get fixed by the RPC/RFC Editor/ISE and in which proportions.  Maybe there's a simple fix?

Generally, I don't see the editing team getting into the process earlier than they already are unless there's a specific cost savings to the process for doing so.  (And yes, I'm ignoring the author/doc editor time here).  Maybe we get them to do an adjunct to the "how to write an RFC" tutorials entitled "How not to get your RFC rejected by the Editors"?  

Mike,

Anecdotal, but…

As ISE I find the drafts presented on the Independent Stream to be very mixed. My reviewers address technical points and major issues of clarity, but don’t focus on smaller issues of language usage. I try to polish the documents myself (working with the authors) and sometimes ask the authors to go away and find a friend who can help with the issues of language.

>From time to time one gets through the net. A recent document came back from the RPC with more than 90 questions (recall that the RPC simply fix small issues, so questions reflect something that needs author input for resolution), and on this document the RPC had abandoned work before they got to the bottom of the document. In my opinion that should not happen and it was an ISE error.

In fact, I would have been very happy for the RPC to bounce this document as soon as it was obvious that it was going to be a problem. But what measures should they use to make that judgement? I think it should be something like the number of questions per page, perhaps averaged over the first ten pages. More than two questions per page seems excessive, to me.

Best,
Adrian (who is also [email-masked])

---

From: Eliot Lear <[email-masked]>
Date: Sun, 19 Apr 2020 12:23:52 +0200

Hi Mike,

> On 19 Apr 2020, at 00:41, Michael StJohns <[email-masked]> wrote:
> 
> Hi Eliot - I'm sure you didn't mean to imply that we had to have your approval to ask Jay or John for information as the language above seems to indicate?  My understanding of your role is that of moderator, not mediator or have I got that wrong?

I believe my role to be that similar to a WG chair.  I would ask questions on behalf of this group when I see that they further our purposes.  That doesn’t stop you or anyone else of asking questions.  However, see below.

> 
> In any event,  while it may seem off topic, knowing what types of things are taking up the RPC's time in the documents could help to scope the general remit for the RSE.  So far I've heard anecdotally that the RPC has been reluctant to push back on authors for basic editorial issues and authors and WG chairs have in some cases said "let the RFC editors fix it".   I don't know how prevalent that is, getting the information about types of problems and interactions with the WGs might give us a better handle on whether to scope the job as "well defined, do what your told" or "RFC editor has discretion on what it accepts and has the right to hold the IETF inbound documents to a higher standard" or some range between.
> 
> It also may mean that we need to add some explicit add-on support for NN English to Standard English editing  in the RFC process which may fragment the RSE's job slightly.  It may also be the case that we can ask for community support from various language communities to enable something like that.
> 

In this case, would we want to say, no matter the answer to an information request we would make, that someone (RPC/RSE/IAB/community) should have the authority to set minimal editorial standards prior to processing?  That would presumably leave to the stream owners how they choose to meet that standard.

(We can fill in the role later)

If nobody answers no to that question, perhaps we can move on.  Otherwise we may indeed need some data.

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Apr 2020 13:18:57 +1000

Hi Eliot,

Sorry for the delay, I had a busy weekend.

> Since this is an important issue for you, would you care to elaborate a bit more about what sort of decisions the RSE makes, their impact, and what you think good looks like at a high level?

Sure. 

RFC 8728 s 2.1.4. documents the responsibilities of the RSE, and calls out the evolution of the RFC Series explicitly. One might imagine this includes things like the format of RFCs, the editorial style used, creating resources for editors to use, the archival nature of the series, the RFC identifiers themselves, and so forth.

There are a variety of decisions that could be made -- or not made -- about these things. Because of the diverse nature of not only the IETF community but the larger RFC-producing and consuming community, some are bound to be contentious. 

8728 vests these responsibilities in the RSE with the expectation that they will 'engage with the Internet technical community in a process of articulating and refining a vision for the series and its continuous evolution.' Conspicuously missing is the word consensus, which would imply the extensive guidance we give the IESG and WG chairs about decision-making. 

Appeal is also central to the IETF's concept of consensus. However, 8728 does not contain that word; instead, it only says 'the RSE cooperates closely with the community, and operates under oversight of the RSOC: thus, ultimately, under oversight of the IAB.'

More guidance is provided by RFC 8729, in the various Process Change subsections. For example, s 4.4.3. regarding series-wide guidelines and rules says '[w]hen additions or changes are needed to series-wide definitions, the IAB will work with the RFC Editor and stream stakeholders to get community input and review.  The IAB will approve changes by validating appropriate consideration of community requirements.'

This supports the view that the only practical check on the RSE is IAB approval of specific actions; approval that is rarely withheld (especially after recent events, I'd suspect). That, in turn, is somewhat muddied by the ill-defined role of RSOC.

RSOC is, according to 8729, 'responsible for ensuring that the RFC Series is run in a transparent and accountable manner.' However, 8728 does not enact how this is done; it only says that RSOC 'will approve consensus policy and vision documents as developed by the RSE...', along with 'decisions that affect the RSE individually.' It would be interesting to hear whether the IAB thinks it has delegated its 'validating appropriate consideration' powers to the RSOC, and what the RSOC thinks about that (and I sit on both).

I think our primary task is exploring whether this arrangement results in what's best for the community and the Series.

For example, let's imagine that our next RSE talks to parts of the community and determines that the archival requirement was no longer necessary, and so they should start updating in-place RFCs. Others in the community would be very unhappy about this. The IAB could 'validate[e] appropriate consideration of community requirements' and determine that the RSE hadn't done so, but this could get heated; 'appropriate consideration' is a value judgment, and the IAB's questioning could be seen as interfering with the autonomy of the RSE. In the end, no matter what decision was made, there would likely be parts of the community who felt that they were not listened to, an RSE with burnt fingers, and an IAB (or is it RSOC?) having to make a decision without clear criteria.

That example may not be realistic, because a good RSE would convene some body to make that decision, and establish ground rules that look an awful lot like the IETF's consensus guidance. Perhaps the lack of doing so would be enough for the IAB to use as evidence that 'appropriate consideration' did not take place. I'm not certain of either of these things happening, however, because they're not written down.

For a second example, replace the obviously contentious change with a more subtle one; perhaps one that it would be reasonable to think that most people wouldn't care about, and so is a 'production' issue (e.g., a detail of the XML format).

For a third example, use the lack of a change or other action as the impetus to conflict.

I believe the latter two are realistic examples.

What we have now is effectively a system whereby the RSE makes decisions with little guidance regarding how they should go about consulting the community. Importantly, the examples above do not just illustrate the dangers to the community of an RSE running amok (or even just slightly out of sync); they also illustrate dangers to the RSE, who is vulnerable the the effects of mismatched expectations. 

I'm not yet sure what "good" looks like, but I think it's reasonable to ask why the consensus process hasn't been explicitly invoked (possibly with modifications like a different appeal chain). Yes, there are clearly aspects of this role that are operational and shouldn't be nit-picked to death (but still need _some_ form of oversight); however, there are many that are not. In that manner, it's very interesting to think about parallels with the discussion on the LLC's role currently happening on ietf@.

Other changes might help too; for example, a regular rfc-dispatch meeting for ideas and changes related to the series could be a good way to socialise proposals for change (both from the community and the RFC Editor) in a more transparent, accountable fashion. 

More than anything else, though, we need to write things down, and do so clearly.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Apr 2020 13:37:44 +1000

I can see a number approaches we as a community (broadly read) could take to this general issue:

1. We fund the RFC Editor (as a function) to do the editorial work so the document editors don't have to worry too much -- i.e., the RPC doing significant editorial work is expected. This seems to be the status quo.
2. We fund the RSE to create resources that help the community as much as possible with editorial work, but the RPC still serves as a backstop to assure editorial consistency -- i.e., we should encourage editors to take on responsibility, but still help them with the work.
3. We "crowdsource" from within (perhaps using IETF WG-like processes overseen by the RSE) to create resources that help the community edit, but the RPC still serves as a backstop -- same as #2, but with a different source of advice.
4. We "crowdsource", with no backstop (effectively, this is what the W3C does) -- a more radical change from the status quo.

There are of course many variations, and I'd be surprised if I didn't miss at least a few alternatives.

I don't think exploring those options is in scope for this group. I'm also a little surprised to see how eager this group is to dig into the fine details of these sorts of things, because AFAICT that implies that we're defining the RSE role so closely that it effectively cements in our current understanding of how things work -- turning the RSE into a job that *could* "just be done by a contractor."

I think what's in scope here is structuring the RFC Editor function in such a way that the community (broadly read) is able to come to consensus about issues like this in a way that's accountable, transparent, and representative, so that they can execute whatever approach we agree to -- again, in an accountable, transparent way. 

In other words, there needs to be a defined role that demonstrates leadership, and its occupant(s) need both the appropriate resources to fill that function, `and the appropriate oversight, checks and balances as well as responsibilities to be successful in doing so. 

I sometimes fear this group mistakes itself for that leadership (e.g., most of the messages on this list have tried to debug AUTH48 and the editorial process). While it's important to understand the past to help us plan the future that our program aspires to define, we should not try to troubleshoot its problems.

Cheers,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 19 Apr 2020 23:40:42 -0400

The primary reason that the existing documents do not point to a 
consensus process, as I understand the history, is that it was and is 
unclear whose consensus would be judged and where / how.

Note also the IAB documents, including IAB process documents, are not 
IETF consensus documents.  The IAB for all of its work consults the 
community, but is not bound by community consensus.  Maybe we want to 
change that, but that would be a MUCH larger change.
Unless we choose to change it drastically, the RSE is under the 
oversight of the IAB>  (The RSOC is the currently agreed means for 
performing that oversight.)

Could there be other ways of structuring this?  Presumably.  That is 
after all a part of why we have this list.

I do have to say thought that most of the concerns I see it your note do 
not resonate with me.  There are practical constraints and limitations 
that help significantly.  (And any job description has to recognize 
those constraints in some fashion.)  Trying to make those too formal and 
it seems to me we end up with a job that becomes both ineffective and 
impossible.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 19 Apr 2020 23:45:59 -0400

Since I just disagreed with Mark's previous message, I want to say that 
meat of this message (the second half), and the goals of this work it 
describes (at least as I understand what I read) seems right to me.

Yours,
Joel

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Apr 2020 13:46:40 +1000

> On 20 Apr 2020, at 1:40 pm, Joel M. Halpern <[email-masked]> wrote:
> 
> The primary reason that the existing documents do not point to a consensus process, as I understand the history, is that it was and is unclear whose consensus would be judged and where / how.

Yes, I've heard that asserted in various ways. I always find it puzzling that we say it's difficult to find a community affected by a change and judge its consensus, and yet the IETF does this all the time. We explicitly say that there is no membership, and that anyone can contribute (without even showing up at a meeting). Do we not really believe that?

> Note also the IAB documents, including IAB process documents, are not IETF consensus documents.  The IAB for all of its work consults the community, but is not bound by community consensus.  Maybe we want to change that, but that would be a MUCH larger change.
> Unless we choose to change it drastically, the RSE is under the oversight of the IAB>  (The RSOC is the currently agreed means for performing that oversight.)
> 
> Could there be other ways of structuring this?  Presumably.  That is after all a part of why we have this list.
> 
> I do have to say thought that most of the concerns I see it your note do not resonate with me.  There are practical constraints and limitations that help significantly.  (And any job description has to recognize those constraints in some fashion.)  Trying to make those too formal and it seems to me we end up with a job that becomes both ineffective and impossible.

Of course we can go too far, as in all things.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Apr 2020 16:44:01 +1200

> Yes, I've heard that asserted in various ways. I always find it puzzling that we say it's difficult to find a community affected by a change and judge its consensus, and yet the IETF does this all…

Let's be specific, because it does need a mechanism:

Strawman #1:
Define the community as everybody who finds RFCs to be useful.

How does somebody (say, the RSE) discover and judge the rough consensus of that community?

Strawman #2:
We define the community as "everybody who bothers to join the rfc-interest list", and the RSE could indeed use IETF-like rough consensus. 

Strawman #3:
Convert that mailing list into the "RFC Association" with its own Articles of Incorporation etc.

Strawman #4:
Use ISOC membership as a proxy for the RFC community.

I'm sure there are other options, but we'd have to pick one or another to talk about consensus.

     Brian

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 20 Apr 2020 14:58:20 +1000

On Mon, Apr 20, 2020, at 14:44, Brian E Carpenter wrote:
> [...]
> We define the community as "everybody who bothers to join the 
> rfc-interest list", and the RSE could indeed use IETF-like rough 
> consensus. 

I don't know how to make #1 work at all.  But we have worked examples of #2 that demonstrate some degree of efficacy.  And we know at least some of us are comfortable operating in that mode.

I would be leery of any attempt to define some sort of membership (#3+), though I know those schemes can work (for some definition of "work"), though details matter in terms of what emergent biases appear.

Any system will have its quirks, biases, and exposure to attacks of various kinds.  But I would suggest that similarity to existing systems will reduce the potential for unpleasant surprises.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Apr 2020 08:54:58 +0100

On 20/04/2020 05:44, Brian E Carpenter wrote:
> Strawman #1: Define the community as everybody who finds RFCs to be
> useful.
> 
> Strawman #2: We define the community as "everybody who bothers to
> join the rfc-interest list", and the RSE could indeed use IETF-like
> rough consensus.
Strawman #2.5: Define the community as anyone who reads
RFCs. Publish an RFC that says "if you care about the
operation and future of the series, get yourself active
on the rfc-interest list." Go from there with an
expectation that the RSE follow the rough consensus of
that list as needed.

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Apr 2020 11:40:11 +0200

Good evening, Mark.

> On 20 Apr 2020, at 05:37, Mark Nottingham <[email-masked]> wrote:
> 

I read things a little differently.  I think people are trying to understand the implications of decisions that we make now in terms of structure, and are working “bottom up” as it were.  Start with a problem and see what it means in terms of decision process as it trickles through the system.  And so that leads us a bit into the weeds, but then we’ll surface as people gain their footing.  What’s important is that people explicitly relate these exercises to decisions we think we have to make as a group.

> I think what's in scope here is structuring the RFC Editor function in such a way that the community (broadly read) is able to come to consensus about issues like this in a way that's accountable,…

You are articulating requirements for the solution here (good!): transparency and accountability.  The general thrust of your messages is that we could do a better job with those with this role.  As to the options above, it seems to me  a question as to whether the community decides the four options, the IAB decides those options, the RSE decides those options, or someone else like RSOC decides those options.  This group should decide who decides.

Eliot

---

From: Greg Skinner <[email-masked]>
Date: Mon, 20 Apr 2020 21:19:11 -0700

Comments inline

> On Apr 17, 2020, at 1:55 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Brian, do you (or anyone else) have any ideas why this is so?  Do they (the authors, chairs, etc.) know about the Style Guide <https://www.rfc-editor.org/styleguide/>?
Are there other issues?

> I'm trying to imagine drafting an RFC in French, a language that I can read and speak quite well, if the IETF's publication language was French. The result would be horrible, and my writing speed w…

I  would have problems drafting an RFC in languages that I know (less than fluently) also.  But even when writing in English, reviewing drafts (I have never authored or co-authored one, although I have initiated two status changes), I refer to the Style Guide and other guidelines as needed.

Perhaps it is not a bad thing if the rate of RFC publication is lower because the quality is higher.  Arguably, it could reduce the number of editorial errata.

Regards, Greg

---

From: Michael StJohns <[email-masked]>
Date: Tue, 21 Apr 2020 12:14:16 -0400

On 4/21/2020 12:19 AM, Greg Skinner wrote:
>>
>> Nevertheless, there's a gap today. We have (and this is a good thing) 
>> many authors, WG chairs and document shepherds who are not of English 
>> mother tongue. Often they simply *cannot* detect errors in the 
>> English, and certainly cannot fix them. Are we willing to pay to fix 
>> this earlier in the process, rather than paying the RFC Editor to fix 
>> it after document approval?
>>
>
> Brian, do you (or anyone else) have any ideas why this is so?  Do they 
> (the authors, chairs, etc.) know about the Style Guide 
> <https://www.rfc-editor.org/styleguide/>?
> Are there other issues?
>
Greg - Brian, I think,  was referring to English fluency: 
https://en.wikipedia.org/wiki/ILR_scale.    Nothing to do with the IETF, 
everything to do with their knowledge and experience in English.  My 
personal experience is that non-native speakers in the IETF range from a 
mid-range L2 all the way up to L5 with many sitting somewhere in the L3 
range.

A few decades back I was asked to review/edit an internet text book 
written by a non-native speaker and I stopped after about 4 chapters 
because the sentence structure was so jarring.  I passed the book back 
to the author with a recommendation that it be handed to a professional 
editor who worked with non-native speakers for a pass to clean up the 
basics.    The structure was problematic enough that simple technical 
points were getting lost.

In any event, I'm impressed with anyone who actually learns another 
language even at the lowest levels.  It's something I've never had the 
aptitude for.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Apr 2020 08:59:08 +1200

On 22-Apr-20 04:14, Michael StJohns wrote:
> Greg - Brian, I think,  was referring to English fluency:  https://en.wikipedia.org/wiki/ILR_scale.    Nothing to do with the IETF, everything to do with their knowledge and experience in English.  My personal experience is that non-native speakers in the IETF range from a mid-range L2 all the way up to L5 with many sitting somewhere in the L3 range.

Correct. I don't want to name and shame anybody, so no examples, but when you see a draft in which almost every sentence has incorrect or simply ugly syntax - misuse of words, wrong word order, errors of tense, case, number, even gender, etc. - that should (IMHO) never get near WG LC, let alone the RFC queue, until it has been fixed. Why? Because such errors can and do create technical misunderstandings. Therefore, declaring a consensus on the text is risky.

There is also the opposite problem: fluent English writers using complex or subtle syntax that confuses non-native English readers. That is very hard to detect, especially in one's own writing. I think my paragraph above is an example.

My own rule, when I remember to apply it, is this: if somebody misunderstands what I write, that is *my* fault, not theirs. I should correct my writing, not their reading.

   Brian

> 
> A few decades back I was asked to review/edit an internet text book written by a non-native speaker and I stopped after about 4 chapters because the sentence structure was so jarring.  I passed the book back to the author with a recommendation that it be handed to a professional editor who worked with non-native speakers for a pass to clean up the basics.    The structure was problematic enough that simple technical points were getting lost. 
> 
> In any event, I'm impressed with anyone who actually learns another language even at the lowest levels.  It's something I've never had the aptitude for.
> 
> Mike
> 
>