Subject: [Rfced-future] draft-saintandre-rfced-model-01.txt

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Jun 2021 15:54:40 +0200

Everyone,

Please have a good look at Peter’s and*your*latest work before today’s 
call.  We’ve come a long way.  Now we still have a ways to go, but a 
fresh read of this draft will help us keep moving.

https://datatracker.ietf.org/doc/draft-saintandre-rfced-model/

Eliot

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Jun 2021 15:08:39 -0400

--On Monday, June 21, 2021 15:54 +0200 Eliot Lear <[email-masked]>
wrote:

> Everyone,
> 
> Please have a good look at Peter's and*your*latest work
> before today's call.  We've come a long way.  Now we
> still have a ways to go, but a fresh read of this draft will
> help us keep moving.
> 

I'm quite sure that I'm far out in the rough part of "rough
consensus" but. after studying Peter's latest draft (which I
think is excellent given the discussions) and the on-list
discussions of the last few weeks, I think we are, very
fundamentally, headed in the wrong direction with significant
philosophical problems in what we are proposing and doing.  I
would be surprised if this note changes the minds of anyone
reading it and would even be surprised if most of the group
bothers to read it at all.  However, because I see dangers in
the direction in which things are headed, I'm feeling a need to
try to summarize a perspective and set of positions that have
been raised before and largely ignored.  If I were right, most
of the discussions of recent months are not analogous to
rearranging the deck chairs on the Titanic; they are about
forming committees to develop policy for such rearrangements,
other committees to review and validate the work of the first
committee, and mechanisms for reviewing that process.  Glug,
glug,...

Core issue #1: The function of the RFC Editor Function.   The
RFC Series predates the IETF by many years.  Even though it
became the primary venue for publishing IETF work and we have
made adjustments along the line, neither RFC 5620 nor 6335/8728
fundamentally changed that model.  However, from Jon and Joyce
through at least most of Heather's tenure, decisions have been
made informally and depending on the assumption that everyone
involved is an adult with shared goals about good quality
documents and a better Internet (and ARPANET before it).  It
worked well almost all of the time; when it didn't, things got
sorted out on, more or less, a Do The Right Thing principle.  We
are now trying to make rules and structures to cover every
possible case.  That has rarely worked well, if only because it
encourage little disagreements to turn into large, formal,
decision-making processes.  In addition, the IETF part of the
puzzle is changing.  RFCs may still be the formal publication of
record, but far more, including documentation of rather
fundamental policy decisions, is being done by blogs,
statements, datatracker entries, etc.  That may be fine, but it
may suggest that some clear redrawing of boundaries is important
... and this effort is not addressing those issues.

Core issue #2: The question of expertise.  While Heather was the
first person to be in charge of the Series who came out of a
professional publications background, all of her predecessors
understood what they didn't know and were good (some better than
others, of course) at asking questions, understanding, learning,
and thinking through the answers, and then making decisions
using that advice and being willing to be accountable for it.
The new approach is modeled on IETF WGs, but ignores a
fundamental assumption built into the WG model: that a large
majority of the participants in a WG will have significant
expertise in the subject matter.  While I hope we are evolving
better ways to deliver the message, when people have spoken up
in WGs who have no ideas what they are talking about and are
persistent about it, WGs usually have ways to deal with that
behavior.   By contrast, most people who have participated
actively in the IETF for any length of time have probably
noticed that the issues that call forth the most passion and the
longest threads on the IETF list and elsewhere are those about
which people have little expertise but strong opinions of one
type or another.  What I'm about to say may smack of elitism,
putting me further into the rough, but I note that we do not
think highly of, e.g., politicians trying to design network
architectures and protocols.  If our goal is to create
structures that turn the RFC Series into something the fraction
of the IETF community who are willing and able to invest large
amounts of time on these things want (perhaps at the expense of
doing Internet technical work), then I think we are right on
track.   But, noting that subset of the IETF community is almost
certainly not representative of IETF participants generally much
less the broader Internet community, that is a very significant
change in objectives.  If we are going to do that, we should be
explicit about it.  If we are not, the idea of open
participation to anyone who wants to be involved and has the
time, with no expectations about expertise falls into the "be
careful what you wish for" category.

