From nobody Wed Dec 9 09:11: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 D448B3A1030 for ; Wed, 9 Dec 2020 09:11:49 -0800 (PST) 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 YF8HBpYYGI8l for ; Wed, 9 Dec 2020 09:11:47 -0800 (PST) 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 5E97B3A1011 for ; Wed, 9 Dec 2020 09:11:41 -0800 (PST) Received: from unformal-11.home ([47.186.0.128]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0B9HBTCm061029 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 9 Dec 2020 11:11:34 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1607533894; bh=seVxNwNQIuEJys6NIjOP72Q4NoeM4JL5ealbGGouJRA=; h=From:To:Subject:Date; b=GGXsCBNQ65cBrrN8dCCPQQIRZSqint7JvV/neHoXHTNMzzMVmtVnObae06NzGwbPg OGzyiYeBirnUBRx5eFl6O4GLdMP4ib8UIzoIslVz7tiMz67Oe+bmiSbvCnlwlyW9ZP CxeFzaAdSP4MxRjG917g3wTlIGHkpOeKpyzA58Mk= X-Authentication-Warning: raven.nostrum.com: Host [47.186.0.128] claimed to be unformal-11.home From: Robert Sparks To: "tools-implementation@ietf.org" , jay@daley.org.nz Message-ID: Date: Wed, 9 Dec 2020 11:11:24 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [Tools-implementation] Draft of message noting that we will allow xml2rfc to produce text formatted as an RFC but paginated with page numbers. 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 Dec 2020 17:11:50 -0000 Tools-implementation team (plus Jay): - I plan to send the below note to tools-discuss and forward a pointer to=20 it on the ietf list and rfc-interest on Friday unless I hear a request=20 for something significantly different from you before then. Please comment. If you think this is ok as is, please say so. RjS ---------- Subject: Allowing xml2rfc to generate text documents with page numbers The RFCs that define the format specifications for RFCs are clear that=20 the published rendered text format for RFCs will not have page numbers. However, we have received many requests to allow the rendering tool to=20 add those numbers when people are rendering documents locally for their=20 own purposes. Adding and maintaining support for that is trivial, and we = plan to make that available via a command-line argument in an upcoming=20 release of xml2rfc. This isn't a change to how RFCs will be published - published RFCs will=20 continue to follow the format requirements from RFC 7994 and the=20 discussions around the revision of the documents defining the RFC=20 formats. Those wishing to change how RFCs are published should=20 contribute to future efforts revising those specifications. In general, the formatters will be able to produce a superset of what is = required for RFC publication, and we anticipate that new capabilities=20 will be added when there is appropriate demand. We acknowledge the concerns around the potential for confusion raised=20 during the discussion of the request for this capability. However, we=20 note that it is possible to generate a document with the current tools=20 that looks like a published RFC with completely different content.=20 Addressing this potential for confusion is not an issue to solve with=20 the formatting tools. Robert Sparks, Tools Team Chair From nobody Wed Dec 9 10:04:57 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 F3C2B3A16DF for ; Wed, 9 Dec 2020 10:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Fvdg94TS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Wef/S4i/ 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 xzowvGWH18Dg for ; Wed, 9 Dec 2020 10:04:54 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759AD3A16DD for ; Wed, 9 Dec 2020 10:04:54 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 550839E2; Wed, 9 Dec 2020 13:04:53 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Wed, 09 Dec 2020 13:04:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=t7vGXF4KjCqnF/jIgPZemmpBSELjB6l BdLYCZNTn0fw=; b=Fvdg94TS+WH7vjx/hyfBgMthEhb8JhxEYfKckR1s8Mxoloc H1+L8+VVfQBBsW0xBtWXwbjOxE5s6/+4NnnmBQ0FUp7+CJdLwuZq1nM9bVb/nowW LwDxI2Nxs4aZERxODh6pU96Lp8BdAc8eIZfchzca5oiTJlp1QwEXSvb4R/qHRmLx lJVUBoOca+OtDgzwSetTRZlMrPbZzyDmMq9YpErigwej2QMz1fr3mI60y1nY9odW g4fr/6Nmbugep6eYrlG45ZWgs3AZfF9HKDzUrw3Jx451P5Wdq8EQvaeDtjmjAK1y CN8G21QOHErw5hlwiaxU1yVnFKLX3K1aBXA4WZA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=t7vGXF 4KjCqnF/jIgPZemmpBSELjB6lBdLYCZNTn0fw=; b=Wef/S4i/oMefbYOVCV6DNo L3S4f2APmY6lczKgXmjOC5Kcp4wdeBp++BdZUz7n24u2SuJ3UlB0Lwuyf/3qYwQv vn1ouLPGODD/5uMGQFC0qQrSfOyRN7wgdgbCpRB2VywgTWvmDysY4Y3G/RHfzLNp 7KvlnKQ7bw44lheBbFlr13Do3PW4zT0phoppU35Mqsle6hAOt97sseG+MA67ASLi PKTbSW0QDNNjLqXvUJziHDtfLfWKNDVs/qMW6wv/+rTFlJzybDDYOODcrzGLSO1N V7/ZYF6JOXsDqPiMleQdh8tCVEjWoPid76OjvTzitw4grBn2LLmr1pN3kKZBinPw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejkedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucggtffrrghtthgvrhhnpeeffffhhffffeehgfdtjedvfeettedtheffueeh teevvdevkeffuefgveduvddtleenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhk ohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 06B166F6005E; Wed, 9 Dec 2020 13:04:28 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 09 Dec 2020 18:03:13 +0000 From: "Alexey Melnikov" To: "Robert Sparks" , "tools-implementation@ietf.org" , jay@daley.org.nz Content-Type: text/plain Archived-At: Subject: Re: [Tools-implementation] =?utf-8?q?Draft_of_message_noting_that_we?= =?utf-8?q?_will_allow_xml2rfc_to_produce_text_formatted_as_an_RFC_but_pag?= =?utf-8?q?inated_with_page_numbers=2E?= 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 Dec 2020 18:04:56 -0000 Hi Robert, This looks reasonable to me! On Wed, Dec 9, 2020, at 5:11 PM, Robert Sparks wrote: > Tools-implementation team (plus Jay): - > > I plan to send the below note to tools-discuss and forward a pointer to > it on the ietf list and rfc-interest on Friday unless I hear a request > for something significantly different from you before then. > > Please comment. If you think this is ok as is, please say so. > > RjS > > ---------- > > Subject: Allowing xml2rfc to generate text documents with page numbers > > The RFCs that define the format specifications for RFCs are clear that > the published rendered text format for RFCs will not have page numbers. > > However, we have received many requests to allow the rendering tool to > add those numbers when people are rendering documents locally for their > own purposes. Adding and maintaining support for that is trivial, and we > plan to make that available via a command-line argument in an upcoming > release of xml2rfc. > > This isn't a change to how RFCs will be published - published RFCs will > continue to follow the format requirements from RFC 7994 and the > discussions around the revision of the documents defining the RFC > formats. Those wishing to change how RFCs are published should > contribute to future efforts revising those specifications. > > In general, the formatters will be able to produce a superset of what is > required for RFC publication, and we anticipate that new capabilities > will be added when there is appropriate demand. > > We acknowledge the concerns around the potential for confusion raised > during the discussion of the request for this capability. However, we > note that it is possible to generate a document with the current tools > that looks like a published RFC with completely different content. > Addressing this potential for confusion is not an issue to solve with > the formatting tools. > > Robert Sparks, Tools Team Chair > > > > -- > Tools-implementation mailing list > Tools-implementation@ietf.org > https://www.ietf.org/mailman/listinfo/tools-implementation > From nobody Wed Dec 9 11:30:36 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 DAFC23A1100 for ; Wed, 9 Dec 2020 11:30:33 -0800 (PST) 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 xrFG69-nGhL2 for ; Wed, 9 Dec 2020 11:30:32 -0800 (PST) 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 073063A10ED for ; Wed, 9 Dec 2020 11:30:31 -0800 (PST) Received: from unformal-11.home ([47.186.0.128]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0B9JUO5O001546 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 9 Dec 2020 13:30:27 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1607542228; bh=fsXDzbT5O7zRaLYlWsUlf4Sm+HAE43EpjvzdZenAePo=; h=To:From:Subject:Date; b=dGwvIHL8y8htSja0leyL0yg4QCMLmLVNe49mih1yzhkUPRdIKwnNikVyDIRpfHwPH X3ZXdk90xw3tyAuReV9mGhsZWEwKKiFup/4Vi2Xc/GVsWck0fKBw6VbwMNsatFgAeh Atj58CaiBwbFRyikYu+fjlTBAJ+8BKRs4ykNsJ4E= X-Authentication-Warning: raven.nostrum.com: Host [47.186.0.128] claimed to be unformal-11.home To: "tools-implementation@ietf.org" , jay@daley.org.nz From: Robert Sparks Message-ID: <79a73ae2-d565-33b3-6753-58587269861c@nostrum.com> Date: Wed, 9 Dec 2020 13:30:19 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 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] Draft of message about chat trials 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 Dec 2020 19:30:34 -0000 Do you think this is sufficient or do we need to take a different approach? =========== To: ietf-announce Subject: Next steps: chat service trials We have been running trial zulip, matrix, and xmpp services since October. See As noted in those announcements, the issue that we are trying to address is the difficulty people have been reporting obtaining jabber services and clients. We are hopeful that these trials will help the community develop a better sense of whether to focus on improving the experiences with xmpp or to pursue other chat solutions. We are also open to the possibility that these other solutions may be worth operating in addition to improving the experiences from xmpp. However, usage and feedback so far has not been sufficient to inform what services we should run in the future. We had around 50 local jabber accounts created on xmpp-trial1.ietf.org, and around 40 accounts were created on each of the matrix and zulip services. Few rooms have been created on the matrix service other than those bridging to xmpp. Few streams were created on the zulip service other than those bridging to xmpp and those ingesting a few mailing lists. We are not aware of anyone trying to use the zulip or matrix servers for ietf work outside the main meeting. If you've used the services, please take a few minutes to provide feedback at tools-discuss@ietf.org. Is providing local jabber accounts and a web interface to jabber sufficient? Are there features that matrix or zulip provide that are truly helpful for progressing IETF work? If so, please describe how they are helping. To collect more feedback, we are planning to extend the trials through IETF 110. Please take advantage of these services between now and then (at interim meetings for example) and let us know what you find to be effective. Thanks again to the volunteers that have been helping configure these services and keep them going. Robert Sparks, Tools Team Chair From nobody Wed Dec 9 11:37: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 A70183A16A4; Wed, 9 Dec 2020 11:37:14 -0800 (PST) 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 skm-jkxFJK-5; Wed, 9 Dec 2020 11:37:11 -0800 (PST) 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 5ED083A1667; Wed, 9 Dec 2020 11:37:11 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id C4EDE3C2C64; Wed, 9 Dec 2020 11:37:10 -0800 (PST) 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 B16623C2C63; Wed, 9 Dec 2020 11:37:10 -0800 (PST) To: tools-implementation@ietf.org, Jay Daley References: From: Glen Organization: AMS Message-ID: <2b753945-8ee6-c26c-4e56-fd08a9f7c0d1@amsl.com> Date: Wed, 9 Dec 2020 11:37:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.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 of message noting that we will allow xml2rfc to produce text formatted as an RFC but paginated with page numbers. 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 Dec 2020 19:37:15 -0000 No issues that I can see, I think it is okay, although I'm not the most qualified to judge this topic area. ;-) Glen On 12/9/2020 09:11, Robert Sparks wrote: > Tools-implementation team (plus Jay): - > > I plan to send the below note to tools-discuss and forward a pointer to > it on the ietf list and rfc-interest on Friday unless I hear a request > for something significantly different from you before then. > > Please comment. If you think this is ok as is, please say so. > > RjS > > ---------- > > Subject: Allowing xml2rfc to generate text documents with page numbers > > The RFCs that define the format specifications for RFCs are clear that > the published rendered text format for RFCs will not have page numbers. > > However, we have received many requests to allow the rendering tool to > add those numbers when people are rendering documents locally for their > own purposes. Adding and maintaining support for that is trivial, and we > plan to make that available via a command-line argument in an upcoming > release of xml2rfc. > > This isn't a change to how RFCs will be published - published RFCs will > continue to follow the format requirements from RFC 7994 and the > discussions around the revision of the documents defining the RFC > formats. Those wishing to change how RFCs are published should > contribute to future efforts revising those specifications. > > In general, the formatters will be able to produce a superset of what is > required for RFC publication, and we anticipate that new capabilities > will be added when there is appropriate demand. > > We acknowledge the concerns around the potential for confusion raised > during the discussion of the request for this capability. However, we > note that it is possible to generate a document with the current tools > that looks like a published RFC with completely different content. > Addressing this potential for confusion is not an issue to solve with > the formatting tools. > > Robert Sparks, Tools Team Chair > > > From nobody Wed Dec 9 11:46:14 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 B844B3A1141 for ; Wed, 9 Dec 2020 11:46:11 -0800 (PST) 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, 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 jnXGuh2prLVq for ; Wed, 9 Dec 2020 11:46:10 -0800 (PST) Received: from daley.org.nz (412514.vps-10.com [212.48.70.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0939C3A10D8 for ; Wed, 9 Dec 2020 11:46:09 -0800 (PST) Received: from [192.168.1.110] (unknown [158.140.230.105]) by 412514.vps-10.com (Postfix) with ESMTPSA id 0FD814EFB0A; Thu, 10 Dec 2020 08:46:07 +1300 (NZDT) Authentication-Results: 412514.vps-10.com; spf=pass (sender IP is 158.140.230.105) smtp.mailfrom=jay@daley.org.nz smtp.helo=[192.168.1.110] Received-SPF: pass (412514.vps-10.com: connection is authenticated) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jay Daley Mime-Version: 1.0 (1.0) Date: Thu, 10 Dec 2020 08:46:02 +1300 Message-Id: References: Cc: tools-implementation@ietf.org In-Reply-To: To: Robert Sparks X-Mailer: iPhone Mail (18B92) Archived-At: Subject: Re: [Tools-implementation] Draft of message noting that we will allow xml2rfc to produce text formatted as an RFC but paginated with page numbers. 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 Dec 2020 19:46:12 -0000 Looks good to me. I perhaps would use =E2=80=9Cdifferent output=E2=80=9D rat= her than =E2=80=9Csuperset=E2=80=9D as the latter implies compatibility, but= that=E2=80=99s a minor issue.=20 Jay (sent from my phone) --=20 Jay Daley=20 +64 21 678840 jay@daley.org.nz wire: @jaydaley > On 10/12/2020, at 6:11 AM, Robert Sparks wrote: >=20 > =EF=BB=BFTools-implementation team (plus Jay): - >=20 > I plan to send the below note to tools-discuss and forward a pointer to it= on the ietf list and rfc-interest on Friday unless I hear a request for som= ething significantly different from you before then. >=20 > Please comment. If you think this is ok as is, please say so. >=20 > RjS >=20 > ---------- >=20 > Subject: Allowing xml2rfc to generate text documents with page numbers >=20 > The RFCs that define the format specifications for RFCs are clear that the= published rendered text format for RFCs will not have page numbers. >=20 > However, we have received many requests to allow the rendering tool to add= those numbers when people are rendering documents locally for their own pur= poses. Adding and maintaining support for that is trivial, and we plan to ma= ke that available via a command-line argument in an upcoming release of xml2= rfc. >=20 > This isn't a change to how RFCs will be published - published RFCs will co= ntinue to follow the format requirements from RFC 7994 and the discussions a= round the revision of the documents defining the RFC formats. Those wishing t= o change how RFCs are published should contribute to future efforts revising= those specifications. >=20 > In general, the formatters will be able to produce a superset of what is r= equired for RFC publication, and we anticipate that new capabilities will be= added when there is appropriate demand. >=20 > We acknowledge the concerns around the potential for confusion raised duri= ng the discussion of the request for this capability. However, we note that i= t is possible to generate a document with the current tools that looks like a= published RFC with completely different content. Addressing this potential f= or confusion is not an issue to solve with the formatting tools. >=20 > Robert Sparks, Tools Team Chair >=20 >=20 >=20 From nobody Wed Dec 9 11:50: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 44BA53A1141; Wed, 9 Dec 2020 11:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.91 X-Spam-Level: X-Spam-Status: No, score=-101.91 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, 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 Z6E7seX_t_32; Wed, 9 Dec 2020 11:50:14 -0800 (PST) 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 0BD953A10D8; Wed, 9 Dec 2020 11:50:14 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 792CC3C2CBA; Wed, 9 Dec 2020 11:50:13 -0800 (PST) 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 637CB3C2CB9; Wed, 9 Dec 2020 11:50:13 -0800 (PST) To: tools-implementation@ietf.org, Jay Daley References: <79a73ae2-d565-33b3-6753-58587269861c@nostrum.com> From: Glen Organization: AMS Message-ID: Date: Wed, 9 Dec 2020 11:50:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <79a73ae2-d565-33b3-6753-58587269861c@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 of message about chat trials 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 Dec 2020 19:50:17 -0000 On 12/9/2020 11:30, Robert Sparks wrote: > Do you think this is sufficient or do we need to take a different approach? Might I suggest one potential add: Truncating for focus.... maybe between these two sections add something like: --snip-- > We are not aware of anyone trying to use the zulip or matrix servers for > ietf work outside the main meeting. > > If you've used the services, please take a few minutes to provide > feedback at tools-discuss@ietf.org. If you are interested in using these services more directly for your working group's day-to-day communication, and are willing to test one or both of these services on a primary basis for a while, please let us know so we can help accommodate. We especially encourage leadership teams, and groups with an interest in remote participation/communication to get involved here. If you are one of those who has had, or has reported, issues using Jabber, please take some time now to work with these new services and help the IETF help the community. The more usage and exposure these services get, the better informed the IETF's future planning will be. > Is providing local jabber accounts and a web interface to jabber > sufficient? > Are there features that matrix or zulip provide that are truly helpful > for progressing IETF work? If so, please describe how they are helping. --snip-- My thoughts just for this list (and its public archive): I feel like we don't want to just be observers here. We've all heard *repeated* complaints about Jabber. I like Jabber, but, really, we've gotten complaints, and here we're trying to solve issues, and we've had... 37 people participate. I feel like we should encourage, even *prod*, the community to work with these new services (including the new Jabber client services) and really get involved in this process. And there are some obvious candidates for these things: * We should encourage the IESG, IAB, IRTF leadership teams to get involved. Not to mention the Tools Architecture Team, and even the larger Tools-Discuss team. * We should encourage the XMPP, SHMOO, MANYCOUCHES, and any other such groups to get involved. * We should encourage anyone currently using IETF Slack or other alternative channels. * We should encourage the team members for each of the three protocols (i.e. the people who set up Prosody/EJabberd, Matrix, and Zulip) to step up and help us encourage participation. * Because Matrix has active attention from its developers, I have been hanging out on Zulip, I'd like to make an Implementation stream there and see if I can get the six of us involved. :-) * We should make clear that if people want positive change, they need to get involved. Otherwise, a less-informed decision will be made, and the community will be less-happy. You obviously don't need to use my words, or even any of this, this is just feedback. The IETF needs some visible guidance and reminders to get involved here, and I think that falls to us. Glen From nobody Wed Dec 9 12:03:04 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 37D2C3A1115; Wed, 9 Dec 2020 12:03:02 -0800 (PST) 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 Ff493OFi_gEX; Wed, 9 Dec 2020 12:03:00 -0800 (PST) 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 61AD83A173D; Wed, 9 Dec 2020 12:02:37 -0800 (PST) From: Jay Daley Message-Id: <41D3FBF3-81F4-49ED-B776-DE3D8E52071B@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_D5280122-6B71-44B6-B86A-E85D8639250D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 10 Dec 2020 09:02:35 +1300 In-Reply-To: Cc: tools-implementation@ietf.org To: Glen References: <79a73ae2-d565-33b3-6753-58587269861c@nostrum.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Tools-implementation] Draft of message about chat trials 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 Dec 2020 20:03:02 -0000 --Apple-Mail=_D5280122-6B71-44B6-B86A-E85D8639250D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m too busy right now to give detailed feedback but I like all = of Glen=E2=80=99s suggestions. Jay > On 10/12/2020, at 8:50 AM, Glen wrote: >=20 > On 12/9/2020 11:30, Robert Sparks wrote: >> Do you think this is sufficient or do we need to take a different = approach? >=20 > Might I suggest one potential add: >=20 > Truncating for focus.... maybe between these two sections add = something like: >=20 > --snip-- >=20 >> We are not aware of anyone trying to use the zulip or matrix servers = for ietf work outside the main meeting. >> If you've used the services, please take a few minutes to provide = feedback at tools-discuss@ietf.org. >=20 > If you are interested in using these services more directly for your = working group's day-to-day communication, and are willing to test one or = both of these services on a primary basis for a while, please let us = know so we can help accommodate. We especially encourage leadership = teams, and groups with an interest in remote participation/communication = to get involved here. >=20 > If you are one of those who has had, or has reported, issues using = Jabber, please take some time now to work with these new services and = help the IETF help the community. >=20 > The more usage and exposure these services get, the better informed = the IETF's future planning will be. >=20 >> Is providing local jabber accounts and a web interface to jabber = sufficient? >> Are there features that matrix or zulip provide that are truly = helpful for progressing IETF work? If so, please describe how they are = helping. >=20 > --snip-- >=20 > My thoughts just for this list (and its public archive): >=20 > I feel like we don't want to just be observers here. We've all heard = *repeated* complaints about Jabber. I like Jabber, but, really, we've = gotten complaints, and here we're trying to solve issues, and we've = had... 37 people participate. >=20 > I feel like we should encourage, even *prod*, the community to work = with these new services (including the new Jabber client services) and = really get involved in this process. >=20 > And there are some obvious candidates for these things: >=20 > * We should encourage the IESG, IAB, IRTF leadership teams to get = involved. Not to mention the Tools Architecture Team, and even the = larger Tools-Discuss team. >=20 > * We should encourage the XMPP, SHMOO, MANYCOUCHES, and any other such = groups to get involved. >=20 > * We should encourage anyone currently using IETF Slack or other = alternative channels. >=20 > * We should encourage the team members for each of the three protocols = (i.e. the people who set up Prosody/EJabberd, Matrix, and Zulip) to step = up and help us encourage participation. >=20 > * Because Matrix has active attention from its developers, I have been = hanging out on Zulip, I'd like to make an Implementation stream there = and see if I can get the six of us involved. :-) >=20 > * We should make clear that if people want positive change, they need = to get involved. >=20 > Otherwise, a less-informed decision will be made, and the community = will be less-happy. >=20 > You obviously don't need to use my words, or even any of this, this is = just feedback. The IETF needs some visible guidance and reminders to = get involved here, and I think that falls to us. >=20 > Glen >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_D5280122-6B71-44B6-B86A-E85D8639250D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m too busy right now to give detailed feedback but I like all of = Glen=E2=80=99s suggestions.

Jay

On 10/12/2020, at 8:50 AM, Glen <glen@amsl.com> = wrote:

On 12/9/2020 11:30, Robert Sparks wrote:
Do you think this is = sufficient or do we need to take a different approach?

Might I suggest one potential = add:

Truncating for focus.... maybe between = these two sections add something like:

--snip--

We are not aware of anyone trying to use the zulip or matrix = servers for ietf work outside the main meeting.
If you've = used the services, please take a few minutes to provide feedback at tools-discuss@ietf.org.

If you are interested in using these services more directly = for your working group's day-to-day communication, and are willing to = test one or both of these services on a primary basis for a while, = please let us know so we can help accommodate.   We especially = encourage leadership teams, and groups with an interest in remote = participation/communication to get involved here.

If you are one of those who has had, or has reported, issues = using Jabber, please take some time now to work with these new services = and help the IETF help the community.

The = more usage and exposure these services get, the better informed the = IETF's future planning will be.

Is providing local jabber accounts and a web = interface to jabber sufficient?
Are there features that = matrix or zulip provide that are truly helpful for progressing IETF = work? If so, please describe how they are helping.

--snip--

My thoughts just for this list (and its public archive):

I feel like we don't want to just be observers = here.  We've all heard *repeated* complaints about Jabber. =   I like Jabber, but, really, we've gotten complaints, and = here we're trying to solve issues, and we've had...  37 people = participate.

I feel like we should = encourage, even *prod*, the community to work with these new services = (including the new Jabber client services) and really get involved in = this process.

And there are some obvious = candidates for these things:

* We should = encourage the IESG, IAB, IRTF leadership teams to get involved. =  Not to mention the Tools Architecture Team, and even the larger = Tools-Discuss team.

* We should encourage = the XMPP, SHMOO, MANYCOUCHES, and any other such groups to get = involved.

* We should encourage anyone = currently using IETF Slack or other alternative channels.

* We should encourage the team members for = each of the three protocols (i.e. the people who set up = Prosody/EJabberd, Matrix, and Zulip) to step up and help us encourage = participation.

* Because Matrix has active = attention from its developers, I have been hanging out on Zulip, I'd = like to make an Implementation stream there and see if I can get the six = of us involved.  :-)

* We should make = clear that if people want positive change, they need to get involved.

Otherwise, a less-informed decision will be = made, and the community will be less-happy.

You obviously don't need to use my words, or even any of = this, this is just feedback.  The IETF needs some visible guidance = and reminders to get involved here, and I think that falls to us.

Glen


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

= --Apple-Mail=_D5280122-6B71-44B6-B86A-E85D8639250D-- From nobody Thu Dec 10 06:34:13 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 95DA13A0F01 for ; Thu, 10 Dec 2020 06:34:11 -0800 (PST) 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 jZrbwE5CUYOf for ; Thu, 10 Dec 2020 06:34:09 -0800 (PST) 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 083F13A0EFB for ; Thu, 10 Dec 2020 06:34:08 -0800 (PST) Received: from unformal-11.home ([47.186.0.128]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0BAEY7Bn029792 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 10 Dec 2020 08:34:08 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1607610848; bh=rYH9ozOVumGDC69feuBSVbN7xSyGDNqKQeiHSU5apJ8=; h=To:References:From:Subject:Date:In-Reply-To; b=LTvTk22USb6XsW4KhjizSOtxvW7Z3g6li1fHR4c4NULWn2tF0GzmMiOKLFTIQMK2d 7xNJ9JQmk9h3DgWtqpqza2IYTHK0fQXB6J9GA8mNTXNd78KD+6O5Z2ParToWYgKB+H QKPOk97ImApKiJosnkJktCn5L0zL1NSyc5PB6wig= X-Authentication-Warning: raven.nostrum.com: Host [47.186.0.128] claimed to be unformal-11.home To: tools-implementation@ietf.org References: <79a73ae2-d565-33b3-6753-58587269861c@nostrum.com> <41D3FBF3-81F4-49ED-B776-DE3D8E52071B@ietf.org> From: Robert Sparks Message-ID: <1c886ee6-e7be-21c1-167c-e1e25a5dadfd@nostrum.com> Date: Thu, 10 Dec 2020 08:34:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <41D3FBF3-81F4-49ED-B776-DE3D8E52071B@ietf.org> Content-Type: multipart/alternative; boundary="------------16C3574551A41206E35899F1" Content-Language: en-US Archived-At: Subject: [Tools-implementation] 2nd iteration: Re: Draft of message about chat trials 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 Dec 2020 14:34:12 -0000 This is a multi-part message in MIME format. --------------16C3574551A41206E35899F1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I've tried to worked the spirit of Glen's suggestions into the text, and = aimed people at some specific resources on matrix and zulip Some inline comments at the end. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To: ietf-announce Subject: Next steps: chat service trials We have been running trial zulip, matrix, and xmpp services since October= =2E See As noted in those announcements, the issue that we are trying to address = is the difficulty people have been reporting obtaining jabber services=20 and clients. We are hopeful that these trials will help the community=20 develop a better sense of whether to focus on improving the experiences=20 with xmpp or to pursue other chat solutions. We are also open to the=20 possibility that these other solutions may be worth operating in=20 addition to improving the experiences from xmpp. However, usage and feedback so far has not been sufficient to inform=20 what services we should run in the future. We had around 50 local jabber accounts created on xmpp-trial1.ietf.org,=20 and around 40 accounts were created on each of the matrix and zulip=20 services. Few rooms have been created on the matrix service other than those=20 bridging to xmpp. Few streams were created on the zulip service other than those bridging=20 to xmpp and those ingesting a few mailing lists. We are not aware of anyone trying to use the zulip or matrix servers for = ietf work outside the main meeting. If you've used the services, please take a few minutes to provide=20 feedback at tools-discuss@ietf.org. Is providing local jabber accounts and a web interface to jabber sufficie= nt? Are there features that matrix or zulip provide that are truly helpful=20 for progressing IETF work? If so, please describe how they are helping. To collect more feedback, we are planning to extend the trials through=20 IETF 110. Please take advantage of these services between now and then=20 (at interim meetings for example) and let us know what you find to be=20 effective. If you are interested in using these services more directly for your=20 group's day-to-day communication, and are willing to test one or both of = these services on a primary basis for a while, please coordinate with=20 the appropriate leadership and let the tools team know so we can help=20 accommodate.=C2=A0 Please consider using these services for ad-hoc,=20 design-team meetings, and even interims (again, coordinating with the=20 appropriate leadership). If you have had issues using Jabber in the past, please take some time=20 now to work with these new services and describe whether they improve=20 your experience. We need more feedback about these services to develop a sense of what=20 will best meet the community's needs going forward. Please engage in=20 exploring and discussing them at tools-discuss@ietf.org. While exploring, feel free to use the trial1-feedback room on Matrix and = the trial1-feedback stream on Zulip. Thanks again to the volunteers that have been helping configure these=20 services and keep them going. Robert Sparks, Tools Team Chair =3D=3D=3D=3D=3D On 12/9/20 2:02 PM, Jay Daley wrote: > I=E2=80=99m too busy right now to give detailed feedback but I like all= of=20 > Glen=E2=80=99s suggestions. > > Jay > >> On 10/12/2020, at 8:50 AM, Glen > > wrote: >> >> On 12/9/2020 11:30, Robert Sparks wrote: >>> Do you think this is sufficient or do we need to take a different=20 >>> approach? >> >> Might I suggest one potential add: >> >> Truncating for focus.... maybe between these two sections add=20 >> something like: >> >> --snip-- >> >>> We are not aware of anyone trying to use the zulip or matrix servers = >>> for ietf work outside the main meeting. >>> If you've used the services, please take a few minutes to provide=20 >>> feedback at tools-discuss@ietf.org . >> >> If you are interested in using these services more directly for your=20 >> working group's day-to-day communication, and are willing to test one = >> or both of these services on a primary basis for a while, please let=20 >> us know so we can help accommodate. =C2=A0=C2=A0We especially encourag= e=20 >> leadership teams, and groups with an interest in remote=20 >> participation/communication to get involved here. I think we directly approach the IESG, IAB, IRTF chair, and manycouches=20 (which is the shmoo list) with followup messages. >> >> If you are one of those who has had, or has reported, issues using=20 >> Jabber, please take some time now to work with these new services and = >> help the IETF help the community. >> >> The more usage and exposure these services get, the better informed=20 >> the IETF's future planning will be. >> >>> Is providing local jabber accounts and a web interface to jabber=20 >>> sufficient? >>> Are there features that matrix or zulip provide that are truly=20 >>> helpful for progressing IETF work? If so, please describe how they=20 >>> are helping. >> >> --snip-- >> >> My thoughts just for this list (and its public archive): >> >> I feel like we don't want to just be observers here. =C2=A0We've all h= eard=20 >> *repeated* complaints about Jabber. =C2=A0=C2=A0I like Jabber, but, re= ally,=20 >> we've gotten complaints, and here we're trying to solve issues, and=20 >> we've had... =C2=A037 people participate. >> >> I feel like we should encourage, even *prod*, the community to work=20 >> with these new services (including the new Jabber client services)=20 >> and really get involved in this process. >> >> And there are some obvious candidates for these things: >> >> * We should encourage the IESG, IAB, IRTF leadership teams to get=20 >> involved. =C2=A0Not to mention the Tools Architecture Team, and even t= he=20 >> larger Tools-Discuss team. >> >> * We should encourage the XMPP, SHMOO, MANYCOUCHES, and any other=20 >> such groups to get involved. >> >> * We should encourage anyone currently using IETF Slack or other=20 >> alternative channels. >> >> * We should encourage the team members for each of the three=20 >> protocols (i.e. the people who set up Prosody/EJabberd, Matrix, and=20 >> Zulip) to step up and help us encourage participation. >> >> * Because Matrix has active attention from its developers, I have=20 >> been hanging out on Zulip, I'd like to make an Implementation stream=20 >> there and see if I can get the six of us involved. =C2=A0:-) Sure! >> >> * We should make clear that if people want positive change, they need = >> to get involved. >> >> Otherwise, a less-informed decision will be made, and the community=20 >> will be less-happy. >> >> You obviously don't need to use my words, or even any of this, this=20 >> is just feedback. =C2=A0The IETF needs some visible guidance and remin= ders=20 >> to get involved here, and I think that falls to us. >> >> Glen >> > > --=20 > Jay Daley > IETF Executive Director > jay@ietf.org > > --------------16C3574551A41206E35899F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I've tried to worked the spirit of Glen's suggestions into the text, and aimed people at some specific resources on matrix and zulip

Some inline comments at the end.

===========

To: ietf-announce

Subject: Next steps: chat service trials

We have been running trial zulip, matrix, and xmpp services since October.
See
<https://mailarchive.ietf.org/arch/browse/ietf-announce/?q=%22trial%20chat%22>

As noted in those announcements, the issue that we are trying to address is the difficulty people have been reporting obtaining jabber services and clients. We are hopeful that these trials will help the community develop a better sense of whether to focus on improving the experiences with xmpp or to pursue other chat solutions. We are also open to the possibility that these other solutions may be worth operating in addition to improving the experiences from xmpp.

However, usage and feedback so far has not been sufficient to inform what services we should run in the future.

We had around 50 local jabber accounts created on xmpp-trial1.ietf.org, and around 40 accounts were created on each of the matrix and zulip services.
Few rooms have been created on the matrix service other than those bridging to xmpp.
Few streams were created on the zulip service other than those bridging to xmpp and those ingesting a few mailing lists.

We are not aware of anyone trying to use the zulip or matrix servers for ietf work outside the main meeting.

If you've used the services, please take a few minutes to provide feedback at tools-discuss@ietf.org.

Is providing local jabber accounts and a web interface to jabber sufficient?
Are there features that matrix or zulip provide that are truly helpful for progressing IETF work? If so, please describe how they are helping.

To collect more feedback, we are planning to extend the trials through IETF 110. Please take advantage of these services between now and then (at interim meetings for example) and let us know what you find to be effective.

If you are interested in using these services more directly for your group's day-to-day communication, and are willing to test one or both of these services on a primary basis for a while, please coordinate with the appropriate leadership and let the tools team know so we can help accommodate.  Please consider using these services for ad-hoc, design-team meetings, and even interims (again, coordinating with the appropriate leadership).

If you have had issues using Jabber in the past, please take some time now to work with these new services and describe whether they improve your experience.

We need more feedback about these services to develop a sense of what will best meet the community's needs going forward. Please engage in exploring and discussing them at tools-discuss@ietf.org.

While exploring, feel free to use the trial1-feedback room on Matrix and the trial1-feedback stream on Zulip.

Thanks again to the volunteers that have been helping configure these services and keep them going.

Robert Sparks, Tools Team Chair

=====

On 12/9/20 2:02 PM, Jay Daley wrote:
I’m too busy right now to give detailed feedback but I like all of Glen’s suggestions.

Jay

On 10/12/2020, at 8:50 AM, Glen <glen@amsl.com> wrote:

On 12/9/2020 11:30, Robert Sparks wrote:
Do you think this is sufficient or do we need to take a different approach?

Might I suggest one potential add:

Truncating for focus.... maybe between these two sections add something like:

--snip--

We are not aware of anyone trying to use the zulip or matrix servers for ietf work outside the main meeting.
If you've used the services, please take a few minutes to provide feedback at tools-discuss@ietf.org.

If you are interested in using these services more directly for your working group's day-to-day communication, and are willing to test one or both of these services on a primary basis for a while, please let us know so we can help accommodate.   We especially encourage leadership teams, and groups with an interest in remote participation/communication to get involved here.
I think we directly approach the IESG, IAB, IRTF chair, and manycouches (which is the shmoo list) with followup messages.

If you are one of those who has had, or has reported, issues using Jabber, please take some time now to work with these new services and help the IETF help the community.

The more usage and exposure these services get, the better informed the IETF's future planning will be.

Is providing local jabber accounts and a web interface to jabber sufficient?
Are there features that matrix or zulip provide that are truly helpful for progressing IETF work? If so, please describe how they are helping.

--snip--

My thoughts just for this list (and its public archive):

I feel like we don't want to just be observers here.  We've all heard *repeated* complaints about Jabber.   I like Jabber, but, really, we've gotten complaints, and here we're trying to solve issues, and we've had...  37 people participate.

I feel like we should encourage, even *prod*, the community to work with these new services (including the new Jabber client services) and really get involved in this process.

And there are some obvious candidates for these things:

* We should encourage the IESG, IAB, IRTF leadership teams to get involved.  Not to mention the Tools Architecture Team, and even the larger Tools-Discuss team.

* We should encourage the XMPP, SHMOO, MANYCOUCHES, and any other such groups to get involved.

* We should encourage anyone currently using IETF Slack or other alternative channels.

* We should encourage the team members for each of the three protocols (i.e. the people who set up Prosody/EJabberd, Matrix, and Zulip) to step up and help us encourage participation.

* Because Matrix has active attention from its developers, I have been hanging out on Zulip, I'd like to make an Implementation stream there and see if I can get the six of us involved.  :-)
Sure!

* We should make clear that if people want positive change, they need to get involved.

Otherwise, a less-informed decision will be made, and the community will be less-happy.

You obviously don't need to use my words, or even any of this, this is just feedback.  The IETF needs some visible guidance and reminders to get involved here, and I think that falls to us.

Glen


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


--------------16C3574551A41206E35899F1-- From nobody Thu Dec 10 10:10: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 1D3833A1170 for ; Thu, 10 Dec 2020 10:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.91 X-Spam-Level: X-Spam-Status: No, score=-101.91 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, 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 U38G-WS_DMje for ; Thu, 10 Dec 2020 10:10:22 -0800 (PST) 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 0EB343A115F for ; Thu, 10 Dec 2020 10:10:22 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 89FF13C3408 for ; Thu, 10 Dec 2020 10:10:21 -0800 (PST) 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 7A0803C3402 for ; Thu, 10 Dec 2020 10:10:21 -0800 (PST) To: tools-implementation@ietf.org References: <79a73ae2-d565-33b3-6753-58587269861c@nostrum.com> <41D3FBF3-81F4-49ED-B776-DE3D8E52071B@ietf.org> <1c886ee6-e7be-21c1-167c-e1e25a5dadfd@nostrum.com> From: Glen Organization: AMS Message-ID: <7db35978-94c4-f67a-08d2-031746b0cbd0@amsl.com> Date: Thu, 10 Dec 2020 10:10:20 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <1c886ee6-e7be-21c1-167c-e1e25a5dadfd@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] 2nd iteration: Re: Draft of message about chat trials 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 Dec 2020 18:10:26 -0000 This seems good to me... Glen On 12/10/2020 06:34, Robert Sparks wrote: > I've tried to worked the spirit of Glen's suggestions into the text, and > aimed people at some specific resources on matrix and zulip > > Some inline comments at the end. > > =========== > > To: ietf-announce > > Subject: Next steps: chat service trials > > We have been running trial zulip, matrix, and xmpp services since October. > See > > > As noted in those announcements, the issue that we are trying to address > is the difficulty people have been reporting obtaining jabber services > and clients. We are hopeful that these trials will help the community > develop a better sense of whether to focus on improving the experiences > with xmpp or to pursue other chat solutions. We are also open to the > possibility that these other solutions may be worth operating in > addition to improving the experiences from xmpp. > > However, usage and feedback so far has not been sufficient to inform > what services we should run in the future. > > We had around 50 local jabber accounts created on xmpp-trial1.ietf.org, > and around 40 accounts were created on each of the matrix and zulip > services. > Few rooms have been created on the matrix service other than those > bridging to xmpp. > Few streams were created on the zulip service other than those bridging > to xmpp and those ingesting a few mailing lists. > > We are not aware of anyone trying to use the zulip or matrix servers for > ietf work outside the main meeting. > > If you've used the services, please take a few minutes to provide > feedback at tools-discuss@ietf.org. > > Is providing local jabber accounts and a web interface to jabber sufficient? > Are there features that matrix or zulip provide that are truly helpful > for progressing IETF work? If so, please describe how they are helping. > > To collect more feedback, we are planning to extend the trials through > IETF 110. Please take advantage of these services between now and then > (at interim meetings for example) and let us know what you find to be > effective. > > If you are interested in using these services more directly for your > group's day-to-day communication, and are willing to test one or both of > these services on a primary basis for a while, please coordinate with > the appropriate leadership and let the tools team know so we can help > accommodate.  Please consider using these services for ad-hoc, > design-team meetings, and even interims (again, coordinating with the > appropriate leadership). > > If you have had issues using Jabber in the past, please take some time > now to work with these new services and describe whether they improve > your experience. > > We need more feedback about these services to develop a sense of what > will best meet the community's needs going forward. Please engage in > exploring and discussing them at tools-discuss@ietf.org. > > While exploring, feel free to use the trial1-feedback room on Matrix and > the trial1-feedback stream on Zulip. > > Thanks again to the volunteers that have been helping configure these > services and keep them going. > > Robert Sparks, Tools Team Chair > > ===== > > On 12/9/20 2:02 PM, Jay Daley wrote: >> I’m too busy right now to give detailed feedback but I like all of >> Glen’s suggestions. >> >> Jay >> >>> On 10/12/2020, at 8:50 AM, Glen >> > wrote: >>> >>> On 12/9/2020 11:30, Robert Sparks wrote: >>>> Do you think this is sufficient or do we need to take a different >>>> approach? >>> >>> Might I suggest one potential add: >>> >>> Truncating for focus.... maybe between these two sections add >>> something like: >>> >>> --snip-- >>> >>>> We are not aware of anyone trying to use the zulip or matrix servers >>>> for ietf work outside the main meeting. >>>> If you've used the services, please take a few minutes to provide >>>> feedback at tools-discuss@ietf.org . >>> >>> If you are interested in using these services more directly for your >>> working group's day-to-day communication, and are willing to test one >>> or both of these services on a primary basis for a while, please let >>> us know so we can help accommodate.   We especially encourage >>> leadership teams, and groups with an interest in remote >>> participation/communication to get involved here. > I think we directly approach the IESG, IAB, IRTF chair, and manycouches > (which is the shmoo list) with followup messages. >>> >>> If you are one of those who has had, or has reported, issues using >>> Jabber, please take some time now to work with these new services and >>> help the IETF help the community. >>> >>> The more usage and exposure these services get, the better informed >>> the IETF's future planning will be. >>> >>>> Is providing local jabber accounts and a web interface to jabber >>>> sufficient? >>>> Are there features that matrix or zulip provide that are truly >>>> helpful for progressing IETF work? If so, please describe how they >>>> are helping. >>> >>> --snip-- >>> >>> My thoughts just for this list (and its public archive): >>> >>> I feel like we don't want to just be observers here.  We've all heard >>> *repeated* complaints about Jabber.   I like Jabber, but, really, >>> we've gotten complaints, and here we're trying to solve issues, and >>> we've had...  37 people participate. >>> >>> I feel like we should encourage, even *prod*, the community to work >>> with these new services (including the new Jabber client services) >>> and really get involved in this process. >>> >>> And there are some obvious candidates for these things: >>> >>> * We should encourage the IESG, IAB, IRTF leadership teams to get >>> involved.  Not to mention the Tools Architecture Team, and even the >>> larger Tools-Discuss team. >>> >>> * We should encourage the XMPP, SHMOO, MANYCOUCHES, and any other >>> such groups to get involved. >>> >>> * We should encourage anyone currently using IETF Slack or other >>> alternative channels. >>> >>> * We should encourage the team members for each of the three >>> protocols (i.e. the people who set up Prosody/EJabberd, Matrix, and >>> Zulip) to step up and help us encourage participation. >>> >>> * Because Matrix has active attention from its developers, I have >>> been hanging out on Zulip, I'd like to make an Implementation stream >>> there and see if I can get the six of us involved.  :-) > Sure! >>> >>> * We should make clear that if people want positive change, they need >>> to get involved. >>> >>> Otherwise, a less-informed decision will be made, and the community >>> will be less-happy. >>> >>> You obviously don't need to use my words, or even any of this, this >>> is just feedback.  The IETF needs some visible guidance and reminders >>> to get involved here, and I think that falls to us. >>> >>> Glen >>> >> >> -- >> Jay Daley >> IETF Executive Director >> jay@ietf.org >> >> > From nobody Thu Dec 10 10:37:56 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 6F5F53A119E for ; Thu, 10 Dec 2020 10:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=hc8FHZCs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Q5GgDHso 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 RHc6A0wGAdft for ; Thu, 10 Dec 2020 10:37:53 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB9D3A119C for ; Thu, 10 Dec 2020 10:37:53 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BFED45C0186 for ; Thu, 10 Dec 2020 13:37:51 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Thu, 10 Dec 2020 13:37:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=rUpNq fJiw1zCPACpIGyXBl3IlXRvY3TEfuTTxC8rEHA=; b=hc8FHZCssvjM7Nznknkhy vNijZlrzgUf6+87GlWbH5V0VUYaPczlvEOEpZsN6d758MilOFUPxGyvOVOf0Ikf/ jdpWd1DGa3e+hyibKIghD2JRlUJ4KOPumW8/9N+Y2mubt9OFlYST11OJqK+2lt5p BevgCWYvXXAP9SvAjcfPHuIMMMzkf1yacgsvqBSSEEY2TEHR/M7Jhjr5xzHjOIu7 ZlPM7c4zgJ/FlULKrP/jULVSH+as6QnqWHsVaTFaVdhYaTTWw+fNTvSXHVRSxv8n jii501NBc1ahwKt44er29+p9dk1mEWo2mmIvSfQzTzb1m9gqyCj0et2jbV1cteSy w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=rUpNqfJiw1zCPACpIGyXBl3IlXRvY3TEfuTTxC8rE HA=; b=Q5GgDHsoLaD1xXLXjXvfqfX/71zQivmVMlA6w8HcseJeyCnsLnVJKuy9N tjHoWrO1fwOwX3oB0X9GCRV3P4oHw5Zq4uz5chIVc2UUKweE23rjpg3JJcFcbBHQ 2vDXU4OJZHGFMuoMBB2ofK9ZRqFtIeDQLFIZSx5YrTCjro7TofBlTs/aS0dKW56u DXFnqYqiRfGc5ltDMAT25pAGAGVt4c3hFcw4N0TwrhS5yAyrVsHyoG7XpdrNRB26 2GYZ+k45GDFJm+pIcjQxiTd4DVI2XJs7LlPRZQdHCnKUZTB1IjX83UKHns88C48p OMulZJmqcr0E4sdX8Fe8bCBKx4Jig== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudektddgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorggr mhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeelve ejfeevhfdvfeeftdegfeduveekkeejgfffgfeffeeiheelleefgfegfeeuvdenucffohhm rghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D3F3A6F6005F; Thu, 10 Dec 2020 13:37:26 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: In-Reply-To: <7db35978-94c4-f67a-08d2-031746b0cbd0@amsl.com> References: <79a73ae2-d565-33b3-6753-58587269861c@nostrum.com> <41D3FBF3-81F4-49ED-B776-DE3D8E52071B@ietf.org> <1c886ee6-e7be-21c1-167c-e1e25a5dadfd@nostrum.com> <7db35978-94c4-f67a-08d2-031746b0cbd0@amsl.com> Date: Thu, 10 Dec 2020 18:36:07 +0000 From: "Alexey Melnikov" To: tools-implementation@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Tools-implementation] =?utf-8?q?2nd_iteration=3A_Re=3A_Draft_of?= =?utf-8?q?_message_about_chat_trials?= 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 Dec 2020 18:37:56 -0000 On Thu, Dec 10, 2020, at 6:10 PM, Glen wrote: > This seems good to me... +1 >=20 > Glen >=20 > On 12/10/2020 06:34, Robert Sparks wrote: > > I've tried to worked the spirit of Glen's suggestions into the text,= and=20 > > aimed people at some specific resources on matrix and zulip > >=20 > > Some inline comments at the end. > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > To: ietf-announce > >=20 > > Subject: Next steps: chat service trials > >=20 > > We have been running trial zulip, matrix, and xmpp services since Oc= tober. > > See > > > >=20 > > As noted in those announcements, the issue that we are trying to add= ress=20 > > is the difficulty people have been reporting obtaining jabber servic= es=20 > > and clients. We are hopeful that these trials will help the communit= y=20 > > develop a better sense of whether to focus on improving the experien= ces=20 > > with xmpp or to pursue other chat solutions. We are also open to the= =20 > > possibility that these other solutions may be worth operating in=20 > > addition to improving the experiences from xmpp. > >=20 > > However, usage and feedback so far has not been sufficient to inform= =20 > > what services we should run in the future. > >=20 > > We had around 50 local jabber accounts created on xmpp-trial1.ietf.o= rg,=20 > > and around 40 accounts were created on each of the matrix and zulip=20= > > services. > > Few rooms have been created on the matrix service other than those=20= > > bridging to xmpp. > > Few streams were created on the zulip service other than those bridg= ing=20 > > to xmpp and those ingesting a few mailing lists. > >=20 > > We are not aware of anyone trying to use the zulip or matrix servers= for=20 > > ietf work outside the main meeting. > >=20 > > If you've used the services, please take a few minutes to provide=20= > > feedback at tools-discuss@ietf.org. > >=20 > > Is providing local jabber accounts and a web interface to jabber suf= ficient? > > Are there features that matrix or zulip provide that are truly helpf= ul=20 > > for progressing IETF work? If so, please describe how they are helpi= ng. > >=20 > > To collect more feedback, we are planning to extend the trials throu= gh=20 > > IETF 110. Please take advantage of these services between now and th= en=20 > > (at interim meetings for example) and let us know what you find to b= e=20 > > effective. > >=20 > > If you are interested in using these services more directly for your= =20 > > group's day-to-day communication, and are willing to test one or bot= h of=20 > > these services on a primary basis for a while, please coordinate wit= h=20 > > the appropriate leadership and let the tools team know so we can hel= p=20 > > accommodate.=C2=A0 Please consider using these services for ad-hoc,=20= > > design-team meetings, and even interims (again, coordinating with th= e=20 > > appropriate leadership). > >=20 > > If you have had issues using Jabber in the past, please take some ti= me=20 > > now to work with these new services and describe whether they improv= e=20 > > your experience. > >=20 > > We need more feedback about these services to develop a sense of wha= t=20 > > will best meet the community's needs going forward. Please engage in= =20 > > exploring and discussing them at tools-discuss@ietf.org. > >=20 > > While exploring, feel free to use the trial1-feedback room on Matrix= and=20 > > the trial1-feedback stream on Zulip. > >=20 > > Thanks again to the volunteers that have been helping configure thes= e=20 > > services and keep them going. > >=20 > > Robert Sparks, Tools Team Chair > >=20 > > =3D=3D=3D=3D=3D > >=20 > > On 12/9/20 2:02 PM, Jay Daley wrote: > >> I=E2=80=99m too busy right now to give detailed feedback but I like= all of=20 > >> Glen=E2=80=99s suggestions. > >> > >> Jay > >> > >>> On 10/12/2020, at 8:50 AM, Glen >>> > wrote: > >>> > >>> On 12/9/2020 11:30, Robert Sparks wrote: > >>>> Do you think this is sufficient or do we need to take a different= =20 > >>>> approach? > >>> > >>> Might I suggest one potential add: > >>> > >>> Truncating for focus.... maybe between these two sections add=20 > >>> something like: > >>> > >>> --snip-- > >>> > >>>> We are not aware of anyone trying to use the zulip or matrix serv= ers=20 > >>>> for ietf work outside the main meeting. > >>>> If you've used the services, please take a few minutes to provide= =20 > >>>> feedback at tools-discuss@ietf.org . > >>> > >>> If you are interested in using these services more directly for yo= ur=20 > >>> working group's day-to-day communication, and are willing to test = one=20 > >>> or both of these services on a primary basis for a while, please l= et=20 > >>> us know so we can help accommodate. =C2=A0=C2=A0We especially enco= urage=20 > >>> leadership teams, and groups with an interest in remote=20 > >>> participation/communication to get involved here. > > I think we directly approach the IESG, IAB, IRTF chair, and manycouc= hes=20 > > (which is the shmoo list) with followup messages. > >>> > >>> If you are one of those who has had, or has reported, issues using= =20 > >>> Jabber, please take some time now to work with these new services = and=20 > >>> help the IETF help the community. > >>> > >>> The more usage and exposure these services get, the better informe= d=20 > >>> the IETF's future planning will be. > >>> > >>>> Is providing local jabber accounts and a web interface to jabber=20= > >>>> sufficient? > >>>> Are there features that matrix or zulip provide that are truly=20= > >>>> helpful for progressing IETF work? If so, please describe how the= y=20 > >>>> are helping. > >>> > >>> --snip-- > >>> > >>> My thoughts just for this list (and its public archive): > >>> > >>> I feel like we don't want to just be observers here. =C2=A0We've a= ll heard=20 > >>> *repeated* complaints about Jabber. =C2=A0=C2=A0I like Jabber, but= , really,=20 > >>> we've gotten complaints, and here we're trying to solve issues, an= d=20 > >>> we've had... =C2=A037 people participate. > >>> > >>> I feel like we should encourage, even *prod*, the community to wor= k=20 > >>> with these new services (including the new Jabber client services)= =20 > >>> and really get involved in this process. > >>> > >>> And there are some obvious candidates for these things: > >>> > >>> * We should encourage the IESG, IAB, IRTF leadership teams to get=20= > >>> involved. =C2=A0Not to mention the Tools Architecture Team, and ev= en the=20 > >>> larger Tools-Discuss team. > >>> > >>> * We should encourage the XMPP, SHMOO, MANYCOUCHES, and any other=20= > >>> such groups to get involved. > >>> > >>> * We should encourage anyone currently using IETF Slack or other=20= > >>> alternative channels. > >>> > >>> * We should encourage the team members for each of the three=20 > >>> protocols (i.e. the people who set up Prosody/EJabberd, Matrix, an= d=20 > >>> Zulip) to step up and help us encourage participation. > >>> > >>> * Because Matrix has active attention from its developers, I have=20= > >>> been hanging out on Zulip, I'd like to make an Implementation stre= am=20 > >>> there and see if I can get the six of us involved. =C2=A0:-) > > Sure! > >>> > >>> * We should make clear that if people want positive change, they n= eed=20 > >>> to get involved. > >>> > >>> Otherwise, a less-informed decision will be made, and the communit= y=20 > >>> will be less-happy. > >>> > >>> You obviously don't need to use my words, or even any of this, thi= s=20 > >>> is just feedback. =C2=A0The IETF needs some visible guidance and r= eminders=20 > >>> to get involved here, and I think that falls to us. > >>> > >>> Glen > >>> > >> > >> --=20 > >> Jay Daley > >> IETF Executive Director > >> jay@ietf.org > >> > >> > >=20 >=20 > --=20 > Tools-implementation mailing list > Tools-implementation@ietf.org > https://www.ietf.org/mailman/listinfo/tools-implementation >