Re: [Manycouches] IETF Slack workspace

Brian E Carpenter <> Sun, 12 July 2020 20:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2AA1A3A07F3; Sun, 12 Jul 2020 13:48:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZiDB0Sy7X2CB; Sun, 12 Jul 2020 13:48:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A5E53A07F2; Sun, 12 Jul 2020 13:48:16 -0700 (PDT)
Received: by with SMTP id z5so5073836pgb.6; Sun, 12 Jul 2020 13:48:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yKbZZyCZbMaoBr77fbIBd48bwGgjq7myPpSDVZFPJ2E=; b=XUZoD0Zep5rnRxYShzHFZKXv1Z3X7K84q/Ts9JrvSW0Hh/bvN5uJx5ArYIkLJOFg2X hBz20YYIgid5zhCDsgengqYdKL7QPh8fjhDRB8WWqsly8G7XyAonMMRW10j6eNzbYHWB D+EKcLg/OETaXUytcXnmHIJs1oPfkgHhdnRYUtApJWQ09p5XE3XXX40Nn/LodujvE7hc hfQZUTMwWe+ygifVEyMhQYWQ1VU0Wp2DnblZnl6wbJMCrso9UZzY8EFGPBWcTtCpew8j cM/sVtMqlVIYShWhUE5l60xK3AsZLxTi8KlsfK++Cm+/s+XCfvdmYw09oj6YaTBw+stU PBNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yKbZZyCZbMaoBr77fbIBd48bwGgjq7myPpSDVZFPJ2E=; b=TczI/ItRkiQTc2zdwZzrHN/0w+558WZAI6bMpCQ8wiJI0EI0XU9ZcPTFJyqbQj0jIB ePXMjVo2ANXzeA7xDHH5hxzZxwok6okffTQ4u3cZLkNYf5x/ci4LAiKiuJ1YCybEVz2V Cycj5j+ExPTIgqDl2y5uuFPYC9b7tNFSnf9QJ6+r9L6dmXyx7JWCALjYzJ873gHDgv70 Sy0KSaufpbA4d/A90yFtCUCavGEv8m7ektxFDT2lqo5SmEX817GxHiNA5/5dEqGquNBD 9BUp0Xzj2+uzjMJiM00fcae/TNn5dm2ZtHPGYJTVj1iHByqo9X1hI4vVO0jc4iEoj5jV Eu2w==
X-Gm-Message-State: AOAM531pOBuyCWgi4xgzLWlE2j/eKXFrn0/nuMn8GifIUlR7jSuUf4iy tY2J256gRyGRCzWqKWtx+tdLgx/q
X-Google-Smtp-Source: ABdhPJy6VCTSgJawGKVg68UREESb85e3u8A8DDypb1HDc7LqgPJuh/rDUxppXWv23aPKGaVS80OiRw==
X-Received: by 2002:a63:5613:: with SMTP id k19mr1881139pgb.424.1594586895263; Sun, 12 Jul 2020 13:48:15 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id a30sm12553296pfr.87.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jul 2020 13:48:14 -0700 (PDT)
Subject: Re: [Manycouches] IETF Slack workspace
To: John C Klensin <>, Richard Barnes <>
Cc: Erik Kline <>, IETF discussion list <>,
References: <> <> <> <20200711060823.GX3100@localhost> <> < om> <324784EC430BD61F3658E359@PSB> <> <06D6019FC529B81847343C4B@PSB>
From: Brian E Carpenter <>
Message-ID: <>
Date: Mon, 13 Jul 2020 08:48:10 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <06D6019FC529B81847343C4B@PSB>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 12 Jul 2020 20:48:18 -0000

Yes, this looks good to me now.

   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
> <> 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:
>> --Richard
>> On Sat, Jul 11, 2020 at 10:38 PM John C Klensin
>> <> wrote:
>>> --On Saturday, July 11, 2020 18:03 -0400 Richard Barnes
>>> <> 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