Subject: [Manycouches] IETF Slack workspace

From: Theresa Enghardt <[email-masked]>
Date: Fri, 10 Jul 2020 21:24:02 -0700

As an experiment, there is now a Slack workspace at https://ietf.slack.com, which provides a persistent chat platform with ad-hoc channel creation.

This platform can be used for sidebar conversations during IETF 108.

To get access to the Slack workspace, please send an email requesting an invite to Christopher Wood <[email-masked]>, Richard Barnes <[email-masked]>, or Theresa Enghardt <[email-masked]>.

---

From: Erik Kline <[email-masked]>
Date: Fri, 10 Jul 2020 22:20:50 -0700

How will conversations on Jabber be synchronized with those on Slack?

On Fri, Jul 10, 2020 at 9:24 PM Theresa Enghardt <[email-masked]> wrote:
> _______________________________________________
> Manycouches mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manycouches

---

From: Theresa Enghardt <[email-masked]>
Date: Fri, 10 Jul 2020 22:25:48 -0700

> How will conversations on Jabber be synchronized with those on Slack?

So far we are not planning to bridge or synchronize both
technologies/platforms by any technical means.

---

From: Nico Williams <[email-masked]>
Date: Sat, 11 Jul 2020 01:08:24 -0500

> technologies/platforms by any technical means.

Hmmm.  Might I suggest then that the experiment be limited to one or two
WG meetings?  Otherwise this split may prove quite disruptive.

Nico
--

---

From: Ross Finlayson <[email-masked]>
Date: Sat, 11 Jul 2020 18:20:19 +1200

> On Jul 11, 2020, at 4:24 PM, Theresa Enghardt <[email-masked]> wrote:
> 

What is the RFC that describes this protocol? :-)

---

From: Brian Carpenter <[email-masked]>
Date: Sat, 11 Jul 2020 22:35:29 +1200

So this presumably amounts to IETF Contributions under the IPR rules. How
will it be added to the meeting records, like a jabber log, for the benefit
of other participants?

Regards
    Brian
    (via tiny screen & keyboard)

---

From: Theresa Enghardt <[email-masked]>
Date: Sat, 11 Jul 2020 11:19:56 -0700

> WG meetings?  Otherwise this split may prove quite disruptive.

Slack is neither intended as a replacement for Jabber, nor is its usage
tied to any particular WG meeting.

We rather envision it to be used for more ad-hoc, side conversations,
for which no Jabber channel exists.

---

From: Ned Freed <[email-masked]>
Date: Sat, 11 Jul 2020 11:47:47 -0700 (PDT)

> for which no Jabber channel exists.

I am required to use Slack at work. There's probably an amount of pressure
sufficient to compell me to immerse myself in the IET's version of "let
everyone else define your folder structure for you", but rest assured it would
be very high indeed.

FWIW.

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Jul 2020 08:44:40 +1200

It seems to be IPv4-only. That seems like a bad start for an IETF tool.

Regards
   Brian Carpenter

---

From: Ali Mezgani <[email-masked]>
Date: Sat, 11 Jul 2020 22:31:16 +0100

Hello,

Interesting. How to register into the workspace?

Regards,

On Sat, Jul 11, 2020 at 21:45 Brian E Carpenter <[email-masked]>
wrote:

> > As an experiment, there is now a Slack workspace at
> https://ietf.slack.com, which provides a persistent chat platform with
> ad-hoc channel creation.
> >
> > To get access to the Slack workspace, please send an email requesting an
> invite to Christopher Wood <[email-masked]>, Richard Barnes
> <[email-masked]>, or Theresa Enghardt <[email-masked]>.
> >

---

From: Theresa Enghardt <[email-masked]>
Date: Sat, 11 Jul 2020 14:33:26 -0700

> Interesting. How to register into the workspace?

To get an invite, please send an email requesting an invite to
Christopher Wood <[email-masked] <mailto:[email-masked]>>,
Richard Barnes <[email-masked]>, or Theresa Enghardt <[email-masked]
<mailto:[email-masked]>>.

---

From: Ali Mezgani <[email-masked]>
Date: Sat, 11 Jul 2020 22:42:20 +0100

Thank you for your quick response.

Regards,

On Sat, Jul 11, 2020 at 22:33 Theresa Enghardt <[email-masked]> wrote:

> To get an invite, please send an email requesting an invite to Christopher
> Wood <[email-masked]>, Richard Barnes <[email-masked]> <[email-masked]>, or
> Theresa Enghardt <[email-masked]>.
>

---

From: Theresa Enghardt <[email-masked]>
Date: Sat, 11 Jul 2020 14:51:58 -0700

On 11.07.20 03:35, Brian Carpenter wrote:
> So this presumably amounts to IETF Contributions under the IPR rules.
> How will it be added to the meeting records, like a jabber log, for
> the benefit of other participants?

We will treat Slack discussions like hallway conversations.

Therefore, we do not plan to archive them.

---

From: Richard Barnes <[email-masked]>
Date: Sat, 11 Jul 2020 18:03:56 -0400

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

---

From: Richard Barnes <[email-masked]>
Date: Sat, 11 Jul 2020 18:05:10 -0400

Hey all,

I just discovered an EVEN EASIER way to sign up than emailing me, Chris,
and Theresa.  All you have to do is click this link, enter some details,
and you're in:

https://join.slack.com/t/ietf/shared_invite/zt-frvduilu-k9UfPr3sAelv_XPptqJ4wQ

See you there,
--Richard

On Sat, Jul 11, 2020 at 12:25 AM Theresa Enghardt <[email-masked]>
wrote:

> As an experiment, there is now a Slack workspace at https://ietf.slack.com,
> which provides a persistent chat platform with ad-hoc channel creation.
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Jul 2020 22:38:09 -0400

--On Saturday, July 11, 2020 18:03 -0400 Richard Barnes
<[email-masked]> 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

---

From: Richard Barnes <[email-masked]>
Date: Sun, 12 Jul 2020 10:46:18 -0400

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

---

From: John C Klensin <[email-masked]>
Date: Sun, 12 Jul 2020 11:27:54 -0400

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
<[email-masked]> 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:
> 
>> > 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 
>> 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.
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Jul 2020 08:48:10 +1200

Yes, this looks good to me now.

Thanks
   Brian Carpenter

---

From: Richard Barnes <[email-masked]>
Date: Fri, 24 Jul 2020 11:54:26 -0400

Last-minute reminder before the IETF: If you're interested in HotRFC or
trying out a different, Slack-based experience for hallway conversations
alongside the virtual IETF, you can use this link to make an account: