Richard, Keep an eye on BCP 78 and well as BCP 79, but while the devil is always in the details, your note (and the PR on github) seem to me to be consistent with exactly the sort of thinking for which I was arguing. Wrt the PR, you should think about the Note Well statement and whether it is useful (I have not thought about it enough to have an opinion: the overlap with your bullet points seems obvious but that does not mean it would be the right thing to do). thanks, john --On Sunday, July 12, 2020 10:46 -0400 Richard Barnes <rlb@xxxxxx> wrote: > 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: > > https://github.com/bifurcation/ietf-slack-coc/pull/1 > > --Richard > > On Sat, Jul 11, 2020 at 10:38 PM John C Klensin > <john-ietf@xxxxxxx> 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 >> >>
