From nobody Tue Jul 3 09:22:12 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B35130FD1 for ; Tue, 3 Jul 2018 09:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 zeDf6rHf41Tv for ; Tue, 3 Jul 2018 09:21:58 -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 B30D113108F for ; Tue, 3 Jul 2018 09:16:18 -0700 (PDT) Received: from unescapeable.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w63GGDqa083224 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 3 Jul 2018 11:16:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be unescapeable.local From: Robert Sparks To: IETF Tools Development Message-ID: Date: Tue, 3 Jul 2018 11:16:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [TOOLS-DEVELOPMENT] Better agenda support for meetings other than WG/RG group meetings during the IETF week X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:22:10 -0000 Some fodder for discussion between now and the tools call next week (10 July), and possibly during that call. Please read through this and share your thoughts, particularly if you see an aspect that we need to consider, but I've missed: ----------------- Summary: We have many non WG/RG things asking to be on the official agenda so that people can find them.  The workaround we're currently using clutters the week-view of the agenda and the customized ics files the datatracker makes available for download.  Some of the meetings are starting to ask for the ability to manage agendas, materials, and minutes. Not all of them are appropriate for including in the IETF meeting proceedings. We need to discuss what we will support, and prioritize when we will do the work needed to support what we chose. That work will need to include some significant model design. We should also look for ways to help ensure that the appropriate approval process is not shortcut as more people ask for this kind of support. ----------------- A little more detail on some of that: For several years, we have had requests to put non WG or RG things on the agenda. Examples include: * the newcomer's (and other) tutorials * the IEPG meeting * AD office hours for some subset of areas * The WG chairs lunch We've recently had a bloom of such things, adding * many ANRW sessions * the Systers lunch * The Hackdemo Happy Hour And I expect we'll eventually get requests to show things like the HotRFC sessions and the 3gpp/ietf coordination meeting. Right now, we are hacking those things onto the agenda using a "non-session" session type. You'll note the agenda for IETF 102 has these permanently showing on the customizable calendar. (Look at the graphical schedule at for instance.) These also can't currently be removed from the customized .ics files the datatracker provides. We need to model these differently. Henrik has some initial thoughts about reworking the way we hold Group attributes that would allow us to make displaying the agenda more data-driven, letting us present tabs for different classes of meeting type. This is likely a good path to pursue, but we will need to be careful to preserve the agenda pages and, particularly, the proceedings pages for previous meetings. The Hackathon has been asking for agenda, materials, and minutes support for several meetings. We've hacked around things to provide that. At this meeting, the various ANRW sessions asked for similar support. I don't think we're providing that this time. We should make it so that we can do so when it's appropriate. We also need to be able to say what ends up in the IETF meeting proceedings. (Should the ANRW materials show up in the IETF meeting proceedings?) ---- From nobody Mon Jul 9 11:24:42 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72E4130E73 for ; Mon, 9 Jul 2018 11:24:40 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 j8iFl0DlTa74 for ; Mon, 9 Jul 2018 11:24:38 -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 C7AD7126CC7 for ; Mon, 9 Jul 2018 11:24:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B7726300A2A for ; Mon, 9 Jul 2018 14:24:36 -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 LwKRW9nYPw4V for ; Mon, 9 Jul 2018 14:24:35 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id C2D86300261 for ; Mon, 9 Jul 2018 14:24:35 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <8FC61B4A-BBEF-4658-916A-EBAED141D0B6@vigilsec.com> Date: Mon, 9 Jul 2018 14:24:36 -0400 To: IETF Tools Development X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 10 July 2018 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 18:24:41 -0000 Tools Call Agenda -- 10 July 2018 at 1:00 Eastern JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m440dd848726339c03e605b9956e38bac Meeting number (access code): 640 103 570 Meeting password: tools JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Meeting number (access code): 640 103 570 Meeting password: tools 1. Datatracker Projects - Expected Datatracker Releases -- Robert and Henrik -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan - GDPR Compliance -- Robert and Henrik - Management of "extra" IETF meeting sessions -- Robert 2. Community & Other Projects - Discontinue MonArch email archives -- Robert and Ryan -- Community clearly still likes MonArch speed 3. RFC Services Projects - RFC Format Contracts -- Heather and Robert -- IDnits -- Publication Formatter -- Text Submission -- RFClint -- SVGcheck -- XMLdiff 4. Server Infrastructure - IESG discussions of DMARC -- Henrik and Alexey -- Deployed for all mail lists -- Should we transition to ARC? 5. Parking Lot - Prepare the RFC Production Center code for publication 6. AOB From nobody Tue Jul 10 14:50:29 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C2A131162 for ; Tue, 10 Jul 2018 14:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xKt3Mmles3ia for ; Tue, 10 Jul 2018 14:50:25 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC819130E90 for ; Tue, 10 Jul 2018 14:50:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id F0DC21D1B85 for ; Tue, 10 Jul 2018 14:50:23 -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 P-CSMlvUoqnl for ; Tue, 10 Jul 2018 14:50:23 -0700 (PDT) Received: from [IPv6:2601:647:4200:a088:fd41:4742:9843:6162] (unknown [IPv6:2601:647:4200:a088:fd41:4742:9843:6162]) by c8a.amsl.com (Postfix) with ESMTPSA id CC39F1CADDC for ; Tue, 10 Jul 2018 14:50:23 -0700 (PDT) From: Alexa Morris Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <11D6D8DF-E909-4F4C-BC6E-DF74A6E23089@amsl.com> Date: Tue, 10 Jul 2018 14:50:24 -0700 To: IETF Tools Development X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [TOOLS-DEVELOPMENT] Issue with text files in Wagtail X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 21:50:28 -0000 Following up on this morning=E2=80=99s discussion, here is a bit more = information about the Wagtail text file issue. As far as we can = determine, there are three sets of files currently affected: - IESG minutes - Appeals and appeal responses - IESG-internal docs linked from or embedded in the IESG telechat agenda = (minutes to be approved, roll call, action item list); note that = permission to view this is limited to those with an IESG or Secretariat = role. All of those files, even ones added or updated after the website = switchover, currently live on www6 (the old site) and we are pointing to = them from www7 (the new site). If you want to upload a file in Wagtail, it will end up with a url = structure like =E2=80=9Cwww.ietf.org/documents/randomnumber/filename=E2=80= =9D. See https://ietf.org/documents/170/demo_text_file.txt for an = example of a file I just uploaded. All documents (e.g., PDF policies, = PPT presentations, IESG minutes) go into the same documents directory. = The number in the URL (e.g., 170) appears to be a subdirectory for that = file, with the file itself living in that subdirectory. If it's still the case that the IETF wants to have things like minutes = organized into predictable directories, say for people who are scraping = minutes with their own tools, then I think this organizational structure = is an issue.=20 Note also that as far as I could determine, there is no way to display = things uploaded to the documents directory in your browser; you must = save and then open the file. However, that may be because I don't know = what I'm doing...=20 I'm happy to discuss this further in Montreal. -Alexa= From nobody Tue Jul 10 15:18:48 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABACE131196 for ; Tue, 10 Jul 2018 15:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 o_5yd6YVAqF0 for ; Tue, 10 Jul 2018 15:18:44 -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 9F61C1311C2 for ; Tue, 10 Jul 2018 15:18:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5BE9A300A2A for ; Tue, 10 Jul 2018 18:18:42 -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 pRpGpBQr4SJQ for ; Tue, 10 Jul 2018 18:18:41 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 32BB5300557; Tue, 10 Jul 2018 18:18:41 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Russ Housley In-Reply-To: <11D6D8DF-E909-4F4C-BC6E-DF74A6E23089@amsl.com> Date: Tue, 10 Jul 2018 18:18:02 -0400 Cc: IETF Tools Development Content-Transfer-Encoding: quoted-printable Message-Id: References: <11D6D8DF-E909-4F4C-BC6E-DF74A6E23089@amsl.com> To: Alexa Morris X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Issue with text files in Wagtail X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 22:18:47 -0000 > On Jul 10, 2018, at 5:50 PM, Alexa Morris wrote: >=20 > Following up on this morning=E2=80=99s discussion, here is a bit more = information about the Wagtail text file issue. As far as we can = determine, there are three sets of files currently affected: >=20 > - IESG minutes > - Appeals and appeal responses > - IESG-internal docs linked from or embedded in the IESG telechat = agenda (minutes to be approved, roll call, action item list); note that = permission to view this is limited to those with an IESG or Secretariat = role. >=20 > All of those files, even ones added or updated after the website = switchover, currently live on www6 (the old site) and we are pointing to = them from www7 (the new site). >=20 > If you want to upload a file in Wagtail, it will end up with a url = structure like =E2=80=9Cwww.ietf.org/documents/randomnumber/filename=E2=80= =9D. See https://ietf.org/documents/170/demo_text_file.txt for an = example of a file I just uploaded. All documents (e.g., PDF policies, = PPT presentations, IESG minutes) go into the same documents directory. = The number in the URL (e.g., 170) appears to be a subdirectory for that = file, with the file itself living in that subdirectory. >=20 > If it's still the case that the IETF wants to have things like minutes = organized into predictable directories, say for people who are scraping = minutes with their own tools, then I think this organizational structure = is an issue.=20 >=20 > Note also that as far as I could determine, there is no way to display = things uploaded to the documents directory in your browser; you must = save and then open the file. However, that may be because I don't know = what I'm doing...=20 >=20 > I'm happy to discuss this further in Montreal. >=20 > -Alexa It seems to treat them like objects that can be downloaded but not = displayed, like a .zip file. If you are available at the start of the code sprint, please come talk = about it. Russ From nobody Tue Jul 10 15:26:11 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6C6131196 for ; Tue, 10 Jul 2018 15:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 e-v7yZQwhPwp for ; Tue, 10 Jul 2018 15:26:07 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816341311C1 for ; Tue, 10 Jul 2018 15:26:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7BF781D1B87; Tue, 10 Jul 2018 15:26: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 mVT0UsiSdvVF; Tue, 10 Jul 2018 15:26:05 -0700 (PDT) Received: from [IPv6:2601:647:4200:a088:fd41:4742:9843:6162] (unknown [IPv6:2601:647:4200:a088:fd41:4742:9843:6162]) by c8a.amsl.com (Postfix) with ESMTPSA id 4E0671CADDC; Tue, 10 Jul 2018 15:26:05 -0700 (PDT) From: Alexa Morris Message-Id: <3D9E2D62-E78E-46E7-94B1-90D223C1FDEC@amsl.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3F1B56FE-B04A-406E-8865-55545611D45F" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 10 Jul 2018 15:26:06 -0700 In-Reply-To: Cc: IETF Tools Development To: Russ Housley References: <11D6D8DF-E909-4F4C-BC6E-DF74A6E23089@amsl.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Issue with text files in Wagtail X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 22:26:10 -0000 --Apple-Mail=_3F1B56FE-B04A-406E-8865-55545611D45F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 10, 2018, at 3:18 PM, Russ Housley = wrote: >=20 >=20 >=20 >> On Jul 10, 2018, at 5:50 PM, Alexa Morris wrote: >>=20 >> Following up on this morning=E2=80=99s discussion, here is a bit more = information about the Wagtail text file issue. As far as we can = determine, there are three sets of files currently affected: >>=20 >> - IESG minutes >> - Appeals and appeal responses >> - IESG-internal docs linked from or embedded in the IESG telechat = agenda (minutes to be approved, roll call, action item list); note that = permission to view this is limited to those with an IESG or Secretariat = role. >>=20 >> All of those files, even ones added or updated after the website = switchover, currently live on www6 (the old site) and we are pointing to = them from www7 (the new site). >>=20 >> If you want to upload a file in Wagtail, it will end up with a url = structure like =E2=80=9Cwww.ietf.org/documents/randomnumber/filename=E2=80= =9D. See https://ietf.org/documents/170/demo_text_file.txt for an = example of a file I just uploaded. All documents (e.g., PDF policies, = PPT presentations, IESG minutes) go into the same documents directory. = The number in the URL (e.g., 170) appears to be a subdirectory for that = file, with the file itself living in that subdirectory. >>=20 >> If it's still the case that the IETF wants to have things like = minutes organized into predictable directories, say for people who are = scraping minutes with their own tools, then I think this organizational = structure is an issue.=20 >>=20 >> Note also that as far as I could determine, there is no way to = display things uploaded to the documents directory in your browser; you = must save and then open the file. However, that may be because I don't = know what I'm doing...=20 >>=20 >> I'm happy to discuss this further in Montreal. >>=20 >> -Alexa >=20 > It seems to treat them like objects that can be downloaded but not = displayed, like a .zip file. >=20 > If you are available at the start of the code sprint, please come talk = about it. I am, and I will! Alexa >=20 > Russ --Apple-Mail=_3F1B56FE-B04A-406E-8865-55545611D45F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 10, 2018, at 3:18 PM, Russ Housley <housley@vigilsec.com> wrote:



