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 > > >