Re: Sergeant-at-Armss and New proposal/New SOW comment period

[John C Klensin <[e-mail]>]

--On Saturday, 31 August, 2019 14:22 -0500 Adam Roach
<[e-mail]> 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