Nicely written, largely stating what might be obvious for many, but
still nice to see it in black and white.
A few comments/suggestions:
1) Section 3. Authors/Editors
I suggest that you suggest that WG (co)chair(s) add an editor that is
unrelated to the draft, but that they trust who has good editing skills. As we
all well know, that is half the battle for getting a draft successfully across
the finish line and to the IESG. How many times has the IESG seen drafts that
are not up to snuff in some (editorially-related) manner? This person might
also keep the draft's trajectory motivated in the forward progress direction.
Finally, in cases where a draft is controversial, this //might// aid in
diffusing any electric situations.
2) Section 5.2. Competing Drafts states:
Engineering for interesting topics often produces competing,
interesting proposals.
I suggest replacing "interesting proposals" with just "competing
proposals"
I'd also put a reference here to the point I made above.
3) A little further in this section, I suggesting amending the text a
bit from:
Sometimes,
multiple versions are formally published, absent consensus among the
alternatives.
to something like:
Sometimes, multiple versions are formally published, absent consensus
among the
alternatives. In this way, marketplace economics and preferences are allowed
to weigh-in on the relevancy of one approach versus the other(s). In these
cases, the working group should be prepared to revisit the drafts later once a
clear preference in the marketplace exists. At this time the working group
should be prepared to amend, narrow or delete the competing approaches as
necessary, in order to clarify the multiple approaches to as narrow a selection
of options as possible once the approaches are ready for Proposed Standard
status.
4) There is also no mention of functioning and interoperability of
implementations, and hence no reference to the "working code" part of the
mantra. I think it is important to provide some guidance in this regard during
all phases of the document's states. For example, two competing approaches,
but one with running and demonstrable interoperating code might cause a WG to
err in that direction rather than having competing approaches just because a
second one was dreamt up at the last minute for political reasons.
--Tom
Hi,
Dave Crocker and I have this little draft [1] discussing the process and
considerations for creating formal working group drafts that are targeted for
publication.
We believe that this may help clarify some of the issues and concerns
associated with this part of the process. We are targeting this as
Informational (i.e. commentary on existing process, not new normative
definition of process) and would like your input.
What is not clear?
What have we got wrong?
How should we resolve the remaining editor notes?
Thanks,
Adrian
(per pro Dave)
[1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt