From nobody Tue Sep 1 05:11:40 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EA43A0FDE for ; Tue, 1 Sep 2020 05:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TGN4lbU8LgF6 for ; Tue, 1 Sep 2020 05:11:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497A03A0FDF for ; Tue, 1 Sep 2020 05:11:37 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:58337 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kD58S-0008U0-7A; Tue, 01 Sep 2020 05:11:36 -0700 To: Robert Sparks , "tools-implementation@ietf.org" References: From: Henrik Levkowetz Message-ID: <0447d10d-7846-60f2-ce4b-9acda26bd108@levkowetz.com> Date: Tue, 1 Sep 2020 14:11:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Df4hFIpag4qnx2C5LTtNaacoxEmtJko7I" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: tools-implementation@ietf.org, rjsparks@nostrum.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-implementation] Why we're looking at the filesystem structure X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 12:11:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Df4hFIpag4qnx2C5LTtNaacoxEmtJko7I Content-Type: multipart/mixed; boundary="rWXWCN0jrkosMXMokcrBWxIhrHxpaaKQd"; protected-headers="v1" From: Henrik Levkowetz To: Robert Sparks , "tools-implementation@ietf.org" Message-ID: <0447d10d-7846-60f2-ce4b-9acda26bd108@levkowetz.com> Subject: Re: [Tools-implementation] Why we're looking at the filesystem structure References: In-Reply-To: --rWXWCN0jrkosMXMokcrBWxIhrHxpaaKQd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think this is right. Good points. Henrik On 2020-09-01 05:09, Robert Sparks wrote: > I've been thinking deeply about both Glen and Henrik's questions about = > why we are looking at the filesystem structure and what our goals are=20 > when we talk about changing it. >=20 > One insight that I think I've identified is that this activity is a=20 > means to an end, not an end in itself, and we are probably being=20 > distracted by focusing on what the filesystem structure should be. >=20 > It's more important to understand what we really _have_ than it is to=20 > "fix" it (though I think we should keep the pressure up on making it=20 > better). >=20 > The more important goals are being able to discuss doing something less= =20 > painful to us (operators and coders) and more useful to the community=20 > than what we're doing now with providing services. When we've tried to = > approach those in the past, we've felt that we need to do things like=20 > reduce confusion in the URL namespace at www.ietf.org and understand th= e=20 > subtle requirements we currently have with services relying on files in= =20 > the various places we have them. Talking about _those_ things, we've=20 > run quickly into the need to understand what the files we have are all = > about, and then get lost focusing on changes rather than understanding = > what's there. >=20 > I think we're risking getting lost again. The apparent goal we're=20 > pushing towards (defining a better structure) is not really the what=20 > we're trying to achieve, though it is providing a good pressure for=20 > making progress towards those more important goals. >=20 > We need to understand and document the things we have. The=20 > keep/archive/discard conversations are good ways to help us build that = > understanding, but if we build a "perfect" structure in isolation of=20 > what we're going to do with it, the effort isn't going to pay back well= =2E=20 > We need to make sure we understand what we're going to do with the resu= lt. >=20 > Reducing confusion in the www.ietf.org URL namespace is both a "make it= =20 > easier for the user" and "make it simpler for the code and operations" = > goal. Being able to _know_ whether we can pull a service off into the=20 > cloud without breaking other services (or at least really understanding= =20 > how those other services will have to change) is a prerequisite for=20 > reducing our pain, and improving the experience for the community. Thos= e=20 > are goals we should make sure we are moving towards. >=20 > There are obvious things to change with where we're keeping things (and= =20 > in some cases, what we're keeping), yes. Let's change them. >=20 > But I think we should change the timbre of the conversation and make=20 > sure we're talking about "what is that" and "what/who uses that" at=20 > least as much as we're talking about "do we need to keep this". (But=20 > let's not ignore "should we keep this" and "what do we do with it if we= =20 > _do_ keep it" as we're talking about it). >=20 > RjS >=20 >=20 --rWXWCN0jrkosMXMokcrBWxIhrHxpaaKQd-- --Df4hFIpag4qnx2C5LTtNaacoxEmtJko7I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9OOnAACgkQTptXS4+7 Fxr2FBAAkdDsQS3BOezpZix6jeGbbwhLKzGZgdghgj8s4bgGHrc+jRZDFf9IfH2c hRICoiD1BimtoR3Z6JzCMFdEdQS+/MqqjTERF5Vw3S5FX/+5BDDZQ8w6Cb18hIEh 2ZZ6RJ5y4mbu4I7e7J8NVwAEqIe9HsPZIa2OL+YIrXRjlamM7OHbZnoVmJUfqA0F 2FL38akqDxD/es1TD7TwFnQKqLjA44ZclM0kQRcnScD6M0m1MvQdLemrd5uVf900 V2BvxqBYk23ORwFvd/6R5kSGp0pKUtK6ziwW8C6CgB3pKpD3XjBAvDKG2EUGnTyR opwoXysuseqMXd1KvLsQp1s4hpljIkwNgDupm43qvxO7lNZ9DYlsV3q8onz3ucEp 8xMtAdBHVtlqMe64v1FusOoixk+SUIyZyuBSaHfJcogYvAXozaYtcX0FU8HYoCcN jLCsf55vaVyBGliAt7sP8nMk8MkbD8v1ZhmGfiWKfq6d0UW+qF4hXFOXULx2X4Nj 9zgMj8VUF+62KG9Lvc0VVmNi5iOHWBc5BonGKlTH7+7fGlx9WBzWEaqiy/lQIC8r eoC7eN5iR93GCnnBHBD7I5Wp8FDsb32Z38atbWae6xXo5hVWdGuJMVNl461Ua07x QSty6nN7Fj1y42D+aZpfVWVrT8DCu3NdxceUAtYsgKcwNXUHhSk= =Mbh+ -----END PGP SIGNATURE----- --Df4hFIpag4qnx2C5LTtNaacoxEmtJko7I-- From nobody Tue Sep 1 09:33:16 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B21E3A08FB for ; Tue, 1 Sep 2020 09:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 pD9wx2hqSG2q for ; Tue, 1 Sep 2020 09:33:13 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9597B3A08F6 for ; Tue, 1 Sep 2020 09:33:13 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 081GX8EC056382 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 1 Sep 2020 11:33:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1598977989; bh=DRPNvl4DbEsarZSrppJK6C9wufvfoBwoWFP+5BnjRVw=; h=To:Cc:From:Subject:Date; b=Ber/b1w9jXcbExaCfB/I/7Pb6LgeEDS4yiXm3+982fBvKtT7mkpIJtKiWkeJ4nzrI 4p6CGMdUpz6Q0sEnI3pdDctnVz6MbAOh+EY2CbTiSZ18+x5AXIR0Hr6tHnend0Gt4V qakTdih1Azbul1hSVEpeAS1t7BuLABMDpNPUPPm0= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: "tools-implementation@ietf.org" Cc: Ryan Cross From: Robert Sparks Message-ID: <04ca622f-002c-5157-827c-fb5090b2cf75@nostrum.com> Date: Tue, 1 Sep 2020 11:33:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Tools-implementation] A usability anecdote on the mailarchive tool X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 16:33:15 -0000 I was catching up on the gendispatch list today using thunderbird to read the list through the IETF imap service. I encountered a couple of days of messages that were not being served correctly through that service (Ryan is looking at fixing that). They were served through the http-based mailarchive service just fine, however, so I shifted to those to complete my goal of catching up. And I found that I was significantly more than twice as slow reading the view via mailarchive than I was reading it through thunderbird. I started poking at why, and a lot of it has to do with how the css at mailarchive renders whitespace around quotations. Some has to do with contrast, and some has to do with the need to scroll more. I also lost time to learning to discard things that were in my face but I didn't have to read. Those would eventually be trained into me, but before accepting them I think perhaps I should push back about them. (Like the thread index at the bottom of the message - that should perhaps be collapsed or otherwise made very visually distinct). So I wonder if we should look for outside help in assessing how the view can be made more ergonomic (and also assess how the community is really using the tool)? RjS From nobody Tue Sep 1 10:23:48 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C863A0BFD for ; Tue, 1 Sep 2020 10:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NZiXENrnxmuY for ; Tue, 1 Sep 2020 10:23:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160DC3A0BDA for ; Tue, 1 Sep 2020 10:23:46 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:59541 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kDA0X-0002q1-87; Tue, 01 Sep 2020 10:23:45 -0700 To: Robert Sparks , "tools-implementation@ietf.org" References: <04ca622f-002c-5157-827c-fb5090b2cf75@nostrum.com> Cc: Ryan Cross From: Henrik Levkowetz Message-ID: <845a2ad2-69ee-f282-7057-e241839480df@levkowetz.com> Date: Tue, 1 Sep 2020 19:23:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <04ca622f-002c-5157-827c-fb5090b2cf75@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LEUrkGwfsJegdPDmgnLQA8wUArtTqR0b9" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: rcross@amsl.com, tools-implementation@ietf.org, rjsparks@nostrum.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-implementation] A usability anecdote on the mailarchive tool X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 17:23:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LEUrkGwfsJegdPDmgnLQA8wUArtTqR0b9 Content-Type: multipart/mixed; boundary="caCoq2XDFvIFde6r5m1jt3iLI8KcFCj5U"; protected-headers="v1" From: Henrik Levkowetz To: Robert Sparks , "tools-implementation@ietf.org" Cc: Ryan Cross Message-ID: <845a2ad2-69ee-f282-7057-e241839480df@levkowetz.com> Subject: Re: [Tools-implementation] A usability anecdote on the mailarchive tool References: <04ca622f-002c-5157-827c-fb5090b2cf75@nostrum.com> In-Reply-To: <04ca622f-002c-5157-827c-fb5090b2cf75@nostrum.com> --caCoq2XDFvIFde6r5m1jt3iLI8KcFCj5U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-09-01 18:33, Robert Sparks wrote: > I was catching up on the gendispatch list today using thunderbird to=20 > read the list through the IETF imap service. >=20 > I encountered a couple of days of messages that were not being served=20 > correctly through that service (Ryan is looking at fixing that). They=20 > were served through the http-based mailarchive service just fine,=20 > however, so I shifted to those to complete my goal of catching up. >=20 > And I found that I was significantly more than twice as slow reading th= e=20 > view via mailarchive than I was reading it through thunderbird. I=20 > started poking at why, and a lot of it has to do with how the css at=20 > mailarchive renders whitespace around quotations. Some has to do with=20 > contrast, and some has to do with the need to scroll more. >=20 > I also lost time to learning to discard things that were in my face but= =20 > I didn't have to read. Those would eventually be trained into me, but=20 > before accepting them I think perhaps I should push back about them.=20 > (Like the thread index at the bottom of the message - that should=20 > perhaps be collapsed or otherwise made very visually distinct). +1 Collapse and greyed-out when collapsed, and not visually part of the message pane. > So I wonder if we should look for outside help in assessing how the vie= w=20 > can be made more ergonomic (and also assess how the community is really= =20 > using the tool)? Ack. --caCoq2XDFvIFde6r5m1jt3iLI8KcFCj5U-- --LEUrkGwfsJegdPDmgnLQA8wUArtTqR0b9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9Og5oACgkQTptXS4+7 Fxr0yQ/+IBzDY942pmLB5BWVbQ8wPwKAldiu80tAHXZ9ZBRBk7pTyJnZtaei60cM ic41qfoFbJciEZBd9/G18A7tOu3q4mK+r/zyCeiNjooXGx1bWpHWwnoVW00gWmWy jWELjAMDrJRIc1yJID0w3dIvOzm78BuczoIoukHC1w0C/ImqIiagPSydiqEx0Ax5 akvAp0nLKOYoADalY/R3qyTrfesXtwM8uzw6QuLbBwIpqp64pBfKLwCpTvxal1G9 G/svCOrf2yZx2f5+rQSBZLHeCo5jAZKghb3oexwQJLUb7FSe77vcNhyKpgp8Fjlc JX58K1yPyTQPH0xeRfPUAsLU7ou2TyidLdgGQFrjcjL4+nv504uPu8KYcVFnCjGT BCTKABfIgI6zx59ZQlsXOvXXUy8n+reGCdyEU7FNDFFm3mJRzXxclYNLfplsJDJn F/Fkx7zPIXSsB9CFf5uA+Y6mL0oqWIQ0lPZIX2diBKHdtOW9XPWnwsvvtDp9aWHF Kz94814BKZct5KuQjQYYPNIYvPO75o9/NnMHDlV3Xppywx8LRK9QElPqWZsSn04S je3TgXdXZAQJlNadBIVZcKqhpHGhv2ojLt2dF0mE2pquwuyhZYGipMXtczRX2m+0 YbFZlbHnXVJhUzXqU8iIOLUqw0/bq0BR+56ACTJlDp/MyFMY4oo= =Sa8B -----END PGP SIGNATURE----- --LEUrkGwfsJegdPDmgnLQA8wUArtTqR0b9-- From nobody Tue Sep 1 10:31:07 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF903A0C45 for ; Tue, 1 Sep 2020 10:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 BQyzw-4ASrC4 for ; Tue, 1 Sep 2020 10:31:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 F2C543A0C28 for ; Tue, 1 Sep 2020 10:31:01 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 081HUuNE076901 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 1 Sep 2020 12:30:58 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1598981458; bh=8HhH07m7qStJ78Fi47Wlj7boR169H5E9P4kbVWLaKGg=; h=Subject:To:References:From:Date:In-Reply-To; b=YojBG8wvBttgiDaZpFIKyCDQ77cQGQ4DrFVkkgQETmdxTm29GSy5GBIkAfGgEJpv9 EM29UjSMCpnjV+N5LhK1lo81FybIh2MwCV5TGdFxqoW4PVZr9Dp15hl/qmt4FxP6iN oFGQC5C6CITLdY9pQyH1ApD+X21H8vUBBsqbRgTw= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Ryan Cross , "tools-implementation@ietf.org" References: <751dc801-bd0a-ed46-e21e-c4ff5cecc8f2@nostrum.com> <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com> From: Robert Sparks Message-ID: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> Date: Tue, 1 Sep 2020 12:30:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Tools-implementation] Organization of the mail archives X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 17:31:06 -0000 After consulting with Ryan, I propose this disposition for the following email archive related directories: >> Legacy Mailarchive /a/ietf A few very old mail archive scripts This can simply be removed. The scripts are no longer used. >> Email Mailarchive /a/isode ISODE IMAP server data store >> Email Mailarchive /a/mailarch Mail Archive operations These should stay where they are. /a/mailarch/data/archive is the _authoritative_ store. /a/mailarch/data/mbox_archive/public is an automatically generated set of mbox files generated from the authoritative store. That should be used to replace several things below. >> Email Mailman /a/mailman Mailman operations That has to remain (though we should consider what to do with it when we bring in Mailman3 >> Email Mailman /a/mailman/archives Mailman Legacy Archives This has to remain - it is where mailman's internal archiving takes place - any lists using pipermail are kept here, so Legacy isn't really accurate above >> >> Email Postfix /a/postfix Postfix operations This remains >> FTP FTP/Website combined /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT exposed by http >> These have all been imported, and are served through the mailarchive. These should be stashed. I personally don't think we should serve them in any way since they are available through the mailarchive. If they are served, they should clearly be in something I'd like to start calling the "museum". > >> FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains text versions of mail archive ftp, rsync night-runner All web access is to the /a/www/ietf-mail-archive tree, which this is a copy of This should go away as soon as ftp stops depending on it (and we had another conversation about removing it already). >> Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive >> Email Mailarchive /a/www/ietf-mail-archive/text >> Email Mailarchive /a/www/ietf-mail-archive/text-secure >> Email Mailarchive /a/www/ietf-mail-archive/web >> Email Mailarchive /a/www/ietf-mail-archive/web-old >> Email Mailarchive /a/www/ietf-mail-archive/web-secure >> >> Again, has all of that been imported, and can all of this simply be removed (or stashed offline)? All of this should be stashed. Everything here, with the possible exception of things in web-old have been imported into mailarchive. Ryan is looking at making sure those get imported. Once that's done, all of these should either be taken offline or put in the museum. Are there any other puddles of email-archive related things that aren't in those directories? From nobody Tue Sep 1 10:44:37 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF68A3A0C08 for ; Tue, 1 Sep 2020 10:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 kosmVbcyk3kU for ; Tue, 1 Sep 2020 10:44:35 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A473A0C07 for ; Tue, 1 Sep 2020 10:44:35 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 9B6D63C3C22 for ; Tue, 1 Sep 2020 10:44:23 -0700 (PDT) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by c8a.amsl.com (Postfix) with ESMTPSA id 7A2113C3C21 for ; Tue, 1 Sep 2020 10:44:23 -0700 (PDT) Received: by mail-yb1-f169.google.com with SMTP id x2so1268660ybf.12 for ; Tue, 01 Sep 2020 10:44:35 -0700 (PDT) X-Gm-Message-State: AOAM533mmAD4NRJQg6taJCDMDEfnaZyPoklykex0nOieAtoGF0Mbd1GS QuSpKz2zs9PQh9/p9G53/WKAF/cHDPTHAAS5nO0= X-Google-Smtp-Source: ABdhPJxR5YufDjw5yqw9LzwwH6o7Oquqsdzf5ZGG2qB5JrOq3qHi5GEpSfirQ1xaLmY7bTaz3v2i3pmjrpLHD8sMvRI= X-Received: by 2002:a25:8b89:: with SMTP id j9mr4714283ybl.457.1598982274319; Tue, 01 Sep 2020 10:44:34 -0700 (PDT) MIME-Version: 1.0 References: <751dc801-bd0a-ed46-e21e-c4ff5cecc8f2@nostrum.com> <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com> <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> In-Reply-To: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> From: Glen Date: Tue, 1 Sep 2020 10:44:22 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tools-implementation@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Tools-implementation] Organization of the mail archives X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 17:44:37 -0000 On Tue, Sep 1, 2020 at 10:31 AM Robert Sparks wrote: > >> Email Mailarchive /a/isode ISODE IMAP server data store > >> Email Mailarchive /a/mailarch Mail Archive operations > These should stay where they are. > >> Email Mailman /a/mailman Mailman operations > That has to remain > >> Email Postfix /a/postfix Postfix operations > This remains Right. Any package which can be deployed in a more-or-less isolated tree should be in/remain in /a/(packagename) > (though we should consider what to do with it when we bring in Mailman3 At the moment, we are investigating whether the two versions of Mailman can be run in parallel in our environment. We do not yet know, but initial indications are encouraging. Mailman 3 will be deployed into /a/mailman3. Glen From nobody Tue Sep 1 10:51:46 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067703A0C88 for ; Tue, 1 Sep 2020 10:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 ph2j1Dp2rd1l for ; Tue, 1 Sep 2020 10:51:41 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9FD3A0C95 for ; Tue, 1 Sep 2020 10:51:41 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id C5DB23C3C85 for ; Tue, 1 Sep 2020 10:51:29 -0700 (PDT) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by c8a.amsl.com (Postfix) with ESMTPSA id A331F3C3C83 for ; Tue, 1 Sep 2020 10:51:29 -0700 (PDT) Received: by mail-yb1-f178.google.com with SMTP id 189so1297751ybw.3 for ; Tue, 01 Sep 2020 10:51:41 -0700 (PDT) X-Gm-Message-State: AOAM530yMt7xFeNj2VLOOciBjsh0E+B9a+nxXu7EQwQPVeXrIdcIuiUV 7Sy+CmYyeRTpKsAMNaOb/FqJoIWgVzwstDVhm9k= X-Google-Smtp-Source: ABdhPJyjdIQZD0+4dHEBK8uhN2hlpiClI/OER/7MfSHm/W9+FLErrrnnCpgPfTl5JTjI+uX1Uk51Sk9iGVRTIyUZnuE= X-Received: by 2002:a25:5807:: with SMTP id m7mr4496631ybb.456.1598982700478; Tue, 01 Sep 2020 10:51:40 -0700 (PDT) MIME-Version: 1.0 References: <751dc801-bd0a-ed46-e21e-c4ff5cecc8f2@nostrum.com> <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com> <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> In-Reply-To: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> From: Glen Date: Tue, 1 Sep 2020 10:51:28 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tools-implementation@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Tools-implementation] Organization of the mail archives X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 17:51:45 -0000 Separate subthread: On Tue, Sep 1, 2020 at 10:31 AM Robert Sparks wrote: > >> Email Mailman /a/mailman/archives Mailman Legacy Archives > This has to remain - it is where mailman's internal archiving takes > place - any lists using pipermail are kept here, so Legacy isn't really > accurate above Point of clarification: *All lists use pipermail in that Ryan has said that Mailman2's internal archiver cannot be shut off or replaced. But *No lists use pipermail in that /pipermail is not served from anywhere in the Apache config, and all references to /pipermail are redirected to the Mailarchive. So we cannot move or remove, but can safely ignore, everything inside /a/mailman it seems. > >> FTP FTP/Website combined /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT exposed by http Forgive me, I might be misreading "NOT exposed by http," but: https://www.ietf.org/ietf-ftp/concluded-wg-ietf-mail-archive/ > These have all been imported, and are served through the mailarchive. > These should be stashed. I personally don't think we should serve them > in any way since they are available through the mailarchive. +1 I agree they should be removed from FTP, RSYNC, and HTTP, and not served. > >> FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains text versions of mail archive ftp, rsync night-runner All web access is to the /a/www/ietf-mail-archive tree, which this is a copy of > This should go away as soon as ftp stops depending on it (and we had > another conversation about removing it already). > >> Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive > >> Email Mailarchive /a/www/ietf-mail-archive/text > >> Email Mailarchive /a/www/ietf-mail-archive/text-secure > >> Email Mailarchive /a/www/ietf-mail-archive/web > >> Email Mailarchive /a/www/ietf-mail-archive/web-old > >> Email Mailarchive /a/www/ietf-mail-archive/web-secure > >> Again, has all of that been imported, and can all of this simply be removed (or stashed offline)? > All of this should be stashed. Everything here, with the possible > exception of things in web-old have been imported into mailarchive. Ryan > is looking at making sure those get imported. Once that's done, all of > these should either be taken offline or put in the museum. +1. I assume I should do the "taking offline". How will I know when to proceed with that? Robert, I assume you will oversee that? Glen From nobody Tue Sep 1 11:39:33 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7553A0EE6 for ; Tue, 1 Sep 2020 11:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 Bo4qP112kkMo for ; Tue, 1 Sep 2020 11:39:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 59EDB3A0EE5 for ; Tue, 1 Sep 2020 11:39:29 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 081IdQrJ001228 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 1 Sep 2020 13:39:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1598985567; bh=ezEsL1HlvhHuPAAfTR1cn0I/PSA4jWoYyGnO3vVbD4E=; h=To:From:Subject:Date; b=Vqv6sFr1tAYDPLLF2X7/2+OHBA5AXBICYkhYEup5g0pvruqMzSpL+851DghIs+rHg 2aBFlSaV03u50XLwI7z4VBSAAus453YqcagD+vsvQIyOmh3RWSJI/81YBjBE0/ueVO LqIczAbsZeg/LAr6z5PsQVHz50D1+v9IgsO47b1Q= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: "tools-implementation@ietf.org" From: Robert Sparks Message-ID: Date: Tue, 1 Sep 2020 13:39:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------9BA3FF7F69BA1A24245FB172" Content-Language: en-US Archived-At: Subject: [Tools-implementation] Building an understanding of the directories at ietf/YYmon X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 18:39:31 -0000 This is a multi-part message in MIME format. --------------9BA3FF7F69BA1A24245FB172 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Does anyone already understand what all the directories at /a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about? I can make some guesses based on what I see there (I think they were an early effort to organize meeting materials, but it would be better if there were a definitive description of them already lying around. rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d [0-9][0-9][a-z][a-z][a-z] 00dec  01mar  03jul  04nov  90dec  92mar  94dec  95jul    97aug 99jul 00jul  02dec  03mar  05aug  91jul  92nov  94jul  96dec    97dec 99mar 00mar  02jul  03nov  05mar  91mar  93jul  94mar  96jun    98aug 99nov 01aug  02mar  04aug  05nov  91nov  93mar  95apr  96mar    98dec 01dec  02nov  04mar  06mar  92jul  93nov  95dec  97apr    98mar The newest file there is: -rw-rw-rw- 1 wwwrun www 279 Aug  1  2001 01aug/opsarea.txt Looking through the http configs, they get served at https://www.ietf.org/ietf/YYmon, and there are a smattering of hits for them in the logs, all from spiders. Some RFCs reference them: rfc1719: > 1. Introduction > > At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide > BOF", on the process and progress of the IPng activities. > > ("IPng" stands for "IP, the next generation". The IPDecide BOF was > chaired by Brian Carpenter. Minutes are available in the IETF > directories, with the file name 93jul.txt>.) rfc1752: > [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision > Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt, > August 1993. rfc3238: > [OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda: > "http://www.ietf.org/ietf/00dec/opes-agenda.txt". > Minutes: "http://www.ietf.cnri.reston.va.us/ > proceedings/00dec/toc.htm#P25_256". > > IAB Informational [Page 14] > RFC 3238 IAB Considerations for OPES January 2002 > > [OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes: > "http://www.ietf.org/proceedings/01mar/ietf50-40.htm". > > [OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda: > "http://www.ietf.org/ietf/01aug/opes.txt". Minutes: > "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM". I think these would go into a museum that gets served somewhere, but I don't know if we should force that to continue to be a slice of the www.ietf.org namespace. Is it ok to break those few URLs and enter errata against the RFCs to point to where we move them to? There's no real win to slice parts of https://www.ietf.org/ietf/ out with redirects - I'd like to return everything under that url to be something the website (i.e. wagtail) can use. Otherwise we decide to continue to live with having that chunk of the namespace dispatched to a separate service than wagtail. RjS --------------9BA3FF7F69BA1A24245FB172 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Does anyone already understand what all the directories at /a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about?

