Folks,
Steven M. Bellovin wrote:
Dave, a lot of this discussion has boiled down to a single topic, one
that's been talked about for a very long time: early, cross-area review.
Unfortunately, we've tried several schemes that haven't worked and we
don't really know how to do better.
Henning Schulzrinne wrote:
> In WG meetings, we're encouraged to talk about open issues, which often
> means that the same three people that have been arguing some
> angels-on-a-pin point on the mailing list, having lost everybody else,
...
> Similarly, in the plenaries, we rehash NAT and RFC-over-HTML arguments
> or learn about the number of enterprise numbers that have been assigned.
Spencer Dawkins wrote:
> When I was a WG chair, chairs were required to produce a SHORT summary
> of what the HECK was going on their working groups, each IETF week, due
> by Friday morning, for our ADs.
Each of the above refer to particular reporting or reviewing mechanisms that we
currently have or claim to have. (Spencer, the wgs that I participate in are
quite diligent to produce summaries of their f2f meetings.)
Each of the above is for a particular purpose: In-depth review by targeted
experts, progress on specification details or reporting that progress, as well
as community consideration (or haggling) of philosophical points. These are all
worthy tasks.
However none cover the reason for Design Summaries (I'm changing the name, a
bit.) The nature of a Summary has the wg take a step back from daily details
and create a snapshot of the basic design and specification decisions, to date,
but not as a list of individual decisions (or open issues.)
Instead it should try to the provide salient details as a coherent set. In
other words, a summary of the design, architecture or the like.
The purpose that this serves is to enable interested parties to understand the
salient aspects of working group effort, so far, in terms of that integrated
design, rather than as a project activity report. This includes workers in
related efforts, content experts, those considering participation, and those
likely to be consumers of the wg output.
Cross-area review is for a much more focused purpose, with targeted experts, and
goes much deeper than a Design Summary, I believe. Certainly a cross-area
reviewer might like to *start* with the latest DS. So might any reviewer, for
that matter.
Side notes:
1. For a community that seeks to be open and inclusive, an on-going
challenge is to incorporate new participants, after the working group has
developed significant history, as Henning notes. Currently either the new
participant must review all the docs and records and then decide whether to
participate, or they join in with too little background and burden the wg with
tutoring them. Pointing new folk at the latest Intermediate Summary could
greatly reduce the burden both on new participants and current participants and
greatly improve their understanding, when they start to participate.
2. It occurs to me that one small added bit of mechanism might facilitate
things -- although it would not serve in the stead of a DS: Have the issues
ticketing system used by the wg includ a "major decision" flag. This is merely a
way of noting decisions that are considered to be particular import, for
whatever reason. It does not cover a variety of decisions that are made
implicitly but could help anyone trying to construct a summary.
- - - -
Steve raises the larger question about making cross-area review (or, I believe,
*any* tracking, reporting, or quality-assurance mechanism) work. He views them
as a failure. My direct (and narrow) experience is quite the opposite.
I think this reduces to the very basic fact that we have some working groups
that have mature participation and diligent performance, and others that don't.
It is striking to me that IESG review seems not to distinguish between these.
(Perhaps the IESG believes it does. I will leave it as an exercise to the
reader as to why my own impression is that it does not.)
From what I am seeing, some wgs have embraced cross-area review vigorously.
Not merely to satisfy a bureaucratic requirement, but to ensure that possible
issues with related content specialties get due consideration, early in the process.
And perhaps that is the deeper point that we ought to consider: There are a
variety of things a wg can do, during the many months or years of its work, to
ensure competence and sufficiency of its output. I believe that Design
Summaries would fill a significant gap in the repertoire.
Whether a working group employs those tools and makes a diligent effort to
produce quality work that has significant community vetting, prior to dumping
its output into the IESG's lap, ought to be seriously considered.
d/
ps. As with many ideas that show up in these discussions, choosing to do a
Design Summary does not require formal approval by the IESG or IETF. It merely
requires the decision by a working group -- or for that matter, any wg
participant -- to create it and make it available. Given the popularity of
non-IETF support web pages for working groups, it would of course be trivial to
add the latest DS to that page...
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf