Re: [Rfced-future] Posted my draft

Michael StJohns <msj@nthpermutation.com> Sun, 06 September 2020 00:02 UTC

Return-Path: <msj@nthpermutation.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 5172B3A0DBD for <rfced-future@ietfa.amsl.com>; Sat, 5 Sep 2020 17:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.344
X-Spam-Level:
X-Spam-Status: No, score=-2.344 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, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-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 dCL_PolX3Mtp for <rfced-future@ietfa.amsl.com>; Sat, 5 Sep 2020 17:02:33 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 91A903A0DAA for <rfced-future@iab.org>; Sat, 5 Sep 2020 17:02:33 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id o64so9846263qkb.10 for <rfced-future@iab.org>; Sat, 05 Sep 2020 17:02:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=/O2fIA1k1Df7uE+DV99uQTRsxpICufRk51zn6jwaSf4=; b=huS5X7qokTvQGf0ssy9+TtJJLu5f56pf1rnXdSfdimdUoqHDUcQ1QKww0r4JR62+Aw IFanbkbfq1QI6r+VJghqPefrjcnwSPbA73QAStNa3/E0YhZSk8t6A6LMfke+6T5qqeAd HNhpNDZTWKvN3pZ7ZOockxq9hIxbbDK2IRURgRFO79OogDsDqYOWvnN80IupU4ugLYza Og4iBCQYe3+8S11sBBL5K3hjtpaNiXtCusN3Wyr8R3cM14NZlP9AIhQcd1GUrb8wt+uw U5gkf4QQzOpH/Iwf3yUM68Nb80UwEbIIQcjBQDWb2YMvcw4BQFFjgUe+87+5yFpZQvdr RFDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=/O2fIA1k1Df7uE+DV99uQTRsxpICufRk51zn6jwaSf4=; b=mYKWMVvzT5XLNAIFjvnyLnmMk8/urM3Ya/7APC8C/p+UBx1ixAS0w9iaIgn5SMhTzY STSvSL+b8oO+fjhXtyRmFMJIItqW9nROMQRgrq+Thb9J+rAVQ3g8giddadFr24BWHiMe I3tcg2GyPgsRCyy3f1X9DTPGmKHLoKyvGaFmQYKmoX4Cxx8hQGajK7inCibBuXM/5PVD Tz643SeHFnC1kpRW8TL2yKQTWzHd40mO3EgPjmiGjY89FThxdvuF2P8OsAyLNbzgAP7U lC6YmUFXp1b2ZzxOiTMzy8Tpgfe32ZaC1rkAWz3CCDhxfzc4PpGHz9LO1bP72pQoX41t g9kg==
X-Gm-Message-State: AOAM532CPn1zxdJm37XMkxJmzStciF760fRwWW5fvJ+vfG0SjKMRfD2N 7eGL2IY8oa95ygHUcf7juvuEM39wxFHrl+KdRuo=
X-Google-Smtp-Source: ABdhPJx1vxccwVzGeyvJJCUAnBKfqjdcgW6EdR3qVB7bCgD3r7FVmzF5jRB716Nx2wufYku/maV4NQ==
X-Received: by 2002:a37:e82:: with SMTP id 124mr13768696qko.77.1599350552118; Sat, 05 Sep 2020 17:02:32 -0700 (PDT)
Received: from [192.168.1.20] (pool-71-114-22-128.washdc.fios.verizon.net. [71.114.22.128]) by smtp.gmail.com with ESMTPSA id o72sm7706933qka.113.2020.09.05.17.02.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Sep 2020 17:02:31 -0700 (PDT)
To: Eric Rescorla <ekr@rtfm.com>
Cc: rfced-future@iab.org
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>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <b746a12e-8ac9-f6bc-9446-b2953e235f1d@nthpermutation.com>
Date: Sat, 05 Sep 2020 20:02:29 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBMzv5odA=28Me8PP8tv9PziZo425AVJ4Ywye9-vxRSGEQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------B98ABC982553640CF9A8C414"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/V9wug5s4L7PiRF32TXosTV5DoZ8>
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: Sun, 06 Sep 2020 00:02:36 -0000

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 <mailto: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



>
>