Subject: [Rfced-future] Fwd: I-D Action: draft-carpenter-rfced-model-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Aug 2020 15:49:21 +1200

Here's my suggested RFC Editor model for the future.

For reasons that escape me, it didn't emerge in v3 format, but apart from that it has much the same structure as draft-thomson-rfced-model-01 and (with permission) much of the same text. 

I have put the v3 html version at https://www.cs.auckland.ac.nz/~brian/draft-carpenter-rfced-model-00.html

The main differences from Martin's draft are:

a) There is a free-standing open RFC Series Advisory WG, under ISOC auspices.
b) There is a senior professional RFC Series Advisor, who has no line management duties.
c) No IAB program is needed.

All comments welcome, of course.

Regards
    Brian Carpenter

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-rfced-model-00.txt
Date: Thu, 20 Aug 2020 20:30:42 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Alternative Proposed Model for RFC Editing and Publication
        Author          : Brian E. Carpenter
	Filename        : draft-carpenter-rfced-model-00.txt
	Pages           : 19
	Date            : 2020-08-20

Abstract:
   The finishing process for a document that is approved for publication
   as an RFC currently involves a somewhat detailed and lengthy process.
   The system that executes that process involves a number of different
   actors, each bringing competency with different aspects of the
   overall process.  Ensuring that this process functions smoothly is
   critical to the mission of the organizations that publish documents
   in the RFC series.

   This document proposes a framework for that system that aims to
   provide clear delineations of accountability and responsibility for
   each of the actors in this system.  It would require significant
   updates to RFC 8728 and RFC 8729, and minor updates to RFC 2850 and
   RFC 7841.

   Discussion of this document takes place on the RFC Editor Futures
   mailing list ([email-masked]).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-rfced-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-rfced-model-00
https://datatracker.ietf.org/doc/html/draft-carpenter-rfced-model-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Aug 2020 07:56:10 +0200

> b) There is a senior professional RFC Series Advisor, who has no line management duties.

As should be obvious from my previous statements, I think that this is good.

I’m still having a hard time imagining finding the senior professional that wants to be that RSA.

E.g., in the equivalent of the most recent ietf.org kerfuffle, the RSA would have needed to deal with an unruly RSAWG instead of just setting sane publishing policy.
That is of course good in the sense of understanding the community consensus about such a piece of policy, but I can’t imagine I would have wanted to have had the job of the adult in the room.

Grüße, Carsten

---

From: Brian Rosen <[email-masked]>
Date: Fri, 21 Aug 2020 12:36:20 -0400

Thanks Martin and Brian. 

Others, please have initial proposals out by end of next week.  Then we will schedule interims to discuss.

Brian and Eliot

> On Aug 21, 2020, at 1:56 AM, Carsten Bormann <[email-masked]> wrote:
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

From: Michael StJohns <[email-masked]>
Date: Fri, 21 Aug 2020 13:44:02 -0400

> As should be obvious from my previous statements, I think that this is good.
Hi Carsten - can you clarify the above was what you meant?  I'm asking 
because there appears to be a disconnect between that statement and what 
follows.
> That is of course good in the sense of understanding the community consensus about such a piece of policy, but I can’t imagine I would have wanted to have had the job of the adult in the room.

Nor I, nor any senior person with a lick of self-esteem.

Later, Mike

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Aug 2020 19:49:30 +0200

Hi Michael,

> On 2020-08-21, at 19:44, Michael StJohns <[email-masked]> wrote:
> 
> Hi Carsten - can you clarify the above was what you meant?  I'm asking because there appears to be a disconnect between that statement and what follows.

I’m assuming the line management is less of an issue than the ability to simply make decisions.  (Or what is the disconnect you are seeing?)

> Nor I, nor any senior person with a lick of self-esteem.

So I’m looking for the power to go ahead with a decision that is the right thing to do, in the specific portfolio defined for that advisor, with a consultation as opposed to an RSAWG consensus process.

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Fri, 21 Aug 2020 13:55:01 -0400

> I’m assuming the line management is less of an issue than the ability to simply make decisions.  (Or what is the disconnect you are seeing?)

You seemed to say "I think its good that the RSA has no line management 
responsibilities, but that I can't imaging finding any RSA who would 
enjoy that job."    It's possible I was conflating "line management" as 
being the opposite of a "strict advisor" role with no "ability to simply 
make decisions" instead of the middle ground I get from your above 
sentence.    Below clarifies this and matches up with what I thought you 
were getting at.

