Design Summaries (Re: Intermediate wg summaries)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]