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,

On 2022-03-17 11:52, John C Klensin wrote:
> Martin,
> 
> I think all I can say at this point is that I hope you are right.

Thanks. I can only add to this that I hope I don't have to be right
(i.e., I hope we won't need all the checks and balances and safety 
valves that I described below).

Regards,   Martin.


>     john
> 
> 
> --On Wednesday, March 16, 2022 09:48 +0900 "Martin J. Dürst"
> <[e-mail]> wrote:
> 
>> 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.
>>>