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

Alia Atlas <akatlas@gmail.com> Mon, 16 October 2017 14:22 UTC

Return-Path: <akatlas@gmail.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 F11E21344EF for <ietf@ietfa.amsl.com>; Mon, 16 Oct 2017 07:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 IXhYocr-ULZM for <ietf@ietfa.amsl.com>; Mon, 16 Oct 2017 07:22:45 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 B44411344F0 for <ietf@ietf.org>; Mon, 16 Oct 2017 07:22:44 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id 196so5314019wma.1 for <ietf@ietf.org>; Mon, 16 Oct 2017 07:22:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xqVngx13++x+SibCyQCFq0FN/g8xns2nDZcTG4lhadw=; b=jwPbfnlYkFjOeLwSJXI2A+2v+fqu6tqvctqOTna+XeaeEZwVF/ZiF5EfnNyH6Pe4Zc RPDZL+B6cWGntPTeBMcWbgAffbn5wOKNsST8yry9LFlt+6t/zyCdD7kB/kZcfXg4g54m ZOugFgi9yhT34wZMq04jKzDMqqtpi0KGVT8vvR9q07Uk3rFanlLKy0Q0JOthmOatBQM9 5vhdsO3Oy0XAYPlQkuyXGhhYfLnwV/MsEQ4yR1GLkxHmUA1mZnoWweNDsjB4F20f2pQ7 8vGlgNDaAdBdtlCRfrFssXSGbR7E8P6mSympSP+m70Sz7MxlstAjToSXA95qClsFaZ/Q d3IA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xqVngx13++x+SibCyQCFq0FN/g8xns2nDZcTG4lhadw=; b=bfr4SJi3CY2hs1DV2/Mda5e9gG8izGMDwF29VZ0KCk4EQ1/l8hZFSTzTMFSqhbEszc h+FIQwgfXsKMC/vjiT6KyScL+ctQY4qTf0FZqcvYTGAYAzTXez+wGqqSY6gociyhvpYi LlB0tlOn3CYqQW6wsabjdZiX/rx/Z/WscfZ/lAdoQTRQtjyRl+pQqyaZ0kiv6VoXsvkA hECKXT3tu9ZCtrGzhTjPdoyvHMkJp60gWowuKqLPAkn9eGjXjIAWkJABHeQIZnCdRY7N HtyJPKbIFf2aiNTgOgzxbxKeQogvalvUfc8iSpsK6cEzpcbfjmy85s4BjJ8Cqg5z3VGd 0ntg==
X-Gm-Message-State: AMCzsaUFRVfHniNi9qBhYHufwOZpDQbp2IFJNy+c+o7RavpnSGd8JBkn OEtzp82A7fK2lVGyvmsHLUs67mpk3ZI00BtwejA38w==
X-Google-Smtp-Source: ABhQp+SNxiAsQV2ch+XMvgDukIyXeSRLtjU5rZU8GnHNEVKqtg+dASuXOKOrVB5LYkPOSj7Sl86fVXT+VNOy4mparrw=
X-Received: by 10.28.232.75 with SMTP id f72mr1004320wmh.90.1508163763010; Mon, 16 Oct 2017 07:22:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.183.202 with HTTP; Mon, 16 Oct 2017 07:22:42 -0700 (PDT)
In-Reply-To: <e29d2547-3ad1-9402-c4b7-a005982d003a@network-heretics.com>
References: <CAKKJt-fAaNPeeuSfS0Dv6vTAOXR=OS2XSKqPVMyxxr1O1tLwBg@mail.gmail.com> <e29d2547-3ad1-9402-c4b7-a005982d003a@network-heretics.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Mon, 16 Oct 2017 10:22:42 -0400
Message-ID: <CAG4d1rd=rnQvAorgu=NNAsStku7Pxe7cWLYjCuDvnHboQdTYuw@mail.gmail.com>
Subject: Re: Request for feedback - IESG thoughts about new work proposals
To: Keith Moore <moore@network-heretics.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a1147578a5b86e2055baabd0e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ABXQEXSlEdK_MXA6VRae_fGvvXI>
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: Mon, 16 Oct 2017 14:22:47 -0000

Hi Keith,

On Sat, Oct 14, 2017 at 8:17 AM, Keith Moore <moore@network-heretics.com>
wrote:

> On 10/11/2017 09:21 AM, 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.
>
>
> So I understand the scope of this request for feedback to be about
> improving IESG's ability to charter new work, and that's an admirable goal
> on IESG's part.
>
> However, I wonder if IESG has come to think of the purpose of BOFs as
> being to lead to new WG charters in the short term.   If true, I think it's
> unfortunate.
>
> One of IETF's biggest problems IMO is the tendency to silo work, to fail
> to recognize when there is a need for broadly applicable work rather than
> point solutions.   This in turn leads to a great deal of unnecessary
> complexity in network code and applications, and a tremendous amount of
> wasted effort.   The resulting tendency is to produce too many working
> groups, too many standards documents, and standards documents with
> too-limited scope or applicability.
>

Yes, I agree.  In routing, there are more targeted point solutions - partly
because the general protocols aren't sufficient, partly because proponents
are interested in one domain, and partly because it is incredibly hard to
join different solutions together or select one after work has started.

Note that I said this is IETF's problem, not specifically IESG's problem.
> But I see essentially no effort within IETF to try to identify common
> ground between different concerns, or to look for opportunities to address
> multiple concerns with a common framework.   And it's much easier to do
> this before working groups are chartered, than after.   IAB has sometimes
> tried to do this by holding meetings, but the meetings have seemed fairly
> exclusive (there are high barriers to participation) and also have taken a
> long time to produce results.
>
> I'd like to see an effort to encourage IETF participants in general (not
> just a few handpicked people) to think more broadly.   I'd like to see more
> meeting time devoted to identifying common ground and opportunities for
> more broadly applicable work.   Such efforts should NOT be expected to
> propose working groups, at least not in the near term.   It's fine if they
> do, but the expectation should not be there.   And I don't care what such
> sessions are called, but I think BOFs were originally supposed to be able
> to serve such purposes.
>

As Spencer mentioned, the challenging ideas tend to touch on multiple areas
or be so broad as to be hard to break down to concrete work items.  How do
we, the IESG, encourage proponents and others to do the map-and-gap wok and
describe the framework that is more broadly applicable?  Since I started on
the IESG, we've pushed back against unnecessary "process" or information
documents such as too many/poor use-cases, architectures, frameworks, and
requirements - but it feels like those are what is needed to adequately
explain and map the space for more broadly applicable work.  What happens
if a BoF isn't sufficient to help that work happen?
Does it make sense to charter WGs just focused on the map-and-gap?   What
about applicability?

Regards,
Alia


> And maybe IESG is too busy to charter them, because it needs to be focused
> on working groups.   Maybe that should be left to IAB or some committee
> appointed for that purpose.   But there should be a clearly visible path by
> which IETF participants can request such sessions.
>
> Keith
>
> p.s. It is tempting, if the only tool you have is a working group, to
> treat every problem as if the solution were more protocol specifications.
>