Subject: Re: Last Call: 'Experimental Procedure for Long Term Suspensions from Mailing Lists' to Experimental RFC

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 15 Feb 2006 12:25:55 -0600

Dear IESG,

I'm glad that you are considering this experiment. We certainly heard from 
people who expressed discomfort with the current BCP procedures in this area 
during recent discussions, and I don't know that very many people were 
thrilled with those procedures (especially after we started noticing gaps in 
the BCP coverage).

I do have one procedural comment here.

I agree that IESG can conduct experiments of more than 18 months duration 
under BCP 93, but the specific procedural problem here isn't about an 
experiment that needs to run for 18 months, it's about an experiment that 
may not start for several months (because the IESG needs to receive a 
suspension request in order to start the experiment).

Could I suggest that the IESG (perhaps "also") say "the clock on this 
experiment doesn't start until we actually receive a suspension request"?

The goal of the "sunset" language was to prevent an experiment from running 
forever, not to run a clock while nothing is being experimented with.

Thanks,

Spencer, who would be thrilled if this experiment never started because no 
one needed to be suspended ...

> The IESG has received a request from an individual submitter to consider 
> the
> following document:
>
> - 'Experimental Procedure for Long Term Suspensions from Mailing Lists '
>   <draft-hartman-mailinglist-experiment-01.txt> as an Experimental RFC
>
> NOTE: This is a Last Call under RFC 3933 (BCP 93). If the IESG approves
> this document, it will become an experimental IETF process document for
> a period of 18 months.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-03-15.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-hartman-mailinglist-experiment-01.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 15 Feb 2006 22:24:04 +0100

I believe sending out a Last Call on this document is:

1) Premature. This version of the document has been with us for all of 10 
days, and the previous version since January 24.

2) Inappropriate. The IESG is in the midst of considering a very divisive 
issue that has to be decided using the current set of rules.

3) Badly timed. This Last Call ends four days before the next IETF meeting 
begins.

I urge the IESG to cancel the current Last Call, make the proposal a topic 
of the General Area open meeting in Dallas, and issue the Last Call after 
the Dallas meeting.

                        Harald Alvestrand

--On onsdag, februar 15, 2006 12:40:18 -0500 The IESG 
<[email-masked]> wrote:

> the  following document:

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Feb 2006 23:07:02 +0100

Harald Tveit Alvestrand wrote:

> make the proposal a topic of the General Area open meeting
> in Dallas, and issue the Last Call after the Dallas meeting.

It's only an experiment relevant for listmoms and WG Chairs.

Nothing like that other case with about 1,000,000 domains and
a community determined that "extend and embrace" spiced with
"opt-out" isn't what they consider as experimental, especially
if it's known to be technically flawed.

Are mailing list management experiments interesting enough for
a meeting ?  The discussion about "something between 3934 and
3683" didn't start 2006-01-24, it's at least some weeks older.

                          Bye, Frank

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Feb 2006 18:57:58 -0500

>>>>> "Spencer" == Spencer Dawkins <[email-masked]> writes:

    Spencer> I agree that IESG can conduct experiments of more than 18
    Spencer> months duration under BCP 93, but the specific procedural
    Spencer> problem here isn't about an experiment that needs to run
    Spencer> for 18 months, it's about an experiment that may not
    Spencer> start for several months (because the IESG needs to
    Spencer> receive a suspension request in order to start the
    Spencer> experiment).

    Spencer> Could I suggest that the IESG (perhaps "also") say "the
    Spencer> clock on this experiment doesn't start until we actually
    Spencer> receive a suspension request"?

    Spencer> The goal of the "sunset" language was to prevent an
    Spencer> experiment from running forever, not to run a clock while
    Spencer> nothing is being experimented with.

As much of this experiment is in defining procedures as it is in
running those procedures.  So, to be useful, the IESG would have to
actually approve a procedure for mailing list management under this
experiment.

That can happen immediately and debugging that process is half the
battle^h^h^hfun.

I would not object to the proposed change you make.  I just want to
point out it is more complicated.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Feb 2006 14:33:35 +0100

Harald Tveit Alvestrand wrote:
> 1) Premature. This version of the document has been with us for all of 
> 10 days, and the previous version since January 24.

I think the spirit of RFC 3933 is to get things tried out quickly,
so I don't buy this. The community has been discussing related topics
in the recent past. Of course, if many comments come in during LC,
Sam would need to rethink.

> 2) Inappropriate. The IESG is in the midst of considering a very 
> divisive issue that has to be decided using the current set of rules.

It will be decided according to current rules. We can surely separate
that from designing future rules.

> 
> 3) Badly timed. This Last Call ends four days before the next IETF 
> meeting begins.

Why is that a problem?

> 
> I urge the IESG to cancel the current Last Call, make the proposal a 
> topic of the General Area open meeting in Dallas, and issue the Last 
> Call after the Dallas meeting.

I have indeed reserved a slot in the open meeting, in case there are
open issues after the Last Call. And we always have the option of a
second Last Call, if the first one produces enough substantive comments
to need it.

     Brian

---

From: Ned Freed <[email-masked]>
Date: Thu, 16 Feb 2006 11:49:39 -0800 (PST)

>                         Harald Alvestrand

For the record, I am in complete agreement with Harald on all his points and
fully support his call to cancel the last call of this document.

				Ned

P.S. There seems to be some confusion about point #3 "bad timing". The issue
is simply that a lot of people's attention is elsewhere this close to
a meeting.