Re: [Manycouches] IETF Slack workspace

Richard Barnes <rlb@ipv.sx> Sun, 12 July 2020 14:46 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870E63A0A6A for <ietf@ietfa.amsl.com>; Sun, 12 Jul 2020 07:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMLFFpIADOyD for <ietf@ietfa.amsl.com>; Sun, 12 Jul 2020 07:46:40 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3796A3A0A68 for <ietf@ietf.org>; Sun, 12 Jul 2020 07:46:39 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id a32so8136445qtb.5 for <ietf@ietf.org>; Sun, 12 Jul 2020 07:46:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aIypcHSPz/Xleaj9JR/F5w/igq5mRkJDlqEApctddG8=; b=sVkkTmjTRdve4J6uGGA+K5N+JRujgAMkyaBpph2i02JmjaQQ7jZA/yscblKMJ2W3uq vqcMuRdhhbYofB3iL17rdS+I8zSV2wveimM2MWOVDc32LKZzQgX7fNBtsPQz2Y9LChei eiy/PNf2hFwcYjQ2BpDwXpBtXh7VWlFDD8QijY7ZU4VZjeYG2/G83dx2FTIjH0PuIkr4 rTXjuKzymjdKGGb19OW7tPMRa3EYzpWa8SeZfownI3IwkvF5885xio4KNIOskN3XJxm0 hPadlhC8I+BYjhvQDHDZ9dHVDVkA0JZ1qPYs8D+o35BJB+Uti1xSaYO1Y+Mtll0PXcWI VGkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aIypcHSPz/Xleaj9JR/F5w/igq5mRkJDlqEApctddG8=; b=hbhQfMAL/SJkuoMFWLnzIgQJQMsm/WQiAvRi9iTD4dRs7xuaxiLdZUl1AZvNdTz1f0 C1w3wh0Q7dOLxpp3UgzsYK4iClpLutMXUB3BKzBfGYnAimMMP95hMgVoU2pnWtl3DHdQ ycZoUdHfnLeEpR7yoWIjdROnJPcA1hdE9ygKbGBk9AaiskpC6jq3a15ZrCVN5//5lQd2 apB6lTjVEfwLSLUcs3E8k50MFcGjzOz2MaWXBWrC+ViI+R59jq0qGZ16CT0KzVeq+sDW uQrwvxzTDsW9g3ZmSiYKYI4qV52zTugHFAju9CscV1WYipLAFucwiEvNB3c3VvZULk1i iYIg==
X-Gm-Message-State: AOAM531rDqt2Pmf/KXGKFHDCDs60r0b/3Y+aa9pOttaExQiXjDd/v82D gEtNsxqcpGTGWfjYh4vKgCEEl4prbLgRIY2qdF6Qhg==
X-Google-Smtp-Source: ABdhPJxqklVMtsroEba0LpV9cn10FGYQ3qBodSqPnc/zvmTxdEqXPTSUboQtZ/C7W3k0hjdURyUrps/e2E46ApapraQ=
X-Received: by 2002:ac8:2a3d:: with SMTP id k58mr64451381qtk.265.1594565198814; Sun, 12 Jul 2020 07:46:38 -0700 (PDT)
MIME-Version: 1.0
References: <3064c634-3958-f5e3-26c2-cdd148a86605@tenghardt.net> <CAMGpriUJm-Wx48bAO4LNgFzvrBO0ksQ60_Qs6iz8YL7RfzGrLw@mail.gmail.com> <aa7ee087-7314-26db-6184-2443def3cb4b@tenghardt.net> <20200711060823.GX3100@localhost> <CANMZLAY8wtq1cVtHPPAwyCvygiO2rEc9yPNotD+bdvHtZa1tTQ@mail.gmail.com> <CAL02cgStMc7tVGL7iaP0m0gSe+TCj1dmRH5g2v-9w3vJTdXOaw@mail.gmail.com> <324784EC430BD61F3658E359@PSB>
In-Reply-To: <324784EC430BD61F3658E359@PSB>
From: Richard Barnes <rlb@ipv.sx>
Date: Sun, 12 Jul 2020 10:46:18 -0400
Message-ID: <CAL02cgRV6WK_ffNtqqG6KocYc5J0CX9WxUhkPC3-QvfoGgG1aA@mail.gmail.com>
Subject: Re: [Manycouches] IETF Slack workspace
To: John C Klensin <john-ietf@jck.com>
Cc: Brian Carpenter <brian.e.carpenter@gmail.com>, Erik Kline <ek.ietf@gmail.com>, IETF discussion list <ietf@ietf.org>, manycouches@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003f40ff05aa3fa448"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wP6q2sDlVQwlxhEOPRXMBRL7oPQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jul 2020 14:46:43 -0000

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@jck.com> wrote:

>
>
> --On Saturday, July 11, 2020 18:03 -0400 Richard Barnes
> <rlb@ipv.sx> 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
>
>