ietf
[Top] [All Lists]

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

2009-02-02 21:02:10
Hi,

I think that all the proposed actions and decisions in the draft
statement are reasonable, and well within the IESG's scope
under RFC2026 and RFC2418. So almost no problems there.

Almost, because I'm not sure that the "MUST NOT publish" should
apply to Experimental. I think SHOULD NOT is strong enough for
Experimental; we already have a set of guidelines for Experimental
publication.

What isn't quite clear is how and when an activity becomes
agreed to be OBE. Is there intended to be a call to the community,
like a document Last Call or a WG Charter review? Or will the IESG
just reach a conclusion privately?

For example, may we expect to see a call for comments such as:

"Last Call: Avian Transport Mechanisms considered OBE.
The IESG is considering declaring the goals of the Avian Transport
Mechanisms (ATM) WG to be overtaken by events. This will cause
the WG to be closed, and the review of all ATM drafts will end.
The IESG plans to make a decision in the next few weeks,..."

Whatever method is chosen for establishing consensus, I think
it should be mentioned in the statement.

    Brian

On 2009-02-02 13:48, 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

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