Keith,
I think there are two stages of chartering:
- the early "we don't quite know what we're doing and what shape this
will take, just the general direction"
and the
- "most work items have drafts associated with them"
In my suggestion, a WG would amend the charter with additional detail
once a draft has been started. Alternatively, if charter items are
referencable (database) items rather than text, the I-D tracker could
easily point to the charter item the draft addresses, without amending
the charter.
Also, I think that part of the difficulty of having this discussion is
that our experiences are biased by the working groups we participate in.
There are at least two kinds, from what I can tell:
(1) Single "big-ticket" item: "Develop a [new] protocol to do X". There
is one clear main spec, with auxiliary documents such as requirements,
MIBs and such. This classical IETF approach used to dominate; I'm
guessing that relatively few WGs follow this model today. Among the
groups I attend, NSIS and ECRIT are relatively close to that model.
(2) Maintenance WG: A WG is maintaining a technology and producing a
more-or-less steady stream of related extensions, specifications and
updates. Examples I'm familiar with include MMUSIC, AVT, SIPPING, SIP,
TSVWG.
Clearly, a WG with three specs on its charter can function well with
manual processes and human memory. SIPPING, to continue the example,
lists (http://tools.ietf.org/wg/sipping/) on the order of 40 drafts in
various stages of being processed.
Btw, there are some WGs that make this a bit easier: See
http://www.ietf.org/html.charters/6lowpan-charter.html for an example.
(Unfortunately, my example isn't helped that in this particular case
none of the drafts referenced seem to exist, although all but one
deadline has passed.)
Henning
Keith Moore wrote:
IMHO, at WG charter time we typically don't understand the problem
well enough to be specifying things like how many documents there should
be in the final product or what should be in those documents. That,
and "published an I-D describing X" is not a very useful charter
milestone. To the extent we make milestones out of documents we should
require that the WG get rough consensus on those documents before they
are considered complete.
The milestones we most need to track aren't the WG's final products,
but the preliminary steps, because the failure of a WG to address
important details early its lifetime is what seems to cause WGs to bog
down later.
I don't see anything wrong with creating milestones like this:
- the WG needs to reach consensus on a document describing its
scope in detail - design goals and non-goals, and identifying
any effects that the WG's work might have on other concerns.
this doesn't have to be published as an RFC, and it might
actually be better if it's not published as an RFC. but it does
need to get WG consensus.
- the WG needs to solicit external review of that document and
respond to that review and revise the document as appropriate
- the WG needs to entertain and review proposals for a solution
(including soliciting external review)
- the proposers need to respond to review and revise their
proposals
- the WG needs to choose one or more candidates for a solution
from among the revised proposals
etc.
If we took pains to select useful milestones, a WG progress
tracker might be quite useful.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf