Design Summaries (Re: Intermediate wg summaries)

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf