Subject: [Rfced-future] What I hope for with respect to the RFC/RSE.

From: Michael StJohns <[email-masked]>
Date: Sun, 24 May 2020 20:35:03 -0400

Hi - Elliot asked me to write my thought on what elements I might want 
from the outcome of this process - ideally as a delta to the current 
system.   It took me a while to go through the existing documents to get 
an idea of the written baseline.  RFC8728 and RFC8729 mainly.  I found 
myself in agreement with quite a large portion of those documents, 
especially with respect to the actual RFC Series Editor and RPC roles.  
What I found myself less sanguine with were the various sections that 
dealt with "oversight".  To be blunt, I believe that having either the 
IAB or IESG directly manage other resources  or contracts is not 
tenable.  The criteria of "able to manage a contract or employee" is not 
and has never been a criteria for selection of either an IESG or IAB 
member and the delegation of that responsibility to the RSOC does not 
appear to have been successful.

  * My general desire is to see an RFC publication system  that retains
    and perhaps expands its global impact and the generally wide respect
    for its quality and reach.
  * I'd like the people who make up the system to be professionals with
    the ability to continue to help this community publish a wide range
    of documents that help "make the Internet work better by ...
    influenc[ing] the way people design, use, and manage the Internet".
  * I'd like us to treat said professionals at least as well as we treat
    ourselves.
  * I'd like a system that evolves over time, and that is relatively
    immune to influence from relatively few people over a relatively
    short period of time.
  * I'd like a system that's responsible and accountable to the
    community directly rather than through the two layers of indirection
    we currently have.
  * I'd like some large measure of independence to be retained by this
    publication system and that the member's of that system voices are
    heard and honored as full partners and not "just a contractor[s]".
  * I'd like the RFC publication system to be stable in the face of
    unforeseen challenges and be able to gain (or regain) and retain
    institutional memory.
  * I'd really prefer that we don't have to do this again for another 10
    years.
  * I'd also prefer that once we have an RSE, we assume we keep them
    (after a probationary period) until they get tired of us, or they
    really mess up.

Those are my desires and I could stop there.   But I though I'd provide 
a sketch of how things might be restructured - this is provided not as a 
fleshed out proposal, but as a thought experiment to show that I think 
it's possible to have both independence and accountability:

___________________________________

The oversight for the RFC Publication System shall vest in an RFC Series 
editorial board (RSEB) consisting of 4 at large members selected through 
the Nomcom process for staggered 4 year terms (with a maximum of 1 
renewal) plus the RSE as the chair, plus the Stream managers (who must 
not be the chair of the particular board that appoints them).  The 
senior at-large member is the deputy chair and acts as chair in any 
matter in which the RSE is recused or not available.  The RSEB shall act 
by voting, but shall try to achieve consensus.

The RPC shall appoint a non-voting observer to the RSEB.    The RSEB may 
select an Executive Director or secretary for the RSEB.

The RSE may recommend that any document not be published and with a 
majority vote by the RSEB prohibit publication.   This shall generally 
be a last resort after negotiation with the publication stream over 
perceived problems.

The RSEB (minus the RSE) is the search committee for new RSEs.  They 
make the hiring recommendation to the LLC board.

The at-large members are selected for their experience in the IETF and 
their experience with publication systems with the latter given more 
weight.  They are selected through the normal Nomcom process, and 
approved by the LLC.

The at-large members must approve the ISE (who is nominated by the 
IAB).  Tie votes are broken by the RSE.

The stream managers for the IAB, IRTF and IESG(Standards) represent the 
groups that they come from, and are expected to consult with them on any 
non-routine matters.  They are reappointed each year as their respective 
bodies reform after the Nomcom process.

Each stream manager (including the ISE) shall provide a PUBLIC annual 
assessment of at least a page of how the RSE/RFC publication system is 
meeting or not meeting their needs.

The RSE shall provide an annual public report of the numbers and types 
of problems corrected on submitted documents.  This report shall be 
broken down by stream and shall be used to identify remedial actions for 
the production of documents from each stream.

The RSEB will consider the public assessments and provide a PUBLIC 
annual response approved by a majority of the board.

The RSEB (minus the RSE) will make a private recommendation to the LLC 
not later than 6 months prior to contract renewal (if the RSE is a 
contractor) or not more often than every 2 years (if an employee) on the 
continuance of the RSE.  The recommendation must be approved by the 
majority of the RSEB but may contain additional comments by any member 
for or against the recommendation and identified as originating from 
them. If the RSEB is unable to approve the report due to a lack of a 
majority, the report shall be forwarded without the recommendation but 
with any individual commentary. If the recommendation is for termination 
or non-renewal, the LLC shall share a redacted summary of the 
recommendation including any vote counts to the RSE, but not the actual 
positions taken by any member of the board.  The RSE is allowed to make 
a public or a private statement to the LLC with respect to the 
recommendation.

The LLC is the hiring entity for the RSE and bears all responsibilities 
normally attributed to a hiring entity.  The LLC is solely responsible 
for accepting or rejecting the recommendation of the RSEB with respect 
to the hiring or continuation of the RSE.   The LLC must make its own 
evaluation of the RSE performance rather than rely on the RSEB 
recommendation.

The RSEB by a 3/4 vote and with concurrence of the LLC (who must sign 
off on any costs) may add or remove streams.  Streams may be proposed by 
any entity in the form of an Informational RFC on the Independent stream.

Documents that touch on the RSE or RFC Publication System models shall 
be published after a community wide last call and with the majority 
approval of the RSEB.  Any document that changes the roles or 
responsibilities of the RSE or RPC which would require contract or job 
description changes also requires approval of the LLC.

____________________

