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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] 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.