On = Jul 10, 2018, at 5:50 PM, Alexa Morris <amorris@amsl.com> = wrote:

Following up on this morning=E2=80=99s= discussion, here is a bit more information about the Wagtail text file = issue. As far as we can determine, there are three sets of files = currently affected:

- IESG minutes
- Appeals and appeal responses
- IESG-internal = docs linked from or embedded in the IESG telechat agenda (minutes to be = approved, roll call, action item list); note that permission to view = this is limited to those with an IESG or Secretariat role.

All of those files, even ones added or updated = after the website switchover, currently live on www6 (the old site) and = we are pointing to them from www7 (the new site).

If you want to upload a file in Wagtail, it will end up with = a url structure like =E2=80=9Cwww.ietf.org/documents/randomnumber/filename=E2=80=9D. = See https://ietf.org/documents/170/demo_text_file.txt for an = example of a file I just uploaded. All documents (e.g., PDF policies, = PPT presentations, IESG minutes) go into the same documents directory. = The number in the URL (e.g., 170) appears to be a subdirectory for that = file, with the file itself living in that subdirectory.

If it's still the case that the IETF wants to have things = like minutes organized into predictable directories, say for people who = are scraping minutes with their own tools, then I think this = organizational structure is an issue. 

Note also that as far as I could determine, there is no way = to display things uploaded to the documents directory in your browser; = you must save and then open the file. However, that may be because I = don't know what I'm doing... 

I'm happy to discuss this further in Montreal.

-Alexa

It seems to treat them like = objects that can be downloaded but not displayed, like a .zip = file.

If you are = available at the start of the code sprint, please come talk about = it.

I am, and = I will!

Alexa


Russ

