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

["Martin J. Dürst" <[e-mail]>]

Hello John, others,

Towards the end of this mail, John raises the question "What will we be 
able to do if the new Version 3 of the RFC Editor model fails. (The rest 
of John's mail is really just a slow buildup to this question.)

Just for the record, I want to list the stopgaps that are built into the 
new process.

- The RSWG is open to anybody. As long as things work fine, it is indeed 
possible that not too many people participate. But if there's a 
fundamental problem developing (or after it developed, in need of 
correction), more people can participate.

- The RSWG chairs can be replaced by the IAB/IESG at any time.

- The representatives on the RSAB can be replaced at any time.

- Updates to the process are possible through the RSWG and RSAB,
   but require the agreement of the IAB and IESG.

- The RPC and the RSCE serve by contract, with the assumption that these
   contracts contain the necessary clauses for what happens in bad times.

- The IETF Executive Director also is employed by contract, for which
   I guess similar considerations apply.

- The LLC Board, the IAB, and the IESG's members are selected by the
   Nomcom.

I may have forgotten a piece or two, but I think all the necessary 
provisions for "emergency measures" are available. Also, these 
provisions (and the provisions for day-to-day work) are based on 
experience made over decades in the wider IETF community (e.g. WG　process).

It may not be particularly easy or quick to fix the direction of the 
ship if it is sailing in a wrong direction, but it's definitely 
possible. After all, neither what happened after Kobe nor the current 
move from Model 2 to Model 3 were particularly quick, either.

So overall, yes, we are threading new ground, and at least in my 
opinion, that means we should thread carefully, at least at the start. 
But the ground is similar to other ground that we know, and we have all 
the means in place to get out of quicksand (or whatever other problem) 
if and when we discover it.

Regards,   Martin.


On 2022-03-15 01:12, John C Klensin wrote:
> 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.
> 
> 

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan