Re: Request for feedback - IESG thoughts about new work proposals

Eliot Lear <lear@cisco.com> Thu, 12 October 2017 07:45 UTC

Return-Path: <lear@cisco.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 8E096132F2E for <ietf@ietfa.amsl.com>; Thu, 12 Oct 2017 00:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ZK8-nd977TQw for <ietf@ietfa.amsl.com>; Thu, 12 Oct 2017 00:45:03 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0DD132143 for <ietf@ietf.org>; Thu, 12 Oct 2017 00:45:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23781; q=dns/txt; s=iport; t=1507794302; x=1509003902; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=2eiBoNpkCZ08JZOshGdngclCrfcpCvsaqBBWSPSxlWc=; b=HyX36YEBwgdY3d0skZ53+rxbqldWkm0uWKla264TnRuEmUAHH1Saw5W6 0FIMiTIiACzyZ/qwaiHTJsRTaczcB6477h53SmTqbF7MLdtWSkBDmu89n W2qozrov7vQvVZVEl46Fz3etliiU802ojrvGATpzPYTDMUw8Kecs68EAr Y=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DPAADlHN9Z/xbLJq1TChkBAQEBAQEBAQEBAQcBAQEBAYMvgRJuJ4N6ih90kA4ili+CEgcDJ4UUAoUlGAECAQEBAQEBAWsohR0BAQEDASNLEAsLGCcDAgJGEQYBDAYCAQEQB4l7CBCpGYInJ4sTAQEBAQEBAQMBAQEBAQEBAQEBAQ4KBYMthUIrC4FmgQ6BJIM2gz6CYQWHR4l9j36EPIIhgQGDYoNhhUiCL4kyhy5wlHWBOR84gQ4yIQgdFUmCXYI9HIFpPjYBimsBAQE
X-IronPort-AV: E=Sophos;i="5.43,365,1503360000"; d="asc'?scan'208,217";a="655405749"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2017 07:44:57 +0000
Received: from [10.61.111.29] (dhcp-10-61-111-29.cisco.com [10.61.111.29]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9C7ivbs020906; Thu, 12 Oct 2017 07:44:57 GMT
Subject: Re: Request for feedback - IESG thoughts about new work proposals
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>
References: <CAKKJt-fAaNPeeuSfS0Dv6vTAOXR=OS2XSKqPVMyxxr1O1tLwBg@mail.gmail.com>
From: Eliot Lear <lear@cisco.com>
Message-ID: <b0d5bbdb-9fb4-6394-a6be-57300773e7d0@cisco.com>
Date: Thu, 12 Oct 2017 09:44:58 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAKKJt-fAaNPeeuSfS0Dv6vTAOXR=OS2XSKqPVMyxxr1O1tLwBg@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="e7TvmqwmgMmbuCNJHX1As1kDVL7lXgOuE"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/4RS2O3hE-hFhTjXpRoMYvoirits>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 12 Oct 2017 07:45:06 -0000

Hi Spencer,

Thanks to the IESG for focusing on how to better develop new work at the
IETF.  The note is a good start, but let me ask a question:  Our working
methods are evolving.  Should your note be focused on bofs or on new
work as a whole?  For instance, is it worth doing a broader message that
answer some more general questions, like these:

  * How best to determine which area to bring work to in the first place?
  * How can the IESG facilitate nascent ideas prior to their entering
    the formal standardization (e.g., non-wg mailing lists, bar bofs,
    presentation at one of the area meetings, etc) and how to arrange
    for these activities?
  * When to use a bof and when to use a wg like dispatch (or perhaps
    secdispatch)?
  * When to (not) approach an AD to do AD-sponsored work?
  * Can one make use of shepherds and what is their role?
  * What to do when you believe you've hit a wall.

As perhaps a trivial example of why the timing is good to do such a
thing, were one to look at the Tao, one would see that it does not even
list the current set of IETF areas, nor does it have contacts for those
areas.  There are other issues.  Same holds true for the new work
tutorial from IETF 81.  Fine documents when they were written, but time
as passed.

The role of the IAB could also use a dusting off here.  For instance,
should one have to wait for a bof to get a shepherd out of the IAB? 
Should the IAB members themselves have to perform that role or could
they perhaps make use of program members or other members of the
community to assist?

By taking this broader approach it helps to start from the position of a
new participant who has some bright idea and is trying to figure out a
road to success.  Having both positive and negative examples would
help.  A lot.

Yes, this is more work.  No, you probably don't have the time.  You
might want to ask the community for help along these lines. 

Eliot


On 10/11/17 3:21 PM, Spencer Dawkins at IETF wrote:
>
> The IESG has spent considerable time discussing how we can improve our
> ability to charter new work as soon as it’s ready and ensure proposals
> have the resources needed for success. We want to share our
> expectations about BOF requests and new work proposals with the
> community because we are interested in feedback. 
>
>
> We ask for feedback, either on the IETF Discussion List (so, replies
> to this note are fine), or optionally, to the IESG at iesg@ietf.org
> <mailto:iesg@ietf.org>. We would like to put this in place soon after
> IETF 100.
>
>
> We would like to see earlier notice about proposals for new work, and
> more attention to specific work products in proposals.
>
>
> *** Earlier notice to ADs about proposals for new work to enable
> better support and improving chances of success
>
>
> We ask that proponents provide BOF requests and proposals for new work
> as early as possible so that your area directors can begin evaluating
> these requests long before our coordination call with the IAB each
> IETF meeting cycle. 
>
>
> Earlier notice about new work proposals will give area directors more
> time to provide direction, to involve other IETF participants with
> relevant backgrounds and related interests, and to confirm whether a
> BOF would be required to consider a proposal for new work.
>
>
> Earlier notice about new work proposals will also give area directors
> more time to request that the IAB provide BOF shepherds to help
> improve BOF requests, when that is appropriate, and more time for BOF
> shepherds to help to improve the BOF proposal. 
>
>
> The IAB's expectations are described in their statement on "IAB Member
> Roles in Evaluating New Work Proposals"[1].
>
>
> *** More focus on specific work products in new work proposals
>
>
> The IESG has received some BOF requests that describe interesting
> problems at considerable length but do not clearly identify what the
> BOF proponents want the IETF to do. When that happens, we cannot
> approve a BOF intended to form a working group.
>
>
> In some cases, area directors might approve a non-WG-forming BOF to
> tease out the details of the BOF proposal, but often that isn’t the
> best way forward. However, we also want to put ideas in front of the
> IETF community early in the process, in order to gauge community
> interest and feasibility. 
>
>
> The BOF Wiki at https://trac.tools.ietf.org/bof/trac/wiki, where we
> collect BOF requests for each upcoming IETF meeting cycle, will be
> using this template:
>
>
> - Long name and abbreviation
>
> - Description, including whether the BoF is intended to form a WG or not
>
> - The responsible Area Director (AD)
>
> - Suggested BoF Chairs (or the ADs as placeholders)
>
> - Number of people expected to attend
>
> - Length of session (1, 1.5, 2, or 2.5 hours)
>
> - Conflicts to avoid (whole Areas and/or WGs)
>
> - Links to the mailing list, draft charter if any, relevant
> Internet-Drafts, etc.
>
>
> Proponents are encouraged to add new entries in the BoF wiki even if
> they don't have all information that the template is asking for yet.
> The entry can be modified until the Cut-off date for BOF proposal
> requests to Area Directors, which is available from
> https://ietf.org/meeting/important-dates.html. 
>
>
> When writing the description, the IESG strongly encourages BOF
> proponents to focus on the work that would be reflected in an approved
> working group charter. What we are looking for is:
>
>
> - What protocols or practices already exist in this space?
>
> - What modifications are required for the purpose described in the BOF
> request? 
>
> - What entirely new protocols or practices must be developed?
>
>
> We prefer that BOF proponents do this mapping, and gap analysis,
> rather than relying on the IESG, the IAB, and the broader community.
> That will help us make better decisions more quickly about approving
> BOFs, and to charter new work more quickly, that produces solutions
> more quickly. As we said in "Support Documents in IETF Working Groups"
> [2], 
>
>
> "In order to speed up the time period from idea to running code, the
> IESG supports working groups that commence solution work early in the
> working group timeline, and do not wait for completion and publication
> of the support documents. When the problem scope is well understood
> and agreed upon, charters focused on solutions work are extremely
> efficient."
>
>
> Spencer Dawkins, for the IESG
>
>
> [1]
> https://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-member-roles-in-evaluating-new-work-proposals/
>
>
> [2] https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html
>