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

From: The IESG <[email-masked]>
Date: Sun, 1 Feb 2009 16:48:52 -0800 (PST)

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
[email-masked] mailing lists by 2009-02-11. Exceptionally, 
comments may be sent to [email-masked] 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 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Feb 2009 15:01:08 +1300

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:
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Feb 2009 15:44:40 +0100

Two concerns.

1) As the chair of a WG that many will consider to be a prime example of 
OBE, I am a bit worried about the "MUST NOT publish" statements.

A traditional antidote to long-running WGs has been to kill them and 
tell the editors "if you really want to finish up, you can always do 
individual submission" - and individual submission has no barrier to 
publishing PS or Experimental for OBE technologies - the traditional 
mantras being "this is an experiment to see if interest revives" or 
"this PS is replacing another, even more OBE PS".

I wouldn't want to put a WG into a situation where its work items get 
"better" treatment if the WG is shut down and items progressed without 
WG review than it does if the WG remains active.

2) For completeness, I'm also quite puzzled as to why the IESG statement 
does not contain the words "If the IESG determines that a WG is OBE, the 
IESG will shut down the working group" at the end of section 2. Even if 
that happens after the WG submits documents to the IESG, so that the 
IESG has to follow the advice in section 3, there seems little reason to 
let it hang around.

A logical reason might be that the IESG doesn't want to take on the 
excess heat generated by declaring a WG to be OBE and closing it - but 
in that case, it can never invoke the procedure in section 3, since the 
WG hasn't been declared OBE (unless the OBE declaration is done in 
secret, which would be very un-IETFish).

If OBE => closed, the handling should become simpler.

                           Harald

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Feb 2009 18:42:42 +0200

Brian,

> Experimental; we already have a set of guidelines for Experimental

I think I agree with this.

Jari

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Feb 2009 11:51:49 -0500

Hi.

I largely agree with Harald's comments, which I will not repeat.

I do, however, have a concern that he didn't mention (and might
not agree with).  While I am generally in favor of the IESG's
telling the community about how it thinks about issues, there is
a fuzzy boundary between doing that and trying to create more
and more rules and mechanisms in the hope that those can be
substituted for careful judgment.  There isn't quite enough
information in this statement for me to be sure how the IESG
intends to use it (that is not a complaint), but I fear it will
lie on the "more rules" rather than "better explanation" side of
the boundary.  

It appears to me that it creates a new category and set of rules
about that category, but that the criteria for getting something
into that category are extremely subjective and dependent on
IESG judgment.  That may be ok, but the IESG has always had the
authority to shut down WGs because they are not making progress
or have become irrelevant and has always been able to make
determinations about the proper classification of documents.  

Put differently, I don't understand the problem that this
document is trying to solve.  Classifying something as OBE
doesn't move us forward any better than simply identifying what
is actually going on.  After reading the statement, I have no
more information about how to identify something as OBE than I
do about how to identify a WG as not working on anything anyone
cares about.  The advice to avoid chartering WGs with very long
running times has been part of the culture for as long as I can
remember; it is not clear that recommendation in this document
will make any difference.

I don't seem much difference between the IESG (or an AD) saying
"this WG is not making any progress on any subject that anyone
cares about any more" and generating a statement that permits
identifying a subset of those cases with a specific label.  If
there is no difference, then this document is useless but
harmless except insofar as it contributes to a growing pile of
rules.  On the other hand, if the difference is that classifying
something in this way constrains the IESG's ability to apply
good sense and case-by-case analysis to what ought to be done
with partially-complete WG products, then it could easily be a
problem rather than a solution to one.

If the real problem is that the IESG has decided that ADs
cannot, in practice, shut WGs down when people still want to
work in them, no matter how irrelevant the work has become or
how little progress the WG is making, I suggest that new
"statements" and categories won't solve that problem because the
same folks who would object to the WG being shut down under
existing rules will object to its being defined as OBE so it can
be shut down.

     john

--On Tuesday, February 03, 2009 15:44 +0100 Harald Alvestrand
<[email-masked]> wrote:

> Two concerns.
> 
> 1) As the chair of a WG that many will consider to be a prime
> example of OBE, I am a bit worried about the "MUST NOT
> publish" statements.
> 
> A traditional antidote to long-running WGs has been to kill
> them and tell the editors "if you really want to finish up,
> you can always do individual submission" - and individual
>...

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Feb 2009 12:07:39 -0500

--On Tuesday, February 03, 2009 18:42 +0200 Jari Arkko
<[email-masked]> wrote:

> Brian,
> 
>> 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.
>>   
> 

Setting my other misgivings aside, +1.

However, I just tried to think about the cases in which we would
want to publish something as experimental that we had concluded
were OBE.

(1) In the late 80s and early 90s, a large fraction of the
community (probably a majority) had concluded that TCP/IP was
OBE.  We had an entire IETF Area devoted to OSI Transition.
Fortunately, we did not shut down all of the WGs that depended
on TCP or IP as this document would suggest if it has been
applied at that time.

(2) Using the criteria in the document, we would have shut down
(or never started) any work on XMPP because it appeared at the
time that the marketplace had decided on a set of incompatible
and proprietary protocols.

(3) Given those two examples, and probably others, I think there
may be a place for publishing specifications that appear to be
dead ends as Experimental or even, with appropriate disclaimers,
as Proposed Standards.  The conclusion that the technology is
OBE could be wrong and the community and IESG should be able to
make judgments about the risks of being wrong, the advantages of
having alternate technologies well-specified in case the
marketplace choice turns out to be unworkable in practice.

So, again, I'm not quite sure what problem is being solved here
and I think an argument should be made for "more good sense and
judgment and fewer rules that then turn out to over-constrain
us".

    john

---

From: SM <[email-masked]>
Date: Tue, 03 Feb 2009 09:37:15 -0800

Hello,
>IETF activities that are overtaken by events (OBE).  Please review and

[snip]

>investment that it requires. Therefore, the WG should be rechartered or

The draft statement mentions how a WG can be overtaken by events.  It 
describes measures to prevent that from happening and IESG action 
about publication of WG documents if the WG is overtaken by 
events.  The only mention of whose going to do the OBE pronouncement 
is through an IESG Note when the document is published.

>- it address a problem to which all solutions are worse than the problem

Will the IESG be formally asking the IETF community whether a WG 
should be declared as OBE?

At 06:44 03-02-2009, Harald Alvestrand wrote:
>2) For completeness, I'm also quite puzzled as to why the IESG 
>statement does not contain the words "If the IESG determines that a 
>WG is OBE, the IESG will shut down the working group" at the end of 
>section 2. Even if that happens after the WG submits documents to 
>the IESG, so that the IESG has to follow the advice in section 3, 
>there seems little reason to let it hang around.

If the IESG determines that a WG is OBE, it should say so instead of 
creating "do not publish" rules.

Regards,
-sm

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 3 Feb 2009 11:40:47 -0600

Speaking as someone who usually doesn't know what the IESG is thinking ... 
;-)

I applaud the attempt to explain this situation to the community, and can 
only echo that during my years as IESG scribe, this situation does arise 
fairly frequently - I'd guess quarterly, just from memory. So it is nice to 
see the IESG talking to the community, and trying to be proactive, instead 
of waiting until the OBE specification hits Publication Requested and 
everyone freaks out (as the statement says now).

("Always easier to talk about the general case than about $THIS working 
group")

But I also share John's concerns about (inadvertantly?) constraining the 
IESG's ability to use judgement and face the resulting feedback, when the 
Right Thing to Do may not have been anticipated when the IESG made the 
rules.

Most of this statement does NOT use 2119 language, so I was reading the text 
that doesn't use 2119 language as an attempt to explain to the community 
what the IESG is likely to do, and reduce the level of astonishment when the 
situation comes up. I liked that more.

John, if the existing 2119 language went away, and the statement pointed out 
(as you said) that the IESG has always had the authority to do what the 
statement describes, would that help?

I'd also suggest including a sentence that points out the costs of us 
producing and publishing ANYthing - I know that I've talked to a lot of IETF 
people who don't usually think about these costs. That might help the 
community focus when an IESG question about OBE hits the community.

("is this work worth the impact it will have on getting YOUR work through 
the IESG, and the impact it will have on YOUR registration costs?")

Thanks,

Spencer

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Feb 2009 14:50:13 -0500

--On Tuesday, February 03, 2009 11:40 -0600 Spencer Dawkins
<[email-masked]> wrote:

> Speaking as someone who usually doesn't know what the IESG is
> thinking ... ;-)
>... 
Spencer,

Since you addressed part of your comments to me, let me try a
specific answer:

(1) Anything that clearly shifts this document toward "guidance
to the community about how the IESG is thinking about things"
and away from "more rules" will make me proportionally happier.
Certainly eliminating the 2119 language would help in that
regard.

(2) The reason I asked the question about what the problem was
being solved is that I don't believe we have an OBE
specification problem.  I believe we have a problem that derives
from an apparently growing reluctance on the part of the IESG to
shut down disfunctional and non-productive WGs and WGs that are
just not worth the resources they consume.  The OBE situation is
just a special case of that more general problem.  I imagine
that the reluctance is caused by the IESG not believing it has
community support for such shutdowns.  More specifically, while
much of the community favors them in the abstract, shutting down
a WG will almost always upset those who have invested work in it
and, in today's IETF, they will be a lot louder than those who
will applaud the action.  If that is, in fact, the problem, then
I don't think posting this document as a special case will solve
it. At the same time, if the IESG has decided that, even if they
can't or won't solve the disfunctional WG problem generally,
they are willing to take a stand about the OBE case, I'm in
favor of it.

(3) Finally, reprising many comments and specific suggestions
over the years, I believe "under what circumstances should we
shut this WG down?" is the wrong question.  Instead, we should
be devising criteria, interpreting benchmarks, and possibly
using IESG turnover as triggers for review of WGs, reviews that
start from the assumption that, beyond a certain point, a WG
needs to justify its continued existence rather than requiring
an AD to justify calling it off.  I don't know if it is still
possible to do that in the IETF, but I note that ISO (including
ISO/IEC JTC1) learned the value of shutting down projects how to
do that, in part, from us and created more specific sunset and
timeout procedures around it than we ever had... and that,
during the same period, we forgot how to shut WGs down when they
were not performing.

   john

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 3 Feb 2009 14:01:57 -0600

Hi, John,

Your observations make sense to me. Thanks for sharing, as always.

Spencer

From: "John C Klensin" <[email-masked]>

Date: Tue, 03 Feb 2009 12:18:38 -0800
From: Randy Presuhn <[email-masked]>
Subject: Re: Please Review Draft IESG Statement on Activities that are OBE
Sender: [email-masked]
To: [email-masked]

Hi -

> From: "John C Klensin" <[email-masked]>
> To: "Spencer Dawkins" <[email-masked]>; "Harald Alvestrand" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, February 03, 2009 11:50 AM
> Subject: Re: Please Review Draft IESG Statement on Activities that are OBE
...
...

The proposal strikes me as largely a statement of common sense.
However, "common sense" is notoriously difficult to state correctly
in formal terms, and a fear that the 2119 terms lack the fuzziness
needed for this kind of proposal.  We *generally* don't want to spend
resources on things OBE, but there are cases (like TCP/IP) where
it might be in the organization's interest to do so anyway.

Randy

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Feb 2009 23:15:16 +0200

John,

> ... a large fraction of the
> OBE.  ...
> ... we would have shut down
> (or never started) any work on XMPP ...

Right.

> lie on the "more rules" rather than "better explanation" side of

That is something that I also care about. Note that the statement says 
almost nothing about the real reasons for being OBE; the IESG and the 
community need to apply judgment in making such decisions.

For instance, what is a "non-problem"? We have to be very careful about 
that. For instance, I think it would be inappropriate to declare an 
application as something addressing a non-problem when its only used by 
a small number of people. Its hard to predict usage patterns, and what 
seems to be "winning" right now may be dead tomorrow, and vice versa. A 
far more workable rule for continuing IETF work is whether the group 
actually invests cycles in it, progresses specifications, produces 
technically sound solutions, has running code, and so on. Even the most 
non-OBE WG may have to be terminated, if no one is doing work.

But where these decisions get difficult is when the different indicators 
give you a different answer. For instance, if you have an active WG that 
has half a dozen implementations and is making progress with its 
specifications, but everyone else in the IETF believes we do not need 
it, the WG has hard remaining issues in its specifications, or that the 
results may even be harmful in some context. There is no easy answer in 
such cases.

Jari

---

From: Thomas Narten <[email-masked]>
Date: Mon, 09 Feb 2009 16:39:53 -0500

At the 20k level, I pretty much agree with everything John has said.

This smells to me mostly of a way for the IESG to have an friendlier
way of shutting down a WG without huring people's feelings. Sorry, but
I think this missed the point. (I would be fine with individual cases
being closed due to OBE, but even then the reasons will be nuanced and
not covered by a broad statement.)

OBE is not well defined, and folk will just start arguing about
whether something really is OBE or not. I.e, we're just moving the
problem elsewhere. In some cases, the problem may be easier to solve
this way, but in others I doubt it.

John C Klensin <[email-masked]> writes:

> an AD to justify calling it off.

I think this is right. And the question isn't whether an effort is
OBE, but rather: is the effort a still a good use of IETF cycles. That
can be measured in many ways, including:

  - is there (still) a real customer for this work at the end of the
    day?

  - is the effort making decent progress without excessive
    intervention/help from the ADs and other non-WG parties?

  - will the effort require serious cycles from the IESG (and others)
    when the WG declares it's finished and it goes to IETF LC? (And
    will that effort be worth the benefit?)

  - is the effort sending misleading (or incorrect) signals to the
    broader community about whether the IETF really is developing a
    useful solution in a particular area?

That is, all-in-all, does it make sense to continue the WG, or should
the IETF cut its losses and move on?

A good number of the above questions have little to do with whether
something is overcome by events.

Thomas

---

From: Eric Burger <[email-masked]>
Date: Tue, 10 Feb 2009 09:35:34 -0500

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Feb 2009 15:28:42 +1300

Eric,

On 2009-02-11 03:35, Eric Burger wrote:
...
> 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.

It seems to me that everything involved is well within the authority
of the IETF under BCP9 and BCP25. An IESG Statement, which is
relatively easy to update compared to a BCP, seems like exactly
the right vehicle.

   Brian