Thanks - Mike

---

From: Mirja Kuehlewind <[email-masked]>
Date: Sat, 22 Aug 2020 10:25:18 +0200

Hi Carsten,

One quick question below.

> On 21. Aug 2020, at 19:49, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Michael,
> 

I can see why the person in the advisor role would want to take decision with consultation only or how it can be hard to find someone who is expert in the publishing domain but also understands our usually consensus process, however, I don’t really understand why we as a community would want that. I think it would be good for strategic decisions to have someone who can declare consensus (that would be the chairs or could eventually be also someone noncom selected) and then also a real advisor role who brings in expertise but doesn’t need to carry the responsibility. I believe it was an interesting experience for our last RSE to get to know our community and I can image it might also be something interesting for an advisor role. Or what kind of decisions are we actually taking about if it is not daily business/line manager decisions but maybe you also don’t mean strategic decisions?

Mirja

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Aug 2020 09:11:49 +1200

> I can see why the person in the advisor role would want to take decision with consultation only or how it can be hard to find someone who is expert in the publishing domain but also understands our…

Right. In my model the Advisor doesn't take decisions; the Advisory WG takes decisions by our very own rough consensus process. The Advisor gives advice.

    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 22 Aug 2020 23:26:51 +0200

Hi Mirja,

> On 2020-08-22, at 10:25, Mirja Kuehlewind <[email-masked]> wrote:
> 
> I don’t really understand why we as a community would want that.

There are many angles of thought that lead to the same conclusion, and I can only hope to touch the surface in an email.
Note that I’m going to trample on some popular myths here, so please excuse me if you (collective you) get a bit excited when reading this.

(1) The myth of rough consensus and running code.

That mantra is definitely the foundational myth of the IETF, and I’m not setting out to destroy it here.  But we should be wary of its applicability and its limitations.

(1a) Rough consensus works because we have a meritocracy, not a democracy.  We give leadership positions to people from within the community that we have observed for a while and who we think know their part about technology and technology management and what works and what doesn’t.  This is *not* perfect, but it is working reasonably well to sustain a more-than-third-of-a-century self-governing body.  (There are also some checks and balances needed to make this work.)

(1b) We can’t recruit the leadership we need for a publishing strategy out of the IETF and its usual meritocracy process. It is great that we have a few people who do have some background here, but in the end we are all armchair pilots when it comes to publishing.

(1c) A corollary: The subjects of our decisions usually involve technology.  There is a cold, hard requirement that “It Has To Work” (RFC 1925), and there are indicators and metrics we can use beyond that.  So whatever follies and unhealthy fashions we succumb to, are ultimately shot down by reality.  That is much worse on the publishing side.  What indicators do we use there?  Number of RFCs sold?  See also (3).

(1d) Group-Think.  I’m old enough to have been in dozens of meetings where a course of action seemed inevitable and we talked ourselves into a consensus to go forward even though many people knew intuitively that this was the wrong way forward (often actually catastrophically so).  While individuals are fallible as well, setting someone up to be a counterpoint, with the power to prevent, is often a good idea.  (Actually, the role we culture for ADs in the document approval process is just that, and, yes, that can also be annoying.)

(1e) Incentives for disturbing the process.  A consultation cannot be hijacked as well as a consensus process.  Setting up the system so it is less prone to hijacking saves a lot of effort, including on the side of the potential hijackers.

(2) The myth of direct vs. representative democracy.

The IETF is not run as a democracy, so the analogies are limited.  
They are still rather relevant.

We have a couple millenniums of experience with various forms of governance.
We know that direct democracy is vulnerable to fashions (well, any democracy is, direct is just less moderated).  Understanding the 2014 Swiss immigration initiative, Brexit, or even the strong popular vote for a US president in 2016 is beyond this little missive.  But clearly, the IETF would be rather prone to engineer its little Brexit on the RFC series based on a fleeting fashion and some ideas that sound good in a 5-paragraph email message but don’t survive reality (or even thorough thinking).  (Insert my usual reference to the fallacy of “process confabulation” here as well.)

(3) The value proposition (a.k.a the myth of “let’s put it up on github and be done”).

We need to work on the reputation of the RFC series.  This is, of course, heavily linked to the reputation of its main stream, the IETF stream, and thus the IETF, which is outside the scope of this discussion.
On the reputational side, mistakes linger.  (I’m at a university that was a late child of the 1968s movement, and even though the unfortunate parts of that heritage were mostly overcome in the 1980s, people out there still think everybody here is a red sock.)  That is a perspective that is somewhat foreign to technologists, where a new sow is run through the village (please excuse my German) every three years.  (Yes, we do need to help run the Internet, but the merit of that is less reliant on its reputation than on what it actually can do.)

