*sigh*
Adam - Hyperbole at this point is not helpful. Specifically "no
supervision" does not come even close to what we've been asking.... no -
make that telling ... the SAA to do. Let's not distract the
conversation off the topic.
The SAA MUST NOT be used as a tool, or even be perceived as being used
as a tool to stymie dissent, or to stop or steer discussions that might
be uncomfortable to the SAA or I*. The fact that there is an RFC-I
mailing list does not in itself mean that all RFC related discussions
must take place on that list.
Matthew was wrong to attempt to get the discussion moved over and needs
to use a much finer filter in the future, as do all of the SAA, on any
discussion that might be a community pushback or even discussion on I*
leadership proposals.
For now - let's keep it here. If we get to a point where we're cycling
on a few topics, and those topics are more appropriate for the other
list (e.g. maybe more details on things that have a broad community
buy-in), then yeah, feel free to suggest it.
By the way - while I'm on the topic:
The SAA should not participate in a conversation that it expects to have
oversight on. Listening is fine, advocacy for one side or another is
pretty much disqualifying in acting as the SAA for that topic as SAA
decisions could be seen to be tainted by bias.
Later, Mike
'On 8/31/2019 3:55 PM, Adam Roach wrote:
This is a fair point. Is it your position that there is no supervision function intended to keep the discussion within the mailing list’s charter, aside from that required to tamp down abusive behavior?
/a
On Aug 31, 2019, at 14:36, Bob Hinden <bob.hinden@xxxxxxxxx> wrote:
Adam,
On Aug 31, 2019, at 12:02 PM, Adam Roach <adam@xxxxxxxxxxx> wrote:
On 8/31/19 1:15 PM, Keith Moore wrote:
It's not easy to think of a topic more important to the future of IETF than the manner in which its output is published. To suggest that this topic should not be discussed in IETF, but should instead be discussed in a venue outside of IETF, defies all logic.
I think this overstates things a bit.
One of the key objections that was repeatedly raised regarding the RFCPLUSPLUS BOF was that it took place within the context of IETF process, and since it had implications on streams other than the IESG stream, ran the risk of overstepping its bounds [1]. I believe it's pretty clear, even ignoring RFC 3005's "well-established list" clause, that whatever sincere concerns existed about proposing changes to the RFC Editor function solely within the IETF process back then must necessarily translate to holding a more existential discussion about the future of that function on an IETF mailing list list.
To be clear, I suggested to the SAA that the conversation had this very risk of overstepping the bounds of the IETF's purview, as was clearly communicated by the community during that BOF. Any criticism of this logic should be directed at me rather than him.
Rereading RFC3005, it says:
The IETF Chair, the IETF Executive Director, or a sergeant-at-arms
appointed by the Chair is empowered to restrict posting by a person,
or of a thread, when the content is inappropriate and represents a
pattern of abuse.
The intended role of the sergeant-at-arms is for content that is is inappropriate and represents a
pattern of abuse. There was no “inappropriate” nor “pattern of abuse” here whatsoever.
Bob
/a
____
[1] There were many such comments, both on-list and at the microphone. This one is representative: https://mailarchive.ietf.org/arch/msg/rfcplusplus/jQHmeaGqN231LNIPfCQwpeUIxds
