From nobody Tue Sep 4 14:02:46 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 D7140130F0D for ; Tue, 4 Sep 2018 14:02:45 -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 vQVCU7iIlldL for ; Tue, 4 Sep 2018 14:02: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 65B43128BAC for ; Tue, 4 Sep 2018 14:02:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4EC9E300A54 for ; Tue, 4 Sep 2018 17:02: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 16h0pmI0ObBN for ; Tue, 4 Sep 2018 17:02: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 6C1AE300435 for ; Tue, 4 Sep 2018 17:02:41 -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.5 \(3445.9.1\)) Message-Id: <45BEDACD-A2B5-43BE-861E-EF51891742A2@vigilsec.com> Date: Tue, 4 Sep 2018 17:02:42 -0400 To: IETF Tools Development X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 11 September 2018 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 21:02:46 -0000 Tools Call Agenda -- 11 September 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 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 -- Is there any status on ARC? 5. Parking Lot - Prepare the RFC Production Center code for publication 6. AOB From nobody Thu Sep 6 11:58:38 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 C653512F18C for ; Thu, 6 Sep 2018 11:58:36 -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 ECFhR7XEbjir for ; Thu, 6 Sep 2018 11:58:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF91130EFB for ; Thu, 6 Sep 2018 11:58:34 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w86IwXkT080683 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 6 Sep 2018 13:58:34 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: tools-development@ietf.org References: <45BEDACD-A2B5-43BE-861E-EF51891742A2@vigilsec.com> From: Robert Sparks Message-ID: Date: Thu, 6 Sep 2018 13:58:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <45BEDACD-A2B5-43BE-861E-EF51891742A2@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 11 September 2018 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 18:58:37 -0000 Notes for next week's call On 9/4/18 4:02 PM, Russ Housley wrote: > Tools Call Agenda -- 11 September 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 This, and the PLAN page it links to have been updated. > - GDPR Compliance -- Robert and Henrik Coding should be complete in the next few days. There is an operational step that follows that we should discuss briefly on the call. > - Management of "extra" IETF meeting sessions -- Robert We are planning a project to improve the meeting scheduling application overall - this will be one item in that project. > > 2. Community & Other Projects > - Discontinue MonArch email archives -- Robert and Ryan We are getting more community awareness of the static pages, leading to more community testing and a few bug reports. I think the next step is to get some more folks to look and comment. Once we have a period where there are no major functional bugs outstanding, we should propose a date to the community for discontinuing Mhonarch. As a thumbnail proposal, I suggest that date be a couple of weeks after the Bangkok IETF. > > 3. RFC Services Projects > - RFC Format Contracts -- Heather and Robert > -- IDnits > -- Publication Formatter > -- Text Submission > -- RFClint > -- SVGcheck > -- XMLdiff See . > > 4. Server Infrastructure > - IESG discussions of DMARC -- Henrik and Alexey > -- Deployed for all mail lists > -- Is there any status on ARC? > > 5. Parking Lot > - Prepare the RFC Production Center code for publication > > 6. AOB > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Mon Sep 10 09:04:00 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 2EE99130E6F for ; Mon, 10 Sep 2018 09:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 5HWs4bpGbBT5 for ; Mon, 10 Sep 2018 09:03:56 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0079.outbound.protection.outlook.com [104.47.33.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF83124BE5 for ; Mon, 10 Sep 2018 09:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bKQvoiolMGJXPqQ8Cxewy5HvH9GeGcJ0DbvsykmC7dk=; b=QElGT4KKkdpFcKP6mDgi+dEf2aGdVZ9rPZHm2fGqRRwqfelebtj4++gIzEEcDQ6NKdFkI8RVBYGzKsQbLNruG8sVl1fyze2NLKXupVLyoOdbU/jZlJDFykANr/TJ4DSVbi4v2htEsWYYTnFC+zVaA4C+0/x6KZHldnunnWi6lYA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=wood@isoc.org; Received: from [192.168.1.196] (71.178.204.147) by BL0PR06MB4626.namprd06.prod.outlook.com (2603:10b6:208:57::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.19; Mon, 10 Sep 2018 16:03:53 +0000 From: Greg Wood Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <9932204C-057C-4EB6-AF3B-AF0CC65DBF8C@isoc.org> Date: Mon, 10 Sep 2018 12:03:50 -0400 To: IETF Tools Development X-Mailer: Apple Mail (2.3445.9.1) X-Originating-IP: [71.178.204.147] X-ClientProxiedBy: BN6PR03CA0081.namprd03.prod.outlook.com (2603:10b6:405:6f::19) To BL0PR06MB4626.namprd06.prod.outlook.com (2603:10b6:208:57::32) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fa3dd245-77dc-4b1d-4245-08d6173701b4 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4626; X-Microsoft-Exchange-Diagnostics: 1; BL0PR06MB4626; 3:z/v9h2Ssv88Bn+hydKDI77qbt9WlmhdDpU7eDD1J8+Kvd4ApMXTrq0LGCOYwF653Ae5b8X022/4rAOvFLR2srG14dNBkEucjnERX3h+dPoVzHQ0GwXa9xX3MpTg+rjgr5YD4nFFXVJWmh+vepafm44NnPweK6NpbpWm8WZt7s4n7ceNLLWI0psDLUVPVxfpx/ITCsrxwh0Ryx5ri1pPD0bk4BTQR5mktXi+MwoTVQKa9P1yhLbFoWBl1f26sButR; 25:EtisJQOagG9Ul7xOQ72ml9sbqiQdXeAbfrHeF34UNk2GyG0IB8hgI8g6RdHxy3FK6sFydDAQFF1iQlpe2lsd43Difyy+SV2L/DI2cMTFNjSDuBjZPTLGYlnrhVvHsJPLhfd53K11bnNnc70fYnkGHDJ2bIygQ+s96YH1VhmNjOFxlhtfWTZqbbaECoOdWRglvarTFkoneoA7T2LvhmCPBuI1Q9V05fPy65liKyXLHRYAYngicd6B9BQCFXdgbfg+yYHifnhSHqFCooXYa1SC/Dr4V4GvgjSmrp6zaZoeqeb54QTDyKfhSvoSUvtlZXPPhCLyRRo1Jj2ju191rSiyfw==; 31:TLtS9GqbWs/qUDpjh+v5VhueOXHxOD/EozYHpXg4IverQE9rI1CXhPkS8EKKx92ksLO9Gl4N+zgVw8ocyE5sw30kgiyWUI8P7ZkRG9DPWdgp1gf729NaDhQ8o2Z0arDWjXtLYWxdTukph7/Z4XoyLyyNNsYOMlyiZBBKOlV6WV6HNQG+QHNEok4Z3awOxFdXIEomrqJBLQZKKlfMU+oFkuxEVA7XejGSNLRt7Nn+UCE= X-MS-TrafficTypeDiagnostic: BL0PR06MB4626: X-Microsoft-Exchange-Diagnostics: 1; BL0PR06MB4626; 20:kCANOiv9p7kV74bCxTtgeLkjVlVI879zGaEvvRGjEPEODoSz4KMa0Lh+O17uNvnND56z4ss9pzCHdG0Y+6X7utd0MIvV3cmzyex4JQv2rW7l0BKByN26jzZ2GIZiz1kjj5pxECodmm4GhJa6DMf+n9nckT8snYcWh2yufS9AbuUN4uaBTVu7zJjj81b/U5/Wnfw5NQdRB99qKmusNi6Fso9m43k/o9rqz+LLKu6stpsvx1Yx/ASiZD6lXMkxfhzpERZ7Q8khesfzuc+Ya/WNQy+40yc3nn7lq4Z9AV57AXaViezxCO/imisg5MXDeUuGnB9TB479p65+j1woW613+FAM8tkEUJdIQS8v0jqfFW/x4H/iIHFT8dRA9wTbabZZKZLBYfan+KLbn+PwLFjQIQ3MsYQvuOesJFmyXTRhwWervkMHE2V1K8paM2BHBA+U7q3gcjLPA3SGPgFbM9tPug/weibP+4EOwKQl8SlE9WsynGC6zvgm1NTpd9WmEWg4; 4:k5ZXytRDv1MJjoP0rS5HiHuFbU4+DU0i+1s9ZYStO+zn3ycOeyIYU/aaMkxMQxdML+WQW0PVZ5hQ2D1yDwRr5TET+az209TAqybBoYnNnEzk1SeKTB0e0xh3Gad/0YwvJmLrXBXapjdSock23+GNGKKgXhfbpXfsQiqyjHbXR0lYna/tflrCEyjtcbVMnX4zJNI+j6KuiK+6VLKDdmTl+9SxGKuvbJDHEIfiKHTvie0t8T2BJ7cDZueOwjQo5BtWxHLWH9zSloI04Qvx8/vGHQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699050); SRVR:BL0PR06MB4626; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4626; X-Forefront-PRVS: 07915F544A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(396003)(136003)(346002)(39850400004)(376002)(366004)(199004)(189003)(25786009)(52116002)(316002)(117156002)(82746002)(15650500001)(14444005)(16526019)(105586002)(16576012)(186003)(305945005)(50466002)(106356001)(77096007)(83716003)(86362001)(7736002)(26005)(386003)(476003)(2616005)(486006)(956004)(2906002)(50226002)(15974865002)(5660300001)(6486002)(6916009)(68736007)(66066001)(8936002)(23726003)(6116002)(3846002)(8676002)(81156014)(8746002)(81166006)(36756003)(33656002)(478600001)(57306001)(53936002)(97736004)(47776003)(163123001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR06MB4626; H:[192.168.1.196]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:3; MX:3; Received-SPF: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL0PR06MB4626; 23:+iMwHexSGBONXrHojt7zCuMv7xV7u9oW7aBh5g6f3?= =?us-ascii?Q?UmDTtRRdtDXHcIaUctjKt2B7A7JXjW9IseWoD2AqAzWjIvHXC5ZNFAwLx0mX?= =?us-ascii?Q?jdpf181LDRQ8BcT7XOYHGJrSSm73KuoRLB14TEFi255sv2JR+VJs2N9NoyG0?= =?us-ascii?Q?PeNZSxVq57dsQDHnzf/6Q07GewrlFyUvC+9l46bFShM78rOim4WTqfZjllLq?= =?us-ascii?Q?b8guivpfN47rxgNZlFdOrjDbgMeNXuATDCG8HBfmE5TWwJkidScS15XxErAD?= =?us-ascii?Q?RAxVP2zzW556tqHbAEenl/6yY8KUo/3qjngXPoQDt+Gwdt5WKaYPMKHOEnUl?= =?us-ascii?Q?9JQjnzjhnBDFLt8gGWQf68vBuSSokIYL2y8yOb8a1eUVlwDDol5OzWjb0W9N?= =?us-ascii?Q?4efQMT+no+YmeGD7G/LQ4Rn8C+KdhTnuzsBvDbHHFL7ywcIZZK6TB7MKn2EB?= =?us-ascii?Q?K+p2bmFuX6juIC6fbzTA9QayQTr7UTYGizbgCAYZmM712FC7k2jmrFn7eeMH?= =?us-ascii?Q?IRmTmSJa/P9JP4FC7JEABQrzLuYXCPG1yAcknszPYGpM4EkU9LQaPufGAxu+?= =?us-ascii?Q?znNbWhmPIjgXkF1u6gqurFTofrAlT+c9tlSTPS0r4hbZYHa7aCZgl5r2blIa?= =?us-ascii?Q?7ixA9WoaCmzJuoY3jfAwlWb2aZWCh2oyPVXEocH2UdXgVQi2dXiIM5T09htS?= =?us-ascii?Q?GmcOOpJGhsqEuN3W3sEegTIlW4cUi/FrU7UakhptCKdI2TlSWyXyyitukyRH?= =?us-ascii?Q?VuYcUOqsG/3QAFZawaUrglMSHFyCrriJxmxapmDkn8cpMTsoxpE156c5HjN+?= =?us-ascii?Q?uuyavzbtyWD73yu3OCKNTKX7tWTrpA41n6In/draPFxyC+r/KzlKy0Yzat8B?= =?us-ascii?Q?6yjJuxN/e1r5H44N5C/4UaYaltAD+H3AGQZMkepk3NQbyvLSzy/6qhSbEYnZ?= =?us-ascii?Q?QR/HCRZ82/rb05Ldn9RlIqoUmPWh7PH1xLINy14oiIF2fZ6aPooRHHfh6G3t?= =?us-ascii?Q?ziUDE6kFeT2OWOkfdrJkEIbngJwFgUABQCgV5OFCoAvbDCedhxMdfifpHmmi?= =?us-ascii?Q?ccg7yQv3V21dEcvT6XldT52B1NuYZpqUSsXg/0hqG3yb06NCC/xB7KqZl019?= =?us-ascii?Q?4PgY/LD/iLVFkjWRg/7ecZEb5BPfxd4gOP9+s9c/Hjp3qaq8UnXpinYdYZxK?= =?us-ascii?Q?drlqRRTZXwL1rZeqdCDhlcLUgTNnwCGTz6DWNnrReglbcb83T13286E1jBvE?= =?us-ascii?Q?v/dpFmBGXg6yFz1jFM1+p3M8LwQpcRQUFKvcmTL?= X-Microsoft-Antispam-Message-Info: 2LduXrDWdahwmiCnUMUkficghZc7OgvZ7mn8O0TAom1Wa8o4SJj4knN0sE81jJ20cmzIb9buFuQsyaxQUzpM7h79pWtrRB4ahrv8P4wOsQy0Yjai/evIwlNiDePXNqypr2Z2zrS3wHYLSZFzYoW7lVVjXPBKudggIYOMKw2BkYRYsq4Gci6e7MSyJTd6F2B0eItm9Ud7Y0npeCgcXhGVTekHnlqcUKsXDHR7QKkBoe4h+lxswlzbRbJF4crCYwTuu4PTKzgX4i7Tx1zJYyalOwywElmm8nvfXAlTHOD4e29Pfa/hloH5c5ylmVFbqGLKz9S8z9UPsG1A9exjjvRzfAxtUWf7D3tV+39YAA8m/lU= X-Microsoft-Exchange-Diagnostics: 1; BL0PR06MB4626; 6:459+JS0F+SeMcXmpM7/fO/+WLvTWdUHPImXsHOh5AQB4TaRaFVpyWZHO+Ot/iW/8sjHIg7Ty4UuZowWv0qSeA+j77HdV//WpTBIp5PUNpCXvas0rGzU9sNu2KvXfV3jAixhGx+fraQFsiA5LwATHDlzX2EFb91ojUd0xyeWyJsXEY+AcNJtCNcu10o4ncq7aVl9qX4LtOygUCgNZ2n4s9LSBCJhz/jMCcWBEYjAriIjO0i3/HRAOtGUUsxXWSgNa88RLWbLDBWYpwzcvSDhojbTS/s2IQtkr03BYVO9EG+f3NhSzyziur9fh9VOMquUe/Z4i26tLwpz2aSY4DXC7HLbQ3/mZYG2/h6uyHNSby4EhWdGvx8FUvMtCnlh2ydYspNka1DYHrlmZzWIIv7K0+qS22/34rZWgsh3CiicRuOKjYXKzeeyC+kAu8ZezbGpyNikdPiieCRpVzx+WW79AyA==; 5:qTlQpcCH2/Qp3hFtIxHCnSgq/g/6d1uatCLI/V3XXKLGya9z+AJkIpXWlb5svx4TD4bcfSNNfooUGtJL0+2h0FtxJ5OcNr/fAZmdLO5QonC2xESxpfvJwayoJSgusE5kqyrrUL38nWgI1gwLTBoHvm/prXbvogXsBK1AzmLXanI=; 7:Q6/DES+lwZHWFvll3UiZmrUhG60kgj+dxeJWUUd7OvGgcZltLQnRB0Oov73XiAS6YrYPaGek9wD5fgmAHG65JpibIWFD0fS1Oj9tGOiEKqIYw3Ht9fwlYXsehmRZuVQslogpAu4l+deC22L212okPqDTU86g9Kq478c/Y4MwyrzC2e0AjeBCaGpiDZhHIRNefrLmNWV+HVFq/PpqaPJfP/4ibld1UWcpkFlbwTG3rH0hUdaWIogvGhntJxA85Hyh SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2018 16:03:53.8265 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fa3dd245-77dc-4b1d-4245-08d6173701b4 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4626 Archived-At: Subject: [TOOLS-DEVELOPMENT] www.ietf.org updates X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 16:03:58 -0000 Hello, There are three updates to www.ietf.org underway with Torchbox: + Wagtail upgrade from version 1.12.1 to 2.2.2 + Home page display changes (based on feedback received from the IETF = community) + Addition of an RSS feed for the IETF Blog These are expected to be complete by the end of October. -Greg= From nobody Tue Sep 11 11:45: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 61B35131063 for ; Tue, 11 Sep 2018 11:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BIGNUM_EMAILS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 yj1ELxpZLpOm for ; Tue, 11 Sep 2018 11:45:54 -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 6772F130F20 for ; Tue, 11 Sep 2018 11:45:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 42EC2300A3D for ; Tue, 11 Sep 2018 14:45:51 -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 aKx241ijEAQV for ; Tue, 11 Sep 2018 14:45:49 -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 60BE43005D0; Tue, 11 Sep 2018 14:45:49 -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.5 \(3445.9.1\)) Message-Id: <1E867C4F-5694-4E14-BD98-A6A8EE54B059@vigilsec.com> Date: Tue, 11 Sep 2018 14:45:49 -0400 Cc: IESG , IETF Tools Development To: IETF Chair X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TOOLS-DEVELOPMENT] Tools Team Report -- 11 September 2018 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 18:45:58 -0000 Tools Team Report -- 11 September 2018 1. Datatracker Projects - The merge plan was recently updated. -- See http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan -- Highlight that the transition to Python3 and Postgress will be tackled in 2019. - GDPR Compliance -- The email for people to give consent for information in the datatracker did not go out July 2018 as planned. Deletion of email addresses had many more edge cases than expected, so more time was needed to write the code. Next week, the consent requestes will go out to a list of over 15,000 email addresses Of course, most of them are very old, so they will bounce. The email will include a link to their datatracker account page. Alissa will send a message to the community to avoid surprises. - Management of "extra" IETF meeting sessions -- this task is being combined with the update to the meeting scheduling tool that is in the budget for 2019. 2. Community & Other Projects - The Tools Team is working to discontinue MonArch email archives. This will allow all of the mail-related tools to work from one copy of the archives in maildir format. However, the community clearly still likes the speed offered by MonArch. Yesterday an update to mailarchive.ietf.org was deployed, and it is much faster. The update makes much greater use of static pages and it uses ElasticSearch, which is much more efficient than the previous index approach. Robert Sparks will renew the discussion with the community discontinuing the MonArch email archives next week. 3. RFC Services Projects - RFC Format contracts are on schedule: -- IDnits -- Publication Formatter -- Text Submission -- RFClint -- SVGcheck -- XMLdiff - IDnits, Publication Formatter, and Text Submission are on schedule, and they will be completed this year. - RFClint, SVGcheck, and XMLdiff are in final acceptance test by the RFC Series Editor and the RFC Production Center. Bugs are being resolved promptly. 4. Server Infrastructure - The custom DMARC-handling software was deployed for all mail lists in June. We received very positive feedback from the community. - There is a desire to move away from the custom software to ARC, but the ARC software cannot be configured to handle just a few of our mail lists. Henrik is providing requirements to the ARC developers for the needed configuration capability. So far, they have not offered a release date with the new capability. - There are three updates to www.ietf.org underway with Torchbox. First, upgrade the version of Wagtail from 1.12.1 to 2.2.2. Second, change the home page display based on feedback received from the IETF community, which includes adding email archive search to the page. Third, add an RSS feed for the IETF Blog. All three updates are expected to be complete by the end of October. 5. Other Business - The web pages for the Tools Team were updated. -- https://www.ietf.org/about/grpups/tools -- https://datatracker.ietf.org/group/tools/about/ - The IESG needs to decide when to change IDnits to allow I-Ds with non-ascii characters in places other than names to be posted. We have a request to allow posting. -- See https://trac.tools.ietf.org/tools/ietfdb/ticket/2574 - The IMAP server code that is provided by ISODE does not handle changed usernames well. When a person changed their username, the IMAP server noticed the change, but all saved IMAP state was lost. Changing the username back recovered the state. Alexey has written a fix that will be released soon. 6. Parking Lot - Prepare the RFC Production Center code for publication. -- Maybe this can get some attention when the six RFC Format tools are posted in an open source repository. From nobody Wed Sep 19 08:35:20 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 0074313104C for ; Wed, 19 Sep 2018 08:35:19 -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 i9NNO5EZn3cf for ; Wed, 19 Sep 2018 08:35:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BABB1292AD for ; Wed, 19 Sep 2018 08:35:17 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8JFZFV6093913 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 19 Sep 2018 10:35:15 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: IETF Tools Development From: Robert Sparks Message-ID: <24ce90c5-7b69-f5ac-d40e-93dcb0516ce3@nostrum.com> Date: Wed, 19 Sep 2018 10:35:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [TOOLS-DEVELOPMENT] RFC format tools: Shifting emphasis to complete html conversion before idnits X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 15:35:19 -0000 Based on feedback from Heather today, Henrik is shifting to work on completing the html converter before completing idnits. This is a convenient time to do so - the refocus will not cause any delay in the overall plan to complete the tools. has been updated to reflect the shift. RjS From nobody Wed Sep 19 09:03:30 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 92BA9131065; Wed, 19 Sep 2018 09:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeZX0-39Ef0r; Wed, 19 Sep 2018 09:03:27 -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 6C69E130E4D; Wed, 19 Sep 2018 09:03:25 -0700 (PDT) Received: from [192.168.178.20] ([217.251.143.189]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MIQlv-1g5h5G41Tb-00486z; Wed, 19 Sep 2018 18:03:18 +0200 To: Russ Housley , IETF Chair Cc: IESG , IETF Tools Development References: <1E867C4F-5694-4E14-BD98-A6A8EE54B059@vigilsec.com> From: Julian Reschke Message-ID: Date: Wed, 19 Sep 2018 18:03:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <1E867C4F-5694-4E14-BD98-A6A8EE54B059@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:EKMeo0LrHsX4wipsrQspPRgjpzZlK/aVrOolzLopjfUMBpF/OqB qnBcXCTAlD64vG7Bw0HxVhWebS9RYioydtqov32vd1RWyJj4l/7WYpcSL2OKDdla8ssIsVE gH6i98DBkeMgoMMg2BBVMlIfo30P8pKjcLpRO9nKTFOvH6pFVrOE4TQRWRUQE7dg5TvvXod aBh5lGcCBgK+dNyVA06fQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:19rL08vQc7w=:OHM68DwVRkNW5BC4+lZIiS 7OOrH+MilyllUzQRkLzc9vJCmvnojVZ6BLCKz2zaffKaY+nBJ+0CYqFj2SsQT1j34Fz+/WCvw tLs9dRfvFC4ZW05eZ0Tj4XrYO8sXc7nhEZV4sTE7HpZva88DqfMm5k4kGeCn9dTGHNGCyZ+lJ Nvlaz6cwXZuXqjy8G7eGxCpNWIGBynf8+eX4uIkkHGzFZVNbongRxgBeLCsiD8GYB29Tl3T30 0p16TJmdUaoATQwmdfThvZdESM+VrFuw8JhTexsPWl3jfVIGbT+rSEGshrl5KmTMi6E8nvdnK //bPtHapjkioH+tcvhrX2ydmEmgTeUY5RZU1ElGq93j+8qEIBXXzR8azqWwuS3PWvI5LC3N7M T4Z48PvQVgRm490WcqfWZolwsq/f9AyR0Tsboqk6wT+wL1b7o/bG2OQltCXqeJFfnTkdJgo6m Xyqw0vWVgIfB0Q7XvAixIYES5bZ38vCu+Rxzs/hBjGdvdc/uysVDqvG9MSV6Rn9uuIy6/HCty 9lWMl57iy3UZ+CAQ0ZdmCSq+b/nEBk/DQD4Xxs2aNI410BsG//FGlWZAD1YxiayL3Csstn9wI o7XQiGXcj/gjAlFsbxAMSwaWL1BeXc2S51tk0VatTfet+idOIEfHebxSIMxBhLKVRsn1OQ87W /zPTb9cGG0kn/fCUwKkko/5NAVHTeTvRw/Yg8hd7g9vuycnp6FWIw6MknM1rdXRYhh0rHNHoa zATVkHr+2uLNV9xyZrSmLOaf5Gx37s8+xfFUQBi/nL3IlAMev7GCZM+peX+HXoy/F4GRFeuMU fYE97L5FTRWMXCLLDCnT5WBq11DzpmwAd13lgefPxZkwb4/i5I= Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Team Report -- 11 September 2018 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 16:03:29 -0000 On 9/11/2018 8:45 PM, Russ Housley wrote: > ... > - IDnits, Publication Formatter, and Text Submission are on > schedule, and they will be completed this year. > - RFClint, SVGcheck, and XMLdiff are in final acceptance test by > the RFC Series Editor and the RFC Production Center. Bugs are > being resolved promptly. > ... Out of curiosity - we have over 50 issues open on the specs, and so far there hasn't been a lot of progress getting them discussed and resolved. Don't we need to fix these spec issues before any of the deliverables can be considered "complete"? Best regards, Julian From nobody Wed Sep 19 09:12:26 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 1AE45131071; Wed, 19 Sep 2018 09:12:18 -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 Oo25Q_DXebjN; Wed, 19 Sep 2018 09:12:16 -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 DEA7F130FCA; Wed, 19 Sep 2018 09:12:15 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8JGCAPC000233 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 19 Sep 2018 11:12:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: Julian Reschke , Russ Housley , IETF Chair Cc: IESG , IETF Tools Development References: <1E867C4F-5694-4E14-BD98-A6A8EE54B059@vigilsec.com> From: Robert Sparks Message-ID: <1b655149-6724-6a12-d58e-3b7a73e663bd@nostrum.com> Date: Wed, 19 Sep 2018 11:12:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Team Report -- 11 September 2018 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 16:12:18 -0000 No - the development SoWs are scoped to implement the RFCs that are published to the extent they are implementable. Only some of the changes needed because of the issues discovered with the RFCs will be reflected in the initial deliverables - primarily those that would otherwise leave us with tools that wouldn't work at all. After we have agreement on what we want to do about the rest of the specification issues (or as each becomes stable enough to act on), we'll approach changing the tools through maintenance or a new development effort, depending on scope. (I'm expecting them to all be maintenance level). RjS On 9/19/18 11:03 AM, Julian Reschke wrote: > On 9/11/2018 8:45 PM, Russ Housley wrote: >> ... >>     - IDnits, Publication Formatter, and Text Submission are on >>       schedule, and they will be completed this year. >>     - RFClint, SVGcheck, and XMLdiff are in final acceptance test by >>       the RFC Series Editor and the RFC Production Center.  Bugs are >>       being resolved promptly. >> ... > > Out of curiosity - we have over 50 issues open on the specs, and so > far there hasn't been a lot of progress getting them discussed and > resolved. Don't we need to fix these spec issues before any of the > deliverables can be considered "complete"? > > Best regards, Julian > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Wed Sep 19 09:22:22 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 88CEF131072; Wed, 19 Sep 2018 09:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXEnySqe7KPx; Wed, 19 Sep 2018 09:22:13 -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 722EB131071; Wed, 19 Sep 2018 09:22:11 -0700 (PDT) Received: from [192.168.178.20] ([217.251.143.189]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MNZVG-1g8heZ3h6I-007AoP; Wed, 19 Sep 2018 18:21:58 +0200 To: Robert Sparks , Russ Housley , IETF Chair Cc: IESG , IETF Tools Development References: <1E867C4F-5694-4E14-BD98-A6A8EE54B059@vigilsec.com> <1b655149-6724-6a12-d58e-3b7a73e663bd@nostrum.com> From: Julian Reschke Message-ID: <8e88e8c6-06d4-cce5-cb3a-dc2bc2860487@gmx.de> Date: Wed, 19 Sep 2018 18:21:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <1b655149-6724-6a12-d58e-3b7a73e663bd@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:pQLJmbZKWCMjJwe0V/8JhAzEqttiMfgk+i1pHtDmGirOCxdLJHb pBBJPR99674CLGaJdFX/IAMKWLNDfRxqi+Dzyo1ywAyW26rf5MlKFF9kJVry3z0EydmgZuv ceEZA43saT6gP3ORubfXs2zNuheiKxoBr0XhstHz7NF4o5K8FGiSEWATy5X0XfruURXBRf3 BEA3bollms35fH8AVUFEw== X-UI-Out-Filterresults: notjunk:1;V01:K0:/6dYE6WK6mU=:dOLm6b/uMYxRN71+RnnaPJ PPM+gom4O59t78D9jLt241TbhC1FPvQU9sBtN8LwvDBhX2XGs3hmPfJ7BLD6sYULCN2kkwapE ASyVZ/NbFHUAx1QDY5R4l0P/peTZDSpH6R8nawRwTUsVWeXhFjvBjfoFsOBT7QECOx+MxntIV insvUB/qEFjESdQex65mlxo94BEmFUPtrV4GubfFs8OKQ5dgdlPZzMyUjni0r0QpMYVbyRkB9 swpY9b8fB5ZR+W153LG3NATg5IpZkPOK8Ejh/xI/ItJAQ7pDrYHfQSM3w/glHYK2W8Jg5HN5I m/Vnz03PI1NwsJOQcz50CdUyy1we2jM7La4OZfd1TuGHFewfajvoPwFs1PZdmPxvVEfe2yBFI hcCRiHEH4XURe/xkHEra00XkvWlNqVhnyXu9kYHmQrJrH+4MfqeKnfYj+TboJ0i5n8LYRnWjx halwGUvaxdlb9XbCgbRZsZ5I5OYOveffSjrPoxI93eeZsdFi/srkQOW7NxZ4FPKODWH+k5zUO zF/6bDljRGNh1BUn3W+axRLEI43PwW7m18FPCXmzTnz37FQqynX5Djr8HO1vaTwjQG7LLUAUv EbazxKaopTO3zECO6oWWFUFEIILiuw3IYevYfuc8C8yFol2qa/IIWmsUGtVT+gGRp+LSnYyBS ZTy4r05B5Bnsb08zqQDo7WBlvSLouj/MRXzPF6dEswiBdDZiITpSyCaDI+97hvCUkjI2rp2ly zyjnDEztkDCmgsoqh1vFkuchh1r23dM4DYQ+gb8N4u1/FMM/iZGhO9KmCTY3tjA2LFjZPWRmd DLBiY4AvEZt55W0IbnUvcFMCD/RriHCAij5sk+kj0GUgI9kM74= Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Team Report -- 11 September 2018 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 16:22:15 -0000 On 9/19/2018 6:12 PM, Robert Sparks wrote: > No - the development SoWs are scoped to implement the RFCs that are > published to the extent they are implementable. > > Only some of the changes needed because of the issues discovered with > the RFCs will be reflected in the initial deliverables - primarily those > that would otherwise leave us with tools that wouldn't work at all. > ... Well, some of he bug categories are: 1) missing features 2) features that should work differently (such as anchor numbering, deprecation of v2 elements that over-complicate things...) 3) simplifications and probably more... My fear is that by shipping code for controversial stuff we'll essentially paint us into a corner - it's hard to get rid of features once they have been used in the wild. Do we have a strategy for making incompatible changes to the v3 vocabulary? Best regards, Julian From nobody Wed Sep 19 10:50:16 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 D22FF130DF5; Wed, 19 Sep 2018 10:50:08 -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 yc6LqKUDeHT9; Wed, 19 Sep 2018 10:50:07 -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 40779127333; Wed, 19 Sep 2018 10:50:07 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8JHo0aU016100 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 19 Sep 2018 12:50:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: Julian Reschke , Russ Housley , IETF Chair Cc: IESG , IETF Tools Development References: <1E867C4F-5694-4E14-BD98-A6A8EE54B059@vigilsec.com> <1b655149-6724-6a12-d58e-3b7a73e663bd@nostrum.com> <8e88e8c6-06d4-cce5-cb3a-dc2bc2860487@gmx.de> From: Robert Sparks Message-ID: <5d78f6c1-ea10-5d38-3871-59ec2193fd41@nostrum.com> Date: Wed, 19 Sep 2018 12:49:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8e88e8c6-06d4-cce5-cb3a-dc2bc2860487@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Team Report -- 11 September 2018 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 17:50:09 -0000 On 9/19/18 11:21 AM, Julian Reschke wrote: > On 9/19/2018 6:12 PM, Robert Sparks wrote: >> No - the development SoWs are scoped to implement the RFCs that are >> published to the extent they are implementable. >> >> Only some of the changes needed because of the issues discovered with >> the RFCs will be reflected in the initial deliverables - primarily >> those that would otherwise leave us with tools that wouldn't work at >> all. >> ... > > Well, some of he bug categories are: > > 1) missing features > > 2) features that should work differently (such as anchor numbering, > deprecation of v2 elements that over-complicate things...) > > 3) simplifications > > and probably more... Thanks for thinking these through. > > My fear is that by shipping code for controversial stuff we'll > essentially paint us into a corner - it's hard to get rid of features > once they have been used in the wild. Yes, but... > > Do we have a strategy for making incompatible changes to the v3 > vocabulary? It's a position with some obvious rough edges, but I'm not sure we need one other than "just do it", as long as we address these the documents and make the changes in the tools before we publish an RFC in the v3 format. Those folks brave enough to be working on drafts using the v3 format in the meantime would need to change their drafts if an incompatible change occurred. If something causes things to drag out such that we have an archival artifact and then need to change the version, we'd need to do something differently. > > Best regards, Julian From nobody Wed Sep 19 11:25:05 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 7D009130E63; Wed, 19 Sep 2018 11:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IyfW8aI3AFr; Wed, 19 Sep 2018 11:25:03 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 A6760127B92; Wed, 19 Sep 2018 11:25:02 -0700 (PDT) Received: from [192.168.178.20] ([217.251.143.189]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M2L60-1fm7hu1Gpo-00s7Nl; Wed, 19 Sep 2018 20:24:42 +0200 To: Robert Sparks , Russ Housley , IETF Chair Cc: IESG , IETF Tools Development References: <1E867C4F-5694-4E14-BD98-A6A8EE54B059@vigilsec.com> <1b655149-6724-6a12-d58e-3b7a73e663bd@nostrum.com> <8e88e8c6-06d4-cce5-cb3a-dc2bc2860487@gmx.de> <5d78f6c1-ea10-5d38-3871-59ec2193fd41@nostrum.com> From: Julian Reschke Message-ID: Date: Wed, 19 Sep 2018 20:24:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <5d78f6c1-ea10-5d38-3871-59ec2193fd41@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:3V+CJB4Jmn9oVVBRFyccTp5Y/vOinFYkhlJ9Uc72LKaTd5cEuEj 6vvPHihqq7fl71AeF6aRn/qMTtuB5Ddo8kkduVPhMVpObuuBMnTML4CMafUdJu4HtDqO8NP xjy38YJpg3plqoROd0Ve6GWL2SIWJBMDfeqJObM2JTkJdp5g97MQy99X+esISxhb0b7RuLC Ea5hStBBoQbJoIYHc8aDA== X-UI-Out-Filterresults: notjunk:1;V01:K0:nHOOGg7FNo8=:PqN4axnldfGTWplx8fNxgA gFGikCutiqB7vuMb41cqEwE7GaA1wAYhRvDBmggiKKTQvjb1WBElRduS/o8Brp4eb8JxZiVzG /mtudEK2oBn9RFkcKYtVLTa/6qF5a4UuDA25imwjfTayiRz0MDYV7bFrU8LHGOYX9DXKMrqxX FuzgjN1RRo5X09kDzogxXr++S+uCTRHCAzxUto0dQFWEd85n8bI2Waj7I/KE5meQ9NXZOcL5r w3VaU6QlZDmGc7QoNi0Lq7xUpoDwgqVId/EuhK2sPY6Q1UzKkIMEABsstuK+MQ/3jjOZmRREm 0h2fCrXtJrdeETn3K1kzH0So2tM72CTBJ8eJYx91KRGbufUpnc3ak+BSFs7Lh9MJIY5bQQAot Ibst91xWofZM+moDVVBQiapsQWUqjBYzSUtFB6nB47NVqb/P72HHOyY/03pKonU23Z0HEJojS 8u+Vk1v+EJ7k/y/8x9ml0dYOwHNLIDx29DRPBmQEOijLkfz9VQxt+YqEMKpU7jsFWvyu0ngli iHTvgwhhJRsXng6kEwUb/CEU4HVW5BaGNQLY10E1HWsPqy15+SLb/dTNe34l8ZSOGXk7wGo5Q SdzdV1T4z2D7VAM6+YIn+QB1cABVKbBH4ozF2R7FcgbN6gkBGpNYjU6t6aKInBdDsv3brjfN9 eFJaUQW/Vdqkzgzq7/Ijt70T2Dyy09QBdQ4WwQbYRmpUYc6RPyO12bJ8auhWYLn1RpJmO7ZvV 8qERRDhbB21avu6cWlwtLoeDeopMMkcF188cB9zMkk43LTOmCaEPPhENLHDti06RYEFAe3xif p1ygnAyj3q1oCYILKXVucxcZj8xUb1maHRTv2uKuF8YjWrE3go= Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Team Report -- 11 September 2018 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 18:25:05 -0000 On 9/19/2018 7:49 PM, Robert Sparks wrote: > > > On 9/19/18 11:21 AM, Julian Reschke wrote: >> On 9/19/2018 6:12 PM, Robert Sparks wrote: >>> No - the development SoWs are scoped to implement the RFCs that are >>> published to the extent they are implementable. >>> >>> Only some of the changes needed because of the issues discovered with >>> the RFCs will be reflected in the initial deliverables - primarily >>> those that would otherwise leave us with tools that wouldn't work at >>> all. >>> ... >> >> Well, some of he bug categories are: >> >> 1) missing features >> >> 2) features that should work differently (such as anchor numbering, >> deprecation of v2 elements that over-complicate things...) >> >> 3) simplifications >> >> and probably more... > Thanks for thinking these through. >> >> My fear is that by shipping code for controversial stuff we'll >> essentially paint us into a corner - it's hard to get rid of features >> once they have been used in the wild. > Yes, but... >> >> Do we have a strategy for making incompatible changes to the v3 >> vocabulary? > It's a position with some obvious rough edges, but I'm not sure we need > one other than "just do it", as long as we address these the documents > and make the changes in the tools before we publish an RFC in the v3 > format. Those folks brave enough to be working on drafts using the v3 > format in the meantime would need to change their drafts if an > incompatible change occurred. > ... But that essentially means were just getting to a "beta" stage, not some kind of stable release. Would be better to be clear about that. Best regards, Julian From nobody Wed Sep 19 11:44:33 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 33245130E6A for ; Wed, 19 Sep 2018 11:44:32 -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 OtZCd45UJG3c for ; Wed, 19 Sep 2018 11:44:30 -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 3DD77127B92 for ; Wed, 19 Sep 2018 11:44:30 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8JIiTuX025007 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 19 Sep 2018 13:44:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: IETF Tools Development From: Robert Sparks Message-ID: Date: Wed, 19 Sep 2018 13:44:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [TOOLS-DEVELOPMENT] Draft of message to send re mailarch and mhonarc X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 18:44:32 -0000 Here is a proposed message to send at least to IETF general, if not to ietf-announce. Thoughts on changes? We made the datatracker-project@ alias recently. Should we create a mailarch-project@ alias for bug reports rather than using django-project@? (Or is there an even better address to use than those?). -------- To: IETF Announce Subject: Improvements to the mailarch tool, and plans to discontinue the mhonarc archives There have been several improvements to the mailarch tool recently. If you haven't already discovered it, please try out the new "Static Mode", particularly if you frequently use the Mhonarc archives. See, for example, . To get this view by default when browsing lists, set "Static Mode On" in the Settings menu at top right of the page. Also note that the speed of searching a list, and searching across multiple lists has been significantly improved. The use of whitespace and fonts have also been adjusted. We are continuing to work towards having a single copy of the archived messages to manage that all the tools will serve. The bits shown by mailarch are the same bits on disk used by the imap access to the archive. In particular, we plan to discontinue the use of Mhonarc soon, likely between IETF 103 and 104. When we make that change, all exising URLs into the Mhonarc archives will redirect to the same message in mailarch as discussed in section 2.7 of RFC6778. Please exercise the mailarch system. If you find issues, report them at and choose the "MailArchive: User Interface Component". Alternatively, you can send mail to django-project@ietf.org. From nobody Wed Sep 19 12:08: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 85029130DD4 for ; Wed, 19 Sep 2018 12:08:46 -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 sVL82s3aNsX6 for ; Wed, 19 Sep 2018 12:08:45 -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 640AE130E86 for ; Wed, 19 Sep 2018 12:08:45 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 275EC1D30ED for ; Wed, 19 Sep 2018 12:08:27 -0700 (PDT) Received: from mail-it0-f43.google.com (mail-it0-f43.google.com [209.85.214.43]) by c8a.amsl.com (Postfix) with ESMTPSA id 049781CA05C for ; Wed, 19 Sep 2018 12:08:27 -0700 (PDT) Received: by mail-it0-f43.google.com with SMTP id h3-v6so9838187ita.2 for ; Wed, 19 Sep 2018 12:08:45 -0700 (PDT) X-Gm-Message-State: APzg51D4wUyYlusrSXcx+5Cnu3ePj7isYSzxxN/7mZpa1efFuS9Wz6JA Hph1VoMcl1tNvUMwEOOA2U6q16xokJeN1t+YWE4= X-Google-Smtp-Source: ANB0VdZi0XBbGcojkcgKwfIT27GFzCQTQ0ohaNCgL1I5NsPYKt2kPvPdKqZtzkXraqer7yPTc7EsCkv4xbsgpcqT/TA= X-Received: by 2002:a24:99c2:: with SMTP id a185-v6mr23636973ite.12.1537384124625; Wed, 19 Sep 2018 12:08:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Glen Date: Wed, 19 Sep 2018 12:08:32 -0700 X-Gmail-Original-Message-ID: Message-ID: To: tools-development@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Draft of message to send re mailarch and mhonarc X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 19:08:46 -0000 All - On Wed, Sep 19, 2018 at 11:44 AM Robert Sparks wrote: >Should we create a mailarch-project@ alias for bug reports rather than using > django-project@? As the IT Director of the vendor who will ultimately receive these, my vote would be YES PLEASE. > (Or is there an even better address to use than those?). I can't think of one. > To get this view by default when browsing lists, set "Static Mode On" in > the Settings menu at top right of the page. My feeble memory tells me that someone tripped over this before because they were not logged in. If my memory is correct, I'd recommend adding a phrase to that effect (i.e., ".... top right of the page, when you are logged in.") or whatever. > When we make that change, all exising URLs into the Mhonarc > archives will redirect to the same message in mailarch as discussed in > section 2.7 of RFC6778. Possibly orthogonal to your topic, but I'm curious as to the status of this? Has someone already worked out how to implement this? (Since it would probably fall to me to implement, just clarifying that I have not given this any thought at all.) Apologies if yes, or off point, I just don't remember where this stands. Best, Glen From nobody Wed Sep 19 12:15:36 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 5D8CE130E97 for ; Wed, 19 Sep 2018 12:15:34 -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 ji13DqrPSpgF for ; Wed, 19 Sep 2018 12:15:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88CC130E61 for ; Wed, 19 Sep 2018 12:15:31 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8JJFUTb029876 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 19 Sep 2018 14:15:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: tools-development@ietf.org References: From: Robert Sparks Message-ID: <99835619-50eb-acbf-ca6f-6d45c1a04bb1@nostrum.com> Date: Wed, 19 Sep 2018 14:15:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Draft of message to send re mailarch and mhonarc X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 19:15:34 -0000 On 9/19/18 2:08 PM, Glen wrote: > All - > > On Wed, Sep 19, 2018 at 11:44 AM Robert Sparks wrote: >> Should we create a mailarch-project@ alias for bug reports rather than using >> django-project@? > As the IT Director of the vendor who will ultimately receive these, my > vote would be YES PLEASE. > >> (Or is there an even better address to use than those?). > I can't think of one. > >> To get this view by default when browsing lists, set "Static Mode On" in >> the Settings menu at top right of the page. > My feeble memory tells me that someone tripped over this before > because they were not logged in. If my memory is correct, I'd > recommend adding a phrase to that effect (i.e., ".... top right of the > page, when you are logged in.") or whatever. We fixed that - it shows now if you are logged in or not, > >> When we make that change, all exising URLs into the Mhonarc >> archives will redirect to the same message in mailarch as discussed in >> section 2.7 of RFC6778. > Possibly orthogonal to your topic, but I'm curious as to the status of > this? Has someone already worked out how to implement this? (Since > it would probably fall to me to implement, just clarifying that I have > not given this any thought at all.) Apologies if yes, or off point, I > just don't remember where this stands. It was implemented with the original project and has been tested again recently to make sure the implementation has not suffered rot. > > Best, > Glen > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Wed Sep 19 12:37:20 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 54989130E61 for ; Wed, 19 Sep 2018 12:37:18 -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, HTML_MESSAGE=0.001, 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 tP62gdKigMXP for ; Wed, 19 Sep 2018 12:37:16 -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 63F80129C6A for ; Wed, 19 Sep 2018 12:37:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 297B8300A9A for ; Wed, 19 Sep 2018 15:37:14 -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 Ep8vTdk9znJt for ; Wed, 19 Sep 2018 15:37:12 -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 2386730044B; Wed, 19 Sep 2018 15:37:12 -0400 (EDT) From: Russ Housley Message-Id: <955AD9C6-7636-480B-B38A-0E775D687173@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BE8EE072-ACA3-4960-AE1E-EEE61A0A6629" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 19 Sep 2018 15:37:12 -0400 In-Reply-To: Cc: Robert Sparks , IETF Chair , IESG , IETF Tools Development To: Julian Reschke References: <1E867C4F-5694-4E14-BD98-A6A8EE54B059@vigilsec.com> <1b655149-6724-6a12-d58e-3b7a73e663bd@nostrum.com> <8e88e8c6-06d4-cce5-cb3a-dc2bc2860487@gmx.de> <5d78f6c1-ea10-5d38-3871-59ec2193fd41@nostrum.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Team Report -- 11 September 2018 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 19:37:19 -0000 --Apple-Mail=_BE8EE072-ACA3-4960-AE1E-EEE61A0A6629 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Julian: >=20 >>> Do we have a strategy for making incompatible changes to the v3 = vocabulary? >> It's a position with some obvious rough edges, but I'm not sure we = need one other than "just do it", as long as we address these the = documents and make the changes in the tools before we publish an RFC in = the v3 format. Those folks brave enough to be working on drafts using = the v3 format in the meantime would need to change their drafts if an = incompatible change occurred. >> ... >=20 > But that essentially means were just getting to a "beta" stage, not = some kind of stable release. Would be better to be clear about that. My perspective is that the code will implement the existing RFCs. Once = bis documents are available, we can make an assessment of the code = changes that are needed. We also want the lessons learned from doing to = code to impact the bis documents. Russ --Apple-Mail=_BE8EE072-ACA3-4960-AE1E-EEE61A0A6629 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Julian:

