Re: [Rfced-future] Posted my draft

Eric Rescorla <ekr@rtfm.com> Mon, 07 September 2020 18:18 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641643A0F9A for <rfced-future@ietfa.amsl.com>; Mon, 7 Sep 2020 11:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.396
X-Spam-Level:
X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_egtHp1BuQP for <rfced-future@ietfa.amsl.com>; Mon, 7 Sep 2020 11:18:18 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6AE3A0F99 for <rfced-future@iab.org>; Mon, 7 Sep 2020 11:18:17 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id y2so7870395lfy.10 for <rfced-future@iab.org>; Mon, 07 Sep 2020 11:18:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r3VkXLINSMV0BPtlvn95g9TEUkqtiCTByuRgeau657k=; b=FnSv0rq2VAnrtMitYpxBMZq9WH/OCA6vBfwxVRjpWRxtvjH6lx+0NigIR3k1oX5e+z eHuYLgGWXlvE9dpzA/TfgIRJAtr87t+9lPCkuoyjfaFGAWL2fWZxYtK1xUFcA2vqdcwF MumRUrQS2DkrXppUoCRUlsG6Ef1jMV4bc9VFiHFtOMFSlBVjkbiyu0b7lnRLaMsnLPm0 yw1R+t++ymOP7ATABrDx3BTUvJkU3Op65QqMo5BIGwj2digBzufCMPWLxL+QXZUYVRFf icxqKC0xUVQqBnV4yOP0KxoJakMa4I47eBpkIYU0QN+t8EGVZvz6IG8rcWk3sTnn4Med pU0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r3VkXLINSMV0BPtlvn95g9TEUkqtiCTByuRgeau657k=; b=KHfH4SI8MaClW3aaAT4hlxYkw8HEnBBfottnznHYCy2VnL5JUc43noh0I4p29e1gEJ erSK2rcSVAY5JTEIhgrwNKL/Pk36akk5yzPNKkNCY2ecnj17MxuefN4ra4rmi1268r7c SYifA9edrxSnonL8QPrXXot6As117PayKx0MkGCb/eCLTDJlDizS2SewCOyTm1wWVRxX A2Hg1LQDATgnR5Mvw/Waw7hDfrbAqfia8CmivZGO7eoslY3bIjL9fZ1dIltyJP5kIuK0 4bsgRO5lj6CgnCHPsvmRZJjeWf70CEdIMqGdoH2NUsA1dmNWfonnIc6WbdAYMMfv4UmN /1rw==
X-Gm-Message-State: AOAM5325t5Sx8IfiiN7ZAEQfRQ+LfkNOZ0tRfJru7a6kwM1+BCOgi16T F65B/Cfh+GFUuRc0NrDPe9G1SdudPNvRgNoeA4/uu3+4VhDVFg==
X-Google-Smtp-Source: ABdhPJysV4tH+sMHlUt9i66pLKhpLC6Pa4+7zjqEiih6qqVeiplF/+bxgDxFvwq2LL9Zik8bHT3QAoLv4f5UlfPy7x8=
X-Received: by 2002:a19:e57:: with SMTP id 84mr10683772lfo.161.1599502695501; Mon, 07 Sep 2020 11:18:15 -0700 (PDT)
MIME-Version: 1.0
References: <10085448-5443-7641-26fc-4ee6692d39e0@nthpermutation.com> <CABcZeBP7zHG_OK-J1KJbBHnvMFnB5TqVUmcaP2E0SUDinKrEsg@mail.gmail.com> <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com> <CABcZeBMzv5odA=28Me8PP8tv9PziZo425AVJ4Ywye9-vxRSGEQ@mail.gmail.com> <b746a12e-8ac9-f6bc-9446-b2953e235f1d@nthpermutation.com>
In-Reply-To: <b746a12e-8ac9-f6bc-9446-b2953e235f1d@nthpermutation.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 07 Sep 2020 11:17:39 -0700
Message-ID: <CABcZeBNB9UzfV_gyi1r3XQ-AYxe0kWigjNzjE4t8=ZgmfC_Tkw@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Cc: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000fba65505aebd3d34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/Fwjf_p_eV3CJdSvlM23vG4euhF0>
Subject: Re: [Rfced-future] Posted my draft
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Sep 2020 18:18:20 -0000

Thanks for your complete response which helps me understand your position

As I said in my initial review, I believe that the structure you propose
would not allow for a sufficient level of community oversight over the RSE
function. In particular, I think the RSOC/IAB/RSEB whatever needs to be
empowered to replace the RSE if they do not agree with their strategic
direction. I believe that is fairly clearly the case under 6635 and should
be the case under any new structure and is not under what you propose.

Chairs: sounds like a good topic for the interim.

-Ekr



On Sat, Sep 5, 2020 at 5:02 PM Michael StJohns <msj@nthpermutation.com>
wrote:

> On 9/5/2020 6:50 PM, Eric Rescorla wrote:
>
> [Trying to cut down to the points that I think are at the heart
> of the matter, which does not mean that I necessarily agree
> with your responses.]
>
> On Wed, Sep 2, 2020 at 11:23 AM Michael StJohns <msj@nthpermutation.com>
> wrote:
> > On 9/1/2020 3:16 PM, Eric Rescorla wrote:
> > > Specifically:
> > >
> > > 1. The RSEB (which nominally represents the RFC community) does not
> > > seem to have any hiring and firing authority [0]
> >
> > Well, contrary to popular belief, neither the IAB nor the RSOC has
> > ever had hiring or firing authority.  In the ISOC era, that rested
> > with the HR department I believe.  In the LLC era it rests with the
> > LLC .  What the IAB and RSOC did have was the ability to recommend
> > or request the selection of a particular candidate by the hiring
> > entity.  A good portion of the problem we encountered was them not
> > understanding those limitations.  The LLC has indicated an intent to
> > defer to the wishes of the IAB in this matter, but legally, the role
> > still resides with the LLC.
> >
> > With respect to hiring, in the "new" model, the RSEB can recommend
> > RSE candidates to the LLC, but if the LLC isn't able to come to an
> > agreement on terms with that candidate, there's nothing the RSEB can
> > do to change that.  That again was no different than before.  The
> > LLC - legally, but probably not ever going to happen practically -
> > could actually hire whoever they wanted irrespective of any input
> > from the RSEB, IAB, IESG etc.
>
> I agree with some of this and disagree with other parts:
>
> 1. Yes, I imagine that the LLC (and ISOC before it) could legally hire
> anyone they wanted and give them any title they wanted. However, this
> would not make them the RSE for the purposes of our process (as was
> discussed in detail in IASA 2.0). Here is the relevant text from
> 6635:
>
>    The RSE is appointed by the IAB, but formally hired by the IAOC.  The
>    IAB delegates the direct oversight over the RSE to the RSOC, which it
>    appoints.
>
> That's what it says.  And you're correct that the RSE might be considered
> "illegitimate" if the LLC ignored the formal appointment and hired someone
> to do the work of the RSE, even without the actual title.  But the LLC has
> the money, and as such has the veto power regardless of what the documents
> say.  Appointing a non-IAB approved (or in my case non-RSEB recommended)
> RSE could end up with the LLC getting yelled at by the community, but it
> still doesn't change the reality of how the contracting business works.
>
> The recourse here - as noted before - is that the RSEB could refuse to
> publish the (illegitimate) RSE's work.
>
>
> 2. The purpose of these documents is in part to memorialize our
> understanding of the terms under which the LLC is expected to act.
> So, while 6635 I think makes clear that the LLC ought to contract
> with/hire either the person that the IAB/RSOC selects or nobody,
> your document appears to change that. But perhaps I've misunderstood
> you. Hence some questions about your intent:
>
> - If the LLC ignored the RSEB's chosen candidate and selected
>   their own, would they be able to act as the RSE for the
>   purposes of this process, such as chairing the RSEB?
>
> That would be an interesting discussion.  In any event the person hired as
> RSE would be doing the work - the RSEB could either approve it or not for
> publication.  My guess is that all of that would work itself out either by
> the RSE being replaced, by the RSEB being replaced, or by the LLC being
> replaced - whichever made more sense to the community.
>
>
> - If the RSEB wishes to replace the current RSE at the end
>   of their contract, what mechanism do they use to do that
>   and what impact does that have on the LLC (as in the
>   first question)?
>
> The RSEB and RSEB members may make any comments they want to the LLC.  The
> LLC can assign those comments as much or as little weight as they feel
> appropriate.  That may result in the LLC asking the RSEB to set up a
> search, or for the LLC re-uping the RSE irrespective of the RSEBs desires.
>   This is pretty much how the IAB takes community comments on the ISE
> AFAICT.   The point is that the RSEB isn't there to manage the RSE, but to
> work with the RSE to direct the strategic direction of the RFC series.
>
> (Consider for example an RSE that's doing what the community wants, but
> not what the RSEB wants - if the LLC gets lots of messages of support about
> the RSE, how much weight should the LLC give to the RSEB's comments
> suggesting the RSE needs to go?)
>
>
>
> > In any event, the LLC handles personnel and contract issues, and the
> > RSEB is the one that approves the publication of the RSE's work and
> > never the twain shall meet. I doubt that the RSEB is going to
> > approve said documents so if the strategy espoused by the RSE is at
> > odds with what the RSEB members believe is the correct path.  If the
> > RSEB is mostly against the RSE time and again, and the members of
> > the RSEB make those concerns known to the LLC, its unlikely that the
> > LLC will extend the contract.
>
> As noted above, this seems to me to be a material change from
> the existing 6635 situation in which the LLC would not be expected
> to independently determine the suitability of an RSE who the
> RSOC had decided not to engage. Again, I'm speaking here of the
> implications for our process, not what the LLC's legal rights
> are.
>
> I guarantee that the LLC (and the ISOC before it) made their own
> determinations of suitability - not necessarily the same ones that the IAB
> or RSOC made.  You could have someone who looked good on paper and wowed
> every member of the IAB, but  didn't meet their criteria hen the LLC did
> its due diligence.  I'd expect that to mostly come from the lawyers working
> contract issues.
>
> I think you're making too much of this - the LLC is the contracting
> entity.   It's going to try to be doing the right thing for the community,
> and the RSEB/Search Committee will hopefully provide the LLC with one or
> more good candidates for that role.  I'd be shocked if they selected
> someone else - mainly because I don't think they want that much work.  But
> I could actually see it happening if say the search committee is unable to
> find someone, and there's a need for an interim.  Maybe expanding Jay's
> role for a while, or getting the RPC to amend the contract to pick up some
> of the need - options that the LLC might take to maintain the business of
> the IETF.
>
>
>
> But perhaps this is just a matter of me not understanding what
> you have written down. Let's consider a concrete case:
>
> The RSEB \setminus RSE wants to proceed in a certain strategic
> direction (inscribing the RSEs on clay tablets say). They ask the RSE
> to develop the plan to do so, but the RSE opposes it and so refuses to
> do so in a timely fashion. What, if any, recourse does the RSEB have?
>
> I assume you meant inscribing RFCs on clay tablets not "RSEs"?
>
> Well, first if the RSEB was seriously convinced that clay tablets made
> sense, I'd be trying to figure out how to replace each and every one of the
> RSEB members, or I'd be looking at the voting record and replacing the 5
> RSEB members that said this was a good idea.
>
> If the RSEB proposes an idea that the RSE doesn't want to go along with,
> then the recourse is for the RSEB to approach the LLC or CM and ask them to
> intercede.  The LLC or CM may or may not choose to intercede and will have
> to make those decisions based on what the contract says and their
> perception of reality.
>
> Lastly, if the RSEB feels that clay tablets are the way to go, they can
> always write their own plan and approve it themselves.  Alternately, they
> can ask the LLC to hire someone specifically to write that proposal.
>
>
>
>
>
> > > 3. Section 4.3 says:
> > >
> > >    While it is ultimately the LLC's decision, the RSE should be engaged
> > >    via either a personal services contract or an employment contract
> for
> > >    a given term.  Engagement as an at-will employee would not be
> > >    appropriate for a senior-level resource with these strategic
> > >    responsibilities and would not provide any measure of consistency
> and
> > >    continuity over the RFC Series.
> > >
> > > While I can certainly understand how this arrangement might be
> > > appealing to prospective RSEs, I do not believe it provides an
> > > appropriate level of accountability to the community. Specifically, I
> > > believe it is necessary to have the ultimate authority for stratetic
> > > decisions be vested in the community (in this case this would be the
> > > RSEB, ignoring for the moment its composition), but that does not
> > > appear to be the case here. This issue is exacerbated by the fact
> > > that the RSE is themselves a member of the RSEB.
> >
> > 1) Strategic decisions ARE vested in the community.  It takes at
> > least 5 members of the RSEB (which may or may not include the RSE)
> > to approve a new document that describes changes in strategy.  The
> > RSEB represents the community.  If it isn't written down, it didn't
> > happen.
>
> Sure, and that prevents the RSE from unilaterally doing bad things but
> it does not prevent the RSE from effectively stalling good things they
> don't agree with. See the example I gave above.
>
> And clay tablets are a good thing?  I'd find this question more
> interesting if you could provide a much better example and explain how
> "good" is determined.
>
> Again, there's nothing preventing the RSEB from doing the work itself if
> it believes it has the better solution.
>
> We actually want someone to say no if the RSEB is making bad decisions -
> it's reputational on the RSEs part not to do things that a broader
> community would find .... stupid.    I'd expect at least this model from
> anyone I'd hire as a contractor - or why would I hire them?  I may not
> always agree with their choices, but I'm paying them for a specific set of
> expertise.
>
>
>
>
> > 4) Continuity is important in this space - perhaps more so that
> > you're willing to admit.  The model of an on-call consultant who
> > sometimes comes in and answers questions does not support the idea
> > of a dynamic and world-class publication system.  We can coast a
> > while on the work that Heather and her predecessors have done, but I
> > don't think we can do that for long and maintain the publication
> > standards.
>
> Indeed, we disagree on this point, but I don't think each of us
> offering our unsupported assertions is going to get us very far, so
> I'll refrain from arguing it at present. I will, however, note that
> neither "dynamic" nor "world-class" are the words that come to mind
> when I think of our present publication system.
>
> -Ekr
>
> I've been around long enough to see what a bad system looks like (cf the
> IDEA series or even PKCS11 by Oasis).   The main problems with the RFC
> series appear to be pre-publication or so I opine given the data.  The
> actual publication process and model works reasonably well, with vastly
> varying qualities of submissions, and many different requirements.   The
> documents are available world wide and in a manner that allows free and
> easy access.  The documents are widely cited, and the stability of the
> references means that those cites are meaningful 20+ years later.
>
> So, yes, we disagree.
>
> Later, Mike
>
>
>
>
>
>
>