As you may guess, the above is mostly to fix what I perceive is a 
problem with the IAB and RSOC oversight of the RFC series.   You may 
have other ideas or may hate mine.   Feel free to take exception to the 
broad strokes or propose your own, but for now let's try and avoid 
twiddling the fine points (e.g. "I really think there should be 3 at 
large members" would be twiddling the fine points).

Later, Mike

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 25 May 2020 11:06:29 +1000

Hi Mike,

> On 25 May 2020, at 10:35 am, Michael StJohns <[email-masked]> wrote:
> 
> Hi - Elliot asked me to write my thought on what elements I might want from the outcome of this process - ideally as a delta to the current system.   It took me a while to go through the existing documents to get an idea of the written baseline.  RFC8728 and RFC8729 mainly.  I found myself in agreement with quite a large portion of those documents, especially with respect to the actual RFC Series Editor and RPC roles.  What I found myself less sanguine with were the various sections that dealt with "oversight".  To be blunt, I believe that having either the IAB or IESG directly manage other resources  or contracts is not tenable.  The criteria of "able to manage a contract or employee" is not and has never been a criteria for selection of either an IESG or IAB member and the delegation of that responsibility to the RSOC does not appear to have been successful.  
> 
> 	• My general desire is to see an RFC publication system  that retains and perhaps expands its global impact and the generally wide respect for its quality and reach.  
> 	• I'd like the people who make up the system to be professionals with the ability to continue to help this community publish a wide range of documents that help "make the Internet work better by ... influenc[ing] the way people design, use, and manage the Internet". 

I think I agree with all of the above. It does make me think that we might be more successful if the decision-making / leadership role were carved away from the "contracting" role (i.e., the publisher-centric aspects); that might help avoid the need to have a special oversight function for the contractor/specialist.

> 	• I'd like us to treat said professionals at least as well as we treat ourselves.   

This is a low bar; we treat ourselves pretty badly.

> 	• I'd like a system that evolves over time, and that is relatively immune to influence from relatively few people over a relatively short period of time.  

If I parse correctly, I think I agree. 

> 	• I'd like a system that's responsible and accountable to the community directly rather than through the two layers of indirection we currently have.  

Agreed, as long as that's transparent. Having someone who goes and talks to different parts of the community and then makes a decision based upon those conversations isn't accountable; they get to choose their facts (deliberately or not). We need a system where the consensus of the community can be judged by all because we have a shared discourse about the series, rather than a piecemeal one.

> 	• I'd like some large measure of independence to be retained by this publication system and that the member's of that system voices are heard and honored as full partners and not "just a contractor[s]".  

I think we still need to explore this notion of independence and what it brings. Asserting that it's important isn't adequate.

> 	• I'd like the RFC publication system to be stable in the face of unforeseen challenges and be able to gain (or regain) and retain institutional memory.  
> 	• I'd really prefer that we don't have to do this again for another 10 years.  
> 	• I'd also prefer that once we have an RSE, we assume we keep them (after a probationary period) until they get tired of us, or they really mess up.

I'd hope so.

> Those are my desires and I could stop there.   But I though I'd provide a sketch of how things might be restructured - this is provided not as a fleshed out proposal, but as a thought experiment to show that I think it's possible to have both independence and accountability:
> 
> 
> 
> The oversight for the RFC Publication System shall vest in an RFC Series editorial board (RSEB) consisting of 4 at large members selected through the Nomcom process for staggered 4 year terms (with a maximum of 1 renewal) plus the RSE as the chair, plus the Stream managers (who must not be the chair of the particular board that appoints them).  The senior at-large member is the deputy chair and acts as chair in any matter in which the RSE is recused or not available.  The RSEB shall act by voting, but shall try to achieve consensus.
> 
> The RPC shall appoint a non-voting observer to the RSEB.    The RSEB may select an Executive Director or secretary for the RSEB. 
> 
> The RSE may recommend that any document not be published and with a majority vote by the RSEB prohibit publication.   This shall generally be a last resort after negotiation with the publication stream over perceived problems.

If you're not constraining this to editorial matters, you're talking about a radical change in how the RFC Series works -- one that I think would be surprising and undesirable to the vast majority of the community.

If you really want to pursue this, let's put the question to the community and see what the reactions are. Even in this limited group so far, you're pretty much a lone voice on this, AFAICT.

> The RSEB (minus the RSE) is the search committee for new RSEs.  They make the hiring recommendation to the LLC board. 
> 
> The at-large members are selected for their experience in the IETF and their experience with publication systems with the latter given more weight.  They are selected through the normal Nomcom process, and approved by the LLC.
> 
> The at-large members must approve the ISE (who is nominated by the IAB).  Tie votes are broken by the RSE.

Is this in scope for this program? I suspect not.

> The stream managers for the IAB, IRTF and IESG(Standards) represent the groups that they come from, and are expected to consult with them on any non-routine matters.  They are reappointed each year as their respective bodies reform after the Nomcom process.
> 
> Each stream manager (including the ISE) shall provide a PUBLIC annual assessment of at least a page of how the RSE/RFC publication system is meeting or not meeting their needs.  

That sounds useful, but still a really indirect way of getting feedback from the community to the RSE.

> The RSE shall provide an annual public report of the numbers and types of problems corrected on submitted documents.  This report shall be broken down by stream and shall be used to identify remedial actions for the production of documents from each stream.

We should get feedback from the RPC about how much extra work keeping these numbers will be, and how hard it is to categorise them.

> The RSEB will consider the public assessments and provide a PUBLIC annual response approved by a majority of the board.
> 
> The RSEB (minus the RSE) will make a private recommendation to the LLC not later than 6 months prior to contract renewal (if the RSE is a contractor) or not more often than every 2 years (if an employee) on the continuance of the RSE.  The recommendation must be approved by the majority of the RSEB but may contain additional comments by any member for or against the recommendation and identified as originating from them.  If the RSEB is unable to approve the report due to a lack of a majority, the report shall be forwarded without the recommendation but with any individual commentary. If the recommendation is for termination or non-renewal, the LLC shall share a redacted summary of the recommendation including any vote counts to the RSE, but not the actual positions taken by any member of the board.  The RSE is allowed to make a public or a private statement to the LLC with respect to the recommendation. 
> 
> The LLC is the hiring entity for the RSE and bears all responsibilities normally attributed to a hiring entity.  The LLC is solely responsible for accepting or rejecting the recommendation of the RSEB with respect to the hiring or continuation of the RSE.   The LLC must make its own evaluation of the RSE performance rather than rely on the RSEB recommendation.
> 
> The RSEB by a 3/4 vote and with concurrence of the LLC (who must sign off on any costs) may add or remove streams.  Streams may be proposed by any entity in the form of an Informational RFC on the Independent stream.

This is a surprising amount of power to give to relatively few people; one where mistakes will be very difficult to correct.

> Documents that touch on the RSE or RFC Publication System models shall be published after a community wide last call and with the majority approval of the RSEB.  Any document that changes the roles or responsibilities of the RSE or RPC which would require contract or job description changes also requires approval of the LLC.
> 
> ____________________
> 
> As you may guess, the above is mostly to fix what I perceive is a problem with the IAB and RSOC oversight of the RFC series.   You may have other ideas or may hate mine.   Feel free to take exception to the broad strokes or propose your own, but for now let's try and avoid twiddling the fine points (e.g. "I really think there should be 3 at large members" would be twiddling the fine points).

Fair enough.

Your proposal is indeed pretty focused on that one perceived problem; AFACT it's basically taking the RSOC out of the IAB's hands and making it Nomcom-selected, with some accountability measures.

That might address the problems that you perceive, but on first reading, it doesn't address a number of the problems that I perceive. So, I'll try to write something along the same lines this week, and we'll see where that gets us.

Cheers,

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 May 2020 13:54:56 +1200

So, Mike, take this as a friendly challenge, since I generally like what you wrote:

>  a system that's responsible and accountable to the community directly

Yes, more or less what my draft says too.

> The at-large members are selected for their experience in the IETF and their experience with publication systems with the latter given more weight.  They are selected through the normal Nomcom process

How do we reach the whole candidate pool? Where do we send the call for nominations? We clearly want a wider spread than traditionally, if we are really trying to cover the whole RFC-using community. In fact, I don't see why IETF experience is the first criterion. Experience writing code or running networks based on RFCs seems equally important.

Regards
   Brian Carpenter

On 25-May-20 12:35, Michael StJohns wrote:
>   * My general desire is to see an RFC publication system  that retains and perhaps expands its global impact and the generally wide respect for its quality and reach. 
>   * I'd like the people who make up the system to be professionals with the ability to continue to help this community publish a wide range of documents that help "make the Internet work better by ... influenc[ing] the way people design, use, and manage the Internet".
>   * I'd like us to treat said professionals at least as well as we treat ourselves.  
>   * I'd like a system that evolves over time, and that is relatively immune to influence from relatively few people over a relatively short period of time. 
>   * I'd like a system that's responsible and accountable to the community directly rather than through the two layers of indirection we currently have. 
>   * I'd like some large measure of independence to be retained by this publication system and that the member's of that system voices are heard and honored as full partners and not "just a contractor[s]". 
>   * I'd like the RFC publication system to be stable in the face of unforeseen challenges and be able to gain (or regain) and retain institutional memory. 
>   * I'd really prefer that we don't have to do this again for another 10 years. 
>   * I'd also prefer that once we have an RSE, we assume we keep them (after a probationary period) until they get tired of us, or they really mess up.
>

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 24 May 2020 21:56:11 -0400

Michael

I really agree with your first section.  You talk about making them full
partners, and I can see this going
another step.  I see the RFC publication system not just work on documents,
but be our voice in other corners of other
technical communities. People ask me at times "so why are the IETF RFCs so
much better than other systems", and
I can say a few words, then I struggle to speak eloquently on the topic.
This role should be empowered (and funded)
to do so.

I still need to work through your second section.

thanks
tim

On Sun, May 24, 2020 at 8:35 PM Michael StJohns <[email-masked]>
wrote:

> system.   It took me a while to go through the existing documents to get an
> idea of the written baseline.  RFC8728 and RFC8729 mainly.  I found myself
> in agreement with quite a large portion of those documents, especially with
> respect to the actual RFC Series Editor and RPC roles.  What I found myself
> less sanguine with were the various sections that dealt with "oversight".
> To be blunt, I believe that having either the IAB or IESG directly manage
> other resources  or contracts is not tenable.  The criteria of "able to
> manage a contract or employee" is not and has never been a criteria for
> selection of either an IESG or IAB member and the delegation of that
> responsibility to the RSOC does not appear to have been successful.
>
>    - My general desire is to see an RFC publication system  that retains
>    and perhaps expands its global impact and the generally wide respect for
>    its quality and reach.
>    - I'd like the people who make up the system to be professionals with
>    the ability to continue to help this community publish a wide range of
>    documents that help "make the Internet work better by ...
>    - I'd like us to treat said professionals at least as well as we treat
>    ourselves.
>    - I'd like a system that evolves over time, and that is relatively
>    immune to influence from relatively few people over a relatively short
>    period of time.
>    - I'd like a system that's responsible and accountable to the
>    community directly rather than through the two layers of indirection we
>    currently have.
>    - I'd like some large measure of independence to be retained by this
>    publication system and that the member's of that system voices are heard
>    and honored as full partners and not "just a contractor[s]".
>    - I'd like the RFC publication system to be stable in the face of
>    - I'd really prefer that we don't have to do this again for another 10
>    years.
>    - I'd also prefer that once we have an RSE, we assume we keep them
>    (after a probationary period) until they get tired of us, or they really
>    mess up.
>
> Those are my desires and I could stop there.   But I though I'd provide a
> sketch of how things might be restructured - this is provided not as a
> fleshed out proposal, but as a thought experiment to show that I think it's
> possible to have both independence and accountability:
>
>
> the Nomcom process for staggered 4 year terms (with a maximum of 1 renewal)
> plus the RSE as the chair, plus the Stream managers (who must not be the
> chair of the particular board that appoints them).  The senior at-large
> member is the deputy chair and acts as chair in any matter in which the RSE
> is recused or not available.  The RSEB shall act by voting, but shall try
> to achieve consensus.
>
> majority vote by the RSEB prohibit publication.   This shall generally be a
> last resort after negotiation with the publication stream over perceived
> problems.
>
> The RSEB (minus the RSE) is the search committee for new RSEs.  They make
> the hiring recommendation to the LLC board.
>
> weight.  They are selected through the normal Nomcom process, and approved
> by the LLC.
>
> The RSE shall provide an annual public report of the numbers and types of
> problems corrected on submitted documents.  This report shall be broken
> down by stream and shall be used to identify remedial actions for the
> production of documents from each stream.
>
> The RSEB will consider the public assessments and provide a PUBLIC annual
> response approved by a majority of the board.
>
> The RSEB (minus the RSE) will make a private recommendation to the LLC not
> later than 6 months prior to contract renewal (if the RSE is a contractor)
> or not more often than every 2 years (if an employee) on the continuance of
> the RSE.  The recommendation must be approved by the majority of the RSEB
> but may contain additional comments by any member for or against the
> recommendation and identified as originating from them.  If the RSEB is
> unable to approve the report due to a lack of a majority, the report shall
> be forwarded without the recommendation but with any individual commentary. If
> the recommendation is for termination or non-renewal, the LLC shall share a
> redacted summary of the recommendation including any vote counts to the
> RSE, but not the actual positions taken by any member of the board.  The
> RSE is allowed to make a public or a private statement to the LLC with
> respect to the recommendation.
>
> normally attributed to a hiring entity.  The LLC is solely responsible for
> accepting or rejecting the recommendation of the RSEB with respect to the
> hiring or continuation of the RSE.   The LLC must make its own evaluation
> of the RSE performance rather than rely on the RSEB recommendation.
>
> The RSEB by a 3/4 vote and with concurrence of the LLC (who must sign off
> on any costs) may add or remove streams.  Streams may be proposed by any
> entity in the form of an Informational RFC on the Independent stream.
>
> Documents that touch on the RSE or RFC Publication System models shall be
> published after a community wide last call and with the majority approval
> of the RSEB.  Any document that changes the roles or responsibilities of
> the RSE or RPC which would require contract or job description changes also
> requires approval of the LLC.
>
> ____________________
>
> As you may guess, the above is mostly to fix what I perceive is a problem
> with the IAB and RSOC oversight of the RFC series.   You may have other
> ideas or may hate mine.   Feel free to take exception to the broad strokes
> or propose your own, but for now let's try and avoid twiddling the fine
> points (e.g. "I really think there should be 3 at large members" would be
> twiddling the fine points).
>
> Later, Mike
>
>
>
> --
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
>

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 24 May 2020 21:58:22 -0400

On Sun, May 24, 2020 at 9:55 PM Brian E Carpenter <
[email-masked]> wrote:

> weight.  They are selected through the normal Nomcom process
>
> How do we reach the whole candidate pool? Where do we send the call for
> nominations? We clearly want a wider spread than traditionally, if we are
> really trying to cover the whole RFC-using community. In fact, I don't see
> why IETF experience is the first criterion. Experience writing code or
> running networks based on RFCs seems equally important.
>
> Regards
>    Brian Carpenter
>
>
Agree with Brian on the candidate pool.  We need to include folks who use
our documents and have an outside perspective

tim

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 May 2020 11:58:29 +0200

Mike,

Thank you for having taken the time to detail your views.  This is very helpful, even if one doesn’t agree with everything you wrote.  You clearly drew out what you believed the problem to be, and how you would address it.  Your proposal is interesting and will help us crystalize our views. 

On Mark Nottingham’s question of scope:

> […]

Mark asserted that appointment/approval of the ISE is not in scope for this effort.  As I read our charter, I would tend to agree, although it is a fine line.  Rather than get into a tussle over the charter, because nobody has raised issues about the management of the stream managers, let’s limit our scope to how the RSE and RPC interacts with or is accountable to them.  We already have enough to be getting on with.

> The RSE may recommend that any document not be published and with a majority vote by the RSEB prohibit publication.   This shall generally be a last resort after negotiation with the publication st…

In my view, based on the discussion that previously occurred, the overwhelming consensus is against you.  If people other than Mike agree with the above text, please say so now.

Eliot

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 26 May 2020 00:08:12 +1000

On Mon, May 25, 2020, at 19:58, Eliot Lear wrote:
> In my view, based on the discussion that previously occurred, the overwhelming consensus is against you. If people *other* than Mike agree with the above text, please say so now.

I have not yet commented on this, but I believe I am with the overwhelming here.

This issue only occurs in the situation where the RSE has said "I don't want to publish this document for reasons X, Y, Z" and the elected representatives of the IETF have said "regardless, we have reasons which override those concerns and insist that you publish".

At this point, the remedy for the RSE is to resign rather than publish under their watch. They must have this option open to them, but that is the ultimate remedy available to the RSE.

Refusal to publish and retaining the role is not tenable. The RSE and the RFC series exist to serve the streams, not the other way around.

The role of the RSE is to ensure that high quality documents are created which accurately represent the intent of the stream owners.

Eliot - you are quite correct that this is the first key question we need to have consensus on in order to describe this role: who will have ultimate authority to determine which documents are published.

Regards,

Bron.

P.S. There also needs to be a way to deal with RSE filibustering, and/or tarpitting - either undue delay in publishing a document they don't like, or running out the clock and then sending it back with minor edits over and and over.

P.P.S. I will provide some justification for why I take this position. It is along the lines of "The Net interprets censorship as damage and routes around it." - I don't wish to see fragmentation where the IAB or IETF find themselves needing to publish a separate stream of documents and start treating them as authoritative.

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

---

From: "John Levine" <[email-masked]>
Date: 25 May 2020 12:52:00 -0400

In article <[email-masked]> you write:
>At this point, the remedy for the RSE is to resign rather than publish under their watch. They must have this option open
>to them, but that is the ultimate remedy available to the RSE.

Agreed.  The point of a having a nuclear option is to force people on each side to think really
carefully before pushing the button.

>P.S. There also needs to be a way to deal with RSE filibustering, and/or tarpitting - either undue delay in publishing a
>document they don't like, or running out the clock and then sending it back with minor edits over and and over.

I think the solution to that is don't appoint an RSE who is a jerk,
rather than to try to invent meta-meta-rules for bad faith situations
unlikely to arise in practice. We have had RSEs for decades and as far
as I know filibustering has never been a problem.

R's,
John

---

From: Michael StJohns <[email-masked]>
Date: Mon, 25 May 2020 13:49:22 -0400

> How do we reach the whole candidate pool? Where do we send the call for nominations? We clearly want a wider spread than traditionally, if we are really trying to cover the whole RFC-using communit…

Oops - temporary myopia on my part.  I agree mostly.  I think this is 
the goal, but may take a few years to get there.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 25 May 2020 14:09:28 -0400

On 5/25/2020 5:58 AM, Eliot Lear wrote:
> Mark asserted that appointment/approval of the ISE is not in scope for 
> this effort.  As I read our charter, I would tend to agree, although 
> it is a fine line.  Rather than get into a tussle over the charter, 
> because nobody has raised issues about the management of the stream 
> managers, let’s limit our scope to how the RSE and RPC interacts with 
> or is accountable to them.  We already have enough to be getting on with.

Firstly, on the matter of in charter-out of charter, this is in.   We 
re-organized the RFC system 10 years ago and the splitting out of the 
ISE from the RSE was one of the results.  It makes sense to take another 
look at whether that needs to continue or whether the ISE is properly 
chartered or circumscribed and whether in some circumstances it might 
make sense to fold the ISE back into the RSE.   I don't actually think 
that latter is the best approach, but its something that should be 
considered - at least as it effects the RSE roles and responsibilities.  
Note that as of right now both the ISE and RSE are funded positions, and 
that any protections we provide with respect to oversight of the RSE may 
also need to apply with respect to the ISE.

Secondly, on the matter of who appoints the ISE, it would be helpful if 
you consider the context in which I suggested this. My suggestions were 
meant to devolve the IAB from overall control of the RFC System and the 
change in appointment/approval of the ISE was in that vein.   Right now, 
the IAB appoints the RSE, the ISE and the IAB stream manager.  They also 
appoint the IRTF chair who appoints the IRTF stream manager.  In other 
words, out of 5 people, the IAB appoints or indirectly appoints 4.     
This proposal is in support of

"I'd like a system that evolves over time, and that is relatively immune to influence from relatively few people over a relatively short period of time."

Keep in mind, my baseline is the point where ISI transitioned out of the 
RFC SE role; we've had 10 years of experience with most of the changes 
from that point, and actually evaluating how they've worked out ought to 
be part of the information feeding into the process of this group.

Later, Mike

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 May 2020 21:49:17 +0200

Hi Mike,

> Secondly, on the matter of who appoints the ISE, it would be helpful if you consider the context in which I suggested this.   My suggestions were meant to devolve the IAB from overall control of the RFC System and the change in appointment/approval of the ISE was in that vein.   Right now, the IAB appoints the RSE, the ISE and the IAB stream manager.  They also appoint the IRTF chair who appoints the IRTF stream manager.  In other words, out of 5 people, the IAB appoints or indirectly appoints 4.
> 

For one to take this view, one has to be of the opinion that the streams are part of the RFC Editor function.  I don’t see it that way.  I see the streams as interacting with that function.  This is why I view discussion of the ISE as out of scope.  That is not to say that I believe the IAB MUST continue to appoint and manage the ISE as they do today, but simply that it is not the task at hand in this group now.  Again, if others disagree with me, please say so.

This is also not to say that we can't adjust stream responsibilities relating to the RSE/RPC etc, as you have done in your interesting early proposal.  That I view as very much in scope.

Eliot

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 25 May 2020 16:51:41 -0400

Eliot

Even if you take the opinion that the streams interact with the RFC Editor
function, I would still argue that the
RFC Editor function should have a larger role in the appointment/approval
of the stream managers.

tim

On Mon, May 25, 2020 at 3:49 PM Eliot Lear <lear=[email-masked]>
wrote:

> For one to take this view, one has to be of the opinion that the streams
> are part of the RFC Editor function.  I don’t see it that way.  I see the
> streams as interacting with that function.  This is why I view discussion
> of the ISE as out of scope.  That is not to say that I believe the IAB MUST
> continue to appoint and manage the ISE as they do today, but simply that it
> is not the task at hand in this group now.  Again, if others disagree with
> me, please say so.
>
> This is also not to say that we can't adjust stream responsibilities
> relating to the RSE/RPC etc, as you have done in your interesting early
> proposal.  That I view as very much in scope.
>
> Eliot
> --

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 May 2020 09:06:28 +1200

> I have not yet commented on this, but I believe I am with the overwhelming here.

Me too. My own draft suggests three principles here:

       *  The RFC Editor team has control of editorial matters, subject
          to review by the relevant stream and the document authors.  In
          particular, a badly written document may be returned to its
          stream for improvements if an abnormal amount of copy-editing
          is required.

       *  If an individual member of the RFC Editor team has personal
          comments on the technical content of a draft RFC, they must be
          handled in person, using the appropriate mechanism of the
          stream concerned, not as an RFC Editor matter.

       *  If the RFC Editor team believes that a draft RFC contains a
          serious technical flaw, which the stream declines to change,
          the RFC Editor cannot block the document indefinitely.  Note
          that there is more discussion of such disagreements in
          Section 4.3 of [RFC8728].

I intentionally made this a team matter, not a personal matter for the RSE.
If the RSE wants to argue for pi=22/7, they can do so as an individual
participant.

> Eliot - you are quite correct that this is the first key question we need to have consensus on in order to describe this role: who will have ultimate authority to determine which documents are publ…

The only good answer to that is "the community". And yes, I know that leaves some uncertainty at the heart of the matter. The procedure in https://www.rfc-editor.org/rfc/rfc8728.html#name-disagreements-among-entitie goes into this (but based on the IAB/RSOC model, which I assume we will be changing).

Regards
    Brian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 May 2020 09:19:32 +1000

> On 26 May 2020, at 2:52 am, John Levine <[email-masked]> wrote:
> 

Agreed. The best thing we can do here is to have clear guidance for both the RSE and the community about the nature of the role, so that expectations match.

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 May 2020 17:32:12 -0600

On 5/24/20 6:35 PM, Michael StJohns wrote:

I have always seen them as hyper independent. As some cloud you tossed a draft to and hopped would rain the document back at you. I have been confused by their priorities and expectations. I trusted them. And I can't think of a failure. So that part, I think, should not change.

To these two:

I have not tracked a specific draft through the process in a long time. I would think that transparency inside the process helps. Including why it is stalled would reduce the desire to change things from frustration or misinformation.

Influence - as in priorities? I would not think that the format of the documents would be at the whim of hidden people doing hidden communications.

In 10 years, I kinda hope some new awesome technology comes out and things have to get updated. Just because I like new tech.

-- 
Doug Royer - (http://DougRoyer.US) [email-masked] 714-989-6135

---

From: Bob Hinden <[email-masked]>
Date: Mon, 25 May 2020 17:16:30 -0700

Mike,

Overall I like your proposal for RFC Series editorial board (RSEB).  It would be a nice replacement for the current IAB/RSOC structure.

I am not too troubled by the RSEB approving non-publication as it would have to be a very extenuating situation for that to happen and given the makeup of the group.

Bob

> On May 24, 2020, at 5:35 PM, Michael StJohns <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 May 2020 13:28:39 +1200

> On 5/24/20 6:35 PM, Michael StJohns wrote:
...
> I have not tracked a specific draft through the process in a long time. I would think that transparency inside the process helps. Including why it is stalled would reduce the desire to change thing…

To me, the IETF data tracker and the RFC Editor queue are quite explicit. Yes, you can always ask "Why has my document been in RFC-EDITOR state for 8.9 weeks?" but you can't really expect that level of detail to be exposed in the tracking system.
 
> Influence - as in priorities? I would not think that the format of the documents would be at the whim of hidden people doing hidden communications.

It never has been. The old format was simple and always well described and the new format was openly designed in gory detail.

Regards
   Brian

---

From: Michael StJohns <[email-masked]>
Date: Mon, 25 May 2020 21:34:54 -0400

On 5/25/2020 3:49 PM, Eliot Lear wrote:
>>
>> Secondly, on the matter of who appoints the ISE, it would be helpful 
>> if you consider the context in which I suggested this.   My 
>> suggestions were meant to devolve the IAB from overall control of the 
>> RFC System and the change in appointment/approval of the ISE was in 
>> that vein. Right now, the IAB appoints the RSE, the ISE and the IAB 
>> stream manager.  They also appoint the IRTF chair who appoints the 
>> IRTF stream manager.  In other words, out of 5 people, the IAB 
>> appoints or indirectly appoints 4.
>>
>
> For one to take this view, one has to be of the opinion that the 
> streams are part of the RFC Editor function.

Hi Eliot -

Kudos on your taking up mind reading as a new educational task, but I'd 
suggest you ask for your money back as I do not have that opinion.

The streams today feed the RFC publication system. They aren't part of 
the editor function (except maybe the ISE as the ISE unlike other stream 
managers well ... edits), but it would foolish in the extreme to not 
consider their needs and how they might influence the publication system 
on a tactical level.

Later, Mike

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 May 2020 20:05:06 -0600

> To me, the IETF data tracker and the RFC Editor queue are quite explicit. Yes, you can always ask "Why has my document been in RFC-EDITOR state for 8.9 weeks?" but you can't really expect that leve…

I would expect basic status. "waiting for manpower to start it", "Waiting for answers to questions from ...", "waiting for external zzz to happen...", "being tweaked ..."

As I have no clue how they internalize the process, I would not know what specifically to want. Maybe just a comment saying "if you have waited more that 8.8 weeks, send us an email to find out why"?  Perhaps a live automated graph of average process times? Something other than a black hole. Or maybe I just don't know where to look?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 May 2020 14:39:38 +1200

On 26-May-20 14:05, Doug Royer wrote:
> As I have no clue how they internalize the process, 

Well, to focus on this particular state, the /about/queue page says: "RFC-EDITOR = Undergoing final internal review before AUTH48" and in the queue there are 48 documents ranging from 0.7 to 11.9 weeks in that state.

There isn't (to my knowledge) a GUI so I used grep, sort and wc. However, those data tell me that whoever does that final review is backlogged.

I don't see any lack of transparency here, although there could certainly (in theory) be a nice GUI that would be easier to use than the raw list.

(There is a summary table at https://www.rfc-editor.org/reports/CurrQstats.txt
but that confounds RFC-EDITOR and RFC-EDITOR*R which is a different state.)

> I would not know what specifically to want. Maybe just a comment saying "if you have waited more that 8.8 weeks, send us an email to find out why"?  Perhaps a live automated graph of average process times? Something other than a black hole. Or maybe I just don't know where to look?

Well, I hesitate to send nag emails when the recipient is already backlogged. It can literally only make things worse.

And for our business here: is progress-chasing at the RPC a job for the RSE, or for IETF LLC that holds the RPC contract?

Regards,
    Brian

---

From: Christian Huitema <[email-masked]>
Date: Mon, 25 May 2020 21:53:16 -0700

> And for our business here: is progress-chasing at the RPC a job for the RSE, or for IETF LLC that holds the RPC contract?

The current structure is a little weird. The RSE is in theory in charge,
but in practice is not managing contracts or budgets. Things would be
clearer if the LLC was clearly in charge of what amounts to executing a
contract according to performance targets, and if the RSE could focus on
issues like formats and errata.

-- Christian Huitema

---

From: Bob Hinden <[email-masked]>
Date: Tue, 26 May 2020 10:05:19 -0700

Christian,

> On May 25, 2020, at 9:53 PM, Christian Huitema <[email-masked]> wrote:
> 

If I remember correctly, the LLC was supposed to be board, so it would be the IETF Executive Director who would do this.   Even then, does the IETF Executive Director become knowledgable about about the details of the operation of the contracts, or does some other group like what Mike proposed in the RSEB make recommendations to the LLC.

Bob

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 May 2020 10:41:48 -0700

> On May 26, 2020, at 10:05 AM, Bob Hinden <[email-masked]> wrote:
> 
> Christian,
> 

Let's set aside the discussion of whether we need a special board and just look at the RFC function. In the current state, the RSE proposes a set of metrics to evaluate the RPC, in terms of delays and load such as number of documents or pages per month, and the RSE also provides a monthly report showing how the RPC is meeting the negotiated metrics. And then the RSE is supposedly evaluated on how well the RPC performs.

IMHO this setup is fraught with latent conflicts. These conflicts only appear of course during times of tension, such as when RPC productivity is affected by the arrival of big document clusters, or by spec changes that require retooling and retraining. When that happens everybody gets frustrated. Document authors and the IESG resent the long publication delays. The RSE is in theory in charge but cannot easily increase the RPC budget. The RPC is doing its best but does not control the incoming load or the changes in tools. The tools team gets to deliver on the new spec with the old manpower allocation. Etc.

I think we have to address the root causes of these frustrations. I think that means separating clearly the specification functions of the RSE and the production functions of the RPC, the latter being controlled by the LLC without squeezing the RSE in the middle.

-- Christian Huitema

---

From: Bob Hinden <[email-masked]>
Date: Tue, 26 May 2020 12:56:52 -0700

Christian,

> On May 26, 2020, at 10:41 AM, Christian Huitema <[email-masked]> wrote:
> 
> 

To some degree it like the contract for the Secretariat.   The LLC holds the contract, but they are doing work for the IESG.   At a high level if the IESG is happy with the secretariat, it’s good.  Might be a good model for the RFC Series.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 May 2020 08:49:42 +1200

Below...
> To some degree it like the contract for the Secretariat.   The LLC holds the contract, but they are doing work for the IESG.   At a high level if the IESG is happy with the secretariat, it’s good.…

If it's working for the IESG/Secretariat relationship, yes. Maybe we should check with the IESG?

Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship is *not* working?

     Brian

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 May 2020 16:50:44 -0400

On 5/26/2020 4:49 PM, Brian E Carpenter wrote:
> Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship is*not*  working?

Aye.

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 26 May 2020 16:58:32 -0400

Agreed

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 May 2020 23:04:40 +0100

[As an individual]

> On 25 May 2020, at 01:35, Michael StJohns <[email-masked]> wrote:
> Hi - Elliot asked me to write my thought on what elements I might want from the outcome of this process - ideally as a delta to the current system.   It took me a while to go through the existing documents to get an idea of the written baseline.  RFC8728 and RFC8729 mainly.  I found myself in agreement with quite a large portion of those documents, especially with respect to the actual RFC Series Editor and RPC roles.  What I found myself less sanguine with were the various sections that dealt with "oversight".  To be blunt, I believe that having either the IAB or IESG directly manage other resources  or contracts is not tenable.  The criteria of "able to manage a contract or employee" is not and has never been a criteria for selection of either an IESG or IAB member
> 

That specific wording is not included, but both the IAB and IESG job descriptions ask for leadership and management skills. From the list of current and past members, I would be surprised if there was a time when they did not include several members with significant experience in managing contracts and employees.

> and the delegation of that responsibility to the RSOC does not appear to have been successful.  
> 
> My general desire is to see an RFC publication system  that retains and perhaps expands its global impact and the generally wide respect for its quality and reach.  
> I'd like the people who make up the system to be professionals with the ability to continue to help this community publish a wide range of documents that help "make the Internet work better by ... influenc[ing] the way people design, use, and manage the Internet". 
> I'd like us to treat said professionals at least as well as we treat ourselves.   
> I'd like a system that evolves over time, and that is relatively immune to influence from relatively few people over a relatively short period of time.  
> I'd like a system that's responsible and accountable to the community directly rather than through the two layers of indirection we currently have.  
> I'd like some large measure of independence to be retained by this publication system and that the member's of that system voices are heard and honored as full partners and not "just a contractor[s]”.  
Given the importance of the RFC series to the standards process, the limits of such independence would need to be very clearly specified.
> I'd like the RFC publication system to be stable in the face of unforeseen challenges and be able to gain (or regain) and retain institutional memory.  
> I'd really prefer that we don't have to do this again for another 10 years.  
> I'd also prefer that once we have an RSE, we assume we keep them (after a probationary period) until they get tired of us, or they really mess up.
That sounds suspiciously like a job for life. We have rolling contracts for other services the IETF community requires. It’s not clear why the RFC Series Editor should be different.
> Those are my desires and I could stop there.   But I though I'd provide a sketch of how things might be restructured - this is provided not as a fleshed out proposal, but as a thought experiment to…

Since it’s not clear we have agreement on the problem, specific proposals to solve it seem premature. 

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 May 2020 00:16:30 +0200

On 2020-05-26, at 04:39, Brian E Carpenter <[email-masked]> wrote:
> 
> that confounds RFC-EDITOR and RFC-EDITOR*R which is a different state

(One of the little projects that the next RSE could do as part of a continual improvement process is clean up that state system, or, more generally speaking, the way the progress is communicated.
After some little surprises, I’m no longer sure even the RPC personnel understands it fully.)

Grüße, Carsten

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 May 2020 09:59:54 +1000

> Do we agree that the current IAB/RSOC/LLC/RSE/RPC relationship is *not* working?

I agree that it's not working, but I don't think swapping out the IAB for another, similar body is going to help in any significant way. The problems are structural -- they're caused by the (lack of) description of the roles, and their relationships. If we constitute Mike's model, it'll happen again.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 May 2020 20:06:47 -0400

> carefully before pushing the button.

I submit that this pretty much what happened with Heather and it's 
really not IMHO what we want to have happen ever again.

On one hand, you have a group of people with little or no skin in the 
game - they might not get their document published, but it's not going 
to adversely affect their career and livelihood.  On the other you have 
someone who basically has to either give up a job that they hopefully 
enjoy and take pride in or bow to pressure and stay silent and perhaps 
have their name on something they find problematic.  E.g. for one side 
its like stepping in a puddle, for the other it's like drowning.

The funny thing about this is that we all agree that the RSE may 
prohibit publication of a document - we're just arguing about what 
conditions apply (e.g. small editorial, large editorial, content, 
technical, violations of physics).   I'd rather - in the words of 
someone who was eloquent on that point -

>   don't appoint an RSE who is a jerk,
> unlikely to arise in practice.

In 40 some odd years there's one apocryphal story about Jon refusing to 
publish a document.  Up until 10 years ago with the transition from ISI, 
there really was no question that the RFC Editor had the final call.  I 
don't expect there to be cases where this happens in the future, but 
that's because I lack imagination, not because I think it can't possibly 
happen.   I suggested a way forward by allowing the RSEB to be the final 
shot caller and placing a pretty high bar on that.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 May 2020 20:18:15 -0400

> And for our business here: is progress-chasing at the RPC a job for the RSE, or for IETF LLC that holds the RPC contract?

The general rule in the US at least is that you can tell a contractor 
what to do, but not how to do it.  I don't have a problem with the RSE 
being the contract monitor and technical advisor (both to the LLC and to 
the RPC) on the RPC functions.  I believe it would be unfair to tag the 
RSE with responsibility of nagging the RPC and judging their performance 
on the RPC's performance.   The main role here I think is to identify 
current and pending problems related to the RPC to the LLC and suggest 
ways to mitigate or resources (and perhaps budget) to be added. 
Alternately, we outsource everything into one contract (including the 
RSE function) and only have one place to kick when we're unhappy.  (I 
*do not* recommend this approach).

Later, Mike

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 May 2020 17:19:37 -0700

On Tue, May 26, 2020 at 5:00 PM Mark Nottingham <[email-masked]> wrote:

> >> To some degree it like the contract for the Secretariat.   The LLC
> holds the contract, but they are doing work for the IESG.   At a high level
> if the IESG is happy with the secretariat, it’s good.  Might be a good
> model for the RFC Series.
> >
> I agree that it's not working, but I don't think swapping out the IAB for
> another, similar body is going to help in any significant way. The problems
> are structural -- they're caused by the (lack of) description of the roles,
> and their relationships. If we constitute Mike's model, it'll happen again.
>

I agree with Mark here. We need to first figure out what it is we are
trying to achieve before we start designing mechanism.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 May 2020 01:22:35 +0100

Hiya,

On 27/05/2020 01:06, Michael StJohns wrote:
> prohibit publication of a document

I don't agree with that statement myself.

I think the earlier discussion seemed to indicate that
the RSE would need to go nuclear (i.e. resign) in that
situation and was not expected to have "prohibition" as
a weapon of choice. The RSE ought have a bunch of ways
of pushing back if one of the set of streams starts asking
for gibberish to be published, but no, I don't buy a veto,
which is how I read your mail.

Cheers,
S.

PS: I do think the IAB screwed up in the events that lead
to Heather's resignation. I hope we don't conflate things
too much but extending the RSE's powers in that way solely
based on that IAB screw-up doesn't seem like a considered
plan to me.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 May 2020 20:50:08 -0400

I do not know whether I agree or disagree.
Until the mess that led to Heather's resignation, I thought the 
structure was working pretty well.

So I strongly suspect that the forms of "not working" that various 
people want to solve are quite different.  Without specifying what was 
not working, I do not know if I agree or disagree with the claim it is 
or is not working.

Yours,
Joel

On 5/26/2020 8:19 PM, Eric Rescorla wrote:
> 
> 
> On Tue, May 26, 2020 at 5:00 PM Mark Nottingham <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     On 27 May 2020, at 6:49 am, Brian E Carpenter
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>      >
>      >> To some degree it like the contract for the Secretariat.   The
>     LLC holds the contract, but they are doing work for the IESG.   At a
>     high level if the IESG is happy with the secretariat, it’s good. 
>     Might be a good model for the RFC Series.
>      >
>     I agree that it's not working, but I don't think swapping out the
>     IAB for another, similar body is going to help in any significant
>     way. The problems are structural -- they're caused by the (lack of)
>     description of the roles, and their relationships. If we constitute
>     Mike's model, it'll happen again.
> 
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 May 2020 13:33:13 +1200

> not working, I do not know if I agree or disagree with the claim it is 

I would guess that we've all suffered matrix management at some point
in our lives. If so, we also know that it works as long as people are
reasonable, and stops working when they're not. So I suggest that our
goal should be to carefully minimise the matrix component of the structure;
it seems impossible to reduce it to zero.

    Brian

---

From: Ben Campbell <[email-masked]>
Date: Tue, 26 May 2020 20:34:58 -0500

> On May 26, 2020, at 7:06 PM, Michael StJohns <[email-masked]> wrote:
> 
[…]

> The funny thing about this is that we all agree that the RSE may prohibit publication of a document - we're just arguing about what conditions apply (e.g. small editorial, large editorial, content, technical, violations of physics).   I'd rather - in the words of someone who was eloquent on that point -

In retrospect, I do not agree that the RSE should be able to veto publication of an IETF stream document, period.  I previously thought it might be reasonable for the RSE to do so for editorial issues, but I no longer think that. I think the IESG should be able to insist on publishing anything on the IETF stream. The recourse for that should be the same as the recourse for any other IESG action.

So, no, I don’t think we all agree on that point.

[…]

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 May 2020 21:47:19 -0400

On 5/26/2020 8:19 PM, Eric Rescorla wrote:
>     LLC holds the contract, but they are doing work for the IESG.   At
>     a high level if the IESG is happy with the secretariat, it’s
>     good.  Might be a good model for the RFC Series.
>     >
>     way. The problems are structural -- they're caused by the (lack
>     of) description of the roles, and their relationships. If we
>     constitute Mike's model, it'll happen again.
>
>

The problems aren't actually publicly structural, they appear to be 
deeply embedded in how the IAB managed this task.  Given that the 
general response for details on why things were done is "its a personnel 
matter" and the lack of a transparent explanation for how things went 
wrong from their point of view, we need to give the current structure up 
as lost and figure out something else.

Here's where I found active problems with the IAB:    The scheduling of 
the RFC++ BOF without reference or involvement of the RSE at the time; 
the wholesale replacement of RSOC members who had served well and 
consisted of substantially more than 60% of the institutional knowledge 
of the "new" RFC model again without reference to the RSE; the 
constructive termination of the RSE by the RSOC with the explanation 
that "we're going to re-run the selection process early because we want 
to make sure we have options" - an explanation that still makes no 
sense; and the failure of the IAB exercise its oversight of the RSOC or  
to take any action to try and mitigate the actions of the RSOC - I note 
the RSOC is still intact.   The problem we have here is that the 
community has no sway over the RSOC, and that it would require wholesale 
recalls of the IAB to reach through to address RSOC issues.  That needs 
to change.

I do understand the IAB has a bit of paralysis due to the hue and cry 
we've raised and is attempting to keep in the background and hopefully 
let the community come to a better solution and I do appreciate that.  
That still doesn't argue for the IAB retaining the oversight function in 
any manner.  In case I haven't been clear, this is primary to what I 
believe we need to achieve.

