Hi, Wes, all, +1 to "no one-size-fits-all". A model that's worked well in a few groups I've been involved in is something between (2) and (3), where the defined criteria is "complete enough that interoperable implementations could conceivably be produced", a slightly lower bar; with the added caveat that discussion of the developing individual draft is encouraged on the working group list, and will be given second-preference agenda time at meetings. This allows a smaller group around the initial authors to build a coherent proposal, without shutting those out from the process who are motivated to contribute. The WG -00 then has at least plausible suggested answers to the most obvious questions raised, and can be modified by the WG from there (or, indeed, eventually rejected if it turns out the broad approach is incapable of drawing consensus support). This looks basically like a design team approach with self-appointed design teams. This approach would tend to work better for incremental or self-contained work around an already-elaborated framework or theme. Best regards, Brian On 28 Nov 2012, at 16:36 , George, Wes wrote: >> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of >> John Leslie >> >> I'm increasingly seeing a "paradigm" where the review happens >> _before_ adoption as a WG draft. After adoption, there's a great lull >> until the deadline for the next IETF week. There tend to be a few, >> seemingly minor, edits for a version to be discussed. The meeting time >> is taken up listing changes, most of which get no discussion. Lather, >> rinse, repeat... > > [WEG] I've seen several discussions recently across WG lists, WG chairs list, etc about this specific topic, and it's leading me to believe that we do not have adequate guidance for either WG chairs or participants on when it is generally appropriate to adopt a draft as a WG document. I see 3 basic variants just among the WGs that I'm actively involved in: > 1) adopt early because the draft is talking about a subject the WG wants to work on (may or may not be an official charter milestone), and then refine a relatively rough draft through several I-D-ietf-[wg]-* revisions before WGLC > 2) adopt after several revisions of I-D-[person]-[wg]-* because there has been enough discussion to make the chairs believe that the WG has interest or the draft has evolved into something the WG sees as useful/in charter; Then there are only minor tweaks in the draft up until WGLC (the above model) > 3) don't adopt the draft until some defined criteria are met (e.g. interoperable implementations), meaning that much of the real work gets done in the individual version > > It seems to me that these variants are dependent on the people in the WG, the workload of the group, the chairs, past precedent, AD preferences, etc. It makes it difficult on both draft editors and those seeking to follow the discussion for there to be such a disparity from WG to WG on when to adopt drafts. I'm not convinced that there is a one-size-fits-all solution here, but it might be nice to coalesce a little from where we are today. > So I wonder if perhaps we need clearer guidance on what the process is actually supposed to look like and why. If someone can point to a document that gives guidance here, then perhaps we all need to be more conscientious about ensuring that the WGs we participate in are following the available guidance on the matter. > > Wes George > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.