Yes, this looks good to me now. Thanks Brian Carpenter On 13-Jul-20 03:27, John C Klensin wrote: > 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 >>> >>> > > >
