Re: Try this: was Re: New proposal/New SOW comment period

Sarah Banks <sbanks@encrypted.net> Tue, 10 September 2019 23:44 UTC

Return-Path: <sbanks@encrypted.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1242B120013 for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2019 16:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 rMUtjBQBWelh for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2019 16:44:24 -0700 (PDT)
Received: from aws.hosed.org (aws.hosed.org [50.16.104.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D17120026 for <ietf@ietf.org>; Tue, 10 Sep 2019 16:44:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by aws.hosed.org (Postfix) with ESMTP id 17E7F80093; Tue, 10 Sep 2019 19:44:23 -0400 (EDT)
X-Virus-Scanned: Debian amavisd-new at aws.hosed.org
Received: from aws.hosed.org ([127.0.0.1]) by localhost (aws.hosed.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OJnvj8lHZY5; Tue, 10 Sep 2019 19:44:22 -0400 (EDT)
Received: from [192.168.1.81] (corelight.static.monkeybrains.net [208.90.215.182]) by aws.hosed.org (Postfix) with ESMTPSA id 2ABC18007D; Tue, 10 Sep 2019 19:44:20 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: Try this: was Re: New proposal/New SOW comment period
From: Sarah Banks <sbanks@encrypted.net>
In-Reply-To: <681bea04-a31a-bd26-6982-9a2c1238ef0f@gmail.com>
Date: Tue, 10 Sep 2019 16:44:18 -0700
Cc: ietf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB40DB18-E4CF-41A9-98B8-BD064A062AB8@encrypted.net>
References: <ec715385-93ca-ddf0-f9b1-d0e4ae1666fe@nthpermutation.com> <CAL02cgTqDTXgG1bU1DGBkdQ7XwV=2ryJzQU1QD8yNba-7ngk3A@mail.gmail.com> <44cbe750-e030-69d7-54ba-5eaeccc5f512@gmail.com> <CABcZeBNw8c17F0bvcSJoS4R=dk_KoSx1jWkEnupUUps6k8UcGg@mail.gmail.com> <CAL02cgS88fD7BkrE4T0A+S99xN-b4JZDm4yu2nLAb3oiG50S4g@mail.gmail.com> <1dbc8dbe-d883-a433-8dc4-247ac1760152@joelhalpern.com> <CAL02cgRz=yZW+oE-wxoWQJ-8fbfi4NBFLNk2KSafHh+2FPUNPw@mail.gmail.com> <681bea04-a31a-bd26-6982-9a2c1238ef0f@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lR-OxsC2wICmJGvPo8VbCHyZEIo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2019 23:44:27 -0000

Hi Brian,
   The point was to have the "what do we want next" discussion under the meetings that Heather is organizing. As a community member, I don't want any SOW steering that; if we really need someone now, let them be guided by what we have today, and let us have that discussion thoroughly and come to whatever consensus we can achieve. I'm deeply concerned that conflating the two in the SOW is off mark at best, and unfair to everyone who's indicated they have different opinions. What's wrong with the proposal to have someone keep the documents flowing while we have that discussion? If I'm wrong, and the community believes we can achieve consensus in a 2 week comment period, by all means, I'll get onboard :) 

Thanks
Sarah

> On Sep 10, 2019, at 4:02 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 11-Sep-19 10:06, Richard Barnes wrote:
>> That was not my understanding, FWIW.   Maybe the RSOC could clarify?
>> 
>> Mike’s proposal seems even weirder through your lens, though, since it does not describe a caretaker RSE role, but rather a full on RSE in every regard except the application of the oversight specified in RFC 6635.. 
> 
> They're *our* rules so we can choose to ignore them or change them. Can we just evaluate Mike's proposal on its merits: does it describe what we want to happen next?
> 
> There's a parallel discussion needed about how we'd like to change the rules. And the changes proposed might be radical. That's why I wrote https://www.cs.auckland.ac.nz/~brian/CommentaryIAB.pdf, and why we have some RFC Editor Model virtual interims coming up.
> 
>   Brian
> 
>> 
>> —RLB
>> 
>> 
>> On Tue, Sep 10, 2019 at 17:10 Joel M. Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> wrote:
>> 
>>    Maybe I misunderstood the RSOC message.
>>    I thought they had indicated that they were NOT trying to hire an RSE as
>>    defined by RFC 6635 and its details.  Rather, as I understood them, they
>>    were hiring someone in a temporary capacity (explicitly NOT an acting
>>    RSE) to keep the series running while the community decides what it wants.
>> 
>>    Sure, that is breaking the letter of the law.  I believe we all know
>>    that.  I actually appreciate that the RSOC understands that trying to
>>    follow the letter of the law at the current time is a bad idea.
>> 
>>    Given that we are on a path where we are not following the letter of the
>>    laaw, it seems to me reasonable (good?  bad?  that is a different
>>    question, but clearly reasonable) to use that latitude in formulating
>>    the SoW so as to describe what we want, not what the letter of the law says..
>> 
>>    Since our rules are not laws, and we are practical people, that seems okay.
>>    And since reaching community agreement on what we do want is CLEARLY
>>    going to take some time, I do not see how the LLC can say that they will
>>    wait to hire someone to keep the trains running while we figure out what
>>    we really want.
>> 
>>    So yes EKR, this SoW violates the letter of RFC 6635.  And if we want,
>>    as a temporary measure, to violate it further in the interest of keeping
>>    things on track while we figure out what we want, then explain what
>>    further changes are needed.
>> 
>>    Sure, I would prefer that we were all in agreement on what the job
>>    really was, and we could hire the right person to hold the job for a
>>    number of years.  But we are not in such agreement.
>> 
>>    Yours,
>>    Joel
>> 
>>    On 9/10/2019 4:59 PM, Richard Barnes wrote:
>>> On Tue, Sep 10, 2019 at 16:45 Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>
>>> <mailto:ekr@rtfm.com <mailto:ekr@rtfm.com>>> wrote:
>>> 
>>> 
>>> 
>>>      On Tue, Sep 10, 2019 at 1:39 PM Brian E Carpenter
>>>      <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com> <mailto:brian..e.carpenter@gmail.com <mailto:brian..e.carpenter@gmail.com>>>
>>>      wrote:
>>> 
>>>           > This draft disclaims or contradicts RFC 6635 at a few points.
>>> 
>>>          Do we really need to worry about that? This is a time of change
>>>          and I don't think it matters if we deviate from the letter of a
>>>          7-year-old Informational document.
>>> 
>>> 
>>>      Not Richard, but it seems to me that either one feels constrained by
>>>      these documents or one does not. And if not, then I think we need to
>>>      more generally ask whether the 6635 structure is even approximately
>>>      right.
>>> 
>>> 
>>> Am Richard, concur with what EKR says here.
>>> 
>>> Even if one disagrees with the content of RFC 6635 (which we probably
>>> all do, in different ways), there are other, non-Informational documents
>>> that specify how to replace it with something that has community
>>> consensus.  And this ain’t it.
>>> 
>>> —Richard
>>> 
>>> 
>>> 
>>>      -Ekr
>>> 
>>> 
>>>          Regards
>>>              Brian Carpenter
>>> 
>>>          On 11-Sep-19 08:00, Richard Barnes wrote:
>>>           > Hi Mike,
>>>           >
>>>           > Thanks for taking the time to put this together.  It looks
>>>          much more like what I would expect an SOW / JD to look like than
>>>          prior drafts.
>>>           >
>>>           > Unfortunately, I don't think it's a suitable starting point
>>>          for a process that is premised on RFC 6635.  Despite the fact
>>>          that you've called it a PM, the contractor being engaged here
>>>          will act as RSE, even if only on an interim basis.  So RFC 6635
>>>          clearly applies.
>>>           >
>>>           > This draft disclaims or contradicts RFC 6635 at a few
>>>          points.  Specifically, the paragraphs in the summary starting
>>>          "The PM, as acting RSE, ..." and "The general
>>>          responsibilities...." are incompatible with RFC 6635, and the
>>>          "Reporting Relationships" section significantly underplays the
>>>          role of the RSOC.
>>>           >
>>>           > One of the foundational ideas in forming the LLC was that it
>>>          would follow the will of the community, and RFC 6635 encodes the
>>>          community's expectation of how the RSE role should be realized.
>>>          So it is incumbent on the LLC to follow the RFC (including, for
>>>          example, facilitating the RSOC's oversight), and this
>>>          solicitation needs to reflect that.
>>>           >
>>>           > In case the RSOC does choose to use draw on this document, a
>>>          couple of more specific comments are below.
>>>           >
>>>           > --Richard
>>>           >
>>>           >
>>>           > - I don't see a lot of value in calling this role a PM, as
>>>          opposed to just a temporary RSE.
>>>           >
>>>           > - Under "Education and Experience Requirements", I would lead
>>>          with the leadership requirement (i.e., swap the first two
>>>          bullets).  As has been discussed at length here, the RSE (even
>>>          interim) is not an editor.
>>>           >
>>>           > - There's still some ambiguity here about the relationship to
>>>          the RPC and Publisher.  If I understand the intent here
>>>          correctly, the idea is that this PM is not PM'ing the RPC, but
>>>          rather observing and opining on their performance (and providing
>>>          advice as necessary), as input to someone at the LLC who
>>>          actually manages that contract.  But that seems in conflict with
>>>          the deliverables that use verbs like "coordinate" and "resolve
>>>          issues".  It would be good to clarify this, probably in the
>>>          "Reporting Relationships" section.
>>>           >
>>>           > - As others have noted, the April 1 RFCs belong to the ISE,
>>>          not the RSE.
>>>           >
>>>           > On Sun, Sep 8, 2019 at 11:51 AM Michael StJohns
>>>          <msj@nthpermutation.com <mailto:msj@nthpermutation.com> <mailto:msj@nthpermutation.com <mailto:msj@nthpermutation.com>>
>>>          <mailto:msj@nthpermutation <mailto:msj@nthpermutation>. <mailto:msj@nthpermutation <mailto:msj@nthpermutation>.>.com>>
>>>          wrote:
>>>           >
>>>           >     After thinking about it a bit, I decided I really didn't
>>>          like the SOW as
>>>           >     it mostly ignored the input the community had given in
>>>          the discussion to
>>>           >     the run up to the SOW.   So I wrote a new one.  This one
>>>          mostly
>>>           >     completely replaces the project summary with something a
>>>          bit clearer for
>>>           >     the bidders and I think more accurately describes the
>>>          role of the PM as
>>>           >     acting RSE.  The reporting relationship was changed to
>>>          more accurately
>>>           >     reflect the legal relationship between the bidder, the
>>>          LLC and the RSOC
>>>           >     and to constrain some of the issues we encountered in the
>>>          last few months.
>>>           >
>>>           >     Much of the Education and experience section survived,
>>>          albeit rearranged
>>>           >     and word twiddled in places.
>>>           >
>>>           >     Ditto for the skills section.
>>>           >
>>>           >     The "Operational Oversight" section is replaced by "Typical
>>>           >     Deliverables" and broken up into three sections as I
>>>          suggested in an
>>>           >     earlier email.
>>>           >
>>>           >     I also added an "optional deliverable" to cover April
>>>          fool's RFCs.
>>>           >
>>>           >     This is basically an SOW for an RSE, but with the
>>>          exclusion of planning
>>>           >     for evolution of the series.  That was the only thing I
>>>          could find as
>>>           >     "strategic".
>>>           >
>>>           >     Discuss!
>>>           >
>>>           >     Mike
>>>           >
>>>           >
>>>           >
>>> 
>>