Hi, Keith,
On Oct 16, 2017 19:00, "Keith Moore" <moore@xxxxxxxxxxxxxxxxxxxx> 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 <moore@xxxxxxxxxxxxxxxxxxxx> 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,AliaWorking 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."sooner" may not be the best definition of the goal.
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.
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