With respect to the mechanism I proposed - as I said - it's a thought 
experiment to show there are workable alternatives to what we're 
currently doing.    I don't expect that the RSEB would be a "similar 
body" to the IAB as Mark suggests, but one focused ONLY on the RFC 
publication system and responsible to the community directly.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 May 2020 21:56:41 -0400

On 5/26/2020 9:34 PM, Ben Campbell wrote:
> I think the IESG should be able to insist on publishing anything on 
> the IETF stream. The recourse for that should be the same as the 
> recourse for any other IESG action.

I did not see that coming.  You really don't need an RPC or an RSE then 
- just run your final document through an ID to RFC filter and you're 
done.   Or hire someone to do that?

Later, Mike

---

From: Adam Roach <[email-masked]>
Date: Tue, 26 May 2020 21:05:12 -0500

On 5/26/2020 8:56 PM, Michael StJohns wrote:
> I did not see that coming.  You really don't need an RPC or an RSE 
> then - just run your final document through an ID to RFC filter and 
> you're done.   Or hire someone to do that? 

While I expect that the model Ben has in mind here is "the RPC does its 
best to edit a document, but the go/no-go decision ultimately lies with 
the stream manager," there's also a much bigger question of what the 
purpose of the RSE role *is*. This really gets to the core of the issue 
that Larry raised earlier today.

/a

---

From: Ben Campbell <[email-masked]>
Date: Tue, 26 May 2020 21:22:13 -0500

> On May 26, 2020, at 9:05 PM, Adam Roach <[email-masked]> wrote:
> 
>> I did not see that coming.  You really don't need an RPC or an RSE then - just run your final document through an ID to RFC filter and you're done.   Or hire someone to do that? 
> 
> 
> While I expect that the model Ben has in mind here is "the RPC does its best to edit a document, but the go/no-go decision ultimately lies with the stream manager,”

Yes, exactly. I expect that, if an RPC has issues with an IETF stream document, they would do everything in their power to correct the issues. But “unilaterally refuse to publish” should not part of that toolbox.

> there's also a much bigger question of what the purpose of the RSE role *is*. This really gets to the core of the issue that Larry raised earlier today.
> 

I agree that is a bigger question :-) 

Ben.

---

From: Doug Royer <[email-masked]>
Date: Tue, 26 May 2020 20:23:40 -0600

> That sounds suspiciously like a job for life. We have rolling contracts for other services the IETF community requires. It’s not clear why the RFC Series Editor should be different.

As they are not Microsoft Word editors that can be replaced by someone just bubbling out of school, I would think that it would be in everyone's best interest if they could last for a long time. The learning curve has to be very large.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 May 2020 19:28:04 -0700

> done.   Or hire someone to do that?

Well, as has been noted, some other SDOs (for instance WHATWG) more or less
do this, but I don't think that that really follows.

While not a direct comparison, if I self-publish a book, I might hire a
copy editor or a technical editor, but the ultimate decision about the
contents of the book would be mine. That doesn't mean I didn't need the
copy editor.

-Ekr

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 May 2020 07:00:12 +0100

> On 27 May 2020, at 02:34, Ben Campbell <[email-masked]> wrote:
> 
> 
> 
>> On May 26, 2020, at 7:06 PM, Michael StJohns <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> […]
> 

+1

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 May 2020 09:06:23 +0100

[As an individual]

> On 27 May 2020, at 07:00, Colin Perkins <[email-masked]> wrote:
>> On 27 May 2020, at 02:34, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:

To elaborate: I’d agree that the RFC Editor ought to be able to push back, perhaps quite strongly, to say “this is too poorly written to publish”, but ultimately an editorial veto should not be possible.

Similarly, I do not believe the RFC Editor has 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 (hate speech, obscenity, indecency, etc.), how it should be handled, and when/if the RFC Editor can refuse publication on such grounds. 

There will certainly be legal restrictions on what the RFC Editor can publish, and the community needs to understand those. 

Colin

---

From: "John Levine" <[email-masked]>
Date: 27 May 2020 22:19:50 -0000

In article <[email-masked]>,
Doug Royer  <[email-masked]> wrote:
>> That sounds suspiciously like a job for life. We have rolling contracts for other services the IETF
>community requires. It’s not clear why the RFC Series Editor should be different.
>
>As they are not Microsoft Word editors that can be replaced by someone just bubbling out of school, I would
>think that it would be in everyone's best interest if they could last for a long time. The learning curve has
>to be very large.

Although the RFC production center contract is up for renewal every
few years, in practice the same group of people have been doing it for
decades. It would be very difficult to replace or recreate their
skills and experience.

R's,
John
-- 
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: Mark Nottingham <[email-masked]>
Date: Thu, 28 May 2020 10:51:30 +1000

> decades. It would be very difficult to replace or recreate their

Agreed. They are 'contractors' in the sense that they are on contract, but they have considerable context about our needs that's hard to replace.

So, this is another interesting comparison. I've never heard of anyone from our community treating the RPC badly in their interactions, and would be appalled if that happened; I think it's safe to say that there's an expectation in our community that the RPC are treated as professionals, and there would be at least social sanctions against someone who violated that. We respect the RPC both as people and professionals; they do hard work cleaning up our editorial messes.

That respect, however, doesn't translate to giving them authority over the documents; they make editorial suggestions, and authors, WG chairs and ADs make decisions about the final content of the document (at least in the IETF stream). As was mentioned yesterday, there are clear roles and expectations for all parties, and so things work smoothly. Describing the RPC as 'independent' doesn't really make sense, except in one or two narrow technical senses (e.g., they are an independent legal entity contracted to us).

With this in mind, can someone who believes that the RSE should be independent and/or have some form of authority explain what motivates the difference to the relationship with the RPC? That might help move the discussion along.

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 May 2020 14:11:39 +1200

> With this in mind, can someone who believes that the RSE should be independent and/or have some form of authority explain what motivates the difference to the relationship with the RPC? That might…

It's hard to answer that without erecting a strawman, so here we go, treating the style guide as a benchmark for authority:

The RPC announces that instead of using the Chicago Manual of Style, they are switching to using Lynne Truss's "Eats, Shoots & Leaves", and all American spellings will be replaced by British spellings, and all occurrences of "ize" will be replaced by "ise".

(The current spelling policy is at https://www.rfc-editor.org/rfc/rfc7322.html#section-3.1 )

Who has authority to tell them whether that's OK or not? It really can't be IETF LLC, and the IETF bodies like the IAB are not subject matter experts. Bikeshedding such issues on [email-masked] doesn't seem like a good idea. An RSE who is explicitly responsible to the community and who has relevant expertise seems like the right answer. There are certainly less trivial issues of course (like what "archival" means in the library world) that lead to the same answer IMHO.

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 May 2020 19:20:37 -0700

On Wed, May 27, 2020 at 7:11 PM Brian E Carpenter <
[email-masked]> wrote:

> It's hard to answer that without erecting a strawman, so here we go,
> treating the style guide as a benchmark for authority:
>
> The RPC announces that instead of using the Chicago Manual of Style, they
> are switching to using Lynne Truss's "Eats, Shoots & Leaves", and all
> American spellings will be replaced by British spellings, and all
> occurrences of "ize" will be replaced by "ise".
>
> (The current spelling policy is at
> https://www.rfc-editor.org/rfc/rfc7322.html#section-3.1 )
>
> Who has authority to tell them whether that's OK or not? It really can't
> be IETF LLC, and the IETF bodies like the IAB are not subject matter
> experts.

Actually, it's not at all clear to me that the IAB can't decide this.

Yes, this is a topic that involves technical issues, but it's not at all
uncommon to have someone make decisions on topics that involve technical
issues in which they are not subject matter experts (indeed, this is
arguably the norm in companies, governments, etc.)  The way that this
usually works is that the decision maker gets briefed on the issue by
subject matter experts and makes a decision based on that briefing.

I don't want to overindex on your example, but I'd note that spelling
conventions are actually not really the kind of question on which subject
matter expertise is particularly helpful: after all, both the American and
British spellings are legitimate and it's a judgement call, not a matter of
technical right or wrong which to choose. This is in fact the case with
many questions which involve technical issues.

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Thu, 28 May 2020 16:47:59 -0400

> Agreed. They are 'contractors' in the sense that they are on contract, but they have considerable context about our needs that's hard to replace.

Actually, no.  They are employees of a contractor - this is an important 
difference.  In models like this, what happens is the contractors 
change, and the employees are generally hired away by the new 
contractor.   The employees are insulated from adverse actions on the 
part of the contracting entity (e.g. us collectively) by their 
relationship with the contracted entity (e.g the RPC).

> So, this is another interesting comparison. I've never heard of anyone from our community treating the RPC badly in their interactions, and would be appalled if that happened; I think it's safe to…

As employees of a contract managed by the ED and the LLC no individuals 
within the IETF or even the IETF leadership have any ability to twiddle 
directly with an RPC employee.   The recourse is for the ED or LLC to 
talk to the RPC manager who is responsible for executing the contract.  
If the ED or LLC are unable to get satisfaction that way, then they may 
take legal action  - if and only if there's a contract violation.

In practice, it's in the best interest of the IETF that the ED/LLC and 
RPC act together as collaborators rather than in a 
me-boss-you-contractor relationship and the "never heard of anyone...." 
comment is indicative of that model.  Sadly, that's seems to be anathema 
as a model for the IETF dealing with the RSE.

>
> That respect, however, doesn't translate to giving them authority over the documents; they make editorial suggestions, and authors, WG chairs and ADs make decisions about the final content of the document (at least in the IETF stream). As was mentioned yesterday, there are clear roles and expectations for all parties, and so things work smoothly.
The RPC has a contract which spells out the boundaries.  And even the, 
the IETF has no direct control over *how* things are done.  I'd actually 
have to look at the wording of the RPC contract to see if the lines are 
drawn as clearly as you think they are.
>   Describing the RPC as 'independent' doesn't really make sense, except in one or two narrow technical senses (e.g., they are an independent legal entity contracted to us).

*sigh*   Independent:  "Free from outside control; not depending on 
another's authority".  I'd argue strongly that - within the boundaries 
of the contract - the RPC members are independent of IETF control.   
They may not be independent from their managers, but they certainly 
don't have to worry about day to day interference from the IETF with 
their core responsibilities.  The way the relationship is structured 
provides some measure of protection.

> With this in mind, can someone who believes that the RSE should be independent and/or have some form of authority explain what motivates the difference to the relationship with the RPC? That might…

Unfortunately, the structure that the IAB set up to deal with the RSE 
had few if any of these restraints and in a few instances stepped over 
the line into the space that the community had agreed belonged to the RSE.

The US IRS says this about independent contractors: "The general rule is 
that an individual is an independent contractor if the payer has the 
right to control or direct only the result of the work and not what will 
be done and how it will be done."   So maybe what I should be asking you 
is "what is the result of the work and how should the community direct it?"

Jay - in the chat transcript of the last call - argued that he didn't 
have independence, he had defined lines of authority.  I would argue 
that these are the same unless the lines of authority may be changed at 
any time by fiat.  It may be that he doesn't have independence to do his 
job - but that would actually be a sad commentary on the relationship.

Later, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 May 2020 08:59:18 +1200

> In models like this, what happens is the contractors 
> contractor.
And, importantly, hiring nominated key staff can be a *requirement* of the RFP. I've done RFPs for services where we did that.

Regards
   Brian Carpenter

---

From: Jay Daley <[email-masked]>
Date: Fri, 29 May 2020 09:02:01 +1200

> On 29/05/2020, at 8:47 AM, Michael StJohns <[email-masked]> wrote:
> 
> Jay - in the chat transcript of the last call - argued that he didn't have independence, he had defined lines of authority.  I would argue that these are the same unless the lines of authority may be changed at any time by fiat.  It may be that he doesn't have independence to do his job - but that would actually be a sad commentary on the relationship.

I didn’t argue that I don’t have independence, what I said was that framing this as 'independence' is the wrong way to look at it as a) it masks the details of the issues; and b) takes us into various ratholes about the meaning of independence.

A far better way to look at it, which applies to me, is that when the following chain is in place, things work

1.  clear governance (both for goal setting and performance management)
2.  clear goals
3.  clear delegated authorities
4.  clear values (how things should be done)

Jay

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