--On Saturday, 31 August, 2019 14:22 -0500 Adam Roach <adam@xxxxxxxxxxx> wrote: > On 8/31/19 7:54 AM, John C Klensin wrote: >> More important RFC 3005 clearly calls out "Discussion of IETF >> administrative policies" as an appropriate posting topic and >> this discussion is very much about administrative policies. > By that logic, IANAPLAN, MTGVENUE, and IASA2 discussion should > have taken place here, and redirecting them to their > respective working group mailing lists would have been > misguided. Would you have raised the same objection? Actually, I did raise an objection about IASA2, before the WG was created and active (i.e., while whatever community discussions about the IETF LLC that occurred were going on) and was generally ignored. However, there are important differences between the IASA2 WG that followed and maybe the other two: the results of the IASA2 WG were documents, most of which led to IETF LC and, hence, a round of discussions on the IETF list. That, for me, creates a different situation than the present one in which: * There are clearly IETF administrative policies involved. That isn't an interpretation of 3005 that requires some sort of logic. I quoted exact text from the document. * There has already been significant evidence of broad community interest in and concern about this particular matter. If it were a topic for which there was evidence that most of the community felt could be left to experts and/or some relatively small number of people who really cared about it and they were almost all on an identified special mailing list, I'd feel that pushing things to that mailing list would be reasonable even though it would be inconsistent with the very clear language of the BCP. * There is actually no appropriate other mailing list. rfc-interest isn't it for reasons already given. If none of the other issues that have been raised (in this note or elsewhere) and 3005 didn't have specific language about IETF administrative procedures, a description of the action as "trigger happy" would (still) apply. I can find nothing in 3005 or elsewhere that charges the SAAs with keeping as much traffic off the IETF list as possible even if doing so violates explicit provisions of 3005 and/or trying to send traffic to other mailing lists. Of course, if one took "there is already another mailing list and the topic should be discussed there" to its limits, the IESG's encouraging discussions of WG documents on the IETF List during IETF Last Call would be improper. I hope no one would seriously suggest that we go there but, the exception for Last Call discussions in 3005 is part of the same bullet list as "administrative policies". * The IAB has made it clear on many occasions that it is not controlled by community consensus. Even when it asks for input and considers it, it is not obligated to follow the suggestions in that input but, instead, is going to follow its own best judgment. There are a large number of situations in which that is exactly the right behavior and I think the community would be making a mistake if it changed the requirements for IAB decision-making. However, the actions and response that led us into this situation left several members of the community with a sense that, in this particular area, the IAB (directly or via authority delegated to the RSOC) was making decisions under cover of darkness (or at least executive session) and that they were either not in touch with with the community or believed that their preferences, procedurally and administratively, were more important than the community ones. The main solution for a problem list that, at least short of Kobe-style major changes, is sunshine and we have two main sunshine mechanisms: plenaries and the IETF list. Telling people to take a discussion at that sort of level elsewhere, whether to an inappropriate mailing list list rfc-interest or to a newly-created one, has the odor of trying to suppress the discussion by isolating it from the community and requiring those who feel that it is important to follow to subscribe to and follow an list part of whose effect will inevitably be isolating. And, fwiw, in the light of what we have learned from the discussions leading up to RFC 7776 and the ombudsteam, it appears to me that 3005 is in significant need of revision to reflect the different roles or public and private comments, to clarify that the SAA role should not be seen as keeping as much traffic as possible off the IETF list, probably to clarify what traffic is appropriate without turning that into absolute rules, to at least consider whether disruptive behavior on the IETF list is different from disruptive behavior elsewhere in the IETF and, if it is not, where the SAA mechanism is the best way to deal with it, and, just as we have done with the ombudsteam, to take precautions about weaponizing the SAA function. But I hope we can get though the present discussion without going there. best, john