(3) Core issue #3: What is a standard and what is a stable
document?  While, ideally, it should not be a required part of
this discussion, it appears to me that there is an ongoing
difference of opinion in the IETF was to whether standards (and
perhaps IETF Stream documents in general) should be stable
specifications that may periodically be revised or replaced but
are otherwise threaded together with "updates" and "obsoletes"
designations (possibly supplemented by organizing documents
along the lines proposed by NEWTRK) or whether we want to move
more toward living documents that are updated in place with each
correction, changes of experience, or change in community
opinion about one or more points.  If we are going to move more
in the latter direction, it could have a profound effect on the
RFC Series, either because IETF Standards and other normative
specifications come out of the Series, dramatically changing the
mix of documents, or because the system has to adjust to a
completely different type of documents for which, e.g., the
current production model might not be correct for at least a
subset.  While a lighter-weight structure might have more
ability to adapt to such changes, the current effort to specify
details and create an elaborate discussion and approval process
seems less likely to do so, especially if the RSWG/RSAB
structure ends up not completely agreeing with, e.g., the IESG.
The solution is presumably obvious: Convene another Program or
WG to more or less start over.  Unfortunately, we are pushing
toward two years of limited functionality since the actions that
apparently convinced Heather that she didn't want more of
whatever was going on.  I think that has been very damaging and
that a repeat would be more so.  Others probably disagree but I
would ask them whether, if we can go two or more years without
an RSEA or any of the structure now proposed, should we be
trying to see what we can learn from that and devise something
much lighter weight on the basis of the experience?

(4) Core issue #4: What got us here and are we fixing it?  The
chain of events that led to this Program/Group could be seen
either as an assertion of power by some bodies over the RSE (aka
"the RSE is 'just' a contractor") or an asser5ion of authority
by groups who lacked substantive expertise (see (2) above),
neither with any transparency as far as the broader community
was concerned.  It seems to me that the new model probably fixes
the transparency problem, but does so partially by increasing
the number of non-expert people and organizational structures
with an ability to meddle and/or interfere with keeping a clear
focus on consistent objectives.  Is that a solution?  For those
who think it is, consider how you would feel if you took a
network engineering job, discovered that you were managed by a
committee or two, none of whose members understood your job or
your areas of expertise, and whose objectives might shift over
time (either because of changing membership or to convince
themselves or others that they were being useful).

I have a longer list, but it is probably better that I keep this
rant (comparatively) short and get it out.

Do I have alternate suggestions?  Yes, but they depend on
changes in the decisions about the issues identified above even,
or especially, when those decisions were made implicitly or
because we started erecting structures without really addressing
them in a way that made those decisions moot.

Grumpily and from, probably, far out in the rough,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jun 2021 08:28:09 +1200

John,

I will respond later in more detail (e.g. when I'm no longer trying
to attend to the Webex meeting), but I'd like to say one thing now:

> more toward living documents

Yes. And as you know better than anyone, this goes back 20 years,
and the bulk of the IETF and/or IESG has never wanted to engage.

So IMNITLHO**, we (rfced-future) need to set that concern aside
for the purposes of this discussion, and they (the IETF) need to
put their own house in order. If the IETF comes back with clearly
defined requirements for a new kind of document, that may or may
not be a job for the RFC series.

    Brian Carpenter

** in my not in the least humble opinion

---

From: S Moonesamy <[email-masked]>
Date: Tue, 22 Jun 2021 09:54:35 -0700

Hi John,
>was concerned.  It seems to me that the new model probably fixes

Yes.

>themselves or others that they were being useful).

It takes some time to understand what the objectives are and to be 
consistent in moving towards them.  During that time there may be new 
persons coming on board and old persons leaving.  There will be 
persons meddling or interfering.  The second option, to avoid 
meddling, is to avoid bringing in new persons.  I prefer the first 
option as it can inject fresh input into the group.

