Re: [Rfced-future] Posted my draft

Eric Rescorla <ekr@rtfm.com> Sat, 05 September 2020 22:50 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 110163A134B for <rfced-future@ietfa.amsl.com>; Sat, 5 Sep 2020 15:50:55 -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 e-glHmoHZhTq for <rfced-future@ietfa.amsl.com>; Sat, 5 Sep 2020 15:50:53 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 AC37E3A134A for <rfced-future@iab.org>; Sat, 5 Sep 2020 15:50:52 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id w3so11938277ljo.5 for <rfced-future@iab.org>; Sat, 05 Sep 2020 15:50:52 -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=9KPtPAnTK3c1tjGYdJhCRaDwVWGf6ZVzUwuOnZUPajA=; b=YAycJLcPgp1G+5s7J3k+o4Yo26rwa4viE8GLFnqQxsEPGcdHzT5lL4XlMq9VU1NPwV trP+z6Beu8aezzZETJdV73pXcwQVOOMOeNEmUug1nvvUoMzgvDR6dHfEfyRcPS/fAMnd HsdS0mof4MQ0oFpzbRFKiZAjydMOYZfAQLPxIAbZRrnVhrMpXD53DPPigFY+ndaRlStJ mtgrN1MhImVKkYapAQNKQsptI4TIFe8eahrWKjii79jdY6bpNWnDweO5kQ+foWKCnaVK Wu9YvpF+/EcPUORJpQ0mTLwFlW18krPpJpdDHEiWgaewQNrvYJTwO/kmeEtL9WwifZMn DqFg==
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=9KPtPAnTK3c1tjGYdJhCRaDwVWGf6ZVzUwuOnZUPajA=; b=MBTtmALou2s4AQXTjJzbaPoO8+Wof6uj0Vt0QEf09iilOZ8lBoqPhToHCeFxwC4lay FU+aYS7NTf8fV61tn8PvMcFNDANmxz1rKR6ZbnzgPEDnibyGLibTrA0cknx1S59UUQof x3LppV7ynfX7vrJibyMBtdCRBC85MuMze1zdK2Vlw8J36gU/b3oHatDcReQntRuB3OjK 7WDs8xnz5GlWHeUJEuOwLMNnAJwvP5ij1iM/mfKdLIetd1ly/UFKhXWtm27vWAkoYElM 1Mn1LuTLOzb9Ax7Wr0ezagw5NmvuHICSQsGj3TrS3ZVV1i7oE+DBg6a/aNi7drJuHi5o 297Q==
X-Gm-Message-State: AOAM5314fC0bmooYwIYZyU0U6niuxDmTH/7dDUXUp63mMYzXcdHNbUe+ OUvkB5wRLgR6OzAjKj4msbtvDmVT+VSDWJ9Nw1fg7g==
X-Google-Smtp-Source: ABdhPJwnDqtyHzbaBRcOHUfq1GlRB/68bp0QCyEeGRxHKJtOljzEX1CNtGdmmvfSpn9yP6HFw4KnbmJapTnLB+hovjw=
X-Received: by 2002:a2e:8850:: with SMTP id z16mr6718439ljj.184.1599346250640; Sat, 05 Sep 2020 15:50:50 -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>
In-Reply-To: <6490b02a-c5a8-5883-8a2a-52299787eb0f@nthpermutation.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 05 Sep 2020 15:50:13 -0700
Message-ID: <CABcZeBMzv5odA=28Me8PP8tv9PziZo425AVJ4Ywye9-vxRSGEQ@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Cc: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="0000000000002480ff05ae98d172"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/xFu8EWlYX-Ff_LiFQcx2ZEkLJVQ>
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: Sat, 05 Sep 2020 22:50:55 -0000

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

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?

- 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)?


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

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?



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


> 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