Subject: Re: [Tools-discuss] Zulip implementation Service Plan

From: Jay Daley <[email-masked]>
Date: Fri, 18 Feb 2022 12:34:05 +1300

Apologies for the long delaying replying - most of your suggestions were incorporated at the time, just not replied to.  Some comments:

First, thanks for taking the time to properly review this,

> On 2/09/2021, at 1:43 PM, Tim April <[email-masked]> wrote:
> 
> Hi Jay,
> 
> In re-reading the document I have a few comments for further discussion:
> 
> 1.2: Do we expect all users to understand what OIDC is? Could “Datatracker OIDC” be replaced with “Datatracker Single Sign-On”?
> 
We normally just say "using your Datatracker credentials" or "login" or something similar so this now says that.
> 1.3: I would also suggest adding this to the end of the section. “#NOTEWELL will be a default stream for all users.” This can be configured through the organizational settings for the instance.
> 
Done
> 2.1: For the first bullet under the mailing list mirror note, I would replace
> 
> “In this configuration they can choose not to subscribe to the list mirror.”
> With
> 
> “In this configuration they can choose not to subscribe to the list mirror in zulip or to mute the stream them to view or search the mirrored messages without receiving notifications for them.”
Done.
> 3.1: It may also be worth noting that attachments will also be retained for some period of time.
> 
Done
> 3.1: It may be worth calling out the message edit time restriction, if enabled. In the tulip services that I host / operate, we have the edit timer set to 10 minutes just to limit the length of time that of the change to somewhere near the time the conversation happened.
> 
Done
> 3.1: As an operator, from time to time I get requests to delete messages, either because someone sends something sensitive to the service or they misspeak and may feel it is something which could have negative impact on others. It may be up to Jay, Lars and Counsel as to what policy / process could be used to delete a message, but I would suggest thinking a little about that before the switch announcement.
> 
We don’t get that with Jabber so it seems best to leave this for now and only address it if we get an issue.
> 3.2: This section is very vague about under what circumstances DMs may be inspected. My instinct is to avoid anything which I do not expect to be public on the IETF zulip system with the wording of this section, but I feel like that remove some of the usefulness of the system. In the corporate space, there is usually a well defined policy which governs the ability for operators to access messages under three conditions:
> 
> 1) Verified lawful request from an agency with jurisdiction (usually verified by counsel)
> 2) Explicit policy which defines the conditions under which access may be granted to a set of messages (Eg: HR dispute, discovery, harassment claims, etc).
> 3) Extraordinary conditions under which a quorum of some set of participants documents a need to access messages.
> Some of these policies also include criteria under which the parties to these messages will be informed that the message was retrieved.
> 
I don’t think we can predetermine what the policy is because ultimately the community is free to set whatever policy there is consensus for.
> 4 - Other Integrations: Are additional integrations allowed to be deployed by IETF participants? Are there criteria to do so? Who needs to be contact/involved/informed to do something like that?
> 
Again I think it’s too soon to try and work that out in advance.  I would expect anyone who wants a new integration to raise that here or directly with Robert as per our other tools.

cheers
Jay

> Thanks!
> 
> --tim
> 
> On 1 Sep 2021, at 19:57, Jay Daley wrote:
> 
> Hi
> 
> I’ve put together a Service Plan for our upcoming Zulip implementation based on work by Tim April and had that reviewed and revised by a number of people who were involved in the trial. Robert is now happy for this to be shared for comment and any further revisions. Please find the document at
> 
> https://github.com/ietf-tools/zulip-implementation/blob/main/Service-Plan.md <https://github.com/ietf-tools/zulip-implementation/blob/main/Service-Plan.md>
> 
> The aim to is sign this off at the next Tools meeting in two weeks time.
> 
> cheers
> Jay
> 
> -- 
> Jay Daley
> IETF Executive Director
> [email-masked]
> 
> ___________________________________________________________
> Tools-discuss mailing list - [email-masked]
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: [email-masked]
> * Report tools.ietf.org bugs to: [email-masked]
> * Report all other bugs or issues to: [email-masked]
> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss <https://www.ietf.org/mailman/listinfo/tools-discuss>

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Feb 2022 12:21:39 -0500

Seeing this message reminded me to try Zulip.  I didn't find zulip info anywhere.

I read the linked service-plan, and I wondered, if Zulip will authenticate
via DT, can't it assume that the DT has shown the notewell to the
participant?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Robert Sparks <[email-masked]>
Date: Fri, 18 Feb 2022 14:48:42 -0600

