Hi John,
I think if we tease apart two things, there might be some compromise territory here: Disclosure obligations and publication/archiving/recording.
Disclosure obligations are the primary focus of BCP79 as it applies to participants. I could probably live with that part of those documents applying to Slack, in the sense that "if you discuss patented stuff related to IETF standards, you have to disclose it". Note, though, that that will only apply to some messages in the Slack -- not to, say, discussion of what coffee you're drinking during this ealy session. And there will be no policing.
What we should avoid is the implication that because those disclosure obligations attach, we need to record and archive everything. As you point out, IETF participants have non-conversations in non-recorded, non-archived, non-transparent channels all the time (e.g., in person). Just because something is in a technical modality that might facilitate recording and archiving doesn't mean it's necessary or useful. In this case, I would argue that it would be harmful, for the same reasons that recording in-person conversations would be.
Here's a PR to reflect this in the IETF Slack Code of Conduct that Chris, Theresa, and I have worked up:
--Richard
On Sat, Jul 11, 2020 at 10:38 PM John C Klensin <john-ietf@xxxxxxxx> wrote:
--On Saturday, July 11, 2020 18:03 -0400 Richard Barnes
<rlb@xxxxxx> wrote:
> As Theresa said, this mechanism is explicitly for discussions
> that are not IETF Contributions. They are equivalent to
> hallway conversations at an IETF meeting and will be treated
> as such -- they will not be archived or included in meeting
> records. Since we are using a free instance, Slack will
> remove messages once we hit a 10,000 message limit.
Richard,
Perhaps like Brian, I can't see how that works. If you are in a
hurry, skip to the last two paragraph and then decide whether
the rest is worth reading.
You and your colleagues have named this as an IETF workspace.
You have promoted and discussed it using IETF facilities
including the main IETF discussion mailing list. By any
reasonable definition that puts it "within the context of an
IETF activity" (RFC 8179 Section 1.c). One can argue that does
not make all such conversations "intended to affect the IETF
Standards Process" (ibic.) but it seems to me that policing
conversations to be sure that none of them are intended to have
that effect that would be quite hard and that you (quite
reasonably) don't want to appoint a police-person. To make
splitting that particular hair a little more complicated, from
reading the bulleted list in the rest of that section, there
better not be an IESH or IAB members in any of the Slack
discussions, any discussions that include members or that might
influence a design team, etc. Coming to the next paragraph,
from what you and Theresa have said, you can clearly argue that
your general intent for the Slack setup is to "clearly not [be]
intended to be input to an IETF activity, group, or function"
and hence not a Contribution, but, again, you cannot enforce
that.
I note that, if I take a document author aside after a f2f WG
meeting (in the hallway) and attempt to change her mind about a
position taken during that WG meeting --a conversation clearly
intended to influence the standards process-- that is an "oral
statement" Contribution within the language of BCP 79/ RFC 8179.
However, skipping over all of that because I think that any of
us could split enough hairs to make some or all discussions on
your "IETF Slack workspace" Contributions (or not), I actually
don't think that would be helpful. Instead, I think that these
difficult and somewhat novel times should encourage us to be
even more careful about openness and transparency than in more
normal times that are better understood and which our procedural
documents generally assume. Remember that BCP70 came about, not
because Scott and others thought that tying us in knots or
having boilerplate text in RFCs and read out at the beginning of
every meeting would be fun, but because of genuine (and legal
expert-backed) concerns about keeping the IETF and its standards
out of the middle of IPR litigation and other battles. I
suggest that it would be helpful to think about these novel
cases and borderline tools in terms of a procedural variation on
the robustness principle: if there are two possible ways to
interpret a given rule, go for the one that promotes the most
transparency.
I think that means treating the Slack workspace in general as if
BCP 78 and 79 apply. If there are particular conversations to
which those rules do not apply, you should be sure they are
appropriately firewalled (and I have no idea how to do that)
And you should have a conversation with the IETF Trust and its
legal counsel about whether it is necessary to archive
conversations that might otherwise disappear and how to do that.
Just my hardnosed, somewhat paranoid, opinion of course,
john