Do we have a strategy = for making incompatible changes to the v3 vocabulary?
It's a position with some obvious rough edges, = but I'm not sure we need one other than "just do it", as long as we = address these the documents and make the changes in the tools before we = publish an RFC in the v3 format. Those folks brave enough to be working = on drafts using the v3 format in the meantime would need to change their = drafts if an incompatible change occurred.
...

But that essentially means were just getting to a "beta" = stage, not some kind of stable release. Would be better to be clear = about that.

My = perspective is that the code will implement the existing RFCs. =  Once bis documents are available, we can make an assessment of the = code changes that are needed.  We also want the lessons learned = from doing to code to impact the bis documents.

Russ


= --Apple-Mail=_BE8EE072-ACA3-4960-AE1E-EEE61A0A6629-- From nobody Wed Sep 19 14:36:26 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 32E36130E8B for ; Wed, 19 Sep 2018 14:36:25 -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, HTML_MESSAGE=0.001, 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 vGxpYSeBsLAg for ; Wed, 19 Sep 2018 14:36:24 -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 1D56B130E02 for ; Wed, 19 Sep 2018 14:36:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0444D300A9A for ; Wed, 19 Sep 2018 17:36:22 -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 vZT7UpDHRA5t for ; Wed, 19 Sep 2018 17:36:20 -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 C5EC3300435; Wed, 19 Sep 2018 17:36:20 -0400 (EDT) From: Russ Housley Message-Id: <81967285-7E69-4EAB-8622-3D15DF789898@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_09D015BE-66AB-4088-B7F1-5A14380EEBF1" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 19 Sep 2018 17:36:21 -0400 In-Reply-To: Cc: IETF Tools Development To: Robert Sparks References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Draft of message to send re mailarch and mhonarc X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 21:36:25 -0000 --Apple-Mail=_09D015BE-66AB-4088-B7F1-5A14380EEBF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Robert: >=20 > We are continuing to work towards having a single copy of the archived > messages to manage that all the tools will serve. The bits shown by = mailarch > are the same bits on disk used by the imap access to the archive. This reads a bit awkwardly to me. And, it misses one important point. I = suggest: We are working towards a single copy of the archived mail list messages. = Currently, mailarchive and IMAP work from the same files, but MonArch uses a = separate set of files in another format. Russ --Apple-Mail=_09D015BE-66AB-4088-B7F1-5A14380EEBF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Robert:

We are continuing to work = towards having a single copy of the archived
messages to manage that all the = tools will serve. The bits shown by mailarch
are the same bits on disk used = by the imap access to the archive.


This = reads a bit awkwardly to me.  And, it misses one important point. I = suggest:

We are working towards a single copy of the archived mail = list messages. Currently,
mailarchive and IMAP work = from the same files, but MonArch uses a separate
set = of files in another format.

Russ

= --Apple-Mail=_09D015BE-66AB-4088-B7F1-5A14380EEBF1-- From nobody Thu Sep 20 04:10:52 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 C32D6130DCF for ; Thu, 20 Sep 2018 04:10:50 -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 pv2UURCFEj4P for ; Thu, 20 Sep 2018 04:10:49 -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 EAB5D130E1B for ; Thu, 20 Sep 2018 04:10:48 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:61829 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1g2wrA-0006Hx-BC; Thu, 20 Sep 2018 04:10:48 -0700 To: Robert Sparks , IETF Tools Development References: From: Henrik Levkowetz Message-ID: Date: Thu, 20 Sep 2018 13:10:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W4rlk8KgOOhbSXBQbMLCv3IOiNN4k3eA9" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: tools-development@ietf.org, rjsparks@nostrum.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Draft of message to send re mailarch and mhonarc X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 11:10:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W4rlk8KgOOhbSXBQbMLCv3IOiNN4k3eA9 Content-Type: multipart/mixed; boundary="dbATGQe2krAXoLeawce3nSi1gQjTaFTSu"; protected-headers="v1" From: Henrik Levkowetz To: Robert Sparks , IETF Tools Development Message-ID: Subject: Re: [TOOLS-DEVELOPMENT] Draft of message to send re mailarch and mhonarc References: In-Reply-To: --dbATGQe2krAXoLeawce3nSi1gQjTaFTSu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-09-19 20:44, Robert Sparks wrote: > Here is a proposed message to send at least to IETF general, if not to = > ietf-announce. >=20 > Thoughts on changes? >=20 > We made the datatracker-project@ alias recently. Should we create a=20 > mailarch-project@ alias for bug reports rather than using=20 > django-project@? (Or is there an even better address to use than those?= ). Sounds good to me, as does the message below. Best, Henrik > -------- >=20 > To: IETF Announce >=20 > Subject: Improvements to the mailarch tool, and plans to discontinue th= e=20 > mhonarc archives >=20 > There have been several improvements to the mailarch tool recently. >=20 > If you haven't already discovered it, please try out the new "Static Mo= de", > particularly if you frequently use the Mhonarc archives. >=20 > See, for example,=20 > . >=20 > To get this view by default when browsing lists, set "Static Mode On" i= n=20 > the > Settings menu at top right of the page. >=20 > Also note that the speed of searching a list, and searching across=20 > multiple lists > has been significantly improved. The use of whitespace and fonts have=20 > also been > adjusted. >=20 > We are continuing to work towards having a single copy of the archived > messages to manage that all the tools will serve. The bits shown by mai= larch > are the same bits on disk used by the imap access to the archive. >=20 > In particular, we plan to discontinue the use of Mhonarc soon, likely=20 > between > IETF 103 and 104. When we make that change, all exising URLs into the=20 > Mhonarc > archives will redirect to the same message in mailarch as discussed in = > section > 2.7 of RFC6778. >=20 > Please exercise the mailarch system. If you find issues, report them at= > and choose the > "MailArchive: User Interface Component". Alternatively, you can send ma= il > to django-project@ietf.org. >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --dbATGQe2krAXoLeawce3nSi1gQjTaFTSu-- --W4rlk8KgOOhbSXBQbMLCv3IOiNN4k3eA9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlujgDEACgkQTptXS4+7 FxrhCw/+N6yTPmr/jZL3uNUwINZrh8mE7WtYvQsubB39YNKFNsDJRG6YG+Qtjd3W g7lgtJWAtkXjRg6boMgsMrV9myMXLklI1XaZW37c/ITC6EcGueW1tP1PzNN0ONfk jl86zFk3ODtTZZJVJCgM0YB0wDoPn8xOca5iI7a0QXBOrq0oJW2VB8CLxYvqj+dI wYdXl7HLp49shHTSehxRSFIHcbzopH79eafHI6nLIBzWl9XH+cMydX29tne3BFpM Dx2KY/p+3imVHkUzntUv8XX74wHi8RWkibdAIMbOaK7YMFYuDa1brivsI98fDT4q eYJgM5/8nGB8tuO97RFOEiycXIq2Vhhtz1vFikvsXP7qKF3XHC+jJC1SOmgLSflP UCzOEr+fh8jNcMMsRw16uoh+mtvmtH2vuJ1jMpoDKJoCAoqnpF2FfERMbyEv5/GW dswDk58eTvfLW4S9JDfgPF4Ozip+4Lx3hcSCU2U8QuLCPir8Vs+Ql3SATzWoktBd 2Or/fq+tTk27T6UfnPA4c8IYd+rC/kVEQh/MYFYmBDjaBmBt1CI1y793NtYo61we k3SpFN1O739gTn6uqnC5+ze05KSPpyJNgc0fuzsa5+TxAxx1uOTlsZwNIJ0sjuoM WBWjruHmYJYJgDji8cxEBoo2Tq9TDtVbsNcX5L1/G0RAs+9oWvA= =DsID -----END PGP SIGNATURE----- --W4rlk8KgOOhbSXBQbMLCv3IOiNN4k3eA9-- From nobody Tue Sep 25 11:35:30 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 6D7CD128CB7 for ; Tue, 25 Sep 2018 11:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 etgDMLJzOxQr for ; Tue, 25 Sep 2018 11:35:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A3A128CF2 for ; Tue, 25 Sep 2018 11:35:27 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8PIZQHh020675 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 25 Sep 2018 13:35:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: tools-development@ietf.org References: From: Robert Sparks Message-ID: Date: Tue, 25 Sep 2018 13:35:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F11E2EF090D213F2EBEA754B" Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Draft of message to send re mailarch and mhonarc X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 18:35:29 -0000 This is a multi-part message in MIME format. --------------F11E2EF090D213F2EBEA754B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Here is a changed version capturing Russ' suggestion, and changing the email for reporting issues. Is this ready to send? Is now the right time to send it? RjS --- To: IETF Announce Subject: Improvements to the mailarch tool, and plans to discontinue the mhonarc archives There have been several improvements to the mailarch tool recently. If you haven't already discovered it, please try out the new "Static Mode", particularly if you frequently use the Mhonarc archives. See, for example, . To get this view by default when browsing lists, set "Static Mode On" in the Settings menu at top right of the page. Also note that the speed of searching a list, and searching across multiple lists has been significantly improved. The use of whitespace and fonts have also been adjusted. We are working towards a single copy of the archived mail list messages. Currently, mailarch and IMAP work from the same files, but MonArch uses a separate set of files in another format. We plan to discontinue the use of Mhonarc soon, likely between IETF 103 and 104. When we make that change, all exising URLs into the Mhonarc archives will redirect to the same message in mailarch as discussed in section 2.7 of RFC6778. Please exercise the mailarch system. If you find issues, report them at and choose the "MailArchive: User Interface Component". Alternatively, you can send mail to mailarch-project@ietf.org. --------------F11E2EF090D213F2EBEA754B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Here is a changed version capturing Russ' suggestion, and changing the email for reporting issues.
Is this ready to send?
Is now the right time to send it?

RjS

---
To: IETF Announce

Subject: Improvements to the mailarch tool, and plans to discontinue the mhonarc archives

There have been several improvements to the mailarch tool recently.

If you haven't already discovered it, please try out the new "Static Mode",
particularly if you frequently use the Mhonarc archives.

See, for example, <https://mailarchive.ietf.org/arch/browse/static/ietf/2018-09/>.

To get this view by default when browsing lists, set "Static Mode On" in the
Settings menu at top right of the page.

Also note that the speed of searching a list, and searching across multiple lists
has been significantly improved. The use of whitespace and fonts have also been
adjusted.

We are working towards a single copy of the archived mail list messages. Currently,
mailarch and IMAP work from the same files, but MonArch uses a separate set of files
in another format.

We plan to discontinue the use of Mhonarc soon, likely between IETF 103 and 104.
When we make that change, all exising URLs into the Mhonarc archives will redirect
to the same message in mailarch as discussed in section 2.7 of RFC6778.

Please exercise the mailarch system. If you find issues, report them at
<https://trac.tools.ietf.org/tools/ietfdb/newticket> and choose the
"MailArchive: User Interface Component". Alternatively, you can send mail
to mailarch-project@ietf.org.
--------------F11E2EF090D213F2EBEA754B-- From nobody Tue Sep 25 15:01:35 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 D4451130DDA for ; Tue, 25 Sep 2018 15:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 XiUDrfeAt_pw for ; Tue, 25 Sep 2018 15:01:31 -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 070D2130DD3 for ; Tue, 25 Sep 2018 15:01:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A15B8300A3D for ; Tue, 25 Sep 2018 18:01:28 -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 tEPR3FKBwJ6W for ; Tue, 25 Sep 2018 18:01:27 -0400 (EDT) Received: from [172.20.4.108] (h48.74.129.40.static.ip.windstream.net [40.129.74.48]) by mail.smeinc.net (Postfix) with ESMTPSA id E077D300494; Tue, 25 Sep 2018 18:01:26 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7FC9B156-1F76-46EA-A9D3-6AD160E05207" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 25 Sep 2018 18:01:27 -0400 In-Reply-To: Cc: IETF Tools Development To: Robert Sparks References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Draft of message to send re mailarch and mhonarc X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 22:01:34 -0000 --Apple-Mail=_7FC9B156-1F76-46EA-A9D3-6AD160E05207 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Looks good to me. Russ > On Sep 25, 2018, at 2:35 PM, Robert Sparks = wrote: >=20 > Here is a changed version capturing Russ' suggestion, and changing the = email for reporting issues. > Is this ready to send? > Is now the right time to send it? >=20 > RjS >=20 > --- > To: IETF Announce=20 >=20 > Subject: Improvements to the mailarch tool, and plans to discontinue = the mhonarc archives=20 >=20 > There have been several improvements to the mailarch tool recently.=20 >=20 > If you haven't already discovered it, please try out the new "Static = Mode",=20 > particularly if you frequently use the Mhonarc archives.=20 >=20 > See, for example, = = .=20 >=20 > To get this view by default when browsing lists, set "Static Mode On" = in the=20 > Settings menu at top right of the page.=20 >=20 > Also note that the speed of searching a list, and searching across = multiple lists=20 > has been significantly improved. The use of whitespace and fonts have = also been=20 > adjusted.=20 >=20 > We are working towards a single copy of the archived mail list = messages. Currently, > mailarch and IMAP work from the same files, but MonArch uses a = separate set of files > in another format. >=20 > We plan to discontinue the use of Mhonarc soon, likely between IETF = 103 and 104.=20 > When we make that change, all exising URLs into the Mhonarc archives = will redirect=20 > to the same message in mailarch as discussed in section 2.7 of = RFC6778.=20 >=20 > Please exercise the mailarch system. If you find issues, report them = at=20 > = and choose the=20 > "MailArchive: User Interface Component". Alternatively, you can send = mail=20 > to mailarch-project@ietf.org .=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --Apple-Mail=_7FC9B156-1F76-46EA-A9D3-6AD160E05207 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Looks good to me.

Russ


On Sep 25, 2018, at 2:35 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

