With the change that you have proposed below, I would support publication of
this document (and the running of this experiment).
While there are a number of small things we could tweak, I think that would
be a waste of time. This is good enough as a temporary measure to relieve
the current pressures, and I think that our efforts would be better spent on
working on a real BCP proposal along the lines you have described below.
From: Sam Hartman [mailto:hartmans-ietf(_at_)mit(_dot_)edu]
Sent: Tuesday, May 09, 2006 10:43 AM
To: Margaret Wasserman
Cc: 'IETF Discussion'
Subject: Re: [Gen-art] Re: Gen-art review
"Margaret" == Margaret Wasserman
Margaret> This document defines an RFC3933 experiment in which we
Margaret> would temporarily give the IESG the authority to create
Margaret> new mailing list management procedures and enact them.
Margaret> The only hard limitations on this authority are that
Margaret> posting suspensions cannot run beyond the timeframe of
Margaret> the experiment (18 months), nor can the procedures
Margaret> prevent anyone from reading an IETF mailing list. The
Margaret> document does not even limit the type of action that the
Margaret> IESG can take -- while it only talks about posting
Margaret> rights suspensions, this document would allow the IESG
Margaret> to define an enact other types of mailing list control
Margaret> at their discretion. It explicitly does not require
Margaret> that we use the same procedures on all IETF mailing
Margaret> lists, as it explicitly allows the IESG to define
Margaret> different procedures for different lists.
Note that this is the same authority the IESG had for WG
mailing lists under RFC 2418.
However I agree that this is not where we want to be long-term.
Margaret> This document does not define any principles that the
Margaret> IESG should follow in determining mailing list
Margaret> management procedures, nor does it require any type of
Margaret> community review or consensus to enact them.
I think these are the sorts of details--principles and review
requirements--that the community needs to decide on. I think
that will take a while to do, and it is my hope that this
experiment may provide input to that process. Long term
though I agree with you that the BCP for mailing list
management must provide principles.
Margaret> At first, I thought it was the purpose of this document
Margaret> to allow the IESG to try out different mailing list
Margaret> management procedures on different IETF mailing lists
Margaret> for a short period of time, with the goal of picking
Margaret> some successful procedures that would later be discussed
Margaret> by the community and potentially reflected in our BCPs.
Margaret> In other words, I thought that this was a temporary
Margaret> measure to address the weaknesses in our current
Margaret> procedures and get some experience with alternatives. I
Margaret> still thought that the goal would be to settle on
Margaret> well-defined, community-consensus-based procedures by
Margaret> then end of this 18 months.
That is the goal of this experiment.
I propose adding text to clarify this fact.
I propose adding to the end of the last paragraph in the introduction:
This experiment is successful if it gives the community useful input
on how to design mailing list management process. It is
that this experiment will be adopted in its current form as a
Margaret> At that time, I supported
Margaret> this document, because I saw it as a better alternative
Margaret> than living with our broken procedures until the
Margaret> community could fix them. I thought that the IESG could
Margaret> end this experiment if/when we had community consensus
Margaret> on a new set of procedures.
I still believe that to be true.
I'm sorry if my comments at the general area meeting were confusing.
I believe that as a general rule you want the operative part
of an experiment to look like a BCP. I've been pushing
fairly hard for this even in this case because this is one of
the first experiments we are running. I do not believe that
this current experiment would make a great BCP.
Ietf mailing list
Ietf mailing list