[Rfced-future] A broader look (was: Re: RFC Editor liaison to the IAB? [was: Re: Comment on draft-iab-rfcefdp-rfced-model-12])

[John C Klensin <[e-mail]>]

Rich (and Martin and Peter),

This is partially OBE given Mirja's note and my response, but...

To the best of my knowledge, no one has proposed keeping the
liaison.  Certainly neither Brian nor I have.

The concern was precisely about allowing appropriate parties to
make appropriate changes and being sure that the appropriate
parties are sufficiently identified and empowered to do so.   To
use a metaphor that once was popular in the IETF, "changing the
engines of an airplane in flight" is difficult business and
often catastrophic, at least unless careful pre-flight design
provisions were made to make those things possible.  

I've been working on a longer note on this subject, but maybe
the above and a few more comments are an adequate (and shorter)
substitute.  I've said bits of this before but not drawn things
together and, frankly, I think so many of us are anxious to be
done with this process that I am pessimistic about this note
getting any serious attention.  Nonetheless..  

Several recent discussions have left me concerned that we have
not had a sufficient appreciation of the degree to which the new
Model is an experiment without much precedent.   The previous
Model documents were descriptive of then-current practices plus
or minus a few minor tweaks.  This one, by contrast, is arguably
the largest change to the public-facing side of the IETF and its
work since the Kobe affair and POISED.   Unlike this one, even
those changes did not involve creating new institutions, only
radically redefining the roles (and appointment structure, etc.)
of existing ones.  

So, now we are creating an RSWG that is sort of like an IETF WG
except where it isn't and an RSAB that is sort of like -- well,
I don't know what it is sort of like unless it is IAB-lite.  We
are eliminating a key (even if sometimes problematic) role and
oversight authority in the RSE -- a role that was based in
technical publications knowledge and experience -- replacing
part of it with committees, the majority of whose participants
are unlikely to have that knowledge and experience, an advisory
function whose parameters will have to be sorted out over time,
and giving vastly more authority to the LLC and its leadership.
Every one of those changes may be desirable and reflect the need
to solve real problems but, because of the extent of the changes
and the degree to which we are going into territory we think we
understand (but may not), it is an experiment and the other old
IETF metaphor is a question: "what could possibly go wrong?". 

Good practice, especially good engineering practice, suggests
that, if we design experiments that involve radical changes to
existing systems, we should either figure out a way to run those
experiments while those existing systems remain in place (not an
option in this case because the existing systems had already
broken) or to be sure that, if something fails, we have adequate
mechanisms for discovering the failure before too much damage is
done and then changing course as needed.  AFAICT, we have not
done that.  We have said several variations of 
"let the RSWG sort it out" which is fine as long as the RSWG --
despite risks that have been mentioned but, IMO, not really
considered -- does not work as expected/hoped.   Similarly,
while the rearrangement of reporting/oversight of the RPC is,
IMO, a tweak, what would happen in the unlikely event of a
future RPC and a future LLC and ExecDir failing to meet the
community's needs?  Does the RSWG/RSAB have the authority to
change that relationship despite any conceivable RPC having to
be either a contractor or a set of employees of the LLC?  Is the
ability of the RSWG/RSAB to offer advice that the LLC is
expected to follow unless they have what they consider good
reason not to sufficient for all conceivable cases?

The risks I cannot guess at are an equally large concern.
Different people with different perspectives and experience spot
different things.  Active participation in this Program has
included a very small fraction of the community of active IETF
participants and a tiny fraction of the population that might be
affected.   In normal IETF review of a technical specification,
the Last Call process often identifies issues that were not
adequately considered earlier.  But when the community Last Call
was issued this time, AFAICT, zero people commented who had not
actively participated in the Program earlier.   Is that a
problem?  Don't know, but it should at least argue for caution
and/or contingency plans.

I don't know the answer to any of those questions.  I do not
believe that we need to delay any of the current documents or
plans long enough to get answers to them and incorporate them
into the documents.   However, I believe that some effort to
figure out what we do if things do not work as expected and fail
in a non-trivial way would be worthwhile.  Whether that were
done by an extension of the Program, as an activity within the
IAB and/or IESG, or in some other way may be less important than
getting enough of a contingency plan (or framework for one) in
place that, if something does go seriously wrong, we just live
with it because the alternative of trying to figure out how to
start over once the problem is in front of us would be much
worse.

With such a plan, or a plan about how to develop one, in place,
I think we could all relax a bit more and spend less time
worrying about fine details and whether they need to be
addressed now... whether those be the IAB's liaison structure;
the scope of AUTH48; RSAB "CONCERNS"; the finer points of
interactions among the IETF, the RFC Editor Function, and IANA;
or other issues not yet raised.  IMO, each of those conversation
threads has been worthwhile, but I suspect that, absent good
contingency plans, similar ones will keep coming up with no
obvious and fair stopping rule.  To me and at this point, that
is a good reason for leaving as much as possible to the RSWG but
only if we have a plan about what to do if that does not work.

thanks,
    john

(and, yes, that was the short version :-( )


--On Sunday, March 13, 2022 23:41 +0000 "Salz, Rich"
<[e-mail]> wrote:

> If we are proposing a new model, and we are, then remove all
> vestiges of the previous model.  The liaison should go.
> 
> If the new model doesn't work, then the appropriate parties
> can make the appropriate changes.