Here is a changed version capturing Russ' suggestion, and changing the email for reporting issues.
Is this ready to send?
Is now the right time to send it?

RjS

---
To: IETF Announce

Subject: Improvements to the mailarch tool, and plans to discontinue the mhonarc archives

There have been several improvements to the mailarch tool recently.

If you haven't already discovered it, please try out the new "Static Mode",
particularly if you frequently use the Mhonarc archives.

See, for example, <https://mailarchive.ietf.org/arch/browse/static/ietf/2018-09/>.

To get this view by default when browsing lists, set "Static Mode On" in the
Settings menu at top right of the page.

Also note that the speed of searching a list, and searching across multiple lists
has been significantly improved. The use of whitespace and fonts have also been
adjusted.

We are working towards a single copy of the archived mail list messages. Currently,
mailarch and IMAP work from the same files, but MonArch uses a separate set of files
in another format.

We plan to discontinue the use of Mhonarc soon, likely between IETF 103 and 104.
When we make that change, all exising URLs into the Mhonarc archives will redirect
to the same message in mailarch as discussed in section 2.7 of RFC6778.

Please exercise the mailarch system. If you find issues, report them at
<https://trac.tools.ietf.org/tools/ietfdb/newticket> and choose the
"MailArchive: User Interface Component". Alternatively, you can send mail
to mailarch-project@ietf.org.
_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development

--Apple-Mail=_7FC9B156-1F76-46EA-A9D3-6AD160E05207-- From nobody Tue Sep 25 15:04:00 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 C4C81130DD3 for ; Tue, 25 Sep 2018 15:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxprrPSXteYK for ; Tue, 25 Sep 2018 15:03:57 -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 EC130130DD0 for ; Tue, 25 Sep 2018 15:03:56 -0700 (PDT) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:51700 helo=[192.168.1.126]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g4vQx-0004u6-KA; Tue, 25 Sep 2018 15:03:56 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-77ADC1F4-9174-40E1-A239-EA401BC518B4 Mime-Version: 1.0 (1.0) From: Henrik Levkowetz X-Mailer: iPad Mail (15F79) In-Reply-To: Date: Wed, 26 Sep 2018 00:03:48 +0200 Cc: Robert Sparks , IETF Tools Development Content-Transfer-Encoding: 7bit Message-Id: <0D79BA24-5C89-4A76-B33D-019AE1D757EB@levkowetz.com> References: To: Russ Housley X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: tools-development@ietf.org, rjsparks@nostrum.com, housley@vigilsec.com, henrik@levkowetz.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] Draft of message to send re mailarch and mhonarc X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 22:03:59 -0000 --Apple-Mail-77ADC1F4-9174-40E1-A239-EA401BC518B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yup. Best regards, Henrik > On 26 Sep 2018, at 00:01, Russ Housley wrote: >=20 > Looks good to me. >=20 > Russ >=20 >=20 >> On Sep 25, 2018, at 2:35 PM, Robert Sparks wrote: >>=20 >> Here is a changed version capturing Russ' suggestion, and changing the em= ail for reporting issues. >> Is this ready to send? >> Is now the right time to send it? >>=20 >> RjS >>=20 >> --- >> To: IETF Announce=20 >>=20 >> Subject: Improvements to the mailarch tool, and plans to discontinue the m= honarc archives=20 >>=20 >> There have been several improvements to the mailarch tool recently.=20 >>=20 >> If you haven't already discovered it, please try out the new "Static Mode= ",=20 >> particularly if you frequently use the Mhonarc archives.=20 >>=20 >> See, for example, .=20 >>=20 >> To get this view by default when browsing lists, set "Static Mode On" in t= he=20 >> Settings menu at top right of the page.=20 >>=20 >> Also note that the speed of searching a list, and searching across multip= le lists=20 >> has been significantly improved. The use of whitespace and fonts have als= o been =20 >> adjusted.=20 >>=20 >> We are working towards a single copy of the archived mail list messages. C= urrently, >> mailarch and IMAP work from the same files, but MonArch uses a separate s= et of files >> in another format. >>=20 >> We plan to discontinue the use of Mhonarc soon, likely between IETF 103 a= nd 104.=20 >> When we make that change, all exising URLs into the Mhonarc archives will= redirect=20 >> to the same message in mailarch as discussed in section 2.7 of RFC6778.=20= >>=20 >> Please exercise the mailarch system. If you find issues, report them at=20= >> and choose the=20 >> "MailArchive: User Interface Component". Alternatively, you can send mail= =20 >> to mailarch-project@ietf.org.=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-77ADC1F4-9174-40E1-A239-EA401BC518B4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Yup.

Best regards,

        Henrik


On 26 Sep 2018, at 00:01, Russ Housley <housley@vigilsec.com> wrote:

Looks good to me.

Russ


On Sep 25, 2018, at 2:35 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

Here is a changed version capturing Russ' suggestion, and changing the email for reporting issues.
Is this ready to send?
Is now the right time to send it?

RjS

---
To: IETF Announce

Subject: Improvements to the mailarch tool, and plans to discontinue the mhonarc archives

There have been several improvements to the mailarch tool recently.

If you haven't already discovered it, please try out the new "Static Mode",
particularly if you frequently use the Mhonarc archives.

See, for example, <https://mailarchive.ietf.org/arch/browse/static/ietf/2018-09/>.

To get this view by default when browsing lists, set "Static Mode On" in the
Settings menu at top right of the page.

Also note that the speed of searching a list, and searching across multiple lists
has been significantly improved. The use of whitespace and fonts have also been
adjusted.

We are working towards a single copy of the archived mail list messages. Currently,
mailarch and IMAP work from the same files, but MonArch uses a separate set of files
in another format.

We plan to discontinue the use of Mhonarc soon, likely between IETF 103 and 104.
When we make that change, all exising URLs into the Mhonarc archives will redirect
to the same message in mailarch as discussed in section 2.7 of RFC6778.

Please exercise the mailarch system. If you find issues, report them at
<https://trac.tools.ietf.org/tools/ietfdb/newticket> and choose the
"MailArchive: User Interface Component". Alternatively, you can send mail
to mailarch-project@ietf.org.
_______________________________________________
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
--Apple-Mail-77ADC1F4-9174-40E1-A239-EA401BC518B4-- From nobody Fri Sep 28 07:11:38 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 081BB129BBF for ; Fri, 28 Sep 2018 07:11:36 -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 wHxc1gz7tQkE for ; Fri, 28 Sep 2018 07:11:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38C5128C65 for ; Fri, 28 Sep 2018 07:11:34 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8SEBWlW087437 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 28 Sep 2018 09:11:33 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: IETF Tools Development From: Robert Sparks Message-ID: Date: Fri, 28 Sep 2018 09:11:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [TOOLS-DEVELOPMENT] Where to report issues with the format tools (vs the format-related RFCs) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 14:11:36 -0000 All - On the 11-Sep tools call, we had a discussion about where to track issues with the rfc formatting tools being developed. I want to continue that conversation, and make some progress before we get to the 9-Oct tools call. Note that tracking issues with the new format RFCs and thier bis documents is a separate matter - those are being handled in github, with the bis-project for each associated draft. On the call, we talked about reusing and extending the existing xml2rfc trac instance, or extending the datatracker instance, and asked for other ideas. Alice pointed out that the RPC is already familiar with the xml2rfc trac instance that has been in place for several years. Given the RPCs (and at least some of the rest of the community's) familiarity with the existing xml2rfc trac instance, it seems natural to extend that instance to handle issues for the other format tools. We could also take this opportunity to move the xml2rfc trac instance from tools.ietf.org to a secretariat-hosted machine, probably trac.ietf.org. There is already exisiting confusion around where to report sofware issues. I think it's important minimize adding to that. Combining everything into one big tracking system isn't really feasible without some huge disruptions, Keeping separate trackers for each of the format tools is unappealing because it would add to the existing confusion around where to report issues. So, I think extending the xml2rfc trac instance (and possibly moving it to trac.ietf.org) is the right course of action. Other thoughts? Please weigh in soon. Again, I'd like to make progress on this before the next tools call, and I'd _really_ like to have the result in place before we get to IETF 103. RjS From nobody Fri Sep 28 08:36: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 98757130E3F for ; Fri, 28 Sep 2018 08:36:56 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 riPGGb18lYwV for ; Fri, 28 Sep 2018 08:36:54 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 9D1C6130E43 for ; Fri, 28 Sep 2018 08:36:53 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id p6-v6so6267442ljc.5 for ; Fri, 28 Sep 2018 08:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kpsTa/fPELtSN5kMzul5HWXzgngB3oVN8Fo+bVWgibE=; b=Ek0AAXUdzkO/l74HX0hBzUD4OqM938aL41erHG6ezCktCVttcyXbzniBMVZWSjzKPe DsuLMYCZGAtUfqQ2oRWKesR1msAXGFSE7SBC0MNugI+m3SN/f6co/MYNjPjr3RguCE74 xjD3U3cSNYOAJUqFLrm6yg7BFm9X7k+d5SkEwFkgBmx+pOACLPKw9ICZ4cqzzIhx58Ev UyaZt88OcmHxUK5LFOIFfcvOX6mThrLs2F3vb+PKTbqjM1tfHORTJU1tSbgETexKKrRo gTcY2UMadnWPL0MsKDlar3agJ/pg/5vpfTJ6+u76F31W4/zJz9gGOf92LI0WeFUg5G5M xgYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kpsTa/fPELtSN5kMzul5HWXzgngB3oVN8Fo+bVWgibE=; b=IstIsxBwlPZGQzskZa3xseo22szIP0mpzR+9UbAOtE0aUlxWsiavV9qGkdrao5TOQu JVnt7+hhSFh71JdVOeJyywq60wx5+yYseZ7ZEZk7vB67WIkNodrH9UwT6sqfOkvvPJxL 6beVa5fyw6GcRqxQmvDZK/L0FBvTdQMz/kCFGd07ejP1puCIBO0jhtpuMqNtHyR3pWfW ASMFX793ohKNAFpbNur+JI3Gs8KkRoS/Ww4fgxoNYuNEKQLcSVoXWgCBCVNmyR4NX8gx PBGqabKcWa7PpT5lHQH21jlHhbDDyWGTJgpZ01acLmJmvLGK0bVI1Qn8gHq6APzTwJwR lLEg== X-Gm-Message-State: ABuFfohJsN13LMPJBoE/7fHtZuJHJFf9XgOc20Jk+WIPFn+uIkGZDtOk px456tDhmlpv3caqLW8VlU9lbjzHdqAe0bMyToRpnauI X-Google-Smtp-Source: ACcGV62PXOtYm+G/kyQ4dzi4Q7ChlHx83fglcIqLR6dAUg80LHAKkFwQU/ueSDbzi8lYQc0f68tANxhYVYCK7/MrQ3c= X-Received: by 2002:a2e:5416:: with SMTP id i22-v6mr2362526ljb.159.1538149011716; Fri, 28 Sep 2018 08:36:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 28 Sep 2018 08:36:15 -0700 Message-ID: To: Robert Sparks Cc: tools-development@ietf.org Content-Type: multipart/alternative; boundary="000000000000748fb90576f039d1" Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Where to report issues with the format tools (vs the format-related RFCs) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 15:36:57 -0000 --000000000000748fb90576f039d1 Content-Type: text/plain; charset="UTF-8" How many of the tools themselves are being developed on Github? -Ekr On Fri, Sep 28, 2018 at 7:11 AM Robert Sparks wrote: > All - > > On the 11-Sep tools call, we had a discussion about where to track > issues with the rfc formatting tools being developed. I want to continue > that conversation, and make some progress before we get to the 9-Oct > tools call. Note that tracking issues with the new format RFCs and thier > bis documents is a separate matter - those are being handled in github, > with the bis-project for each associated draft. > > On the call, we talked about reusing and extending the existing xml2rfc > trac instance, or extending the datatracker instance, and asked for > other ideas. Alice pointed out that the RPC is already familiar with the > xml2rfc trac instance that has been in place for several years. Given > the RPCs (and at least some of the rest of the community's) familiarity > with the existing xml2rfc trac instance, it seems natural to extend that > instance to handle issues for the other format tools. We could also take > this opportunity to move the xml2rfc trac instance from tools.ietf.org > to a secretariat-hosted machine, probably trac.ietf.org. > > There is already exisiting confusion around where to report sofware > issues. I think it's important minimize adding to that. > > Combining everything into one big tracking system isn't really feasible > without some huge disruptions, > Keeping separate trackers for each of the format tools is unappealing > because it would add to the existing confusion around where to report > issues. > > So, I think extending the xml2rfc trac instance (and possibly moving it > to trac.ietf.org) is the right course of action. > > Other thoughts? Please weigh in soon. Again, I'd like to make progress > on this before the next tools call, and I'd _really_ like to have the > result in place before we get to IETF 103. > > RjS > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > --000000000000748fb90576f039d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How many of the tools themselves are being developed = on Github?

-Ekr


On Fri, Sep 28, 2018 at 7:11 AM Rob= ert Sparks <rj= sparks@nostrum.com> wrote:
A= ll -

On the 11-Sep tools call, we had a discussion about where to track
issues with the rfc formatting tools being developed. I want to continue that conversation, and make some progress before we get to the 9-Oct
tools call. Note that tracking issues with the new format RFCs and thier bis documents is a separate matter - those are being handled in github, with the bis-project for each associated draft.

On the call, we talked about reusing and extending the existing xml2rfc trac instance, or extending the datatracker instance, and asked for
other ideas. Alice pointed out that the RPC is already familiar with the xml2rfc trac instance that has been in place for several years. Given
the RPCs (and at least some of the rest of the community's) familiarity=
with the existing xml2rfc trac instance, it seems natural to extend that instance to handle issues for the other format tools. We could also take this opportunity to move the xml2rfc trac instance from tools.ietf.org
to a secretariat-hosted machine, probably trac.ietf.org.

There is already exisiting confusion around where to report sofware
issues. I think it's important minimize adding to that.

Combining everything into one big tracking system isn't really feasible=
without some huge disruptions,
Keeping separate trackers for each of the format tools is unappealing
because it would add to the existing confusion around where to report
issues.

So, I think extending the xml2rfc trac instance (and possibly moving it to tr= ac.ietf.org) is the right course of action.

Other thoughts? Please weigh in soon. Again, I'd like to make progress =
on this before the next tools call, and I'd _really_ like to have the <= br> result in place before we get to IETF 103.

RjS

_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVEL= OPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-d= evelopment
--000000000000748fb90576f039d1-- From nobody Fri Sep 28 08:55: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 30136130E94 for ; Fri, 28 Sep 2018 08:55:06 -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, HTML_MESSAGE=0.001, 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 yoJ-aHAF74UB for ; Fri, 28 Sep 2018 08:55:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDB6130E6B for ; Fri, 28 Sep 2018 08:55:02 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8SFt1hw004339 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Sep 2018 10:55:02 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: Eric Rescorla Cc: tools-development@ietf.org References: From: Robert Sparks Message-ID: Date: Fri, 28 Sep 2018 10:55:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------893EDCCE8A5FC31B0334AA52" Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Where to report issues with the format tools (vs the format-related RFCs) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 15:55:13 -0000 This is a multi-part message in MIME format. --------------893EDCCE8A5FC31B0334AA52 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit None, though I recall (perhaps incorrectly) that Jim was using Github for his own convenience early in the development of three of them. I am not finding links to github for them at this point. The authoritative source for those three (rfclint, svgcheck, and xmldiff) are here. https://trac.tools.ietf.org/tools/ietfdb/browser/#branch/hawk You can also find distribution here: https://pypi.org/project/rfc-xmldiff/ https://pypi.org/project/rfclint/ https://pypi.org/project/svgcheck/ The source for remainder (the formatters, idnits, and the text submission converter) are here: https://trac.tools.ietf.org/tools/ietfdb/browser/#branch/elft with these pypi links: https://pypi.org/project/id2xml/ https://pypi.org/project/xml2rfc/ (the rewrite of idnits is still coming: see https://trac.tools.ietf.org/tools/ietfdb/wiki/FormatToolsPlan) RjS On 9/28/18 10:36 AM, Eric Rescorla wrote: > How many of the tools themselves are being developed on Github? > > -Ekr > > > On Fri, Sep 28, 2018 at 7:11 AM Robert Sparks > wrote: > > All - > > On the 11-Sep tools call, we had a discussion about where to track > issues with the rfc formatting tools being developed. I want to > continue > that conversation, and make some progress before we get to the 9-Oct > tools call. Note that tracking issues with the new format RFCs and > thier > bis documents is a separate matter - those are being handled in > github, > with the bis-project for each associated draft. > > On the call, we talked about reusing and extending the existing > xml2rfc > trac instance, or extending the datatracker instance, and asked for > other ideas. Alice pointed out that the RPC is already familiar > with the > xml2rfc trac instance that has been in place for several years. Given > the RPCs (and at least some of the rest of the community's) > familiarity > with the existing xml2rfc trac instance, it seems natural to > extend that > instance to handle issues for the other format tools. We could > also take > this opportunity to move the xml2rfc trac instance from > tools.ietf.org > to a secretariat-hosted machine, probably trac.ietf.org > . > > There is already exisiting confusion around where to report sofware > issues. I think it's important minimize adding to that. > > Combining everything into one big tracking system isn't really > feasible > without some huge disruptions, > Keeping separate trackers for each of the format tools is unappealing > because it would add to the existing confusion around where to report > issues. > > So, I think extending the xml2rfc trac instance (and possibly > moving it > to trac.ietf.org ) is the right course of > action. > > Other thoughts? Please weigh in soon. Again, I'd like to make > progress > on this before the next tools call, and I'd _really_ like to have the > result in place before we get to IETF 103. > > RjS > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development > --------------893EDCCE8A5FC31B0334AA52 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit None, though I recall (perhaps incorrectly) that Jim was using Github for his own convenience early in the development of three of them. I am not finding links to github for them at this point.

The authoritative source for those three (rfclint, svgcheck, and xmldiff) are here.
https://trac.tools.ietf.org/tools/ietfdb/browser/#branch/hawk

You can also find distribution here:

https://pypi.org/project/rfc-xmldiff/

https://pypi.org/project/rfclint/

https://pypi.org/project/svgcheck/


The source for remainder (the formatters, idnits, and the text submission converter) are here:

https://trac.tools.ietf.org/tools/ietfdb/browser/#branch/elft

with these pypi links:

https://pypi.org/project/id2xml/
https://pypi.org/project/xml2rfc/
(the rewrite of idnits is still coming: see https://trac.tools.ietf.org/tools/ietfdb/wiki/FormatToolsPlan)

RjS


On 9/28/18 10:36 AM, Eric Rescorla wrote:
How many of the tools themselves are being developed on Github?

-Ekr


On Fri, Sep 28, 2018 at 7:11 AM Robert Sparks <rjsparks@nostrum.com> wrote:
All -

On the 11-Sep tools call, we had a discussion about where to track
issues with the rfc formatting tools being developed. I want to continue
that conversation, and make some progress before we get to the 9-Oct
tools call. Note that tracking issues with the new format RFCs and thier
bis documents is a separate matter - those are being handled in github,
with the bis-project for each associated draft.

On the call, we talked about reusing and extending the existing xml2rfc
trac instance, or extending the datatracker instance, and asked for
other ideas. Alice pointed out that the RPC is already familiar with the
xml2rfc trac instance that has been in place for several years. Given
the RPCs (and at least some of the rest of the community's) familiarity
with the existing xml2rfc trac instance, it seems natural to extend that
instance to handle issues for the other format tools. We could also take
this opportunity to move the xml2rfc trac instance from tools.ietf.org
to a secretariat-hosted machine, probably trac.ietf.org.

There is already exisiting confusion around where to report sofware
issues. I think it's important minimize adding to that.

Combining everything into one big tracking system isn't really feasible
without some huge disruptions,
Keeping separate trackers for each of the format tools is unappealing
because it would add to the existing confusion around where to report
issues.

So, I think extending the xml2rfc trac instance (and possibly moving it
to trac.ietf.org) is the right course of action.

Other thoughts? Please weigh in soon. Again, I'd like to make progress
on this before the next tools call, and I'd _really_ like to have the
result in place before we get to IETF 103.

RjS

_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development

--------------893EDCCE8A5FC31B0334AA52-- From nobody Fri Sep 28 16:12:13 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 C8C53130DBE for ; Fri, 28 Sep 2018 16:12:11 -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, HTML_MESSAGE=0.001, 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 GTmZSuOVr2ix for ; Fri, 28 Sep 2018 16:12:08 -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 B8702129C6B for ; Fri, 28 Sep 2018 16:12:08 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8SNC7pa074879 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Sep 2018 18:12:08 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local From: Robert Sparks To: Eric Rescorla Cc: tools-development@ietf.org References: Message-ID: <4d144615-e3b6-8647-4d3c-edaa3f8e3d28@nostrum.com> Date: Fri, 28 Sep 2018 18:12:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5224A037D41BFE8C2F8ED56F" Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Where to report issues with the format tools (vs the format-related RFCs) X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 23:12:12 -0000 This is a multi-part message in MIME format. --------------5224A037D41BFE8C2F8ED56F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I asked Jim - the github repository he's been using is at https://github.com/Com-AugustCellars/RfcEditor RjS On 9/28/18 10:55 AM, Robert Sparks wrote: > None, though I recall (perhaps incorrectly) that Jim was using Github > for his own convenience early in the development of three of them. I > am not finding links to github for them at this point. > > The authoritative source for those three (rfclint, svgcheck, and > xmldiff) are here. > https://trac.tools.ietf.org/tools/ietfdb/browser/#branch/hawk > > You can also find distribution here: > > https://pypi.org/project/rfc-xmldiff/ > > https://pypi.org/project/rfclint/ > > https://pypi.org/project/svgcheck/ > > > The source for remainder (the formatters, idnits, and the text > submission converter) are here: > > https://trac.tools.ietf.org/tools/ietfdb/browser/#branch/elft > > with these pypi links: > > https://pypi.org/project/id2xml/ > https://pypi.org/project/xml2rfc/ > (the rewrite of idnits is still coming: see > https://trac.tools.ietf.org/tools/ietfdb/wiki/FormatToolsPlan) > > RjS > > > On 9/28/18 10:36 AM, Eric Rescorla wrote: >> How many of the tools themselves are being developed on Github? >> >> -Ekr >> >> >> On Fri, Sep 28, 2018 at 7:11 AM Robert Sparks > > wrote: >> >> All - >> >> On the 11-Sep tools call, we had a discussion about where to track >> issues with the rfc formatting tools being developed. I want to >> continue >> that conversation, and make some progress before we get to the 9-Oct >> tools call. Note that tracking issues with the new format RFCs >> and thier >> bis documents is a separate matter - those are being handled in >> github, >> with the bis-project for each associated draft. >> >> On the call, we talked about reusing and extending the existing >> xml2rfc >> trac instance, or extending the datatracker instance, and asked for >> other ideas. Alice pointed out that the RPC is already familiar >> with the >> xml2rfc trac instance that has been in place for several years. >> Given >> the RPCs (and at least some of the rest of the community's) >> familiarity >> with the existing xml2rfc trac instance, it seems natural to >> extend that >> instance to handle issues for the other format tools. We could >> also take >> this opportunity to move the xml2rfc trac instance from >> tools.ietf.org >> to a secretariat-hosted machine, probably trac.ietf.org >> . >> >> There is already exisiting confusion around where to report sofware >> issues. I think it's important minimize adding to that. >> >> Combining everything into one big tracking system isn't really >> feasible >> without some huge disruptions, >> Keeping separate trackers for each of the format tools is >> unappealing >> because it would add to the existing confusion around where to >> report >> issues. >> >> So, I think extending the xml2rfc trac instance (and possibly >> moving it >> to trac.ietf.org ) is the right course of >> action. >> >> Other thoughts? Please weigh in soon. Again, I'd like to make >> progress >> on this before the next tools call, and I'd _really_ like to have >> the >> result in place before we get to IETF 103. >> >> RjS >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> > --------------5224A037D41BFE8C2F8ED56F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I asked Jim - the github repository he's been using is at

https://github.com/Com-AugustCellars/RfcEditor

RjS

On 9/28/18 10:55 AM, Robert Sparks wrote:
None, though I recall (perhaps incorrectly) that Jim was using Github for his own convenience early in the development of three of them. I am not finding links to github for them at this point.

The authoritative source for those three (rfclint, svgcheck, and xmldiff) are here.
https://trac.tools.ietf.org/tools/ietfdb/browser/#branch/hawk

You can also find distribution here:

https://pypi.org/project/rfc-xmldiff/

https://pypi.org/project/rfclint/

https://pypi.org/project/svgcheck/


The source for remainder (the formatters, idnits, and the text submission converter) are here:

https://trac.tools.ietf.org/tools/ietfdb/browser/#branch/elft

with these pypi links:

https://pypi.org/project/id2xml/
https://pypi.org/project/xml2rfc/
(the rewrite of idnits is still coming: see https://trac.tools.ietf.org/tools/ietfdb/wiki/FormatToolsPlan)

RjS


On 9/28/18 10:36 AM, Eric Rescorla wrote:
How many of the tools themselves are being developed on Github?

-Ekr


On Fri, Sep 28, 2018 at 7:11 AM Robert Sparks <rjsparks@nostrum.com> wrote:
All -

On the 11-Sep tools call, we had a discussion about where to track
issues with the rfc formatting tools being developed. I want to continue
that conversation, and make some progress before we get to the 9-Oct
tools call. Note that tracking issues with the new format RFCs and thier
bis documents is a separate matter - those are being handled in github,
with the bis-project for each associated draft.

On the call, we talked about reusing and extending the existing xml2rfc
trac instance, or extending the datatracker instance, and asked for
other ideas. Alice pointed out that the RPC is already familiar with the
xml2rfc trac instance that has been in place for several years. Given
the RPCs (and at least some of the rest of the community's) familiarity
with the existing xml2rfc trac instance, it seems natural to extend that
instance to handle issues for the other format tools. We could also take
this opportunity to move the xml2rfc trac instance from tools.ietf.org
to a secretariat-hosted machine, probably trac.ietf.org.

There is already exisiting confusion around where to report sofware
issues. I think it's important minimize adding to that.

Combining everything into one big tracking system isn't really feasible
without some huge disruptions,
Keeping separate trackers for each of the format tools is unappealing
because it would add to the existing confusion around where to report
issues.

So, I think extending the xml2rfc trac instance (and possibly moving it
to trac.ietf.org) is the right course of action.

Other thoughts? Please weigh in soon. Again, I'd like to make progress
on this before the next tools call, and I'd _really_ like to have the
result in place before we get to IETF 103.

RjS

_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development


--------------5224A037D41BFE8C2F8ED56F-- From nobody Sat Sep 29 13:30:36 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 5FD0E130E5C for ; Sat, 29 Sep 2018 13:30:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 7TLN-h8Sj90v for ; Sat, 29 Sep 2018 13:30:33 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 1A15012958B for ; Sat, 29 Sep 2018 13:30:33 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id r8-v6so8773965ljc.10 for ; Sat, 29 Sep 2018 13:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=r82qMUTWAjDqnZBI6z6Cfk9vei1w9BHOpoExWrA4ptI=; b=zp7TpHbjfenig77JpAayfIiEL7LPNl32IzJcbrizSQZK+NeKCdF8U46UHuDNgbZ1m7 lxiLyP2PCmjkM6fOJo9W9ikkMWZv5NA/d7Rk8SzgzeothDpCOROx+z/vrSngbCuqYo6r pw8XGkY+pAcp+RoVD79nhUjDy9viutAz5rh3YHBfLcEg+h2bX4WeIa7q2z+IS9knTD0a FDWXd59XfmWXgjtbtzUb+IbfFxgTNcJEZJvJgD13hImHVnRrboBwtxDHmfGvKPouNbn/ LP8oXLtsgF8j6FAuBjGJgBLvJri8sUawzG1swDxZ47MnNXsK/7RsHYx6fAHQgec7909k vq6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=r82qMUTWAjDqnZBI6z6Cfk9vei1w9BHOpoExWrA4ptI=; b=F6x3O1URlEdxuHjjyTavFtP64MfAhyulteQ5STZKgygtNddjr5GdDEyp9ITPjnmhRA HQ+MqMkI2D2NJr3mWNT38wEwaJrec7Ix4/9AvcBMRiDXUO2XXZkZwCl3U0/7hd25Va2R YiRgKpO4s7cHSjnLssgEUPeP9suzo3y1F6Yg6H5+U3T2BSjyFyy77sWwZ8SBRFsHF4i1 jUKvcITqUBv5kf7VyybpnZ8GnSv9u6fOeoSzCPEJhVvr6c6vxpCTPEP+PMpd9JBW1kvt z3sT+nxOaNxDI06ANGjV+lpXzORUYLdHx5PtwJ+a7efHBWtuEM0QoN116CYFTsR9Oal1 73Kw== X-Gm-Message-State: ABuFfohCo2fgyuO3iumRZo3W6FpZ/B1K46gMSOnkIPGhlMKoYTNYkCAN mVsflmwnerNSzMpQPjx3ERv7je3zcd3KYc1/tgzZRdJLYj8= X-Google-Smtp-Source: ACcGV62LgroYhRApjj/Bz9ey3ejlsiv8Sy8f4for8TC1cvTgKV79KEh9emRmrGGGvE4Fe5kc3nu2XVEGIqVhRAF+8QA= X-Received: by 2002:a2e:1b9c:: with SMTP id c28-v6mr2334443ljf.73.1538253030995; Sat, 29 Sep 2018 13:30:30 -0700 (PDT) MIME-Version: 1.0 From: Eric Rescorla Date: Sat, 29 Sep 2018 13:29:54 -0700 Message-ID: To: tools-development@ietf.org Content-Type: multipart/alternative; boundary="0000000000007cd02405770871b9" Archived-At: Subject: [TOOLS-DEVELOPMENT] Request for Tools Team to provide support for more flexible meeting grid X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2018 20:30:35 -0000 --0000000000007cd02405770871b9 Content-Type: text/plain; charset="UTF-8" Hi Folks, The Secretariat has asked for some changes to the agenda. Can you give us some sense of the level of effort/cost/timeline for this? The Secretariat develops the framework for each meeting, and that framework is imposed on all 8 parallel tracks. While this works for most sessions, there are occasionally groups that want to meet differently, e.g., ANRW, regext and rfcweb. Several hacks have been implemented so that these outlying sessions are captured within the overall agenda, however the solutions are acknowledged to be imperfect. As a result, there are several ongoing issues: - Attendees who rely on the Datatracker version of the agenda may miss these sessions, which are managed behind the scenes as a "non session event" (e.g., a beverage break), and which therefore do not appear with the other technical sessions (this happened with ANRW) - Attendees who rely exclusively on the mobile app version of the agenda may miss these sessions, which do not always render properly -Ekr --0000000000007cd02405770871b9 Content-Type: text/html; charset="UTF-8"
Hi Folks,

The Secretariat has asked for some changes to the agenda. Can you give us some sense of the level of effort/cost/timeline for this?

The Secretariat develops the framework for each meeting, and that framework is imposed on all 8 parallel tracks. While this works for most sessions, there are occasionally groups that want to meet differently, e.g., ANRW, regext and rfcweb. Several hacks have been implemented so that these outlying sessions are captured within the overall agenda, however the solutions are acknowledged to be imperfect. As a result, there are several ongoing issues:

- Attendees who rely on the Datatracker version of the agenda may miss these sessions, which are managed behind the scenes as a "non session event" (e.g., a beverage break), and which therefore do not appear with the other technical sessions (this happened with ANRW)
- Attendees who rely exclusively on the mobile app version of the agenda may miss these sessions, which do not always render properly

-Ekr

--0000000000007cd02405770871b9-- From nobody Sat Sep 29 15:54: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 5B947130E07 for ; Sat, 29 Sep 2018 15:54:39 -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 yQLSLnpT1e7F for ; Sat, 29 Sep 2018 15:54:36 -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 AF692130DFD for ; Sat, 29 Sep 2018 15:54:36 -0700 (PDT) Received: from [10.21.14.235] (205-168-105-98.dia.static.qwest.net [205.168.105.98]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8TMsZli006371 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 29 Sep 2018 17:54:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 205-168-105-98.dia.static.qwest.net [205.168.105.98] claimed to be [10.21.14.235] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Robert Sparks X-Mailer: iPhone Mail (16A366) In-Reply-To: Date: Sat, 29 Sep 2018 16:54:29 -0600 Cc: tools-development@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <06B5EC84-6A27-45B8-8581-D758F770A2F6@nostrum.com> References: To: Eric Rescorla Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Request for Tools Team to provide support for more flexible meeting grid X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2018 22:54:40 -0000 Hi Ekr - We had already been exploring options here with the secretariat, have a few i= nitial brainstorm ideas, and are planning to tackle this as part of a larger= contracted project to improve the scheduling tool next year.=20 One option thats looking feasible without a huge model change is to give eac= h room its own grid. That way not all rooms have to run on the same track. T= his will require less disruption than moving to a completely freeform calend= aring model, but will still require a big change to the way the agenda is sh= own, and the way external apps like the mobile app you mention handle the sc= hedule internally.=20 We=E2=80=99ll need to continue to brainstorm with the secretariat and build a= good description of the changes we want. It=E2=80=99s, of course, not feasi= ble to make a change like this before ietf103. I suspect the overall project= to improve the scheduling tool will go past 104, but getting a more flexibl= e grid (especially if a grid per room is good enough) before 104 is probably= doable as an early deliverable.=20 RjS Sent from my iPhone > On Sep 29, 2018, at 2:29 PM, Eric Rescorla wrote: >=20 > Hi Folks, >=20 > The Secretariat has asked for some changes to the agenda. Can you give us s= ome sense of the level of effort/cost/timeline for this? >=20 > The Secretariat develops the framework for each meeting, and that framewor= k is imposed on all 8 parallel tracks. While this works for most sessions, t= here are occasionally groups that want to meet differently, e.g., ANRW, rege= xt and rfcweb. Several hacks have been implemented so that these outlying se= ssions are captured within the overall agenda, however the solutions are ack= nowledged to be imperfect. As a result, there are several ongoing issues: >=20 > - Attendees who rely on the Datatracker version of the agenda may miss the= se sessions, which are managed behind the scenes as a "non session event" (e= .g., a beverage break), and which therefore do not appear with the other tec= hnical sessions (this happened with ANRW) > - Attendees who rely exclusively on the mobile app version of the agenda m= ay miss these sessions, which do not always render properly=20 >=20 > -Ekr >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Sat Sep 29 15:57:20 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 1DE10130DFD for ; Sat, 29 Sep 2018 15:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 zKKRvxn39LRr for ; Sat, 29 Sep 2018 15:57:16 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 F3B61128BAC for ; Sat, 29 Sep 2018 15:57:15 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id p34-v6so55376lfg.10 for ; Sat, 29 Sep 2018 15:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HX09Hgu/22QGA8dQJw4yJ9Zj4IROMNu7oFZVPr6dbOQ=; b=SJ9ajCzl4R+Lq6I6SaNNwHjyPJc5GCqg1ZMc0DhyuGzZZ04ZnBbNcNouJgykKlLrKS VJ3JuKCWzkK2NtU9Ggm8/V2K813zoep59FuGmH06iBi3/F/atikWj4cLXedJO5b4FUL4 SwUM/dBy7yznLgOwvhlbtUIzxhWmpOaOQD4chw697EnSFp7Umk6Bp7X388zOoCKa2SzP gVkedj0n7iIaSliyNJ4hP+9x9c7rUOMGpI+C0l5+azkbuwUWnQvKusrebAlMGKE/zmjr FMOA8aNCZtIAk7ifTrjja0xDvitaoWzLaINBTBI4VHSquYd9sArJzdTkh8NKYkIEmixf 0iNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HX09Hgu/22QGA8dQJw4yJ9Zj4IROMNu7oFZVPr6dbOQ=; b=KBebf4OO7RvSq4qtCu8OutBigKBVgWEBu47xp5Pyf3eXqbTzbRTDPaRPcj4XfsYSTZ kbcpvm/Fn4kaTjtx6rgl5AS24GbPKNb08m1sv35HEKc1PIFpv8Ymm5YicWObbOEuaKm6 9pZThv/DYQ03eD1O6CqM8hqHcP0mspVI1+8dX4W81sw4n4VWxuJgMBQmYsFs6ZxooPXc Nf4qYrW5YJiYqzFEipB96m25RO56V2SQvReHaejZZeqpOffYXziAVq1VzkRW3e585VWc ofm14mUBDMBtyKWNz8aUoVIGgoFpawA5fLVhmIVsyLBvAiIF9wLnGPe9P3Wndxy6TZZb LXZQ== X-Gm-Message-State: ABuFfoiMBVuk3P2NTP7TWrgH1G1z1pKInOB+ftVYiItahlWyZz3buHaH NByP8PMnidMMzttj4J1yYq+qhd1CnubxmalhJlPRbskA X-Google-Smtp-Source: ACcGV61RXR2PjhtaXUgMD5hzMmTEgL6Br9LddIup+bsn6icRBDRKSjUnVf95/8z2AeQ+dASBCm5SNUlhaROGLG453ao= X-Received: by 2002:a19:910c:: with SMTP id t12-v6mr2114838lfd.98.1538261834171; Sat, 29 Sep 2018 15:57:14 -0700 (PDT) MIME-Version: 1.0 References: <06B5EC84-6A27-45B8-8581-D758F770A2F6@nostrum.com> In-Reply-To: <06B5EC84-6A27-45B8-8581-D758F770A2F6@nostrum.com> From: Eric Rescorla Date: Sat, 29 Sep 2018 15:56:36 -0700 Message-ID: To: Robert Sparks Cc: tools-development@ietf.org Content-Type: multipart/alternative; boundary="00000000000032977e05770a7e8d" Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Request for Tools Team to provide support for more flexible meeting grid X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2018 22:57:19 -0000 --00000000000032977e05770a7e8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 29, 2018 at 3:54 PM Robert Sparks wrote: > Hi Ekr - > > We had already been exploring options here with the secretariat, Great., Alexa sent me the description I had, so I figured I better pass it along, but it's great to see you've already started. have a few initial brainstorm ideas, and are planning to tackle this as > part of a larger contracted project to improve the scheduling tool next > year. > > One option thats looking feasible without a huge model change is to give > each room its own grid. That way not all rooms have to run on the same > track. This will require less disruption than moving to a completely > freeform calendaring model, but will still require a big change to the wa= y > the agenda is shown, and the way external apps like the mobile app you > mention handle the schedule internally. > > We=E2=80=99ll need to continue to brainstorm with the secretariat and bui= ld a good > description of the changes we want. It=E2=80=99s, of course, not feasible= to make a > change like this before ietf103. I suspect the overall project to improve > the scheduling tool will go past 104, but getting a more flexible grid > (especially if a grid per room is good enough) before 104 is probably > doable as an early deliverable. > That sounds great. How do things look like from a resourcing perspective? Do you need IESG to help set priorities? something else? -Ekr > RjS > > > Sent from my iPhone > > > On Sep 29, 2018, at 2:29 PM, Eric Rescorla wrote: > > > > Hi Folks, > > > > The Secretariat has asked for some changes to the agenda. Can you give > us some sense of the level of effort/cost/timeline for this? > > > > The Secretariat develops the framework for each meeting, and that > framework is imposed on all 8 parallel tracks. While this works for most > sessions, there are occasionally groups that want to meet differently, > e.g., ANRW, regext and rfcweb. Several hacks have been implemented so tha= t > these outlying sessions are captured within the overall agenda, however t= he > solutions are acknowledged to be imperfect. As a result, there are severa= l > ongoing issues: > > > > - Attendees who rely on the Datatracker version of the agenda may miss > these sessions, which are managed behind the scenes as a "non session > event" (e.g., a beverage break), and which therefore do not appear with t= he > other technical sessions (this happened with ANRW) > > - Attendees who rely exclusively on the mobile app version of the agend= a > may miss these sessions, which do not always render properly > > > > -Ekr > > > > _______________________________________________ > > TOOLS-DEVELOPMENT mailing list > > TOOLS-DEVELOPMENT@ietf.org > > https://www.ietf.org/mailman/listinfo/tools-development > > --00000000000032977e05770a7e8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat= , Sep 29, 2018 at 3:54 PM Robert Sparks <rjsparks@nostrum.com> wrote:
Hi Ekr -

We had already been exploring options here with the secretariat,

Great., Alexa sent me the description I had, so I fi= gured I better pass it along, but it's great to see you've already = started.


= have a few initial brainstorm ideas, and are planning to tackle this as par= t of a larger contracted project to improve the scheduling tool next year. =

One option thats looking feasible without a huge model change is to give ea= ch room its own grid. That way not all rooms have to run on the same track.= This will require less disruption than moving to a completely freeform cal= endaring model, but will still require a big change to the way the agenda i= s shown, and the way external apps like the mobile app you mention handle t= he schedule internally.

We=E2=80=99ll need to continue to brainstorm with the secretariat and build= a good description of the changes we want. It=E2=80=99s, of course, not fe= asible to make a change like this before ietf103. I suspect the overall pro= ject to improve the scheduling tool will go past 104, but getting a more fl= exible grid (especially if a grid per room is good enough) before 104 is pr= obably doable as an early deliverable.

That sounds great. How do things look like from a resourcing perspective? = Do you need IESG to help set priorities? something else?

-Ekr


RjS


Sent from my iPhone

> On Sep 29, 2018, at 2:29 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Hi Folks,
>
> The Secretariat has asked for some changes to the agenda. Can you give= us some sense of the level of effort/cost/timeline for this?
>
> The Secretariat develops the framework for each meeting, and that fram= ework is imposed on all 8 parallel tracks. While this works for most=C2=A0 = sessions, there are occasionally groups that want to meet differently, e.g.= , ANRW, regext and rfcweb. Several hacks have been implemented so that thes= e outlying sessions are captured within the overall agenda, however the sol= utions are acknowledged to be imperfect. As a result, there are several ong= oing issues:
>
> - Attendees who rely on the Datatracker version of the agenda may miss= these sessions, which are managed behind the scenes as a "non session= event" (e.g., a beverage break), and which therefore do not appear wi= th the other technical sessions (this happened with ANRW)
> - Attendees who rely exclusively on the mobile app version of the agen= da may miss these sessions, which do not always render properly
>
> -Ekr
>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> TOOLS-= DEVELOPMENT@ietf.org
> https://www.ietf.org/mailman/listinfo/to= ols-development

--00000000000032977e05770a7e8d-- From nobody Sat Sep 29 16:13: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 5CCC1128BAC for ; Sat, 29 Sep 2018 16:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 JbhFYcct83D7 for ; Sat, 29 Sep 2018 16:13:08 -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 75F3F129385 for ; Sat, 29 Sep 2018 16:13:08 -0700 (PDT) Received: from [10.21.14.235] (205-168-105-98.dia.static.qwest.net [205.168.105.98]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8TND7up009313 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 29 Sep 2018 18:13:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 205-168-105-98.dia.static.qwest.net [205.168.105.98] claimed to be [10.21.14.235] Content-Type: multipart/alternative; boundary=Apple-Mail-A517DAC2-EF05-4A03-968C-EA5977C3CC6E Mime-Version: 1.0 (1.0) From: Robert Sparks X-Mailer: iPhone Mail (16A366) In-Reply-To: Date: Sat, 29 Sep 2018 17:13:01 -0600 Cc: tools-development@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <06B5EC84-6A27-45B8-8581-D758F770A2F6@nostrum.com> To: Eric Rescorla Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Request for Tools Team to provide support for more flexible meeting grid X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2018 23:13:12 -0000 --Apple-Mail-A517DAC2-EF05-4A03-968C-EA5977C3CC6E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Sep 29, 2018, at 4:56 PM, Eric Rescorla wrote: >=20 >=20 >=20 >> On Sat, Sep 29, 2018 at 3:54 PM Robert Sparks wrot= e: >> Hi Ekr - >>=20 >> We had already been exploring options here with the secretariat, >=20 > Great., Alexa sent me the description I had, so I figured I better pass it= along, but it's great to see you've already started. >=20 >=20 >> have a few initial brainstorm ideas, and are planning to tackle this as p= art of a larger contracted project to improve the scheduling tool next year.= =20 >>=20 >> One option thats looking feasible without a huge model change is to give e= ach room its own grid. That way not all rooms have to run on the same track.= This will require less disruption than moving to a completely freeform cale= ndaring model, but will still require a big change to the way the agenda is s= hown, and the way external apps like the mobile app you mention handle the s= chedule internally.=20 >>=20 >> We=E2=80=99ll need to continue to brainstorm with the secretariat and bui= ld a good description of the changes we want. It=E2=80=99s, of course, not f= easible to make a change like this before ietf103. I suspect the overall pro= ject to improve the scheduling tool will go past 104, but getting a more fle= xible grid (especially if a grid per room is good enough) before 104 is prob= ably doable as an early deliverable.=20 >=20 > That sounds great. How do things look like from a resourcing perspective? D= o you need IESG to help set priorities? something else? I expect we=E2=80=99ll be talking about the projects that are large enough t= o need funding, but have been backlogged behind the format tooling (which do= minated our budget this year) over the next couple of months. I expect prior= itization to fall out naturally, and the IESG will certainly be part of sett= ing that. I anticipate the scheduler will be very high, if not first, in the= list. The tools call in a couple of weeks would be good time to talk about i= t.=20 >=20 > -Ekr >=20 >>=20 >> RjS >>=20 >>=20 >> Sent from my iPhone >>=20 >> > On Sep 29, 2018, at 2:29 PM, Eric Rescorla wrote: >> >=20 >> > Hi Folks, >> >=20 >> > The Secretariat has asked for some changes to the agenda. Can you give u= s some sense of the level of effort/cost/timeline for this? >> >=20 >> > The Secretariat develops the framework for each meeting, and that frame= work is imposed on all 8 parallel tracks. While this works for most session= s, there are occasionally groups that want to meet differently, e.g., ANRW, r= egext and rfcweb. Several hacks have been implemented so that these outlying= sessions are captured within the overall agenda, however the solutions are a= cknowledged to be imperfect. As a result, there are several ongoing issues: >> >=20 >> > - Attendees who rely on the Datatracker version of the agenda may miss t= hese sessions, which are managed behind the scenes as a "non session event" (= e.g., a beverage break), and which therefore do not appear with the other te= chnical sessions (this happened with ANRW) >> > - Attendees who rely exclusively on the mobile app version of the agend= a may miss these sessions, which do not always render properly=20 >> >=20 >> > -Ekr >> >=20 >> > _______________________________________________ >> > TOOLS-DEVELOPMENT mailing list >> > TOOLS-DEVELOPMENT@ietf.org >> > https://www.ietf.org/mailman/listinfo/tools-development >>=20 --Apple-Mail-A517DAC2-EF05-4A03-968C-EA5977C3CC6E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent from my iPhone

On Sep 29, 2018, at 4:56= PM, Eric Rescorla <ekr@rtfm.com> w= rote:



On Sat, Sep 29, 2018 a= t 3:54 PM Robert Sparks <rjsparks= @nostrum.com> wrote:
Hi Ekr -<= br>
We had already been exploring options here with the secretariat,

Great., Alexa sent me the description I had, so I figu= red I better pass it along, but it's great to see you've already started.


have a few in= itial brainstorm ideas, and are planning to tackle this as part of a larger c= ontracted project to improve the scheduling tool next year.

One option thats looking feasible without a huge model change is to give eac= h room its own grid. That way not all rooms have to run on the same track. T= his will require less disruption than moving to a completely freeform calend= aring model, but will still require a big change to the way the agenda is sh= own, and the way external apps like the mobile app you mention handle the sc= hedule internally.

We=E2=80=99ll need to continue to brainstorm with the secretariat and build a= good description of the changes we want. It=E2=80=99s, of course, not feasi= ble to make a change like this before ietf103. I suspect the overall project= to improve the scheduling tool will go past 104, but getting a more flexibl= e grid (especially if a grid per room is good enough) before 104 is probably= doable as an early deliverable.

That s= ounds great. How do things look like from a resourcing perspective? Do you n= eed IESG to help set priorities? something else?

I expect we=E2=80=99ll be talking about the projects= that are large enough to need funding, but have been backlogged behind the f= ormat tooling (which dominated our budget this year) over the next couple of= months. I expect prioritization to fall out naturally, and the IESG will ce= rtainly be part of setting that. I anticipate the scheduler will be very hig= h, if not first, in the list. The tools call in a couple of weeks would be g= ood time to talk about it. 

-Ekr


RjS


Sent from my iPhone

> On Sep 29, 2018, at 2:29 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Hi Folks,
>
> The Secretariat has asked for some changes to the agenda. Can you give u= s some sense of the level of effort/cost/timeline for this?
>
> The Secretariat develops the framework for each meeting, and that frame= work is imposed on all 8 parallel tracks. While this works for most  se= ssions, there are occasionally groups that want to meet differently, e.g., A= NRW, regext and rfcweb. Several hacks have been implemented so that these ou= tlying sessions are captured within the overall agenda, however the solution= s are acknowledged to be imperfect. As a result, there are several ongoing i= ssues:
>
> - Attendees who rely on the Datatracker version of the agenda may miss t= hese sessions, which are managed behind the scenes as a "non session event" (= e.g., a beverage break), and which therefore do not appear with the other te= chnical sessions (this happened with ANRW)
> - Attendees who rely exclusively on the mobile app version of the agend= a may miss these sessions, which do not always render properly
>
> -Ekr
>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> TOOLS-D= EVELOPMENT@ietf.org
> https://www.ietf.org/mailman/listinfo/tool= s-development

= --Apple-Mail-A517DAC2-EF05-4A03-968C-EA5977C3CC6E-- From nobody Sat Sep 29 16:23:23 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 502AF129385 for ; Sat, 29 Sep 2018 16:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 vPK0ukcwKsUR for ; Sat, 29 Sep 2018 16:23:19 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 EA2AE128BAC for ; Sat, 29 Sep 2018 16:23:18 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id x16-v6so8890936ljd.12 for ; Sat, 29 Sep 2018 16:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3t46yRjegha9PXw5HtjwG6cZ8pOYA1lKVANgl6cJE9Q=; b=yf/TkF5rC6xFH7hgAHWZ2ufrTYcal7QV9B6FdxgVj2GKV+HnznlFmgdgIclFINtmIR VJdOvThFYG3nRe8sXnCMCH5T0C5DeLjJigAutiyOcQb8LEdAxIXkyXn91CTy+3ezT03b Dr+bqgH6CQEWAiVqceiodQ91hqHj9PTzSVO5PlQlF2AYIlCjA/9F721Qq0aR2j//aTYk hgnUcyJgHfBOeQ39fZ++c9fuDMbkkqgwlfbFWOKydq1FVKtLe1Zmpi6IMkimins2UXLN 5h3LMns7hIurPDoIi0/AhfkZM+rX99JWXXDgK/O0m8AXT1P/wBa7JB8ykvbYHf96KI1f PBJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3t46yRjegha9PXw5HtjwG6cZ8pOYA1lKVANgl6cJE9Q=; b=NDoMpSs81pqg/FIQbNfVuS9Az8u9YNd4t9yfd59IB4MQJxwoh1DKBOKCF+yKEn1GBW S1iq6tpYgHXu3T7u5ofVFpUzCPHL5nYkud683MkUjLHCImgEQigZ32FSWRWBpVlI1JjP E22pL5GLviI8R73BNPPmUqwQ75PcrOfyjiIpo8nvZFG4uXsXL5stqbx4wr97Hsz4x2Hy iMMnipMymhSe6PGSGptAIquFIXMBfQsYpVXN5D3YWEWAKkyHkfO413SQ6bycgb3gMzUU w1+iwScuH3P+TAXz6mJ29er9AshNBY45P4CkMHJK/RM8GXEZMd7caNIysROjlRuF+Sf2 yVCw== X-Gm-Message-State: ABuFfojeNXfT12ROX3fX8H4lusQi2nt83A/HJDQubxi1eL9Bz4QcC17a 5DAiWjiq/yomZoJS4UE8oi4szeOlPbA9RaRS6aEIoQ== X-Google-Smtp-Source: ACcGV61UeDe4iyZtA+WhJHfdehHaXF24y3YovIh5iojVom5FkMcbcp/UTV2EABShLHu6ASoJt313Ork/nASym7kb1ME= X-Received: by 2002:a2e:954e:: with SMTP id t14-v6mr2607087ljh.68.1538263397072; Sat, 29 Sep 2018 16:23:17 -0700 (PDT) MIME-Version: 1.0 References: <06B5EC84-6A27-45B8-8581-D758F770A2F6@nostrum.com> In-Reply-To: From: Eric Rescorla Date: Sat, 29 Sep 2018 16:22:40 -0700 Message-ID: To: Robert Sparks Cc: tools-development@ietf.org Content-Type: multipart/alternative; boundary="0000000000005a904005770adb32" Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Request for Tools Team to provide support for more flexible meeting grid X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2018 23:23:22 -0000 --0000000000005a904005770adb32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks! -Ekr On Sat, Sep 29, 2018 at 4:13 PM Robert Sparks wrote: > > > Sent from my iPhone > > On Sep 29, 2018, at 4:56 PM, Eric Rescorla wrote: > > > > On Sat, Sep 29, 2018 at 3:54 PM Robert Sparks > wrote: > >> Hi Ekr - >> >> We had already been exploring options here with the secretariat, > > > Great., Alexa sent me the description I had, so I figured I better pass i= t > along, but it's great to see you've already started. > > > have a few initial brainstorm ideas, and are planning to tackle this as >> part of a larger contracted project to improve the scheduling tool next >> year. >> >> One option thats looking feasible without a huge model change is to give >> each room its own grid. That way not all rooms have to run on the same >> track. This will require less disruption than moving to a completely >> freeform calendaring model, but will still require a big change to the w= ay >> the agenda is shown, and the way external apps like the mobile app you >> mention handle the schedule internally. >> >> We=E2=80=99ll need to continue to brainstorm with the secretariat and bu= ild a >> good description of the changes we want. It=E2=80=99s, of course, not fe= asible to >> make a change like this before ietf103. I suspect the overall project to >> improve the scheduling tool will go past 104, but getting a more flexibl= e >> grid (especially if a grid per room is good enough) before 104 is probab= ly >> doable as an early deliverable. >> > > That sounds great. How do things look like from a resourcing perspective? > Do you need IESG to help set priorities? something else? > > > I expect we=E2=80=99ll be talking about the projects that are large enoug= h to need > funding, but have been backlogged behind the format tooling (which > dominated our budget this year) over the next couple of months. I expect > prioritization to fall out naturally, and the IESG will certainly be part > of setting that. I anticipate the scheduler will be very high, if not > first, in the list. The tools call in a couple of weeks would be good tim= e > to talk about it. > > > -Ekr > > >> RjS >> >> >> Sent from my iPhone >> >> > On Sep 29, 2018, at 2:29 PM, Eric Rescorla wrote: >> > >> > Hi Folks, >> > >> > The Secretariat has asked for some changes to the agenda. Can you give >> us some sense of the level of effort/cost/timeline for this? >> > >> > The Secretariat develops the framework for each meeting, and that >> framework is imposed on all 8 parallel tracks. While this works for most >> sessions, there are occasionally groups that want to meet differently, >> e.g., ANRW, regext and rfcweb. Several hacks have been implemented so th= at >> these outlying sessions are captured within the overall agenda, however = the >> solutions are acknowledged to be imperfect. As a result, there are sever= al >> ongoing issues: >> > >> > - Attendees who rely on the Datatracker version of the agenda may miss >> these sessions, which are managed behind the scenes as a "non session >> event" (e.g., a beverage break), and which therefore do not appear with = the >> other technical sessions (this happened with ANRW) >> > - Attendees who rely exclusively on the mobile app version of the >> agenda may miss these sessions, which do not always render properly >> > >> > -Ekr >> > >> > _______________________________________________ >> > TOOLS-DEVELOPMENT mailing list >> > TOOLS-DEVELOPMENT@ietf.org >> > https://www.ietf.org/mailman/listinfo/tools-development >> >> --0000000000005a904005770adb32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks!

-Ekr

<= /div>

On Sat, Sep 29, = 2018 at 4:13 PM Robert Sparks <r= jsparks@nostrum.com> wrote:
=


Sent from my iPhone

On Sep 29, 20= 18, at 4:56 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Sat, Sep 29, 2018 at 3:54 PM Robert Sparks <rjsparks@nostrum.com> w= rote:
Hi Ekr -

We had already been exploring options here with the secretariat,

Great., Alexa sent me the description I had, so I fi= gured I better pass it along, but it's great to see you've already = started.


= have a few initial brainstorm ideas, and are planning to tackle this as par= t of a larger contracted project to improve the scheduling tool next year. =

One option thats looking feasible without a huge model change is to give ea= ch room its own grid. That way not all rooms have to run on the same track.= This will require less disruption than moving to a completely freeform cal= endaring model, but will still require a big change to the way the agenda i= s shown, and the way external apps like the mobile app you mention handle t= he schedule internally.

We=E2=80=99ll need to continue to brainstorm with the secretariat and build= a good description of the changes we want. It=E2=80=99s, of course, not fe= asible to make a change like this before ietf103. I suspect the overall pro= ject to improve the scheduling tool will go past 104, but getting a more fl= exible grid (especially if a grid per room is good enough) before 104 is pr= obably doable as an early deliverable.

That sounds great. How do things look like from a resourcing perspective? = Do you need IESG to help set priorities? something else?
<= /div>

I expect we=E2=80=99ll be talking about th= e projects that are large enough to need funding, but have been backlogged = behind the format tooling (which dominated our budget this year) over the n= ext couple of months. I expect prioritization to fall out naturally, and th= e IESG will certainly be part of setting that. I anticipate the scheduler w= ill be very high, if not first, in the list. The tools call in a couple of = weeks would be good time to talk about it.=C2=A0

<= /div>
-Ekr


RjS


Sent from my iPhone

> On Sep 29, 2018, at 2:29 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Hi Folks,
>
> The Secretariat has asked for some changes to the agenda. Can you give= us some sense of the level of effort/cost/timeline for this?
>
> The Secretariat develops the framework for each meeting, and that fram= ework is imposed on all 8 parallel tracks. While this works for most=C2=A0 = sessions, there are occasionally groups that want to meet differently, e.g.= , ANRW, regext and rfcweb. Several hacks have been implemented so that thes= e outlying sessions are captured within the overall agenda, however the sol= utions are acknowledged to be imperfect. As a result, there are several ong= oing issues:
>
> - Attendees who rely on the Datatracker version of the agenda may miss= these sessions, which are managed behind the scenes as a "non session= event" (e.g., a beverage break), and which therefore do not appear wi= th the other technical sessions (this happened with ANRW)
> - Attendees who rely exclusively on the mobile app version of the agen= da may miss these sessions, which do not always render properly
>
> -Ekr
>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> TOOLS-= DEVELOPMENT@ietf.org
> https://www.ietf.org/mailman/listinfo/to= ols-development

--0000000000005a904005770adb32-- From nobody Sun Sep 30 09:42:26 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 42EF41252B7 for ; Sun, 30 Sep 2018 09:42:25 -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 fyQbxxmqgnhs for ; Sun, 30 Sep 2018 09:42:23 -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 7482712426A for ; Sun, 30 Sep 2018 09:42:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8B653300A1E for ; Sun, 30 Sep 2018 12:42:20 -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 F87n7qo9_d3S for ; Sun, 30 Sep 2018 12:42:19 -0400 (EDT) Received: from new-host-3.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 8F60E3002C7 for ; Sun, 30 Sep 2018 12:42:19 -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.5 \(3445.9.1\)) Message-Id: <974A500B-0BC8-4FE9-8A99-FAC23C139F95@vigilsec.com> Date: Sun, 30 Sep 2018 12:42:20 -0400 To: IETF Tools Development X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TOOLS-DEVELOPMENT] Projects for 2019 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2018 16:42:25 -0000 This is the list of projects that came from a brainstorm session between = Robert and myself. Basically, we went through our notes and collected = the projects that were delayed since the RFC Format efforts consumed all = of this year's budget. Then, we divided the list into things that would = best be done by volunteers and things that would best be contracted. Volunteer Projects: 1 Improve GitHub tools for authors 2 WG tracking of reviews 3 Allow non-chairs to upload slides 4 WG chair agenda support Contract Projects: =09 1 Rework the meeting scheduler=09 2 Improvements to mail archive tool=09 3 Wagtail and IETF website maintenance=09 4 IANA expert review tracking =09 5 Security review of RFC Editor toolsprior to open source 6 EDU team materials =09 7 IRSG agenda and ballots =09 8 Meetecho customization for IETF=09 9 Requirement for document review assistance 10 Automatic agenda builder 11 Transition yangcatalog.org Thanks, Russ