Subject: Re: [Rfced-future] A voice from the (perhaps lunatic) fringe (was: draft-saintandre-rfced-model-01.txt)

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jul 2021 17:00:31 +1200

Long ago I promised to comment on issues #1 and #2 below
(having commented on #3 immediately):

On 22-Jun-21 07:08, John C Klensin wrote:
> 
> 
> --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.
>>
>> https://datatracker.ietf.org/doc/draft-saintandre-rfced-model/
> 
> 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.

Are we really, though? This is certainly a point we need to
keep in mind when reviewing the proposal as a whole. Are we
defining anything that doesn't *need* to be defined in advance?
If so, delete it.

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

Indeed. But there's close to a continuum between a casual idea
mentioned on your favourite instant messaging tool through
wiki pages, pull requests, blogs, I-Ds, etc etc, up to formal
publication in an archived series. If we get to "living
standards" documents as hinted in #3 below, whether they fit
in the formal & archived category or not must be addressed.
 
> 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.

It's a fair warning, but it seems to me that the people here
(and that is not the 40k+ people covered by Jay's recent survey)
are convinced that we should reject kings, presidents and Editors.
So I think that means accepting the risk that a bunch of amateurs
will decide that they know best, whatever the expert says.

Something like “Democracy is the worst form of government,
except for all the others.”

   Brian

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