Re: Please Review Draft IESG Statement on Activities that are OBE

Sounds like a good policy.  However, what is the motivation to put  
this in writing?  Is it that we are missing stronger language to let  
the IESG yank a charter?
The reason I ask is the participants in a work group SHOULD be the  
closest to the technology and aware of events. Because of that, if  
anything, I would expect folks in the work group to fold up shop long  
before the IESG tells them to.
Even this is a hard one to put a rule on: the SPEECHSC work group is  
all but dormant. In a sense, we are OBE, because all of the interested  
parties have coded to draft-ietf-speechsc-mrcpv2-17 already. So, do we  
shut down and declare victory? If we did, then MRCPv2 does not get  
published as an RFC, and all of those implementations become  
orphaned.  However, if there is literally only one person working on  
the draft, does that mean no one cares? I would offer people do care,  
but it is not directly visible.
Given that, do we really need another procedural document for which,  
at the end of the day, the procedure is "AD's work with work group  
chairs to determine if the work group should continue work"?
If anything, I would offer the excellent prescriptions described below  
should either be part of an update to 2026 or a BCP for how AD's  
should monitor and work with Work Groups, in general.

On Feb 1, 2009, at 7:48 PM, The IESG wrote:

> The IESG is considering publication of the attached IESG Statement on
> IETF activities that are overtaken by events (OBE).  Please review and
> comment.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to  
> the
> ietf(_at_)ietf(_dot_)org mailing lists by 2009-02-11. Exceptionally,
> comments may be sent to iesg(_at_)ietf(_dot_)org instead.
>
> The IESG
>
> ==========
>
> 1. Introduction
>
> IETF activities can be overtaken by events (OBE). For example, assume
> that a Working Group is chartered to address a particular problem.  
> While
> the working group is developing its solution to the problem, one of  
> the
> following events occur:
>
> - unrelated technologies evolve, causing the problem to cease to exist
> - unrelated technologies evolve, significantly decreasing the  
> magnitude
> of the problem
>
> In these cases, the WG is OBE. Its output no longer merits the
> investment that it requires. Therefore, the WG should be rechartered  
> or
> terminated.
>
> A WG can also be OBE if the community agrees that it should never have
> been chartered for any of the following reasons:
>
> - it addresses an ill-defined problem
> - it addresses a non-problem
> - it address a problem to which all solutions are worse than the  
> problem
> This memo describes several measures that ADs can take to prevent WGs
> from becoming OBE. It also describes several measures that can be  
> taken
> in the unhappy event that the IESG is presented with the output of a  
> WG
> that has been OBE.
>
> 2. Preventative Measures
>
> 2.1 Prudent Chartering
>
> Avoid charters that run longer than one or two years. When faced with
> multi-year efforts, break the task into smaller pieces that can be
> achieved in one-or-two year increments.
>
> 2.2 Frequent Charter Review
>
> Use re-chartering exercises to re-evaluate the problem that a WG is
> addressing. Do not recharter a WG to work on a problem that is OBE.
>
> 3. IESG Actions
>
> The worst outcome for a WG that is OBE is for that WG to continue its
> work and send its output to the IESG for publication. When that  
> happens,
> the IESG must choose among the following options:
>
> - publish with the status proposed by the WG
> - negotiate the document status with the WG and then publish
> - reject the document.
>
> If the IESG publishes the document unchanged, it may adversely impact
> the overall quality of the RFC series. If it rejects the document, it
> violates its charter with the WG.
>
> The IESG MUST NOT publish the output of WG that has been OBE as PS,  
> BCP
> or EXPERIMENTAL. Publishing under those headers would imply that the
> IETF proposes deployment of those solutions/experiments, which it
> clearly does not.
>
> The IESG MAY publish the output of a WG that has been OBE as
> INFORMATIONAL or HISTORIC. It should add an IESG note stating that the
> problem addressed by the document has been OBE.
>
> The IESG MUST NOT reject a document simply because it has been OBE. It
> must consider publication as INFORMATIONAL or HISTORIC.
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf-announce

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf