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 > > > > > > >
- [Rfced-future] Posted my draft Michael StJohns
- Re: [Rfced-future] Posted my draft Eliot Lear
- Re: [Rfced-future] Posted my draft Carsten Bormann
- Re: [Rfced-future] Posted my draft Mirja Kuehlewind
- Re: [Rfced-future] Posted my draft Adrian Farrel
- Re: [Rfced-future] Posted my draft Michael StJohns
- Re: [Rfced-future] Posted my draft Michael StJohns
- Re: [Rfced-future] Posted my draft Michael StJohns
- Re: [Rfced-future] Posted my draft Mirja Kuehlewind
- Re: [Rfced-future] Posted my draft Christian Huitema
- Re: [Rfced-future] Posted my draft Michael StJohns
- Re: [Rfced-future] Posted my draft Mirja Kuehlewind
- Re: [Rfced-future] Posted my draft Michael StJohns
- Re: [Rfced-future] Posted my draft Eric Rescorla
- Re: [Rfced-future] Posted my draft Michael StJohns
- Re: [Rfced-future] Posted my draft Eric Rescorla
- Re: [Rfced-future] Posted my draft Michael StJohns
- Re: [Rfced-future] Posted my draft Eric Rescorla
- Re: [Rfced-future] Posted my draft Adam Roach
- Re: [Rfced-future] Posted my draft Adrian Farrel
- Re: [Rfced-future] Posted my draft Eric Rescorla
- Re: [Rfced-future] Posted my draft Adam Roach
- [Rfced-future] Primary complaint? [was: Posted my… Brian E Carpenter
- Re: [Rfced-future] Primary complaint? [was: Poste… Adam Roach
- Re: [Rfced-future] Primary complaint? [was: Poste… Brian E Carpenter