= --Apple-Mail=_3F1B56FE-B04A-406E-8865-55545611D45F-- From nobody Wed Jul 11 06:48:17 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9912130E3E for ; Wed, 11 Jul 2018 06:48:15 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 o62-Vp-CEIZI for ; Wed, 11 Jul 2018 06:48:12 -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 E8FCA130DC9 for ; Wed, 11 Jul 2018 06:48:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BFACE300A20 for ; Wed, 11 Jul 2018 09:48: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 KWVKXr_bX60w for ; Wed, 11 Jul 2018 09:48:08 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id E05203005A8 for ; Wed, 11 Jul 2018 09:48:08 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> Date: Wed, 11 Jul 2018 09:48:09 -0400 To: IETF Tools Development X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 13:48:16 -0000 During the tools call yesterday, we talked about writing some guidance = on this topic. Please review and comment. Russ =3D =3D =3D =3D =3D =3D =3D =3D=20 Guidance: When to Upgrade Server Software There are many reasons to upgrade the software on the IETF servers, including bug fixes, access to new features, performance improvement. Yet, the software update needs to be done a at time that is going to have minimal impact on the IETF community. The impact might be the result of a service outage while the upgrade take place, or it might be the result of an unexpected problem with the newly installed software. This guidance is intended to avoid outages when the IETF community is depending on the IETF servers the most. Guidelines Do not make updates to any major server software the week before or during the IETF meeting. Do not make updates to the IETF Datatracker on Wednesday or Thursday of the IESG formal telechat. Do not make updates to the IETF Datatracker a few days prior to the I-D cut-off date for an IETF meeting. Exceptions If something critical is broken, fix it. If a new feature will make things work more smoothly for the IESG or Secretariat, ask. If they want it now, give it to them now. Last update: 10 July 2018= From nobody Wed Jul 11 08:14:59 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12341130DE5 for ; Wed, 11 Jul 2018 08:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zCl_Zl2v8bPB for ; Wed, 11 Jul 2018 08:14:56 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 A41E0130DEF for ; Wed, 11 Jul 2018 08:14:55 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id i20-v6so6451883eds.12 for ; Wed, 11 Jul 2018 08:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YKtd1ZJmk4TLuPL9mwa3LE/sYJJIUmMnMixADEH8qtY=; b=UF2J0XIcDATuaKPYcIFRBSSyHARV3Zdya3zzwEXuT4qEgPrk5sLjDM1JRfe2a7YaNB rY9IefLWYmGoNGQ9JafO5BXxADdCX+XD69HV+u8ftaF0DHA5d6f2Fj7QDMcH59ZR1Pb8 kaAKrTb2g7bT8AQr/TFrbJ+1gC6QIfCu6MyIFuQt4oiyZJwgKAxpKoBIMYPEqSsJ7OYd ohmZMZg6pAzburHS0LqemMskuhZtdD9ml7Vq4YSwdpEI2uGWo4S5NbqpEivTgRAwDf6v yLPn9KpOBPI9QlpwVznyQDqSiu4TTJzg5qb/Wxg4jCbY/yoamROUHidJIdSYGhoczhdx ep2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YKtd1ZJmk4TLuPL9mwa3LE/sYJJIUmMnMixADEH8qtY=; b=OaWWkkY+ZvgNRYgJW8d1uixGfsXpeh+seD4urG0B3gvpnC8jjgagIqU1Q7txcpDcC4 6aIm9sT06laJuaJXWGt1IGMH5QGizprzqrYYcdPC1xE5qqnHjhaepHYdGmzBf+NS+TGv 7zyPK5hf3IlgeOK58ex2TuHdw/zORod4EIyV3pHk3xBRdv2c3y+U1duJ57QdeLrJgAfS um1CZmmeU2rkqHNaQdwZyXcJscz8BNmLcCbSs+mwEQi60US3ATjCatvI3iZx3wleD6rT K/1GArDiFf1FI92mx9LQ2mFx8MIZZwrWvfExlXbI2M90GsP3GQvLLCAzQnwVVTT8H5i6 LZVw== X-Gm-Message-State: APt69E2T81mer6aC16+rwXqDKgf8mFR2RYZKNnZDFxOivDDvSZ3sXq1N imnTuzr9SzyHgzkGrtA9ejU= X-Google-Smtp-Source: AAOMgpeHdlLAvBcY9vkyVmMSdvyOu6cJqyIHQslXMzVmOscR6CORroMhMfPl6lUBSY+CgNI7QjsgMw== X-Received: by 2002:a50:aa43:: with SMTP id p3-v6mr26388598edc.233.1531322094255; Wed, 11 Jul 2018 08:14:54 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:f3a:11b1:1a6a:ad50:7be7? ([2601:647:4d01:f3a:11b1:1a6a:ad50:7be7]) by smtp.gmail.com with ESMTPSA id c19-v6sm4726950ede.13.2018.07.11.08.14.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 08:14:53 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A0E8E2E1-37E7-4D21-9CD8-3480D0BFB611"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 11 Jul 2018 08:14:51 -0700 In-Reply-To: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> Cc: Bob Hinden , IETF Tools Development To: Russ Housley References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 15:14:58 -0000 --Apple-Mail=_A0E8E2E1-37E7-4D21-9CD8-3480D0BFB611 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looks good to me. Sorry for missing yesterday=E2=80=99s call. Bob > On Jul 11, 2018, at 6:48 AM, Russ Housley = wrote: >=20 > During the tools call yesterday, we talked about writing some guidance = on this topic. Please review and comment. >=20 > Russ >=20 >=20 > =3D =3D =3D =3D =3D =3D =3D =3D >=20 >=20 > Guidance: When to Upgrade Server Software >=20 > There are many reasons to upgrade the software on the IETF servers, > including bug fixes, access to new features, performance improvement. > Yet, the software update needs to be done a at time that is going to > have minimal impact on the IETF community. The impact might be the > result of a service outage while the upgrade take place, or it might > be the result of an unexpected problem with the newly installed > software. This guidance is intended to avoid outages when the > IETF community is depending on the IETF servers the most. >=20 > Guidelines >=20 > Do not make updates to any major server software the week before > or during the IETF meeting. >=20 > Do not make updates to the IETF Datatracker on Wednesday or > Thursday of the IESG formal telechat. >=20 > Do not make updates to the IETF Datatracker a few days prior to > the I-D cut-off date for an IETF meeting. >=20 > Exceptions >=20 > If something critical is broken, fix it. >=20 > If a new feature will make things work more smoothly for the IESG or > Secretariat, ask. If they want it now, give it to them now. >=20 >=20 > Last update: 10 July 2018 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --Apple-Mail=_A0E8E2E1-37E7-4D21-9CD8-3480D0BFB611 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAltGHusACgkQrut0EXfn u6gAVwf6A9OeJwClXU5Ni6JhMYtbN/jxaTxW1JX+rTEwKJopfoBmB+zvvLLxPIGg VNuUzsh4tKoYq658ag/abFsdOJN+hylEVnI4O9pZKvGXp4URIzoFEjbY+Fnqgh30 rq7hXpXuhRPrunA+fyBAfRNCnbPwfLQVYFz5UKBAB6mK+zYFQNn9hZl1y6cmodhD tVHbwnGSYQCq3eW00lyPayhekm7f+t7I7g9UbswEjLh9TbLY/b2ugRqbRZyRQYzP OAXxnN6zUz9gZIb+m1efVZMPjrrP5teuJcUCR0dxFP8o+OTmLO4mkv44csXq4jyY 8tUU5aSAv0Dcv45h2EiAoM5EKcngeg== =1irT -----END PGP SIGNATURE----- --Apple-Mail=_A0E8E2E1-37E7-4D21-9CD8-3480D0BFB611-- From nobody Wed Jul 11 09:25:08 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5938130F9C for ; Wed, 11 Jul 2018 09:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 DQUJsPFfQ1lW for ; Wed, 11 Jul 2018 09:24: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 BCF06130F9D for ; Wed, 11 Jul 2018 09:24:56 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6BGOsg2039359 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Jul 2018 11:24:55 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Ben Campbell In-Reply-To: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> Date: Wed, 11 Jul 2018 11:24:36 -0500 Cc: IETF Tools Development Content-Transfer-Encoding: quoted-printable Message-Id: <11CE5AE4-21C7-461A-9D7D-303F0E8F4065@nostrum.com> References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 16:25:06 -0000 LGTM. Ben. > On Jul 11, 2018, at 8:48 AM, Russ Housley = wrote: >=20 > During the tools call yesterday, we talked about writing some guidance = on this topic. Please review and comment. >=20 > Russ >=20 >=20 > =3D =3D =3D =3D =3D =3D =3D =3D=20 >=20 >=20 > Guidance: When to Upgrade Server Software >=20 > There are many reasons to upgrade the software on the IETF servers, > including bug fixes, access to new features, performance improvement. > Yet, the software update needs to be done a at time that is going to > have minimal impact on the IETF community. The impact might be the > result of a service outage while the upgrade take place, or it might > be the result of an unexpected problem with the newly installed > software. This guidance is intended to avoid outages when the > IETF community is depending on the IETF servers the most. >=20 > Guidelines >=20 > Do not make updates to any major server software the week before > or during the IETF meeting. >=20 > Do not make updates to the IETF Datatracker on Wednesday or > Thursday of the IESG formal telechat. >=20 > Do not make updates to the IETF Datatracker a few days prior to > the I-D cut-off date for an IETF meeting. >=20 > Exceptions >=20 > If something critical is broken, fix it. >=20 > If a new feature will make things work more smoothly for the IESG or > Secretariat, ask. If they want it now, give it to them now. >=20 >=20 > Last update: 10 July 2018 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Thu Jul 12 06:14:31 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D7F130F19 for ; Thu, 12 Jul 2018 06:14:20 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 kUw_cK3pQgXl for ; Thu, 12 Jul 2018 06:14: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 76927130F15 for ; Thu, 12 Jul 2018 06:14:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C856D300A2A for ; Thu, 12 Jul 2018 09:14:15 -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 o7qVydWzxwjN for ; Thu, 12 Jul 2018 09:14:13 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 6F8FB300438 for ; Thu, 12 Jul 2018 09:14:13 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 12 Jul 2018 09:14:13 -0400 References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> To: IETF Tools Development In-Reply-To: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> Message-Id: X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 13:14:30 -0000 I have not received any suggestions to change the text. Where is the = best place to post this? Russ > =3D =3D =3D =3D =3D =3D =3D =3D=20 >=20 >=20 > Guidance: When to Upgrade Server Software >=20 > There are many reasons to upgrade the software on the IETF servers, > including bug fixes, access to new features, performance improvement. > Yet, the software update needs to be done a at time that is going to > have minimal impact on the IETF community. The impact might be the > result of a service outage while the upgrade take place, or it might > be the result of an unexpected problem with the newly installed > software. This guidance is intended to avoid outages when the > IETF community is depending on the IETF servers the most. >=20 > Guidelines >=20 > Do not make updates to any major server software the week before > or during the IETF meeting. >=20 > Do not make updates to the IETF Datatracker on Wednesday or > Thursday of the IESG formal telechat. >=20 > Do not make updates to the IETF Datatracker a few days prior to > the I-D cut-off date for an IETF meeting. >=20 > Exceptions >=20 > If something critical is broken, fix it. >=20 > If a new feature will make things work more smoothly for the IESG or > Secretariat, ask. If they want it now, give it to them now. >=20 >=20 > Last update: 10 July 2018 From nobody Thu Jul 12 06:33:49 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F6E130F21 for ; Thu, 12 Jul 2018 06:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 VV3XqVfEDU32 for ; Thu, 12 Jul 2018 06:33:45 -0700 (PDT) Received: from outbound-ss-348.hostmonster.com (outbound-ss-348.hostmonster.com [74.220.202.212]) (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 CEEBE130F08 for ; Thu, 12 Jul 2018 06:33:45 -0700 (PDT) Received: from cmgw13.unifiedlayer.com (unknown [10.9.0.13]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id AD8201E06CD for ; Thu, 12 Jul 2018 07:33:44 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id dbj6fvPZGYe1jdbj6fGHlz; Thu, 12 Jul 2018 07:33:44 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=xMoiMPO3cEaBIL20Ubh8ik5rtiUL8D8fY9v4rKRreYc=; b=kFWgxr5nSD/zjBCaSuyYwCRkJC g9N5+IRITyU6gO2cLnHyUdMC9HEss0azedxa1OYKAPu0NlODegT2S2R+FBsB7OSGRtuDO+Z3YgIjD lTQ6IMb49vjYnJ1A1Wj1LjbWA; Received: from [172.58.187.246] (port=20097 helo=[IPV6:2607:fb90:a851:73e1:0:2:7dd3:bc01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fdbj4-003il2-2i; Thu, 12 Jul 2018 07:33:44 -0600 From: Lou Berger To: Russ Housley , IETF Tools Development Date: Thu, 12 Jul 2018 09:33:36 -0400 Message-ID: <1648eb26f80.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> User-Agent: AquaMail/1.15.0-916 (build: 101500003) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 172.58.187.246 X-Source-L: No X-Exim-ID: 1fdbj4-003il2-2i X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPV6:2607:fb90:a851:73e1:0:2:7dd3:bc01]) [172.58.187.246]:20097 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 13:33:48 -0000 Hi Russ, Thanks for this. Two comments below ---------- On July 12, 2018 9:15:03 AM Russ Housley wrote: > I have not received any suggestions to change the text. Where is the best > place to post this? > > Russ > > >> = = = = = = = = >> >> >> Guidance: When to Upgrade Server Software >> >> There are many reasons to upgrade the software on the IETF servers, >> including bug fixes, access to new features, performance improvement. >> Yet, the software update needs to be done a at time that is going to >> have minimal impact on the IETF community. The impact might be the >> result of a service outage while the upgrade take place, or it might >> be the result of an unexpected problem with the newly installed >> software. This guidance is intended to avoid outages when the >> IETF community is depending on the IETF servers the most. >> >> Guidelines >> >> Do not make updates to any major server software the week before >> or during the IETF meeting. >> >> Do not make updates to the IETF Datatracker on Wednesday or >> Thursday of the IESG formal telechat. >> >> Do not make updates to the IETF Datatracker a few days prior to >> the I-D cut-off date for an IETF meeting. I suggest including the mail server and archive infrastructure at this time as well, given the typical male load during that time. This period Should probably be expanded to include the working group agenda upload deadlines as well. >> >> Exceptions >> >> If something critical is broken, fix it. >> >> If a new feature will make things work more smoothly for the IESG or >> Secretariat, ask. If they want it now, give it to them now. >> How about s/want / deem it sufficiently critical to do Thanks Lou >> >> Last update: 10 July 2018 > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > From nobody Thu Jul 12 09:24:14 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4DD130E9A for ; Thu, 12 Jul 2018 09:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 RV_NLkFfWmC1 for ; Thu, 12 Jul 2018 09:24:10 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 AD6AF130E89 for ; Thu, 12 Jul 2018 09:24:10 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 48194175DAD for ; Thu, 12 Jul 2018 10:24:10 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id deO2f4nUdd20TdeO2fvJ8N; Thu, 12 Jul 2018 10:24:10 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:To:From:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=SzpsQMoDYdH2EVklNMlifk/bEshOXzcDSiwbwoq8uPk=; b=pv/yifwzsJ6905EhGJHUqoBdrs qq9eDfyZU0UfTIxwJn5TeVqxWLNOskaNbkNbMmFnMKTIazHqIxtf5iSShUAa8YcbPEaISj0Mm3Wz8 wfPHIW/GEe7cVXmHWou79CcoM; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:48728 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fdeO1-000CEr-Rl; Thu, 12 Jul 2018 10:24:10 -0600 From: Lou Berger To: Russ Housley , IETF Tools Development References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> <1648eb26f80.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Message-ID: <549826e5-f9d8-6677-4fa4-1f6600b550a6@labn.net> Date: Thu, 12 Jul 2018 12:24:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1648eb26f80.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Source-L: No X-Exim-ID: 1fdeO1-000CEr-Rl X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:48728 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 16:24:13 -0000 PS sorry about the humorous voice to text typos... On 7/12/2018 9:33 AM, Lou Berger wrote: > Hi Russ, > > Thanks for this. Two comments below > > > ---------- > On July 12, 2018 9:15:03 AM Russ Housley wrote: > >> I have not received any suggestions to change the text. Where is the best >> place to post this? >> >> Russ >> >> >>> = = = = = = = = >>> >>> >>> Guidance: When to Upgrade Server Software >>> >>> There are many reasons to upgrade the software on the IETF servers, >>> including bug fixes, access to new features, performance improvement. >>> Yet, the software update needs to be done a at time that is going to >>> have minimal impact on the IETF community. The impact might be the >>> result of a service outage while the upgrade take place, or it might >>> be the result of an unexpected problem with the newly installed >>> software. This guidance is intended to avoid outages when the >>> IETF community is depending on the IETF servers the most. >>> >>> Guidelines >>> >>> Do not make updates to any major server software the week before >>> or during the IETF meeting. >>> >>> Do not make updates to the IETF Datatracker on Wednesday or >>> Thursday of the IESG formal telechat. >>> >>> Do not make updates to the IETF Datatracker a few days prior to >>> the I-D cut-off date for an IETF meeting. > I suggest including the mail server and archive infrastructure at this time > as well, given the typical male load during that time. This period Should > probably be expanded to include the working group agenda upload deadlines > as well. > >>> Exceptions >>> >>> If something critical is broken, fix it. >>> >>> If a new feature will make things work more smoothly for the IESG or >>> Secretariat, ask. If they want it now, give it to them now. >>> > How about s/want / deem it sufficiently critical to do > > Thanks > > Lou >>> Last update: 10 July 2018 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > From nobody Thu Jul 12 09:46:53 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCD3130E89 for ; Thu, 12 Jul 2018 09:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 yOfMSDODiQ2I for ; Thu, 12 Jul 2018 09:46:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 86A4F130EE3 for ; Thu, 12 Jul 2018 09:46:48 -0700 (PDT) Received: from [192.168.178.20] ([93.217.65.248]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LobGI-1gInFP0Bcw-00gW3e; Thu, 12 Jul 2018 18:46:45 +0200 To: "Heather Flanagan (RFC Series Editor)" , tools-development@ietf.org References: <6ADCCD42-0FDF-46EE-83B9-6550A34BEAD8@rfc-editor.org> <3b4c5bd8-453b-6e92-88d6-48ea18f5c926@rfc-editor.org> From: Julian Reschke Message-ID: <7e47683a-5b4e-76b3-2183-bfd17c52bbb5@gmx.de> Date: Thu, 12 Jul 2018 18:46:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3b4c5bd8-453b-6e92-88d6-48ea18f5c926@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:o9gPTe/ljPTjxstkBJDo4xK6qbe/m8eYf1iBIyhA2m2jH9x9C1l qc2zXtqSR2aXjhLPJ/+piDDXyvd/Z0Gh63sOyUD+D3OhPV3UKBJQvrpYbi18Ga2xEltbg4n K1BoyoXCWjAuuSC/YeYWV4mvvSgirVVos6vKsjioxoRAWQ4hMtq66KNBZrmfnSW9vWYFpME L+Yj3KPvoEDiYFdE6ZlyA== X-UI-Out-Filterresults: notjunk:1;V01:K0:zJFibQk+k/Q=:3WkhVStScujVh1QSiQ4DnR 514zMoHAbJ9hKaQl1+qf3KuA2yT3Hpk88CajgIf4zV9iW6nUjGe9jWPwUn2CCtnwIbf8hBw2c Q4HmRutAAqG/fucRVkjqQ5QEFdFFeeD+19RSSeN2Jb0lTa8xRwxIHY5OLgzRhciMWYWp27cs3 2koWQixNBFT3e5kgWux6st2sAw+X9Btk5dKM3rCTRje5sEPmVOSCeRrbSNQUNRcB9u/Kr6Uq6 K1a96MlUR+EXnGqu3P2tO5kur9c3/FIjFNg6qeNWT1niey32Dhlqf+7Eo3AgHmC5577eukOzb ly9rhxotMFplA10WgnCtjaH9UWHLe5VJI/2B4X0aC/4N7yZOHIUZLtkY1Ea9bYBu2hgOmFnf+ fn4gUOVEU0SPqk4YqGvFZK281TsqHZeS35ALKaKvrojZTfjSE7tI1LL3BEZOkKDif/pFPCbmD /vPrkcP5Ej0QLJXq5PrjfYlsdPFeSvzJSnEzhch874Q4zY3hPjv++h1TSfG803ypRxTtDc5Eh qN8K/1m191faGq2jiUrKtG5LvTcSCVXwEwDrQnr5lsrtDB/g9lerS72zSbCfxHem132MFTXez gm+f9P0924LJNpLqHXw2BldO/dHcRtaMj243Xaow/CW3QR9FyydSxDrqfANn2XVl0SNXV3feo ZcxBzHjhbjNoP5pDE9I4NNZd0kc6pANIXLvKsyOd+FCjG/jRGLRFBA04MJKBTwUc8l/b48z1X kadnDQojro0AV6ORCd7w6YD4eh8v2i7O3w6+G/8Gf7zydgjCQKwWmV1z3K3VCkyUBZTKk5DRG o50pPl6 Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Fwd: Notes from the format developers and doc authors meeting @ IETF 101 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 16:46:52 -0000 On 2018-04-09 19:29, Heather Flanagan (RFC Series Editor) wrote: > ... > Henrik - one round on preptool is done. Started working on the text > formatter, which informed more work needing to be done on preptool. The > preptool should contain the index if any and the ToC (if any) so the > formatter will work of the same information. Henrik will be generating a > list of all the issues/changes and using a script that creates both an > email and an issue in GitHub. If they need fixing, we expect to see what > the list says, and then Henrik will make a proposal for the change,and > then he and Paul will work on coordinating/accepting the associated PRs. > One PR per issue. For Henrik-generated changes, Paul will handle the PR > review and approval, and for Paul-generated changes, Henrik will handle > the PR review and approval. > > Henrik will be proposing a new tag related to non-ASCII. Any news here? Haven't seen any activity in github... > Paul - will generate a new I-D as soon as the first handful of 7991-bis > issues have been dealt with. Paul will also handle curation of issues > and make sure people take discussions to the list. > Julian - will update his sample draft to include SVG. Most of v3 to HTML > and most of v3 to PDF, v3 to EPUB, v3 to v2, and most of the preptool. > The sample doc includes examples with non-ASCII. Do need an XSLT2 > processor and Java to run Julian’s tools. The v3 to v2 is to downconvert > the files he has so he can have TXT. See -- I have converted one example to conforming SVG. I also added code to to strip non-conforming SVG (even converting @style to conforming attributes), but I have to say that the results aren't really satisfying even for very simple stuff. Played around with various flow chart generators that emit SVG, and the lack of markers for me is a showstopper. (also, correction: the HTML formatter works with any XSLT engine, even in the browser, just open <). > ... Best regards, Julian From nobody Thu Jul 12 15:47:14 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204001311F6 for ; Thu, 12 Jul 2018 15:47:13 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 B9W8WlKlTOit for ; Thu, 12 Jul 2018 15:47: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 6F93D1311E7 for ; Thu, 12 Jul 2018 15:47:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0E9BE300A2A for ; Thu, 12 Jul 2018 18:47: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 KhKIFcVaq-OV for ; Thu, 12 Jul 2018 18:47:08 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 0AD23300288 for ; Thu, 12 Jul 2018 18:47:08 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 12 Jul 2018 18:47:08 -0400 References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> <1648eb26f80.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> To: IETF Tools Development In-Reply-To: <1648eb26f80.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Message-Id: <8028D08B-0465-4429-BCAB-9D4F1378DD9B@vigilsec.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 22:47:13 -0000 Addressing Lou's comments. Russ = = = = = = = = = = Guidance: When to Upgrade Server Software There are many reasons to upgrade the software on the IETF servers, including bug fixes, access to new features, performance improvement. Yet, the software update needs to be done a at time that is going to have minimal impact on the IETF community. The impact might be the result of a service outage while the upgrade take place, or it might be the result of an unexpected problem with the newly installed software. This guidance is intended to avoid outages when the IETF community is depending on the IETF servers the most. Guidelines Do not make updates to any major server software the week before or during the IETF meeting. Do not make updates to the IETF Datatracker on Wednesday or Thursday of the IESG formal telechat. Do not make updates to the IETF Datatracker a few days prior to the I-D cut-off date for an IETF meeting. Do not make updates to the IETF Datatracker a few days prior to the IETF meeting preliminary and final agenda publication dates. Do not make updates to the IETF Datatracker a few days prior to the working group agenda publication deadline for an IETF meeting. Exceptions If something critical is broken, fix it. If a new feature will make things work more smoothly for the IESG or Secretariat, ask. If they deem it sufficiently urgent, give it to them now. Last update: 12 July 2018 From nobody Thu Jul 12 19:50:44 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34DD130DCF for ; Thu, 12 Jul 2018 19:50:42 -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] 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 B8DwOiJGjTGm for ; Thu, 12 Jul 2018 19:50:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98D0127332 for ; Thu, 12 Jul 2018 19:50:40 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:58798 helo=tannat.local) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1fdoAJ-0007ZV-SD; Thu, 12 Jul 2018 19:50:40 -0700 To: Russ Housley , IETF Tools Development References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> <1648eb26f80.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <8028D08B-0465-4429-BCAB-9D4F1378DD9B@vigilsec.com> From: Henrik Levkowetz Message-ID: <9d145c7c-5724-74b6-3164-bc2edef8c0c6@levkowetz.com> Date: Fri, 13 Jul 2018 04:50:32 +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: <8028D08B-0465-4429-BCAB-9D4F1378DD9B@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-development@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-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 02:50:43 -0000 Comments inline: On 2018-07-13 00:47, Russ Housley wrote: > Addressing Lou's comments. > > Russ > > = = = = = = = = = = > > Guidance: When to Upgrade Server Software > > There are many reasons to upgrade the software on the IETF servers, > including bug fixes, access to new features, performance improvement. > Yet, the software update needs to be done a at time that is going to > have minimal impact on the IETF community. The impact might be the > result of a service outage while the upgrade take place, or it might > be the result of an unexpected problem with the newly installed > software. This guidance is intended to avoid outages when the > IETF community is depending on the IETF servers the most. > > Guidelines > > Do not make updates to any major server software the week before > or during the IETF meeting. > > Do not make updates to the IETF Datatracker on Wednesday or > Thursday of the IESG formal telechat. So far this makes some sense to me, but I'd actually limit this to say (in order to provide stability in what the IESG see around a telechat, not because the danger of downtime): > Do not make updates to the IESG-related parts of the IETF > Datatracker on Wednesday or Thursday of the IESG formal telechat. And then follow up with: Do not make any updates to the IETF Datatracker within a few hours of the IESG formal telechat. (as it could coincide with an AD energetically working through some document issue). > Do not make updates to the IETF Datatracker a few days prior to > the I-D cut-off date for an IETF meeting. A few hours would make more sense. It takes one single command to roll back a release, and I think we've only had to roll back twice over the 12 years we've made releases. The downtime when making a release are a matter of seconds. > Do not make updates to the IETF Datatracker a few days prior to > the IETF meeting preliminary and final agenda publication dates. I don't understand this at all. We've routinely done this during the last 20 meetings. This feels like a completely gratuitous limitation. > Do not make updates to the IETF Datatracker a few days prior to > the working group agenda publication deadline for an IETF meeting. I have a hard time understanding this, too. What incident (that hasn't happened, ever) are we trying to prevent with this? Henrik > Exceptions > > If something critical is broken, fix it. > > If a new feature will make things work more smoothly for the IESG or > Secretariat, ask. If they deem it sufficiently urgent, give it to > them now. > > > Last update: 12 July 2018 > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > From nobody Fri Jul 13 12:52:31 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C508130F43 for ; Fri, 13 Jul 2018 12:52:30 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 FoUQYs5q9yGh for ; Fri, 13 Jul 2018 12:52:28 -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 D82DB130F40 for ; Fri, 13 Jul 2018 12:52:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A5C133005DF for ; Fri, 13 Jul 2018 15:52:25 -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 vp8mYpdRiupa for ; Fri, 13 Jul 2018 15:52:24 -0400 (EDT) Received: from [5.5.33.141] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 452473005C9; Fri, 13 Jul 2018 15:52:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Russ Housley In-Reply-To: <9d145c7c-5724-74b6-3164-bc2edef8c0c6@levkowetz.com> Date: Fri, 13 Jul 2018 15:52:23 -0400 Cc: IETF Tools Development Content-Transfer-Encoding: quoted-printable Message-Id: References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> <1648eb26f80.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <8028D08B-0465-4429-BCAB-9D4F1378DD9B@vigilsec.com> <9d145c7c-5724-74b6-3164-bc2edef8c0c6@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 19:52:30 -0000 See below ... [snip] >>=20 >> Guidelines >>=20 >> Do not make updates to any major server software the week before >> or during the IETF meeting. >>=20 >> Do not make updates to the IETF Datatracker on Wednesday or >> Thursday of the IESG formal telechat. >=20 > So far this makes some sense to me, but I'd actually limit this to > say (in order to provide stability in what the IESG see around a > telechat, not because the danger of downtime): >=20 >> Do not make updates to the IESG-related parts of the IETF >> Datatracker on Wednesday or Thursday of the IESG formal telechat. >=20 > And then follow up with: >=20 > Do not make any updates to the IETF Datatracker within a few > hours of the IESG formal telechat. >=20 > (as it could coincide with an AD energetically working through some > document issue). Yes, stability is the concern. I know that many ADs put their ballots = into the datatracker one the day before the telechat or the morning = before the telechat depending on their time zone. As a result the ADs = are using the datatracker heavily on these days. I guess we should change the wording to accommodate a telechat that = takes place on a day other than Thursday. >=20 >> Do not make updates to the IETF Datatracker a few days prior to >> the I-D cut-off date for an IETF meeting. >=20 > A few hours would make more sense. It takes one single command to > roll back a release, and I think we've only had to roll back twice = over > the 12 years we've made releases. The downtime when making a release > are a matter of seconds. I realize the downtime to make a release is not the issue, but the time = to realize that things are not working as expected and then rollback is = the problem. Again, the point is stability during a known period of = heavy use. >=20 >> Do not make updates to the IETF Datatracker a few days prior to >> the IETF meeting preliminary and final agenda publication dates. >=20 > I don't understand this at all. We've routinely done this during the > last 20 meetings. This feels like a completely gratuitous limitation. Again, the point is stability during a known period of heavy use. We = know the Secretariat is tinkering with the agenda to get it published. >=20 >> Do not make updates to the IETF Datatracker a few days prior to >> the working group agenda publication deadline for an IETF meeting. >=20 > I have a hard time understanding this, too. What incident (that = hasn't > happened, ever) are we trying to prevent with this? Again, the point is stability during a known period of heavy use. Russ From nobody Fri Jul 13 15:42:41 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390AF1292AD for ; Fri, 13 Jul 2018 15:42:40 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 RLWeMt1RzyZN for ; Fri, 13 Jul 2018 15:42:37 -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 99EB9130DEF for ; Fri, 13 Jul 2018 15:42:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6806B300A44 for ; Fri, 13 Jul 2018 18:42:35 -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 00bhdUIRI4jH for ; Fri, 13 Jul 2018 18:42:34 -0400 (EDT) Received: from [172.20.7.12] (unknown [207.96.246.27]) by mail.smeinc.net (Postfix) with ESMTPSA id 1DBAD300546; Fri, 13 Jul 2018 18:42:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Russ Housley In-Reply-To: Date: Fri, 13 Jul 2018 18:42:34 -0400 Cc: IETF Tools Development Content-Transfer-Encoding: quoted-printable Message-Id: References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> <1648eb26f80.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <8028D08B-0465-4429-BCAB-9D4F1378DD9B@vigilsec.com> <9d145c7c-5724-74b6-3164-bc2edef8c0c6@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 22:42:40 -0000 I have been thinking about this some more. I think we need to balance = the desire for continuous incremental improvement and the recognition = that the datatracker is now vital to so many aspects of IETF life. = Where is that balance point? Russ > On Jul 13, 2018, at 3:52 PM, Russ Housley = wrote: >=20 > See below ... >=20 >=20 > [snip] >=20 >>>=20 >>> Guidelines >>>=20 >>> Do not make updates to any major server software the week before >>> or during the IETF meeting. >>>=20 >>> Do not make updates to the IETF Datatracker on Wednesday or >>> Thursday of the IESG formal telechat. >>=20 >> So far this makes some sense to me, but I'd actually limit this to >> say (in order to provide stability in what the IESG see around a >> telechat, not because the danger of downtime): >>=20 >>> Do not make updates to the IESG-related parts of the IETF >>> Datatracker on Wednesday or Thursday of the IESG formal telechat. >>=20 >> And then follow up with: >>=20 >> Do not make any updates to the IETF Datatracker within a few >> hours of the IESG formal telechat. >>=20 >> (as it could coincide with an AD energetically working through some >> document issue). >=20 > Yes, stability is the concern. I know that many ADs put their ballots = into the datatracker one the day before the telechat or the morning = before the telechat depending on their time zone. As a result the ADs = are using the datatracker heavily on these days. >=20 > I guess we should change the wording to accommodate a telechat that = takes place on a day other than Thursday. >=20 >>=20 >>> Do not make updates to the IETF Datatracker a few days prior to >>> the I-D cut-off date for an IETF meeting. >>=20 >> A few hours would make more sense. It takes one single command to >> roll back a release, and I think we've only had to roll back twice = over >> the 12 years we've made releases. The downtime when making a release >> are a matter of seconds. >=20 > I realize the downtime to make a release is not the issue, but the = time to realize that things are not working as expected and then = rollback is the problem. Again, the point is stability during a known = period of heavy use. >=20 >>=20 >>> Do not make updates to the IETF Datatracker a few days prior to >>> the IETF meeting preliminary and final agenda publication dates. >>=20 >> I don't understand this at all. We've routinely done this during the >> last 20 meetings. This feels like a completely gratuitous = limitation. >=20 > Again, the point is stability during a known period of heavy use. We = know the Secretariat is tinkering with the agenda to get it published. >=20 >>=20 >>> Do not make updates to the IETF Datatracker a few days prior to >>> the working group agenda publication deadline for an IETF meeting. >>=20 >> I have a hard time understanding this, too. What incident (that = hasn't >> happened, ever) are we trying to prevent with this? >=20 > Again, the point is stability during a known period of heavy use. >=20 > Russ >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Fri Jul 13 20:29:51 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791D2130DC8 for ; Fri, 13 Jul 2018 20:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 vpHDxTIP_w-c for ; Fri, 13 Jul 2018 20:29: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 E957A130DCF for ; Fri, 13 Jul 2018 20:29:45 -0700 (PDT) Received: from [10.204.64.160] (mobile-166-170-59-199.mycingular.net [166.170.59.199]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6E3TeQw027179 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 13 Jul 2018 22:29:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-170-59-199.mycingular.net [166.170.59.199] claimed to be [10.204.64.160] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Robert Sparks Mime-Version: 1.0 (1.0) Date: Fri, 13 Jul 2018 20:49:51 -0500 Message-Id: References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> <1648eb26f80.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <8028D08B-0465-4429-BCAB-9D4F1378DD9B@vigilsec.com> <9d145c7c-5724-74b6-3164-bc2edef8c0c6@levkowetz.com> Cc: Henrik Levkowetz , IETF Tools Development In-Reply-To: To: Russ Housley X-Mailer: iPhone Mail (15F79) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 03:29:49 -0000 I think we need to recognize that our test suite is relatively strong and ou= r experience with the tracker to date gives us a good feel for what would be= a low risk vs medium risk release. ( i posit that the days of a high risk r= elease are _mostly_ behind us modulo big infrastructure or model changes). [= *] I was comfortable with the original draft, but if we want to share our think= ing more (that us what this exercise primarily is about, I hope) we can writ= e in more about using good judgement and being aware of time sensitive activ= ities. Hard rules wont match reality (or may actually impede the greater goo= d for the community).=20 Perhaps a recasting that is more advisory vs prescriptive would serve future= folks better? Again, I=E2=80=99m not uncomfortable with the original formulation as I expe= ct =E2=80=98doing the right thing=E2=80=99 to win out at any given point in t= ime.=20 RjS [*] I think the mail infrastructure changes we ate going through and plannin= g to go through are much more risky than any current datatracker improvement= s (consider mail disruption on a telechat morning) and we seem to be getting= unleashing those reasonably right.=20 RjS Composed on my iPhone while on a tiny bouncy plane.=20 > On Jul 13, 2018, at 5:42 PM, Russ Housley wrote: >=20 > I have been thinking about this some more. I think we need to balance the= desire for continuous incremental improvement and the recognition that the d= atatracker is now vital to so many aspects of IETF life. Where is that bala= nce point? >=20 > Russ >=20 >=20 >> On Jul 13, 2018, at 3:52 PM, Russ Housley wrote: >>=20 >> See below ... >>=20 >>=20 >> [snip] >>=20 >>>>=20 >>>> Guidelines >>>>=20 >>>> Do not make updates to any major server software the week before >>>> or during the IETF meeting. >>>>=20 >>>> Do not make updates to the IETF Datatracker on Wednesday or >>>> Thursday of the IESG formal telechat. >>>=20 >>> So far this makes some sense to me, but I'd actually limit this to >>> say (in order to provide stability in what the IESG see around a >>> telechat, not because the danger of downtime): >>>=20 >>>> Do not make updates to the IESG-related parts of the IETF >>>> Datatracker on Wednesday or Thursday of the IESG formal telechat. >>>=20 >>> And then follow up with: >>>=20 >>> Do not make any updates to the IETF Datatracker within a few >>> hours of the IESG formal telechat. >>>=20 >>> (as it could coincide with an AD energetically working through some >>> document issue). >>=20 >> Yes, stability is the concern. I know that many ADs put their ballots in= to the datatracker one the day before the telechat or the morning before the= telechat depending on their time zone. As a result the ADs are using the d= atatracker heavily on these days. >>=20 >> I guess we should change the wording to accommodate a telechat that takes= place on a day other than Thursday. >>=20 >>>=20 >>>> Do not make updates to the IETF Datatracker a few days prior to >>>> the I-D cut-off date for an IETF meeting. >>>=20 >>> A few hours would make more sense. It takes one single command to >>> roll back a release, and I think we've only had to roll back twice over >>> the 12 years we've made releases. The downtime when making a release >>> are a matter of seconds. >>=20 >> I realize the downtime to make a release is not the issue, but the time t= o realize that things are not working as expected and then rollback is the p= roblem. Again, the point is stability during a known period of heavy use. >>=20 >>>=20 >>>> Do not make updates to the IETF Datatracker a few days prior to >>>> the IETF meeting preliminary and final agenda publication dates. >>>=20 >>> I don't understand this at all. We've routinely done this during the >>> last 20 meetings. This feels like a completely gratuitous limitation. >>=20 >> Again, the point is stability during a known period of heavy use. We kno= w the Secretariat is tinkering with the agenda to get it published. >>=20 >>>=20 >>>> Do not make updates to the IETF Datatracker a few days prior to >>>> the working group agenda publication deadline for an IETF meeting. >>>=20 >>> I have a hard time understanding this, too. What incident (that hasn't >>> happened, ever) are we trying to prevent with this? >>=20 >> Again, the point is stability during a known period of heavy use. >>=20 >> Russ >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Sat Jul 14 06:57:57 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7B6131091 for ; Sat, 14 Jul 2018 06:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 pkEIeASnLF_7 for ; Sat, 14 Jul 2018 06:57:41 -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 15DAE131016 for ; Sat, 14 Jul 2018 06:57:41 -0700 (PDT) Received: from dhcp-9a25.meeting.ietf.org (dhcp-9a25.meeting.ietf.org [31.133.154.37]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6EDvNBT036613 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 14 Jul 2018 08:57:24 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_60E43BDE-2123-4E4D-B104-B92450C5E32F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 14 Jul 2018 09:57:21 -0400 In-Reply-To: Cc: Russ Housley , Henrik Levkowetz , IETF Tools Development To: Robert Sparks References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> <1648eb26f80.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <8028D08B-0465-4429-BCAB-9D4F1378DD9B@vigilsec.com> <9d145c7c-5724-74b6-3164-bc2edef8c0c6@levkowetz.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 13:57:55 -0000 --Apple-Mail=_60E43BDE-2123-4E4D-B104-B92450C5E32F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am also okay with the original draft. I think I=E2=80=99m agreeing with Robert, but I encourage people to = avoid overthinking this. It doesn=E2=80=99t need to be perfect or even = all that precise. It=E2=80=99s really a principle-of-least-surprise matter. I think it=E2=80= =99s good enough to point out the sort of events that we want to avoid = disruption for, try not to disrupt them unless there is a really good = reason, and otherwise offer a fair amount of discretion. Ben. > On Jul 13, 2018, at 9:49 PM, Robert Sparks = wrote: >=20 > I think we need to recognize that our test suite is relatively strong = and our experience with the tracker to date gives us a good feel for = what would be a low risk vs medium risk release. ( i posit that the days = of a high risk release are _mostly_ behind us modulo big infrastructure = or model changes). [*] >=20 > I was comfortable with the original draft, but if we want to share our = thinking more (that us what this exercise primarily is about, I hope) we = can write in more about using good judgement and being aware of time = sensitive activities. Hard rules wont match reality (or may actually = impede the greater good for the community). >=20 > Perhaps a recasting that is more advisory vs prescriptive would serve = future folks better? >=20 > Again, I=E2=80=99m not uncomfortable with the original formulation as = I expect =E2=80=98doing the right thing=E2=80=99 to win out at any given = point in time. >=20 > RjS >=20 > [*] I think the mail infrastructure changes we ate going through and = planning to go through are much more risky than any current datatracker = improvements (consider mail disruption on a telechat morning) and we = seem to be getting unleashing those reasonably right. >=20 > RjS >=20 > Composed on my iPhone while on a tiny bouncy plane. >=20 >> On Jul 13, 2018, at 5:42 PM, Russ Housley = wrote: >>=20 >> I have been thinking about this some more. I think we need to = balance the desire for continuous incremental improvement and the = recognition that the datatracker is now vital to so many aspects of IETF = life. Where is that balance point? >>=20 >> Russ >>=20 >>=20 >>> On Jul 13, 2018, at 3:52 PM, Russ Housley = wrote: >>>=20 >>> See below ... >>>=20 >>>=20 >>> [snip] >>>=20 >>>>>=20 >>>>> Guidelines >>>>>=20 >>>>> Do not make updates to any major server software the week before >>>>> or during the IETF meeting. >>>>>=20 >>>>> Do not make updates to the IETF Datatracker on Wednesday or >>>>> Thursday of the IESG formal telechat. >>>>=20 >>>> So far this makes some sense to me, but I'd actually limit this to >>>> say (in order to provide stability in what the IESG see around a >>>> telechat, not because the danger of downtime): >>>>=20 >>>>> Do not make updates to the IESG-related parts of the IETF >>>>> Datatracker on Wednesday or Thursday of the IESG formal telechat. >>>>=20 >>>> And then follow up with: >>>>=20 >>>> Do not make any updates to the IETF Datatracker within a few >>>> hours of the IESG formal telechat. >>>>=20 >>>> (as it could coincide with an AD energetically working through some >>>> document issue). >>>=20 >>> Yes, stability is the concern. I know that many ADs put their = ballots into the datatracker one the day before the telechat or the = morning before the telechat depending on their time zone. As a result = the ADs are using the datatracker heavily on these days. >>>=20 >>> I guess we should change the wording to accommodate a telechat that = takes place on a day other than Thursday. >>>=20 >>>>=20 >>>>> Do not make updates to the IETF Datatracker a few days prior to >>>>> the I-D cut-off date for an IETF meeting. >>>>=20 >>>> A few hours would make more sense. It takes one single command to >>>> roll back a release, and I think we've only had to roll back twice = over >>>> the 12 years we've made releases. The downtime when making a = release >>>> are a matter of seconds. >>>=20 >>> I realize the downtime to make a release is not the issue, but the = time to realize that things are not working as expected and then = rollback is the problem. Again, the point is stability during a known = period of heavy use. >>>=20 >>>>=20 >>>>> Do not make updates to the IETF Datatracker a few days prior to >>>>> the IETF meeting preliminary and final agenda publication dates. >>>>=20 >>>> I don't understand this at all. We've routinely done this during = the >>>> last 20 meetings. This feels like a completely gratuitous = limitation. >>>=20 >>> Again, the point is stability during a known period of heavy use. = We know the Secretariat is tinkering with the agenda to get it = published. >>>=20 >>>>=20 >>>>> Do not make updates to the IETF Datatracker a few days prior to >>>>> the working group agenda publication deadline for an IETF meeting. >>>>=20 >>>> I have a hard time understanding this, too. What incident (that = hasn't >>>> happened, ever) are we trying to prevent with this? >>>=20 >>> Again, the point is stability during a known period of heavy use. >>>=20 >>> Russ >>>=20 >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --Apple-Mail=_60E43BDE-2123-4E4D-B104-B92450C5E32F 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 - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAltKAUEACgkQgFZKbJXz 1A2Y+xAAwNdG9BcRjibdPAbfMT/eXfSixavh0GDjgQ+5gqLs4g2WdsTNZ2zSerCF w2QQyYIhS+hRb9zHGU+REPgOTWx531OVtvz+qzVuVTk7Hyg1zgFSnTPWtPq+UL0n 1jnqgjW4Ttvik6S3wrBErhqxEF5guOGxwP3qVPQAoNJ6jAJaUSRrM+F3Yepxlk0o ASqe3mtRPt6A6Mk6io/jreNk3bBEiT21pAz8oHlY0QdOnlZJ74Qw49V217yf04bJ /H3dnTYbBPxAOqKcInS5KxV0UOithnokTSzpa2hMJNv0U6JUK/tnRtDHDNNfaPoA 1Dq2AjBx8Ybwt7PV8XKcFJoAsex1OcVUFlDzVbpH7zagGHYhfHR/DYa3rwvS85EW vrLT0Df9mQEqGK5NIl1kVeRun51Z6PlgVDbsJYxlQym4gbA11TSb40SV4d8jZmq7 OeJStSJoESv93ZNo66yrTiqvdB9LnFrXvgTUuS8pLquDPgzQhwRe8ow7K6a5xNhE 9VHWFG/CZWBs/teG5oHtk9+BVBUNWdaJgtWKktmw3/EUfHIaBZLlHGYH1Cmstity UTev7t+yk2ZR76W4DNDz+fFHOZe/8m9DkyDmTF8tkWJPTyimh68gIyKBexEMFGqI OWaKghxpxqoVg/r6p1AdW0ggKI372ijDgVUBHKSa6TbQwdOI9jE= =Er8q -----END PGP SIGNATURE----- --Apple-Mail=_60E43BDE-2123-4E4D-B104-B92450C5E32F-- From nobody Sun Jul 15 05:40:28 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB3B130E33 for ; Sun, 15 Jul 2018 05:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=fAwmF0vw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Tf8MN9jV 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 bmKJtQ-c6GwC for ; Sun, 15 Jul 2018 05:40:25 -0700 (PDT) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F50130E1B for ; Sun, 15 Jul 2018 05:40:25 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 96495B55; Sun, 15 Jul 2018 08:40:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 15 Jul 2018 08:40:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=7gK3xVvbB1p+NC+HdvUiGt4WFaXch ystJKKlu53+49g=; b=fAwmF0vwqOKgrLwJ+4hFj4Y6J5kO2wjpclZDkF3PLusgh TfnovvfLLhP36uFok/02t1IjpKrwhMO426ZU7Eze3aS9mCdaN00IkAZmu/vNDXTO Tlq37fZXo/+g6Nq6uuZ4krGp70pqzkeTKSAmzJbZR6QDzB6zBFSm3TO/9Qworqv7 Mon80N4IH+Bwr8D0dsGLWcGrnpKjcJvR01acnyS+TAzQANzIWcqKhoDypbpEi9Fs WI+ncktoUvGPi7RnJ6ihNmZ5wZXuXDehqSmuvZjMnvTM5eVPljsnJ3R3OQNYXDNj lGV6mFeecElEm/fuU0UNSNy1KA159PPqR5xAp8wlA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=7gK3xV vbB1p+NC+HdvUiGt4WFaXchystJKKlu53+49g=; b=Tf8MN9jVCeJV+U6gqpjKar aX1Xldtl4KcC7ApNzNrk8zbSGURn+ziRek6mSjfYgnzeFEMMVskDyuNxKjsagxi8 s6/rwLCKxodxTzUsOKXOHBYwfU9s5njolPn1VWwXfPAkO8Qnw9ncbHWvs+Vvr/L7 jMwEPe/ScB15rxujqGUtCZJAVUi9ai0751aOv5f2LoGsjTllNdAeV96Ca45jQH3K 0aBx70mvob3t2O4T9RS6EQ38ZlPPWSOxN9MtTZVgtmpFUHDMMRGwEH/vk3Ek78zE uPCTem1F3ydH6NVrUX7oWxqf9R4KnN+IuNgQrlPgs7wJca39tYrrrjd4mwumvUlg == X-ME-Proxy: X-ME-Sender: Received: from [172.16.15.82] (unknown [66.171.165.154]) by mail.messagingengine.com (Postfix) with ESMTPA id 0300810255; Sun, 15 Jul 2018 08:40:24 -0400 (EDT) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: Date: Sun, 15 Jul 2018 08:54:50 -0400 Cc: IETF Tools Development Content-Transfer-Encoding: quoted-printable Message-Id: References: <65A307F9-5D7B-4E9B-A313-48C9987DAC7C@vigilsec.com> To: Russ Housley , Bob Hinden Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Guidance on When to Upgrade Server Software X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 12:40:27 -0000 > On 11 Jul 2018, at 11:14, Bob Hinden wrote: >=20 > Sorry for missing yesterday=92s call. Me too.