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

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 10 September 2019 21:10 UTC

Return-Path: <jmh@joelhalpern.com>
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 B14D6120273 for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2019 14:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 q0Ao239bR7tc for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2019 14:10:36 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1028120255 for <ietf@ietf.org>; Tue, 10 Sep 2019 14:10:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 46Sd3c4jKtz1Z1MG; Tue, 10 Sep 2019 14:10:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1568149836; bh=jVXGx6Izxmj6Tywly7/pwLaonsmKCiVwguaRrvVdNFU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Xm90eSCfQi4NZDfxH4CqZVbpZkl1f4htQFMhdNAy2bZUyhgNBmcM47+LNT8zLpDHK uHw7eT+2WbE0XKJ0wkxlqoYP4VV7f2zzxoUMXlujIkUyFzUk0PLlxqCY8wpubDRGz+ ClWv3RatGbIwuh6K4ML6zy2ip9wDbxlL+YyfaCQ0=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [172.20.7.244] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 46Sd3b5YS2z1Z1MF; Tue, 10 Sep 2019 14:10:35 -0700 (PDT)
Subject: Re: Try this: was Re: New proposal/New SOW comment period
To: Richard Barnes <rlb@ipv.sx>, Eric Rescorla <ekr@rtfm.com>
Cc: RFC Interest <rfc-interest@rfc-editor.org>, Michael StJohns <msj@nthpermutation.com>, IETF Discuss List <ietf@ietf.org>
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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <1dbc8dbe-d883-a433-8dc4-247ac1760152@joelhalpern.com>
Date: Tue, 10 Sep 2019 17:10:33 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAL02cgS88fD7BkrE4T0A+S99xN-b4JZDm4yu2nLAb3oiG50S4g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/CEI2gU_69t8eKBKZm8f6nUhG4ew>
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 21:10:39 -0000

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>> wrote:
> 
> 
> 
>     On Tue, Sep 10, 2019 at 1:39 PM Brian E Carpenter
>     <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. <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
>          >
>          >
>          >
>