--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