I could go on and on.
Axiom: The RFC series is an asset that took 50 years to build.
Let’s not squander it.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Aug 2020 09:57:28 +1200

On 23-Aug-20 09:26, Carsten Bormann wrote:
...
> Axiom: The RFC series is an asset that took 50 years to build.

Yes. Hence https://tools.ietf.org/html/draft-carpenter-rfced-model-00#page-16

   Brian

---

From: Jay Daley <[email-masked]>
Date: Sun, 23 Aug 2020 10:49:46 +1200

> On 22/08/2020, at 5:49 AM, Carsten Bormann <[email-masked]> wrote:
> 

By analogy the ED/LLC can consult on certain issues rather go through a consensus process and that is made possible by a set of consensus guidance on when/what to consult about (writing this in a mobile device so I can’t list the RFCs that contain that guidance right now) and clear oversight in the form of the LLC board with all the safeguards of NomCom, appeals, recalls etc. 

For this role, either it stay standalone in which case that structure needs to be replicated, or the role is fitted into an existing structure. I understood an earlier suggestion that the LLC appoint a PM to fit with the latter option. 

Jay

-- 
Jay Daley
IETF Executive Director

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 24 Aug 2020 16:25:56 +0200

Hi Brian,

> On 22. Aug 2020, at 23:11, Brian E Carpenter <[email-masked]> wrote:
> 

Yes, I believe I understood your and Martin's proposal here but I got the impression that Carsten has a different view on what the role should be and was trying to clarify this.

However, now that I actually had more time to look at your draft, I do have a comment: I not convinced that ISOC is the right body here to put in charge. Here are my reasons:

1) Reading Andrews recent mail on the list on nomcom eligibility list where he says that he might become more and more detached from the IETF community and therefore has a hard time to find good candidate for the NomCom chair position, I’m afraid this could apply here as well. The chairs of the proposed RSAWG don’t necessarily need to be members of the IETF community but ISOC somehow needs a pool of people to select from that understand the consensus process we run in the IETF. 

2) In line with point 1, having the ISOC in generally running an RFC2418-based consensus group directly _in_ ISOC is an entirely new kind of activity and needs urgently feedback from ISOC and the Board of Trustees. I’m really not sure if such a setup actually fits well into the ISOC’s organisation otherwise.

3) More practically, if the ISOC or I guess the BoT selects the chairs of the proposed RSAWG, we need a new appeal chain because ISOC is basically our last resort so far but this would be an ISOC decision and that should also be appealable somehow.

4) And finally a point that maybe not everybody might agree with. However, we did discuss the importance of the IETF for RFC series and the other way around. Given this crucial dependency I would like to see a slightly tighter coupling here. I think we have agreement that the community that is relevant for the RFC series is larger than just the IETF, however, the IRTF, ISE, and the IAB are still closely connected to the IETF and in practice I think people who care the most of the RFC series are also somehow connected to the IETF. I think it would actually not be right to neglect this situation.

This is my personal option and not a comment in my capacity as IAB member. This is also not a comment on the IAB being the better choice or not. However, I would be interested to understand why you think the IAB is not a good choice?

I think I read in an earlier message something like the IAB is too busy already. Actually I‘m not sure how true that is (but that a separate topic to discuss) but I don’t think that would be an argument for creating something entirely new within in ISOC if that’s the sole reason.

Mirja

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Aug 2020 09:29:17 +1200

Hi Mirja,

My response is at the end...

> I think I read in an earlier message something like the IAB is too busy already. Actually I‘m not sure how true that is (but that a separate topic to discuss) but I don’t think that would be an arg…

There are really two separate arguments here. One is exactly what you say: the RFC Series is for the whole community (whatever that may be). Rooting the RFC Series in ISOC rather than in the IETF is symbolic of that. I agree with you that attaching it directly to the ISOC Board is not completely satisfactory, and that would need more work.

The second point is not so much the IAB's workload as whether the IAB should need to deal with this whole class of issue at all. Now that we have the LLC in place, why should the IAB spend any time on what is basically a distraction from the technology? Just because the IAB has done this for the last 25+ years isn't a reason. I'd like the IAB to be able to focus on Architecture. That's been my preference for 25 years, too ;-).

Both my model and Martin's involve a group that works in accordance with RFC2418. That model implies that somebody ought to act like an AD to oversee the chairs. Is that really a job for the IAB?

Regards
    Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Aug 2020 09:15:31 +0200

> The second point is not so much the IAB's workload as whether the IAB should need to deal with this whole class of issue at all. Now that we have the LLC in place, why should the IAB spend any time…

Why did you choose ISOC and not the LLC Board?

Eliot

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 25 Aug 2020 13:54:28 +0200

Hi Brian,

See below.

> On 24. Aug 2020, at 23:29, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Mirja,
> 

So I’m not sure what exactly you mean by “this whole class of issue” but given the IAB also appoints the ISE and the IRTF chair, as well as reviews RGs, I would actually say that the IAB does already deal with that.

I agree that I would also like to see the IAB focusing more on architecture but I think this is not because the IAB itself is too busy. It depends a lot on the specific people on IAB which topics are discussed and I would charterize the work of the IAB rather as identifying and flagging problem/gaps than developing technology. After all I would say that often members of the IAB are people who are deeply involved in the work in the IETF and would probably do this architectural thinking and analysis anyway but the IAB and IAB program provide a forum to anchor this work and discuss in a group. Progress on these things however often strongly depends on how busy these people are in their day jobs otherwise. However, I believe that’s rather a separate topic.

But because the members of the IAB do usually cover a board set of expertise in different areas of the IETF, usually including ex-ADs, working group chairs, and of course document authors, and have experience with interactions for all RFC streams that we have currently, I actually believe that this group of people is well set up for the task. However, I don’t necessarily want to argue for the IAB being the right choice but I definitely think it’s the better choice than ISOC. What’s missing in the current setup is a clear description of responsibilities. 

> Both my model and Martin's involve a group that works in accordance with RFC2418. That model implies that somebody ought to act like an AD to oversee the chairs. Is that really a job for the IAB?

I think this is definitely not a job for anybody in ISOC. However, I don’t see this as a challenge for the IAB. The IAB already publishes RSE related documents in the IAB stream and appoints many people in different roles, including the chairs/lead of IAB programs. Also my experience as an AD is that if you have/select good chairs, there is usually not that much additional support needed. Yes, there can be exceptional situation but those situations are also something the IAB needs to be able to handle anyway, e.g. when an appeal reaches the IAB. So not sure which part of the job you think is not appropriate for the IAB?

Mirja

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 Aug 2020 12:55:23 -0400

I don't know why Brian made the choices he did.
In my book, we carefully crafted the LLC and its board to focus on 
administrative activities.  It is not constituted around policy issues. 
We had a lot of discussion about what the remit of the LLC board should be.
Owning and serving as an appeals chain for a community-in-the-large 
policy and strategy activity seems a direct contravention of what we 
agreed in establishing the current administrative structure.

The LLC having contract oversight responsibility does seem consistent 
with the defined structure, and that aspect seems to be something most 
of the proposals agree on.

Yours,
Joel

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2020 14:58:51 -0400

In article <[email-masked]> you write:
>> The second point is not so much the IAB's workload as whether the IAB should need to deal with this whole class of issue at all.
>Now that we have the LLC in place, why should the IAB spend any time on what is basically a distraction from the technology? Just
>because the IAB has done this for the last 25+ years isn't a reason. I'd like the IAB to be able to focus on Architecture. That's
>been my preference for 25 years, too ;-).
>

Briefly putting on my ISOC board member hat, no to both.

Modern ISOC boards are very different from when Brian was on the board
20 years ago. The majority of the board is selected by the chapters
and org members, and know as little about the IETF as a typical IETFer
knows about ISOC chapters. They have neither the expertise nor the
interest to oversee the RFC series. If you asked, I'm pretty sure we
would say no.  (Well, we minus me since due to my dual role I'm
recused from anything that potentially touches the LLC.)

For the LLC, I echo Joel's comments that the LLC handles our business,
not the policy.  If there were an issue about the terms of the contract,
that's for the LLC to sort out.  Policy issues belong with the IAB or IESG.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Aug 2020 15:27:02 +1200

> Why did you choose ISOC and not the LLC Board?

Because the LLC is a contracting-out company for IETF tools and services, and the LLC Board is mandated to oversee that work. ISOC is a civil society organisation with very general goals for the good of the Internet, so I believe it is a more suitable place to oversee consensus formation for the community.

    Brian