I can make some guesses based on what I see there (I think they were an early effort to organize meeting materials, but it would be better if there were a definitive description of them already lying around.

rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d [0-9][0-9][a-z][a-z][a-z]
00dec  01mar  03jul  04nov  90dec  92mar  94dec  95jul    97aug  99jul
00jul  02dec  03mar  05aug  91jul  92nov  94jul  96dec    97dec  99mar
00mar  02jul  03nov  05mar  91mar  93jul  94mar  96jun    98aug  99nov
01aug  02mar  04aug  05nov  91nov  93mar  95apr  96mar    98dec
01dec  02nov  04mar  06mar  92jul  93nov  95dec  97apr    98mar

The newest file there is:

-rw-rw-rw- 1 wwwrun www 279 Aug  1  2001 01aug/opsarea.txt

Looking through the http configs, they get served at https://www.ietf.org/ietf/YYmon, and there are a smattering of hits for them in the logs, all from spiders.

Some RFCs reference them:

rfc1719:

1. Introduction

   At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide
   BOF", on the process and progress of the IPng activities.

   ("IPng" stands for "IP, the next generation".   The IPDecide BOF was
   chaired by Brian Carpenter.  Minutes are available in the IETF
   directories, with the file name </ietf/93jul/ipdecide-minutes-
   93jul.txt>.)

rfc1752:

   [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
      Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
      August 1993.

rfc3238:

   [OPESBOF1]  OPES BOF, 49th IETF, December 12, 2000.  Agenda:
               "http://www.ietf.org/ietf/00dec/opes-agenda.txt".
               Minutes:  "http://www.ietf.cnri.reston.va.us/
               proceedings/00dec/toc.htm#P25_256".

IAB                          Informational                     [Page 14]
RFC 3238              IAB Considerations for OPES           January 2002

   [OPESBOF2]  OPES BOF, 50th IETF, March 9, 2001.  Minutes:
               "http://www.ietf.org/proceedings/01mar/ietf50-40.htm".

   [OPESBOF3]  OPES BOF, 51st IETF, August 2001.  Agenda:
               "http://www.ietf.org/ietf/01aug/opes.txt".  Minutes:
               "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".

I think these would go into a museum that gets served somewhere, but I don't know if we should force that to continue to be a slice of the www.ietf.org namespace.

Is it ok to break those few URLs and enter errata against the RFCs to point to where we move them to?

There's no real win to slice parts of https://www.ietf.org/ietf/ out with redirects - I'd like to return everything under that url to be something the website (i.e. wagtail) can use. Otherwise we decide to continue to live with having that chunk of the namespace dispatched to a separate service than wagtail.

RjS




--------------9BA3FF7F69BA1A24245FB172-- From nobody Tue Sep 1 11:59:10 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC043A0F48 for ; Tue, 1 Sep 2020 11:59:08 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 44g8CAEz-BHw for ; Tue, 1 Sep 2020 11:59:06 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6E33A0F3E for ; Tue, 1 Sep 2020 11:59:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5210A300B92 for ; Tue, 1 Sep 2020 14:59:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2WL20jxtWSiI for ; Tue, 1 Sep 2020 14:59:01 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id DD81A300AFF; Tue, 1 Sep 2020 14:59:00 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C20604A2-01BB-4BDF-A931-CABDD0DC3374" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Tue, 1 Sep 2020 14:59:01 -0400 In-Reply-To: Cc: "tools-implementation@ietf.org" To: Robert Sparks References: X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Tools-implementation] Building an understanding of the directories at ietf/YYmon X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 18:59:08 -0000 --Apple-Mail=_C20604A2-01BB-4BDF-A931-CABDD0DC3374 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If memory serves, the proceedings used to include a snapshot of the I-Ds = that were active at the time of the meeting. This is from a time when = the proceedings were distributed as a CD-ROM. Russ > On Sep 1, 2020, at 2:39 PM, Robert Sparks = wrote: >=20 > Does anyone already understand what all the directories at = /a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about? >=20 > I can make some guesses based on what I see there (I think they were = an early effort to organize meeting materials, but it would be better if = there were a definitive description of them already lying around. >=20 > rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d [0-9][0-9][a-z][a-z][a-z] > 00dec 01mar 03jul 04nov 90dec 92mar 94dec 95jul 97aug 99jul > 00jul 02dec 03mar 05aug 91jul 92nov 94jul 96dec 97dec 99mar > 00mar 02jul 03nov 05mar 91mar 93jul 94mar 96jun 98aug 99nov > 01aug 02mar 04aug 05nov 91nov 93mar 95apr 96mar 98dec > 01dec 02nov 04mar 06mar 92jul 93nov 95dec 97apr 98mar > The newest file there is: >=20 > -rw-rw-rw- 1 wwwrun www 279 Aug 1 2001 01aug/opsarea.txt >=20 > Looking through the http configs, they get served at = https://www.ietf.org/ietf/YYmon , and = there are a smattering of hits for them in the logs, all from spiders. >=20 > Some RFCs reference them: >=20 > rfc1719: >=20 >=20 >> 1. Introduction >>=20 >> At the Amsterdam IETF meeting, we held a BOF, entitled the = "IPDecide >> BOF", on the process and progress of the IPng activities. >>=20 >> ("IPng" stands for "IP, the next generation". The IPDecide BOF = was >> chaired by Brian Carpenter. Minutes are available in the IETF >> directories, with the file name > 93jul.txt>.) >=20 >=20 > rfc1752: >=20 >=20 >> [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng = Decision >> Process BOF (IPDECIDE)", = /ietf/93jul/ipdecide-minutes-93jul.txt, >> August 1993. >=20 >=20 > rfc3238: >=20 >=20 >> [OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda: >> "http://www.ietf.org/ietf/00dec/opes-agenda.txt" = . >> Minutes: "http://www.ietf.cnri.reston.va.us/ >> proceedings/00dec/toc.htm#P25_256" = . >>=20 >> IAB Informational [Page = 14] >> RFC 3238 IAB Considerations for OPES January = 2002 >>=20 >> [OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes: >> "http://www.ietf.org/proceedings/01mar/ietf50-40.htm" = . >>=20 >> [OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda: >> "http://www.ietf.org/ietf/01aug/opes.txt" = . Minutes: >> = "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM" = . >=20 >=20 > I think these would go into a museum that gets served somewhere, but I = don't know if we should force that to continue to be a slice of the = www.ietf.org namespace. >=20 > Is it ok to break those few URLs and enter errata against the RFCs to = point to where we move them to? >=20 > There's no real win to slice parts of https://www.ietf.org/ietf/ = out with redirects - I'd like to return = everything under that url to be something the website (i.e. wagtail) can = use. Otherwise we decide to continue to live with having that chunk of = the namespace dispatched to a separate service than wagtail. >=20 > RjS >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Tools-implementation mailing list > Tools-implementation@ietf.org > https://www.ietf.org/mailman/listinfo/tools-implementation --Apple-Mail=_C20604A2-01BB-4BDF-A931-CABDD0DC3374 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii If memory serves, the proceedings used to include a snapshot of the I-Ds that were active at the time of the meeting.  This is from a time when the proceedings were distributed as a CD-ROM.

Russ


On Sep 1, 2020, at 2:39 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

Does anyone already understand what all the directories at /a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about?

I can make some guesses based on what I see there (I think they were an early effort to organize meeting materials, but it would be better if there were a definitive description of them already lying around.

rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d [0-9][0-9][a-z][a-z][a-z]
00dec  01mar  03jul  04nov  90dec  92mar  94dec  95jul    97aug  99jul
00jul  02dec  03mar  05aug  91jul  92nov  94jul  96dec    97dec  99mar
00mar  02jul  03nov  05mar  91mar  93jul  94mar  96jun    98aug  99nov
01aug  02mar  04aug  05nov  91nov  93mar  95apr  96mar    98dec
01dec  02nov  04mar  06mar  92jul  93nov  95dec  97apr    98mar

The newest file there is:

-rw-rw-rw- 1 wwwrun www 279 Aug  1  2001 01aug/opsarea.txt

Looking through the http configs, they get served at https://www.ietf.org/ietf/YYmon, and there are a smattering of hits for them in the logs, all from spiders.

Some RFCs reference them:

rfc1719:


1. Introduction

   At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide
   BOF", on the process and progress of the IPng activities.

   ("IPng" stands for "IP, the next generation".   The IPDecide BOF was
   chaired by Brian Carpenter.  Minutes are available in the IETF
   directories, with the file name </ietf/93jul/ipdecide-minutes-
   93jul.txt>.)


rfc1752:


   [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
      Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
      August 1993.


rfc3238:


   [OPESBOF1]  OPES BOF, 49th IETF, December 12, 2000.  Agenda:
               "http://www.ietf.org/ietf/00dec/opes-agenda.txt".
               Minutes:  "http://www.ietf.cnri.reston.va.us/
               proceedings/00dec/toc.htm#P25_256".

IAB                          Informational                     [Page 14]
RFC 3238              IAB Considerations for OPES           January 2002

   [OPESBOF2]  OPES BOF, 50th IETF, March 9, 2001.  Minutes:
               "http://www.ietf.org/proceedings/01mar/ietf50-40.htm".

   [OPESBOF3]  OPES BOF, 51st IETF, August 2001.  Agenda:
               "http://www.ietf.org/ietf/01aug/opes.txt".  Minutes:
               "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".


I think these would go into a museum that gets served somewhere, but I don't know if we should force that to continue to be a slice of the www.ietf.org namespace.

Is it ok to break those few URLs and enter errata against the RFCs to point to where we move them to?

There's no real win to slice parts of https://www.ietf.org/ietf/ out with redirects - I'd like to return everything under that url to be something the website (i.e. wagtail) can use. Otherwise we decide to continue to live with having that chunk of the namespace dispatched to a separate service than wagtail.

RjS




--
Tools-implementation mailing list
Tools-implementation@ietf.org
https://www.ietf.org/mailman/listinfo/tools-implementation

--Apple-Mail=_C20604A2-01BB-4BDF-A931-CABDD0DC3374-- From nobody Tue Sep 1 12:04:03 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CE23A0F48 for ; Tue, 1 Sep 2020 12:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 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, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 HMgYCgWhc0vO for ; Tue, 1 Sep 2020 12:04:00 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2D3303A0F3E for ; Tue, 1 Sep 2020 12:04:00 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 081J3wGV009918 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 1 Sep 2020 14:03:59 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1598987039; bh=r+RQ5ZTuggGlkuMZei6iDRt9nck59jFdiSCHvTcKmmQ=; h=Subject:To:References:From:Date:In-Reply-To; b=AvhjBqnqUwBy1HorXbLxRhe1+gC14Syp/pqRtnIGW127CSPj4zPvsT8d3cFepO2im CwdUnIkuI6I9qO1JCC70MIMK5tAQMtOBSWCAa7H3I5zd5KcxzC6GLsH0pxPDfXYC84 qIJ6MPgUWLYIpZecy0TL53U6V/tALjfyiyHkaEpE= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: tools-implementation@ietf.org References: <751dc801-bd0a-ed46-e21e-c4ff5cecc8f2@nostrum.com> <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com> <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> From: Robert Sparks Message-ID: Date: Tue, 1 Sep 2020 14:03:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Organization of the mail archives X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 19:04:02 -0000 On 9/1/20 12:51 PM, Glen wrote: > Separate subthread: > > On Tue, Sep 1, 2020 at 10:31 AM Robert Sparks wrote: >>>> Email Mailman /a/mailman/archives Mailman Legacy Archives >> This has to remain - it is where mailman's internal archiving takes >> place - any lists using pipermail are kept here, so Legacy isn't really >> accurate above > Point of clarification: > *All lists use pipermail in that Ryan has said that Mailman2's > internal archiver cannot be shut off or replaced. > But > *No lists use pipermail in that /pipermail is not served from anywhere > in the Apache config, and all references to /pipermail are redirected > to the Mailarchive. > > So we cannot move or remove, but can safely ignore, everything inside > /a/mailman it seems. Thank you! But I'm still a bit concerned about one thing. I had it in my head that there were still some active, or only recently (~5yrs) dormant lists that only existed outside what mailarchive was ingesting. If that's not true, I'll be relieved. Ryan (or anyone else) - do you remember any such thing and can you point to it? > >>>> FTP FTP/Website combined /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT exposed by http > Forgive me, I might be misreading "NOT exposed by http," but: > https://www.ietf.org/ietf-ftp/concluded-wg-ietf-mail-archive/ Old notes - clearly no longer correct. At the time, they said "http://www.ietf.org/ietf-ftp goes to ietf-ftp/ietf". > >> These have all been imported, and are served through the mailarchive. >> These should be stashed. I personally don't think we should serve them >> in any way since they are available through the mailarchive. > +1 I agree they should be removed from FTP, RSYNC, and HTTP, and not served. > >>>> FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains text versions of mail archive ftp, rsync night-runner All web access is to the /a/www/ietf-mail-archive tree, which this is a copy of >> This should go away as soon as ftp stops depending on it (and we had >> another conversation about removing it already). >>>> Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive >>>> Email Mailarchive /a/www/ietf-mail-archive/text >>>> Email Mailarchive /a/www/ietf-mail-archive/text-secure >>>> Email Mailarchive /a/www/ietf-mail-archive/web >>>> Email Mailarchive /a/www/ietf-mail-archive/web-old >>>> Email Mailarchive /a/www/ietf-mail-archive/web-secure >>>> Again, has all of that been imported, and can all of this simply be removed (or stashed offline)? >> All of this should be stashed. Everything here, with the possible >> exception of things in web-old have been imported into mailarchive. Ryan >> is looking at making sure those get imported. Once that's done, all of >> these should either be taken offline or put in the museum. > +1. > > I assume I should do the "taking offline". How will I know when to > proceed with that? Robert, I assume you will oversee that? Yes. Right now we are still trying to understand, and that understanding will build a plan. I talk about what I think _should_ happen above as a proposal to that plan, not as directives to take action now. > > Glen > From nobody Tue Sep 1 12:12:28 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926263A0F68 for ; Tue, 1 Sep 2020 12:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.026 X-Spam-Level: X-Spam-Status: No, score=-3.026 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 QGDlkMBedIwP for ; Tue, 1 Sep 2020 12:12:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BC4963A0F67 for ; Tue, 1 Sep 2020 12:12:24 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 081JCMDS012966 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 1 Sep 2020 14:12:23 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1598987544; bh=VbzP4BZwQYmXi/FTHy+pzUdzspoAX82TKfGoNF1NMQQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=oMyaQSrbi35gWYn9g/52GAujiEsSM6sIiCAjULQsgNjuqWwUJifjucV7aroBmL0sa XoRm+/tFhl6GZ1TiICg/UKmbu9EBRZaPsE+5ycIvDc/NQWA+pQuS4Uv02N4lVG5ftu b3NKs5qRsSelDl4yiIEjrrKnzmTJKcU++cCnlMls= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Russ Housley Cc: "tools-implementation@ietf.org" References: From: Robert Sparks Message-ID: Date: Tue, 1 Sep 2020 14:12:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6AF24BE9A86468B320708AF5" Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Building an understanding of the directories at ietf/YYmon X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 19:12:27 -0000 This is a multi-part message in MIME format. --------------6AF24BE9A86468B320708AF5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 9/1/20 1:59 PM, Russ Housley wrote: > If memory serves, the proceedings used to include a snapshot of the > I-Ds that were active at the time of the meeting.  This is from a time > when the proceedings were distributed as a CD-ROM. Yes, but I don't think that's what these directories contain. There are other directories that support the cd-rom images, and proceedings. > > Russ > > >> On Sep 1, 2020, at 2:39 PM, Robert Sparks > > wrote: >> >> Does anyone already understand what all the directories at >> /a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about? >> >> I can make some guesses based on what I see there (I think they were >> an early effort to organize meeting materials, but it would be better >> if there were a definitive description of them already lying around. >> >> rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d [0-9][0-9][a-z][a-z][a-z] >> 00dec  01mar  03jul  04nov  90dec  92mar  94dec 95jul    97aug  99jul >> 00jul  02dec  03mar  05aug  91jul  92nov  94jul 96dec    97dec  99mar >> 00mar  02jul  03nov  05mar  91mar  93jul  94mar 96jun    98aug  99nov >> 01aug  02mar  04aug  05nov  91nov  93mar  95apr 96mar    98dec >> 01dec  02nov  04mar  06mar  92jul  93nov  95dec 97apr    98mar >> >> The newest file there is: >> >> -rw-rw-rw- 1 wwwrun www 279 Aug  1  2001 01aug/opsarea.txt >> >> Looking through the http configs, they get served at >> https://www.ietf.org/ietf/YYmon, and there are a smattering of hits >> for them in the logs, all from spiders. >> >> Some RFCs reference them: >> >> rfc1719: >> >> >>> 1. Introduction >>> >>> At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide >>> BOF", on the process and progress of the IPng activities. >>> >>> ("IPng" stands for "IP, the next generation". The IPDecide BOF was >>> chaired by Brian Carpenter. Minutes are available in the IETF >>> directories, with the file name >> 93jul.txt>.) >> >> >> rfc1752: >> >> >>> [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision >>> Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt, >>> August 1993. >> >> >> rfc3238: >> >> >>> [OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda: >>> "http://www.ietf.org/ietf/00dec/opes-agenda.txt". >>> Minutes:"http://www.ietf.cnri.reston.va.us/ proceedings/00dec/toc.htm#P25_256". >>> >>> IAB Informational [Page 14] >>> RFC 3238 IAB Considerations for OPES January 2002 >>> >>> [OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes: >>> "http://www.ietf.org/proceedings/01mar/ietf50-40.htm". >>> >>> [OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda: >>> "http://www.ietf.org/ietf/01aug/opes.txt". Minutes: >>> "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM". >> >> >> I think these would go into a museum that gets served somewhere, but >> I don't know if we should force that to continue to be a slice of the >> www.ietf.org namespace. >> >> Is it ok to break those few URLs and enter errata against the RFCs to >> point to where we move them to? >> >> There's no real win to slice parts of https://www.ietf.org/ietf/ out >> with redirects - I'd like to return everything under that url to be >> something the website (i.e. wagtail) can use. Otherwise we decide to >> continue to live with having that chunk of the namespace dispatched >> to a separate service than wagtail. >> >> RjS >> >> >> >> >> -- >> Tools-implementation mailing list >> Tools-implementation@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-implementation > --------------6AF24BE9A86468B320708AF5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit


On 9/1/20 1:59 PM, Russ Housley wrote:
If memory serves, the proceedings used to include a snapshot of the I-Ds that were active at the time of the meeting.  This is from a time when the proceedings were distributed as a CD-ROM.
Yes, but I don't think that's what these directories contain. There are other directories that support the cd-rom images, and proceedings.

Russ


On Sep 1, 2020, at 2:39 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

Does anyone already understand what all the directories at /a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about?

I can make some guesses based on what I see there (I think they were an early effort to organize meeting materials, but it would be better if there were a definitive description of them already lying around.

rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d [0-9][0-9][a-z][a-z][a-z]
00dec  01mar  03jul  04nov  90dec  92mar  94dec  95jul    97aug  99jul
00jul  02dec  03mar  05aug  91jul  92nov  94jul  96dec    97dec  99mar
00mar  02jul  03nov  05mar  91mar  93jul  94mar  96jun    98aug  99nov
01aug  02mar  04aug  05nov  91nov  93mar  95apr  96mar    98dec
01dec  02nov  04mar  06mar  92jul  93nov  95dec  97apr    98mar

The newest file there is:

-rw-rw-rw- 1 wwwrun www 279 Aug  1  2001 01aug/opsarea.txt

Looking through the http configs, they get served at https://www.ietf.org/ietf/YYmon, and there are a smattering of hits for them in the logs, all from spiders.

Some RFCs reference them:

rfc1719:


1. Introduction

   At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide
   BOF", on the process and progress of the IPng activities.

   ("IPng" stands for "IP, the next generation".   The IPDecide BOF was
   chaired by Brian Carpenter.  Minutes are available in the IETF
   directories, with the file name </ietf/93jul/ipdecide-minutes-
   93jul.txt>.)


rfc1752:


   [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
      Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
      August 1993.


rfc3238:


   [OPESBOF1]  OPES BOF, 49th IETF, December 12, 2000.  Agenda:
               "http://www.ietf.org/ietf/00dec/opes-agenda.txt".
               Minutes:  "http://www.ietf.cnri.reston.va.us/
               proceedings/00dec/toc.htm#P25_256".

IAB                          Informational                     [Page 14]
RFC 3238              IAB Considerations for OPES           January 2002

   [OPESBOF2]  OPES BOF, 50th IETF, March 9, 2001.  Minutes:
               "http://www.ietf.org/proceedings/01mar/ietf50-40.htm".

   [OPESBOF3]  OPES BOF, 51st IETF, August 2001.  Agenda:
               "http://www.ietf.org/ietf/01aug/opes.txt".  Minutes:
               "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".


I think these would go into a museum that gets served somewhere, but I don't know if we should force that to continue to be a slice of the www.ietf.org namespace.

Is it ok to break those few URLs and enter errata against the RFCs to point to where we move them to?

There's no real win to slice parts of https://www.ietf.org/ietf/ out with redirects - I'd like to return everything under that url to be something the website (i.e. wagtail) can use. Otherwise we decide to continue to live with having that chunk of the namespace dispatched to a separate service than wagtail.

RjS




--
Tools-implementation mailing list
Tools-implementation@ietf.org
https://www.ietf.org/mailman/listinfo/tools-implementation

--------------6AF24BE9A86468B320708AF5-- From nobody Tue Sep 1 12:29:31 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9102B3A1027 for ; Tue, 1 Sep 2020 12:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 sEm3wQb-UCnr for ; Tue, 1 Sep 2020 12:29:20 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4E13A0FA3 for ; Tue, 1 Sep 2020 12:29:18 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id AF8233C2E08 for ; Tue, 1 Sep 2020 12:29:06 -0700 (PDT) Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by c8a.amsl.com (Postfix) with ESMTPSA id 89ED93C2E07 for ; Tue, 1 Sep 2020 12:29:06 -0700 (PDT) Received: by mail-yb1-f177.google.com with SMTP id q16so1466618ybk.6 for ; Tue, 01 Sep 2020 12:29:18 -0700 (PDT) X-Gm-Message-State: AOAM532Txqm09VoJbjL5nk086WZRVXguGGF5EV5IERdXBG44Lzbn6pjy 8gXlxpNp00s4FqTdQhKs5prlCYR3RUVZRyRzk/Y= X-Google-Smtp-Source: ABdhPJx0hG1eYlvZj7Arcl0vuZcjpTfgZ3tTfbNikbLR+FP5xVVuzfwify4c/Woebn5HAG8JOSZfeTlDn0wB3wWWFBw= X-Received: by 2002:a25:8b89:: with SMTP id j9mr5351276ybl.457.1598988557501; Tue, 01 Sep 2020 12:29:17 -0700 (PDT) MIME-Version: 1.0 References: <751dc801-bd0a-ed46-e21e-c4ff5cecc8f2@nostrum.com> <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com> <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> In-Reply-To: From: Glen Date: Tue, 1 Sep 2020 12:29:05 -0700 X-Gmail-Original-Message-ID: Message-ID: To: tools-implementation@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Tools-implementation] Organization of the mail archives X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 19:29:30 -0000 On Tue, Sep 1, 2020 at 12:04 PM Robert Sparks wrote: > > So we cannot move or remove, but can safely ignore, everything inside > > /a/mailman it seems. > Thank you! Oh! Well... you're welcome! > But I'm still a bit concerned about one thing. I had it in my head that > there were still some active, or only recently (~5yrs) dormant lists > that only existed outside what mailarchive was ingesting. If that's not > true, I'll be relieved. Ryan (or anyone else) - do you remember any such > thing and can you point to it? Well, there is: tail -35 /a/postfix/virtual tail -36 /a/postfix/aliases which are external feeder points for the mailarchive tool. All of them are pointing to new new archive system (only), but I have no idea which are still active/in use or not. I'm not aware of anything pointing to MHonarc or any legacy archiving systems. > Yes. Right now we are still trying to understand, and that understanding > will build a plan. I talk about what I think _should_ happen above as a > proposal to that plan, not as directives to take action now. Okay, thank you. I have that September 4 removal directive I'll proceed with, but everything else I'll just take as conversation unless you tell me otherwise. Glen From nobody Thu Sep 3 06:35:39 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FD23A0BFC for ; Thu, 3 Sep 2020 06:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wZgvFdRnIRN9 for ; Thu, 3 Sep 2020 06:35:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC44C3A0BF2 for ; Thu, 3 Sep 2020 06:35:31 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:51306 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kDpOg-0002hU-1o for tools-implementation@ietf.org; Thu, 03 Sep 2020 06:35:30 -0700 To: tools-implementation@ietf.org References: <67be10c9-1958-4357-bb59-7fd2f845bd23@levkowetz.com> From: Henrik Levkowetz Message-ID: Date: Thu, 3 Sep 2020 15:35:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <67be10c9-1958-4357-bb59-7fd2f845bd23@levkowetz.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MWHC9qVxL7IAG2afu6g10R9ACM4XKQemu" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: tools-implementation@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-implementation] https accesses to drafts and RFCs on tools.ietf.org X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 13:35:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MWHC9qVxL7IAG2afu6g10R9ACM4XKQemu Content-Type: multipart/mixed; boundary="8EinoA1AVW74WXaIMKrfmbVgW7a2M4r7h"; protected-headers="v1" From: Henrik Levkowetz To: tools-implementation@ietf.org Message-ID: Subject: Re: https accesses to drafts and RFCs on tools.ietf.org References: <67be10c9-1958-4357-bb59-7fd2f845bd23@levkowetz.com> In-Reply-To: <67be10c9-1958-4357-bb59-7fd2f845bd23@levkowetz.com> --8EinoA1AVW74WXaIMKrfmbVgW7a2M4r7h Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Roman Here are the FTP figures from the IETF production server, based on the available log data. The bargraphs are scaled to the same scale as the equivalent tools figures. Since the production server doesn't serve htmlized drafts and RFCs over FTP, there are no figures for those categories: Unprocessed Drafts: 506 2020-08-02 3%=20 180 2020-08-03 1%=20 196 2020-08-04 1%=20 128 2020-08-05 0%=20 127 2020-08-06 0%=20 211 2020-08-07 1%=20 189 2020-08-08 1%=20 199 2020-08-09 1%=20 215 2020-08-10 1%=20 193 2020-08-11 1%=20 1851 2020-08-12 12%=20 1280 2020-08-13 8%=20 174 2020-08-23 1%=20 156 2020-08-24 1%=20 193 2020-08-25 1%=20 111 2020-08-26 0%=20 1986 2020-08-27 13%=20 210 2020-08-28 1%=20 5355 2020-08-29 36% * 523 2020-08-30 3%=20 180 2020-08-31 1%=20 204 2020-09-01 1%=20 257 2020-09-02 1%=20 118 2020-09-03 0%=20 614.2 Average/Day 4%=20 14742 Total =20 111 Minimum/Day 5355 Maximum/Day Unprocessed RFCs: 9 2020-08-02 0%=20 29 2020-08-03 0%=20 30 2020-08-04 0%=20 23 2020-08-05 0%=20 3376 2020-08-06 24% ********* 637 2020-08-07 4% * 30 2020-08-08 0%=20 14 2020-08-09 0%=20 24 2020-08-10 0%=20 20 2020-08-11 0%=20 18 2020-08-12 0%=20 36 2020-08-13 0%=20 1 2020-08-22 0%=20 17 2020-08-23 0%=20 19 2020-08-24 0%=20 27 2020-08-25 0%=20 24 2020-08-26 0%=20 35 2020-08-27 0%=20 3549 2020-08-28 26% ********** 3483 2020-08-29 25% ********** 1802 2020-08-30 13% ***** 38 2020-08-31 0%=20 330 2020-09-01 2%=20 59 2020-09-02 0%=20 20 2020-09-03 0%=20 546.0 Average/Day 4% =3D 13650 Total =20 1 Minimum/Day 3549 Maximum/Day The figures above show only retrievals of the .txt version, which matches= the tools.ietf.org figures; but there were also retrievals of derived .pd= f, =2Ehtml, .json (meta-information) and text versions without extension, wh= ich in particular gave a spike of 49855 retrievals on Aug. 28th. That spike was essentially due to one actor. Grouping the Aug. 28 data above by cli= ent: 1 1.241.44.96 0%=20 1 162.216.25.12 0%=20 7 172.83.168.131 0%=20 6 192.30.89.142 0%=20 4 2001:4898:80e8:a:9a8:247b:f8dc:e 0%=20 7 2a00:801:fd:800:250:56ff:fea5:ca 0%=20 5 alpha.harfa.net 0%=20 8 anubis.u-strasbg.fr 0%=20 3464 chekov.greenie.muc.de 97% ***************************= ***** 5 ftp.nluug.nl 0%=20 7 ftp2.ncnu.edu.tw 0%=20 8 pike-www.lysator.liu.se 0%=20 7 proxy3.nic.ad.jp 0%=20 5 quimby.gnus.org 0%=20 7 seymour23.snmp.com 0%=20 7 vlsi03.si.noda.tus.ac.jp 0%=20 or looking at the full RFC retrievals of that date, not just the .txt fil= es: 1 1.241.44.96 0%=20 1 162.216.25.12 0%=20 29 172.83.168.131 0%=20 31 192.30.89.142 0%=20 4 2001:4898:80e8:a:9a8:247b:f8dc:e 0%=20 33 2a00:801:fd:800:250:56ff:fea5:ca 0%=20 26 alpha.harfa.net 0%=20 36 anubis.u-strasbg.fr 0%=20 31 chandelierly.boon.volia.net 0%=20 49482 chekov.greenie.muc.de 99% ***************************= ***** 27 ftp.nluug.nl 0%=20 34 ftp2.ncnu.edu.tw 0%=20 34 pike-www.lysator.liu.se 0%=20 36 proxy3.nic.ad.jp 0%=20 5 quimby.gnus.org 0%=20 12 seymour23.snmp.com 0%=20 33 vlsi03.si.noda.tus.ac.jp 0%=20 Best regards, Henrik On 2020-08-25 19:46, Henrik Levkowetz wrote: > Hi Roman, >=20 > I don't know how to best partition and select the data about https acce= sses > to drafts and RFCs on tools.ietf.org, but here's a first approach. >=20 > I've split the data into accesses to htmlized documents and unprocessed= > documents, and in turn split those into draft-* and rfc* accesses. >=20 > All figures are for the last 73 days (since June 14th): >=20 > Htmlized drafts: > 97322 Average/Day > 7104548 Total =20 > 29097 Minimum/Day > 135658 Maximum/Day >=20 > Htmlized RFCs: > 306076 Average/Day > 22343564 Total =20 > 126506 Minimum/Day > 535266 Maximum/Day >=20 > Unprocessed Drafts: > 47976 Average/Day > 3502257 Total =20 > 14070 Minimum/Day > 169578 Maximum/Day >=20 > Unprocessed RFCs: > 8748 Average/Day > 638645 Total =20 > 5289 Minimum/Day > 18640 Maximum/Day >=20 > In case it would be of any use (I don't think so, the figures above > should contain the essence, but ...) I've also copied in the per-day > counts with histogram below. >=20 > Let me know if you need the data massaged differently. >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 >=20 > -----------------------------------------------------------------------= --------- >=20 >=20 >=20 > apache-html-draft.hits > 81266 2020-06-14 1% ******************************** > 106428 2020-06-15 1% ****************************************** > 110841 2020-06-16 1% ******************************************** > 111007 2020-06-17 1% ******************************************** > 78600 2020-06-18 1% ******************************* > 72794 2020-06-19 1% **************************** > 53766 2020-06-20 0% ********************* > 62376 2020-06-21 0% ************************ > 88540 2020-06-22 1% *********************************** > 85501 2020-06-23 1% ********************************** > 81878 2020-06-24 1% ******************************** > 92900 2020-06-25 1% ************************************ > 87744 2020-06-26 1% ********************************** > 62831 2020-06-27 0% ************************* > 67390 2020-06-28 0% ************************** > 104369 2020-06-29 1% ***************************************** > 100735 2020-06-30 1% **************************************** > 107741 2020-07-01 1% ****************************************** > 135658 2020-07-02 1% ***********************************************= ******* > 89205 2020-07-03 1% *********************************** > 74852 2020-07-04 1% ***************************** > 64488 2020-07-05 0% ************************* > 90414 2020-07-06 1% *********************************** > 113455 2020-07-07 1% ********************************************* > 95969 2020-07-08 1% ************************************** > 104358 2020-07-09 1% ***************************************** > 95166 2020-07-10 1% ************************************* > 103439 2020-07-11 1% ***************************************** > 104289 2020-07-12 1% ***************************************** > 123107 2020-07-13 1% ***********************************************= ** > 105469 2020-07-14 1% ***************************************** > 124455 2020-07-15 1% ***********************************************= ** > 111573 2020-07-16 1% ******************************************** > 114783 2020-07-17 1% ********************************************* > 84040 2020-07-18 1% ********************************* > 91487 2020-07-19 1% ************************************ > 98138 2020-07-20 1% *************************************** > 86829 2020-07-21 1% ********************************** > 89191 2020-07-22 1% *********************************** > 92841 2020-07-23 1% ************************************ > 95828 2020-07-24 1% ************************************** > 78270 2020-07-25 1% ******************************* > 79919 2020-07-26 1% ******************************* > 89278 2020-07-27 1% *********************************** > 105444 2020-07-28 1% ***************************************** > 115671 2020-07-29 1% ********************************************** > 107497 2020-07-30 1% ****************************************** > 91011 2020-07-31 1% ************************************ > 112594 2020-08-01 1% ******************************************** > 117895 2020-08-02 1% ********************************************** > 115567 2020-08-03 1% ********************************************** > 111839 2020-08-04 1% ******************************************** > 133018 2020-08-05 1% ***********************************************= ***** > 129636 2020-08-06 1% ***********************************************= **** > 92681 2020-08-07 1% ************************************ > 103041 2020-08-08 1% ***************************************** > 108460 2020-08-09 1% ******************************************* > 101429 2020-08-10 1% **************************************** > 100971 2020-08-11 1% **************************************** > 112109 2020-08-12 1% ******************************************** > 108633 2020-08-13 1% ******************************************* > 113473 2020-08-14 1% ********************************************* > 105689 2020-08-15 1% ****************************************** > 105464 2020-08-16 1% ***************************************** > 117522 2020-08-17 1% ********************************************** > 106793 2020-08-18 1% ****************************************** > 115426 2020-08-19 1% ********************************************* > 124808 2020-08-20 1% ***********************************************= ** > 97833 2020-08-21 1% ************************************** > 80983 2020-08-22 1% ******************************** > 71943 2020-08-23 1% **************************** > 74813 2020-08-24 1% ***************************** > 29097 2020-08-25 0% *********** >=20 > 97322.6 Average 1% =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 7104548 Total =20 > 29097 Minimum =20 > 135658 Maximum =20 >=20 >=20 > apache-html-rfcs.hits > 146316 2020-06-14 0% ************** > 291820 2020-06-15 1% ***************************** > 295920 2020-06-16 1% ***************************** > 338479 2020-06-17 1% ********************************** > 273364 2020-06-18 1% *************************** > 222879 2020-06-19 0% ********************** > 141763 2020-06-20 0% ************** > 188444 2020-06-21 0% ******************* > 288590 2020-06-22 1% ***************************** > 270873 2020-06-23 1% *************************** > 305401 2020-06-24 1% ****************************** > 333383 2020-06-25 1% ********************************* > 274105 2020-06-26 1% *************************** > 241347 2020-06-27 1% ************************ > 188843 2020-06-28 0% ******************* > 348267 2020-06-29 1% *********************************** > 325185 2020-06-30 1% ******************************** > 373970 2020-07-01 1% ************************************* > 352141 2020-07-02 1% *********************************** > 321019 2020-07-03 1% ******************************** > 223567 2020-07-04 1% ********************** > 232055 2020-07-05 1% *********************** > 368149 2020-07-06 1% ************************************* > 353699 2020-07-07 1% *********************************** > 321830 2020-07-08 1% ******************************** > 394128 2020-07-09 1% *************************************** > 361806 2020-07-10 1% ************************************ > 280085 2020-07-11 1% **************************** > 286048 2020-07-12 1% **************************** > 345781 2020-07-13 1% ********************************** > 288702 2020-07-14 1% ***************************** > 309233 2020-07-15 1% ******************************* > 535266 2020-07-16 2% ***********************************************= ******* > 352427 2020-07-17 1% *********************************** > 242841 2020-07-18 1% ************************ > 387772 2020-07-19 1% *************************************** > 517604 2020-07-20 2% ***********************************************= ***** > 488514 2020-07-21 2% ***********************************************= ** > 388045 2020-07-22 1% *************************************** > 311588 2020-07-23 1% ******************************* > 317076 2020-07-24 1% ******************************* > 211095 2020-07-25 0% ********************* > 283776 2020-07-26 1% **************************** > 334426 2020-07-27 1% ********************************* > 328170 2020-07-28 1% ********************************* > 340508 2020-07-29 1% ********************************** > 315105 2020-07-30 1% ******************************* > 229031 2020-07-31 1% *********************** > 159211 2020-08-01 0% **************** > 220397 2020-08-02 0% ********************** > 316824 2020-08-03 1% ******************************* > 313566 2020-08-04 1% ******************************* > 310807 2020-08-05 1% ******************************* > 331097 2020-08-06 1% ********************************* > 279409 2020-08-07 1% **************************** > 165472 2020-08-08 0% **************** > 172664 2020-08-09 0% ***************** > 287621 2020-08-10 1% ***************************** > 295719 2020-08-11 1% ***************************** > 294523 2020-08-12 1% ***************************** > 307640 2020-08-13 1% ******************************* > 416059 2020-08-14 1% ***************************************** > 280695 2020-08-15 1% **************************** > 263146 2020-08-16 1% ************************** > 333133 2020-08-17 1% ********************************* > 442889 2020-08-18 1% ******************************************** > 478904 2020-08-19 2% ***********************************************= * > 435493 2020-08-20 1% ******************************************* > 344104 2020-08-21 1% ********************************** > 280130 2020-08-22 1% **************************** > 289216 2020-08-23 1% ***************************** > 327903 2020-08-24 1% ********************************* > 126506 2020-08-25 0% ************ >=20 > 306076.2 Average 1% =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 22343564 Total =20 > 126506 Minimum =20 > 535266 Maximum =20 >=20 >=20 > apache-id-draft.hits > 49253 2020-06-14 1% *************** > 55167 2020-06-15 1% ***************** > 50603 2020-06-16 1% **************** > 46365 2020-06-17 1% ************** > 35022 2020-06-18 0% *********** > 36849 2020-06-19 1% *********** > 26434 2020-06-20 0% ******** > 50503 2020-06-21 1% **************** > 39440 2020-06-22 1% ************ > 36768 2020-06-23 1% *********** > 35647 2020-06-24 1% *********** > 40646 2020-06-25 1% ************ > 38485 2020-06-26 1% ************ > 29214 2020-06-27 0% ********* > 39570 2020-06-28 1% ************ > 41089 2020-06-29 1% ************* > 33619 2020-06-30 0% ********** > 38919 2020-07-01 1% ************ > 65630 2020-07-02 1% ******************** > 54483 2020-07-03 1% ***************** > 39213 2020-07-04 1% ************ > 57434 2020-07-05 1% ****************** > 49707 2020-07-06 1% *************** > 52609 2020-07-07 1% **************** > 57386 2020-07-08 1% ****************** > 49086 2020-07-09 1% *************** > 62601 2020-07-10 1% ******************* > 158713 2020-07-11 4% ***********************************************= *** > 105169 2020-07-12 3% ********************************* > 169578 2020-07-13 4% ***********************************************= ******* > 47409 2020-07-14 1% *************** > 46682 2020-07-15 1% ************** > 49097 2020-07-16 1% *************** > 47495 2020-07-17 1% *************** > 32693 2020-07-18 0% ********** > 47718 2020-07-19 1% *************** > 42470 2020-07-20 1% ************* > 36461 2020-07-21 1% *********** > 37586 2020-07-22 1% *********** > 34639 2020-07-23 0% *********** > 31298 2020-07-24 0% ********* > 28626 2020-07-25 0% ********* > 47178 2020-07-26 1% *************** > 37545 2020-07-27 1% *********** > 36335 2020-07-28 1% *********** > 43743 2020-07-29 1% ************* > 38596 2020-07-30 1% ************ > 35525 2020-07-31 1% *********** > 36294 2020-08-01 1% *********** > 68482 2020-08-02 1% ********************* > 53792 2020-08-03 1% ***************** > 52330 2020-08-04 1% **************** > 50216 2020-08-05 1% *************** > 53453 2020-08-06 1% ***************** > 43428 2020-08-07 1% ************* > 47594 2020-08-08 1% *************** > 65591 2020-08-09 1% ******************** > 49202 2020-08-10 1% *************** > 44368 2020-08-11 1% ************** > 43565 2020-08-12 1% ************* > 43954 2020-08-13 1% ************* > 42661 2020-08-14 1% ************* > 42860 2020-08-15 1% ************* > 63403 2020-08-16 1% ******************** > 49925 2020-08-17 1% *************** > 41924 2020-08-18 1% ************* > 45676 2020-08-19 1% ************** > 42967 2020-08-20 1% ************* > 35859 2020-08-21 1% *********** > 29273 2020-08-22 0% ********* > 41134 2020-08-23 1% ************* > 33938 2020-08-24 0% ********** > 14070 2020-08-25 0% **** >=20 > 47976.1 Average 1% =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 3502257 Total =20 > 14070 Minimum =20 > 169578 Maximum =20 >=20 >=20 > apache-rfc-rfc.hits > 5689 2020-06-14 0% **************** > 7496 2020-06-15 1% ********************* > 6072 2020-06-16 0% ***************** > 7809 2020-06-17 1% ********************** > 8344 2020-06-18 1% ************************ > 5607 2020-06-19 0% **************** > 6158 2020-06-20 0% ***************** > 8768 2020-06-21 1% ************************* > 6436 2020-06-22 1% ****************** > 10604 2020-06-23 1% ****************************** > 6253 2020-06-24 0% ****************** > 9404 2020-06-25 1% *************************** > 7029 2020-06-26 1% ******************** > 6340 2020-06-27 0% ****************** > 6685 2020-06-28 1% ******************* > 18446 2020-06-29 2% ***********************************************= ****** > 6903 2020-06-30 1% ******************* > 7748 2020-07-01 1% ********************** > 9239 2020-07-02 1% ************************** > 10152 2020-07-03 1% ***************************** > 6783 2020-07-04 1% ******************* > 6220 2020-07-05 0% ****************** > 9874 2020-07-06 1% **************************** > 15519 2020-07-07 2% ******************************************** > 8622 2020-07-08 1% ************************ > 9060 2020-07-09 1% ************************** > 9293 2020-07-10 1% ************************** > 9300 2020-07-11 1% ************************** > 7486 2020-07-12 1% ********************* > 9554 2020-07-13 1% *************************** > 9725 2020-07-14 1% **************************** > 7622 2020-07-15 1% ********************** > 7774 2020-07-16 1% ********************** > 7787 2020-07-17 1% ********************** > 6762 2020-07-18 1% ******************* > 7617 2020-07-19 1% ********************** > 8770 2020-07-20 1% ************************* > 11967 2020-07-21 1% ********************************** > 7177 2020-07-22 1% ******************** > 6735 2020-07-23 1% ******************* > 11814 2020-07-24 1% ********************************** > 5953 2020-07-25 0% ***************** > 9505 2020-07-26 1% *************************** > 8357 2020-07-27 1% ************************ > 13692 2020-07-28 2% *************************************** > 9109 2020-07-29 1% ************************** > 6942 2020-07-30 1% ******************** > 15018 2020-07-31 2% ******************************************* > 7288 2020-08-01 1% ********************* > 10365 2020-08-02 1% ****************************** > 11136 2020-08-03 1% ******************************** > 10579 2020-08-04 1% ****************************** > 11461 2020-08-05 1% ********************************* > 15231 2020-08-06 2% ******************************************** > 9138 2020-08-07 1% ************************** > 10778 2020-08-08 1% ******************************* > 6635 2020-08-09 1% ******************* > 7065 2020-08-10 1% ******************** > 7351 2020-08-11 1% ********************* > 18640 2020-08-12 2% ***********************************************= ******* > 8030 2020-08-13 1% *********************** > 7939 2020-08-14 1% ********************** > 7211 2020-08-15 1% ******************** > 6818 2020-08-16 1% ******************* > 7713 2020-08-17 1% ********************** > 8318 2020-08-18 1% ************************ > 9671 2020-08-19 1% **************************** > 8971 2020-08-20 1% ************************* > 6335 2020-08-21 0% ****************** > 5289 2020-08-22 0% *************** > 7672 2020-08-23 1% ********************** > 8450 2020-08-24 1% ************************ > 5342 2020-08-25 0% *************** >=20 > 8748.6 Average 1% =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > 638645 Total =20 > 5289 Minimum =20 > 18640 Maximum =20 >=20 --8EinoA1AVW74WXaIMKrfmbVgW7a2M4r7h-- --MWHC9qVxL7IAG2afu6g10R9ACM4XKQemu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9Q8RYACgkQTptXS4+7 Fxp2/RAAzSsAehZANBLM3Y4bJvOKUPHtXxEyWRRvSaB74JqdiL+9WvUiLx6wnv1q luaHPrAM1Mvj5ipjXTlGeAgkpnwVDQsIuVjgmUQU80WNd7bCuKoDp1MhHW89zqdP qRxWQyIvbTbn/wehu6MiIaI/mx0I71dzoTC6PgwJ8JuAS2s9eQNr9auBNbQS1c03 QhHchh17iWE6/332UrcvqZsCivPt8J4fsiKB8mD+VaOWHEwbyMnhHLVwaA0sC0Lq qczPCCU45ZujZThBlwxxXRtR9efj9+Vj1bj5CJ+sXAL6G/uWyugkyzudHWc28sUH J1Zxj2/bVa09AzYIqpFqhXq6xN8oNQSDna3+apI93gWMjRE/FlJY5mYTzSxTaq6K 3SrCpGW5uLJdnmAAbYTsJ9UPP1bl0A9jrbd5AwmOFwLxufyImJmpX5ed1aBeBbxA ulSjQo0a5cJHFYxdPvhvuTouR5Z9lylAwKTjxF2pIkXGhfgizm7QPRFPBqwKgHH5 NM5aHc69XMpsUpzqA6pv7lQCjCvLCcZVupB1QciqnFzKlE02hVjYatC1lMEHjdyF 3Uh7fZhXjf6rA9pqPNE7tEz86Y/Llbjg/bhAVAlk/4H6VQ+p33cHAh4Uhiy44Sp1 G1Jsx7w7IpwvGOv8z+Pl6sAoiP5HzgkiWC1BqxDJrxcpTy1R+Mc= =aqM6 -----END PGP SIGNATURE----- --MWHC9qVxL7IAG2afu6g10R9ACM4XKQemu-- From nobody Wed Sep 9 08:37:38 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74AB3A0D3A for ; Wed, 9 Sep 2020 08:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 CCJzKGfFMiV8 for ; Wed, 9 Sep 2020 08:37:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A62FE3A0E8E for ; Wed, 9 Sep 2020 08:37:33 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 089FbVP8019258 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 9 Sep 2020 10:37:32 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599665852; bh=72ukPnSvtz5Sbwz0KLeV4LROY/JNXc8BrFIs9oqU8ik=; h=To:From:Subject:Date; b=XQYtHn3MrL0P7J4Qoz20hmfdTzXNn+O3uCOKGjryMxW4EsrTSnrdxqQ9RKUR5KOjs SyUnZggdBqSbrc8dfZYZnfPPZovhEtJEVZoYxp8B6BAHf/noWYF0ootwQy+oikVreZ 93tzwZwX7afNuvluGTfVyU03xonyeVZnFItaXIBM= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: "tools-implementation@ietf.org" From: Robert Sparks Message-ID: <7ac14729-a756-594e-6eb4-befef94223bc@nostrum.com> Date: Wed, 9 Sep 2020 10:37:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Tools-implementation] Reminder: Call On Tue 15 Sep X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 15:37:37 -0000 I will put together an agenda later today or during the day tomorrow, but at a very high level, the focus will be continuing the conversation about understanding the files needed by the services we provide. I'd like to push further on the notion of what we can put into an "attic", "museum" or other space that has the connotation that this is not something a service is using and is not expected to change. Separately we should talk about how that set of bits should be exposed. From nobody Wed Sep 9 09:21:11 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8413A0522 for ; Wed, 9 Sep 2020 09:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 2tT3emCnrDwv for ; Wed, 9 Sep 2020 09:21:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 345A33A0476 for ; Wed, 9 Sep 2020 09:21:05 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 089GL301034120 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 9 Sep 2020 11:21:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599668464; bh=zO8vwNz5/Y4KgGYs12JcRF56/IH0YGxM7ywrSKOGiQI=; h=To:From:Subject:Date; b=mmfbPTjHv1XeS7E/xtFpQ2Bu15USzXjRfcEnzyT5gy6O1y+Ko3jkxcr9tVeSWKywz IfYXY//k0yUeaGnKJzcsbuFtAdNQlpDnkcIwKb9S9OS59JqD3WAUktAstDNhF4It9h O8qwYpYCSoPXrd7zXgc9RqkHmFJb7ZEtDRizkYOo= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: "tools-implementation@ietf.org" From: Robert Sparks Message-ID: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> Date: Wed, 9 Sep 2020 11:21:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 16:21:09 -0000 A few weeks ago, shortly after the yc.o team's work managed to crash the host they were working on through changing settings in a container, I proposed that we unroll the things we currently have in containers on production. At the time, Glen suggested we not do that. I'd like to ask the question again - I think we may have more to consider. 1. I remain uneasy about docker's implementation on OpenSuse. The container crash above, the issues we've run into with containers locking (and sometimes causing processes talking to them like apache) to hang are suspicious. That we've not been able to pin down what's really going on suggests to me the issue is in a place we can't really look, inside docker's interstitial networking or filesystem abstraction code perhaps. 2. Many of the containers we have (and in particular the one for the website) really need to be designed differently if they are going to remain deployed as containers. The amount of file-system mapping they do is not what the docker architects expect as a normal use-case. Mapping sockets in the way we do is also likely not something they focus on testing. 3. Docker is making Glen uncomfortable and the benefit for him (operationally) of the containerization is not proportional to the extra problems it is bringing. So I again suggest that we unroll for the production deploys, at least for now. I think we can unroll everything at this point, but there might still be a hitch in unrolling the trac instances. Henrik - could you remind me what our thinking was with respect to those? I do plan to keep up the pressure to have containerized versions of these services - this isn't a call to abandon Docker - but I suggest we need to change how we're currently using it. RjS From nobody Wed Sep 9 10:52:00 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117B13A0BDC for ; Wed, 9 Sep 2020 10:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.858 X-Spam-Level: X-Spam-Status: No, score=-102.858 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 gPEkiIQgR2Sd for ; Wed, 9 Sep 2020 10:51:49 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C6E3A0C47 for ; Wed, 9 Sep 2020 10:51:49 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 23B7E3C13D4 for ; Wed, 9 Sep 2020 10:51:28 -0700 (PDT) Received: from [192.168.86.10] (173-8-133-94-SFBA.hfc.comcastbusiness.net [173.8.133.94]) by c8a.amsl.com (Postfix) with ESMTPSA id EE2FF3C13D3 for ; Wed, 9 Sep 2020 10:51:27 -0700 (PDT) To: tools-implementation@ietf.org References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> From: Glen Organization: AMS Message-ID: <49b0f12f-48a8-f810-2570-1d7f4c4b6342@amsl.com> Date: Wed, 9 Sep 2020 10:51:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.1 MIME-Version: 1.0 In-Reply-To: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 17:51:59 -0000 My full support and agreement here. To clarify: I suggested *not* doing it only because I didn't want to be the cause of heartburn or the loud voice whining. :-) But these arguments are persuasive, and I agree with everything said here, both in terms of present *and* future planning. Glen On 9/9/2020 09:21, Robert Sparks wrote: > A few weeks ago, shortly after the yc.o team's work managed to crash the > host they were working on through changing settings in a container, I > proposed that we unroll the things we currently have in containers on > production. At the time, Glen suggested we not do that. I'd like to ask > the question again - I think we may have more to consider. > > 1. I remain uneasy about docker's implementation on OpenSuse. The > container crash above, the issues we've run into with containers locking > (and sometimes causing processes talking to them like apache) to hang > are suspicious. That we've not been able to pin down what's really going > on suggests to me the issue is in a place we can't really look, inside > docker's interstitial networking or filesystem abstraction code perhaps. > > 2. Many of the containers we have (and in particular the one for the > website) really need to be designed differently if they are going to > remain deployed as containers. The amount of file-system mapping they do > is not what the docker architects expect as a normal use-case. Mapping > sockets in the way we do is also likely not something they focus on > testing. > > 3. Docker is making Glen uncomfortable and the benefit for him > (operationally) of the containerization is not proportional to the extra > problems it is bringing. > > So I again suggest that we unroll for the production deploys, at least > for now. I think we can unroll everything at this point, but there might > still be a hitch in unrolling the trac instances. Henrik - could you > remind me what our thinking was with respect to those? > > I do plan to keep up the pressure to have containerized versions of > these services - this isn't a call to abandon Docker - but I suggest we > need to change how we're currently using it. > > RjS > > From nobody Wed Sep 9 10:56:09 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DA83A0BF3 for ; Wed, 9 Sep 2020 10:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hsnXukvMNf-o for ; Wed, 9 Sep 2020 10:56:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6DA3A0BED for ; Wed, 9 Sep 2020 10:56:06 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:60882 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kG4KD-0005uM-Bt; Wed, 09 Sep 2020 10:56:05 -0700 To: Robert Sparks , "tools-implementation@ietf.org" References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> From: Henrik Levkowetz Message-ID: <55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com> Date: Wed, 9 Sep 2020 19:55:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BKVq4CstLWpBSrgC41ef1WGSfnxKMrRNq" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: tools-implementation@ietf.org, rjsparks@nostrum.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 17:56:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BKVq4CstLWpBSrgC41ef1WGSfnxKMrRNq Content-Type: multipart/mixed; boundary="kBLGjvumLIsBDXGlbeqCcmoncKVdj3DI6"; protected-headers="v1" From: Henrik Levkowetz To: Robert Sparks , "tools-implementation@ietf.org" Message-ID: <55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com> Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do. References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> In-Reply-To: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> --kBLGjvumLIsBDXGlbeqCcmoncKVdj3DI6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Robert, On 2020-09-09 18:21, Robert Sparks wrote: > So I again suggest that we unroll for the production deploys, at least = > for now. I think we can unroll everything at this point, but there migh= t=20 > still be a hitch in unrolling the trac instances. Henrik - could you=20 > remind me what our thinking was with respect to those? Since we're now running apache with a python 3.6 mod_wsgi, we cannot run Trac under mod_wsgi until it's available for Python 3. (There's progress= , but it's not there yet). Which means moving it to nginx if we're not goi= ng to use Docker. Henrik --kBLGjvumLIsBDXGlbeqCcmoncKVdj3DI6-- --BKVq4CstLWpBSrgC41ef1WGSfnxKMrRNq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9ZFy4ACgkQTptXS4+7 Fxps0g/+PubovxO+fAAld+wmU78QBzYBU+fUMbtaiGghQ81dtNiHeQGFkRZCJV0K q0lxIxg7OjVUsVX0+pK/TeRi92grLGmJFttxhkzl1X+GKUCRPITqr/OFJmSicrUh LJtk5GfJCyaltocuErmYtYYrHBuLT/3ABvVTC+Fg1h4G5kzeLb1kzv4uQ1EKA1g+ lVG+ZOmQl9JLeldmow3KgWmaBBJwV+jpobLPNtGCCO7KD33UpRX+cfceO0osSFlB RgzgT8PnIINxynhuNs73kavyrQJOOJ01CWG4CltSP6oUwz3uoW983lwBrVNtVofb kwTKSYpT5N8RJ2o+BfEtgutjud/5jlI9czkjiawNUGb3bUPtUjyTtP/XN834FzYq xiP8HD/Km40o74tKyAjOf4KsgHio8t8XrHxj5KXtjdwj1U0liFMCI3eXKv3G4qfH +F2Bk6wguuYCDAFDy0NowmH99n5tnY5+ohq2i8Vyi1lHu2nA8ZIS3U3qyoYzYhQC 7Cw2TThb057q5SFbnUlzWutdH8bkLZRACyNgO1v64EzbyqfXr9EYVeoENATD5Db1 9g2rpCVu3mXF6/Dz3e3E8l4rwBsqUMlrOR9xVULpTQQNxSWH7Y996Sry9ky2UOCA HcApe16fiCmTcd8GXZCrTT1WctS7iYMSOp3vHVs+b5/9h6l2vnE= =KJ1Q -----END PGP SIGNATURE----- --BKVq4CstLWpBSrgC41ef1WGSfnxKMrRNq-- From nobody Wed Sep 9 11:08:09 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F623A0B85 for ; Wed, 9 Sep 2020 11:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 awmvlkXGVtKt for ; Wed, 9 Sep 2020 11:08:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1FCC43A0AA7 for ; Wed, 9 Sep 2020 11:08:06 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 089I83KV070584 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 9 Sep 2020 13:08:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599674884; bh=gxZeyDLMdtwkHVCNDh1gizGMKf0ZwSNI9Dg1Et6TRTU=; h=Subject:To:References:From:Date:In-Reply-To; b=RPLM3JVl4R7GrhwL0dBPRa+eXAz19zPQZ1m2uV1Rdva/66/1ktrB4Dxp79p17jJXX lnGFVN2Rrthzh5Ck5meYY/fW8QK4Hw8Ubn1NwV+1cFDTD8LHU/3qhKIVshCjAvRpKg XCUcG9BWFgG0Qhe5/eWc0yVR7rugjdUfL9Qj18A0= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Henrik Levkowetz , "tools-implementation@ietf.org" References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> <55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com> From: Robert Sparks Message-ID: <1c0ac174-c75d-4af5-f54a-3419b854d189@nostrum.com> Date: Wed, 9 Sep 2020 13:08:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 18:08:07 -0000 On 9/9/20 12:55 PM, Henrik Levkowetz wrote: > Hi Robert, > > On 2020-09-09 18:21, Robert Sparks wrote: > >> So I again suggest that we unroll for the production deploys, at least >> for now. I think we can unroll everything at this point, but there might >> still be a hitch in unrolling the trac instances. Henrik - could you >> remind me what our thinking was with respect to those? > Since we're now running apache with a python 3.6 mod_wsgi, we cannot run > Trac under mod_wsgi until it's available for Python 3. (There's progress, > but it's not there yet). Which means moving it to nginx if we're not going > to use Docker. Glen mentioned possibly using mod_wsgi-express to run a separate apache instance that loaded the 2.7 module rather than the 3.6 module? > > > Henrik > From nobody Wed Sep 9 11:29:07 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CE83A0C30 for ; Wed, 9 Sep 2020 11:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Hc_9jhv9W-or for ; Wed, 9 Sep 2020 11:29:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C883A0C28 for ; Wed, 9 Sep 2020 11:29:05 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:61221 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kG4q8-0007sS-8P; Wed, 09 Sep 2020 11:29:04 -0700 To: Robert Sparks , "tools-implementation@ietf.org" References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> <55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com> <1c0ac174-c75d-4af5-f54a-3419b854d189@nostrum.com> From: Henrik Levkowetz Message-ID: <972828d1-6a92-7217-b216-db52ec651bcb@levkowetz.com> Date: Wed, 9 Sep 2020 20:28:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1c0ac174-c75d-4af5-f54a-3419b854d189@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GlMumqoI92bdPNL0wTQOjCNpTritjcsog" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: tools-implementation@ietf.org, rjsparks@nostrum.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 18:29:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GlMumqoI92bdPNL0wTQOjCNpTritjcsog Content-Type: multipart/mixed; boundary="mkoFKssQFQmOuak95fwxM7pUT1tbcXwQ6"; protected-headers="v1" From: Henrik Levkowetz To: Robert Sparks , "tools-implementation@ietf.org" Message-ID: <972828d1-6a92-7217-b216-db52ec651bcb@levkowetz.com> Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do. References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> <55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com> <1c0ac174-c75d-4af5-f54a-3419b854d189@nostrum.com> In-Reply-To: <1c0ac174-c75d-4af5-f54a-3419b854d189@nostrum.com> --mkoFKssQFQmOuak95fwxM7pUT1tbcXwQ6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-09-09 20:08, Robert Sparks wrote: >=20 > On 9/9/20 12:55 PM, Henrik Levkowetz wrote: >> Hi Robert, >> >> On 2020-09-09 18:21, Robert Sparks wrote: >> >>> So I again suggest that we unroll for the production deploys, at leas= t >>> for now. I think we can unroll everything at this point, but there mi= ght >>> still be a hitch in unrolling the trac instances. Henrik - could you >>> remind me what our thinking was with respect to those? >> Since we're now running apache with a python 3.6 mod_wsgi, we cannot r= un >> Trac under mod_wsgi until it's available for Python 3. (There's progr= ess, >> but it's not there yet). Which means moving it to nginx if we're not = going >> to use Docker. > Glen mentioned possibly using mod_wsgi-express to run a separate apache= =20 > instance that loaded the 2.7 module rather than the 3.6 module? I don't think you can run 2 Apache instances with different mod_wsgi modu= les without containerizing one of them? Henrik --mkoFKssQFQmOuak95fwxM7pUT1tbcXwQ6-- --GlMumqoI92bdPNL0wTQOjCNpTritjcsog Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9ZHukACgkQTptXS4+7 FxpGaQ/5AZGhYiGADu70BlQtArvbbnqEJgSmI65Ad1rQBQ3TzPZfWCN4BD9/I5Kx pKSyQhEtdqSiozlZOlinpktKun06ilVtYEfX6r6J/PmLh5HGpfc3qWsk9WcDSg31 LSAZcvJqJLH3N6e9IVELNydzj+8Sk5m/gyd1nBONZXuP4xHMQ/YHiXn2xwJ2pdnr 2YgIudob1HWtrDifuzfqbOZT/cF5qtDETnIeMcr554Aj15vjiVdeP+zF520q9Dog dfnJ06drVABNqf5JzcU6FNGJiruBdGIxwaKpxeo7D/0HeBI2bH9mUhAPe7600a0X W1a5yslXhacFfVgyyJQHlngoE0KNjy5E/e/cRsaRzlLVYJTZ8ZjhFkzHo9RzH/V6 GdOYx6Zx8N022ZIe71E1vtdrbYEXYWOLXtKsMY/CNOoZ/PXQTp2D4khW5xluXrtw eAmeI0aKJ14pZXK9DkkA1G2X4LlPnURUlpb25J8Hc0OhyRJcBM1oSJ9c8i6Azdlo M+Bw10rHPZQX/RirIsc5OQQHMMGRSRjTFv+L/VJ6n2IKLCuqOuBSN5IjgbZKmSwv Po5SeAfqPbOrm+3s9wLRn4dHtO5Ix41HtX5CfZNm3YiW52IdN6hcDCiLRqoSU2FJ fSUmDpBZNE1dzEfbqk4qeQesj3NjIYZTz2PO0KX04K6b4wOTRww= =+kUv -----END PGP SIGNATURE----- --GlMumqoI92bdPNL0wTQOjCNpTritjcsog-- From nobody Wed Sep 9 13:02:25 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CF13A0D54 for ; Wed, 9 Sep 2020 13:02:22 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OCiA77N5AmYx for ; Wed, 9 Sep 2020 13:02:20 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43383A0B41 for ; Wed, 9 Sep 2020 13:02:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6D7C6300B70 for ; Wed, 9 Sep 2020 16:02:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AO-IjC7ZtYpb for ; Wed, 9 Sep 2020 16:02:16 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 557A9300435; Wed, 9 Sep 2020 16:02:16 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EFDD6B93-6631-4491-9656-824ECF59CC91" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Wed, 9 Sep 2020 16:02:17 -0400 In-Reply-To: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> Cc: "tools-implementation@ietf.org" To: Robert Sparks References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 20:02:23 -0000 --Apple-Mail=_EFDD6B93-6631-4491-9656-824ECF59CC91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One of the reasons that we went to containers was to isolate some = python2 from python3. Will we just use virtual environment for that? Russ > On Sep 9, 2020, at 12:21 PM, Robert Sparks = wrote: >=20 > A few weeks ago, shortly after the yc.o team's work managed to crash = the host they were working on through changing settings in a container, = I proposed that we unroll the things we currently have in containers on = production. At the time, Glen suggested we not do that. I'd like to ask = the question again - I think we may have more to consider. >=20 > 1. I remain uneasy about docker's implementation on OpenSuse. The = container crash above, the issues we've run into with containers locking = (and sometimes causing processes talking to them like apache) to hang = are suspicious. That we've not been able to pin down what's really going = on suggests to me the issue is in a place we can't really look, inside = docker's interstitial networking or filesystem abstraction code perhaps. >=20 > 2. Many of the containers we have (and in particular the one for the = website) really need to be designed differently if they are going to = remain deployed as containers. The amount of file-system mapping they do = is not what the docker architects expect as a normal use-case. Mapping = sockets in the way we do is also likely not something they focus on = testing. >=20 > 3. Docker is making Glen uncomfortable and the benefit for him = (operationally) of the containerization is not proportional to the extra = problems it is bringing. >=20 > So I again suggest that we unroll for the production deploys, at least = for now. I think we can unroll everything at this point, but there might = still be a hitch in unrolling the trac instances. Henrik - could you = remind me what our thinking was with respect to those? >=20 > I do plan to keep up the pressure to have containerized versions of = these services - this isn't a call to abandon Docker - but I suggest we = need to change how we're currently using it. >=20 > RjS >=20 >=20 > --=20 > Tools-implementation mailing list > Tools-implementation@ietf.org > https://www.ietf.org/mailman/listinfo/tools-implementation --Apple-Mail=_EFDD6B93-6631-4491-9656-824ECF59CC91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
One of the reasons that = we went to containers was to isolate some python2 from python3. =  Will we just use virtual environment for = that?

Russ

On Sep = 9, 2020, at 12:21 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

A = few weeks ago, shortly after the yc.o team's work managed to crash the = host they were working on through changing settings in a container, I = proposed that we unroll the things we currently have in containers on = production. At the time, Glen suggested we not do that. I'd like to ask = the question again - I think we may have more to consider.

1. I remain uneasy about docker's = implementation on OpenSuse. The container crash above, the issues we've = run into with containers locking (and sometimes causing processes = talking to them like apache) to hang are suspicious. That we've not been = able to pin down what's really going on suggests to me the issue is in a = place we can't really look, inside docker's interstitial networking or = filesystem abstraction code perhaps.

2. = Many of the containers we have (and in particular the one for the = website) really need to be designed differently if they are going to = remain deployed as containers. The amount of file-system mapping they do = is not what the docker architects expect as a normal use-case. Mapping = sockets in the way we do is also likely not something they focus on = testing.

3. Docker is making Glen = uncomfortable and the benefit for him (operationally) of the = containerization is not proportional to the extra problems it is = bringing.

So I again suggest that we unroll = for the production deploys, at least for now. I think we can unroll = everything at this point, but there might still be a hitch in unrolling = the trac instances. Henrik - could you remind me what our thinking was = with respect to those?

I do plan to keep up = the pressure to have containerized versions of these services - this = isn't a call to abandon Docker - but I suggest we need to change how = we're currently using it.

RjS


--
Tools-implementation mailing list
Tools-implementation@ietf.org
https://www.ietf.org/mailman/listinfo/tools-implementation

= --Apple-Mail=_EFDD6B93-6631-4491-9656-824ECF59CC91-- From nobody Wed Sep 9 13:04:25 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBEC3A0D58 for ; Wed, 9 Sep 2020 13:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.026 X-Spam-Level: X-Spam-Status: No, score=-3.026 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 AfWjOD5mVXVX for ; Wed, 9 Sep 2020 13:04:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6D9A13A0B15 for ; Wed, 9 Sep 2020 13:04:22 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 089K4KQW010282 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 9 Sep 2020 15:04:21 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599681861; bh=drl+fQqJ/PhdriTc3sL9BY1dCqhrHnVFg22hSiLobVo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=aiajo5AGaRHwONOoujd6r96Yab5r0ME21wZw1IHUlQblXpbwN9levRTB/Dp1XX5w8 B2oIck2MzvBSnskkGGhKhzxxZ2tIpYYIPvcXoniLfGwqvjO1w9OpzaOZP7wt0thrAF DK+CpW8RipKkiNYGtXZZA/bj91CHL+thiTlO2n+E= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Russ Housley Cc: "tools-implementation@ietf.org" References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> From: Robert Sparks Message-ID: <280055fe-c8e4-669f-9df1-22ab032d828d@nostrum.com> Date: Wed, 9 Sep 2020 15:04:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------10D8EF02AF537B53B264FF10" Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 20:04:24 -0000 This is a multi-part message in MIME format. --------------10D8EF02AF537B53B264FF10 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 9/9/20 3:02 PM, Russ Housley wrote: > One of the reasons that we went to containers was to isolate some > python2 from python3.  Will we just use virtual environment for that? That's the essence of the question below about trac. Trac may need to remain in a container, or move to a separate vm, or something, though we're continuing looking closely at whether we can avoid either. > > Russ > >> On Sep 9, 2020, at 12:21 PM, Robert Sparks > > wrote: >> >> A few weeks ago, shortly after the yc.o team's work managed to crash >> the host they were working on through changing settings in a >> container, I proposed that we unroll the things we currently have in >> containers on production. At the time, Glen suggested we not do that. >> I'd like to ask the question again - I think we may have more to >> consider. >> >> 1. I remain uneasy about docker's implementation on OpenSuse. The >> container crash above, the issues we've run into with containers >> locking (and sometimes causing processes talking to them like apache) >> to hang are suspicious. That we've not been able to pin down what's >> really going on suggests to me the issue is in a place we can't >> really look, inside docker's interstitial networking or filesystem >> abstraction code perhaps. >> >> 2. Many of the containers we have (and in particular the one for the >> website) really need to be designed differently if they are going to >> remain deployed as containers. The amount of file-system mapping they >> do is not what the docker architects expect as a normal use-case. >> Mapping sockets in the way we do is also likely not something they >> focus on testing. >> >> 3. Docker is making Glen uncomfortable and the benefit for him >> (operationally) of the containerization is not proportional to the >> extra problems it is bringing. >> >> So I again suggest that we unroll for the production deploys, at >> least for now. I think we can unroll everything at this point, but >> there might still be a hitch in unrolling the trac instances. Henrik >> - could you remind me what our thinking was with respect to those? >> >> I do plan to keep up the pressure to have containerized versions of >> these services - this isn't a call to abandon Docker - but I suggest >> we need to change how we're currently using it. >> >> RjS >> >> >> -- >> Tools-implementation mailing list >> Tools-implementation@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-implementation > --------------10D8EF02AF537B53B264FF10 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit


On 9/9/20 3:02 PM, Russ Housley wrote:
One of the reasons that we went to containers was to isolate some python2 from python3.  Will we just use virtual environment for that?

That's the essence of the question below about trac. Trac may need to remain in a container, or move to a separate vm, or something, though we're continuing looking closely at whether we can avoid either.


Russ

On Sep 9, 2020, at 12:21 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

A few weeks ago, shortly after the yc.o team's work managed to crash the host they were working on through changing settings in a container, I proposed that we unroll the things we currently have in containers on production. At the time, Glen suggested we not do that. I'd like to ask the question again - I think we may have more to consider.

1. I remain uneasy about docker's implementation on OpenSuse. The container crash above, the issues we've run into with containers locking (and sometimes causing processes talking to them like apache) to hang are suspicious. That we've not been able to pin down what's really going on suggests to me the issue is in a place we can't really look, inside docker's interstitial networking or filesystem abstraction code perhaps.

2. Many of the containers we have (and in particular the one for the website) really need to be designed differently if they are going to remain deployed as containers. The amount of file-system mapping they do is not what the docker architects expect as a normal use-case. Mapping sockets in the way we do is also likely not something they focus on testing.

3. Docker is making Glen uncomfortable and the benefit for him (operationally) of the containerization is not proportional to the extra problems it is bringing.

So I again suggest that we unroll for the production deploys, at least for now. I think we can unroll everything at this point, but there might still be a hitch in unrolling the trac instances. Henrik - could you remind me what our thinking was with respect to those?

I do plan to keep up the pressure to have containerized versions of these services - this isn't a call to abandon Docker - but I suggest we need to change how we're currently using it.

RjS


--
Tools-implementation mailing list
Tools-implementation@ietf.org
https://www.ietf.org/mailman/listinfo/tools-implementation

--------------10D8EF02AF537B53B264FF10-- From nobody Thu Sep 10 11:52:03 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1233A0CE6 for ; Thu, 10 Sep 2020 11:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 XbB7nwmujvzb for ; Thu, 10 Sep 2020 11:52:00 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BA3D13A0C3D for ; Thu, 10 Sep 2020 11:52:00 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 08AIpwQk004232 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2020 13:52:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599763920; bh=lkbgWECUU3Q1A3baTl3gLECKPAm6FE00CDqiZE9JxSs=; h=To:From:Subject:Date; b=UDzVCHZzL5mf87gm4RpAS5HVEusiH97WFZrhPS0ZPlLySE7TAMknmmOWHMdhoottE bGb3oqwHmrVasYdKDhkqwRImQ1Oi7W6fBCKCnhxeOSzZLO2kGhzBI2lxxbQcyK3OJj dIIYaFUjH+dJ/6R1y4wpMVyGo5+TtG+8JsZ9ku7U= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: "tools-implementation@ietf.org" From: Robert Sparks Message-ID: Date: Thu, 10 Sep 2020 13:51:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Tools-implementation] Agenda for next week X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 18:52:02 -0000 See, bash, and in particular add to, https://codimd.ietf.org/ti-2020-09# I haven't included the docker thread (as I think it's reaching closure online). But if someone does want to spend time on it during the call, do not hesitate to add it. RjS From nobody Tue Sep 15 09:58:55 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E753A138F for ; Tue, 15 Sep 2020 09:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 RULyjLMROeAG for ; Tue, 15 Sep 2020 09:58:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 90D4A3A1384 for ; Tue, 15 Sep 2020 09:58:51 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08FGwiTF089504 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 15 Sep 2020 11:58:47 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600189127; bh=o5X6xbyc3+JO3Z5cWechjqheG0b1wmH0HK8ARLyOIW4=; h=Subject:References:To:From:Date:In-Reply-To; b=sGtEJXPK9bCbRHd/o3VgxrzGTS9DBzt617JY5KZFCoQGfPD3x5n2xQrepRyBDKlkP Etn7/IdlMj4eEQGd7xUbjtT+OjcfTO7lJvRLCX9txMKebrjnoJADlJGVcEBgYEFf7w eqB+tuJcuO5cq56C7cm4gGsz985qTHbi1RfrPZvI= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local References: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> To: "tools-implementation@ietf.org" , ryan Cross From: Robert Sparks X-Forwarded-Message-Id: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> Message-ID: <7e213352-f0ba-6a84-0d26-1d2cb669f5f5@nostrum.com> Date: Tue, 15 Sep 2020 11:58:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> Content-Type: multipart/alternative; boundary="------------896B2D2FA8259A3DD3C4288E" Content-Language: en-US Archived-At: Subject: [Tools-implementation] Fwd: Organization of the mail archives X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 16:58:53 -0000 This is a multi-part message in MIME format. --------------896B2D2FA8259A3DD3C4288E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Continuing this in the context of today's conversation. After the cleanup described below, we are/will-be left with: /a/mailarch/data/archive as the _authoritative_ store. /a/mailarch/data/mbox_archive/public as an automatically generated set of mbox files generated from the authoritative store. Should we plan to move the first to be under /doc and the second to be under /derived? RjS -------- Forwarded Message -------- Subject: Organization of the mail archives Date: Tue, 1 Sep 2020 12:30:56 -0500 From: Robert Sparks To: Ryan Cross , tools-implementation@ietf.org After consulting with Ryan, I propose this disposition for the following email archive related directories: >> Legacy Mailarchive /a/ietf A few very old mail archive scripts This can simply be removed. The scripts are no longer used. >> Email Mailarchive /a/isode ISODE IMAP server data store >> Email Mailarchive /a/mailarch Mail Archive operations These should stay where they are. /a/mailarch/data/archive is the _authoritative_ store. /a/mailarch/data/mbox_archive/public is an automatically generated set of mbox files generated from the authoritative store. That should be used to replace several things below. >> Email Mailman /a/mailman Mailman operations That has to remain (though we should consider what to do with it when we bring in Mailman3 >> Email Mailman /a/mailman/archives Mailman Legacy Archives This has to remain - it is where mailman's internal archiving takes place - any lists using pipermail are kept here, so Legacy isn't really accurate above >> >> Email Postfix /a/postfix Postfix operations This remains >> FTP FTP/Website combined >> /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT >> exposed by http >> These have all been imported, and are served through the mailarchive. These should be stashed. I personally don't think we should serve them in any way since they are available through the mailarchive. If they are served, they should clearly be in something I'd like to start calling the "museum". > >> FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains >> text versions of mail archive ftp, rsync night-runner All web access >> is to the /a/www/ietf-mail-archive tree, which this is a copy of This should go away as soon as ftp stops depending on it (and we had another conversation about removing it already). >> Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive >> Email Mailarchive /a/www/ietf-mail-archive/text >> Email Mailarchive /a/www/ietf-mail-archive/text-secure >> Email Mailarchive /a/www/ietf-mail-archive/web >> Email Mailarchive /a/www/ietf-mail-archive/web-old >> Email Mailarchive /a/www/ietf-mail-archive/web-secure >> >> Again, has all of that been imported, and can all of this simply be >> removed (or stashed offline)? All of this should be stashed. Everything here, with the possible exception of things in web-old have been imported into mailarchive. Ryan is looking at making sure those get imported. Once that's done, all of these should either be taken offline or put in the museum. Are there any other puddles of email-archive related things that aren't in those directories? --------------896B2D2FA8259A3DD3C4288E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Continuing this in the context of today's conversation.

After the cleanup described below, we are/will-be left with:


/a/mailarch/data/archive as the _authoritative_ store.

/a/mailarch/data/mbox_archive/public as an automatically generated set of mbox files generated from the authoritative store.

Should we plan to move the first to be under /doc and the second to be under /derived?

RjS



-------- Forwarded Message --------
Subject: Organization of the mail archives
Date: Tue, 1 Sep 2020 12:30:56 -0500
From: Robert Sparks <rjsparks@nostrum.com>
To: Ryan Cross <rcross@amsl.com>, tools-implementation@ietf.org <tools-implementation@ietf.org>


After consulting with Ryan, I propose this disposition for the following email archive related directories:


Legacy Mailarchive /a/ietf A few very old mail archive scripts
This can simply be removed. The scripts are no longer used.
Email Mailarchive /a/isode ISODE IMAP server data store
Email Mailarchive /a/mailarch Mail Archive operations

These should stay where they are.

/a/mailarch/data/archive is the _authoritative_ store.

/a/mailarch/data/mbox_archive/public is an automatically generated set of mbox files generated from the authoritative store. That should be used to replace several things below.

Email Mailman /a/mailman Mailman operations
That has to remain (though we should consider what to do with it when we bring in Mailman3
Email Mailman /a/mailman/archives Mailman Legacy Archives
This has to remain - it is where mailman's internal archiving takes place - any lists using pipermail are kept here, so Legacy isn't really accurate above

Email Postfix /a/postfix Postfix operations
This remains
FTP FTP/Website combined /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT exposed by http

These have all been imported, and are served through the mailarchive. These should be stashed. I personally don't think we should serve them in any way since they are available through the mailarchive. If they are served, they should clearly be in something I'd like to start calling the "museum".

FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains text versions of mail archive ftp, rsync night-runner All web access is to the /a/www/ietf-mail-archive tree, which this is a copy of
This should go away as soon as ftp stops depending on it (and we had another conversation about removing it already).
Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive
Email Mailarchive /a/www/ietf-mail-archive/text
Email Mailarchive /a/www/ietf-mail-archive/text-secure
Email Mailarchive /a/www/ietf-mail-archive/web
Email Mailarchive /a/www/ietf-mail-archive/web-old
Email Mailarchive /a/www/ietf-mail-archive/web-secure

Again, has all of that been imported, and can all of this simply be removed (or stashed offline)?
All of this should be stashed. Everything here, with the possible exception of things in web-old have been imported into mailarchive. Ryan is looking at making sure those get imported. Once that's done, all of these should either be taken offline or put in the museum.

Are there any other puddles of email-archive related things that aren't in those directories?

--------------896B2D2FA8259A3DD3C4288E-- From nobody Tue Sep 15 10:59:22 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DDC3A1657 for ; Tue, 15 Sep 2020 10:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.911 X-Spam-Level: X-Spam-Status: No, score=-101.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 tu20zEehmw0R for ; Tue, 15 Sep 2020 10:59:12 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49743A160D for ; Tue, 15 Sep 2020 10:59:09 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 6CFEC3C2DFB; Tue, 15 Sep 2020 10:59:08 -0700 (PDT) Received: from [IPv6:2603:3024:15a1:78e0:c1b6:d7dd:a558:afbd] (unknown [IPv6:2603:3024:15a1:78e0:c1b6:d7dd:a558:afbd]) by c8a.amsl.com (Postfix) with ESMTPSA id 587F63C13CF; Tue, 15 Sep 2020 10:59:08 -0700 (PDT) To: tools-implementation@ietf.org References: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> <7e213352-f0ba-6a84-0d26-1d2cb669f5f5@nostrum.com> Cc: Ryan Cross From: Glen Organization: AMS Message-ID: <39e9687a-5fe6-195f-b6e2-61a435320fa7@amsl.com> Date: Tue, 15 Sep 2020 10:59:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <7e213352-f0ba-6a84-0d26-1d2cb669f5f5@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-implementation] Fwd: Organization of the mail archives X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 17:59:22 -0000 On 9/15/2020 09:58, Robert Sparks wrote: > Continuing this in the context of today's conversation. > After the cleanup described below, we are/will-be left with: > /a/mailarch/data/archive as the _authoritative_ store. > /a/mailarch/data/mbox_archive/public as an automatically generated set > of mbox files generated from the authoritative store. > Should we plan to move the first to be under /doc and the second to be > under /derived? > RjS No objection. I have a weak preference for leaving data which is only used by a single package in place under /a/packagename, because it will help us identify what things can be easily severed. However, I realize that the mailarch data is also accessed by the ISODE IMAP server, so the proposal to move them under /data and /derived seems correct. Glen From nobody Tue Sep 15 11:15:37 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2293E3A0D9B for ; Tue, 15 Sep 2020 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 jyfySBQ2n2AE for ; Tue, 15 Sep 2020 11:15:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 25CCA3A0D4E for ; Tue, 15 Sep 2020 11:15:34 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08FIFVgE016418 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2020 13:15:33 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600193733; bh=qdnpEwlSmBm+Y51QHvL3g1aFE5TpFRFZbWIbXiVG+zA=; h=To:From:Subject:Date; b=wRFmO1gVS0NZE0eEM0ptZ4PQBD3Btx7d/qp2gYlIfJ9CWg7d16o88VSqjbEFcETmh nfX4okEJf8F0icB0rESb9SzOBOtxF3LVKXCa+uREnUczal+Gr8AHpKCTFPLdUtTW+q Xz5rXuw23jb7hhdYkgmhKQL3wnMr9+rIyHyL5t5U= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: "tools-implementation@ietf.org" From: Robert Sparks Message-ID: Date: Tue, 15 Sep 2020 13:15:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Tools-implementation] Different topic: pointing to drafts from the datatracker X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 18:15:35 -0000 You've seen the thread with Carsten, Michael, and others about how the advent of v3 html has put pressure on what URLs for a draft that people might reference (from a paper). I think there are many things we might do with the feedback in that thread. One is fairly quick and easy - I think we have places where the datatracker points to www.ietf.org/id/ for drafts. I propose we change all of those to point to www.ietf.org/archive/id instead. RjS From nobody Tue Sep 15 11:17:11 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9593A1672 for ; Tue, 15 Sep 2020 11:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5YEd2GmKH00o for ; Tue, 15 Sep 2020 11:17:07 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FBA3A1671 for ; Tue, 15 Sep 2020 11:17:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 98F933C3087; Tue, 15 Sep 2020 11:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ay_XgGkJkE3; Tue, 15 Sep 2020 11:17:05 -0700 (PDT) Received: from [IPv6:2601:602:9c00:ae0:b0aa:25e3:6d97:3477] (unknown [IPv6:2601:602:9c00:ae0:b0aa:25e3:6d97:3477]) by c8a.amsl.com (Postfix) with ESMTPSA id 2B1253C3086; Tue, 15 Sep 2020 11:17:05 -0700 (PDT) From: Ryan Cross Message-Id: <1F5A3AFF-2844-4F92-A81F-F70EC5FAA715@amsl.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2C1F256E-C03B-4CAA-9F12-AB9B4A24F694" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 15 Sep 2020 11:17:05 -0700 In-Reply-To: <7e213352-f0ba-6a84-0d26-1d2cb669f5f5@nostrum.com> Cc: "tools-implementation@ietf.org" To: Robert Sparks References: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> <7e213352-f0ba-6a84-0d26-1d2cb669f5f5@nostrum.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Tools-implementation] Organization of the mail archives X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 18:17:09 -0000 --Apple-Mail=_2C1F256E-C03B-4CAA-9F12-AB9B4A24F694 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Inline > On Sep 15, 2020, at 9:58 AM, Robert Sparks = wrote: >=20 > Continuing this in the context of today's conversation. >=20 > After the cleanup described below, we are/will-be left with: >=20 >=20 > /a/mailarch/data/archive as the _authoritative_ store.=20 >=20 > /a/mailarch/data/mbox_archive/public as an automatically generated set = of mbox files generated from the authoritative store.=20 >=20 > Should we plan to move the first to be under /doc and the second to be = under /derived? >=20 >=20 Do you mean /a/mailarch/data/doc/[list name] /a/mailarch/data/derived/[list name] Or something else? > RjS >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: Organization of the mail archives > Date: Tue, 1 Sep 2020 12:30:56 -0500 > From: Robert Sparks = > To: Ryan Cross , = tools-implementation@ietf.org = >=20 > After consulting with Ryan, I propose this disposition for the = following email archive related directories: >=20 >=20 >>> Legacy Mailarchive /a/ietf A few very old mail archive scripts > This can simply be removed. The scripts are no longer used. >>> Email Mailarchive /a/isode ISODE IMAP server data store >>> Email Mailarchive /a/mailarch Mail Archive operations >=20 > These should stay where they are. >=20 > /a/mailarch/data/archive is the _authoritative_ store. >=20 > /a/mailarch/data/mbox_archive/public is an automatically generated set = of mbox files generated from the authoritative store. That should be = used to replace several things below. >=20 >>> Email Mailman /a/mailman Mailman operations > That has to remain (though we should consider what to do with it when = we bring in Mailman3 >>> Email Mailman /a/mailman/archives Mailman Legacy Archives > This has to remain - it is where mailman's internal archiving takes = place - any lists using pipermail are kept here, so Legacy isn't really = accurate above >>>=20 >>> Email Postfix /a/postfix Postfix operations > This remains >>> FTP FTP/Website combined = /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT = exposed by http >>>=20 > These have all been imported, and are served through the mailarchive. = These should be stashed. I personally don't think we should serve them = in any way since they are available through the mailarchive. If they are = served, they should clearly be in something I'd like to start calling = the "museum". >>=20 >>> FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains = text versions of mail archive ftp, rsync night-runner All web access is = to the /a/www/ietf-mail-archive tree, which this is a copy of > This should go away as soon as ftp stops depending on it (and we had = another conversation about removing it already). >>> Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive >>> Email Mailarchive /a/www/ietf-mail-archive/text >>> Email Mailarchive /a/www/ietf-mail-archive/text-secure >>> Email Mailarchive /a/www/ietf-mail-archive/web >>> Email Mailarchive /a/www/ietf-mail-archive/web-old >>> Email Mailarchive /a/www/ietf-mail-archive/web-secure >>>=20 >>> Again, has all of that been imported, and can all of this simply be = removed (or stashed offline)? > All of this should be stashed. Everything here, with the possible = exception of things in web-old have been imported into mailarchive. Ryan = is looking at making sure those get imported. Once that's done, all of = these should either be taken offline or put in the museum. >=20 > Are there any other puddles of email-archive related things that = aren't in those directories? >=20 --Apple-Mail=_2C1F256E-C03B-4CAA-9F12-AB9B4A24F694 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Inline

On Sep 15, 2020, at 9:58 AM, Robert Sparks <rjsparks@nostrum.com> wrote:

Continuing this in the context of today's conversation.

After the cleanup described below, we are/will-be left with:


/a/mailarch/data/archive as the _authoritative_ store.

/a/mailarch/data/mbox_archive/public as an automatically generated set of mbox files generated from the authoritative store.

Should we plan to move the first to be under /doc and the second to be under /derived?


Do you mean

/a/mailarch/data/doc/[list name]

/a/mailarch/data/derived/[list name]

Or something else?

RjS



-------- Forwarded Message --------
Subject: Organization of the mail archives
Date: Tue, 1 Sep 2020 12:30:56 -0500
From: Robert Sparks <rjsparks@nostrum.com>
To: Ryan Cross <rcross@amsl.com>, tools-implementation@ietf.org <tools-implementation@ietf.org>


After consulting with Ryan, I propose this disposition for the following email archive related directories:


Legacy Mailarchive /a/ietf A few very old mail archive scripts
This can simply be removed. The scripts are no longer used.
Email Mailarchive /a/isode ISODE IMAP server data store
Email Mailarchive /a/mailarch Mail Archive operations

These should stay where they are.

/a/mailarch/data/archive is the _authoritative_ store.

/a/mailarch/data/mbox_archive/public is an automatically generated set of mbox files generated from the authoritative store. That should be used to replace several things below.

Email Mailman /a/mailman Mailman operations
That has to remain (though we should consider what to do with it when we bring in Mailman3
Email Mailman /a/mailman/archives Mailman Legacy Archives
This has to remain - it is where mailman's internal archiving takes place - any lists using pipermail are kept here, so Legacy isn't really accurate above

Email Postfix /a/postfix Postfix operations
This remains
FTP FTP/Website combined /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT exposed by http

These have all been imported, and are served through the mailarchive. These should be stashed. I personally don't think we should serve them in any way since they are available through the mailarchive. If they are served, they should clearly be in something I'd like to start calling the "museum".

FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains text versions of mail archive ftp, rsync night-runner All web access is to the /a/www/ietf-mail-archive tree, which this is a copy of
This should go away as soon as ftp stops depending on it (and we had another conversation about removing it already).
Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive
Email Mailarchive /a/www/ietf-mail-archive/text
Email Mailarchive /a/www/ietf-mail-archive/text-secure
Email Mailarchive /a/www/ietf-mail-archive/web
Email Mailarchive /a/www/ietf-mail-archive/web-old
Email Mailarchive /a/www/ietf-mail-archive/web-secure

Again, has all of that been imported, and can all of this simply be removed (or stashed offline)?
All of this should be stashed. Everything here, with the possible exception of things in web-old have been imported into mailarchive. Ryan is looking at making sure those get imported. Once that's done, all of these should either be taken offline or put in the museum.

Are there any other puddles of email-archive related things that aren't in those directories?


--Apple-Mail=_2C1F256E-C03B-4CAA-9F12-AB9B4A24F694-- From nobody Tue Sep 15 11:39:51 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785463A1707 for ; Tue, 15 Sep 2020 11:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 Y45ezBsnCdlC for ; Tue, 15 Sep 2020 11:39:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C545B3A1706 for ; Tue, 15 Sep 2020 11:39:47 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08FIdgdc024743 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 15 Sep 2020 13:39:45 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600195186; bh=fX2vFq0DxRz73T0bxb0XnIVsnhF7oNOOU7mPHzxZh3E=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=PODnj9MQ8WVSDNWResPzuXC/4go7CUAtECifx3timny+lrA/8aLZ6JpjBuQEWmo+r 5BBhDTsVYrXEv9pdztQHAWgu9ah4XvDHUmBtIj8fAL/Y+D/bexpUrVqQ9KVhNEstaF pgeDah15vMMANxxQVdspsVo9Yr+7nCMiTCq8/6yU= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Ryan Cross Cc: "tools-implementation@ietf.org" References: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> <7e213352-f0ba-6a84-0d26-1d2cb669f5f5@nostrum.com> <1F5A3AFF-2844-4F92-A81F-F70EC5FAA715@amsl.com> From: Robert Sparks Message-ID: <97bdd0e1-1dde-72ef-e444-f33a0b15d81f@nostrum.com> Date: Tue, 15 Sep 2020 13:39:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <1F5A3AFF-2844-4F92-A81F-F70EC5FAA715@amsl.com> Content-Type: multipart/alternative; boundary="------------0C9AB767DBBEC5C5196D50AE" Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Organization of the mail archives X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 18:39:49 -0000 This is a multi-part message in MIME format. --------------0C9AB767DBBEC5C5196D50AE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 9/15/20 1:17 PM, Ryan Cross wrote: > Inline > >> On Sep 15, 2020, at 9:58 AM, Robert Sparks > > wrote: >> >> Continuing this in the context of today's conversation. >> >> After the cleanup described below, we are/will-be left with: >> >> >> /a/mailarch/data/archive as the _authoritative_ store. >> >> /a/mailarch/data/mbox_archive/public as an automatically generated >> set of mbox files generated from the authoritative store. >> >> Should we plan to move the first to be under /doc and the second to >> be under /derived? >> >> > Do you mean > > /a/mailarch/data/doc/[list name] > > /a/mailarch/data/derived/[list name] > > Or something else? No - we've been discussing putting original data in a common place, so it would end up being something more like /doc/mailarch/[list name] and /derived/mailarch/[listname]. >> >> RjS >> >> >> >> -------- Forwarded Message -------- >> Subject: Organization of the mail archives >> Date: Tue, 1 Sep 2020 12:30:56 -0500 >> From: Robert Sparks >> To: Ryan Cross , tools-implementation@ietf.org >> >> >> >> >> After consulting with Ryan, I propose this disposition for the >> following email archive related directories: >> >> >>>> Legacy Mailarchive /a/ietf A few very old mail archive scripts >> This can simply be removed. The scripts are no longer used. >>>> Email Mailarchive /a/isode ISODE IMAP server data store >>>> Email Mailarchive /a/mailarch Mail Archive operations >> >> These should stay where they are. >> >> /a/mailarch/data/archive is the _authoritative_ store. >> >> /a/mailarch/data/mbox_archive/public is an automatically generated >> set of mbox files generated from the authoritative store. That should >> be used to replace several things below. >> >>>> Email Mailman /a/mailman Mailman operations >> That has to remain (though we should consider what to do with it when >> we bring in Mailman3 >>>> Email Mailman /a/mailman/archives Mailman Legacy Archives >> This has to remain - it is where mailman's internal archiving takes >> place - any lists using pipermail are kept here, so Legacy isn't >> really accurate above >>>> >>>> Email Postfix /a/postfix Postfix operations >> This remains >>>> FTP FTP/Website combined >>>> /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT >>>> exposed by http >>>> >> These have all been imported, and are served through the mailarchive. >> These should be stashed. I personally don't think we should serve >> them in any way since they are available through the mailarchive. If >> they are served, they should clearly be in something I'd like to >> start calling the "museum". >>> >>>> FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains >>>> text versions of mail archive ftp, rsync night-runner All web >>>> access is to the /a/www/ietf-mail-archive tree, which this is a copy of >> This should go away as soon as ftp stops depending on it (and we had >> another conversation about removing it already). >>>> Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive >>>> Email Mailarchive /a/www/ietf-mail-archive/text >>>> Email Mailarchive /a/www/ietf-mail-archive/text-secure >>>> Email Mailarchive /a/www/ietf-mail-archive/web >>>> Email Mailarchive /a/www/ietf-mail-archive/web-old >>>> Email Mailarchive /a/www/ietf-mail-archive/web-secure >>>> >>>> Again, has all of that been imported, and can all of this simply be >>>> removed (or stashed offline)? >> All of this should be stashed. Everything here, with the possible >> exception of things in web-old have been imported into mailarchive. >> Ryan is looking at making sure those get imported. Once that's done, >> all of these should either be taken offline or put in the museum. >> >> Are there any other puddles of email-archive related things that >> aren't in those directories? >> > --------------0C9AB767DBBEC5C5196D50AE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit


On 9/15/20 1:17 PM, Ryan Cross wrote:
Inline

On Sep 15, 2020, at 9:58 AM, Robert Sparks <rjsparks@nostrum.com> wrote:

Continuing this in the context of today's conversation.

After the cleanup described below, we are/will-be left with:


/a/mailarch/data/archive as the _authoritative_ store.

/a/mailarch/data/mbox_archive/public as an automatically generated set of mbox files generated from the authoritative store.

Should we plan to move the first to be under /doc and the second to be under /derived?


Do you mean

/a/mailarch/data/doc/[list name]

/a/mailarch/data/derived/[list name]

Or something else?
No - we've been discussing putting original data in a common place, so it would end up being something more like /doc/mailarch/[list name] and /derived/mailarch/[listname].

RjS



-------- Forwarded Message --------
Subject: Organization of the mail archives
Date: Tue, 1 Sep 2020 12:30:56 -0500
From: Robert Sparks <rjsparks@nostrum.com>
To: Ryan Cross <rcross@amsl.com>, tools-implementation@ietf.org <tools-implementation@ietf.org>


After consulting with Ryan, I propose this disposition for the following email archive related directories:


Legacy Mailarchive /a/ietf A few very old mail archive scripts
This can simply be removed. The scripts are no longer used.
Email Mailarchive /a/isode ISODE IMAP server data store
Email Mailarchive /a/mailarch Mail Archive operations

These should stay where they are.

/a/mailarch/data/archive is the _authoritative_ store.

/a/mailarch/data/mbox_archive/public is an automatically generated set of mbox files generated from the authoritative store. That should be used to replace several things below.

Email Mailman /a/mailman Mailman operations
That has to remain (though we should consider what to do with it when we bring in Mailman3
Email Mailman /a/mailman/archives Mailman Legacy Archives
This has to remain - it is where mailman's internal archiving takes place - any lists using pipermail are kept here, so Legacy isn't really accurate above

Email Postfix /a/postfix Postfix operations
This remains
FTP FTP/Website combined /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT exposed by http

These have all been imported, and are served through the mailarchive. These should be stashed. I personally don't think we should serve them in any way since they are available through the mailarchive. If they are served, they should clearly be in something I'd like to start calling the "museum".

FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains text versions of mail archive ftp, rsync night-runner All web access is to the /a/www/ietf-mail-archive tree, which this is a copy of
This should go away as soon as ftp stops depending on it (and we had another conversation about removing it already).
Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive
Email Mailarchive /a/www/ietf-mail-archive/text
Email Mailarchive /a/www/ietf-mail-archive/text-secure
Email Mailarchive /a/www/ietf-mail-archive/web
Email Mailarchive /a/www/ietf-mail-archive/web-old
Email Mailarchive /a/www/ietf-mail-archive/web-secure

Again, has all of that been imported, and can all of this simply be removed (or stashed offline)?
All of this should be stashed. Everything here, with the possible exception of things in web-old have been imported into mailarchive. Ryan is looking at making sure those get imported. Once that's done, all of these should either be taken offline or put in the museum.

Are there any other puddles of email-archive related things that aren't in those directories?


--------------0C9AB767DBBEC5C5196D50AE-- From nobody Tue Sep 15 11:47:03 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E183A173E for ; Tue, 15 Sep 2020 11:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.911 X-Spam-Level: X-Spam-Status: No, score=-101.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 oa9tiKOvepHQ for ; Tue, 15 Sep 2020 11:46:58 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C693A1738 for ; Tue, 15 Sep 2020 11:46:58 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 1D9FF3C3152; Tue, 15 Sep 2020 11:46:57 -0700 (PDT) Received: from [IPv6:2603:3024:15a1:78e0:c1b6:d7dd:a558:afbd] (unknown [IPv6:2603:3024:15a1:78e0:c1b6:d7dd:a558:afbd]) by c8a.amsl.com (Postfix) with ESMTPSA id 06E463C3151; Tue, 15 Sep 2020 11:46:57 -0700 (PDT) To: tools-implementation@ietf.org, Ryan Cross References: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com> <7e213352-f0ba-6a84-0d26-1d2cb669f5f5@nostrum.com> <1F5A3AFF-2844-4F92-A81F-F70EC5FAA715@amsl.com> <97bdd0e1-1dde-72ef-e444-f33a0b15d81f@nostrum.com> From: Glen Organization: AMS Message-ID: <52772537-6a5e-d264-cff5-f136beb8391c@amsl.com> Date: Tue, 15 Sep 2020 11:46:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <97bdd0e1-1dde-72ef-e444-f33a0b15d81f@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-implementation] Organization of the mail archives X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 18:47:01 -0000 On 9/15/2020 11:39, Robert Sparks wrote: >> /a/mailarch/data/doc/[list name] >> /a/mailarch/data/derived/[list name] > it would end up being something more like /doc/mailarch/[list name] and > /derived/mailarch/[listname]. For clarity, Ryan, the full path will be: /a/doc/mailarch/[listname] /a/derived/mailarch/[listname] (with the /a - these will *not* go on the root filesystem. :-) ) Glen From nobody Tue Sep 15 11:58:21 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C12D3A17BD for ; Tue, 15 Sep 2020 11:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bZsnI2xJLvQE for ; Tue, 15 Sep 2020 11:58:18 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A753A17BA for ; Tue, 15 Sep 2020 11:58:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1FCE6300B70 for ; Tue, 15 Sep 2020 14:58:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hAVt2fM5UVEr for ; Tue, 15 Sep 2020 14:58:14 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id C3DF3300AAB; Tue, 15 Sep 2020 14:58:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: Date: Tue, 15 Sep 2020 14:58:16 -0400 Cc: "tools-implementation@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8604C59F-23EC-4F27-8CF0-A1928F3E89CD@vigilsec.com> References: To: Robert Sparks X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Tools-implementation] Different topic: pointing to drafts from the datatracker X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 18:58:20 -0000 Yes, that seems to be the quick fix to the request. Russ > On Sep 15, 2020, at 2:15 PM, Robert Sparks = wrote: >=20 > You've seen the thread with Carsten, Michael, and others about how the = advent of v3 html has put pressure on what URLs for a draft that people = might reference (from a paper). >=20 > I think there are many things we might do with the feedback in that = thread. One is fairly quick and easy - I think we have places where the = datatracker points to www.ietf.org/id/ for drafts. I propose we change = all of those to point to www.ietf.org/archive/id instead. >=20 > RjS >=20 > --=20 > Tools-implementation mailing list > Tools-implementation@ietf.org > https://www.ietf.org/mailman/listinfo/tools-implementation From nobody Wed Sep 16 05:32:23 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF09E3A0F8F for ; Wed, 16 Sep 2020 05:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 n8KA0qjXZQhU for ; Wed, 16 Sep 2020 05:32:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B212E3A0F5E for ; Wed, 16 Sep 2020 05:32:20 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53858 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kIWbV-000172-Pu; Wed, 16 Sep 2020 05:32:10 -0700 To: Robert Sparks , "tools-implementation@ietf.org" References: From: Henrik Levkowetz Message-ID: <29c6a7b1-9d44-44eb-640c-689ae92ae506@levkowetz.com> Date: Wed, 16 Sep 2020 14:31:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="g2QlI6MKmvRxoNHncQcJgPxHtjepeEMiR" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: tools-implementation@ietf.org, rjsparks@nostrum.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-implementation] Different topic: pointing to drafts from the datatracker X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 12:32:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --g2QlI6MKmvRxoNHncQcJgPxHtjepeEMiR Content-Type: multipart/mixed; boundary="0Nr8Ub2gbMd4KGPAUkAPKoqCijoSfbCuc"; protected-headers="v1" From: Henrik Levkowetz To: Robert Sparks , "tools-implementation@ietf.org" Message-ID: <29c6a7b1-9d44-44eb-640c-689ae92ae506@levkowetz.com> Subject: Re: [Tools-implementation] Different topic: pointing to drafts from the datatracker References: In-Reply-To: --0Nr8Ub2gbMd4KGPAUkAPKoqCijoSfbCuc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Robert, On 2020-09-15 20:15, Robert Sparks wrote: > You've seen the thread with Carsten, Michael, and others about how the = > advent of v3 html has put pressure on what URLs for a draft that people= =20 > might reference (from a paper). >=20 > I think there are many things we might do with the feedback in that=20 > thread. One is fairly quick and easy - I think we have places where the= =20 > datatracker points to www.ietf.org/id/ for drafts. I propose we change = > all of those to point to www.ietf.org/archive/id instead. Sounds reasonable, although I think the only places we currently don't point at /archive/id/ is in the draft announcement emails. If we change those, too, then maybe it's time to ask the IESG to simply ditch the separate active drafts directory altogether. Having seen how things worked 20 years ago, and how things have evolved, the active-drafts repository made a lot of sense at a time when there was no datatracker, no tools site, and the only way to get drafts was to pull them (via http* or ftp) from the active drafts repository. But today, the utility of that in parallel with /archive/id/ is so marginal, and the extra bother sufficiently large, that I think it could be time to= move to not having separate active drafts and archived drafts directories= =2E Best regards, Henrik --0Nr8Ub2gbMd4KGPAUkAPKoqCijoSfbCuc-- --g2QlI6MKmvRxoNHncQcJgPxHtjepeEMiR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9iBb4ACgkQTptXS4+7 FxogmQ//UqGd7pPHy4NbTxzEc6D4jkxHA9XiQozzRH3YVBQYaKMegJTl8ygitu6y VGcvya/6K6FPgVvYHvxP57zHoHrYvutDqQaWGlaZLF7DHajALmy6uISeUFHxFJ0/ MOCK4rbq/pXn0V18xpw4LEvDiyG0h8A1zcRbJUoGU8oEKMuYnUynyXg0xwNmNb9u hfrOaHNG+aLoWKooW8mYJ7v+Dqq+O2hQUIS59i0Ed8czn4uJcb7WpJX96BsKtq2e akJCaxxrQqGbYeW7fs9opv3PazP0IFo4osYxeWfPXDei/R9NtTUaorfwqNR5fTbD JUxvyOZUwIlD+0HxKwzkfp8prSldYmw5A4g7QxZ+o9v+e+362uetQtl06321z9qY 1UMwwLLh9so+gv1U7CqswbGGMcTY8YvKJwOnGEAZ5zoBqYHu9V6V46fkDl/4U1Zk Mqp7aPicS0Tst93BUsyLJ5Ww6dQ54M9tj4UHs2k8T1HQv36wf1UudlALbaSS39QM s0his5EsmCJ1Nffo2py8ZPzxsI3RgeC+i59U7JgM/ec8AsXuqWdJoWClUH/NHZj2 9iHpTV2RCzovrsYsmUkkh2avSnLeLXKOldwIRNhtFgJMIFTz0BPuB6YZ8e7CexRB oHipkXXn0SoTi2+X0gf7/k7YZI0pYutlk7yrnDupkt9qMUOwQTc= =wX7V -----END PGP SIGNATURE----- --g2QlI6MKmvRxoNHncQcJgPxHtjepeEMiR-- From nobody Wed Sep 16 06:27:23 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6EA3A0640 for ; Wed, 16 Sep 2020 06:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AkI6s__b2kHY for ; Wed, 16 Sep 2020 06:27:19 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9303A074B for ; Wed, 16 Sep 2020 06:27:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 79ED7300B20 for ; Wed, 16 Sep 2020 09:27:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 01orlAuPIjXD for ; Wed, 16 Sep 2020 09:27:15 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 53037300AA4; Wed, 16 Sep 2020 09:27:15 -0400 (EDT) From: Russ Housley Message-Id: <945A91D2-967B-4D3B-B601-D19B80189259@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_EA3ECD85-690F-45F0-A36A-0CFA2A87EADA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Wed, 16 Sep 2020 09:27:16 -0400 In-Reply-To: <29c6a7b1-9d44-44eb-640c-689ae92ae506@levkowetz.com> Cc: Robert Sparks , "tools-implementation@ietf.org" To: Henrik Levkowetz References: <29c6a7b1-9d44-44eb-640c-689ae92ae506@levkowetz.com> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Tools-implementation] Different topic: pointing to drafts from the datatracker X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 13:27:21 -0000 --Apple-Mail=_EA3ECD85-690F-45F0-A36A-0CFA2A87EADA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 16, 2020, at 8:31 AM, Henrik Levkowetz = wrote: >=20 > Signed PGP part > Hi Robert, >=20 > On 2020-09-15 20:15, Robert Sparks wrote: >> You've seen the thread with Carsten, Michael, and others about how = the >> advent of v3 html has put pressure on what URLs for a draft that = people >> might reference (from a paper). >>=20 >> I think there are many things we might do with the feedback in that >> thread. One is fairly quick and easy - I think we have places where = the >> datatracker points to www.ietf.org/id/ for drafts. I propose we = change >> all of those to point to www.ietf.org/archive/id instead. >=20 > Sounds reasonable, although I think the only places we currently don't > point at /archive/id/ is in the draft announcement emails. If we = change > those, too, then maybe it's time to ask the IESG to simply ditch the > separate active drafts directory altogether. >=20 > Having seen how things worked 20 years ago, and how things have = evolved, > the active-drafts repository made a lot of sense at a time when there > was no datatracker, no tools site, and the only way to get drafts was = to > pull them (via http* or ftp) from the active drafts repository. But > today, the utility of that in parallel with /archive/id/ is so = marginal, > and the extra bother sufficiently large, that I think it could be time = to > move to not having separate active drafts and archived drafts = directories. I'm not sure that I totally agree. I like to rsync the current drafts. = I do not want all of them on my laptop. Russ --Apple-Mail=_EA3ECD85-690F-45F0-A36A-0CFA2A87EADA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCX2IStAAKCRCK5O7Q9ZwR y3KnAKCnOL/0VdC1n/sGhOamJRiwXIEYggCgzoxTwHjz81aj3BPOrmt3fYEQ6cU= =5s68 -----END PGP SIGNATURE----- --Apple-Mail=_EA3ECD85-690F-45F0-A36A-0CFA2A87EADA-- From nobody Wed Sep 16 06:30:31 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BA33A0813 for ; Wed, 16 Sep 2020 06:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.282 X-Spam-Level: X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.398, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 24PEpT2EHw5Y for ; Wed, 16 Sep 2020 06:30:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0524C3A03EC for ; Wed, 16 Sep 2020 06:30:26 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08GDUNVT014142 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 16 Sep 2020 08:30:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600263026; bh=SqR3FH3w5LOm/DLpjrK4TWBC4jybTT1oaVAviDeHEXM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=cKiDqWT12KmzRioGkRi14BxnaYhlgRVHZ+Re+Ts8QrqmbZZ+ADRmdnEqS0cHuNjeB Zv8L34osCyGBBzjwNSgZVs54vc9/O/DxlXdCsImS19dFRVLCFeZ94lQISyQmRqYIt4 s/3aP2YTvKUTvFCcd6ZTA5hM3xgDWSMirzTDicEI= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Russ Housley , Henrik Levkowetz Cc: "tools-implementation@ietf.org" References: <29c6a7b1-9d44-44eb-640c-689ae92ae506@levkowetz.com> <945A91D2-967B-4D3B-B601-D19B80189259@vigilsec.com> From: Robert Sparks Message-ID: <64122a22-1fb0-59c7-385c-ffe587aeef36@nostrum.com> Date: Wed, 16 Sep 2020 08:30:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <945A91D2-967B-4D3B-B601-D19B80189259@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Different topic: pointing to drafts from the datatracker X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 13:30:30 -0000 On 9/16/20 8:27 AM, Russ Housley wrote: > >> On Sep 16, 2020, at 8:31 AM, Henrik Levkowetz wrote: >> >> Signed PGP part >> Hi Robert, >> >> On 2020-09-15 20:15, Robert Sparks wrote: >>> You've seen the thread with Carsten, Michael, and others about how the >>> advent of v3 html has put pressure on what URLs for a draft that people >>> might reference (from a paper). >>> >>> I think there are many things we might do with the feedback in that >>> thread. One is fairly quick and easy - I think we have places where the >>> datatracker points to www.ietf.org/id/ for drafts. I propose we change >>> all of those to point to www.ietf.org/archive/id instead. >> Sounds reasonable, although I think the only places we currently don't >> point at /archive/id/ is in the draft announcement emails. If we change >> those, too, then maybe it's time to ask the IESG to simply ditch the >> separate active drafts directory altogether. >> >> Having seen how things worked 20 years ago, and how things have evolved, >> the active-drafts repository made a lot of sense at a time when there >> was no datatracker, no tools site, and the only way to get drafts was to >> pull them (via http* or ftp) from the active drafts repository. But >> today, the utility of that in parallel with /archive/id/ is so marginal, >> and the extra bother sufficiently large, that I think it could be time to >> move to not having separate active drafts and archived drafts directories. > I'm not sure that I totally agree. I like to rsync the current drafts. I do not want all of them on my laptop. Would a place that let you choose what drafts you wanted with a filter work better for you? (Is all active drafts really what you want?) > > Russ > From nobody Wed Sep 16 06:31:52 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456DB3A0814 for ; Wed, 16 Sep 2020 06:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NyoKdVhFkseO for ; Wed, 16 Sep 2020 06:31:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051473A080C for ; Wed, 16 Sep 2020 06:31:50 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:54523 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kIXXF-0007XS-Tj; Wed, 16 Sep 2020 06:31:49 -0700 To: Russ Housley References: <29c6a7b1-9d44-44eb-640c-689ae92ae506@levkowetz.com> <945A91D2-967B-4D3B-B601-D19B80189259@vigilsec.com> Cc: "tools-implementation@ietf.org" , Robert Sparks From: Henrik Levkowetz Message-ID: <7f74fb76-8eae-8e78-6396-1112a9895ddd@levkowetz.com> Date: Wed, 16 Sep 2020 15:31:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <945A91D2-967B-4D3B-B601-D19B80189259@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fwGtDmBMOhE4GmP5pTji98thKrAO06KE6" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: rjsparks@nostrum.com, tools-implementation@ietf.org, housley@vigilsec.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-implementation] Different topic: pointing to drafts from the datatracker X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 13:31:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fwGtDmBMOhE4GmP5pTji98thKrAO06KE6 Content-Type: multipart/mixed; boundary="2i5mb6trRxPeVQAKpIBJujRRKdt3ip6nj"; protected-headers="v1" From: Henrik Levkowetz To: Russ Housley Cc: "tools-implementation@ietf.org" , Robert Sparks Message-ID: <7f74fb76-8eae-8e78-6396-1112a9895ddd@levkowetz.com> Subject: Re: [Tools-implementation] Different topic: pointing to drafts from the datatracker References: <29c6a7b1-9d44-44eb-640c-689ae92ae506@levkowetz.com> <945A91D2-967B-4D3B-B601-D19B80189259@vigilsec.com> In-Reply-To: <945A91D2-967B-4D3B-B601-D19B80189259@vigilsec.com> --2i5mb6trRxPeVQAKpIBJujRRKdt3ip6nj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, On 2020-09-16 15:27, Russ Housley wrote: >=20 >=20 >> On Sep 16, 2020, at 8:31 AM, Henrik Levkowetz w= rote: >>=20 >> Signed PGP part >> Hi Robert, >>=20 >> On 2020-09-15 20:15, Robert Sparks wrote: >>> You've seen the thread with Carsten, Michael, and others about how th= e >>> advent of v3 html has put pressure on what URLs for a draft that peop= le >>> might reference (from a paper). >>>=20 >>> I think there are many things we might do with the feedback in that >>> thread. One is fairly quick and easy - I think we have places where t= he >>> datatracker points to www.ietf.org/id/ for drafts. I propose we chang= e >>> all of those to point to www.ietf.org/archive/id instead. >>=20 >> Sounds reasonable, although I think the only places we currently don't= >> point at /archive/id/ is in the draft announcement emails. If we chan= ge >> those, too, then maybe it's time to ask the IESG to simply ditch the >> separate active drafts directory altogether. >>=20 >> Having seen how things worked 20 years ago, and how things have evolve= d, >> the active-drafts repository made a lot of sense at a time when there >> was no datatracker, no tools site, and the only way to get drafts was = to >> pull them (via http* or ftp) from the active drafts repository. But >> today, the utility of that in parallel with /archive/id/ is so margina= l, >> and the extra bother sufficiently large, that I think it could be time= to >> move to not having separate active drafts and archived drafts director= ies. >=20 > I'm not sure that I totally agree. I like to rsync the current > drafts. I do not want all of them on my laptop. That's a good point that I didn't think of. Ack. Henrik --2i5mb6trRxPeVQAKpIBJujRRKdt3ip6nj-- --fwGtDmBMOhE4GmP5pTji98thKrAO06KE6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9iE7oACgkQTptXS4+7 FxoNJBAApuwyeJip4jDla9BOc7RJTBQlEXHtgIPjqOcHYKBMm53yWkmOuWNCya6y 93TiVshkTwF62U8SL+3tZEx0dSg797LuhmRyFIwpe9XOx/FAlrt5cvUjxfRo7onO PA2tJpo8gAfDu+KDtugYWuiG4jgsiJr9CRvuKj5AtK/c/1WtrCtInaPwqRc8ELf6 wjSfv7wvyWj1rM6MYIAM65Re4dAaYarZGv0r2qykg70A18NC1hxCT0xOSAq8jHev JdeWyOsuLfBGVBT0M2uJAdDE0njS2Fj7BqpKJt67z+iDPYgfKDK0RTjSEoAM2Rg/ ffcHgbNguY1YeGWpDfb8rLlqAO8I9djqjHOY8tNLyTghyyokGH+Wfa/zBHoR+6wD 7WRgOF0539UWFwd7OBldg+dFtHVrplIYZcwAyR8eWuUQ+P4Tak6SjJWgnhApOuf+ 1OSgd8NgpehFKFa/sD+PnneHmbLvpruOF6BV5YvTH3Sl6MrTpqtunmD4nej7DUBr o6VX/ec/UwJ1yf1GUpmofjUeKOzgCWgy/FDgUX88emUGa1tz+Q2OFf2GHHCjozTJ hIGK5GjlQShJa5pIOjCfeB64KzpM9FXeCCXWf8hHKLjmGvCoS2z4Jn5InxdDcVVi 74UeNj0QbqqO01X4zYEwVeqQ4LVcbWeIWgIZGmyt4aUs3E3EyWc= =fg7m -----END PGP SIGNATURE----- --fwGtDmBMOhE4GmP5pTji98thKrAO06KE6-- From nobody Wed Sep 16 11:07:49 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A3D3A08D7 for ; Wed, 16 Sep 2020 11:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 CsShZhFzbgqP for ; Wed, 16 Sep 2020 11:07:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D84343A08D8 for ; Wed, 16 Sep 2020 11:07:46 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08GI7iuZ039860 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2020 13:07:46 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600279666; bh=NQrYyPljwk1w6Xo43/X0vyPrcgwSbJXjmrklA3Umgnc=; h=To:From:Subject:Date; b=OD/58F/XGJzSP52H+FdM1cdbk+/TzBKWbOC9tOMOpjSl70f7Bhe8RKtblWxVbpDwv 1GGuyZotB5zTXAVu2M2ETYrTaEHYFX+o6o0VoHV+F0jMTBlLmfswZ3XSLHA3rzfj7v IxfEme8qBaM6GXehH1VyWQVCjJCcJXMtVRxMp8kE= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: "tools-implementation@ietf.org" From: Robert Sparks Message-ID: <8bc25278-c909-bc54-4efb-08cb7f7862b1@nostrum.com> Date: Wed, 16 Sep 2020 13:07:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Tools-implementation] Database dumps for developers. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 18:07:48 -0000 We are currently producing scrubbed (passwords removed and similar) dumps of the datatracker database on Henrik's servers (but have plans to move that to IETFA). These are used by developers and the sandbox. We also have plans to produce scrubbed dumps of the website database for use by developers. We will also likely have others in the future (a dump of the guides database for instance). These scrubbed dumps should live in one of our buckets I think. I suggest they go into derived (given that they can be recreated if destroyed). I propose raw dumps are not something that should land in any of these buckets. RjS From nobody Wed Sep 16 11:22:20 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589573A0957 for ; Wed, 16 Sep 2020 11:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 aFjetvOEvIVC for ; Wed, 16 Sep 2020 11:22:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6863A0942 for ; Wed, 16 Sep 2020 11:22:16 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:55774 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kIc4O-0005Z0-0S; Wed, 16 Sep 2020 11:22:16 -0700 To: Robert Sparks , "tools-implementation@ietf.org" References: <8bc25278-c909-bc54-4efb-08cb7f7862b1@nostrum.com> From: Henrik Levkowetz Message-ID: <32ead0f2-40b7-8057-1203-6c4a80aa4477@levkowetz.com> Date: Wed, 16 Sep 2020 20:22:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8bc25278-c909-bc54-4efb-08cb7f7862b1@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LPwPXjcAk4mMeasrdGIhveCNCaJMUeCeM" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: tools-implementation@ietf.org, rjsparks@nostrum.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-implementation] Database dumps for developers. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 18:22:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LPwPXjcAk4mMeasrdGIhveCNCaJMUeCeM Content-Type: multipart/mixed; boundary="uLpCoUh7Bbwel3Vt59gXQJAF9lah5WtIu"; protected-headers="v1" From: Henrik Levkowetz To: Robert Sparks , "tools-implementation@ietf.org" Message-ID: <32ead0f2-40b7-8057-1203-6c4a80aa4477@levkowetz.com> Subject: Re: [Tools-implementation] Database dumps for developers. References: <8bc25278-c909-bc54-4efb-08cb7f7862b1@nostrum.com> In-Reply-To: <8bc25278-c909-bc54-4efb-08cb7f7862b1@nostrum.com> --uLpCoUh7Bbwel3Vt59gXQJAF9lah5WtIu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Seems reasonable to me. Henrik On 2020-09-16 20:07, Robert Sparks wrote: > We are currently producing scrubbed (passwords removed and similar)=20 > dumps of the datatracker database on Henrik's servers (but have plans t= o=20 > move that to IETFA). These are used by developers and the sandbox. >=20 > We also have plans to produce scrubbed dumps of the website database fo= r=20 > use by developers. >=20 > We will also likely have others in the future (a dump of the guides=20 > database for instance). >=20 > These scrubbed dumps should live in one of our buckets I think. I=20 > suggest they go into derived (given that they can be recreated if=20 > destroyed). >=20 > I propose raw dumps are not something that should land in any of these = > buckets. >=20 > RjS >=20 --uLpCoUh7Bbwel3Vt59gXQJAF9lah5WtIu-- --LPwPXjcAk4mMeasrdGIhveCNCaJMUeCeM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9iV84ACgkQTptXS4+7 Fxpyzw/7BxKUPYKpm0LPZRjPM9yhCxXwY72UI9vvT/qrVUDWHr1yYbMNvQ8vjs+E jVLj/LFExhDtwKvaGiRf57TnyFfdoC1N9Gf1D7d+bDznfd2QNgjpTsxNsayzyFA0 RBZRfO3DLsJnn7Fr26v99n/Z9JS9wyXtDju6mdTz6eQwQpp1ZbyYPZktXeZznuPB pQBpMuJAn4jkuu4Lu0SQ+D+E+5qSsJcv2n85LMT5mvxk3212C0up99T4Hd9A400b odKdejWSloHWWbazN64sakj7iB8AqvRi4TeA8izrZkkIDWQEZWiPPzTh65Nu91Wa lUik1t0McZ4/2g8z92RH1UsqOyojGsMH9lfLMSGharotgJWHmBxiRBrnCtb8eYDs bPIFz/VUy4owPDChCNgoeqcZI9PX8jd8QeYzVNwZ+Y18uO/RsyH5rPxwfKWDtoUl bh2emDsMO2rriF+9e7edjXpW6dJQqcJtnjwWMEUNlAcePmsXL0w57Kq+shOplNMJ 87SoTxLlLRUzmY2mfe6zTBFhpV7zpe7ukIus3RZ+QmBYhQuaOtnp/ni7E97L1lEa FmhlV+ENAgqqRahAIXvLZ1NyoA+AQM0s4zIuMmcsrRVcXvi6VgMzlLagzuIIFSSg Pb501T8VqZGccC2EM8vbnC7UWcX5fi8H3/c+/u0Pham1mfHU88E= =rrdJ -----END PGP SIGNATURE----- --LPwPXjcAk4mMeasrdGIhveCNCaJMUeCeM-- From nobody Wed Sep 16 11:34:53 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43793A09C6 for ; Wed, 16 Sep 2020 11:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.911 X-Spam-Level: X-Spam-Status: No, score=-101.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 As_CH2KsaRFC for ; Wed, 16 Sep 2020 11:34:50 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D0A3A09C3 for ; Wed, 16 Sep 2020 11:34:50 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id D560E3C24C5 for ; Wed, 16 Sep 2020 11:34:47 -0700 (PDT) Received: from [IPv6:2603:3024:15a1:78e0:157a:cf4b:5cae:777a] (unknown [IPv6:2603:3024:15a1:78e0:157a:cf4b:5cae:777a]) by c8a.amsl.com (Postfix) with ESMTPSA id C6A3F3C24C4 for ; Wed, 16 Sep 2020 11:34:47 -0700 (PDT) To: tools-implementation@ietf.org References: <8bc25278-c909-bc54-4efb-08cb7f7862b1@nostrum.com> <32ead0f2-40b7-8057-1203-6c4a80aa4477@levkowetz.com> From: Glen Organization: AMS Message-ID: <9a5b6c80-54c8-a31e-0922-f0b0cf1a1c69@amsl.com> Date: Wed, 16 Sep 2020 11:34:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <32ead0f2-40b7-8057-1203-6c4a80aa4477@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-implementation] Database dumps for developers. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 18:34:52 -0000 On 9/16/2020 11:22, Henrik Levkowetz wrote: > Seems reasonable to me. Me too... > On 2020-09-16 20:07, Robert Sparks wrote: >> I propose raw dumps are not something that should land in any of these >> buckets. +1 - I have a moderate to strong preference to continue doing what I'm doing with /a/dumps, and /a/dumps-p. :-) (Nightly dumps of both database engines, rotated, for emergency recovery use by AMS staff if it's ever needed.) Glen From nobody Wed Sep 16 11:44:15 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BE43A09E4 for ; Wed, 16 Sep 2020 11:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XGFhTVzex-sG for ; Wed, 16 Sep 2020 11:44:11 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE143A09DB for ; Wed, 16 Sep 2020 11:44:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5431F300B7C for ; Wed, 16 Sep 2020 14:44:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gczQnsCckz72 for ; Wed, 16 Sep 2020 14:44:07 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id EA962300AAB; Wed, 16 Sep 2020 14:44:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <8bc25278-c909-bc54-4efb-08cb7f7862b1@nostrum.com> Date: Wed, 16 Sep 2020 14:44:08 -0400 Cc: "tools-implementation@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4B0E1FBC-79A1-4775-9BCC-E2CF4F6C3996@vigilsec.com> References: <8bc25278-c909-bc54-4efb-08cb7f7862b1@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Tools-implementation] Database dumps for developers. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 18:44:14 -0000 How about=20 ./dev/dump/datatracker ./dev/dump/wagtail ./dev/dump/guides ... Russ > On Sep 16, 2020, at 2:07 PM, Robert Sparks = wrote: >=20 > We are currently producing scrubbed (passwords removed and similar) = dumps of the datatracker database on Henrik's servers (but have plans to = move that to IETFA). These are used by developers and the sandbox. >=20 > We also have plans to produce scrubbed dumps of the website database = for use by developers. >=20 > We will also likely have others in the future (a dump of the guides = database for instance). >=20 > These scrubbed dumps should live in one of our buckets I think. I = suggest they go into derived (given that they can be recreated if = destroyed). >=20 > I propose raw dumps are not something that should land in any of these = buckets. >=20 > RjS >=20 > --=20 > Tools-implementation mailing list > Tools-implementation@ietf.org > https://www.ietf.org/mailman/listinfo/tools-implementation From nobody Wed Sep 16 11:46:25 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F1F3A09FA for ; Wed, 16 Sep 2020 11:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1K4UQEVJjv9G for ; Wed, 16 Sep 2020 11:46:22 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C683A09EE for ; Wed, 16 Sep 2020 11:46:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8FC0C300B4C for ; Wed, 16 Sep 2020 14:46:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id G9IWNggYrftT for ; Wed, 16 Sep 2020 14:46:17 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id BAEC5300AAB; Wed, 16 Sep 2020 14:46:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <9a5b6c80-54c8-a31e-0922-f0b0cf1a1c69@amsl.com> Date: Wed, 16 Sep 2020 14:46:19 -0400 Cc: tools-implementation@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <65737C03-161F-40D6-B813-C666DF22FC75@vigilsec.com> References: <8bc25278-c909-bc54-4efb-08cb7f7862b1@nostrum.com> <32ead0f2-40b7-8057-1203-6c4a80aa4477@levkowetz.com> <9a5b6c80-54c8-a31e-0922-f0b0cf1a1c69@amsl.com> To: Glen Barney X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Tools-implementation] Database dumps for developers. X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 18:46:25 -0000 > On Sep 16, 2020, at 2:34 PM, Glen wrote: >=20 > On 9/16/2020 11:22, Henrik Levkowetz wrote: >> Seems reasonable to me. >=20 > Me too... >=20 >> On 2020-09-16 20:07, Robert Sparks wrote: >>> I propose raw dumps are not something that should land in any of = these >>> buckets. >=20 > +1 - I have a moderate to strong preference to continue doing what I'm = doing with /a/dumps, and /a/dumps-p. :-) (Nightly dumps of both = database engines, rotated, for emergency recovery use by AMS staff if = it's ever needed.) Those are full dumps. They do not have redacted passwords. I would like the names to be very different to avoid weary person from = making typo. Russ From nobody Wed Sep 16 13:38:47 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F9B3A10BD for ; Wed, 16 Sep 2020 13:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 3TLFTq4f5ouE for ; Wed, 16 Sep 2020 13:38:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5A8CA3A08AF for ; Wed, 16 Sep 2020 13:38:45 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08GKcgCT091700 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2020 15:38:44 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600288724; bh=Rbm90mxh843HWX5zqIe13VELkpQIpJmUIc4RHg/J7dY=; h=To:From:Subject:Date; b=jB0W9itjfklsLZFh5eBJHn4eHfFhYVw5v3uIAeE5ZMnhZgZdGZxk7XjyU99+/e0wb ftlHRSjqp66HTaynebbADKHqUJE1VUm3bkG5gM8YT+MzPuNih7wS4aJmDKb8QJ94+J Ue2mienVAG8cvmd2VxxVCec3MKctH2ZwPSlYkE6o= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: "tools-implementation@ietf.org" From: Robert Sparks Message-ID: <60b560f9-615a-5c52-386c-8b0804af6557@nostrum.com> Date: Wed, 16 Sep 2020 15:38:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Tools-implementation] Github backups -> offline bucket X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 20:38:46 -0000 The github backups that we are making should go into the offline bucket we were discussing. I added a section for offline to the page. RjS From nobody Mon Sep 21 12:20:20 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5DF3A0CF2; Mon, 21 Sep 2020 12:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 gKBG4lQ1iVrQ; Mon, 21 Sep 2020 12:20:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6DD1F3A0CF4; Mon, 21 Sep 2020 12:20:17 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08LJKCC7090123 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 21 Sep 2020 14:20:15 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600716015; bh=tW1ZROQw3kyRp0GLYvoHt3hpx3KBfegwulCCY5FCBb8=; h=To:Cc:From:Subject:Date; b=gkTJI1OoQILiVLNk16CVuXqrOqKxVS7gLODF6P9XNQcsbVvoRfQ1ciyFvS1vrhimr ptwL2G2kZND56+j2GENkKx3rW/OzLrZXYfYyLGojunJeQP3jd1XZtYfME8w0wmF1d4 jl0VuaT6BdCuPG/XMtIVStt9JY8QN66two44OvkA= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: "tools-implementation@ietf.org" Cc: Jay Daley From: Robert Sparks Message-ID: Date: Mon, 21 Sep 2020 14:20:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Tools-implementation] Rough draft of message to the community re Zulip and Matrix X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 19:20:19 -0000 All - First, note that Glen is offline this week, and I do not expect him to see any of this conversation until he returns. But please don't wait for him to refine this. I would like to have it in a form that we can send by early next week. Please point out (and offer text for) missing things that need to be addressed in this initial message. ==== We are deploying trials of the matrix and zulip chat services to gain operational experience and get community feedback about how well these services meet the need for IETF related chat. The installs currently have almost no local configuration or customization. Over the next few weeks, we will be exploring reconfiguring them to use datatracker credentials for sign-in, and explore bridging between these systems, Slack, and Jabber. The secretariat is operating each instance. We've chosen this path for these trials over third party hosting to learn what would be needed if the community felt self-hosting was important in the longer term. The services can be found at matrix-trial1.ietf.org and zulip-trial1.ietf.org. Any matrix client can be used with the trial matrix server. We are also hosting an instance of the element web client at matrix-trial1.ietf.org. Similarly any zulip client can be used with the trial zulip server, which has a built in web interface. Around December, we will assess our experiences and the feedback received to inform what chat services we provide in the future and how we will operate them. In January, these trial instances will be taken down. We do not intend to preserve or migrate any account configuration or chat history from the trial instances as we move forward. This does add to the potentially confusing large number of places conversation might take place. We hope to address that with some level of bridging, at least with Jabber, but have been cautioned by the respective development communities that bridging between Zulip and Matrix is unsatisfying since the conversation models in the two applications are so different. The chat services are intended to be explorational and informal. However, please treat them as contexts where participation rules apply (See https://www.ietf.org/about/note-well/). We are not, at this time, planning to host jabber accounts. We may revisit that as an option as we continue to gather more feedback. From nobody Mon Sep 21 13:11:03 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381C83A0544 for ; Mon, 21 Sep 2020 13:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1KYOHcYQKYag for ; Mon, 21 Sep 2020 13:11:00 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD1B3A079F for ; Mon, 21 Sep 2020 13:11:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 083F5300BA4 for ; Mon, 21 Sep 2020 16:10:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rjTJPowVPJYK for ; Mon, 21 Sep 2020 16:10:56 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 129D5300B3C; Mon, 21 Sep 2020 16:10:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: Date: Mon, 21 Sep 2020 16:10:56 -0400 Cc: "tools-implementation@ietf.org" , Jay Daley Content-Transfer-Encoding: quoted-printable Message-Id: <8EC6DB09-5959-42CE-A218-98BCA2E103D5@vigilsec.com> References: To: Robert Sparks X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Tools-implementation] Rough draft of message to the community re Zulip and Matrix X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 20:11:02 -0000 Robert: Comments below. Russ > On Sep 21, 2020, at 3:20 PM, Robert Sparks = wrote: >=20 > All - >=20 > First, note that Glen is offline this week, and I do not expect him to = see any of this conversation until he returns. But please don't wait for = him to refine this. I would like to have it in a form that we can send = by early next week. >=20 > Please point out (and offer text for) missing things that need to be = addressed in this initial message. >=20 > =3D=3D=3D=3D >=20 > We are deploying trials of the matrix and zulip chat services to gain > operational experience and get community feedback about how well these = services > meet the need for IETF related chat. Is thee a sentence or two you can add about the things that we hope will = be better than the current solution? We expect the chat to support face-to-face IETF meetings, virtual = meetings, interim meetings, and virtual hallway discussions. We should = say that all of these are dimensions to consider. >=20 > The installs currently have almost no local configuration or = customization. > Over the next few weeks, we will be exploring reconfiguring them to = use > datatracker credentials for sign-in, and explore bridging between = these systems, > Slack, and Jabber. >=20 > The secretariat is operating each instance. We've chosen this path for = these > trials over third party hosting to learn what would be needed if the = community > felt self-hosting was important in the longer term. >=20 > The services can be found at matrix-trial1.ietf.org and = zulip-trial1.ietf.org. >=20 > Any matrix client can be used with the trial matrix server. We are = also hosting > an instance of the element web client at matrix-trial1.ietf.org. ... there is also a web client available at matrix-trial1.ietf.org.=20 It currently refuses to create an account with "common" names that are = easy to guess. This does not seem ideal for the IETF community. This should tell people what convention we want to use for these = accounts. >=20 > Similarly any zulip client can be used with the trial zulip server, = which has a > built in web interface. It currently uses your email address, which is not bad for the IETF. = However, I never got the email when I tried to create an account. = Probably needs plumbing into the IETF mail system. This should tell people that their email address will be used, and ask = them ti use the email address known to the datatracker. >=20 > Around December, we will assess our experiences and the feedback = received to > inform what chat services we provide in the future and how we will = operate Where do we want them to provide feedback? > them. In January, these trial instances will be taken down. We do not = intend to > preserve or migrate any account configuration or chat history from the = trial > instances as we move forward. >=20 > This does add to the potentially confusing large number of places = conversation > might take place. We hope to address that with some level of bridging, = at least > with Jabber, but have been cautioned by the respective development = communities > that bridging between Zulip and Matrix is unsatisfying since the = conversation > models in the two applications are so different. >=20 > The chat services are intended to be explorational and informal. = However, > please treat them as contexts where participation rules apply (See ... IETF participation ... Some would argue that NOTE WELL applies to contributes, not = participation. You may want to word smith to avoid that tussle. > https://www.ietf.org/about/note-well/). >=20 > We are not, at this time, planning to host jabber accounts. We may = revisit that > as an option as we continue to gather more feedback. From nobody Mon Sep 21 13:18:41 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9213A081F; Mon, 21 Sep 2020 13:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.282 X-Spam-Level: X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.398, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 vJ4yXe61DNey; Mon, 21 Sep 2020 13:18:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 595933A0827; Mon, 21 Sep 2020 13:18:38 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08LKIWdL074002 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 21 Sep 2020 15:18:37 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1600719517; bh=9gis0xr4xEAr6anqel2FbJeb4t1FXKPlcHSzsHuJriU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=lxKr07Ga1VC0NK1fhy6my4kJEFigUqgrEieiZtTi6FJ0dD7aEXW1Otg/z7mSy/9l/ DjM7UuAtbcgzk9rOYvLsr1fVlxNvavI3SzlVHiFaZrhWR0hxwRLCQpjYfQtndZEQmo Wu1mxaeAuV5JIb9pjfRRVjgl43SyruiDOPvomc/w= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Russ Housley Cc: "tools-implementation@ietf.org" , Jay Daley References: <8EC6DB09-5959-42CE-A218-98BCA2E103D5@vigilsec.com> From: Robert Sparks Message-ID: Date: Mon, 21 Sep 2020 15:18:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <8EC6DB09-5959-42CE-A218-98BCA2E103D5@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Rough draft of message to the community re Zulip and Matrix X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 20:18:40 -0000 a couple of quick responses inline On 9/21/20 3:10 PM, Russ Housley wrote: > Robert: > > Comments below. > > Russ > > >> On Sep 21, 2020, at 3:20 PM, Robert Sparks wrote: >> >> All - >> >> First, note that Glen is offline this week, and I do not expect him to see any of this conversation until he returns. But please don't wait for him to refine this. I would like to have it in a form that we can send by early next week. >> >> Please point out (and offer text for) missing things that need to be addressed in this initial message. >> >> ==== >> >> We are deploying trials of the matrix and zulip chat services to gain >> operational experience and get community feedback about how well these services >> meet the need for IETF related chat. > Is thee a sentence or two you can add about the things that we hope will be better than the current solution? > > We expect the chat to support face-to-face IETF meetings, virtual meetings, interim meetings, and virtual hallway discussions. We should say that all of these are dimensions to consider. > >> The installs currently have almost no local configuration or customization. >> Over the next few weeks, we will be exploring reconfiguring them to use >> datatracker credentials for sign-in, and explore bridging between these systems, >> Slack, and Jabber. >> >> The secretariat is operating each instance. We've chosen this path for these >> trials over third party hosting to learn what would be needed if the community >> felt self-hosting was important in the longer term. >> >> The services can be found at matrix-trial1.ietf.org and zulip-trial1.ietf.org. >> >> Any matrix client can be used with the trial matrix server. We are also hosting >> an instance of the element web client at matrix-trial1.ietf.org. > ... there is also a web client available at matrix-trial1.ietf.org. > > It currently refuses to create an account with "common" names that are easy to guess. This does not seem ideal for the IETF community. > > This should tell people what convention we want to use for these accounts. Expand please? I don't think this initial message should be speaking at the level of "what your account name can look like". I also don't think we want to try to start changing the configuration to route around this kind of issue (unless we're forced to to make progress). Letting people see these kinds of edges are part of why we're running this as a trial set of services. > >> Similarly any zulip client can be used with the trial zulip server, which has a >> built in web interface. > It currently uses your email address, which is not bad for the IETF. However, I never got the email when I tried to create an account. Something we'll have to wait for Glen to get back online for to diagnose. > Probably needs plumbing into the IETF mail system. > > This should tell people that their email address will be used, and ask them ti use the email address known to the datatracker. Well, as we get a week or two in, we may integrate accounts with the datatracker anyhow, so it may be moot. But I don't think we should wait on getting that integration working beforew we start getting feedback. I've already called out that we will be making changes like that. > >> Around December, we will assess our experiences and the feedback received to >> inform what chat services we provide in the future and how we will operate > Where do we want them to provide feedback? I think tools-discuss > >> them. In January, these trial instances will be taken down. We do not intend to >> preserve or migrate any account configuration or chat history from the trial >> instances as we move forward. >> >> This does add to the potentially confusing large number of places conversation >> might take place. We hope to address that with some level of bridging, at least >> with Jabber, but have been cautioned by the respective development communities >> that bridging between Zulip and Matrix is unsatisfying since the conversation >> models in the two applications are so different. >> >> The chat services are intended to be explorational and informal. However, >> please treat them as contexts where participation rules apply (See > ... IETF participation ... > > Some would argue that NOTE WELL applies to contributes, not participation. You may want to word smith to avoid that tussle. > >> https://www.ietf.org/about/note-well/). >> >> We are not, at this time, planning to host jabber accounts. We may revisit that >> as an option as we continue to gather more feedback. From nobody Mon Sep 21 13:23:45 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039793A08C7 for ; Mon, 21 Sep 2020 13:23:43 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TGQZA89V-nAV for ; Mon, 21 Sep 2020 13:23:41 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8EE3A08C1 for ; Mon, 21 Sep 2020 13:23:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CB4FD300BAB for ; Mon, 21 Sep 2020 16:23:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PCZjLHXqBCEB for ; Mon, 21 Sep 2020 16:23:36 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 26CBB300B3C; Mon, 21 Sep 2020 16:23:36 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_31CB3E26-7BF4-4380-8339-E971CB4B65C1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Mon, 21 Sep 2020 16:23:36 -0400 In-Reply-To: <8EC6DB09-5959-42CE-A218-98BCA2E103D5@vigilsec.com> Cc: "tools-implementation@ietf.org" , Jay Daley To: Robert Sparks References: <8EC6DB09-5959-42CE-A218-98BCA2E103D5@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Tools-implementation] Rough draft of message to the community re Zulip and Matrix X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 20:23:43 -0000 --Apple-Mail=_31CB3E26-7BF4-4380-8339-E971CB4B65C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The zulip client email did come, but it took a long time. The next = screen has Glen's email address. Shouldn't it have action@ietf.org = ? Russ > On Sep 21, 2020, at 4:10 PM, Russ Housley = wrote: >=20 > Robert: >=20 > Comments below. >=20 > Russ >=20 >=20 >> On Sep 21, 2020, at 3:20 PM, Robert Sparks = wrote: >>=20 >> All - >>=20 >> First, note that Glen is offline this week, and I do not expect him = to see any of this conversation until he returns. But please don't wait = for him to refine this. I would like to have it in a form that we can = send by early next week. >>=20 >> Please point out (and offer text for) missing things that need to be = addressed in this initial message. >>=20 >> =3D=3D=3D=3D >>=20 >> We are deploying trials of the matrix and zulip chat services to gain >> operational experience and get community feedback about how well = these services >> meet the need for IETF related chat. >=20 > Is thee a sentence or two you can add about the things that we hope = will be better than the current solution? >=20 > We expect the chat to support face-to-face IETF meetings, virtual = meetings, interim meetings, and virtual hallway discussions. We should = say that all of these are dimensions to consider. >=20 >>=20 >> The installs currently have almost no local configuration or = customization. >> Over the next few weeks, we will be exploring reconfiguring them to = use >> datatracker credentials for sign-in, and explore bridging between = these systems, >> Slack, and Jabber. >>=20 >> The secretariat is operating each instance. We've chosen this path = for these >> trials over third party hosting to learn what would be needed if the = community >> felt self-hosting was important in the longer term. >>=20 >> The services can be found at matrix-trial1.ietf.org and = zulip-trial1.ietf.org. >>=20 >> Any matrix client can be used with the trial matrix server. We are = also hosting >> an instance of the element web client at matrix-trial1.ietf.org. >=20 > ... there is also a web client available at matrix-trial1.ietf.org.=20 >=20 > It currently refuses to create an account with "common" names that are = easy to guess. This does not seem ideal for the IETF community. >=20 > This should tell people what convention we want to use for these = accounts. >=20 >>=20 >> Similarly any zulip client can be used with the trial zulip server, = which has a >> built in web interface. >=20 > It currently uses your email address, which is not bad for the IETF. = However, I never got the email when I tried to create an account. = Probably needs plumbing into the IETF mail system. >=20 > This should tell people that their email address will be used, and ask = them ti use the email address known to the datatracker. >=20 >>=20 >> Around December, we will assess our experiences and the feedback = received to >> inform what chat services we provide in the future and how we will = operate >=20 > Where do we want them to provide feedback? >=20 >> them. In January, these trial instances will be taken down. We do not = intend to >> preserve or migrate any account configuration or chat history from = the trial >> instances as we move forward. >>=20 >> This does add to the potentially confusing large number of places = conversation >> might take place. We hope to address that with some level of = bridging, at least >> with Jabber, but have been cautioned by the respective development = communities >> that bridging between Zulip and Matrix is unsatisfying since the = conversation >> models in the two applications are so different. >>=20 >> The chat services are intended to be explorational and informal. = However, >> please treat them as contexts where participation rules apply (See >=20 > ... IETF participation ... >=20 > Some would argue that NOTE WELL applies to contributes, not = participation. You may want to word smith to avoid that tussle. >=20 >> https://www.ietf.org/about/note-well/). >>=20 >> We are not, at this time, planning to host jabber accounts. We may = revisit that >> as an option as we continue to gather more feedback. >=20 --Apple-Mail=_31CB3E26-7BF4-4380-8339-E971CB4B65C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = zulip client email did come, but it took a long time.  The next = screen has Glen's email address.  Shouldn't it have action@ietf.org?

Russ


On Sep 21, 2020, at 4:10 PM, Russ Housley = <housley@vigilsec.com> wrote:

Robert:

Comments below.

Russ


On Sep 21, 2020, at 3:20 = PM, Robert Sparks <rjsparks@nostrum.com> wrote:

All -

First, note that Glen is = offline this week, and I do not expect him to see any of this = conversation until he returns. But please don't wait for him to refine = this. I would like to have it in a form that we can send by early next = week.

Please point out (and offer text for) = missing things that need to be addressed in this initial message.

=3D=3D=3D=3D

We = are deploying trials of the matrix and zulip chat services to gain
operational experience and get community feedback about how = well these services
meet the need for IETF related = chat.

Is thee a sentence or = two you can add about the things that we hope will be better than the = current solution?

We expect the chat to = support face-to-face IETF meetings, virtual meetings, interim meetings, = and virtual hallway discussions.  We should say that all of these = are dimensions to consider.


The installs currently have = almost no local configuration or customization.
Over the = next few weeks, we will be exploring reconfiguring them to use
datatracker credentials for sign-in, and explore bridging = between these systems,
Slack, and Jabber.

The secretariat is operating each instance. We've chosen this = path for these
trials over third party hosting to learn = what would be needed if the community
felt self-hosting = was important in the longer term.

The = services can be found at matrix-trial1.ietf.org and zulip-trial1.ietf.org.

Any = matrix client can be used with the trial matrix server. We are also = hosting
an instance of the element web client at matrix-trial1.ietf.org.

... there is also a web client available at matrix-trial1.ietf.org.

It = currently refuses to create an account with "common" names that are easy = to guess.  This does not seem ideal for the IETF community.

This should tell people what convention we = want to use for these accounts.


Similarly any zulip client can = be used with the trial zulip server, which has a
built in = web interface.

It currently = uses your email address, which is not bad for the IETF.  However, I = never got the email when I tried to create an account.  Probably = needs plumbing into the IETF mail system.

This should tell people that their email address will be = used, and ask them ti use the email address known to the datatracker.


Around December, we will assess our experiences and the = feedback received to
inform what chat services we provide = in the future and how we will operate

Where do we want them to provide feedback?

them. In January, these = trial instances will be taken down. We do not intend to
preserve or migrate any account configuration or chat history = from the trial
instances as we move forward.

This does add to the potentially confusing = large number of places conversation
might take place. We = hope to address that with some level of bridging, at least
with Jabber, but have been cautioned by the respective = development communities
that bridging between Zulip and = Matrix is unsatisfying since the conversation
models in = the two applications are so different.

The = chat services are intended to be explorational and informal. However,
please treat them as contexts where participation rules apply = (See

... IETF participation = ...

Some would argue that NOTE WELL applies = to contributes, not participation.  You may want to word smith to = avoid that tussle.

https://www.ietf.org/about/note-well/).

We are not, at this time, planning to host jabber accounts. = We may revisit that
as an option as we continue to gather = more feedback.


= --Apple-Mail=_31CB3E26-7BF4-4380-8339-E971CB4B65C1-- From nobody Mon Sep 21 13:29:32 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903333A0901 for ; Mon, 21 Sep 2020 13:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PYX-9RlFqLD8 for ; Mon, 21 Sep 2020 13:29:30 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99773A08F8 for ; Mon, 21 Sep 2020 13:29:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7AF4D300B3C for ; Mon, 21 Sep 2020 16:29:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8BPe45YWwPsC for ; Mon, 21 Sep 2020 16:29:25 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id F19C6300BA2; Mon, 21 Sep 2020 16:29:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: Date: Mon, 21 Sep 2020 16:29:25 -0400 Cc: "tools-implementation@ietf.org" , Jay Daley Content-Transfer-Encoding: quoted-printable Message-Id: References: <8EC6DB09-5959-42CE-A218-98BCA2E103D5@vigilsec.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Tools-implementation] Rough draft of message to the community re Zulip and Matrix X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 20:29:32 -0000 > On Sep 21, 2020, at 4:18 PM, Robert Sparks = wrote: >=20 > a couple of quick responses inline >=20 > On 9/21/20 3:10 PM, Russ Housley wrote: >> Robert: >>=20 >> Comments below. >>=20 >> Russ >>=20 >>=20 >>> On Sep 21, 2020, at 3:20 PM, Robert Sparks = wrote: >>>=20 >>> All - >>>=20 >>> First, note that Glen is offline this week, and I do not expect him = to see any of this conversation until he returns. But please don't wait = for him to refine this. I would like to have it in a form that we can = send by early next week. >>>=20 >>> Please point out (and offer text for) missing things that need to be = addressed in this initial message. >>>=20 >>> =3D=3D=3D=3D >>>=20 >>> We are deploying trials of the matrix and zulip chat services to = gain >>> operational experience and get community feedback about how well = these services >>> meet the need for IETF related chat. >> Is thee a sentence or two you can add about the things that we hope = will be better than the current solution? >>=20 >> We expect the chat to support face-to-face IETF meetings, virtual = meetings, interim meetings, and virtual hallway discussions. We should = say that all of these are dimensions to consider. >>=20 >>> The installs currently have almost no local configuration or = customization. >>> Over the next few weeks, we will be exploring reconfiguring them to = use >>> datatracker credentials for sign-in, and explore bridging between = these systems, >>> Slack, and Jabber. >>>=20 >>> The secretariat is operating each instance. We've chosen this path = for these >>> trials over third party hosting to learn what would be needed if the = community >>> felt self-hosting was important in the longer term. >>>=20 >>> The services can be found at matrix-trial1.ietf.org and = zulip-trial1.ietf.org. >>>=20 >>> Any matrix client can be used with the trial matrix server. We are = also hosting >>> an instance of the element web client at matrix-trial1.ietf.org. >> ... there is also a web client available at matrix-trial1.ietf.org. >>=20 >> It currently refuses to create an account with "common" names that = are easy to guess. This does not seem ideal for the IETF community. >>=20 >> This should tell people what convention we want to use for these = accounts. >=20 > Expand please? >=20 > I don't think this initial message should be speaking at the level of = "what your account name can look like". I also don't think we want to = try to start changing the configuration to route around this kind of = issue (unless we're forced to to make progress). Letting people see = these kinds of edges are part of why we're running this as a trial set = of services. Do we want them to use their email address or some handle? I was = surprised that "housley" was rejected. I think we want to tell people = enough that they do not get surprised. >=20 >>=20 >>> Similarly any zulip client can be used with the trial zulip server, = which has a >>> built in web interface. >> It currently uses your email address, which is not bad for the IETF. = However, I never got the email when I tried to create an account. >=20 > Something we'll have to wait for Glen to get back online for to = diagnose. It came, but it took a long time. We may want to tell people to expect = that ... >=20 >> Probably needs plumbing into the IETF mail system. >>=20 >> This should tell people that their email address will be used, and = ask them ti use the email address known to the datatracker. >=20 > Well, as we get a week or two in, we may integrate accounts with the = datatracker anyhow, so it may be moot. >=20 > But I don't think we should wait on getting that integration working = beforew we start getting feedback. I've already called out that we will = be making changes like that. It will be easy if the user names are the same. It will be a bigger = pain if they have to make a new account. >=20 >>=20 >>> Around December, we will assess our experiences and the feedback = received to >>> inform what chat services we provide in the future and how we will = operate >> Where do we want them to provide feedback? > I think tools-discuss >>=20 >>> them. In January, these trial instances will be taken down. We do = not intend to >>> preserve or migrate any account configuration or chat history from = the trial >>> instances as we move forward. >>>=20 >>> This does add to the potentially confusing large number of places = conversation >>> might take place. We hope to address that with some level of = bridging, at least >>> with Jabber, but have been cautioned by the respective development = communities >>> that bridging between Zulip and Matrix is unsatisfying since the = conversation >>> models in the two applications are so different. >>>=20 >>> The chat services are intended to be explorational and informal. = However, >>> please treat them as contexts where participation rules apply (See >> ... IETF participation ... >>=20 >> Some would argue that NOTE WELL applies to contributes, not = participation. You may want to word smith to avoid that tussle. >>=20 >>> https://www.ietf.org/about/note-well/). >>>=20 >>> We are not, at this time, planning to host jabber accounts. We may = revisit that >>> as an option as we continue to gather more feedback. >=20 > --=20 > Tools-implementation mailing list > Tools-implementation@ietf.org > https://www.ietf.org/mailman/listinfo/tools-implementation From nobody Mon Sep 21 13:29:41 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAB83A08F8 for ; Mon, 21 Sep 2020 13:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 W607hwGIcbvj; Mon, 21 Sep 2020 13:29:38 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id E24933A08EC; Mon, 21 Sep 2020 13:29:36 -0700 (PDT) From: Jay Daley Message-Id: <6B880295-8288-433B-A6B5-17C03076C7ED@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_8BA1007E-43EE-4403-8021-AB9494A7C51B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 22 Sep 2020 08:29:34 +1200 In-Reply-To: <8EC6DB09-5959-42CE-A218-98BCA2E103D5@vigilsec.com> Cc: Robert Sparks , "tools-implementation@ietf.org" To: Russ Housley References: <8EC6DB09-5959-42CE-A218-98BCA2E103D5@vigilsec.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Tools-implementation] Rough draft of message to the community re Zulip and Matrix X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 20:29:40 -0000 --Apple-Mail=_8BA1007E-43EE-4403-8021-AB9494A7C51B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22/09/2020, at 8:10 AM, Russ Housley wrote: >=20 > Robert: >=20 > Comments below. >=20 > Russ >=20 >=20 >> On Sep 21, 2020, at 3:20 PM, Robert Sparks = wrote: >>=20 >> All - >>=20 >> First, note that Glen is offline this week, and I do not expect him = to see any of this conversation until he returns. But please don't wait = for him to refine this. I would like to have it in a form that we can = send by early next week. >>=20 >> Please point out (and offer text for) missing things that need to be = addressed in this initial message. >>=20 >> =3D=3D=3D=3D >>=20 >> We are deploying trials of the matrix and zulip chat services to gain >> operational experience and get community feedback about how well = these services >> meet the need for IETF related chat. >=20 > Is thee a sentence or two you can add about the things that we hope = will be better than the current solution? "We have clear evidence from the IETF 107 post-meeting survey = (https://www.ietf.org/media/documents/ietf-107-survey-results.pdf = ) that = many IETF participants find jabber a significant problem This is partly = due to difficulties in finding a free jabber service and partly due to = client issues. There are two paths to try to resolve these problems, = one is to improve the IETF jabber service and the other is to switch to = an alternative groupchat solution. The community has already taken a = step on the latter path with the introduction of an IETF Slack space, = and we want to ensure that this path is properly explored by widening = the range of options to well established free/open source tools."=20 >=20 > We expect the chat to support face-to-face IETF meetings, virtual = meetings, interim meetings, and virtual hallway discussions. We should = say that all of these are dimensions to consider. >=20 >>=20 >> The installs currently have almost no local configuration or = customization. >> Over the next few weeks, we will be exploring reconfiguring them to = use >> datatracker credentials for sign-in, and explore bridging between = these systems, >> Slack, and Jabber. >>=20 >> The secretariat is operating each instance. We've chosen this path = for these >> trials over third party hosting to learn what would be needed if the = community >> felt self-hosting was important in the longer term. >>=20 >> The services can be found at matrix-trial1.ietf.org and = zulip-trial1.ietf.org. >>=20 >> Any matrix client can be used with the trial matrix server. We are = also hosting >> an instance of the element web client at matrix-trial1.ietf.org. >=20 > ... there is also a web client available at matrix-trial1.ietf.org = .=20 >=20 > It currently refuses to create an account with "common" names that are = easy to guess. This does not seem ideal for the IETF community. >=20 > This should tell people what convention we want to use for these = accounts. >=20 >>=20 >> Similarly any zulip client can be used with the trial zulip server, = which has a >> built in web interface. >=20 > It currently uses your email address, which is not bad for the IETF. = However, I never got the email when I tried to create an account. = Probably needs plumbing into the IETF mail system. >=20 > This should tell people that their email address will be used, and ask = them ti use the email address known to the datatracker. >=20 >>=20 >> Around December, we will assess our experiences and the feedback = received to >> inform what chat services we provide in the future and how we will = operate >=20 > Where do we want them to provide feedback? >=20 >> them. In January, these trial instances will be taken down. We do not = intend to >> preserve or migrate any account configuration or chat history from = the trial >> instances as we move forward. >>=20 >> This does add to the potentially confusing large number of places = conversation >> might take place. We hope to address that with some level of = bridging, at least >> with Jabber, but have been cautioned by the respective development = communities >> that bridging between Zulip and Matrix is unsatisfying since the = conversation >> models in the two applications are so different. >>=20 >> The chat services are intended to be explorational and informal. = However, >> please treat them as contexts where participation rules apply (See >=20 > ... IETF participation ... >=20 > Some would argue that NOTE WELL applies to contributes, not = participation. You may want to word smith to avoid that tussle. I suggest "treat them as contexts where contribution rules apply" as = 'contribution' is specifically defined to include groupchat messages. Jay >=20 >> https://www.ietf.org/about/note-well/ = ). >>=20 >> We are not, at this time, planning to host jabber accounts. We may = revisit that >> as an option as we continue to gather more feedback. --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_8BA1007E-43EE-4403-8021-AB9494A7C51B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 22/09/2020, at 8:10 AM, Russ Housley <housley@vigilsec.com> wrote:

Robert:

Comments below.

Russ


On = Sep 21, 2020, at 3:20 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

All -

First, note that Glen is = offline this week, and I do not expect him to see any of this = conversation until he returns. But please don't wait for him to refine = this. I would like to have it in a form that we can send by early next = week.

Please point out (and offer text for) = missing things that need to be addressed in this initial message.

=3D=3D=3D=3D

We = are deploying trials of the matrix and zulip chat services to gain
operational experience and get community feedback about how = well these services
meet the need for IETF related = chat.

Is thee a sentence or two you can add about the things that = we hope will be better than the current solution?

"We have = clear evidence from the IETF 107 post-meeting survey  (https://www.ietf.org/media/documents/ietf-107-survey-results.pd= f) that many IETF participants find jabber a significant problem =  This is partly due to difficulties in finding a free jabber = service and partly due to client issues.  There are two paths to = try to resolve these problems, one is to improve the IETF jabber service = and the other is to switch to an alternative groupchat solution. =  The community has already taken a step on the latter path with the = introduction of an IETF Slack space, and we want to ensure that this = path is properly explored by widening the range of options to well = established free/open source tools." 


We expect the chat to support face-to-face IETF meetings, = virtual meetings, interim meetings, and virtual hallway discussions. =  We should say that all of these are dimensions to = consider.


The installs currently have almost no local configuration or = customization.
Over the next few weeks, we will be = exploring reconfiguring them to use
datatracker = credentials for sign-in, and explore bridging between these systems,
Slack, and Jabber.

The = secretariat is operating each instance. We've chosen this path for = these
trials over third party hosting to learn what would = be needed if the community
felt self-hosting was important = in the longer term.

The services can be = found at matrix-trial1.ietf.org and zulip-trial1.ietf.org.

Any = matrix client can be used with the trial matrix server. We are also = hosting
an instance of the element web client at matrix-trial1.ietf.org.

... there is also a web client = available at matrix-trial1.ietf.org. 

It currently refuses to create = an account with "common" names that are easy to guess.  This does = not seem ideal for the IETF community.

This should tell people what convention we want to use for = these accounts.


Similarly any zulip = client can be used with the trial zulip server, which has a
built in web interface.

It currently uses your email = address, which is not bad for the IETF.  However, I never got the = email when I tried to create an account.  Probably needs plumbing = into the IETF mail system.

This should tell people that their email address will be = used, and ask them ti use the email address known to the = datatracker.


Around December, we will assess our experiences and the = feedback received to
inform what chat services we provide = in the future and how we will operate

Where do we want them to provide = feedback?

them. = In January, these trial instances will be taken down. We do not intend = to
preserve or migrate any account configuration or chat = history from the trial
instances as we move forward.

This does add to the potentially confusing = large number of places conversation
might take place. We = hope to address that with some level of bridging, at least
with Jabber, but have been cautioned by the respective = development communities
that bridging between Zulip and = Matrix is unsatisfying since the conversation
models in = the two applications are so different.

The = chat services are intended to be explorational and informal. However,
please treat them as contexts where participation rules apply = (See

... IETF participation ...

Some would argue that NOTE WELL applies to contributes, not = participation.  You may want to word smith to avoid that = tussle.

I = suggest "treat them as contexts where contribution rules apply" as = 'contribution' is specifically defined to include groupchat = messages.

Jay


https://www.ietf.org/about/note-well/).

We are not, at this time, planning to host jabber accounts. = We may revisit that
as an option as we continue to gather = more feedback.

-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_8BA1007E-43EE-4403-8021-AB9494A7C51B-- From nobody Mon Sep 21 13:45:15 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9433A09BC for ; Mon, 21 Sep 2020 13:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 sf-Vx0zMZCT0 for ; Mon, 21 Sep 2020 13:45:11 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59403A09BB for ; Mon, 21 Sep 2020 13:45:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 13CF3300BA4 for ; Mon, 21 Sep 2020 16:45:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 40A0NqlJ3iTv for ; Mon, 21 Sep 2020 16:45:07 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 13F77300AA2 for ; Mon, 21 Sep 2020 16:45:07 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_1611D99D-8E48-49B7-B52F-679E25FF3B93" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: <3BFB4F6F-243A-40B1-8950-7EEF9B83E980@vigilsec.com> References: <160071988057.1616496.9243245802705986514@zulip-trial1.ietf.org> To: tools-implementation@ietf.org Date: Mon, 21 Sep 2020 16:45:07 -0400 X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [Tools-implementation] Fwd: IETF Zulip Trial 1 on Zulip: Your new account details X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 20:45:13 -0000 --Apple-Mail=_1611D99D-8E48-49B7-B52F-679E25FF3B93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just got this message ... This should have a return address other than Glen. Russ > From: Zulip > Subject: IETF Zulip Trial 1 on Zulip: Your new account details > Date: September 21, 2020 at 4:24:40 PM EDT > To: Russ Housley >=20 > =09 > >=20 > Welcome to Zulip! >=20 > You've joined the Zulip organization IETF Zulip Trial 1. >=20 > Your account details: >=20 > Organization URL: https://zulip-trial1.ietf.org = > Email: housley@vigilsec.com > (you'll need these to sign in to the mobile and desktop = apps) > Learn more about Zulip, become a pro with a few = keyboard shortcuts = , or dive right = in ! >=20 > Cheers, > Team Zulip >=20 > PS: Follow us on Twitter , star us on = GitHub , or chat with us live on the = Zulip community server ! >=20 >=20 > =20 --Apple-Mail=_1611D99D-8E48-49B7-B52F-679E25FF3B93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = got this message ...

This should have a return address other than Glen.

Russ

From: = Zulip <glen@amsl.com>
Subject: = IETF Zulip Trial = 1 on Zulip: Your new account details
Date: = September 21, 2020 at 4:24:40 = PM EDT
To: = Russ Housley <housley@vigilsec.com>

 
3D""

Welcome to Zulip!

You've joined the Zulip organization IETF Zulip = Trial 1.

Your account = details:

  • Organization URL: https://zulip-trial1.ietf.org
  • Email: housley@vigilsec.com
    • (you'll need = these to sign in to the mobile and desktop apps)

    Learn more about Zulip, become a pro = with a few keyboard shortcuts, or dive right in!

    Cheers,
    Team Zulip

    PS: Follow us on Twitter, star us on GitHub, or chat with = us live on the Zulip community = server!

    3D"Swimming
    		 

    = --Apple-Mail=_1611D99D-8E48-49B7-B52F-679E25FF3B93-- From nobody Fri Sep 25 11:19:00 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588BF3A1408; Fri, 25 Sep 2020 11:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 tbvhglBd6TYr; Fri, 25 Sep 2020 11:18:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 DC5AC3A1404; Fri, 25 Sep 2020 11:18:56 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08PIImXc006036 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 25 Sep 2020 13:18:54 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1601057936; bh=uVcNO1KLBAIiUP/aWgiGkf1BXJi/oGXcxgu6eBcmq10=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=QaPqdu/PHjdiAkT8QK6jZ/JdMYc2PkrxWl8UT2Uqjk09GEPgiZOEKqgUdFIOWxvXf bzpI0zZ+dds0tsfttELQTmFYeeG/1R9wazlOkP6RfP3JQ81CyyyuEpyUFmAy0mS6iT TuHPUrU9En6pJWK4QKw/4QjtVduF+UXhGllx+H28= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Jay Daley , Russ Housley Cc: "tools-implementation@ietf.org" References: <8EC6DB09-5959-42CE-A218-98BCA2E103D5@vigilsec.com> <6B880295-8288-433B-A6B5-17C03076C7ED@ietf.org> From: Robert Sparks Message-ID: Date: Fri, 25 Sep 2020 13:18:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <6B880295-8288-433B-A6B5-17C03076C7ED@ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix) X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 18:18:58 -0000 I think this reflects the comments so far, with the exception of not talking about the potential delay for the zulip email message. Lets wait for Glen to have an opportunity to look/tweak before we talk about that. ----- We are deploying trials of the matrix and zulip chat services to gain operational experience and get community feedback about how well these services meet the need for IETF related chat. We have clear evidence from the IETF 107 post-meeting survey (https://www.ietf.org/media/documents/ietf-107-survey-results.pdf) that many IETF participants find jabber a significant problem.  This is partly due to difficulties in finding a free jabber service and partly due to client issues.  There are two paths to try to resolve these problems, one is to improve the IETF jabber service and the other is to switch to an alternative groupchat solution.  The community has already taken a step on the latter path with the introduction of an IETF Slack space, and we want to ensure that this path is properly explored by widening the range of options to well established free/open source tools. The installs currently have almost no local configuration or customization. Over the next few weeks, we will be exploring reconfiguring them to use datatracker credentials for sign-in, and explore bridging between these systems, Slack, and Jabber. One consequence of these explorations is that there will  likely be times, outside of meetings, when accounts will be disrupted or even removed and will have to be recreated. Initially, we suggest you use an email address for the username on each service. The secretariat is operating each instance. We've chosen this path for these trials over third party hosting to learn what would be needed if the community felt self-hosting was important in the longer term. The services can be found at matrix-trial1.ietf.org and zulip-trial1.ietf.org. Any matrix client can be used with the trial matrix server. There is also a web client available at at matrix-trial1.ietf.org. Similarly any zulip client can be used with the trial zulip server, which has a built in web interface. We would like feedback on how well each client meets chat needs during meetings, both the full online IETF 109 meeting, virtuals, adhocs, and hallway conversations. Around December, we will assess our experiences and the feedback received to inform what chat services we provide in the future and how we will operate them. In January, these trial instances will be taken down. We do not intend to preserve or migrate any account configuration or chat history from the trial instances as we move forward. This does add to the potentially confusing large number of places conversation might take place. We hope to address that with some level of bridging, at least with Jabber, but have been cautioned by the respective development communities that bridging between Zulip and Matrix is unsatisfying since the conversation models in the two applications are so different. The chat services are intended to be explorational and informal. However, please treat them as contexts where contribution rules apply (See https://www.ietf.org/about/note-well/). We are not, at this time, planning to host jabber accounts. We may revisit that as an option as we continue to gather more feedback. Please send feedback on the services to tools-discuss@ietf.org From nobody Fri Sep 25 11:22:28 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FCD3A14F2 for ; Fri, 25 Sep 2020 11:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 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, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 yntQYbS9l26D for ; Fri, 25 Sep 2020 11:22:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6E56C3A15F7 for ; Fri, 25 Sep 2020 11:21:44 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08PILefM006952 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2020 13:21:43 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1601058103; bh=H51XFJbmJ89e1OzSnrl3LGHmlDSgnxL7Ip/1V+HVSHA=; h=Subject:To:References:From:Date:In-Reply-To; b=U9OSn6ZNaJDABCZODJTM5i4BDhXKMSdOHwh7tSWV69yFllM1HoxAqJg7qXpapfFuK VE60mtf+IWQyDTLHILi+d2ur4l/kwiQbL503aSzYjapSw7cL7j3gMzfqPy+ImHRL5S FlpxMlPK2ynH0E1rEUx0++hWoy+4qzMDNd4ttm78= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: tools-implementation@ietf.org References: <8EC6DB09-5959-42CE-A218-98BCA2E103D5@vigilsec.com> <6B880295-8288-433B-A6B5-17C03076C7ED@ietf.org> From: Robert Sparks Message-ID: Date: Fri, 25 Sep 2020 13:21:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix) X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 18:22:27 -0000 One edit to correct a mangle already: On 9/25/20 1:18 PM, Robert Sparks wrote: > I think this reflects the comments so far, with the exception of not > talking about the potential delay for the zulip email message. Lets > wait for Glen to have an opportunity to look/tweak before we talk > about that. > > ----- > > We are deploying trials of the matrix and zulip chat services to gain > operational experience and get community feedback about how well these > services > meet the need for IETF related chat. > > We have clear evidence from the IETF 107 post-meeting survey > (https://www.ietf.org/media/documents/ietf-107-survey-results.pdf) > that many > IETF participants find jabber a significant problem.  This is partly > due to > difficulties in finding a free jabber service and partly due to client > issues.  There are two paths to try to resolve these problems, one is to > improve the IETF jabber service and the other is to switch to an > alternative > groupchat solution.  The community has already taken a step on the latter > path with the introduction of an IETF Slack space, and we want to > ensure that > this path is properly explored by widening the range of options to well > established free/open source tools. > > The installs currently have almost no local configuration or > customization. > Over the next few weeks, we will be exploring reconfiguring them to use > datatracker credentials for sign-in, and explore bridging between these > systems, Slack, and Jabber. One consequence of these explorations is that > there will  likely be times, outside of meetings, when accounts will be > disrupted or even removed and will have to be recreated. Initially, we > suggest you use an email address for the username on each service. > > The secretariat is operating each instance. We've chosen this path for > these > trials over third party hosting to learn what would be needed if the > community > felt self-hosting was important in the longer term. > > The services can be found at matrix-trial1.ietf.org and > zulip-trial1.ietf.org. > > Any matrix client can be used with the trial matrix server. There is > also a > web client available at at matrix-trial1.ietf.org. > > Similarly any zulip client can be used with the trial zulip server, > which has a > built in web interface. > > We would like feedback on how well each client meets chat needs during > meetings, both the full online IETF 109 meeting, > virtuals, was meant to be "interims". > adhocs, and > hallway conversations. > > Around December, we will assess our experiences and the feedback > received to > inform what chat services we provide in the future and how we will > operate > them. In January, these trial instances will be taken down. We do not > intend to > preserve or migrate any account configuration or chat history from the > trial > instances as we move forward. > > This does add to the potentially confusing large number of places > conversation > might take place. We hope to address that with some level of bridging, > at least > with Jabber, but have been cautioned by the respective development > communities > that bridging between Zulip and Matrix is unsatisfying since the > conversation > models in the two applications are so different. > > The chat services are intended to be explorational and informal. However, > please treat them as contexts where contribution rules apply (See > https://www.ietf.org/about/note-well/). > > We are not, at this time, planning to host jabber accounts. We may > revisit that > as an option as we continue to gather more feedback. > > Please send feedback on the services to tools-discuss@ietf.org > > From nobody Mon Sep 28 09:52:46 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B483A12D2 for ; Mon, 28 Sep 2020 09:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 Ej-2Y9M9ZUvf for ; Mon, 28 Sep 2020 09:52:41 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7355F3A12D1 for ; Mon, 28 Sep 2020 09:52:41 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id A97413C2E55 for ; Mon, 28 Sep 2020 09:52:39 -0700 (PDT) Received: from [192.168.86.10] (173-8-133-94-SFBA.hfc.comcastbusiness.net [173.8.133.94]) by c8a.amsl.com (Postfix) with ESMTPSA id 9756A3C2E54 for ; Mon, 28 Sep 2020 09:52:39 -0700 (PDT) To: tools-implementation@ietf.org From: Glen Organization: AMS Message-ID: Date: Mon, 28 Sep 2020 09:52:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix) X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 16:52:45 -0000 Hi team - Hope you all had a good week. I've read the announcement below, I have only one comment. The paragraph starting with "The secretariat is operating" seems unnecessary from my point of view. The current expectation/perception of the community is that the secretariat operates the IETF's IT services. That's what we're contracted to do, that is in fact my job. In addition, we already know that the community has privacy issues, so we could assume that self-hosting is at least not an aversion point. Therefore, the things stated in that paragraph are already the norm. I could expand on this if desired, but, to keep things brief, I'd recommend removing that entire paragraph. If we decide to go public-cloud later, we can and should open that as a separate topic. For now, the paragraph says nothing new, and adds unnecessary wording to the announcement. Other than that (and Robert's subsequent tweak) I have no further thoughts right now! Also I saw the commentary about "glen@amsl.com" in the emails. When running the initial install script, the script takes two parameters - the server FQDN, and the server (human) administrator account. I provided my own email address as the first account to create, which is where Zulip got this. This was unanticipated, but I guess something to "learn" through these tests. If we end up using Zulip in a permanent state, we will of course know about this and choose a better address/account/alias for this. For now, I will look through and see if this can be safely changed via a setting, as I have time. I note that the message doesn't *require* contact, but just *offers* my address as a human contact point: >> Contact us any time at glen@amsl.com if you run into trouble, have any feedback, or just want to chat! I don't think we should delay announcement until this can be changed; I don't think for a test instance this is a big deal, but I will still look, because I don't want those emails. :-) But I'm fine with whatever you all decide. Glen > We are deploying trials of the matrix and zulip chat services to gain > operational experience and get community feedback about how well these > services > meet the need for IETF related chat. > > We have clear evidence from the IETF 107 post-meeting survey > (https://www.ietf.org/media/documents/ietf-107-survey-results.pdf) that many > IETF participants find jabber a significant problem. This is partly due to > difficulties in finding a free jabber service and partly due to client > issues. There are two paths to try to resolve these problems, one is to > improve the IETF jabber service and the other is to switch to an alternative > groupchat solution. The community has already taken a step on the latter > path with the introduction of an IETF Slack space, and we want to ensure > that > this path is properly explored by widening the range of options to well > established free/open source tools. > > The installs currently have almost no local configuration or customization. > Over the next few weeks, we will be exploring reconfiguring them to use > datatracker credentials for sign-in, and explore bridging between these > systems, Slack, and Jabber. One consequence of these explorations is that > there will likely be times, outside of meetings, when accounts will be > disrupted or even removed and will have to be recreated. Initially, we > suggest you use an email address for the username on each service. > > The secretariat is operating each instance. We've chosen this path for these > trials over third party hosting to learn what would be needed if the > community > felt self-hosting was important in the longer term. > > The services can be found at matrix-trial1.ietf.org and > zulip-trial1.ietf.org. > > Any matrix client can be used with the trial matrix server. There is also a > web client available at at matrix-trial1.ietf.org. > > Similarly any zulip client can be used with the trial zulip server, > which has a > built in web interface. > > We would like feedback on how well each client meets chat needs during > meetings, both the full online IETF 109 meeting, virtuals, adhocs, and > hallway conversations. > > Around December, we will assess our experiences and the feedback received to > inform what chat services we provide in the future and how we will operate > them. In January, these trial instances will be taken down. We do not > intend to > preserve or migrate any account configuration or chat history from the trial > instances as we move forward. > > This does add to the potentially confusing large number of places > conversation > might take place. We hope to address that with some level of bridging, > at least > with Jabber, but have been cautioned by the respective development > communities > that bridging between Zulip and Matrix is unsatisfying since the > conversation > models in the two applications are so different. > > The chat services are intended to be explorational and informal. However, > please treat them as contexts where contribution rules apply (See > https://www.ietf.org/about/note-well/). > > We are not, at this time, planning to host jabber accounts. We may > revisit that > as an option as we continue to gather more feedback. > > Please send feedback on the services to tools-discuss@ietf.org From nobody Mon Sep 28 09:58:46 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8CD3A1009 for ; Mon, 28 Sep 2020 09:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 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, NICE_REPLY_A=-0.213, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 WwEL_S7sb5Yr for ; Mon, 28 Sep 2020 09:58:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C90F63A1005 for ; Mon, 28 Sep 2020 09:58:43 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08SGwdRI070840 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2020 11:58:43 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1601312323; bh=FCYZOoLPfKIzZc4si6ZaDuIymB4aUa3rpVjsuw5dGA4=; h=Subject:To:References:From:Date:In-Reply-To; b=MERo7K6UoxRHb90rBdAjzEkvaClt47WuwESfz3txt1ofcUWnbj+Ko/fJPorO7gK/q a43iUYeNq2r1R4fhnPYtRUOx81stdHl4JivUgUu+7rAL9ldAZikzreRSHUIkgNNTlS E9HnZtaqQ+1c36YsB7L2uEnRJ/44Hr+FnJjvogII= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: tools-implementation@ietf.org References: From: Robert Sparks Message-ID: <82db14a0-8518-b7cb-596b-3b0eb0af0346@nostrum.com> Date: Mon, 28 Sep 2020 11:58:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix) X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 16:58:46 -0000 On 9/28/20 11:52 AM, Glen wrote: > Hi team - > > Hope you all had a good week. > > I've read the announcement below, I have only one comment.  The > paragraph starting with "The secretariat is operating" seems > unnecessary from my point of view.  The current expectation/perception > of the community is that the secretariat operates the IETF's IT services. The point of the sentence is to answer "why aren't we taking advantage of the offers other groups have made to host". > That's what we're contracted to do, that is in fact my job.  In > addition, we already know that the community has privacy issues, so we > could assume that self-hosting is at least not an aversion point. > Therefore, the things stated in that paragraph are already the norm. > > I could expand on this if desired, but, to keep things brief, I'd > recommend removing that entire paragraph. I think it is quite necessary. > If we decide to go public-cloud later, we can and should open that as > a separate topic. For now, the paragraph says nothing new, and adds > unnecessary wording to the announcement. > > Other than that (and Robert's subsequent tweak) I have no further > thoughts right now! > > Also I saw the commentary about "glen@amsl.com" in the emails. When > running the initial install script, the script takes two parameters - > the server FQDN, and the server (human) administrator account.  I > provided my own email address as the first account to create, which is > where Zulip got this. > > This was unanticipated, but I guess something to "learn" through these > tests.  If we end up using Zulip in a permanent state, we will of > course know about this and choose a better address/account/alias for > this.  For now, I will look through and see if this can be safely > changed via a setting, as I have time. > > I note that the message doesn't *require* contact, but just *offers* > my address as a human contact point: > > >> Contact us any time at glen@amsl.com if you > run into trouble, have any feedback, or just want to chat! > > I don't think we should delay announcement until this can be changed; > I don't think for a test instance this is a big deal, but I will still > look, because I don't want those emails.  :-)   But I'm fine with > whatever you all decide. > > Glen > > >> We are deploying trials of the matrix and zulip chat services to gain >> operational experience and get community feedback about how well >> these services >> meet the need for IETF related chat. >> >> We have clear evidence from the IETF 107 post-meeting survey >> (https://www.ietf.org/media/documents/ietf-107-survey-results.pdf) >> that many >> IETF participants find jabber a significant problem.  This is partly >> due to >> difficulties in finding a free jabber service and partly due to client >> issues.  There are two paths to try to resolve these problems, one is to >> improve the IETF jabber service and the other is to switch to an >> alternative >> groupchat solution.  The community has already taken a step on the >> latter >> path with the introduction of an IETF Slack space, and we want to >> ensure that >> this path is properly explored by widening the range of options to well >> established free/open source tools. >> >> The installs currently have almost no local configuration or >> customization. >> Over the next few weeks, we will be exploring reconfiguring them to use >> datatracker credentials for sign-in, and explore bridging between these >> systems, Slack, and Jabber. One consequence of these explorations is >> that >> there will  likely be times, outside of meetings, when accounts will be >> disrupted or even removed and will have to be recreated. Initially, we >> suggest you use an email address for the username on each service. >> >> The secretariat is operating each instance. We've chosen this path >> for these >> trials over third party hosting to learn what would be needed if the >> community >> felt self-hosting was important in the longer term. >> >> The services can be found at matrix-trial1.ietf.org and >> zulip-trial1.ietf.org. >> >> Any matrix client can be used with the trial matrix server. There is >> also a >> web client available at at matrix-trial1.ietf.org. >> >> Similarly any zulip client can be used with the trial zulip server, >> which has a >> built in web interface. >> >> We would like feedback on how well each client meets chat needs during >> meetings, both the full online IETF 109 meeting, virtuals, adhocs, and >> hallway conversations. >> >> Around December, we will assess our experiences and the feedback >> received to >> inform what chat services we provide in the future and how we will >> operate >> them. In January, these trial instances will be taken down. We do not >> intend to >> preserve or migrate any account configuration or chat history from >> the trial >> instances as we move forward. >> >> This does add to the potentially confusing large number of places >> conversation >> might take place. We hope to address that with some level of >> bridging, at least >> with Jabber, but have been cautioned by the respective development >> communities >> that bridging between Zulip and Matrix is unsatisfying since the >> conversation >> models in the two applications are so different. >> >> The chat services are intended to be explorational and informal. >> However, >> please treat them as contexts where contribution rules apply (See >> https://www.ietf.org/about/note-well/). >> >> We are not, at this time, planning to host jabber accounts. We may >> revisit that >> as an option as we continue to gather more feedback. >> >> Please send feedback on the services to tools-discuss@ietf.org > From nobody Mon Sep 28 10:22:03 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1E3A12E2 for ; Mon, 28 Sep 2020 10:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 pYf9R53uuXr2 for ; Mon, 28 Sep 2020 10:22:00 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF9C3A1004 for ; Mon, 28 Sep 2020 10:21:59 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 3BB653C2F2A for ; Mon, 28 Sep 2020 10:21:57 -0700 (PDT) Received: from [192.168.86.10] (173-8-133-94-SFBA.hfc.comcastbusiness.net [173.8.133.94]) by c8a.amsl.com (Postfix) with ESMTPSA id 2BE413C2F29 for ; Mon, 28 Sep 2020 10:21:57 -0700 (PDT) To: tools-implementation@ietf.org References: From: Glen Organization: AMS Message-ID: <1978b20a-b829-85a9-a250-6944652df040@amsl.com> Date: Mon, 28 Sep 2020 10:21:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix) X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 17:22:03 -0000 On 9/28/2020 09:52, Glen wrote: > Also I saw the commentary about "glen@amsl.com" in the emails. I've located the setting, and can change it. What do we want to change it to? We could change it to ietf-action@ietf.org, but then our ticket system will get requests for help here. Is that desired? Maybe we should do a separate alias? Or we could just leave the test as is, whichever. Glen From nobody Mon Sep 28 10:28:02 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B251C3A12EA for ; Mon, 28 Sep 2020 10:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 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, NICE_REPLY_A=-0.213, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 iWqbQA-Es_O6 for ; Mon, 28 Sep 2020 10:27:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 564483A12E9 for ; Mon, 28 Sep 2020 10:27:59 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08SHRqZx080909 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2020 12:27:57 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1601314077; bh=tVeRSgDxgheZ7NrvoSYAq9tC49FFg13ff20T+xgic9Y=; h=Subject:To:References:From:Date:In-Reply-To; b=hG+EiW1/JFjvKpbk+WQ9Qtx8dx5A/ypQv1aSSJSfn+SpHBRWt8Hx4ihjczAFnQVvn CizU4FPBhB3jI5TXBnpCwne6hgLoKJ+GwjZAWS9lyWBPhYZCYIRpSYllbFoCNeWKyr nN669fFXL/S7Z1mIMyIQ2mLaunUkkmEJJQspNy+k= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: tools-implementation@ietf.org References: <1978b20a-b829-85a9-a250-6944652df040@amsl.com> From: Robert Sparks Message-ID: <2dfef357-d4b4-a6e8-d95b-85ceb78e764a@nostrum.com> Date: Mon, 28 Sep 2020 12:27:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <1978b20a-b829-85a9-a250-6944652df040@amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix) X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 17:28:01 -0000 On 9/28/20 12:21 PM, Glen wrote: > On 9/28/2020 09:52, Glen wrote: >> Also I saw the commentary about "glen@amsl.com" in the emails. > > I've located the setting, and can change it. > > What do we want to change it to? > > We could change it to ietf-action@ietf.org, but then our ticket system > will get requests for help here.  Is that desired? > > Maybe we should do a separate alias? Russ found "glen@amsl.com" surprising. I suspect other people will as well. Something @ietf.org seems less likely to trigger that surprise. Requests for help will likely come to you in any case. I think it's your choice whether you want them to be ticketed or not. It would be good to know, at the end, how much volume there was (though if the volume is high, I suspect we'll change strategies anyhow). > > Or we could just leave the test as is, whichever. > > Glen > From nobody Mon Sep 28 11:24:10 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4A33A1068 for ; Mon, 28 Sep 2020 11:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 QeC1wjzzI8NB for ; Mon, 28 Sep 2020 11:24:08 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220863A105A for ; Mon, 28 Sep 2020 11:24:08 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 5274B3C13C1 for ; Mon, 28 Sep 2020 11:24:06 -0700 (PDT) Received: from [192.168.86.10] (173-8-133-94-SFBA.hfc.comcastbusiness.net [173.8.133.94]) by c8a.amsl.com (Postfix) with ESMTPSA id 3D6D73C13C0 for ; Mon, 28 Sep 2020 11:24:06 -0700 (PDT) To: tools-implementation@ietf.org References: <1978b20a-b829-85a9-a250-6944652df040@amsl.com> <2dfef357-d4b4-a6e8-d95b-85ceb78e764a@nostrum.com> From: Glen Organization: AMS Message-ID: Date: Mon, 28 Sep 2020 11:24:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <2dfef357-d4b4-a6e8-d95b-85ceb78e764a@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix) X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 18:24:10 -0000 On 9/28/2020 10:27, Robert Sparks wrote: >> Maybe we should do a separate alias? > Russ found "glen@amsl.com" surprising. I suspect other people will as > well. Something @ietf.org seems less likely to trigger that surprise. > Requests for help will likely come to you in any case. I think it's your > choice whether you want them to be ticketed or not. It would be good to > know, at the end, how much volume there was (though if the volume is > high, I suspect we'll change strategies anyhow). Okay, I am going to be AFK for about 90 minutes. If there are no objections, I will just change the address to "ietf-action@ietf.org", since that's what the community will likely expect. I expect I will have to restart Zulip for the change to be picked up; given the many moving parts, I will just reboot the dedicated instance. Glen From nobody Mon Sep 28 11:29:05 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590073A1078 for ; Mon, 28 Sep 2020 11:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 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, NICE_REPLY_A=-0.213, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 mtk4BioQhmds for ; Mon, 28 Sep 2020 11:29:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E55DC3A1072 for ; Mon, 28 Sep 2020 11:29:00 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08SISwVd002392 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2020 13:29:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1601317740; bh=IF4YY4J/Q4ZeA2rXCrBHjjA9eLsee2a4aW2w3uBm6X4=; h=Subject:To:References:From:Date:In-Reply-To; b=QkWNzvGs4Q5W9ochLkEgFmo/9m/okNevR79uo+mPDk9l4brKj/mTKjTc1Bz3H+CwP ea7d/MkyaLGZZnd0AimN+ZZxQad9293uIJaoIaDqKKSGCrDHPeKDrYOnCwixZh8vR7 FBMy34I9RQLXKwNPXDe5MVA7BKpLiMbxHRe9j7VA= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: tools-implementation@ietf.org References: <1978b20a-b829-85a9-a250-6944652df040@amsl.com> <2dfef357-d4b4-a6e8-d95b-85ceb78e764a@nostrum.com> From: Robert Sparks Message-ID: <2eda6bcb-d321-f2e1-0199-20400bda2376@nostrum.com> Date: Mon, 28 Sep 2020 13:28:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix) X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 18:29:04 -0000 Sounds good to me. On 9/28/20 1:24 PM, Glen wrote: > On 9/28/2020 10:27, Robert Sparks wrote: >>> Maybe we should do a separate alias? >> Russ found "glen@amsl.com" surprising. I suspect other people will as >> well. Something @ietf.org seems less likely to trigger that surprise. >> Requests for help will likely come to you in any case. I think it's >> your choice whether you want them to be ticketed or not. It would be >> good to know, at the end, how much volume there was (though if the >> volume is high, I suspect we'll change strategies anyhow). > > Okay, I am going to be AFK for about 90 minutes.  If there are no > objections, I will just change the address to "ietf-action@ietf.org", > since that's what the community will likely expect. > > I expect I will have to restart Zulip for the change to be picked up; > given the many moving parts, I will just reboot the dedicated instance. > > Glen > From nobody Mon Sep 28 11:36:44 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C18A3A1076 for ; Mon, 28 Sep 2020 11:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 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, NICE_REPLY_A=-0.213, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 qToHwU5W0M0m for ; Mon, 28 Sep 2020 11:36:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A638C3A1080 for ; Mon, 28 Sep 2020 11:36:40 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08SIaaUY004969 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2020 13:36:40 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1601318200; bh=Ro9yXu69M0DBWukN4ORtVuhKn1VLkyOWJGScCRVP8Fs=; h=Subject:To:References:From:Date:In-Reply-To; b=vEg+ooJd0gA83Fz7a7gVzb3RGMLtUUbdpqKbQe1wor1w7/vMldfGkcJnqrug8LmCn lF6571B6H+OcbdWJLPdrAo0zXAuJxhTYUX2JykovfNiM3b4YgmVjRwND3SW+lQDwQR Y3r0VIzOVdxxg1GpF6Xmp7hZUJYkvYKzjRJv7T0o= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: tools-implementation@ietf.org References: <82db14a0-8518-b7cb-596b-3b0eb0af0346@nostrum.com> From: Robert Sparks Message-ID: <7dd4e67b-0dd8-9852-f3e9-84619a8c1b2f@nostrum.com> Date: Mon, 28 Sep 2020 13:36:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <82db14a0-8518-b7cb-596b-3b0eb0af0346@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix) X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 18:36:44 -0000 Here's a proposed edit inline: On 9/28/20 11:58 AM, Robert Sparks wrote: > > On 9/28/20 11:52 AM, Glen wrote: >> Hi team - >> >> Hope you all had a good week. >> >> I've read the announcement below, I have only one comment.  The >> paragraph starting with "The secretariat is operating" seems >> unnecessary from my point of view.  The current >> expectation/perception of the community is that the secretariat >> operates the IETF's IT services. > The point of the sentence is to answer "why aren't we taking advantage > of the offers other groups have made to host". >> That's what we're contracted to do, that is in fact my job.  In >> addition, we already know that the community has privacy issues, so >> we could assume that self-hosting is at least not an aversion point. >> Therefore, the things stated in that paragraph are already the norm. >> >> I could expand on this if desired, but, to keep things brief, I'd >> recommend removing that entire paragraph. > I think it is quite necessary. >> If we decide to go public-cloud later, we can and should open that as >> a separate topic. For now, the paragraph says nothing new, and adds >> unnecessary wording to the announcement. >> >> Other than that (and Robert's subsequent tweak) I have no further >> thoughts right now! >> >> Also I saw the commentary about "glen@amsl.com" in the emails. When >> running the initial install script, the script takes two parameters - >> the server FQDN, and the server (human) administrator account.  I >> provided my own email address as the first account to create, which >> is where Zulip got this. >> >> This was unanticipated, but I guess something to "learn" through >> these tests.  If we end up using Zulip in a permanent state, we will >> of course know about this and choose a better address/account/alias >> for this.  For now, I will look through and see if this can be safely >> changed via a setting, as I have time. >> >> I note that the message doesn't *require* contact, but just *offers* >> my address as a human contact point: >> >> >> Contact us any time at glen@amsl.com if you >> run into trouble, have any feedback, or just want to chat! >> >> I don't think we should delay announcement until this can be changed; >> I don't think for a test instance this is a big deal, but I will >> still look, because I don't want those emails.  :-) But I'm fine with >> whatever you all decide. >> >> Glen >> >> >>> We are deploying trials of the matrix and zulip chat services to gain >>> operational experience and get community feedback about how well >>> these services >>> meet the need for IETF related chat. >>> >>> We have clear evidence from the IETF 107 post-meeting survey >>> (https://www.ietf.org/media/documents/ietf-107-survey-results.pdf) >>> that many >>> IETF participants find jabber a significant problem.  This is partly >>> due to >>> difficulties in finding a free jabber service and partly due to client >>> issues.  There are two paths to try to resolve these problems, one >>> is to >>> improve the IETF jabber service and the other is to switch to an >>> alternative >>> groupchat solution.  The community has already taken a step on the >>> latter >>> path with the introduction of an IETF Slack space, and we want to >>> ensure that >>> this path is properly explored by widening the range of options to well >>> established free/open source tools. >>> >>> The installs currently have almost no local configuration or >>> customization. >>> Over the next few weeks, we will be exploring reconfiguring them to use >>> datatracker credentials for sign-in, and explore bridging between these >>> systems, Slack, and Jabber. One consequence of these explorations is >>> that >>> there will  likely be times, outside of meetings, when accounts will be >>> disrupted or even removed and will have to be recreated. Initially, we >>> suggest you use an email address for the username on each service. We considered running these trials using instances run by the Zulip or Matrix communities. We went with instances operated by the secretariat to learn what would be needed if the community felt self-hosting chat was important in the long-term. >>> >>> >>> The services can be found at matrix-trial1.ietf.org and >>> zulip-trial1.ietf.org. >>> >>> Any matrix client can be used with the trial matrix server. There is >>> also a >>> web client available at at matrix-trial1.ietf.org. >>> >>> Similarly any zulip client can be used with the trial zulip server, >>> which has a >>> built in web interface. >>> >>> We would like feedback on how well each client meets chat needs during >>> meetings, both the full online IETF 109 meeting, virtuals, adhocs, and >>> hallway conversations. >>> >>> Around December, we will assess our experiences and the feedback >>> received to >>> inform what chat services we provide in the future and how we will >>> operate >>> them. In January, these trial instances will be taken down. We do >>> not intend to >>> preserve or migrate any account configuration or chat history from >>> the trial >>> instances as we move forward. >>> >>> This does add to the potentially confusing large number of places >>> conversation >>> might take place. We hope to address that with some level of >>> bridging, at least >>> with Jabber, but have been cautioned by the respective development >>> communities >>> that bridging between Zulip and Matrix is unsatisfying since the >>> conversation >>> models in the two applications are so different. >>> >>> The chat services are intended to be explorational and informal. >>> However, >>> please treat them as contexts where contribution rules apply (See >>> https://www.ietf.org/about/note-well/). >>> >>> We are not, at this time, planning to host jabber accounts. We may >>> revisit that >>> as an option as we continue to gather more feedback. >>> >>> Please send feedback on the services to tools-discuss@ietf.org >> > From nobody Mon Sep 28 13:04:18 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DE73A13BB for ; Mon, 28 Sep 2020 13:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 F_lHQxtisYPy for ; Mon, 28 Sep 2020 13:04:15 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD6F3A140E for ; Mon, 28 Sep 2020 13:04:11 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 2D2B23C3195 for ; Mon, 28 Sep 2020 13:04:09 -0700 (PDT) Received: from [192.168.86.10] (173-8-133-94-SFBA.hfc.comcastbusiness.net [173.8.133.94]) by c8a.amsl.com (Postfix) with ESMTPSA id 1D21A3C3194 for ; Mon, 28 Sep 2020 13:04:09 -0700 (PDT) To: tools-implementation@ietf.org References: <1978b20a-b829-85a9-a250-6944652df040@amsl.com> <2dfef357-d4b4-a6e8-d95b-85ceb78e764a@nostrum.com> <2eda6bcb-d321-f2e1-0199-20400bda2376@nostrum.com> From: Glen Organization: AMS Message-ID: <31e7a8d6-6966-2daa-565d-07c2a0abd343@amsl.com> Date: Mon, 28 Sep 2020 13:04:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <2eda6bcb-d321-f2e1-0199-20400bda2376@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix) X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 20:04:17 -0000 Okay, I've made this change. And I found the email templates and took out the invitation to "just chat with" ietf-action@ietf.org. :-) I have not tested these changes, but I believe they will work. Glen On 9/28/2020 11:28, Robert Sparks wrote: > Sounds good to me. > > On 9/28/20 1:24 PM, Glen wrote: >> On 9/28/2020 10:27, Robert Sparks wrote: >>>> Maybe we should do a separate alias? >>> Russ found "glen@amsl.com" surprising. I suspect other people will as >>> well. Something @ietf.org seems less likely to trigger that surprise. >>> Requests for help will likely come to you in any case. I think it's >>> your choice whether you want them to be ticketed or not. It would be >>> good to know, at the end, how much volume there was (though if the >>> volume is high, I suspect we'll change strategies anyhow). >> >> Okay, I am going to be AFK for about 90 minutes.  If there are no >> objections, I will just change the address to "ietf-action@ietf.org", >> since that's what the community will likely expect. >> >> I expect I will have to restart Zulip for the change to be picked up; >> given the many moving parts, I will just reboot the dedicated instance. >> >> Glen >> > From nobody Mon Sep 28 13:04:58 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5165F3A13BC for ; Mon, 28 Sep 2020 13:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.123 X-Spam-Level: X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 nQmOha3_fxsB for ; Mon, 28 Sep 2020 13:04:54 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693343A13BB for ; Mon, 28 Sep 2020 13:04:54 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 69ACD3C3194 for ; Mon, 28 Sep 2020 13:04:52 -0700 (PDT) Received: from [192.168.86.10] (173-8-133-94-SFBA.hfc.comcastbusiness.net [173.8.133.94]) by c8a.amsl.com (Postfix) with ESMTPSA id 56D823C3193 for ; Mon, 28 Sep 2020 13:04:52 -0700 (PDT) To: tools-implementation@ietf.org References: <82db14a0-8518-b7cb-596b-3b0eb0af0346@nostrum.com> <7dd4e67b-0dd8-9852-f3e9-84619a8c1b2f@nostrum.com> From: Glen Organization: AMS Message-ID: <7ac17f19-27ea-b24c-1080-1afb752dc93f@amsl.com> Date: Mon, 28 Sep 2020 13:04:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <7dd4e67b-0dd8-9852-f3e9-84619a8c1b2f@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-implementation] Draft 2 (was Rough draft of message to the community re Zulip and Matrix) X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 20:04:56 -0000 On 9/28/2020 11:36, Robert Sparks wrote: > Here's a proposed edit inline: > We considered running these trials using instances run by the Zulip or > Matrix > communities. We went with instances operated by the secretariat to learn > what > would be needed if the community felt self-hosting chat was important in > the long-term. I like this. Thank you. Glen From nobody Wed Sep 30 07:32:35 2020 Return-Path: X-Original-To: tools-implementation@ietfa.amsl.com Delivered-To: tools-implementation@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE8F3A09F1 for ; Wed, 30 Sep 2020 07:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 tfsrdpOjda_d for ; Wed, 30 Sep 2020 07:32:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3F2CC3A0972 for ; Wed, 30 Sep 2020 07:32:31 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 08UEWTmb082276 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 30 Sep 2020 09:32:30 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1601476350; bh=DYgbZ434dhmCheAZ440hKnKKwEbnO2xN9r0w4GJxupU=; h=Subject:References:To:From:Date:In-Reply-To; b=D7r9N1/1HgD2xAPJ5bqwXLy9W6/ZMVqsBD5EHihHEZrRUd9sF4FJK7YTZ2b8IevHU AqNRHn2GvoEyQHkYZ17cWD26pmkT6fyOP2GzFZxK5tI63sIQ8c+AP6R0uyugdH+3I1 8tSDGTsSqFGb4dsGuvMKextSvN0wmPCBljqLAll4= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local References: <7D2E7214-12CB-4118-B143-0260B7806407@vigilsec.com> To: "tools-implementation@ietf.org" From: Robert Sparks X-Forwarded-Message-Id: <7D2E7214-12CB-4118-B143-0260B7806407@vigilsec.com> Message-ID: Date: Wed, 30 Sep 2020 09:32:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <7D2E7214-12CB-4118-B143-0260B7806407@vigilsec.com> Content-Type: multipart/alternative; boundary="------------1F1D829B188037B94C3143D3" Content-Language: en-US Archived-At: Subject: [Tools-implementation] Fwd: Places that need updated to get rid of FTP X-BeenThere: tools-implementation@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Implementation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 14:32:33 -0000 This is a multi-part message in MIME format. --------------1F1D829B188037B94C3143D3 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I've asked Scott for his thoughts on what updating the ITU doc below might look like. I think we should assume it will take some time, and be pleasantly surprised if it can be done very quickly. That suggests we should move forward with the separated FTP service that Glen started to build, so it is not in the way when we start moving files around. RjS -------- Forwarded Message -------- Subject: Places that need updated to get rid of FTP Date: Sat, 26 Sep 2020 17:06:10 -0400 From: Russ Housley To: Robert Sparks , Roman D. Danyliw CC: Scott Mansfield Robert and Roman: I forgot they the MOU with ITU has them. We call it RFC 2436. The ITU calls it ITU-T A Suppl. 3 , and it keeps getting approved. We should reach out to them with proposed changes to the URLs, even if we do not turn off FTP quickly so that this does not become a boat anchor. Russ --------------1F1D829B188037B94C3143D3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

    I've asked Scott for his thoughts on what updating the ITU doc below might look like.

    I think we should assume it will take some time, and be pleasantly surprised if it can be done very quickly.

    That suggests we should move forward with the separated FTP service that Glen started to build, so it is not in the way when we start moving files around.

    RjS



    -------- Forwarded Message --------
    Subject: Places that need updated to get rid of FTP
    Date: Sat, 26 Sep 2020 17:06:10 -0400
    From: Russ Housley <housley@vigilsec.com>
    To: Robert Sparks <rjsparks@nostrum.com>, Roman D. Danyliw <rdd@cert.org>
    CC: Scott Mansfield <scott.mansfield@ericsson.com>


    Robert and Roman:

    I forgot they the MOU with ITU has them. We call it RFC 2436. The ITU calls it ITU-T A Suppl. 3 <https://www.itu.int/itu-t/recommendations/rec.aspx?rec=11724>, and it keeps getting approved.

    We should reach out to them with proposed changes to the URLs, even if we do not turn off FTP quickly so that this does not become a boat anchor.

    Russ


    --------------1F1D829B188037B94C3143D3--