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

[Keith Moore <[e-mail]>]

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] <mailto:[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.  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.

Keith