Re: Front-end delays

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]