I am not convinced that the group should be modeled on the IETF 
WG.  Such groups do not work well when discussing non-technical matters.

One of the points which should, in my opinion, be reviewed is the 
role of the IAB.  What role does it having in the model, as proposed 
in draft-saintandre-rfced-model-01?

The performance targets are negotiated by the IETF LLC.  That dilutes 
the authority of the
RSE. In addition, it does not allow for performance targets to be 
cascaded from the RSE's targets.

Some of the "process" stuff could be procedures instead of something 
specified in a RFC.

The question which comes to mind is whether the main concern is about 
accountability or entity politics sprinkled with a semblance of transparency.

Regards,
S. Moonesamy

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Jun 2021 13:16:08 -0400

Brian,

TL:DR summary: We agree that this Program should not try to
solve, or even seriously engage with that third issue.  It could
easily be a prince, perhaps an emperor, among rat holes.
However I believe this effort should be mindful of it to avoid
changing the RFC Editor Function in a way that would
overconstrain that discussion when and if it occurs.

    -----

We don't disagree about what should be done in the near term,
but let give a slightly different perspective....

--On Tuesday, June 22, 2021 08:28 +1200 Brian E Carpenter
<[email-masked]> wrote:

> John,
> 
> I will respond later in more detail (e.g. when I'm no longer
> trying to attend to the Webex meeting), but I'd like to say
> one thing now:
> 
>> difference of opinion in the IETF was to whether standards
>> (and perhaps IETF Stream documents in general) should be
>> stable specifications that may periodically be revised or
>> replaced but are otherwise threaded together with "updates"
>> and "obsoletes" designations (possibly supplemented by
>> organizing documents along the lines proposed by NEWTRK) or
>> whether we want to move more toward living documents

> Yes. And as you know better than anyone, this goes back 20
> years, and the bulk of the IETF and/or IESG has never wanted
> to engage.

Yes, but it would be equally reasonable to say that some of
these issues with the RFC Editor function go back 20 (or 30 or
more) years, that the bulk of the IETF has never wanted to
engage in depth, and that we are where we are now (with the bulk
of the IETF _still_ not engaged) only after a proposal that
interacted with the "what is the Series for?" question produced
a forceful (if short-lived) community response to one of the
"who is the decision-maker and how are decisions made?"
questions and that was followed, presumably coincidentally, by a
series of administrative actions (and perhaps attitudes) that
led to a resignation and a crisis that could not be ignored.

Because of that, while I agree that Core Issue #3 is, and ought
to be, of less immediate interest to this group/Program than the
other two, I see it as inexorably intertwined with both the
others and with what we are, and ought to be, doing here. 

> for the purposes of this discussion, and they (the IETF) need
> to put their own house in order. If the IETF comes back with
> clearly defined requirements for a new kind of document, that
> may or may not be a job for the RFC series.

The counterargument (perhaps even too paranoid for me, but
perhaps not), and IMPELHO [1], is that there are people
participating in this effort who, deep down, believe that, in
the modern age, many of the concepts and principles that drove
the first 50 or so years of the RFC Series are simply obsolete,
with notions of static/archival documents and not having all
documents under the control of the IETF/IESG topping the list.
If one believed that strongly enough [2], then, if this effort
produced a structure that was inefficient or ineffective in
getting documents out in a timely manner, it might not be a
terrible outcome... because it would make it far easier to argue
that we should abandon the current/failed way of doing things in
favor of a model that better (and exclusively) served the needs
of the IETF and served them through a much more dynamic set of
documentation arrangements.

If we make decisions that could lead to such outcomes --  i.e.,
that could have impact on, or reduce choices about, that third
core issue -- we should be very, very, explicit about that.

   john

> ** in my not in the least humble opinion

[1] In my probably even less humble opinion

[2] I am not paranoid enough to believe that anyone
participating in this effort does or would behave this way, but
I think the point is useful nonetheless.