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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Keith,

On Oct 16, 2017 19:00, "Keith Moore" <[e-mail]> wrote:

On 10/16/2017 01:05 PM, Spencer Dawkins at IETF wrote:

Keith has tagged the tension here. That's worth a specific mention.

On Mon, Oct 16, 2017 at 10:36 AM, Keith Moore <[e-mail]>
wrote:

> 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
>
>
> Working groups are good at identifying and fixing bugs, holes, and edge
> cases, but bad at architecture and design.  So I think I'd recommend having
> a BOF to introduce the topic, and requesting that individuals or small
> groups of people submit proposals via Internet-draft.  Then plan to hold
> another BOF at a subsequent meeting,
>

If you do what https://tools.ietf.org/html/rfc5434#section-2 suggests,

   It is also important to recognize the timing constraints.

[...]
agree.   And I also agree that this tends to mean that the likely minimum
time between "topic BOF" and "possible WG forming BOF" would be eight
months.   But sometimes it will be a year or more, and sometimes there will
be multiple topic BOFs, and sometimes there will never be a WG formed.
That should not be taken as an indication of failure.

Some things take time.  In particular, it takes time to develop mindshare
between people with very different views of a problem; or alternatively, it
takes time for someone to go and talk to people with lots of different
views on a problem and synthesize a solution that attempts to consider all
of their needs.

There are several pitfalls to avoid.

One pitfall is creating any expectation that topic BOFs and follow-on
efforts will definitely lead to WG creation.   If someone can come up with
a good solution that attracts broad interest, a WG should be created.  But
there might be no solution, and there might be conflicting solutions where
the conflicts aren't easily resolved - sometimes because a Major Player
doesn't want a standard that competes with its proprietary and/or siloed
solutions.

Another pitfall is the potential for people to torpedo such efforts -
though I think it's harder to torpedo self-organizing design teams than it
is to torpedo working groups.

Another pitfall is that "we're hoping we can find a common solution to
these separate problems" can be taken as a threat of the form "we're not
going to charter work on solutions to any of these separate problems until
we see if someone can propose a common solution".   I'm not sure what the
answer to that is, though it's not necessarily the case that a siloed WG
will come up with a solution more quickly.  It's amazing how long WGs can
sit in FIN-WAIT.   So maybe let the siloed WGs spin up too and invite
people to come up with a more general solution before they finish?    Not
sure.


I've been saying to the IESG that if we want to finish work sooner,
changing the way we doing things so we can start that work sooner seems
like the most obvious change we can make.


"sooner" may not be the best definition of the goal.


Agreed. I think it is *a* goal, and I know it's not the only goal.

IETF produces many more RFCs these days than it did in the late 1990s with
many fewer regular meeting attendees.   Some of the difference is in remote
participation, but some of it is in the work being fragmented - producing
more RFCs many not be an improvement if those RFCs are less
relevant/useful.

As far as I can tell, the biggest reasons for the delay are that the active
participants are overtaxed.  WGs take on too many work items often without
regard for how important those items are or how much energy there is to
actually do the work.   There are too many documents being written and not
enough reviewers.   People lack the energy and travel budget to revise
drafts year after year and attend meeting after meeting when quite often
there's very little feedback and thus very little sense of progress.   And
because there's so little feedback, even the slightest bit of negative
feedback (no matter how irrelevant or poorly informed) has to be taken as a
serious threat.

In other words the problem might not be so much that it's hard to start a
WG, as that it's hard to finish one.   Trying to narrow the focus to fewer
efforts that are each more relevant might help.


We certainly have more to talk about ...

Spencer

Keith