I know that these comments are late for IETF LC, but Brian Carpenter indicated that I should share them here, anyway... I generally support publication of this draft as an Experimental RFC, and I hope that the IESG will use this mechanism to support more moderate and more effective mailing list control over the next 18 months. I consider this a good stop-gap measure to provide the IESG with more flexibility while we take longer-term steps to determine what type(s) of mailing list control are acceptable and reasonable for use within the IETF, and until we can update our BCPs to reflect those decisions. This experiment will also give us an opportunity to try some different mechanisms for mailing list management and to gain valuable experience regarding what works and what doesn't. During the Gen Area meeting today, it was asserted that if this experiment is successful, this document might become a BCP essentially as written. I did not realize that was being considered until we got to the Gen Area meeting, and while I consider it reasonable to offer some relief for an 18-month period while we determine what else we should do, I have some major concerns about the idea that we would be running this experiment with a goal of making this particular draft a BCP. First, I am not sure how/if the community will have enough visibility into the results of this experiment to reasonably determine whether it has been successful. Will the IESG be expected to provide any reports on which types of experimental mailing list control do/don't work? Do we have any measures, even subjective ones, that could be used to determine whether things get better or worse during the period of this experiment? Also, I don't think that it is a good idea to effectively give the IESG absolute, unilateral control of our mailing list management, including the discretion to use different rules for different lists and change those rules over time. To put this in the terms that Brian defined in the Gen Area meeting (see his slides in the proceedings if you weren't there), this document gives the IESG broad discretion over both the process and procedures that will be used for IETF mailing list control, and it does not assert any principles that should be used to guide those processes and procedures. Every situation is different. So, IMO, it is important to provide the IESG with substantial discretion to determine the right types of mailing list control for each situation. I believe that our current BCPs are much too restrictive in this regard. However, we also need to remember that these cases are highly emotionally charged, and often involve well-established IETF participants on one side, such as WG chairs and ADs, and less well-established participants on the other. There are a lot of things that we hope that our WG chairs and mailing list administrators will try before considering a suspension of posting priveleges, such as meeting with the individual(s) involved and trying to work through the issues that are causing disruption. ADs also tend to get involved in those discussions, and by the time an individual situation comes to the attention of the IESG, the WG chairs and ADs involved may be tired of the issue, frustrated or angry with the offending participant and/or impatient for action to be taken. The involved ADs may also feel that a negative decision on the proposed action may be seen as insulting or insensitive to the WG chairs being affected by a participant's behaviour. It is not expected that the involved ADs will recuse themselves from discussion or voting on these issues, and it is quite possible (I don't think it has happened, but it could happen) for these factors to lead to a lynch mob mentality. Because of the emotional nature of these situations, I think that we need some well-understood principles and processes to guide the actions of the IESG in these situations, and to provide some framework for appeals by the targets of these actions in the event that those principles and processes are violated. So, I think that the community needs to determine the right balance between defined processes and IESG discretion, and I personally think that this document errs too far on the side of complete IESG discretion than would be appropriate for a long term solution. Margaret _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf