Re: Changes to the way we manage RFPs

John C Klensin <john-ietf@jck.com> Wed, 26 February 2020 07:19 UTC

Return-Path: <john-ietf@jck.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 1C89D3A0FC0; Tue, 25 Feb 2020 23:19:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 VFnX9bXEgVr4; Tue, 25 Feb 2020 23:18:59 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EF23A0FB7; Tue, 25 Feb 2020 23:18:59 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1j6qy8-000Ev8-J9; Wed, 26 Feb 2020 02:18:56 -0500
Date: Wed, 26 Feb 2020 02:18:49 -0500
From: John C Klensin <john-ietf@jck.com>
To: Jay Daley <jay@ietf.org>
cc: Bob Hinden <bob.hinden@gmail.com>, IETF <ietf@ietf.org>
Subject: Re: Changes to the way we manage RFPs
Message-ID: <E6815976BDDAFB2B06809DEC@PSB>
In-Reply-To: <397FF897-441C-41A7-8C74-F667C232BC64@ietf.org>
References: <908BCE29-8F0B-4451-B25F-A318B967EBC0@gmail.com> <397FF897-441C-41A7-8C74-F667C232BC64@ietf.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/JRSKarlo0pkq-CVR0ygNA9DtRXs>
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: Wed, 26 Feb 2020 07:19:08 -0000

Jay,

--On Wednesday, February 26, 2020 19:09 +1300 Jay Daley
<jay@ietf.org> wrote:

> As I said to Brian, it would be useful for me to understand
> why subscribing to rfp-announce - did I just need to make it
> clearer that this is a zero sum change as far as email volume
> goes?
> 
> My concern btw is the lack of a clear principle that decides
> what gets copied to ietf-announce and why (assuming you
> don't mean everything that goes to rfp-announce). 

My answer may differ from Bob's and Brian's, but have an
observation and possible reason that generalizes far beyond this
change.  There are at least two kinds of openness and
transparency.  One is to have information available to those who
know where to find it and take the time to go looking for it.
The other involving "pushing" the information and its
availability with the expectation that people may stumble across
information of interest, especially information about topics on
with they are not only interested but expert but would not have
thought to go looking for.   The most important example of this
applies to our standards process and one of the big advantages
of f2f meetings over remote participation: if someone is at a
f2f meeting and doesn't have a WG in which they are particularly
involved in a given slot, they may find something in that slot
about which they are mildly curious, wander in, and actually
learn something and/or contribute.  People participating from
their own desks are much more likely to find something else to
do.

It may seem like a stretch to get from there to announcements
about RFPs, but understanding what RFPs are out there and, more
important, how you and the IETF Administration LLC are breaking
things up into pieces may be more important to the community
than we generally realize.  It may be particularly important for
the community to monitor the tendencies of all bureaucracies to
divide work up into more pieces in ways that justify more
contracts, contractors, and administration and therefore more
staff and other resources.   I am _not_ suggesting that we have
that problem or that we would ever have it under your
administration, but it is a long-term, known risk.  Probably
more important in the near term, an unexpected notice of an RFP
might allow some member of the community with particular
expertise, one who normally has no interest in RPFs, to speak up
and say "hey, I know something about that and, while I have no
interest in bidding, I think you are structuring it all wrong
for the following reasons".  It would be unfortunate to lose
that type of expertise and opportunity for input even if it
comes infrequently.  It would also be unfortunate to lose the
possibility of someone spotting a particular RFP topic for which
they know someone with expertise who might not otherwise hear
about an opportunity and alerting that person even though they,
themselves, have no interest in ever bidding on an RFP. 

I worried about the same thing when we split the Last Call list
out: as IETF's work gets more specialized, if someone comes to
the IETF specifically to participate in a specific WG or two,
they may not feel a need to subscribe to the Last Call list
because notifications for Last Calls on that WG's work will be
clear from the WG list and discussions.  But, if they do not
subscribe to the Last Call list, we lose out on whatever topics
they might serendipitously be alerted to for which they have
expertise -- in other WGs, in other areas, and in individual
submissions.  
 
Those are really not arguments to avoid splitting the lists.
Instead, they suggest that, if you are going to do such a thing,
that you be aware of possible unintended side-effects and figure
out a way to mitigate them or even improve things because of
them.  Would we benefit from a monthly summary report from you,
one that summarizes or details outstanding RFPs, not just
plenary reports?  Do we need more explanatory material about why
those who subscribe to the IETF-announce list might want to
subscribe to the other lists too?  Should subscribing to
IETF-Announce automatically put one on the other lists on an
opt-out basis rather than requiring people to find them one at a
time and subscribe (that would protect people who only want to
see the RFP list from being bothered by the irrelevant-to-them
traffic on the IETF-Announce but would keep the information for
subscribers to the latter constant)?  As we continue to break
things out (I definitely see a trend) should we think of
IETF-Announce as a list of lists to which people can subscribe
(or opt out) selectively if they so choose but whose default is
"all announcements"?

And so on.  I don't know the answers to any of those questions,
but would hope that you (and we) would think about them.

best,
   john