Jay is currently working on the Zulip setup, and I think the note-well 
setup is in transition at the moment. Come back to this in a few days 
please.

RjS

On 2/18/22 11:21 AM, Michael Richardson wrote:
> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: Jay Daley <[email-masked]>
Date: Mon, 21 Feb 2022 12:18:37 +1300

> On 19/02/2022, at 9:48 AM, Robert Sparks <[email-masked]> wrote:
> 
> Jay is currently working on the Zulip setup, and I think the note-well setup is in transition at the moment. Come back to this in a few days please.

The Zulip service now has a default stream #NOTEWELL with two topics and one message per topic:

- A reminder of IETF policies.  This is the Note Well text
- Terms of Service.  Link to https://github.com/ietf-tools/zulip-implementation/blob/main/Service-Plan.md, where to propose changes and who to contact for stream requests.

The next step is for the Secretariat to set up their internal processes for responding to stream requests and then we should be good to go.

— 

One other thing.  There are few Zulip settings that we haven’t discussed and feedback is welcome:

1.  Permission to change name and email.  Both of these are turned off as the expectation is that Datatracker will be the source for both of those.

2.  Show preview of uploaded and linked images.  Currently on.

3.  Show preview of linked websites.  Currently off.

4.  Who can access user email addresses. Currently everyone.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Feb 2022 15:02:09 +0000

That makes sense.

No real preference, but it reminds me to make sure animated gifs are disabled or the built-in ones are removed.  (Curse you party parrot :).  Perhaps Tim April (on cc) knows what we did at akamai.  Although not that I think of it, not thrilled with linked images (security people are paranoid about being tracked), but can live with it.

Yes, good idea.

Since IETF zulip is only available to IETF datatracker users, this is reasonable.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Feb 2022 13:17:37 -0500

Salz, Rich <rsalz=[email-masked]> wrote:
    >>     1.  Permission to change name and email.  Both of these are turned
    >> off as the expectation is that Datatracker will be the source for both
    >> of those.

    > That makes sense.

What happens if I connect via meetecho and/or jabber and/or Zulip.
Will I wind up with a name clash?

---

From: Jay Daley <[email-masked]>
Date: Tue, 22 Feb 2022 10:20:47 +1300

> On 22/02/2022, at 7:17 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

We will need to test that.

Jay

--
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 22 Feb 2022 13:02:27 +0000

As  meetecho and zulip both use the datatracker, it should be the same.  As jabber doesn't, it should be the same as it is now.

---

From: Tim April <[email-masked]>
Date: Tue, 22 Feb 2022 20:42:26 -0500

Inline

--tim

>     1.  Permission to change name and email.  Both of these are turned off as the expectation is that Datatracker will be the source for both of those.

Agreed, if there is a source of truth, keeping the relying services pinned in this way is important. An important thing to test is how changes to email or name are propagated to the system. I have seen it done through a sync process (like LDAP) or to require the user to logout and then log back in. Documenting that early might be useful. A slight reason to make the email editable would be to have notifications (missed notifications, log in notices, etc) sent to a different email address.

> No real preference, but it reminds me to make sure animated gifs are disabled or the built-in ones are removed.  (Curse you party parrot :).  Perhaps Tim April (on cc) knows what we did at akamai.…

I believe the image preview option will grab the image once per server and serve the cached image, but that should be checked (clients should grab the image from the server and not the origin). We disabled it on the server I admin for non-privacy related reasons and we’re considering turning it on. I thought there was a ticket to make preview configurable by the user, but I don’t know if that was ever pushed. I find that preview is incredibly valuable for meetings so you can interact passively with the chat system rather than needing to click on image links for context, an example is if someone were to post the slide images to a stream as a talk was being given for people that are not on meet echo. Animations are always a tricky situation, but I am in favor of the preview by default.

>     3.  Show preview of linked websites.  Currently off.

I have recently looked at this code in the codebase and found it to be reasonable. The server will generate the preview and provide text and maybe a cached image as the preview. I’m slightly in favor of this feature being enabled. I would suggest contacting the developers about the safety story around this if considering it.
> Since IETF zulip is only available to IETF datatracker users, this is reasonable.

As long as the syncing discussed in 1 are well handled, I see no issue with allowing them to be visible.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Feb 2022 14:26:10 +0000

Just want to make it clear that I defer to Tim's view in all things Zulip.