From nobody Mon Apr 2 14:31:12 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9393912D95C for ; Mon, 2 Apr 2018 14:31:11 -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 pFVPRzqOfgoA for ; Mon, 2 Apr 2018 14:31:10 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 5D19C12D955 for ; Mon, 2 Apr 2018 14:31:10 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id l190-v6so14116698oig.9 for ; Mon, 02 Apr 2018 14:31:10 -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=gRkpZ4NSaQzb49ffvR6hT0DVkdJSQYuyITak+CAM1P4=; b=CjJTMViU/yb9f8Qz/7+w8jTvxPLsFx5XGbyaaYMiV+QR3YVQlFaDvEq58eLPb/eUsN J2UvQFRa9m1RQL/SAswqJnakApyNV7cJfk7Skjf6/quHVSKu7OhS9PC87UJM0ZmCueJ8 IDytW3BJa6FYr1fD8jMffzg6Zj5G3BPO4tFGhj6uViLqhkAknKsPUzVEJ0oIv3PoGlau WL80CGva0erqtn4S5avqal859uCF/UZE8ndRgUxqwQ6NN6dl9489kNXwOi5TVQaOyaj5 liBT8vWsfriUeEpVpEq23GP6xkh5r/Cu6mCsFo8x24ytzmkBfJuHjDEaDfNnfMZ4rWLb uN2g== 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=gRkpZ4NSaQzb49ffvR6hT0DVkdJSQYuyITak+CAM1P4=; b=sm5jd9jOAAeTht0oZ+RQmVqkXerTQARU0oQnZ5LmwdvEj+MHLKxVFPEhYWUYPxHL6b Bp5ZvR9UaaLCNs7TSBHfag3sd7prAtDKR+1TxWzMPGNZDsoN62fIBNEXUyo1UR4I35nW BZ14pt8naHcTUKLRGOhsIV6fYBhMRTYUyt4xXGCIqB0XqyXKJFqimZi9kUQQ6TSPJEYu vm5o1ytysFIkcY5swGc6jZioWbMF4MzFHUtDlZOFOuTGK1GaTWFJd0ZA67c4BXHf27PM puyaceTvi1Me1kASU6DlHFJLmAzwc4CSC9YRlgQloe9SLK0iNtLVEmk8nTzKNUR2ss2+ Wh+w== X-Gm-Message-State: ALQs6tBtZ6/zv+sqKinOSUN/5WDve43HvfO+1+INrVKE8UY73ee0tv5K 3iC+hqvGtcHVb1fms/EdEmX+ZELLqbf/zfXQP7cAo/LH X-Google-Smtp-Source: AIpwx4+e05DcvON/CWqCGDhK4sUXEG6AAVpDyGO0eEtAJAdKu03R+jP0oxdBXLwjYrkkWj92lB547HCVHG/Gt1kn6gU= X-Received: by 2002:aca:4f46:: with SMTP id d67-v6mr5825247oib.138.1522704669436; Mon, 02 Apr 2018 14:31:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Mon, 2 Apr 2018 14:30:28 -0700 (PDT) From: Eric Rescorla Date: Mon, 2 Apr 2018 14:30:28 -0700 Message-ID: To: tools-discuss Content-Type: multipart/alternative; boundary="000000000000eb85010568e44e60" Archived-At: Subject: [Tools-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 21:31:11 -0000 --000000000000eb85010568e44e60 Content-Type: text/plain; charset="UTF-8" I am seeing delays of seconds to 10s of seconds for simple tasks Any idea what's up? --000000000000eb85010568e44e60 Content-Type: text/html; charset="UTF-8"
I am seeing delays of seconds to 10s of seconds for simple tasks

Any idea what's up?
--000000000000eb85010568e44e60-- From nobody Mon Apr 2 14:34:15 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C791E12D95E for ; Mon, 2 Apr 2018 14:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 GQVy_dpMx2tc for ; Mon, 2 Apr 2018 14:34:11 -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 D63DD12D95C for ; Mon, 2 Apr 2018 14:34:11 -0700 (PDT) Received: from [10.0.2.15] (ip-14-232-239-173.texas.us.northamericancoax.com [173.239.232.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w32LYA5h088729 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 2 Apr 2018 16:34:11 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-14-232-239-173.texas.us.northamericancoax.com [173.239.232.14] claimed to be [10.0.2.15] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (15E216) In-Reply-To: Date: Mon, 2 Apr 2018 16:34:10 -0500 Cc: tools-discuss Content-Transfer-Encoding: quoted-printable Message-Id: <47C7E246-4742-44EE-9D51-9BA669C85311@nostrum.com> References: To: Eric Rescorla Archived-At: Subject: Re: [Tools-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 21:34:14 -0000 It's improved considerably from the 60 secondsand up that I was seeing last w= eek. :-) Ben. > On Apr 2, 2018, at 4:30 PM, Eric Rescorla wrote: >=20 > I am seeing delays of seconds to 10s of seconds for simple tasks >=20 > Any idea what's up? > ___________________________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss >=20 > Please report datatracker.ietf.org and mailarchive.ietf.org > bugs at http://tools.ietf.org/tools/ietfdb > or send email to datatracker-project@ietf.org >=20 > Please report tools.ietf.org bugs at > http://tools.ietf.org/tools/issues > or send email to webmaster@tools.ietf.org From nobody Mon Apr 2 14:49:22 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725A212D96C for ; Mon, 2 Apr 2018 14:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 k_LfNtcCNUKP for ; Mon, 2 Apr 2018 14:49:18 -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 6A0A51200A0 for ; Mon, 2 Apr 2018 14:49:18 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:62920 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f37KH-0001iK-KE; Mon, 02 Apr 2018 14:49:17 -0700 To: Eric Rescorla , tools-discuss References: From: Henrik Levkowetz Message-ID: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> Date: Mon, 2 Apr 2018 23:49:09 +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="92agsW5I1jgDqvATrEscSaQBHPP6skpuV" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.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-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 21:49:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --92agsW5I1jgDqvATrEscSaQBHPP6skpuV Content-Type: multipart/mixed; boundary="dtLHKvw2TLmkWJj1cM99Hl12o9OLRP4g2"; protected-headers="v1" From: Henrik Levkowetz To: Eric Rescorla , tools-discuss Message-ID: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> Subject: Re: [Tools-discuss] Datatracker is being very slow References: In-Reply-To: --dtLHKvw2TLmkWJj1cM99Hl12o9OLRP4g2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-04-02 23:30, Eric Rescorla wrote: > I am seeing delays of seconds to 10s of seconds for simple tasks >=20 > Any idea what's up? I had to do a number of reloads about an hour ago, and noticed that re-loading the login page directly after each apache reload was very slow. It seems reasonably fast now, though (~1s here). Are you still seeing slowness? For which URLs? Henrik --dtLHKvw2TLmkWJj1cM99Hl12o9OLRP4g2-- --92agsW5I1jgDqvATrEscSaQBHPP6skpuV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrCpVUACgkQTptXS4+7 FxrcGQ//Wx1QZpHa4jQ9Wnj2OYLcHZHXc7n8+tPiZe4F+yHCnYnY6k5CxQiU/A6t RjR/g4gpbxn0x/Si0MdW5rQoVCIwy8i+Q8vkJyzKK3qengfh43vFCMHveJWX95Wq AprqHcDpO4v2RuM0t0ZVjeDz7pW22NdYUztZrsI6t9ql4mj+W5Lgou83hm599zZ5 ZtSJFtKAzBmApAVyocPsjIPE87GbzMqHY2rsm/AfJ05dw/JWbs/ND9weR5jHlm4e bULGkIL27lNjb6OoeFRdXmZRdwJsM1LKQ5WJL2GajejC5TYYokdeEnAqQV9Ai7SW 8YAqz0DpD/q67snwq3FocyJoaVwxtCJrsDgsqpVGJFxtalxoka9WPxKfRC8kd4yb 1oHOgjHXzJWbNMbtKf7ElBpbPttsr6AnFHq2GiMCF0uG3heYe4Yre49ifKC1sIbd TmY7r1FI4+3+fh6Jeouzjfh91rtFDplfizQQjr10u8Hz4ahA3cmmZs597Z+YrFhw Fm4jzUXvhD5+ySnxcCYxS+BOVI6OKEzFFOWR+W/O6xlZ4q+jMwWZhNW6e3ZjWMaJ VLzgJ8/X17MoyQZirAiT3FuKT++1nmvvpaQp6fdFFRxCTinCfd4ocpvV4Bl6ah66 62VEzh7cv+mgm+RlNYx3NljO+8c4d9QhtJB1Dzp6ptCHXzKtg6I= =RNTJ -----END PGP SIGNATURE----- --92agsW5I1jgDqvATrEscSaQBHPP6skpuV-- From nobody Mon Apr 2 14:54:10 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8FA1200A0 for ; Mon, 2 Apr 2018 14:54:08 -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 ReKmaYgP84-Q for ; Mon, 2 Apr 2018 14:54:06 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 AD4EA12D963 for ; Mon, 2 Apr 2018 14:54:06 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id m7-v6so17229234otd.1 for ; Mon, 02 Apr 2018 14:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=41qzlFh+2rL++li6nfAM00wnAP5SeuF+mnHxs22b1Xs=; b=rhJNBCXdPOhSObIRly7upt0gC6KB2OBUjK96miniCekCYOCLxBG3jT+Qki/iO+Hl9O eCVyOeBvZRu8FIDfqWzN0hSAmDriQi1oyqGTDo6pHDokksywG8FDOkn86kUSVdGcSmgA MTUp2rwA1c33/dhubsY3IuaDuae7Mbw4vWBZkZCwXdY4MbvvgeA0Ob70Lj+5H/MXn5Oj /s/kPrxm1xolw9KiSuwpRUoOCQsbW1l/+mk4EPBCgIz1AAfEfehr9jdTwjc4ZlYCvoyf i2sZrOHWf03YnnQWSk+GdV8IKmc8i3Zh5Xk0r8v4LWvtxcUtNYlxRMyQkHMmcIMB5ZWz bX5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=41qzlFh+2rL++li6nfAM00wnAP5SeuF+mnHxs22b1Xs=; b=f2v80MMhf2P2/g/LD9um0YeJdUwMI7ZfupKefsvZaeZXywClEwrl9bQn0GIt8fpPma eZ+fFktlnOmfAHVazZzk8AHrbFqt5hIpkovE5rwyycy1rNZKrsyIuf9scRi2lT6Oirth Y30ZMqyezgxDHJtlASGxKRP7eOo5EGDzMIbhdQWxvDUOqnDB4/7rmJVWrH9mZGLWOTUm RDWnmKj3EXXv0fUBpAq3LM7qDRzFVsyK6LegqyDzZyB1C53Cwc51eqykGd2tb8tGUn1A WGHhSH0+jdY7NAlga28BPb6RiQfZj7qoKegLYvCqt+sRhJiRmiadDzgnKF0Z5dK0xLlQ rKiQ== X-Gm-Message-State: ALQs6tBgstvTCymq+qk7WZFm7M/5H/bFJKQCqkJIfJ32jVej0f0dyuC8 H0vP9Iiy5/KRHqU5UZSSL7zzHEbcCxxFi96f+5NN+GbZQQg= X-Google-Smtp-Source: AIpwx48zfgs/JBj9Yjq5+uL0AJSyTLm6Ie0vPOSxSCeOsNJLJw1bAcoh8I6s4ESVuo4oDozC5VY/IZHSU1cFLEJe+8s= X-Received: by 2002:a9d:4289:: with SMTP id r9-v6mr7021027ote.44.1522706046085; Mon, 02 Apr 2018 14:54:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Mon, 2 Apr 2018 14:53:25 -0700 (PDT) In-Reply-To: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> From: Eric Rescorla Date: Mon, 2 Apr 2018 14:53:25 -0700 Message-ID: To: Henrik Levkowetz Cc: tools-discuss Content-Type: multipart/alternative; boundary="000000000000f97e820568e4a054" Archived-At: Subject: Re: [Tools-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 21:54:09 -0000 --000000000000f97e820568e4a054 Content-Type: text/plain; charset="UTF-8" 5.5s wait time for: https://datatracker.ietf.org/iesg/agenda/documents/ On Mon, Apr 2, 2018 at 2:49 PM, Henrik Levkowetz wrote: > > On 2018-04-02 23:30, Eric Rescorla wrote: > > I am seeing delays of seconds to 10s of seconds for simple tasks > > > > Any idea what's up? > > I had to do a number of reloads about an hour ago, and noticed that > re-loading the login page directly after each apache reload was > very slow. It seems reasonably fast now, though (~1s here). Are > you still seeing slowness? For which URLs? > > > Henrik > > --000000000000f97e820568e4a054 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Apr 2, 2018 at 2:49 PM, Henrik Levkowetz <h= enrik@levkowetz.com> wrote:

On 2018-04-02 23:30, Eric Rescorla wrote:
> I am seeing delays of seconds to 10s of seconds for simple tasks
>
> Any idea what's up?

I had to do a number of reloads about an hour ago, and noticed that<= br> re-loading the login page directly after each apache reload was
very slow.=C2=A0 It seems reasonably fast now, though (~1s here).=C2=A0 Are=
you still seeing slowness?=C2=A0 For which URLs?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik


--000000000000f97e820568e4a054-- From nobody Mon Apr 2 15:07:25 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECA412DA08 for ; Mon, 2 Apr 2018 15:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, 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 FirnSHo4Y-y8 for ; Mon, 2 Apr 2018 15:07:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D774B12DA06 for ; Mon, 2 Apr 2018 15:07:21 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w32M7K3l094129 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 2 Apr 2018 17:07:21 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Eric Rescorla , Henrik Levkowetz Cc: tools-discuss References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> From: Adam Roach Message-ID: Date: Mon, 2 Apr 2018 17:07:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B615D932E50E4BC552295FB4" Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 22:07:24 -0000 This is a multi-part message in MIME format. --------------B615D932E50E4BC552295FB4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I can corroborate that I'm seeing 6s between request and response for this URL also. /a On 4/2/18 4:53 PM, Eric Rescorla wrote: > 5.5s wait time for: > https://datatracker.ietf.org/iesg/agenda/documents/ > > On Mon, Apr 2, 2018 at 2:49 PM, Henrik Levkowetz > wrote: > > > On 2018-04-02 23:30, Eric Rescorla wrote: > > I am seeing delays of seconds to 10s of seconds for simple tasks > > > > Any idea what's up? > > I had to do a number of reloads about an hour ago, and noticed that > re-loading the login page directly after each apache reload was > very slow.  It seems reasonably fast now, though (~1s here).  Are > you still seeing slowness?  For which URLs? > > >         Henrik > > > > > ___________________________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss > > Please report datatracker.ietf.org and mailarchive.ietf.org > bugs at http://tools.ietf.org/tools/ietfdb > or send email to datatracker-project@ietf.org > > Please report tools.ietf.org bugs at > http://tools.ietf.org/tools/issues > or send email to webmaster@tools.ietf.org --------------B615D932E50E4BC552295FB4 Content-Type: multipart/related; boundary="------------3DD3EA54554B78BCD2FFE4E2" --------------3DD3EA54554B78BCD2FFE4E2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I can corroborate that I'm seeing 6s between request and response for this URL also.



/a

On 4/2/18 4:53 PM, Eric Rescorla wrote:

On Mon, Apr 2, 2018 at 2:49 PM, Henrik Levkowetz <henrik@levkowetz.com> wrote:

On 2018-04-02 23:30, Eric Rescorla wrote:
> I am seeing delays of seconds to 10s of seconds for simple tasks
>
> Any idea what's up?

I had to do a number of reloads about an hour ago, and noticed that
re-loading the login page directly after each apache reload was
very slow.  It seems reasonably fast now, though (~1s here).  Are
you still seeing slowness?  For which URLs?


        Henrik




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

Please report datatracker.ietf.org and mailarchive.ietf.org
bugs at http://tools.ietf.org/tools/ietfdb
or send email to datatracker-project@ietf.org

Please report tools.ietf.org bugs at
http://tools.ietf.org/tools/issues
or send email to webmaster@tools.ietf.org


--------------3DD3EA54554B78BCD2FFE4E2 Content-Type: image/png; name="bpagdkgjjcdgghcl.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="bpagdkgjjcdgghcl.png" iVBORw0KGgoAAAANSUhEUgAAAgsAAABjCAYAAAAVZ0PQAAAYQGlDQ1BJQ0MgUHJvZmlsZQAA WIWVeQk4Vd/X/z7nTq55nud5nud5zjyPqbi4uGbXUIZSKoqSEAkVilAaREhCA0qmhCShlKlS SIZ4D6rv7/2+/+f/Pu9+nnPOx9prr/1ZZ5+91touAFzKhPDwYJgegJDQKLLDLkN+N/fd/LgJ AAMGwAIAwBB8IsMN7OysEAz+PP97+zEAoK3nS5ktW/+z///bGHyJkT4AQHYI9vaN9AlB8F0A 0Ko+4eQoZPo5RC60PyocwViEJWAmIwQRLLyF/Xew+hb23sFW2zpODkYI9gKAgppAIPsDQLvF iz/Gxx+xQ3sK6WMM9SWFIqqXEazrE0DwBYBzDNGRDgkJQzAXNYLFvf/Djv9/s+n91yaB4P8X 7/iy3SiMSZHhwYTY/+Pr+N9bSHD0nzmEkIs6gGzmsOXz1nsLCrPcwgh3qD3U28YWwYwI7if5 butv4Y8B0WbOv/V/+kQaIe8MsAIAU/sSjC0RzI1gweggZ4PfWJdA3h6L6MO74wKcXHfsw6Hk MIff9uG40GAbq992TgUQzf/gYmKkieMfHT+SqTmCkTWE60hR5k6/bbbHkFxsEEyL4JHIIEfL 32Nn4gKMbP7OFe2wxRlZcxQIifzjC0rYj2zqsKOPUg0gmdv8lltFBTiZ7YxF7fMhbHNgR3Ag MdLN6g8fX6KxyQ4fVBIx1Pk3T1RmeJShw2/9K+HBdr/1UY3E4F1bckEEd0XGOP4ZOx+FfGw7 vqBBIMHCbmdeNHN4lJ3TDjc0P7ACRsAY8INo5PIGYSAQkLrm7s2BPz2mgADIwB8QgcxvyZ8R rts9ocjdEcSBzwgigsi/4wy3e4kgBpH/+ivducsAv+3emO0RQeAjgkPQnGhdtBbaCrnrI5ci Wh2t8WccP92fWbEmWGOsGdYUK+FJSiL/yy4/8EE8CEYuMrBEnkTEqy0OoX+4/2MH8xHTi5nA vMKMYV4DF/AB0SP9Dw//sUb6K7MGY4hV09/eef+nd2hRhLUK2hCtg/BHuKNZ0ZxABq2MeGKA 1kN8U0Gk/7y1/xf36D+s8fJ4GM+G18eL/1uPVpJW5e+YLd/+k+cOL++/nhj97fn3bEb/4Zsv 8rT8tybqBKoa1YZqQXWgGlH3AD/qIaoO1Yl6sIX/fhsftr+NP7M5bPMJQuyQ/ujIV8pPy6// a27C7/nJ2+sPoogHorY2jlFYeCyZ5B8QxW+ARGsiv3moj6w0v6K8AhJFt2L/TmhZcNiO6RBr 9z+ysDsAaCKxGbb5R+aDA6AGiUMMlv/IhHmRrSEBwMNsn2hyzI4MvXXDAEpAh+wUDsCLxC5x xCNFoAq0gD4wARbAFjgBd7APec8BIARhvR8kgCMgGaSBDHAOXACXQAm4Bm6AO+AeaAQt4Cl4 DnrAK/AG+VYmwSyYBz/AGgRBOIgGYoI4ID5IBJKCFCF1SBcygawgB8gd8oL8oVAoGkqAjkJp UCZ0ASqCyqHbUD3UAnVAvdBraByahr5DqzAKpoaZYR5YFJaD1WED2BJ2gvfC/nAEHAcfg9Ph 83AxfB2uhVvg5/AreAyehZdQAEWFYkUJoGRQ6igjlC1qN8oPRUYdQqWiclDFqCpUA7LSL1Fj qDnUChqLZkLzo2WQ79UM7Yz2QUegD6FPoS+gr6Fr0Y/RL9Hj6Hn0BoYGw42RwmhizDFuGH/M fkwyJgdTiqnBPEH21CTmBxaLZcWKYdWQveqODcTGY09hC7E3sc3YXux77BIOh+PASeF0cLY4 Ai4Kl4zLw13HPcT14SZxPymoKPgoFClMKXZThFIkUeRQVFA0UfRRfKJYw9PjRfCaeFu8Lz4W fwZ/Bd+A78ZP4tcoGSjFKHUonSgDKY9QnqesonxCOUK5QEVFJUilQWVPRaI6THWe6hZVO9U4 1Qo1I7UktRH1Hupo6nTqMupm6tfUCzQ0NKI0+jS7aaJo0mnKaR7RjNL8pGWilaU1p/WlTaTN p62l7aP9QoenE6EzoNtHF0eXQ1dN1003R4+nF6U3oifQH6LPp6+nH6RfYmBiUGCwZQhhOMVQ wdDBMMWIYxRlNGH0ZTzGWML4iPE9E4pJiMmIyYfpKNMVpidMk8xYZjFmc+ZA5jTmG8xdzPMs jCzKLC4sB1jyWR6wjLGiWEVZzVmDWc+w3mEdYF1l42EzYCOynWSrYutjW2bnYtdnJ7Knst9k f8W+ysHPYcIRxHGW4x7HW040pySnPed+zoucTzjnuJi5tLh8uFK57nANc8PcktwO3PHcJdyd 3Es8vDy7eMJ58nge8czxsvLq8wbyZvM28U7zMfHp8pH4svke8s3ws/Ab8Afzn+d/zD8vwC1g JhAtUCTQJbAmKCboLJgkeFPwrRClkLqQn1C2UKvQvDCfsLVwgnCl8LAIXkRdJEAkV6RNZFlU TNRVNEX0nuiUGLuYuVicWKXYiDiNuJ54hHixeL8EVkJdIkiiUKJHEpZUkQyQzJfsloKlVKVI UoVSvdIYaQ3pUOli6UEZahkDmRiZSplxWVZZK9kk2XuyX+SE5XbLnZVrk9uQV5EPlr8i/0aB UcFCIUmhQeG7oqSij2K+Yr8SjZKpUqJSndI3ZSllovJF5SEVJhVrlRSVVpVfqmqqZNUq1Wk1 YTUvtQK1QXVmdTv1U+rtGhgNQ41EjUaNFU1VzSjNO5pftWS0grQqtKa0xbSJ2le03+sI6hB0 inTGdPl1vXQv647pCegR9Ir1JvSF9H31S/U/GUgYBBpcN/hiKG9INqwxXDbSNDpo1GyMMt5l nGrcZcJo4mxywWTUVNDU37TSdH6Xyq74Xc1mGDNLs7Nmg+Y85j7m5ebzFmoWBy0eW1JbOlpe sJywkrQiWzVYw9YW1lnWIzYiNqE292yBrbltlu1bOzG7CLv79lh7O/t8+48OCg4JDm2OTI6e jhWOP5wMnc44vXEWd452bnWhc9njUu6y7Grsmuk65ibndtDtuTunO8m9bjdut8vu0t1LHiYe 5zwm96jsSd4zsFds74G9Hfs49wXve+BJ50nwrPbCeLl6VXitE2wJxYQlb3PvAu95HyOfXJ9Z X33fbN9pog4xk/jJT8cv02/KX8c/y386QC8gJ2COZES6QPoWaBZ4KXA5yDaoLGgz2DX4ZghF iFdIfShjaFDo4zDesANhveFS4cnhYxGaEeci5smW5NJIKHJvZF0UM1Jkd0aLRx+PHo/RjcmP +bnfZX/1AYYDoQc6YyVjT8Z+ijONuxqPjveJb00QSDiSMH7Q4GDRIeiQ96HWRKHEY4mTh3cd vnaE8kjQkRdJ8kmZSYtHXY82HOM5dvjY++O7jlcm0yaTkwdTtFIunUCfIJ3oOql0Mu/kRqpv 6rM0+bSctPVTPqeenVY4ff70ZrpfetcZ1TMXM7AZoRkDZ/XOXstkyIzLfJ9lnVWbzZ+dmr14 zvNcR45yzqVcytzo3LHzVufr8oTzMvLWLwRceJVvmH+zgLvgZMFyoW9h30X9i1WXeC6lXVq9 TLo8VLSrqLZYtDinBFsSU/LxisuVtqvqV8tLOUvTSn+VhZaNXXO49rhcrby8grviTCVcGV05 fX3P9Z4bxjfqqmSqim6y3ky7BW5F35q57XV74I7lndZq9eqquyJ3C2qYalJrodrY2vl7AffG 6tzreust6lsbtBpq7sveL2sUaMx/wPLgTBNl07GmzYdxD5eaw5vnWvxb3rd6tr555Pao/7H9 464nlk/an5o+fdRm0PawXae9sUOzo/6Z+rN7z1Wf13aqdNa8UHlR06XaVdut1l3Xo9HT0Kvd 29Sn19fy0vjl037z/uevbF71DjgPDA3uGRwb8h2aeh38+ttwzPDam8MjmJHUt/Rvc0a5R4vf Sby7OaY69mDceLxzwnHizXuf97MfIj+sTx77SPMx5xPfp/IpxanGadPpnhmPmcnZ8Nm1ueTP DJ8Lvoh/uftV/2vnvNv85Dfyt83vpxY4FsoWlRdbl+yWRn+E/FhbTv3J8fPaivpK26rr6qe1 /eu49fO/JH41bFhujGyGbG6GE8iE7VIAhVywnx8A38sAoHEHgKkHAEqPnbPZ74ZCig94u5JW ByeRnG4D3YR54dMoGlQWWgzdjonCSmO/4JopSvAZlMepjlNn05TRDtJzMBAZq5khFnfW2+yU HO6c17i+8Ijx2vIF8scIxAomCp0UzhLJFy0WKxW/KnFV8rJUnnSGTIpsolysfIxCjGKC0gHl 3SpyqhjVt2o16ukaJE1TLWFtWHtCp1W3RO+4fqCBk6GukZQxhwneZN30665PZu/M31gMWQ5Y DVgP2Qza9tu9tO9z6HPsdxpyfuvywXXWbcF9wwO/h2Evwz56T3ovegKjN7MPuy83UdBP3F8+ QJNkHRgVVBj8OGQmjC5cOcKZHBOZFXUzuiNmYv9aLHOcdLxpgufB2ENZiTcOPz3yLunnMYbj ksmGKe4nyCdPp1amdZ76ns59xirj0Nm7mXPZYuc8c7Jyn5xfviCR715wovDexcnLjEV6xUEl p69cvdpUOlj2vZymQrLS7Lr/jZSq8pvPb329w1atd9evJq226l5X3VwDxX2BRvUHNk0uDx2a rVvMW40f6T/WfqL+VKlNrl2qg6dj/dnA85udyS88umS7Nru7ei70+vUpvgQvh/trX2UNhA/a Dsm/Zni9MDzwpmHk8tvk0ZB3TmNa4wITuIm59z0f7k6e/5jwae+U9jTX9MrMwGz13JnPQV9M vwp83Zzf+C624L54bmlkWfFn1srmWvT6wsb+zc3tipEFqRE9QT6YglSgk9Ac7Ab3ofYi9dNF jD2WCfsB94DiKj6fMoeqgPoRzSqdNn0iw2MmFLMeSzxrFds7DmZOJCtzp/CU8bbxTfB/Efgo 2C/0QPiqyCnRcDEbcTHxdYkuyQIpf2lF6RWZZtlkOWt5PvllhW7FUqV4ZSsVTpUPqpVq4eqK 6t81bmlGaulps2h/1+nXrdMr0E802GeobkRp1GucbmJgMm/6cNd1s0LzTItUyxSrFOtUmwzb 83aX7MscqhyvOMU727gIuvx0fel2171g92mPk3tO783bd8Oz3us24Zp3kU+ebybxlF+y/5GA BNL+wMig8ODQkODQwDBSOCmCRA6MDI4KQwrp6P2xBw7GJsWlxJ9OyD5YeKgssfpwy5GepImj S8fxybwpqifsTgalJqcVnXpw+nX6UgbjWblM66zA7KRz53LKcxvP9+ZNXlgrYCgUv6h3yfVy eNHJ4vKS9itTpfgyiWsW5UEVpypvXO++MX+T8Zbybec70dXn7lbX9NZ+rsPVCzRo3rdv9H4Q 0XT44Znm/Jay1tuPGh63IPGqq+1le3tH07O7z693lr643FXQnddzvje3L//ltf66V+0Drwdn htaGad7wjSi8NR51fUceyx1vnpj+wDSp9zH4U95U2/TSrPDcvs8VXynnj3/nWOhcuricupK+ dvVX5+/15wDaIALUQdRIDCiAlpH1f4LU1v1oMoYfM4NtxJVT1OBfUS5SM9PI0DrRxdEXMjQx vmNGs0iyWrL5s8dzJHLGc8Vxx/FE84bwefPbC2gJcgv+EGoVPiQiJzIqmiamLjYuniwhKfFU 0ltyXSpbWlq6TcZHFsgWyGnKvZIPV6BRKFc0VZxQSlIWUX6pclRVUXVc7ay6gfq8xiVNOy2g dUPbQwevU69L0uPS69Y/bqBjsGR40yjYWMp4xqTcNGCXOBInSs2JFiIWHyxLrAjWvNZvbS7a EuyE7WbsbzvEOZo4MTmNO99yOeRq7cblNuNev/uEh+sekT2Lex/vy/EM9NIjsBHmvZ/7lPkm E4l+xv7CAaiACVJL4OWgxOB9IRqhzKFfwzrDKyJSyUGR1lFy0UzRyzHD+xsPFMYmxO2OV01g SPh6cPjQq8Tewy+OPE9qP9p2rO14W3JbytMTj062pj5Kazv14vRA+tiZ2Yyls6uZa1krSHad zRnN7T7flFdzoSd/thB7UeiS3uU9RbFI3rx7pfPqROnqNZZypQqnygPXL954WjV7i/G2+h3P 6uS7VTUDtRt1YvUODYfuVzQONqEfKjUTWjJamx/NPWF+qtG2t/1QRwGS0Xo7v3dZdF/txfYF v3z9ynagc8ju9dsRvtG7448mydO9X54vaq9sbK3/zv/othpWFYCSDgBcFQCw4wSgcAE5Z84D QBeG/E0DgJMGgIUGAfRMB0D2s3/zBw6wAgmgi5wsg8BRJIpUg07wEQIQJ6QK2UIk5BR4EWqA BqFFmBFWgO3hSPgc3ACPofAoFZQvKhfVjaZAG6IPohvQqxgtzGFMG5Yeuxd7HbuBs8eV4tYp HCkq8DA+ED9CaUf5lEqPqp5ahbqaRommhlaTtpnOjK6b3o1+giGUYZXxBBMbUymzGnM7iwfL V9ZjbJxs99id2Bc4sjlVOV9zHeQW5O7gieDl4n3CF8EvxP9WIFfQSYhRqA/JWC6inKLvkJwV KqEmsSJ5WypQWkT6vcwVWT85KblF+YcK6YqeSsrK1MofVVpVL6sdVidoGGtKaNFp/UTq5x7d h3q39K8Y5BmeNTplnGKSZHpw136zcHN/iz2WdlbG1mo2krY8dgz2lA44R5wT3pnahdGVy03U XWm3kYfzHtLexH25nk1eX70FfJx8TxCb/BYDJEnegReC+kNoQ83DksMfRqxEqkXtj76/H3XA LrYobjnB/uDtRObDcUmoo9nHxZObTricnE87fVo2vScjOpM7a+XcTO5Y3mj+p8KVy+zF+lfC Souv3a14fP1V1adbP6spa3juydcb33d7EPzwaMvFRw+ejLdTPlPvDOoq6hl+KfAqbLB1mHMk ZnRoXO/99Y/cU1ozNLODn3O+WswvfM9YFFm6vaz6s3ZVYa3sF/dG+nb8YALSwBTJH7EgC9wA 7eA92IC4IDXIHgqGUqASqBkahTZgPuR8T4TT4DvwMAqDUkB5os6gWlCLaEk0EV2G/oxRwxzF 9GFFsYnYEZwurpSCgeIIxRI+BD+OnIafURlTPaY2p+6nIdL8or1Ap003SB/CABiyGMUZm5n2 MsPMt1hCWQ3Z+NiesodyMHPc5yRw4bhucDtyr/KU8NrwrvFV8h8VIAqaCUkJUwlPijSInhCz F2cVH5I4L0mWspOWk2GQWZIdlmuRr1A4p3hUiazso+Ksaq6mr66uoaApoyWpLaEjoSulJ6ev YqBjaGrkYLzPJNg0fleaWb55pUWj5QurUetvtmg7DntpB31HF6cQ52SXItcHbm/c1zy49+jt 9d2X6tngNe8t7uPtW0Ac9mcLcCXlBg4H84Z4h5aHfYtQIh+IbIrGxtjtzz8wFacWfyLhzSG5 xOOH3yapHs069j3ZMaXuJH9qWtrq6ZD0iQyPswNZHtlTOQfOU+ZdztcqGL548LJIUV/Jkasq pbPXWivyr0dV2dwSuwNVv6mpuZdRH3xf/wG66VlzZqvHY7Eni22tHVnP/V5odNP1fOwr6/ce 4B0cfp37xukt42jPWMaE/QfmyaFPudO6M0NzhM9DX3Xnc79NLPAu2i3F/yhYrv35YmVkdXrt +/rPX+sb2/ED0AMpYAZ8wCGQC26DDjAGliF6SBIyhbyhRGTvN0FjMAoWg62QnV8At8E/UJLI 6p9DdaEp0WboVHQPhgsThHmClcNexDHh0imYKIrxmvjXlHFUfFQd1HE08jSztJV0JHpe+iGG HEY3Jj6mGeZ6lrOsQWxm7GIcOI4pzk6uW9zZPAm8AXyu/JYCRoK6QjrCRiLWom5ivuIREomS 6VKF0pUyjbK9ctMKGEVhJVPlYJVc1Udq8xq8mlZacdrXdAb1sPpqBoGGRUZvTNhN3XYVmL23 UEaqjBEbRdsTdu8c1BwznT67WLvedufcneqxuTd+37pXNOGZj6BvHLEfqTNPk2aDLINvhDKF JYbPkl0iW6IlY7KQCpMY151gePBhouHhziSvo7+Ol6TYnfiZ6pc2cNosvSFD7uzVLJ7s3Bym 3DN5rBeKC2QL6y8ZXu4oti3pv+pW+uaab/mXyrgb2KqcW6K366ot747VxtTR1Jfc12rsbwpt xrdcfWT0eOJpUrtwx/Pn8S/kuqZ6SvsC+1UGsIMjr++8UR2pH9V8Vz+uMnHjg8BkxsfVKe/p tllJ5KyR8CX0q/W86PzMt5vf3RfghSuLKotPl5yX+n84/uhbtlh+8FPuZ/EK3UrsysSq1erd Nfa1g2vj6ybrZb8ofgX86tiQ3EjZmNw02izaWv9IPyXF7fQBURsixcTo5uaCKJIUMgH4dXZz c614c/NXCXLYGAGgOXjnd5/tXEMPQEH3Fmrznj38799f/gs0DuyMWDbu/QAAAZxpVFh0WE1M OmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8i IHg6eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRw Oi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0iaHR0cDov L25zLmFkb2JlLmNvbS9leGlmLzEuMC8iPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1lbnNp b24+NTIzPC9leGlmOlBpeGVsWERpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxZRGlt ZW5zaW9uPjk5PC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRp b24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiaaBnEAAC7ZSURBVHgB7Z1vSFtp++e/ v2WTN8mL5I3CGlmSF1MXVKgu1MJUf1hhqkW0nXZ8qM7gH9QMpgPWBzVs6vyqLmlLVbCROhar dOowHW1HkepT0LJOH1BhTUGFjX0RWRIX4otfXDh5k7zYve5zkhhjtHXGVm2vuyQ5f+5/53Ok 13Wu+z7391/+HyVwYgJMgAkwASbABJjAHgT+wx7H+TATYAJMgAkwASbABGQC7CzwHwITYAJM gAkwASawL4FDdxYkKQC/P4Dgvs1+wJOSF8vLa5AO2gSVmxr9B9wHLnjQhjg/E2ACTIAJMIGT RUBxFoKrsFwsxcWYT33HY3iihjOA0Xo6X/84xgjTMQsdszxTjkmr6KY8ZWXlqKgox6WLlRhf 9n90Gsu/2GC12t5t9H2rGB16BV/Yq5Hck+gb7se4O/DR+3wYDf6fgcOohetgAkyACTABJrCb QDSyEKJzhqx8XLlSjByjCt6F5zCX9cITW8b7HK2ja9EjkihEUQSRlgbuYdYL5NRa0WU3w4gt PCSj7frIIQa1SkO9SZL7tN9X0L+I4bEH8IUzaTNr8OTRECyZovynmSSfN+ocJbxCnxOtpYrT WNr6LMomYV4+yASYABNgAp8NgaizIIIIOeVmVFXV4KZjFO2FKXTkFUbnN3fAWB9uoafveA8g gKWlLUBXjMbSM0jLvABHvxWFhRcQb3rd47dQaunFQEcDRTIqsUwNS57XUSN18WIjZlzhp3tp HQOtldGIx80hZ3R4wzP/GOWRSEi5HUue+D4B7nHbduSDSk7dvIryjlcQUYRvmibpukKwXrqK UWov6PknLNWNmApHFvaqX+n/Awx1i/6TYS2l/obLSO5FDIhoxQ5ix2UniJk2C6qrBvfonx+O 6nasZJjR/6gTGSs/o96xurPzwQB8vgAkPw31uLzyvZB86/J2NAhFJSQPHaOhII+0+57srJD3 mAATYAJM4CQQiDoLorOhoAgVKCm78nsYaHNpRXEWJLIGupyvkKUCHl7vIoOjgj6SmVyCnDxy LrYmUVbagO6BZ5j3p8BiKUaqOppJ3gj6txBaf4WpQDoam39AsnoNreYuuDK+xf3+HjSc96On qVl2IpZ/uYWJFT3a+4dwv/krOMcGsUIjG5L7Gcydz8m7qYG9y4qswCLazPadURBqLUhGDV5y YuQUgm8zhC3XOgUeTsNSkk5HVShp+DuykzUIBrwUC9nCpnBe9qk/6N+k/r/EkroYdlsNDKF1 9Awtyi24p+5hYqyXHI7jaCTVKL3vwPnAJKrrEzgM0gbm6Soa6i4gNTkdVVdSEJpZjBl2Ii6u X1FdXY6yCgusTRZcKq9EGTlYYrus9ZXsPAgHrczcjL4+G0WmvsF4AidOhsVfTIAJMAEmcGII /Mc9e6pWkSmNS4YLuFlpxCVzP9ocL5EdkyGzrg9dp55hdPoVZid+lj9Q5aN//Aek7qhGGNIU tLd/j0xyJKTlxyDzTcMZG5ibocmRa8K4b+EPelov0gt3hKILfT+jIPc07j+qgYkOLY++ouMp aGkpluswtRejzDqJBSqTQWd2pu1OauUTtK81oKDgC/RMeJFbdAYmOi7FhAPcM++qXzhCF5BG 5rHAMIhh97psVDPrhtFfAqTGe0g7O/Tx9mgeSXmZjWjGJS85DJYUvHBciJ6QvE7KlwJTsnIo KTsLGIueVjZkx8+I+y96kLTUi7I2P/pf/AjtvB0VneuKs7BA0QjjZdg6igHfFrT6OG8xrkre ZQJMgAkwgeNPYKezQA5CJEmuRdmIZyTFDCSEAlCnXsD92n/i+sNB0HM7TXRQSvgo9KzJ/ho3 876WD7imbqGp7xUNKdSgKi2mDiU7PfbThmxHlGiGwZRCRlZDnyZk06lk2jZl9qD/1GtMk/Ee 7+vCMB2v7f9NNu60qRQXv+F+7456U7shimSIzHGuj5KXzkf7IWfa8RUxc4nqD4q4uzYSiQlz U4v+76jiaHe0X8DxaEC+RHH9GvUWhi2NmN4ywt6x7SiITmoNWZTjObwUuUkjh2FzzUlFyGGI T6p0eUaIWkPsaH6IcOfU+u05IgWNnXD13IO5giI/5Hw0UrSoQBshGV8Z7zMBJsAEmMBJIBAd hhBP3e75f9JYsxMzo/TUaBX/2aejrsi46zpMpVbURh7hhdEEvRlhbqSwcyPmaCzbR+PYriUR L1BRJCCBoxBTo9Z0Bjral8jsZOeeI9/jLY37v4Q/GMQczQvoHN1EoeVH3LZ9JZfa9IdgyhFG bAPDw6/h8axioEfpa16cU6KWn2pfYWRmFa75SYzL3k24cXnIZQNTdC7eyXjf+kVN8uWHq/TN D6K+vheu2IPhc0fzo4Y+OQnJ8kePlaFmxVF42oPM7TEkpWtaneykDY2KeSGbmBnfALLToURj Ynof8Y+EkxW7LWcJYnneCdO1u3jxuwM5dI8c029jCvMmE2ACTIAJnEQC0ciCeDZeofF2azj0 bMi6jMaW72BK+FCoQWn7HSxdaoFTdgY0qLz/A1w3enGXxq+VpEJh413khcPaETjqyFNmpF5t Ohz2b2Gx9qJiVsmVU9uJs8lqSEUX8EvTIMyXfpZPGM6bcY3eVtCC5irUbsL6sAvmCXEqBQ00 d0EMJ7jl+oUlA0wFNcgatmG6hz70fsb5LB1m3fIpaE1fIkc3iVkaW1cbRlCnVZwaFfVLm/au +pU6xLdegAtbVL/LCa93A26/GWmR69zOeuRbhrzvYS/PR+YuD0B0zYDGrhpUNLXj0jTtqs6g q/HM7j6HgyhyWGfXthpa9Qb6rHXoEyVVp2G/lr67Dj7CBJgAE2ACJ4rAvxy2NoQk+REKqaEh JyLiD7wvEbGgk5qMdny5IB0HhfjV8SfoGVii9ze1YUO/Vzui3nflSVz2/epPXPbjHhXrLPyn usNok952oMjIn+MVaT8ICgzR/dp1wyIZ+JcJMAEmwAROEIFDdxZO0LVzV5kAE2ACTIAJMIH3 IBCds/AeeTkLE2ACTIAJMAEm8BkSYGfhM7zpfMlMgAkwASbABA5CgJ2Fg9DivEyACTABJsAE PkMC7Cx8hjedL5kJMAEmwASYwEEIsLNwEFqclwkwASbABJjAZ0hgl7MgXn30k5KkslLB8SYi eZwYn3LuWBjpePeYe8cEmAATYAJM4OQR2HYWpDV015eirKwKFRXluESKkEPzsUseHoOL861i VKg6hj0Z90Q7Hva1Y+3YrJh4dIz+93+/cnSNc8tMgAkwASbwSRMIOwsBDNS3YJZ8g4wSM9qb v6X1/LYw1knLN5NWwHFJQf8ihsceRCWWM+tG8OTJCLITrkh4XHp9fPoh+Wgp7v1CRj5nVCq8 tPVZlPPxuQLuCRNgAkyACRwFAXm556D7FSZImtB4pRO3q5TleX8yaXCR1CWnKbqQV2SAZ/4x WkkWWlYw1J1B+20SfCJ1Rff4LdyYSUKJaRVjsxu0xK8Rjd2dKDABU60NmDLkw7TyXHZEVMav 0H37e5iEcQ96MdBmIwlqUaMK50mA6EbBKZmBZ24QrXcnlbYM1FZ7EzICL/FN06R83nrpKiq7 hpHtuofrw2rc/81Kje3VD1rGmdQXO5psWCBnSJdBKpOSE259DX4SYkruRfwyF0BJVT7iVqaW 2/p0voKYabPgoVSMRyM1Ca7VD0d1O1ayzOi3GDBQbUO94xTGLTHLNQcD8JHzqFH74SaVzrQ0 A4KkA+L2kwYIbUd8NolExdz+IPQmI1KP4bLXn8495SthAkyACXwcAnJkIShtyq0J2eZoInXJ Fy9+w21yFCT3M5jJUUAOaSaQBkNWYBFtZjs8lDno30Ro/SWW1MWw22pgCK2jZ2hRrsbn38L6 NJUraYOtNl/ONyQsNglPjd+wYMJlRPt9B+wN5zDb04IhFy017KK2yFHQnqe27E3I8lJb1T8j mHQalhJhuFQoafg7spM1ctsIeWUhqL37EcR4q3AUdLjS3Ikqwyac6yFsuZVrdk/dwwRpYky5 93vkli/nhH+pUUqszwdInrp+cHfUQNrAPF1hQ90FpCano+pKCkIzizvmg0iuX1FdXY6yCgus pAFyqbwSZdWN8nZZ6yt5not73IYyczP6SHPDXPYNxj2fOtcT/mfB3WcCTIAJvAcBObIQIIMv jLB+11r+ytr+bpKIFmJNLS3FyKRDpvZiUqWcxII7AEV8MgUWywWkkbkoMAxi2L1ORuaM8qSp I5GooizSe9DA+PAV3G6KJEhbmBailBQ7WJqjuv1rYgcTM+vIVittNViUtjKfnoKHnly1Wj2E M9Mz4UVuEUUHKL9LLhX7laAfwSS5Ld0VK6ryKHKR10lRknKMhYtl1g2jvwQkLf0J6hhQRKW8 zKZEaGIxeclhsKTghWNbplryOilfCkzh8EpSNil7RiBFysqIjLj/ogdJS6RM2uZH/4sfoZ23 o6JzXXEWFlYpRHUZto5iwLcFraz8GamAf5kAE2ACTOAkEpCdBX1yCvV9EUtuP6lERrSLvRh1 PIfq7GXZMIuLi5hTtVqRG4yVdg6KSYbaiGZxRI5QlFLerFCTJHTkrDgqJ4MRplQKZdOnOZuK i378oZyKtAWSTo70SGmPhhXEw2o0g5I/8r1nP3Y1Hi5BAlWpqZHSn9iv9gs4Hg3IuIQzqFFv YdjSqMhUiyGYmKQ1ZFGO5/DSMEMaOQyba04qIqTA45IqHUl0SK2h+6DSyPdGrRdHlFRAw0mu nnswVwjZ8BQ09veggIciInj4lwkwASZwIgnIwxDqtHzkUPdnO+voDYg1eNyrGGptxPD0K/g1 ephyhNHYwPDwa3g8qxjoEYYgHXlpiqxz7JXHvpgQux22WEpWbQqyhT9BGQzZZ3DWAEwPPMaS P7Td1sgiPL41OMq/oTc0BpVwODkcoh9TM6vy0ENsu/Hb0bbVX6DESDGMCTuGKKw+5WjGmJgm ER5g980Por6+F65ogfiaTvK+GvrkJCTLHz1WhpoVR+FpDzIjHljk8sgpI38NQ6NOulWbmBmn +SfZ6RFMkVyIenzCYYs4YNGRhiCW550wXbuLF7876G9qA47pt9tleYsJMAEmwAROJAE5skAm GzefdKKbxvbHOlvC0WcVChvvoEp2CGj+QO0mrA+7YJ4Q15mCBpq7IIYC3HFPjXrhBIQNsbId digoGiGfEl/0PFo3RMMBVTY0VYhhB5p4mFWDlrNJVJTaqqS2hu0wy2Fw0dZ3SpWmL5Gjm8Qs jYerDSMoimlbHbMt6tvuhxpF3Q74Orow1mNHRmExsnQbcJK0tUh+lxNe7wZNyDMjLa4OOcMn 9GXI+x728nxkhu/PzkszoLGrBhVN7bg0TWdUZ9DVeGZnFrEn3z/6FZGdXdtqaNUb6LPWoU/O exr2a+liixMTYAJMgAmcYAK7JKrFokwhMcNAq0kQ6Q9CIiOrpXOHlYJSQMS0sWu6BD3fHk5b Acx038Oc9hwslfTGQ3AVrTSOv3K+DS9uJAizH9aFfeR6xDoL//m/yd7VX2yZJplSlOWv3eMg ghRtUO++qX+xb1ycCTABJsAEjoLALmfhKDrxodsUQw3Vncprl3JbqtNo/+lHeqPiQ7fM9TMB JsAEmAATOPkEPgtnQblNAfh9NNmSohjJ+sOLjJz8PwG+AibABJgAE2AC+xP4jJyF/UHwWSbA BJgAE2ACTCAxAfltiMSn+CgTYAJMgAkwASbABAB2FvivgAkwASbABJgAE9iXADsL++Lhk0yA CTABJsAEmMDhOAv0+qPf73/nQkmMmwkwASbABJgAEzh5BORFmVxDDWga29jde8NlPP3pa0yX l2OcNBVG6uIX2PFjqsOGvoXtsjm1nbhZGp9vd9XvPOJbxejUJnJpEaHkPZZ2fmcdn1EGsc7C fulw1mDYrwU+xwSYABNgAp8qATmyoMnMRyGtbHjeqCzJZ8j6CiUl9CnMkldO3GslZP/Sz7Kj YJDVKNtQSMsqLzy0YfQQFByD/kUMjz3YrY74qd6JI72uAC3jTaIQe6ZNjHc3orS8F5Fb6557 gNKLpbhIn/qOyeh98i9Poj58/GL5Lcyz6uSeVPkEE2ACTOCkEJCdhdTsr0k1sgY3bvxN7ndO eQ3q6r5H3TsiBJ4lEhuCDg2NpBCZlgWLw4FKcjoMkWWAoxQCmHPYZMMiG5ebzxCxIR5aMCli dEotD2SNhqB7Et80iUWUQrBeuopRIV1Nxy5etEU1HNxTdtq/BRetFOgev4VSyyDGh24pbZQ2 YorKyElaxyjpTiz7owIG0V7xRpiA5xXM5ioMLCmy3Tu5rKP1Yh0ezq4jtLWmDDXRKpjX775E bnMPnvRbyUMcxMC8KLsJh3UQuNKGp78PoTb1DTr7/rmzOlqZ0+fzI0grhbqW1yDfFpJIF9u+ WK9U8mJ5eRVuT/g+xtXCu0yACTABJvDxCIS1IZQGpaDyH3NIFmx6d+zflHOOdKUnYS27iqzz F3D27BkUktOhjeu/tPwr7k6v4kq7A6X6t7h5vRcTK/mo05ORopUVsyrbUJejxihpUzTVJ9HQ xxlYStJJjnoNJQ1/p5UWaRElMjCAN6pHFfR55VbEssIgie3Q+hsMay+j3X4Oo2296GuyI+1F J5Lc/8DwxEsY9Gfw01WSqOa0m0BqMfqb12FuqwPaB1CXva0iKRS8chp7YDM5UXY9vAqmmmSq 7T0wZBrFwuCkLEJCoLIvRts6cZe2/3ZUSXELYElvcaM6VjZbRxITW2FNqtOy5LWeHMOy64PQ GVOwtb4BY60DjlLRCicmwASYABM4CgI7nIWDdkCbWYMnXV9gZPQl5mcn4aRPH0UamvuHkRcj +6wmRUORxgb6ESr4EnX3B5Bp0mN5QBGR8nveYIaMkluoQeJXrOFrFBR8Qc6CF7lFZ2TBKskn zu2XUtDe/h0yyU6dal9HmXUSc8sBVFEfH/V/DX1qjAHcr5rP5NzyQCWsEzLwHVc8QQ6Dof83 FKWGDb7WiNICEgh1vY7Jp4GJHAUhPz7eWocF5KM/T+GbV34aYyT0VRaWqbhij5u/Eq628v5v uJr0BqVldtT1j6NIv4iLZQ/gF9EF9yJ9GXGjpY0ckS0EtfESmTFd4U0mwASYABP44ATe31lQ 7RpbgERP934NDT/cJJEm6qrkmiTVwkH8MrOGvKrtp3i16Ws87T+FGZK8nhnvx8QwkNHgwLXw 5ZlSjUjVBJHa3EQjD2SIKDRBUWhK9FQqnlijD6oBBMKyyIrKpPw4G65lO5uaFC5FUrKqkcyO QpRRZCPtWg8elYQJaTSQVh5TlOcljFc6tx2FSOaEv0HM3CzHw5XT6Hr6A2TfUHLiet8blISj E8ujjbBa76HgxY/K+Wg9OpwyiJuqoX86GGSNDrGlpNSCH9Cw3Is2GhoR6XyjAzcK4iIUSlb+ ZgJMgAkwgY9A4L1fndxaW8Q8zVGYn1/E3JwTHhEJGLXgurkcA3M03kyOg9u1KhtoQ9rOJ0HP TC/qabghtbAG3betslHweLdgygmrPupTkJNL22svMTT+RhlqkIdCNjA1syqPk6tJ00GY/5GR V9TOIuVbj8EjDM8GehyvaKLeKhw9z2mf6hTy2r5FtJY3YjwyhyGm1Oe8qaan9eTkJPmjD9Ec hLCj4KiKiwQkhBTEXHcdemjKSq29BobAJs03IMctED+/QNyzTQR2+nRKjbHHYrfprG/ZCV/a 3/D7i9/QnAPMOl6K0RBOTIAJMAEmcEQEdkQWFIO8uydaetLHynN00ieSSuwjqKu8g0KXDRN3 WzARPmEs/AGNZ3eG/FNz8pE2ZKMnxXIllyEfXdfSSQY5HfZKL6w9LZiVz+jI+DRBftA0fYkc 3SRmKaStNozAQm9sVGZMYni6F9enaRz9PBm12cAOaWvf0gOYZ8XTsgolNqs8JCH517CytQ6V 149S4Txw2k1AkwJLYycN/eztKCh/G2F+NO/gl1llCOOh1YKHVKOqsBPjljOwlRjRSUMZkb+H wmYH0qKRod1NJzqiob+3GbrvY33irA6V9su75sEkKsfHmAATYAJM4MMQOBQhqSAtyhQIBaHS 6KHdxzAEaQJlMKgiJyE+UxASPTruPr77okVb0Gq2RyYoi7JOBND1ex/SKC4RVKt3nN9dy6d3 5Fits0D3WQQa1HH36aDUg1SJMtx00JKcnwkwASbABA6TwI7Iwp+tWDEK735qF0+nZMcTJDU5 CgkOJzgk2opPIqQeTZ+hoyCu/VgtukT3eZc/GL1B77/BjsL7s+KcTIAJMIEPSeBQIgsfsoNc NxNgAkyACTABJnC0BN57guPRdpNbZwJMgAkwASbABI6KADsLR0We22UCTIAJMAEmcEIIsLNw Qm4Ud5MJMAEmwASYwFERYGfhqMhzu0yACTABJsAETgiBOGeBXnnz++k1xrhVcg7hYny0YNOy WxEqkjxOjE85eaGdQ+DKVTABJsAEmAAT+NAEos6Ca6qXFBvLUVZRhbKyb1B+cxL7iRYfrGMB TJBIlJWEiMRKfO6Jdjzsa8caL8t3MIx/Ifd/Hf5ff6E0F2UCTIAJMIHPmYDiLPhpSeQ+EnWi lRVt9k40Fhqx5RxE62jsksp/BZMKerEso07RbMisG8GTJyPIfs+1Ff5Ky1z2fQkEaKns/dxD L4Zar4YlwG1Yeqew1/u2y/mYABNgAkzguBOQF2WSSE9BLJJc2FCDs5m06FHmHWiSB+E1KMZd 8rxG5/UurIhMpAbY2EVLA9PSye7xW7gxk4QS0yrGZjdozV86103nTFSHtIrupluY9YagyzoD vTAu4fWU3FP3cH1Yjfu/WYGp/evoaLJhgUSldBmkPklCRW59DX7quCArE/4yF0BJVb6yPLTo Gqc/T8BDcuHmwagIVHxFS92NGFuh5bkf1cDrsKCtfhBPx2PlyIOkDxKAnu6xm4abktNOQR/c hMvth950CskRx5AUwpZJXlSrN8KUGv6DiG+M95kAE2ACTOBYEZAjC1rTGVncadpajvqbvRid egND4fe4etZAqo9raDV3wZXxLe7396DhvB89Tc1YpiGEoH8TofWXWFIXw24jQaHQOnqGhLxw AENk5Ge9GlxpbkNV6ibWhaMRNhiiHEJeeUngvesIkvyxcBR0VEcnqgybcFIlW+F5D8LhmBjr xZT78OdXHKs79LE6k1qM/uZ8CInqgSVlbsl20wEs/RGCkZzJzGQDCqou0/17DXfsMBLpRdyo rsKlsio0WVtQcamS5Kfr5O3qslvwUGWSe5JkqC24M/BAFiCzjJMXyIkJMAEmwASOPQFluWcS dBp5cgejI88xM/8Kw076kIhPDokANeoXIQ9G+DcwNxOAf00ICG3hD3cABfLlkQiR5YKsyVBg GMSwe50mSCYp0YCSv6MqLx3IOwXPXDnGYo3LDjQJ6ggmYZoa1l2xUh0kd53XCc881REul1k3 jP4SIDU14frRO2rnncQElgcqYZ1QBKFicwiHwdD/27ZUtbSOOXL2CkzKstpqQxY5lzRsFZvC t6Hy/m+4mvSGHAU76vrHUUR/PxfLHsAv7r1bOJJG3Ghpg4H+hoKxy3TH1sXbTIAJMAEmcKwI KM6CtAm3X4+rFit9qH/SGm6WtWDhl0UEGuSxBxhMKWSYNfRpQjZlSRYh5CXlWoLCEGiVfELx MZK0qsi2EI+io3s6CxSl2KMOeXwkUmHsL+kPpKbGHuDtgxJIu9aDRyXKfVNrNJBWHsMclqou inXCtEbkUeVuGmYADT8FfWtk6hMlHU4ZhNegoX86GGT5ULGlpNSCH9Cw3Evqo1XygfONDtwo 4KGIMB7+YQJMgAkcWwLyMITkfobr1+tgGXgND7066XG/hVt02WBAcniIQoIe2bnn6InwLQaG XsKfIPof9QW0KcggP8E71o+ZZRqjnurCsIg4C4fhHSlah/oLkNoxtibsGJpZxJSjGWPCQoXr 8M0Por6+F65ogXdUzKd3ERACXMnJSfJHH1rF9bCj4KhKj8urwakswNkzCR+peq5Mi6hC1vY8 hNjcsX8XsduUx7fshC/tb/j9xW9oziGFccfL/fzH2Fp5mwkwASbABI6QgBxZ0GZ+R29AbKBn ogvmCaU3KuNXuN94RjbODvu3sFh7UTGrnMup7cRZemp0x0kL6kUgQTbmetTdt8JltqPHaqGx hBT56XIrPMMxVk0wdlvUvl2HGkXdDvg6ujDWY0dGYTGydBtwSsqTsN/lhNe7QRERM9Li+qH0 kr8PREBDQ0GNNDm1IN5RUGrJa+nETJkN1Rcn6YAKtV13DzyxVEN/GzN9NozREBf9UaDSfjni +ymN8DcTYAJMgAkcSwI7VSeDNCchEIRKRRLDCQywJAWgyFG//7UE6ekysSz1u+oIYKb7Hua0 52CppDcegqtoJWO1cr4NL27QYy6nAxEQ6yz8z8r/cqAyiTKLvwGQTLjsEybK8B7HgrToV7yT +B7FOAsTYAJMgAkcEYGdzsIRdWKvZsVQQ3WneJINJ9VptP/0I7LlsfDIQf5lAkyACTABJsAE PiSBY+0sKBdO0Q6aWBekCY3J4iV+TkyACTABJsAEmMBHJXACnIWPyoMbYwJMgAkwASbABOII RLUh4o7zLhNgAkyACTABJsAEZALsLPAfAhNgAkyACTABJrAvAXYW9sXDJ5kAE2ACTIAJMIFD cxYkjxPjU849FtkhbYGpScx76LU7TkyACTABJsAEmMCJIiAvyuQabUTTcBD2p33IpBfopeXH KLM+R2XXCK7S8r4gCevyCjtSGxy4XUTiUgmSe6IdD6dJqyF3nKSnNzEz+hpJucUkPETL/5K2 QFvfIHDeSGskJF70J0GVfOgQCfzb8P84xNq4KibABJjA50ng3yr/9bO8cDmyYMr+ki5+Awsk DiWS+w8h+EOr7c2LNZrJV3A7ZS2A3IwkeT/RV2bdCJ48GSFHQS4Bx/DP+MMfzklCVU+fDOEp OwqJ0PExJsAEmAAT+EQISD4vfHFL3e+4NP8qbpaW4uJF+pTfwpInktmLodaryvFSG5Z84VL0 sO2whI9fbMDosqIK7Bq1yXlLS6+itLwS5eV2uCJV7WjwcHZkZ0FtykIG1be0JJyDABbmN+Ta vQuLpAQAUnsUzsNpZJC4kGf+McrFRYoPXdCMK+xgkGR0RVUvyRaTCFVpi6z/NN30DVpH12SZ 6ztVVbgzRTKSJHl9s7QS3aOPYQnXY3G8jg5fLI/blbovVqKj+xa1VYlx2YkJYH50kLQm4uWT 5a7yFxNgAkyACTCBIyYQxEybBdVVg6Sjkyj54aiywZlhxpPfh9BgeoO21knZzi51N2JsJR32 Rw40ZKyirX5QtovLw42kwHwO9+mB20ZKy8PWX+W6DTnfwm7vRPvtTjTmabC1FWcbaUVmH61R JPlJn8nllduQfOvydqykkuShY8tr8NDKuvsleRgCSEEueQt9C28hXQ1higSbcgpPY2F6Ee7g 11ibpwNZ+UglQ9/a+Rwmko2uK9BhorMFPR3PkDPyHYJ+6ijJNkgkNXXVUowVEh1KKzHjWraI RmxgU5zzKo7FZmgLzuE3aGjvRHDuAQ1fdGGh5BxyQ5OwPlyELutbtFzVY4D0KIR21Ka4MvKu 7gxPIqTTIXfka4QVkfe7Nj7HBJgAE2ACTOAjElCj9L4D7m/IYagHHv1Us1NDh+zYTEiFhqsG zI88R+BsG57czCJ7RvP6/gjB2FBDQ/cGpFVdRt/1V/TwXQNTSQ/6K41Ipai9PoOmAUwodlSb egqZsvJyAI6mDRgq7yAtxjBKrl9RbY1ZAZlsJ3kUCouMH/D77Xx4x224/nBNaEaS1lIItf2/ oTRWcTiGXHiCoxoZuTSXwOvE0sIrsvmnUVn5HYxk5P+gqMIS1Z9TdIpEHk6h/VEPilL9WKCo Q2SUIaY+2tQgs+BLGZApNx+ZJv3O0+E9wxUzirLTUVqaLx9x+wNwz/2DtlPQcvNrZGbmo7vr 8nZZGsp4Qh7XkyF2FLah8BYTYAJMgAkcKQFpdTvaLqLllyyYFXqH3klUW4RN206Se5Xsawh9 1ntwhwIY6WtHRQep+JITMUdlssP2Um3IksUXRUltquIoSO5JVHQuIqf52x0OiG++F9NkrRtL yEbHJtlxMOL+i3E8bSc7u2VEP20/sZFA5Mq6HGlwL6wCxmLYbg+gv6sHefoYbyO2LtoORxZo YmKGMNq9uNtDmoI5VvJijCgS0Ya7vXRcB1saRQg8r3DJTPvGM6gsOg2NUJlMlIIhOXyy12lR RAoJmvRLoZI9U1xUREseFycmwASYABNgAseGgPYLOB4NyMZXKPJq1FsYttDQARlne8eFHd3U 0pC/Ds9RcH8AVSY1KnNU9DLBa3i0f0ce5XTTsAHopYKgb02OqkcKBz3/QNn1QWTU3sHNvFg7 6MUAORCGyp4dUYVIOajSIWL7ag29qEACkeLRXa3fnntYQErDrp57MFc8pzMpaOzvQUECEUlR XziyQFupXyBHHKFUUPSF/JtdSB6ISKozSKNWJD/NOaBUWP4tCrMNoKGQxCls5GemXr1zHCS2 AlOBALuBOx2PMT8/iev0RsZ2IiitDegYpzkQnJgAE2ACTIAJHAsCauiTk5Asf/RYGWpWHIWn PciMD6xrdRAjB0tzb8m5oKGHGYoqqAxkxDU4RWLKThq+99GZlWk6jiwk09BDkB7Sq8z9QEYN GgqS4PNshh0Ten6fGcSCHFUwJiahPJNTJXQ6dlvOHcTyvBOma3fx4ncH2f8NOKbfJq6HjkYj C6C5BkXndViY1SD3lHKFydlfkRe0CG3ROdkjQeZXKDH+g+YqWCjsoYNRODjhmRI7JIcpKlGe pUPfbD+uqw0Yr1ORv0XhFJUSa4jdVpNAlEjimDq1GP02P+7ceY5OmuhRUnIa3ok38nkEt7C0 sgGvagMojQu3KDn4mwkwASbABJjAkRIw5H0PezkNwctvBsZ3xYD2/h/wjdmGS2PinA619ssQ WfNaOjFTZkP1RTHPQIXarrvycMPy9DMlyrAyCHMZLUFAZexPh6l+eoDueQNj7R5RBcopG1bx K0YXFPMbs62GVr1BQyJ16BN5SNXZfi1dbCVMf05IKkhuinrvsY2ELb3HQeFBtd1ZRG5dDYoy k7BMky+sNPnC9mQUZ+M9tPeoj7NsE+B1FrZZ8BYTYAJM4M8SOJx1FugtBXrQVms1uybrSxIN RdBx4UB8nBSEYtL3t+l/zln4YFdAnlK9BRMxwxsZVzpxu2pvb+eDdYUrZgJMgAkwASbABGQC x8xZUO6KJPkRCISg0SRB+/HcK/6TYAJMgAkwASbABBIQOJbOQoJ+8iEmwASYABNgAkzgiAhs vw1xRB3gZpkAE2ACTIAJMIHjTYCdheN9f7h3TIAJMAEmwASOnAA7C0d+C7gDTIAJMAEmwASO N4GP7ixIHifGp5yR5RkS05G8mBr9B62Lnfg0H2UCTIAJMAEmwAQ+HgFlUabgKiyXbFDWZ1Qa N5CYk400GvbQlPjTPXRPtJNwFC0YmTselrPeXZVYA7tv+CXOnzqHG5nKok27c/ERJsAEmAAT YAIfl0DZ4r/uaPDpmf+xY/9T3VHehiBnoZ6cBZy/jEISsvAuPMP0ypasETF+M7zk82ERIC0I 0oyCXr+fExCEn9bI1iTrdy1YcVjd4HqYABNgAkyACRyUwEGdBZ/HC32qYU9btjx6C1ZSYRYp 60obblYJFUpK/lXaJjlrsUyz7jRJUVuRfdhP76Kd90zRYQgR8c8p+hupQBbDcrsPV0jNMrS0 Kg8XSJ7XaC0lNS2hqHWxETMusvZyCmBuwBY+Xor6jkl4wroQe5VxT91DRVUvSV974SinMg5n uC4/Lcik7Ac9/4SluhFTbmqHZLFvllaie/QxLHL7pbA4XkeHMZbH7eH2K9HRfYvUvyoxLsrR utvzo4OYWY7T+A63xj9MgAkwASbABD4sgXV0mC2oGojYuZ2tScsPZEehoWsIT7rMcI61Y0S2 X344hKOQYcaT34fQYHqDttbJqCaEXAs9ePvooVoikaZll1c+J/nW5e3YEXzJQ8eW1w6k07Sz l8peVBtCrH0UCAit6yRInjWsiU1DEtRkrG+Yu+ClYYn7dVlwkRfU09SMpKd9UE/bcHdiHedr 21CQvAprJ61dPWDEC9KCaN2rjJ+MN3lKUtCAs2d1mJ5+DrclCybPorxy4/k6I4KBSVoLewub 8hWHsBnagpM8r4b2TgTnHtAwRhcWSs4hNzRJy0EvQkd9a7mqx4C1V15DWy5Hkp93hicRIg3v 3BGWtVZuN38zASbABJjAxyNgRHd/E2lBtKMebfiJbGhscv9BglE5Zhj8ixilh/D2+0MkU01R d2kNMyEVGq4aMD/yHIGzbXhyMxxxCFcguX5FtVXoSIQT2TpsCcNNKeMH/H47H16STLhOkgkG 0nHyekOo7f8NpX8yOhF1FoTGxHRbHQlERVIKmm1fIUgdkucy+DcwN0NDCLIXsYU/3JvQjNMZ 3WVYSsVFZOHpo3z41XpIrmd7lAmgIFI9/WaXfE2NDmLJHYRq+SUdSUdpNolAuGIyhTcNV8wo yiYBKX0+Hs7+DDeNZRiWhFZ4ClpobkUmxW26u7y41BRWqtSm48kjB0L6vcM/u1vhI0yACTAB JsAE/jwBaXmQZKdjjHi4Ki/N12s1OHC7KCIxTaqTK/Tk7O3HneBXyA6RNtLYzyQTPY4cGoII 0b8+6z0UlmRhpq8dw/M/4EVH/nbH5LEKI+6/6EHSUi/K2vzof/EjtPN2VHSuy5EG98IqYLwM W0cx4NuCVr+//sN25bu3os6CGBY53+xAXdomWqvbsW7Ix1nyQIJ+cYaCDKYUpKZq6NOEbNpP pu15+cz23AOtXswxIC3usBZmojJYkgspX6lfolA1SG9HvIRvZR2q820w0ZnYEEoktxRS+iFR 6GXPFB4CiZzXJkduSuQI/zIBJsAEmAAT+HAEtGl/w6NHZJxFIlVlteSEhSLtW2S0G6OOgjip QXaGDmNSMYY6RPT7O2hLyzGz4kVBbhZpSz5Hwf0BVJnUqMxRkQPyGh7kyxLXorScVOk0FiCa ITus0sjq0Gq9OKKkgsZOuHruwVwhHqJTyBHpQYH2zzkMO+YsCGOvTc5CSy0JN3l/hmPeD63p DHVaGHA9snPPkZD1WwwMvYQ/SBeaJ8Iev5LHQ+Mhrlc0SbIcl2gOwt5lwlcQ/dGjpC4dWxRd mPYClVcPJhhlKrhANW3gTsdjzM9P4ro1HFWQ6ydRqtYGdIyvRVvjDSbABJgAE2ACH5QAOQjJ yUnKRx/AkHAUDJfxxPGdLDkd27beRA+0W/+Eyx+k4X8npuiZ2GCg6LpWJzsFS3Nv6eGbIhAz NFyhMsjOQGz58HM5ze2jo8rztLItZwpied4J07W7ePG7AzlkKx3Tb3cUP8hONLIQq9eUWmpG zrAFs539uPrCCof9W1hoPkDFrFJ1Tm0nzibTdt1d1Hqa8bCzBRPiFEUjusSYDFW2Vxl3nFeT mnsZhr5VeHXFyAuPpagJtkgq2QFSyTLcWpUixh09R+fVqcXot/lx585zdK6ko6TkNLwTyqxS BLcoxLMBr2oDKKXhC05MgAkwASbABD4qAR0KGppQXnRut6GnfqQWtaFxqQ7Wim/kXumyalAu LxegQXv/DzTXwYZLY+KUDrX2y7tlqxWzSMaQsuzaVkOr3qChjDr0iSpUp2G/drAHclEskg4k JCV0thPpb9OMRJqwqCKFyN3hjT3LRHrwF36DHhrjubOI3LoaFGUmYZkmc1hpMoftySjOknPG iQkwASbABJjAYRI46KuT79O2sJPC2u+2oWRbaVw+od19n4rlPEEEKfKgVu+2z+9dBWU8kLNw kIo/Tl4aaqi3yG9RRNrLuNKJ21V/3nuK1MO/TIAJMAEmwASYgELghDsLykVIkp9e+wxBo0ki z4xvLRNgAkyACTABJnCYBD4JZ+EwgXBdTIAJMAEmwASYwE4C0bchdh7mPSbABJgAE2ACTIAJ KAT+47//+/9lFkyACTABJsAEmAAT2JMARxb2RMMnmAATYAJMgAkwAUHg/wOQXd+sqOuIugAA AABJRU5ErkJggg== --------------3DD3EA54554B78BCD2FFE4E2-- --------------B615D932E50E4BC552295FB4-- From nobody Mon Apr 2 15:07:40 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C44512DA09 for ; Mon, 2 Apr 2018 15:07:39 -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 0DNrjYn3iblt for ; Mon, 2 Apr 2018 15:07:37 -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 A86BA12DA06 for ; Mon, 2 Apr 2018 15:07:37 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:62991 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f37c0-0004yl-QC; Mon, 02 Apr 2018 15:07:37 -0700 To: Eric Rescorla References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> Cc: tools-discuss From: Henrik Levkowetz Message-ID: Date: Tue, 3 Apr 2018 00:07:29 +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="tkvfvs8LvtPKPP2DQKj7R2iVVB3GSJAmF" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.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-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 22:07:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tkvfvs8LvtPKPP2DQKj7R2iVVB3GSJAmF Content-Type: multipart/mixed; boundary="LNgrCmURsEN0KONBbM0f0gopubQcdpIoO"; protected-headers="v1" From: Henrik Levkowetz To: Eric Rescorla Cc: tools-discuss Message-ID: Subject: Re: [Tools-discuss] Datatracker is being very slow References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> In-Reply-To: --LNgrCmURsEN0KONBbM0f0gopubQcdpIoO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-04-02 23:53, Eric Rescorla wrote: > 5.5s wait time for: > https://datatracker.ietf.org/iesg/agenda/documents/ Heh. Ok. That's probably the most complex page in the whole datatracker, and the rendering time is roughly proportional to the number of documents= on the page. With more than 50 documents on the page, it's probably heavier than usual. Ben Campbell pointed out at the end of last week that incremental changes= had brought it up to a response time of about 50s, so I worked during the= weekend to bring it down. Starting from 50s on Friday, I consider 5.5s today a good result. I'll look at caching it, but since parts of the content is individually rendered for each AD, too simple a cache won't work. Henrik > On Mon, Apr 2, 2018 at 2:49 PM, Henrik Levkowetz = > wrote: >=20 >> >> On 2018-04-02 23:30, Eric Rescorla wrote: >> > I am seeing delays of seconds to 10s of seconds for simple tasks >> > >> > Any idea what's up? >> >> I had to do a number of reloads about an hour ago, and noticed that >> re-loading the login page directly after each apache reload was >> very slow. It seems reasonably fast now, though (~1s here). Are >> you still seeing slowness? For which URLs? >> >> >> Henrik >> >> >=20 --LNgrCmURsEN0KONBbM0f0gopubQcdpIoO-- --tkvfvs8LvtPKPP2DQKj7R2iVVB3GSJAmF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrCqaEACgkQTptXS4+7 FxpEKBAAwDRO6vYDrQzGJsEkF1NVTo0LNJI2Bc/vwfwOwc/mtQ+9W71JwmOWsy0q cbVwVC9WgG2ZlOyZdPWHw+SRIFNt5Iwc9DEI+si44tZ+qytjv12ByfY2eLjlQa8x XgcCiRdbal8ZM1MXitz3a2D0JMc9WeBrP9/aT3Fbi56d/7SlGP5NUOKKqtAxA5L1 Klb7ohy6cJG63Ocvk76nymkhQabol216Pf1iFjMSpyCi+wj5xZAydVQ2q1bsn8N9 lkpW/7tSaJ9bhG2ERzuIyV8XwqM6t+yobaJj2/H8tcAo+5fxirlh07VH6uUxo87x 3EEpc69NXwCjU7UXcWWfZ55L0gmv4sFSYP2EejynjkUPdRJBtQGlSskRnPyzJbHw rwZZ96EAg4lCIBGmkY8tb4dZiQOjmsXUKLKfqMBhnZkZwjByJBltROdvR84I5DX6 Aoh4VZyhkK0tLHHjAVOWsioVcyc/m/+c5D4sl5rb6AMaSyW3o/mqIw+yo7yQDaFK 1ZUU394N8iQI0cKqSS8U7V6THaQ7TCwVTyG1VjDaL3P065uDCWLAZjM/HGkm8xuE FZCdKm+cKjzFoqOLTHUoxmiVqLl6L/jMlwkC/fCCapen8KMMxIaiTIIBD4y+rybS jaSjF0LRDLDqmbyXxCy2uJDHaRSMj831pPfSq7Gmfyecd7CZtpI= =lCz9 -----END PGP SIGNATURE----- --tkvfvs8LvtPKPP2DQKj7R2iVVB3GSJAmF-- From nobody Mon Apr 2 15:14:51 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7837E12DA43 for ; Mon, 2 Apr 2018 15:14:42 -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 gBHtC1QyOnGF for ; Mon, 2 Apr 2018 15:14:40 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 527B312DA08 for ; Mon, 2 Apr 2018 15:14:40 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id n40-v6so17245415otd.3 for ; Mon, 02 Apr 2018 15:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K77EdkVvx1uGhdN/0+/hlOnz8fOhIOPAC2FW8oEd2Sw=; b=F6qdH6JnTwhibgu9EpP+p3J3Sxg4ArVfjD8DIb18fwFZ7bts0mqhpqgYGXrxXyE5AV jx0n33MUHD1dV1HXBxAmS7RfuEifvm0Vy3CzWl2VCJ4A40qlF73e5Ud9V1zHDx4oDpub 2iRuQeYNsFGPu/QT0dhQOm6fSPAhT31rP159VWrGhCuwdUTKUSqcDVksmWyIM0J2CfbY lhO3lBquLYUXJ5Fkm3fs1lzT3ypAgpnMsmYLp01vQLDBUhcuyQNmxp6VIx50X5yfQoyy hFnFxwra9P+lIgLZEsWbDmCkL5ODhdj4lHg7GkCZfOjMuCGDEEsFVz18wICsYdJ9Kc8l QD3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K77EdkVvx1uGhdN/0+/hlOnz8fOhIOPAC2FW8oEd2Sw=; b=GrO02lY909UrucDz3UWztkrgb+Has5u9cpV9HLnC9EIcbhQbsFOP53GgC3vJKenhsz LIqbMO+ct8qHifVhqbOGgV0L8RAkFD8AXoH9+o6g79e1JL3xMJwFT59vK2CAOnFamyyg 8BOiGVIQciFr0k+MuG5CNtvzI3gE+xYvQQljzCJ/z44xB0E3AX2CYmP2YZrZbxr/RPqg yWBwVzzREPDKyEFhOqQKBEHJv9MlnHoURf/BFccGf4MQBh9LrrrsEepoNhezmDuNHQF9 2XhsvwZONQasXcRz5+Lr0u7s1Q2cojWY7azOrxGm/DS4k8FAQj+cNikrHLkuACuK78cR 1x9g== X-Gm-Message-State: ALQs6tAo6WeTT6qEJPZANhi5JvRSFRLx2sEli67zwu1WQyJvIzuQ8yKC jNRb3c2JgSg61RVJVI4K9CKHCm2Ni4B+WrhSGmEy5yFB X-Google-Smtp-Source: AIpwx4+EANnAeNncTv0j7zMpPFymftH08nkRdeF4nMqLL5y72jNvXUmEq/ZFsABgohI639koMKURwF/FZ2Fh8inGRTk= X-Received: by 2002:a9d:26d4:: with SMTP id i20-v6mr6181446otd.214.1522707279717; Mon, 02 Apr 2018 15:14:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Mon, 2 Apr 2018 15:13:59 -0700 (PDT) In-Reply-To: References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> From: Eric Rescorla Date: Mon, 2 Apr 2018 15:13:59 -0700 Message-ID: To: Henrik Levkowetz Cc: tools-discuss Content-Type: multipart/alternative; boundary="000000000000813aaa0568e4ea3d" Archived-At: Subject: Re: [Tools-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 22:14:42 -0000 --000000000000813aaa0568e4ea3d Content-Type: text/plain; charset="UTF-8" On Mon, Apr 2, 2018 at 3:07 PM, Henrik Levkowetz wrote: > > > On 2018-04-02 23:53, Eric Rescorla wrote: > > 5.5s wait time for: > > https://datatracker.ietf.org/iesg/agenda/documents/ > > Heh. Ok. That's probably the most complex page in the whole datatracker, > and the rendering time is roughly proportional to the number of documents > on the page. With more than 50 documents on the page, it's probably > heavier than usual. > It's not just this page. Searching for documents with "ice" takes 19+s and "trickle" takes 5+s. Ben Campbell pointed out at the end of last week that incremental changes > had brought it up to a response time of about 50s, so I worked during the > weekend to bring it down. Starting from 50s on Friday, I consider 5.5s > today a good result. > > I'll look at caching it, but since parts of the content is individually > rendered for each AD, too simple a cache won't work. > FWIW, the customary approach would be to have the server serve a JSON file consisting of the telechat status (this could be cached) and then have the client retrieve it with XHR and customize it there. -Ekr > > Henrik > > > > On Mon, Apr 2, 2018 at 2:49 PM, Henrik Levkowetz > > wrote: > > > >> > >> On 2018-04-02 23:30, Eric Rescorla wrote: > >> > I am seeing delays of seconds to 10s of seconds for simple tasks > >> > > >> > Any idea what's up? > >> > >> I had to do a number of reloads about an hour ago, and noticed that > >> re-loading the login page directly after each apache reload was > >> very slow. It seems reasonably fast now, though (~1s here). Are > >> you still seeing slowness? For which URLs? > >> > >> > >> Henrik > >> > >> > > > > --000000000000813aaa0568e4ea3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 2, 2018 at 3:07 PM, Henrik Levkowetz <= henrik@levkowetz.= com> wrote:


On 2018-04-02 23:53, Eric Rescorla wrote:
> 5.5s wait time for:
> https://datatracker.ietf.org/iesg/agend= a/documents/

Heh. Ok. That's probably the most complex page in the whole data= tracker,
and the rendering time is roughly proportional to the number of documents on the page.=C2=A0 With more than 50 documents on the page, it's probab= ly
heavier than usual.
=C2=A0
It's not just= this page. Searching for documents with "ice" takes 19+s and
"trickle" takes 5+s.


Ben Campbell pointed out at the end of last week that incremental changes had brought it up to a response time of about 50s, so I worked during the weekend to bring it down.=C2=A0 Starting from 50s on Friday, I consider 5.5= s
today a good result.

I'll look at caching it, but since parts of the content is individually=
rendered for each AD, too simple a cache won't work.

FWIW, the customary approach would be to have the server = serve a JSON file
consisting of the telechat status (this could b= e cached) and then have the
client retrieve it with XHR and custo= mize it there.

-Ekr



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik


> On Mon, Apr 2, 2018 at 2:49 PM, Henrik Levkowetz <henrik@levkowetz.com>
> wrote:
>
>>
>> On 2018-04-02 23:30, Eric Rescorla wrote:
>> > I am seeing delays of seconds to 10s of seconds for simple ta= sks
>> >
>> > Any idea what's up?
>>
>> I had to do a number of reloads about an hour ago, and noticed tha= t
>> re-loading the login page directly after each apache reload was >> very slow.=C2=A0 It seems reasonably fast now, though (~1s here).= =C2=A0 Are
>> you still seeing slowness?=C2=A0 For which URLs?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>>
>>
>


--000000000000813aaa0568e4ea3d-- From nobody Mon Apr 2 15:22:54 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F0112DA06 for ; Mon, 2 Apr 2018 15:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 NT-MbL3QOrn0 for ; Mon, 2 Apr 2018 15:22:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D2F1241FC for ; Mon, 2 Apr 2018 15:22:50 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w32MMmxT096710 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 2 Apr 2018 17:22:48 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Henrik Levkowetz , Eric Rescorla Cc: tools-discuss References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> From: Adam Roach Message-ID: Date: Mon, 2 Apr 2018 17:22:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 22:22:52 -0000 On 4/2/18 5:07 PM, Henrik Levkowetz wrote: > > On 2018-04-02 23:53, Eric Rescorla wrote: >> 5.5s wait time for: >> https://datatracker.ietf.org/iesg/agenda/documents/ > Heh. Ok. That's probably the most complex page in the whole datatracker, > and the rendering time is roughly proportional to the number of documents > on the page. With more than 50 documents on the page, it's probably > heavier than usual. The ">100ms per document" seems in line with the fact that this very simple endpoint that just returns 20 documents is running about 2.5s for me: https://datatracker.ietf.org/api/v1/doc/document/ 100ms per document seems like a surprising amount of processing time. Do you know where in the technology stack this is coming from? Like, would selecting 20 documents out of the database from the commandline take this long? Or is it being introduced by Django? Apache? I'm hesitant to rely on caching too much; as you say, there's significant per-AD information here. /a From nobody Mon Apr 2 15:52:12 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4E412DA16 for ; Mon, 2 Apr 2018 15:52:12 -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 USWAck9DAw8C for ; Mon, 2 Apr 2018 15:52:10 -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 079831252BA for ; Mon, 2 Apr 2018 15:52:10 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:63231 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f38J6-0007Q0-2D; Mon, 02 Apr 2018 15:52:09 -0700 To: Adam Roach , Eric Rescorla References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> Cc: tools-discuss From: Henrik Levkowetz Message-ID: <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> Date: Tue, 3 Apr 2018 00:51:59 +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="ILs6vJoRQ53dF8dFwaC8VSs8ag72q5kR7" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.com, adam@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-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 22:52:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ILs6vJoRQ53dF8dFwaC8VSs8ag72q5kR7 Content-Type: multipart/mixed; boundary="IgpAtn2Bqhp8j0CE8C4Jlp8CCv6CX4DKw"; protected-headers="v1" From: Henrik Levkowetz To: Adam Roach , Eric Rescorla Cc: tools-discuss Message-ID: <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> Subject: Re: [Tools-discuss] Datatracker is being very slow References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> In-Reply-To: --IgpAtn2Bqhp8j0CE8C4Jlp8CCv6CX4DKw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Adam, On 2018-04-03 00:22, Adam Roach wrote: > On 4/2/18 5:07 PM, Henrik Levkowetz wrote: >> >> On 2018-04-02 23:53, Eric Rescorla wrote: >>> 5.5s wait time for: >>> https://datatracker.ietf.org/iesg/agenda/documents/ >> Heh. Ok. That's probably the most complex page in the whole datatracke= r, >> and the rendering time is roughly proportional to the number of docume= nts >> on the page. With more than 50 documents on the page, it's probably >> heavier than usual. >=20 > The ">100ms per document" seems in line with the fact that this very=20 > simple endpoint that just returns 20 documents is running about 2.5s fo= r me: >=20 > https://datatracker.ietf.org/api/v1/doc/document/ >=20 > 100ms per document seems like a surprising amount of processing time. D= o=20 > you know where in the technology stack this is coming from? Like, would= =20 > selecting 20 documents out of the database from the commandline take=20 > this long? Or is it being introduced by Django? Apache? No, simply returning 20 documents from the database on the command line t= akes less than 10ms (the mysql command line says '20 rows in set (0.00 sec)' )= =2E I haven't looked at where the response time for the tastypie API comes fr= om. However, for the IESG agenda documents page, there are a number of indivi= dual lookups for each document, including things such as 'is this document bei= ng tracked by this user (flag in left-hand margin), 'get the latest document= event opening a ballot that hasn't already been closed', 'get the AD posi= tions for this ballot', 'is this document on the agenda for any upcoming meetin= g (.ics link in the left-hand margin)', 'get historic events in order to=20 calculate time in IESG evaluation', etc., etc., ... I'm sure this can be produced much more efficiently than it is now; we ha= ve collectively been adding information bit after bit to this view for some time, without a lot of consideration for lookup and rendering time. But having spent a bunch of hours inside the code of exactly this page during= the weekend, I can say that currently it's doing a surprising amount of necessary work in order to collect all the bits needed to put together th= e page. A complete refactoring is probably the only way to reduce the rendering time substantially from what it is now. > I'm hesitant to rely on caching too much; as you say, there's=20 > significant per-AD information here. Yes. If I can do caching, each AD will still get the full 5+s hit on the= first visit of the day, and maybe multiple times, depending on the cache time. But I'll at least investigate. Do you have any suggestion regardi= ng caching time if caching seems feasible? Henrik --IgpAtn2Bqhp8j0CE8C4Jlp8CCv6CX4DKw-- --ILs6vJoRQ53dF8dFwaC8VSs8ag72q5kR7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrCtBAACgkQTptXS4+7 FxqYjBAAzeQB1gJG7NAApOCJzMW6bNudR5wXHAAzcdu3XTEgLdYDk/63xcMb9LSC 9XkgpmUfdcJM/PZP3EVAIOgM+edrRQTap3jFit6YoFNodGZTn88uSRSrVCRtx3ml eMNL2hUrpNUWFk8iPJG39Lbn1I3BqJwLfr0QHWd71NY9xUTQ6wcCC6nJwQOJ3nom vTrH6Q0bJ59Aa5VcZYZQx8BqJrnaEqmrVJ5YF7Y+u4hjVUIeip4TEROBieoBBHxe 6i4M5QOVtRzxjGkzbOIXJX7TiSH4HZf3WUKJCiO050Pp+Yk9iTadDNOwq/d4Ddcb VRscxI5Npva+KNds34RuDmYibogRgQ2QW7OI3EqmWDZRaVZuped8wwF11w8IACmq Sz9kNp52gXpYjxxo5ozPy4B00ey/aHudS1YD5foGKRKWZxsH/V0YYS6LUyYvTwRX WjA6KvFZOFkL5wS44XvvSgd5qTS+kdOEZG5IwoXR13jXZoqwJ/o7ybJ3aO5rF8MR yDTy6fZhJNyeBRlHi5gbjdGd5tAh9YHTO+QO8xWZ7sPtQIIMP95vdF0YAqEfT2WN cwYdVRR/bshqIYNfUwHyGkrP5vDkPgxV2Dp3PJf1MU2VtLrIrBEqdSioAb4UTSvd 8NVyOqPtC0OeiJray5dyoEwQ+hWK05GRNFYsVNBRKEbCY5Umgdg= =soSW -----END PGP SIGNATURE----- --ILs6vJoRQ53dF8dFwaC8VSs8ag72q5kR7-- From nobody Mon Apr 2 16:00:36 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D326A12DA1D for ; Mon, 2 Apr 2018 16:00:34 -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 3Ric7cecxCkd for ; Mon, 2 Apr 2018 16:00:33 -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 4CB0012E8A9 for ; Mon, 2 Apr 2018 16:00:30 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:63245 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f38RA-0002x7-BE; Mon, 02 Apr 2018 16:00:29 -0700 To: Eric Rescorla References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> Cc: tools-discuss From: Henrik Levkowetz Message-ID: <16d50499-0c0d-fe2c-a73b-c3a34f27dad0@levkowetz.com> Date: Tue, 3 Apr 2018 01:00:20 +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="PERIsjkB2sjCgV1ENJl0gasfRJTSIXOj1" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.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-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 23:00:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PERIsjkB2sjCgV1ENJl0gasfRJTSIXOj1 Content-Type: multipart/mixed; boundary="WXeIBxGbrKkoQI7K7IH2s2cJwsgjEQOGm"; protected-headers="v1" From: Henrik Levkowetz To: Eric Rescorla Cc: tools-discuss Message-ID: <16d50499-0c0d-fe2c-a73b-c3a34f27dad0@levkowetz.com> Subject: Re: [Tools-discuss] Datatracker is being very slow References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> In-Reply-To: --WXeIBxGbrKkoQI7K7IH2s2cJwsgjEQOGm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ekr, On 2018-04-03 00:13, Eric Rescorla wrote: > On Mon, Apr 2, 2018 at 3:07 PM, Henrik Levkowetz = > wrote: >=20 >> >> >> On 2018-04-02 23:53, Eric Rescorla wrote: >> > 5.5s wait time for: >> > https://datatracker.ietf.org/iesg/agenda/documents/ >> >> Heh. Ok. That's probably the most complex page in the whole datatracke= r, >> and the rendering time is roughly proportional to the number of docume= nts >> on the page. With more than 50 documents on the page, it's probably >> heavier than usual. >> >=20 > It's not just this page. Searching for documents with "ice" takes 19+s = and > "trickle" takes 5+s. 19+s for "ice" documents definitely seems over the top. I'll have a look= =2E >=20 > Ben Campbell pointed out at the end of last week that incremental chang= es >> had brought it up to a response time of about 50s, so I worked during = the >> weekend to bring it down. Starting from 50s on Friday, I consider 5.5= s >> today a good result. >> >> I'll look at caching it, but since parts of the content is individuall= y >> rendered for each AD, too simple a cache won't work. >> >=20 > FWIW, the customary approach would be to have the server serve a JSON f= ile > consisting of the telechat status (this could be cached) and then have = the > client retrieve it with XHR and customize it there. The JSON file would have to comprise much more information than is sent to each client today, in order to be able to do the customization client-= side. I'm not sure if that refactoring would be any easier than the refactoring necessary to do the lookups and server-side rendering of this= page more efficiently. I'm sure both approaches will work an be able to reduce overall page delivery time, but neither is trivial. Henrik >=20 > -Ekr >=20 >=20 >> >> Henrik >> >> >> > On Mon, Apr 2, 2018 at 2:49 PM, Henrik Levkowetz >> > wrote: >> > >> >> >> >> On 2018-04-02 23:30, Eric Rescorla wrote: >> >> > I am seeing delays of seconds to 10s of seconds for simple tasks >> >> > >> >> > Any idea what's up? >> >> >> >> I had to do a number of reloads about an hour ago, and noticed that= >> >> re-loading the login page directly after each apache reload was >> >> very slow. It seems reasonably fast now, though (~1s here). Are >> >> you still seeing slowness? For which URLs? >> >> >> >> >> >> Henrik >> >> >> >> >> > >> >> >=20 >=20 >=20 > ___________________________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss >=20 > Please report datatracker.ietf.org and mailarchive.ietf.org > bugs at http://tools.ietf.org/tools/ietfdb > or send email to datatracker-project@ietf.org >=20 > Please report tools.ietf.org bugs at > http://tools.ietf.org/tools/issues > or send email to webmaster@tools.ietf.org >=20 --WXeIBxGbrKkoQI7K7IH2s2cJwsgjEQOGm-- --PERIsjkB2sjCgV1ENJl0gasfRJTSIXOj1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrCtgQACgkQTptXS4+7 FxpKcQ/+M3iA647uF+idMHNqEPg9JLEBbiCD7D6/SFWwdHmomyjIgA5P+1o0zUoZ PCTfbeEv8/Qss90t5UerlGZ/q9ZPcsr4IJUk6jmhjKPEwxPOrYtF9/WPCyjTeUD1 cTrSwyDYUBumigcHqdjwwjDPYtn9qnNYVExGaMWQnw3a2XXz8IQgsURJNzza6F9Y OORv4Cs2I/Cg20G0lBRpwliE3JP6ShABFYK66j/u83Hq/HnqNERTq7YYcA872oK5 iXN8uuKRKDq2MrwJm/2m80kxY3pJ/b7eEnJojyhnj+6jg2vBRFKxfKpFbts1h5GV 7rD99pPdDDiAJY7Rk7+9neMdkdLYMo0gMNyihn6ldYjNdcmyaw6Gx9Gy20iW0a6J QEaaIY2ReBVjXIwu28OUNDyyrIaTFglCsOP0dTwiy0hNlE3WLCcaw8PceHF4hOEr wzCdJ7KradciqsKToYW9esWSA5otgm2xdpl/LAytFHRo85Bp3ws1TFlYXnDtN9un wAViN05V23dBxv/X6M6tZf7YN55S341ZIstE2h31VNygYqOiiw381/g5DYWTxnCW 88b6zsUplirfQanq53okvci2pEoQKut9xtD85cx/nkQZpbFsGzPqHPHwjrKX+6DR DnTcjGcaqFTtMx2jfi9zgI+tdayTrdvqxl9dT1edouYNFCoGm10= =dZm7 -----END PGP SIGNATURE----- --PERIsjkB2sjCgV1ENJl0gasfRJTSIXOj1-- From nobody Mon Apr 2 16:01:24 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6239A12DA1C for ; Mon, 2 Apr 2018 16:01:23 -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 MwS8fJ6aLiBl for ; Mon, 2 Apr 2018 16:01:21 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 E8F1A12DA18 for ; Mon, 2 Apr 2018 16:01:20 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id h8-v6so17351639oti.6 for ; Mon, 02 Apr 2018 16:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xFQSBLzvmaYi0oBnfUyRQ/gjC1MYNRYCqlgk8E6ZGCE=; b=G/u66ZfY5jJB2LeeLr/ASZHAZc49aOFOMNuT5rfnVXSMCakZTOM5bgQNArvLjcovm8 0+U86ZC68Y1TFlLY1jL6+SliMDUNoqL+OI9RrlLX6V00AmP1Wk11iGlD1vXf9HQw6d9M xQehuU9LEpVr67ODAD/pVbMEbVdPqDSM4XUvd4b4HJAXoZUkW28+7g4m2Ly8sja5VqBU cAybM8OTXnDwDjnNa5zMf5ZcaoxTxnCAfnGiTviKyEIBpJQZjEHFJC/r6B4wbTQ2w07T M2LOdU87KjNKI/wWLvN0TFlHhI+9NAdzHkQ5gegAa74bafKz7YqAmQje/n05lsS8+FTV RHyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xFQSBLzvmaYi0oBnfUyRQ/gjC1MYNRYCqlgk8E6ZGCE=; b=DsdFybMf2zhd9r8j9g80v499JvsH/YtT7ObFUhfn3BweUtTshOjdJGgmmdDb1hnxki +sv2K8GZC9E+KMORadoqmPdjXqe3106l/VpfP72JB9yov6KMvm4GVXLBEqMYgW8is74Y 3Kxnn4fSoWDA0UU5S4y4/oFEWp13bxpqe4bI7mAM7hKBC5eOM+71LITwDdJ3dXucAwMS +a3gQmqKQVpUXmgB5P2Xtgq998Hn9EkPCxXdQRFBnWlKhokob2FJoug/TAk3hJKyirOV CqZqlO5BzaKNZFWjnp62+x+6r30GBuKtxhSxNRXvpTcpZz1HhMG1xG1Rw7RjG8vA7AlH e9Zw== X-Gm-Message-State: ALQs6tAlJglZxJh6YjUKO34mMQqKaOOT3MCqwhmexoCPeOlcooJenVym gPlaXi19esYPFphZtEdFm42Hhn/9nWVlQzb+0oTViD1l X-Google-Smtp-Source: AIpwx48BYEQjdXTOi8TpJ58NHZN+CDqaOXuYECu5uSl/jiCn7tNgwbEUaV15Bp36mpCVEuPM1QyPpY7DmldcnB4RZFk= X-Received: by 2002:a9d:26d4:: with SMTP id i20-v6mr6246082otd.214.1522710080333; Mon, 02 Apr 2018 16:01:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Mon, 2 Apr 2018 16:00:39 -0700 (PDT) In-Reply-To: <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> From: Eric Rescorla Date: Mon, 2 Apr 2018 16:00:39 -0700 Message-ID: To: Henrik Levkowetz Cc: Adam Roach , tools-discuss Content-Type: multipart/alternative; boundary="0000000000006f3af90568e59141" Archived-At: Subject: Re: [Tools-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 23:01:23 -0000 --0000000000006f3af90568e59141 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 2, 2018 at 3:51 PM, Henrik Levkowetz wrote: > Hi Adam, > > On 2018-04-03 00:22, Adam Roach wrote: > > On 4/2/18 5:07 PM, Henrik Levkowetz wrote: > >> > >> On 2018-04-02 23:53, Eric Rescorla wrote: > >>> 5.5s wait time for: > >>> https://datatracker.ietf.org/iesg/agenda/documents/ > >> Heh. Ok. That's probably the most complex page in the whole datatracker, > >> and the rendering time is roughly proportional to the number of > documents > >> on the page. With more than 50 documents on the page, it's probably > >> heavier than usual. > > > > The ">100ms per document" seems in line with the fact that this very > > simple endpoint that just returns 20 documents is running about 2.5s for > me: > > > > https://datatracker.ietf.org/api/v1/doc/document/ > > > > 100ms per document seems like a surprising amount of processing time. Do > > you know where in the technology stack this is coming from? Like, would > > selecting 20 documents out of the database from the commandline take > > this long? Or is it being introduced by Django? Apache? > > No, simply returning 20 documents from the database on the command line > takes > less than 10ms (the mysql command line says '20 rows in set (0.00 sec)' ). > I haven't looked at where the response time for the tastypie API comes > from. > > However, for the IESG agenda documents page, there are a number of > individual > lookups for each document, including things such as 'is this document being > tracked by this user (flag in left-hand margin), 'get the latest document > event opening a ballot that hasn't already been closed', 'get the AD > positions > for this ballot', 'is this document on the agenda for any upcoming meeting > (.ics link in the left-hand margin)', 'get historic events in order to > calculate time in IESG evaluation', etc., etc., ... > > I'm sure this can be produced much more efficiently than it is now; we have > collectively been adding information bit after bit to this view for some > time, without a lot of consideration for lookup and rendering time. But > having spent a bunch of hours inside the code of exactly this page during > the weekend, I can say that currently it's doing a surprising amount of > necessary work in order to collect all the bits needed to put together the > page. A complete refactoring is probably the only way to reduce the > rendering time substantially from what it is now. > Can this work be parallelized, e.g., by rendering the shell of the page to the user and then letting the browser independently request these values. > I'm hesitant to rely on caching too much; as you say, there's > > significant per-AD information here. > > Yes. If I can do caching, each AD will still get the full 5+s hit on the > first visit of the day, and maybe multiple times, depending on the cache > time. But I'll at least investigate. Do you have any suggestion regarding > caching time if caching seems feasible? > Depends which cache you mean. -Ekr > > Henrik > > --0000000000006f3af90568e59141 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 2, 2018 at 3:51 PM, Henrik Levkowetz <= henrik@levkowetz.= com> wrote:
Hi Adam,

On 2018-04-03 00:22, Adam Roach wrote:
> On 4/2/18 5:07 PM, Henrik Levkowetz wrote:
>>
>> On 2018-04-02 23:53, Eric Rescorla wrote:
>>> 5.5s wait time for:
>>> https://datatracker.ietf.org/ie= sg/agenda/documents/
>> Heh. Ok. That's probably the most complex page in the whole da= tatracker,
>> and the rendering time is roughly proportional to the number of do= cuments
>> on the page.=C2=A0 With more than 50 documents on the page, it'= ;s probably
>> heavier than usual.
>
> The ">100ms per document" seems in line with the fact tha= t this very
> simple endpoint that just returns 20 documents is running about 2.5s f= or me:
>
> https://datatracker.ietf.org/api/v1/doc/d= ocument/
>
> 100ms per document seems like a surprising amount of processing time. = Do
> you know where in the technology stack this is coming from? Like, woul= d
> selecting 20 documents out of the database from the commandline take > this long? Or is it being introduced by Django? Apache?

No, simply returning 20 documents from the database on the command l= ine takes
less than 10ms (the mysql command line says '20 rows in set (0.00 sec)&= #39; ).
I haven't looked at where the response time for the tastypie API comes = from.

However, for the IESG agenda documents page, there are a number of individu= al
lookups for each document, including things such as 'is this document b= eing
tracked by this user (flag in left-hand margin), 'get the latest docume= nt
event opening a ballot that hasn't already been closed', 'get t= he AD positions
for this ballot', 'is this document on the agenda for any upcoming = meeting
(.ics link in the left-hand margin)', 'get historic events in order= to
calculate time in IESG evaluation', etc., etc., ...

I'm sure this can be produced much more efficiently than it is now; we = have
collectively been adding information bit after bit to this view for some time, without a lot of consideration for lookup and rendering time.=C2=A0 B= ut
having spent a bunch of hours inside the code of exactly this page during the weekend, I can say that currently it's doing a surprising amount of=
necessary work in order to collect all the bits needed to put together the<= br> page.=C2=A0 A complete refactoring is probably the only way to reduce the rendering time substantially from what it is now.

=
Can this work be parallelized, e.g., by rendering the shell of t= he page to the
user and then letting the browser independently re= quest these values.


> I'm hesitant to rely on caching too much; as you say, there's<= br> > significant per-AD information here.

Yes.=C2=A0 If I can do caching, each AD will still get the full 5+s = hit on the
first visit of the day, and maybe multiple times, depending on the cache time.=C2=A0 But I'll at least investigate.=C2=A0 Do you have any sugges= tion regarding
caching time if caching seems feasible?

Depends which cache you mean.

-Ekr
=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik


--0000000000006f3af90568e59141-- From nobody Mon Apr 2 16:03:19 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C291612DA18 for ; Mon, 2 Apr 2018 16:03:17 -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 v1dkn1ybarIV for ; Mon, 2 Apr 2018 16:03:15 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 A06C71252BA for ; Mon, 2 Apr 2018 16:03:15 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id i28-v6so17357521otf.8 for ; Mon, 02 Apr 2018 16:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OdBsVJal8mfDndr0iSC5X2eu/cBUC1QP9Dhjb6PZLHI=; b=fZRayqLs/d2ZADZ4E1VnREkm1M5lxXiHbkAVSqaD7cXvhFHBLJaItXdxurYnQ2TuUQ Q4GOIhu1KarY0gs3PC5i+5QJl6KDwd8z2q+7PhnvKlhfQmzl+c+ajuMJzc/vFCEpZA4H 2McL0JoZ/Mm5shtYFBhuS4MLye1Lr0tyJajGd0q5ssRIgoBWUmNVBHtEYCOmezwykjOP nvi+PKtgblZZE/yY9YNQP2gsd63CEZ/5P/LRW63LXz+R+DXU4GXU2aVNRx/kUq2TmQYd +DbkjRs4rHvAOr0My+PWlGX9mHRYQk8MR+53weSsISGuZ+QnpF266dfpwxcZhEBuXtO7 hfsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OdBsVJal8mfDndr0iSC5X2eu/cBUC1QP9Dhjb6PZLHI=; b=dR/IL9b8s/UoZMsn73vUOD5zMKZQT/g4oUjCfddbRnzJTqDPTV3q0+3B+BcsOwSkR6 VZoWfZVPywVE3odhTK7ibuDzi/1cNE/wLMQX+dlYPJmSPA1HDI5ATco2oUTdzuGYxl9U XanjJbujFgDJgo3U45xjRJq2Qjsoe2vle3Os+Pa5X6sDcDB9DxjdKwQAXqV3iB7ek+WV RHtKzfHhK2HVsDiQiNP8RrsK58gfi3YHxVDT3Xv7tGvMJ5SKwWAXbmW6BzYxY7Mt6jwF ZF0qtSdsG1tPwLHFDmbbJWQfSzH8Qqy0F8fTF5gL/Ilti5Cvj2LHsPwWX5k5sUeXb8Wx sBJQ== X-Gm-Message-State: ALQs6tA0w5FLVj6Cu6RD5+oQHspKztBbHFJ2cMsJFCVacYhXX4G+WP6X p1sux4a4x8uwHo8vEGIwgm6I+xMeX6A8/2L4zYvltA== X-Google-Smtp-Source: AIpwx48zTzEcLvfU1OI3x+VoWHOwsaX4l7aP0FPWkywGDSA6sCbPNd7UULbGrQkCzwg/Ehr2Hi4XyNL9anyMuN0gYqE= X-Received: by 2002:a9d:5192:: with SMTP id y18-v6mr7032832otg.176.1522710193743; Mon, 02 Apr 2018 16:03:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Mon, 2 Apr 2018 16:02:33 -0700 (PDT) In-Reply-To: <16d50499-0c0d-fe2c-a73b-c3a34f27dad0@levkowetz.com> References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <16d50499-0c0d-fe2c-a73b-c3a34f27dad0@levkowetz.com> From: Eric Rescorla Date: Mon, 2 Apr 2018 16:02:33 -0700 Message-ID: To: Henrik Levkowetz Cc: tools-discuss Content-Type: multipart/alternative; boundary="00000000000031c1090568e598d2" Archived-At: Subject: Re: [Tools-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 23:03:18 -0000 --00000000000031c1090568e598d2 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 2, 2018 at 4:00 PM, Henrik Levkowetz wrote: > Hi Ekr, > > On 2018-04-03 00:13, Eric Rescorla wrote: > > On Mon, Apr 2, 2018 at 3:07 PM, Henrik Levkowetz > > wrote: > > > >> > >> > >> On 2018-04-02 23:53, Eric Rescorla wrote: > >> > 5.5s wait time for: > >> > https://datatracker.ietf.org/iesg/agenda/documents/ > >> > >> Heh. Ok. That's probably the most complex page in the whole datatracker, > >> and the rendering time is roughly proportional to the number of > documents > >> on the page. With more than 50 documents on the page, it's probably > >> heavier than usual. > >> > > > > It's not just this page. Searching for documents with "ice" takes 19+s > and > > "trickle" takes 5+s. > > 19+s for "ice" documents definitely seems over the top. I'll have a look. > > > > > Ben Campbell pointed out at the end of last week that incremental changes > >> had brought it up to a response time of about 50s, so I worked during > the > >> weekend to bring it down. Starting from 50s on Friday, I consider 5.5s > >> today a good result. > >> > >> I'll look at caching it, but since parts of the content is individually > >> rendered for each AD, too simple a cache won't work. > >> > > > > FWIW, the customary approach would be to have the server serve a JSON > file > > consisting of the telechat status (this could be cached) and then have > the > > client retrieve it with XHR and customize it there. > > The JSON file would have to comprise much more information than is sent > to each client today, in order to be able to do the customization client- > side. I'm not sure if that refactoring would be any easier than the > refactoring necessary to do the lookups and server-side rendering of this > page more efficiently. I'm sure both approaches will work an be able to > reduce overall page delivery time, but neither is trivial. > Sure, but it's typically the back-and-forth to the database that's expensive in this kind of app, not the bandwidth to send the joined records for each draft. -Ekr > > Henrik > > > > > > > -Ekr > > > > > >> > >> Henrik > >> > >> > >> > On Mon, Apr 2, 2018 at 2:49 PM, Henrik Levkowetz < > henrik@levkowetz.com> > >> > wrote: > >> > > >> >> > >> >> On 2018-04-02 23:30, Eric Rescorla wrote: > >> >> > I am seeing delays of seconds to 10s of seconds for simple tasks > >> >> > > >> >> > Any idea what's up? > >> >> > >> >> I had to do a number of reloads about an hour ago, and noticed that > >> >> re-loading the login page directly after each apache reload was > >> >> very slow. It seems reasonably fast now, though (~1s here). Are > >> >> you still seeing slowness? For which URLs? > >> >> > >> >> > >> >> Henrik > >> >> > >> >> > >> > > >> > >> > > > > > > > > ___________________________________________________________ > > Tools-discuss mailing list > > Tools-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/tools-discuss > > > > Please report datatracker.ietf.org and mailarchive.ietf.org > > bugs at http://tools.ietf.org/tools/ietfdb > > or send email to datatracker-project@ietf.org > > > > Please report tools.ietf.org bugs at > > http://tools.ietf.org/tools/issues > > or send email to webmaster@tools.ietf.org > > > > --00000000000031c1090568e598d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 2, 2018 at 4:00 PM, Henrik Levkowetz <= henrik@levkowetz.= com> wrote:
Hi Ekr,

On 2018-04-03 00:13, Eric Rescorla wrote:
> On Mon, Apr 2, 2018 at 3:07 PM, Henrik Levkowetz <henrik@levkowetz.com>
> wrote:
>
>>
>>
>> On 2018-04-02 23:53, Eric Rescorla wrote:
>> > 5.5s wait time for:
>> > https://datatracker.ietf.org/i= esg/agenda/documents/
>>
>> Heh. Ok. That's probably the most complex page in the whole da= tatracker,
>> and the rendering time is roughly proportional to the number of do= cuments
>> on the page.=C2=A0 With more than 50 documents on the page, it'= ;s probably
>> heavier than usual.
>>
>
> It's not just this page. Searching for documents with "ice&qu= ot; takes 19+s and
> "trickle" takes 5+s.

19+s for "ice" documents definitely seems over the top.=C2= =A0 I'll have a look.

>
> Ben Campbell pointed out at the end of last week that incremental chan= ges
>> had brought it up to a response time of about 50s, so I worked dur= ing the
>> weekend to bring it down.=C2=A0 Starting from 50s on Friday, I con= sider 5.5s
>> today a good result.
>>
>> I'll look at caching it, but since parts of the content is ind= ividually
>> rendered for each AD, too simple a cache won't work.
>>
>
> FWIW, the customary approach would be to have the server serve a JSON = file
> consisting of the telechat status (this could be cached) and then have= the
> client retrieve it with XHR and customize it there.

The JSON file would have to comprise much more information than is s= ent
to each client today, in order to be able to do the customization client- side.=C2=A0 I'm not sure if that refactoring would be any easier than t= he
refactoring necessary to do the lookups and server-side rendering of this page more efficiently.=C2=A0 I'm sure both approaches will work an be a= ble to
reduce overall page delivery time, but neither is trivial.
=

Sure, but it's typically the back-and-forth to the = database that's expensive in this
kind of app, not the bandwi= dth to send the joined records for each draft.

-Ekr



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik



>
> -Ekr
>
>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>>
>>
>> > On Mon, Apr 2, 2018 at 2:49 PM, Henrik Levkowetz <henrik@levkowetz.com>
>> > wrote:
>> >
>> >>
>> >> On 2018-04-02 23:30, Eric Rescorla wrote:
>> >> > I am seeing delays of seconds to 10s of seconds for = simple tasks
>> >> >
>> >> > Any idea what's up?
>> >>
>> >> I had to do a number of reloads about an hour ago, and no= ticed that
>> >> re-loading the login page directly after each apache relo= ad was
>> >> very slow.=C2=A0 It seems reasonably fast now, though (~1= s here).=C2=A0 Are
>> >> you still seeing slowness?=C2=A0 For which URLs?
>> >>
>> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>> >>
>> >>
>> >
>>
>>
>
>
>
> _______________________= ____________________________________
> Tools-discuss mailing list
> Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/t= ools-discuss
>
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to datat= racker-project@ietf.org
>
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to webmaster= @tools.ietf.org
>


--00000000000031c1090568e598d2-- From nobody Mon Apr 2 16:08:36 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C1E12DA18 for ; Mon, 2 Apr 2018 16:08:35 -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 iCcr2xMbrdjy for ; Mon, 2 Apr 2018 16:08:33 -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 B5B1212DA15 for ; Mon, 2 Apr 2018 16:08:33 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:63286 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f38Yy-0005EQ-Kh; Mon, 02 Apr 2018 16:08:33 -0700 To: Eric Rescorla References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> Cc: tools-discuss From: Henrik Levkowetz Message-ID: <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> Date: Tue, 3 Apr 2018 01:08:24 +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="a4PHeCA5LOQulWF3KTMpkkhF9c0FpJftL" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.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-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 23:08:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a4PHeCA5LOQulWF3KTMpkkhF9c0FpJftL Content-Type: multipart/mixed; boundary="lcGWG8mRhfSFHWtSXWPtewomsjIdoapOF"; protected-headers="v1" From: Henrik Levkowetz To: Eric Rescorla Cc: tools-discuss Message-ID: <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> Subject: Re: [Tools-discuss] Datatracker is being very slow References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> In-Reply-To: --lcGWG8mRhfSFHWtSXWPtewomsjIdoapOF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-04-03 01:00, Eric Rescorla wrote: > On Mon, Apr 2, 2018 at 3:51 PM, Henrik Levkowetz = > wrote: >=20 >> Hi Adam, >> >> On 2018-04-03 00:22, Adam Roach wrote: >> > On 4/2/18 5:07 PM, Henrik Levkowetz wrote: >> >> >> >> On 2018-04-02 23:53, Eric Rescorla wrote: >> >>> 5.5s wait time for: >> >>> https://datatracker.ietf.org/iesg/agenda/documents/ >> >> Heh. Ok. That's probably the most complex page in the whole datatra= cker, >> >> and the rendering time is roughly proportional to the number of >> documents >> >> on the page. With more than 50 documents on the page, it's probabl= y >> >> heavier than usual. >> > >> > The ">100ms per document" seems in line with the fact that this very= >> > simple endpoint that just returns 20 documents is running about 2.5s= for >> me: >> > >> > https://datatracker.ietf.org/api/v1/doc/document/ >> > >> > 100ms per document seems like a surprising amount of processing time= =2E Do >> > you know where in the technology stack this is coming from? Like, wo= uld >> > selecting 20 documents out of the database from the commandline take= >> > this long? Or is it being introduced by Django? Apache? >> >> No, simply returning 20 documents from the database on the command lin= e >> takes >> less than 10ms (the mysql command line says '20 rows in set (0.00 sec)= ' ). >> I haven't looked at where the response time for the tastypie API comes= >> from. >> >> However, for the IESG agenda documents page, there are a number of >> individual >> lookups for each document, including things such as 'is this document = being >> tracked by this user (flag in left-hand margin), 'get the latest docum= ent >> event opening a ballot that hasn't already been closed', 'get the AD >> positions >> for this ballot', 'is this document on the agenda for any upcoming mee= ting >> (.ics link in the left-hand margin)', 'get historic events in order to= >> calculate time in IESG evaluation', etc., etc., ... >> >> I'm sure this can be produced much more efficiently than it is now; we= have >> collectively been adding information bit after bit to this view for so= me >> time, without a lot of consideration for lookup and rendering time. B= ut >> having spent a bunch of hours inside the code of exactly this page dur= ing >> the weekend, I can say that currently it's doing a surprising amount o= f >> necessary work in order to collect all the bits needed to put together= the >> page. A complete refactoring is probably the only way to reduce the >> rendering time substantially from what it is now. >> >=20 > Can this work be parallelized, e.g., by rendering the shell of the page= to > the > user and then letting the browser independently request these values. Given that the biggest problem right now is the number of lookups generat= ed individually per document, instead of being retrieved in bulk by fewer mo= re complex queries, the approach doesn't seem promising. >> I'm hesitant to rely on caching too much; as you say, there's >> > significant per-AD information here. >> >> Yes. If I can do caching, each AD will still get the full 5+s hit on = the >> first visit of the day, and maybe multiple times, depending on the cac= he >> time. But I'll at least investigate. Do you have any suggestion rega= rding >> caching time if caching seems feasible? >> >=20 > Depends which cache you mean. Server-side per-user cache (memcached). Henrik --lcGWG8mRhfSFHWtSXWPtewomsjIdoapOF-- --a4PHeCA5LOQulWF3KTMpkkhF9c0FpJftL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrCt+gACgkQTptXS4+7 Fxon2A//QZiDkYXX4rn1KmZ1bdVAEqjh95dyWpKSFBvVP9EFexGFe7/GAXsa75pc vQjFETGGl/MuF2oDtKPD+Ejxn+NS4ZS6uA/Uj7sCVmwRTn/ZHOPWSNUUaKp6/792 rXRXnsT0lZtSdvIyocx2QHHL6sFciN5bzczj4eQavXCMzjyvM4cJTGoaSDokS8fL 1YCV2xmpf3ReB3JexhmhRz++RE3zRftx27Q8OQJox53JPKB15wejlIjKYNNRTt/n dNnZN+dpRJ23YLqyaFgqKHoksldQg5RkFeutCbn9wSPy5QqxQ/NJ9A6FBTp/lBgP Iv0d0ZSe9H62tBut+EJOyPy6e5wYozUIIlYQd0RvW0bNy13LUX0TFL50hBqdh1RB AsjFeIQbgdchxg2Ak189Jc5dSO7exEh0NBI7kLGrYP321Rx4FKBBVqGTzc0gwbcY vWMF4SG9fm29F9A3ie+XZfCKkotigm0wRlXApxIRPM711wPhiVs78LLb/Z7OgkTH s2AkLJfDp4JTw10EDYx3KiWDi12CRt3xmm2xjHOuIuTJUfNLKxWa8cjk32UIRa00 Hb9gOedoZ44fG/A3S9xVKFndrlUq93TuWzljXp2imagJLR7fgMMxVEgjTD6Z5lJL l2Mm/mTeyIzDtZCSfOWAIRxUN24+ACEWXPvYhkflbwtQqqLCfhE= =TmUs -----END PGP SIGNATURE----- --a4PHeCA5LOQulWF3KTMpkkhF9c0FpJftL-- From nobody Mon Apr 2 16:13:12 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CFD12DA18 for ; Mon, 2 Apr 2018 16:13:10 -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 Fobba5fyTA4P for ; Mon, 2 Apr 2018 16:13:08 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 207FA12DA15 for ; Mon, 2 Apr 2018 16:13:08 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id m22-v6so17363626otf.10 for ; Mon, 02 Apr 2018 16:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fdcq8p60K7uMhkTEiBmbnQqprCQB8xxoQJenjzMqtH0=; b=Yyban2rs0CibOrjBRx9S/Kx6RRbA3UG3PaApbmo/wfBj8jym3PfEVLocq+VzXdfC+f e/HLAoeCqAcSWS2ponThAUW5dtE/vi++hq4n12kJI1DXyiLqtXOT+4SxaIphg0ygCNgc 72CkSeRrXGgP3FYRkoUJmvywNMC7rQVMQZYUjYS5OJ/qw++53L2XwCpfNP9Ir1/DloS0 ZnmcxvuT2cL6ee1nBSsIJoJzslCeaufNEWRLnfneJHNrf2kzZYjT+MuemzloLNMwmtwZ Fuuo9Nuh5JpfyIWytKboYIuRSk700pXrd7CsQJYaw/Hpj5VPh/wMbuh10gJh4aPI8OTa sh5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fdcq8p60K7uMhkTEiBmbnQqprCQB8xxoQJenjzMqtH0=; b=Bx57rcLfx/IwITtWwj9S0OAUD8aeBurY8Al1TBmffBZEFCAs0xlNu8CwB5H8Xb4PtI wHxqqxwEg1YBB/TOOXDs5PYnrXeGaOMQ5b4y9etablMMnNhHvBHg3/k65iZ1gt2erOKf lA3SuyGnLBFrCgsjDoXCh3qvpbEekEgT5v2Am+rjx43brURik7vl5O4AcgAM4Jk9ZInR VsZ97JZr4i0ayHUhZxXcv5OIXxkMVkYfefkM3HsLhLap92hHGaaKT8pgWBcImVR4chpy Lge78ag0XIkeJ+MA0BqLJaoe09dB6aIqOF4Gm0XxldgNLNxJSkE6s8PHjJ0Q9AJPtn5g 1vEQ== X-Gm-Message-State: ALQs6tAtcMFWFeAwIPdOfh4tEWqizTBqu9KAhPoRoWzMzowufKCAU9vB UTOXyDLUThbHoGdG++PaFnh6I6sW/tNWXPpMmKS0uFy0 X-Google-Smtp-Source: AIpwx49h8xyyjkk9oU8oiW/trisK0Cs/JbCpu4pHtUCHQaQloj5Kp0knm6QVOYnG0SrGptPl5D875YAenLkey6Qkc8Y= X-Received: by 2002:a9d:3636:: with SMTP id w51-v6mr6013513otb.101.1522710787515; Mon, 02 Apr 2018 16:13:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Mon, 2 Apr 2018 16:12:27 -0700 (PDT) In-Reply-To: <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> From: Eric Rescorla Date: Mon, 2 Apr 2018 16:12:27 -0700 Message-ID: To: Henrik Levkowetz Cc: tools-discuss Content-Type: multipart/alternative; boundary="00000000000095f9290568e5bb3b" Archived-At: Subject: Re: [Tools-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 23:13:11 -0000 --00000000000095f9290568e5bb3b Content-Type: text/plain; charset="UTF-8" On Mon, Apr 2, 2018 at 4:08 PM, Henrik Levkowetz wrote: > > On 2018-04-03 01:00, Eric Rescorla wrote: > > On Mon, Apr 2, 2018 at 3:51 PM, Henrik Levkowetz > > wrote: > > > >> Hi Adam, > >> > >> On 2018-04-03 00:22, Adam Roach wrote: > >> > On 4/2/18 5:07 PM, Henrik Levkowetz wrote: > >> >> > >> >> On 2018-04-02 23:53, Eric Rescorla wrote: > >> >>> 5.5s wait time for: > >> >>> https://datatracker.ietf.org/iesg/agenda/documents/ > >> >> Heh. Ok. That's probably the most complex page in the whole > datatracker, > >> >> and the rendering time is roughly proportional to the number of > >> documents > >> >> on the page. With more than 50 documents on the page, it's probably > >> >> heavier than usual. > >> > > >> > The ">100ms per document" seems in line with the fact that this very > >> > simple endpoint that just returns 20 documents is running about 2.5s > for > >> me: > >> > > >> > https://datatracker.ietf.org/api/v1/doc/document/ > >> > > >> > 100ms per document seems like a surprising amount of processing time. > Do > >> > you know where in the technology stack this is coming from? Like, > would > >> > selecting 20 documents out of the database from the commandline take > >> > this long? Or is it being introduced by Django? Apache? > >> > >> No, simply returning 20 documents from the database on the command line > >> takes > >> less than 10ms (the mysql command line says '20 rows in set (0.00 sec)' > ). > >> I haven't looked at where the response time for the tastypie API comes > >> from. > >> > >> However, for the IESG agenda documents page, there are a number of > >> individual > >> lookups for each document, including things such as 'is this document > being > >> tracked by this user (flag in left-hand margin), 'get the latest > document > >> event opening a ballot that hasn't already been closed', 'get the AD > >> positions > >> for this ballot', 'is this document on the agenda for any upcoming > meeting > >> (.ics link in the left-hand margin)', 'get historic events in order to > >> calculate time in IESG evaluation', etc., etc., ... > >> > >> I'm sure this can be produced much more efficiently than it is now; we > have > >> collectively been adding information bit after bit to this view for some > >> time, without a lot of consideration for lookup and rendering time. But > >> having spent a bunch of hours inside the code of exactly this page > during > >> the weekend, I can say that currently it's doing a surprising amount of > >> necessary work in order to collect all the bits needed to put together > the > >> page. A complete refactoring is probably the only way to reduce the > >> rendering time substantially from what it is now. > >> > > > > Can this work be parallelized, e.g., by rendering the shell of the page > to > > the > > user and then letting the browser independently request these values. > > Given that the biggest problem right now is the number of lookups generated > individually per document, instead of being retrieved in bulk by fewer more > complex queries, the approach doesn't seem promising. > I wonder if we're talking past each other. My point here is that many of these values aren't necessary to view the page. For instance, I'd be willing to have the page render but not be able to see the ballots or colors or whatever. Based on the description of the problem, it seems like you ought to be able to do that and then fetch those in the background, no? >> I'm hesitant to rely on caching too much; as you say, there's > >> > significant per-AD information here. > >> > >> Yes. If I can do caching, each AD will still get the full 5+s hit on > the > >> first visit of the day, and maybe multiple times, depending on the cache > >> time. But I'll at least investigate. Do you have any suggestion > regarding > >> caching time if caching seems feasible? > >> > > > > Depends which cache you mean. > > Server-side per-user cache (memcached). > Why not indefinitely? You don't have a way to know when the cache ought to be invalidated? -Ekr > > Henrik > > --00000000000095f9290568e5bb3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 2, 2018 at 4:08 PM, Henrik Levkowetz <= henrik@levkowetz.= com> wrote:

On 2018-04-03 01:00, Eric Rescorla wrote:
> On Mon, Apr 2, 2018 at 3:51 PM, Henrik Levkowetz <henrik@levkowetz.com>
> wrote:
>
>> Hi Adam,
>>
>> On 2018-04-03 00:22, Adam Roach wrote:
>> > On 4/2/18 5:07 PM, Henrik Levkowetz wrote:
>> >>
>> >> On 2018-04-02 23:53, Eric Rescorla wrote:
>> >>> 5.5s wait time for:
>> >>> https://datatracker.ietf.or= g/iesg/agenda/documents/
>> >> Heh. Ok. That's probably the most complex page in the= whole datatracker,
>> >> and the rendering time is roughly proportional to the num= ber of
>> documents
>> >> on the page.=C2=A0 With more than 50 documents on the pag= e, it's probably
>> >> heavier than usual.
>> >
>> > The ">100ms per document" seems in line with the= fact that this very
>> > simple endpoint that just returns 20 documents is running abo= ut 2.5s for
>> me:
>> >
>> > https://datatracker.ietf.org/api= /v1/doc/document/
>> >
>> > 100ms per document seems like a surprising amount of processi= ng time. Do
>> > you know where in the technology stack this is coming from? L= ike, would
>> > selecting 20 documents out of the database from the commandli= ne take
>> > this long? Or is it being introduced by Django? Apache?
>>
>> No, simply returning 20 documents from the database on the command= line
>> takes
>> less than 10ms (the mysql command line says '20 rows in set (0= .00 sec)' ).
>> I haven't looked at where the response time for the tastypie A= PI comes
>> from.
>>
>> However, for the IESG agenda documents page, there are a number of=
>> individual
>> lookups for each document, including things such as 'is this d= ocument being
>> tracked by this user (flag in left-hand margin), 'get the late= st document
>> event opening a ballot that hasn't already been closed', &= #39;get the AD
>> positions
>> for this ballot', 'is this document on the agenda for any = upcoming meeting
>> (.ics link in the left-hand margin)', 'get historic events= in order to
>> calculate time in IESG evaluation', etc., etc., ...
>>
>> I'm sure this can be produced much more efficiently than it is= now; we have
>> collectively been adding information bit after bit to this view fo= r some
>> time, without a lot of consideration for lookup and rendering time= .=C2=A0 But
>> having spent a bunch of hours inside the code of exactly this page= during
>> the weekend, I can say that currently it's doing a surprising = amount of
>> necessary work in order to collect all the bits needed to put toge= ther the
>> page.=C2=A0 A complete refactoring is probably the only way to red= uce the
>> rendering time substantially from what it is now.
>>
>
> Can this work be parallelized, e.g., by rendering the shell of the pag= e to
> the
> user and then letting the browser independently request these values.<= br>
Given that the biggest problem right now is the number of looku= ps generated
individually per document, instead of being retrieved in bulk by fewer more=
complex queries, the approach doesn't seem promising.
<= div>
I wonder if we're talking past each other. My point = here is that many of these values
aren't necessary to view th= e page. For instance, I'd be willing to have the page render
= but not be able to see the ballots or colors or whatever. Based on the desc= ription
of the problem, it seems like you ought to be able to do = that and then fetch those in
the background, no?

>> I'm hesitant to rely on caching too much; as you say, there= 9;s
>> > significant per-AD information here.
>>
>> Yes.=C2=A0 If I can do caching, each AD will still get the full 5+= s hit on the
>> first visit of the day, and maybe multiple times, depending on the= cache
>> time.=C2=A0 But I'll at least investigate.=C2=A0 Do you have a= ny suggestion regarding
>> caching time if caching seems feasible?
>>
>
> Depends which cache you mean.

Server-side per-user cache (memcached).

Why not indefinitely? You don't have a way to know when the cac= he ought to be invalidated?

-Ekr



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik


--00000000000095f9290568e5bb3b-- From nobody Mon Apr 2 16:20:39 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EF312DA22 for ; Mon, 2 Apr 2018 16:20:38 -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 6pcH51TE2F1G for ; Mon, 2 Apr 2018 16:20:37 -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 7546712DA1D for ; Mon, 2 Apr 2018 16:20:37 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:63334 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f38ke-0003KT-JM; Mon, 02 Apr 2018 16:20:36 -0700 To: Eric Rescorla References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> Cc: tools-discuss From: Henrik Levkowetz Message-ID: Date: Tue, 3 Apr 2018 01:20:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hxiCcHtknWPAOMKW2vAPkFTg3NEakUj2t" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.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-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 23:20:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hxiCcHtknWPAOMKW2vAPkFTg3NEakUj2t Content-Type: multipart/mixed; boundary="S7rfo1uCPUoDOmBd79wg60t2SsNqdakRw"; protected-headers="v1" From: Henrik Levkowetz To: Eric Rescorla Cc: tools-discuss Message-ID: Subject: Re: [Tools-discuss] Datatracker is being very slow References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> In-Reply-To: --S7rfo1uCPUoDOmBd79wg60t2SsNqdakRw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-04-03 01:12, Eric Rescorla wrote: >> Server-side per-user cache (memcached). >> > Why not indefinitely? You don't have a way to know when the cache ought= to > be invalidated? Not trivially. But it can probably be built based on the time of the lat= est document event for the documents on the agenda. Henrik --S7rfo1uCPUoDOmBd79wg60t2SsNqdakRw-- --hxiCcHtknWPAOMKW2vAPkFTg3NEakUj2t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrCur0ACgkQTptXS4+7 FxpL9A/+JVV6BGHyEkL3+9SqtjzQ3VjuU22aKJV+rW0X/E0Iw8YJhEERcKkBontb qK7uO/x8X6NUI8IlS1uC7cb6OMUnoTtG/Q78615ECpHA8Voy2TkaAfX55BbLEzwk +gKDlvHsdJZBesaYBEFqtX04KTHLirCzn7KnM+9DaMqZrKT1up18Pi26F0MKaMh9 t0ygj0c64emprz5SdGchoZdWeB81aiRiQEadFMyzdhUc9OKRv6CEw2+MyJk7Oju+ WBN9F/E3nyAlroRBKC+AZHzFZH3sePz7UTvmKknW+TKLP6g7B2gqmhUCzYA9rDDG yz/XEzG6GEnOCjEEGpwHLKTIBu7kP88pWoGE0zeNcFOjpr2ys5G5CJeXtB0q8L6R y/n5BM1E7FdRgC0r8XTxcRDChS+gzXxyXnQAf0blo3HD9LS7iB3o1/cwBtlGKOyG pLDn+QESKBtH+rf+QiT03OM87/Ye/riLgrDjcS4GMa17GIWCDV6bFDFyScKTl2Ut qJjHPEP6lUhxxFDSkZ9i9yHG3G7XArBTjBrKMn4rqIcEG7cSrj1TXyLV4z4EX8SL TGRp+4HA0iUbz64rUpbi10rQ4RGWwWZUAqQ1H6tin66G5DQETIdw13XoKDeMVSWa 0csq/xjm8uiKzioy5S+ss90JKTlUFcIKSq21fhP6+rCKuBlRSs8= =ZEDw -----END PGP SIGNATURE----- --hxiCcHtknWPAOMKW2vAPkFTg3NEakUj2t-- From nobody Mon Apr 2 16:27:53 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597E212DA1C for ; Mon, 2 Apr 2018 16:27:52 -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 ZbJDM7ncHwws for ; Mon, 2 Apr 2018 16:27:51 -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 1DD1312DA15 for ; Mon, 2 Apr 2018 16:27:51 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:63347 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f38re-0007NM-FF; Mon, 02 Apr 2018 16:27:50 -0700 To: Eric Rescorla References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> Cc: tools-discuss From: Henrik Levkowetz Message-ID: Date: Tue, 3 Apr 2018 01:27:42 +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="70qxKngOD8VOMtRVrEiQO5tJbSTrwAwgx" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.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-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 23:27:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --70qxKngOD8VOMtRVrEiQO5tJbSTrwAwgx Content-Type: multipart/mixed; boundary="krmQXIGgXeblUcXVEGe13GrEW2tmiH4oQ"; protected-headers="v1" From: Henrik Levkowetz To: Eric Rescorla Cc: tools-discuss Message-ID: Subject: Re: [Tools-discuss] Datatracker is being very slow References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> In-Reply-To: --krmQXIGgXeblUcXVEGe13GrEW2tmiH4oQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-04-03 01:12, Eric Rescorla wrote: >> Given that the biggest problem right now is the number of lookups >> generated individually per document, instead of being retrieved in >> bulk by fewer more complex queries, the approach doesn't seem >> promising. >>=20 > I wonder if we're talking past each other. My point here is that many > of these values aren't necessary to view the page. For instance, I'd > be willing to have the page render but not be able to see the ballots > or colors or whatever. Based on the description of the problem, it > seems like you ought to be able to do that and then fetch those in=20 > the background, no? Yes. But I don't see that refactoring being any easier than the other possible approaches. And I don't see it being inherently superior, given that the raw database accesses currently take up only about 1/6 of the the total time, when measured on my dev server. It's the accumulated cost of fetching individual pieces from many different places in the code and template that results in the long rendering time. Henrik --krmQXIGgXeblUcXVEGe13GrEW2tmiH4oQ-- --70qxKngOD8VOMtRVrEiQO5tJbSTrwAwgx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrCvG4ACgkQTptXS4+7 Fxrq7xAAnH4gNdtHEt9yHDCqtaQFc5s6/aC29EwbJuE35thy4qVKCgCZh0BzhsuL Eqlt1ILCsQ7gveXBHjLhdKCLoDl/i8Mzw652zj9S0SFG4ujoGcFEYC3RTiKFLXol yX/jJYIHijVQ+gVlfJK0hzkB3PoWSWsLh69U9ZLtZNzgFOV7Wr7Llv+kWVPSrN6T nUcbV+CRncNpezZ2La5zpZkYCMDDT7Wu+a6OnwMkVv2lNjnudcykyqklOIPLRuvU E+afbkjgMMOOPztZeUDSG2D82INgavbgg5XadAZ80hJs3mn7y2ku+byNR9gEudk2 d2blaeCpZaZwWdX0e3OCjFLl7oQuAURtmwdxS4B/zKfqq8FMWPxKxsmVIOyepoia cMnCl8wiQtUIDmULSCAFnPBq1zUswUi06sdWYFeXkNFzFKZkX2JvBEVo3n/QnX0M AP+/W0rOWuyNme/+1pH4w8SsWn+l8fmz/VpVZ+96L1TpeXDTpzgyM4gijNHj0KBO rgVjeqzVIKha9ouYAYjFHuMgvgy++s6JWQWfIjhR6m1dfvXVw+GCKcu+50IrHGEp 0LKPg3XWT6Nh+t6TMAGq+tb8tOnyeqlgTsOAoDi6G8z/QCw04xuHsh2o2CW+bqCy 0+4vTdrJlq3DI1zx2BwoWGmPaYh62g4vml5xndOvDseCFV0zEA8= =0TU6 -----END PGP SIGNATURE----- --70qxKngOD8VOMtRVrEiQO5tJbSTrwAwgx-- From nobody Mon Apr 2 16:33:02 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD2E1252BA for ; Mon, 2 Apr 2018 16:33:00 -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 RyIjh2GmOcLV for ; Mon, 2 Apr 2018 16:32:54 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 11751124E15 for ; Mon, 2 Apr 2018 16:32:54 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id h26-v6so17389226otj.12 for ; Mon, 02 Apr 2018 16:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8oKMfmDc493A2Zc7Ev1EoCM17xdbSVmwx+rMzjhfhJI=; b=hjLuKsRQTbMAtslMGIQBzyUId2Q5Jq7947ZrDZkx7wDGuV8lkU7HNamA4Hp9lS4IML IZHHFTmNp9bHFsjFvPV2XojUcML/8BeuPrCQp8If4Z+5f+ga6SU2knmc5mAEHZQE4/oG GcGTDJsgcaV97DrNdmzxNRaQSbiWmBjVEuvUO590Kf8cFgDn0PHa89ZmzZtoF/rjq/mP Cyrv5ueJozXbkupDUPX3K4J3GrCeJL3qmXCMcTQF7oyCs0jnqyOpZmzYuG+aa9FcO+TP M2r+H35kBIRdnaFC69LY28G9JC+RzLKAVwZawdtVzyJn1Z4Qt8FQfIGjid/6fWhCMuPy UTZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8oKMfmDc493A2Zc7Ev1EoCM17xdbSVmwx+rMzjhfhJI=; b=mGzp7aV3rw54YvnG7tFqP/1+ok99RzuFLCnXTydLfEXsMvI6g0O1V9TkkUHvefaNTJ eGfX2FgZsd4P1pgr/plp6/2MRUl52Upk3YERf77EKvZBkqLY8s/Pov3hDHxvqgipYGE/ Gl5bOx9P/RKJ7jNnqdVzEe3CBNM3Ten7m/m5YhcX15rKdtpt1gWIXBiLXchk+27972pE g8+V3d3MhiPh2q8CRSNHf5+a7pLAmfaW9Cr2G3XNjZyc2WgQn1cXJulzvBnLhcVEzDxf olsXCjQ6kWdiyrltZuTJ0oUIag4AISURpqS+Q92flVNXbUvOK7LjvlLg2uEbHr63e5TO ojIw== X-Gm-Message-State: ALQs6tB7k25s4NR30RWU2tx1N7qBDfP7ToTVyiIH9zDWYBfCvrytB5qS UllLxU+WNnAi2Bo5eNSjHnqZ4OBCFTEoezyK/fJQbtBz X-Google-Smtp-Source: AIpwx4+TSBjLvg52fZ6d/F3e5z1JGHYKLla9F9cNwwiEzf1mFeVpuud+eFxoE724wqJLcY6QAGQKiL5zRhltGRTnl2s= X-Received: by 2002:a9d:3636:: with SMTP id w51-v6mr6047039otb.101.1522711973439; Mon, 02 Apr 2018 16:32:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Mon, 2 Apr 2018 16:32:12 -0700 (PDT) In-Reply-To: References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> From: Eric Rescorla Date: Mon, 2 Apr 2018 16:32:12 -0700 Message-ID: To: Henrik Levkowetz Cc: tools-discuss Content-Type: multipart/alternative; boundary="00000000000045b6ca0568e60255" Archived-At: Subject: Re: [Tools-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 23:33:01 -0000 --00000000000045b6ca0568e60255 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 2, 2018 at 4:27 PM, Henrik Levkowetz wrote: > > On 2018-04-03 01:12, Eric Rescorla wrote: > >> Given that the biggest problem right now is the number of lookups > >> generated individually per document, instead of being retrieved in > >> bulk by fewer more complex queries, the approach doesn't seem > >> promising. > >> > > I wonder if we're talking past each other. My point here is that many > > of these values aren't necessary to view the page. For instance, I'd > > be willing to have the page render but not be able to see the ballots > > or colors or whatever. Based on the description of the problem, it > > seems like you ought to be able to do that and then fetch those in > > the background, no? > > Yes. But I don't see that refactoring being any easier than the other > possible approaches. And I don't see it being inherently superior, > given that the raw database accesses currently take up only about 1/6 > of the the total time, when measured on my dev server. It's the > accumulated cost of fetching individual pieces from many different > places in the code and template that results in the long rendering time. > Yes, but the problem is that you aren't displaying *anything* until you have done all of them. -Ekr > > Henrik > > --00000000000045b6ca0568e60255 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 2, 2018 at 4:27 PM, Henrik Levkowetz <= henrik@levkowetz.= com> wrote:

On 2018-04-03 01:12, Eric Rescorla wrote:
>> Given that the biggest problem right now i= s the number of lookups
>> generated individually per document, instead of being retrieved in=
>> bulk by fewer more complex queries, the approach doesn't seem<= br> >> promising.
>>
> I wonder if we're talking past each other. My point here is that m= any
> of these values aren't necessary to view the page. For instance, I= 'd
> be willing to have the page render but not be able to see the ballots<= br> > or colors or whatever. Based on the description of the problem, it
> seems like you ought to be able to do that and then fetch those in
> the background, no?

Yes.=C2=A0 But I don't see that refactoring being any easier tha= n the other
possible approaches.=C2=A0 And I don't see it being inherently superior= ,
given that the raw database accesses currently take up only about 1/6
of the the total time, when measured on my dev server.=C2=A0 It's the accumulated cost of fetching individual pieces from many different
places in the code and template that results in the long rendering time.

Yes, but the problem is that you aren'= ;t displaying *anything* until you
have done all of them.

-Ekr



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik


--00000000000045b6ca0568e60255-- From nobody Mon Apr 2 16:49:27 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1C127076 for ; Mon, 2 Apr 2018 16:49:26 -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 ZlFjNHCA_LWp for ; Mon, 2 Apr 2018 16:49:24 -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 84B1E120721 for ; Mon, 2 Apr 2018 16:49:24 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:63565 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f39CV-0006El-GE; Mon, 02 Apr 2018 16:49:24 -0700 To: Eric Rescorla References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> Cc: tools-discuss From: Henrik Levkowetz Message-ID: Date: Tue, 3 Apr 2018 01:49:15 +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="TiNuknJKoAnvAkmVA8qd4nJT3S1FWiRJh" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.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-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 23:49:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TiNuknJKoAnvAkmVA8qd4nJT3S1FWiRJh Content-Type: multipart/mixed; boundary="W5vjc1CKaNhdeskBSQJHfVgluG3ffrrLk"; protected-headers="v1" From: Henrik Levkowetz To: Eric Rescorla Cc: tools-discuss Message-ID: Subject: Re: [Tools-discuss] Datatracker is being very slow References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> In-Reply-To: --W5vjc1CKaNhdeskBSQJHfVgluG3ffrrLk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-04-03 01:32, Eric Rescorla wrote: > On Mon, Apr 2, 2018 at 4:27 PM, Henrik Levkowetz = > wrote: >=20 >> >> On 2018-04-03 01:12, Eric Rescorla wrote: >> >> Given that the biggest problem right now is the number of lookups >> >> generated individually per document, instead of being retrieved in >> >> bulk by fewer more complex queries, the approach doesn't seem >> >> promising. >> >> >> > I wonder if we're talking past each other. My point here is that man= y >> > of these values aren't necessary to view the page. For instance, I'd= >> > be willing to have the page render but not be able to see the ballot= s >> > or colors or whatever. Based on the description of the problem, it >> > seems like you ought to be able to do that and then fetch those in >> > the background, no? >> >> Yes. But I don't see that refactoring being any easier than the other= >> possible approaches. And I don't see it being inherently superior, >> given that the raw database accesses currently take up only about 1/6 >> of the the total time, when measured on my dev server. It's the >> accumulated cost of fetching individual pieces from many different >> places in the code and template that results in the long rendering tim= e. >> >=20 > Yes, but the problem is that you aren't displaying *anything* until you= > have done all of them. Ack. True :-} Henrik --W5vjc1CKaNhdeskBSQJHfVgluG3ffrrLk-- --TiNuknJKoAnvAkmVA8qd4nJT3S1FWiRJh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrCwXsACgkQTptXS4+7 Fxo2pg//c6hzHgxCky3xoS6tfE/36IAIEpBLqHel+MpOIdGSnfBB5FAA+eI4igGj T/m0maHstGoZ2nHs+F8h1TmdsAPDVDEq6lAks6YeoT1YppPvjUkbEGvMxnV/GVIT pQ7OSPuemNhSXcJJ7SsHumK7bpAEQ0x2QZDDgZjLastufOXp/rQKZHl/SPLiCdD/ H17vNs2oVVpn85O1JahQRzteC92xyvrcYgIDoOnvWP5ixwnSi+pjCPu/Ivl+BXpH Qgy/Gl4u0oFWGRPweSzlZJuIvYXWBqKFBNj4hdViuHnvGmEcG7jKIig44giXIoHH ipl500/46ioBatI6rrMq9pZrgZb51JGY2aT2KzJUVQZ/44jeRKxNARCV5zcb29u6 Venkfdw4LsXBElsX2At1HaDdN/RhXAIWLvazOlWncvWXF4/333CdxLs43VRRmkLz U3J0H+BJQWXsX2pWKOWWa4xiiQBXHhx+pbYykqBhZnDxSbssbGADT8Jky0Kd/6hS MYkpe0nrhgEYQ/H7rDPOcWnT0qm9KYxPLmzApZRnTT+tQhAAckkxmjP5HcPqRDBW Yuch15/S2cmarzD6AmDHFBdcRa/SBxMdbOfWtUrJD/Mw8nvuBENBSpYDalT2rz1i kgQwQ1ErI5Xq+l3Uw7T1sfYYbpDJoq9+GQHaedlZga88VoQ+7WY= =1uFn -----END PGP SIGNATURE----- --TiNuknJKoAnvAkmVA8qd4nJT3S1FWiRJh-- From nobody Wed Apr 4 13:52:58 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F553127AD4 for ; Wed, 4 Apr 2018 13:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 wjEU8BDgA_e7 for ; Wed, 4 Apr 2018 13:52:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27D8126BF0 for ; Wed, 4 Apr 2018 13:52:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A9AFA20090 for ; Wed, 4 Apr 2018 17:02:44 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2DAB58110C for ; Wed, 4 Apr 2018 16:52:55 -0400 (EDT) From: Michael Richardson To: tools-discuss@ietf.org In-Reply-To: <152278530314.22763.12945914024430620449.idtracker@ietfa.amsl.com> References: <152278530314.22763.12945914024430620449.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Tools-discuss] format of AD ballot emails X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 20:52:57 -0000 --=-=-= Content-Type: text/plain Right now we see subjects like: Subject: [6tisch] Ben Campbell's No Objection on draft-ietf-6tisch-6top-protocol-11: (with COMMENT) I wonder if it might be worth changing this to: Subject: [6tisch] 6top-protocol-11: No Objection (COMMENT) from Ben Campbell. (i.e. with draft- always removed, with ietf- removed if it exists, and with the WG removed if it follows. So things like AD sponsored submissions might say, "richardson-foo-bar-fun-03) my goal here is just to group ballot positions together by draft name in MUA folders and in archives. The AD commenting is not as important as that there is something being said about a particular document. My appologies for asking what might be a bike-shed colour suggestion. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlrFOyYACgkQgItw+93Q 3WVi+Qf/Zq0fy8i+tY78SItzEHw8cL5ulJUdHo+oV1VRNNBcdVPSyW7phJuJYdSb JfCD4Si+sprtmiN5O7K4l452R+I679uA2LelIOWyhiC0Icpd7oIUPfq8Iq/djnGv tqe9+rr0hsEJrGdh0T/vzo0d0zZXo++2IvjwwhNxenXLJ0KyTfLgnQ+pAgQR+3Av nKrjTHLOmCuEaInO3ZvnMpvUygdW15BufdsFrZSdpSxsLnUUYsOTR8B3L5p5/j6b QA9rhY/t4am8O1cWmWByLeQYkoszuaeNGV7vYACD6qeGFRXs5reI2+ems/mmZs7m Zd5L5DhQ/0a8T7m2YfY0pblDmZGWEA== =Epx2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 5 06:53:58 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27B4120727; Thu, 5 Apr 2018 06:53:50 -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, 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 F_OqRIUbbkm3; Thu, 5 Apr 2018 06:53:48 -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 C2E44120726; Thu, 5 Apr 2018 06:53:48 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:62919 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f45Ki-00025A-KG; Thu, 05 Apr 2018 06:53:47 -0700 To: Michael Richardson , tools-discuss@ietf.org, WG Chairs References: <152278530314.22763.12945914024430620449.idtracker@ietfa.amsl.com> <518.1522875175@obiwan.sandelman.ca> From: Henrik Levkowetz Message-ID: <6975a66e-5c69-6ac4-8d5b-44e156ed3d40@levkowetz.com> Date: Thu, 5 Apr 2018 15:53:29 +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: <518.1522875175@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S2DKJCd9F6eG2JM23wUB8ouJcvDESbp60" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: wgchairs@ietf.org, tools-discuss@ietf.org, mcr+ietf@sandelman.ca 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-discuss] format of AD ballot emails X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 13:53:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S2DKJCd9F6eG2JM23wUB8ouJcvDESbp60 Content-Type: multipart/mixed; boundary="VNfRPse18gbrvq1q7Jj7T2FUMR2LNoTeL"; protected-headers="v1" From: Henrik Levkowetz To: Michael Richardson , tools-discuss@ietf.org, WG Chairs Message-ID: <6975a66e-5c69-6ac4-8d5b-44e156ed3d40@levkowetz.com> Subject: Re: [Tools-discuss] format of AD ballot emails References: <152278530314.22763.12945914024430620449.idtracker@ietfa.amsl.com> <518.1522875175@obiwan.sandelman.ca> In-Reply-To: <518.1522875175@obiwan.sandelman.ca> --VNfRPse18gbrvq1q7Jj7T2FUMR2LNoTeL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, Makes sense to me. Cc:ing wgchairs in case there are additional comments= =2E Henrik On 2018-04-04 22:52, Michael Richardson wrote: >=20 > Right now we see subjects like: >=20 > Subject: [6tisch] Ben Campbell's No Objection on > draft-ietf-6tisch-6top-protocol-11: (with COMMENT) >=20 > I wonder if it might be worth changing this to: >=20 > Subject: [6tisch] 6top-protocol-11: No Objection (COMMENT) from Ben Cam= pbell. >=20 > (i.e. with draft- always removed, with ietf- removed if it exists, > and with the WG removed if it follows. So things like AD sponsored > submissions might say, "richardson-foo-bar-fun-03) >=20 > my goal here is just to group ballot positions together by draft name i= n MUA > folders and in archives. The AD commenting is not as important as that= there > is something being said about a particular document. >=20 > My appologies for asking what might be a bike-shed colour suggestion. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 > ___________________________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss >=20 > Please report datatracker.ietf.org and mailarchive.ietf.org > bugs at http://tools.ietf.org/tools/ietfdb > or send email to datatracker-project@ietf.org >=20 > Please report tools.ietf.org bugs at > http://tools.ietf.org/tools/issues > or send email to webmaster@tools.ietf.org >=20 --VNfRPse18gbrvq1q7Jj7T2FUMR2LNoTeL-- --S2DKJCd9F6eG2JM23wUB8ouJcvDESbp60 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrGKmAACgkQTptXS4+7 FxqbjQ//aEinbsADxcMc5ZAkjwb6ziTZTLUgHX5e61tmEkL4Y6XW0fH9bk0clkG0 zZUnnh8XftXFQHGga1sfysa13anIXKgl+Ox8MOtzJzdmVoit9dhByzxJn2VNcT5A AlBnAKAbtda/ltbOcsqskyWrmzTirAt1VQ1SxYdbkaRpk8QGvUW7SmWgx4jESmmV k+V4WjBXPPmLaYrF1P6Ce56iQ78mQo+K+ezvYA4HnHG6TEwx1xLBVJuH1zRmPplj F+JgjvI1rbQxOyQa2h2sh327jE7VC9S6zSBkk8bO8/gikng5x688h9zEnhsfwNYm nhp7bStqX50JOHRC7I5Zi1zOvUYeSikAsQ8fRn3XBHGhp4x2OznpD8TR7loSvULg QBfcKhJKKqCC4/ukz8ytnhfT7S7gyrBBktdJz1buZY7FZ4A6RURwJcJzw6a+lvH3 hWqNgRz5FAPIO4CoDZi22bzMgYh0UgElQdqpAy2vfW6eAITlSh8pTbtJQ2jENsst FX8bqM9eFRckzX0mB1H/e9ll7tk/qbmBKNcM6yqM5LKOULJuGJ4U8eVyDidB3dJJ 0AP0OEc/SX47gmiF24gbKlyie9MQnqDoxiWXcyeyrYjenpa7AqO0c8nJnlqT8oXE LIIBQpSJtUG1ZYnnheGlwutTPp2FosSImfV6jYPf6gCQwGSRMAM= =iqQP -----END PGP SIGNATURE----- --S2DKJCd9F6eG2JM23wUB8ouJcvDESbp60-- From nobody Thu Apr 5 07:21:24 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7292212D889; Thu, 5 Apr 2018 07:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 1xa0cxgZ4Per; Thu, 5 Apr 2018 07:21:16 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261E61205D3; Thu, 5 Apr 2018 07:21:16 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id A2A01120B90; Thu, 5 Apr 2018 16:21:14 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 84DA640081; Thu, 5 Apr 2018 16:21:14 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0382.000; Thu, 5 Apr 2018 16:21:14 +0200 From: To: Henrik Levkowetz , Michael Richardson CC: "tools-discuss@ietf.org" , WG Chairs Thread-Topic: [Tools-discuss] format of AD ballot emails Thread-Index: AQHTzOWLUhB4P1O0hkG4fbprIgE/MqPyMjHQ Date: Thu, 5 Apr 2018 14:21:14 +0000 Message-ID: <3011_1522938074_5AC630DA_3011_28_1_53C29892C857584299CBF5D05346208A479FF153@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <152278530314.22763.12945914024430620449.idtracker@ietfa.amsl.com> <518.1522875175@obiwan.sandelman.ca> <6975a66e-5c69-6ac4-8d5b-44e156ed3d40@levkowetz.com> In-Reply-To: <6975a66e-5c69-6ac4-8d5b-44e156ed3d40@levkowetz.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Tools-discuss] format of AD ballot emails X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 14:21:18 -0000 SGksDQoNClN0YXJ0aW5nIHdpdGggdGhlIG5hbWUgb2YgdGhlIGRyYWZ0IHdvdWxkIG1ha2Ugc2Vu c2UgdG8gbWUgYXMgdGhpcyB3b3VsZCBmb2xsb3cgdGhlIGhpZXJhcmNoeSBbV0ddIGRyYWZ0OiBh Y3Rpb24gDQoNCklNTyBJJ2QgcmF0aGVyIHVzZSB0aGUgZnVsbCBuYW1lIG9mIHRoZSBkcmFmdCBm b3IgY29uc2lzdGVuY3kgd2l0aCBleGlzdGluZyBzZWFyY2hpbmcgaGFiaXRzLCBjb25zaXN0ZW5j eSB3aGVuIHRoZSBuYW1lIG9mIHRoZSBkcmFmdCBtYXkgbm90IGFsaWduIHdpdGggdGhlIG5hbWUg b2YgdGhlIFdHIChlLmcuIExTUiBXRyBpcyBub3cgd29ya2luZyBvbiBkcmFmdC1pZXRmLWlzaXMg YW5kIGRyYWZ0LWlldGYtb3NwZiBkb2N1bWVudHMpLg0KDQpJZiB0aGUgYWJvdmUgY2hhbmdlIGlz IGFwcGxpZWQsIHdlIG1pZ2h0IGNvbnNpZGVyIGl0IGZvciBhbGwgZ2VuZXJhdGVkIGVtYWlscy4g ZS5nLg0KDQpPTEQ6ICBSdGdkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXRlYXMt YWN0bi1mcmFtZXdvcmstMTENCk5FVzogZHJhZnQtaWV0Zi10ZWFzLWFjdG4tZnJhbWV3b3JrLTEx OiBSdGdkaXIgbGFzdCBjYWxsIHJldmlldw0KDQpPTEQ6ICBbc3ByaW5nXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3AtMDEudHh0DQpORVc6 IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50ZXJvcC0w MS50eHQ6IEktRCBBY3Rpb24NCg0KT0xEOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTEyLnR4dA0KTkVXOiBkcmFmdC1p ZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0xMi50eHQ6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbg0KDQpPTEQ6ICBQcm90b2NvbCBBY3Rpb246ICdTZWdtZW50IFJvdXRpbmcgQXJjaGl0 ZWN0dXJlJyB0byBQcm9wb3NlZCBTdGFuZGFyZCAoZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1y b3V0aW5nLTE1LnR4dCkNCk5FVzogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLTE1 LnR4dDogUHJvdG9jb2wgQWN0aW9uICdTZWdtZW50IFJvdXRpbmcgQXJjaGl0ZWN0dXJlJyB0byBQ cm9wb3NlZCBTdGFuZGFyZA0KDQpBbmQgc28gb24uLi4NCg0KLS1CcnVubw0KDQogPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KID4gRnJvbTogV0dDaGFpcnMgW21haWx0bzp3Z2NoYWlycy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGVucmlrIExldmtvd2V0eg0KID4gU2VudDog VGh1cnNkYXksIEFwcmlsIDA1LCAyMDE4IDM6NTMgUE0NCiA+IFRvOiBNaWNoYWVsIFJpY2hhcmRz b247IHRvb2xzLWRpc2N1c3NAaWV0Zi5vcmc7IFdHIENoYWlycw0KID4gU3ViamVjdDogUmU6IFtU b29scy1kaXNjdXNzXSBmb3JtYXQgb2YgQUQgYmFsbG90IGVtYWlscw0KID4gDQogPiBIaSBNaWNo YWVsLA0KID4gDQogPiBNYWtlcyBzZW5zZSB0byBtZS4gIENjOmluZyB3Z2NoYWlycyBpbiBjYXNl IHRoZXJlIGFyZSBhZGRpdGlvbmFsIGNvbW1lbnRzLg0KID4gDQogPiAJSGVucmlrDQogPiANCiA+ IE9uIDIwMTgtMDQtMDQgMjI6NTIsIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZToNCiA+ID4NCiA+ ID4gUmlnaHQgbm93IHdlIHNlZSBzdWJqZWN0cyBsaWtlOg0KID4gPg0KID4gPiBTdWJqZWN0OiBb NnRpc2NoXSBCZW4gQ2FtcGJlbGwncyBObyBPYmplY3Rpb24gb24NCiA+ID4gICAgICAgICAgICAg ICAgICAgZHJhZnQtaWV0Zi02dGlzY2gtNnRvcC1wcm90b2NvbC0xMTogKHdpdGggQ09NTUVOVCkN CiA+ID4NCiA+ID4gSSB3b25kZXIgaWYgaXQgbWlnaHQgYmUgd29ydGggY2hhbmdpbmcgdGhpcyB0 bzoNCiA+ID4NCiA+ID4gU3ViamVjdDogWzZ0aXNjaF0gNnRvcC1wcm90b2NvbC0xMTogTm8gT2Jq ZWN0aW9uIChDT01NRU5UKSBmcm9tIEJlbiBDYW1wYmVsbC4NCiA+ID4NCiA+ID4gKGkuZS4gd2l0 aCBkcmFmdC0gYWx3YXlzIHJlbW92ZWQsIHdpdGggaWV0Zi0gcmVtb3ZlZCBpZiBpdCBleGlzdHMs DQogPiA+IGFuZCB3aXRoIHRoZSBXRyByZW1vdmVkIGlmIGl0IGZvbGxvd3MuICBTbyB0aGluZ3Mg bGlrZSBBRCBzcG9uc29yZWQNCiA+ID4gc3VibWlzc2lvbnMgbWlnaHQgc2F5LCAicmljaGFyZHNv bi1mb28tYmFyLWZ1bi0wMykNCiA+ID4NCiA+ID4gbXkgZ29hbCBoZXJlIGlzIGp1c3QgdG8gZ3Jv dXAgYmFsbG90IHBvc2l0aW9ucyB0b2dldGhlciBieSBkcmFmdCBuYW1lIGluIE1VQQ0KID4gPiBm b2xkZXJzIGFuZCBpbiBhcmNoaXZlcy4gIFRoZSBBRCBjb21tZW50aW5nIGlzIG5vdCBhcyBpbXBv cnRhbnQgYXMgdGhhdCB0aGVyZQ0KID4gPiBpcyBzb21ldGhpbmcgYmVpbmcgc2FpZCBhYm91dCBh IHBhcnRpY3VsYXIgZG9jdW1lbnQuDQogPiA+DQogPiA+IE15IGFwcG9sb2dpZXMgZm9yIGFza2lu ZyB3aGF0IG1pZ2h0IGJlIGEgYmlrZS1zaGVkIGNvbG91ciBzdWdnZXN0aW9uLg0KID4gPg0KID4g Pg0KID4gPiAtLQ0KID4gPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5j YT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KID4gPiAgLT0gSVB2NiBJb1QgY29uc3VsdGlu ZyA9LQ0KID4gPg0KID4gPg0KID4gPg0KID4gPg0KID4gPg0KID4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KID4gPiBUb29scy1k aXNjdXNzIG1haWxpbmcgbGlzdA0KID4gPiBUb29scy1kaXNjdXNzQGlldGYub3JnDQogPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdG9vbHMtZGlzY3Vzcw0KID4gPg0K ID4gPiBQbGVhc2UgcmVwb3J0IGRhdGF0cmFja2VyLmlldGYub3JnIGFuZCBtYWlsYXJjaGl2ZS5p ZXRmLm9yZw0KID4gPiBidWdzIGF0IGh0dHA6Ly90b29scy5pZXRmLm9yZy90b29scy9pZXRmZGIN CiA+ID4gb3Igc2VuZCBlbWFpbCB0byBkYXRhdHJhY2tlci1wcm9qZWN0QGlldGYub3JnDQogPiA+ DQogPiA+IFBsZWFzZSByZXBvcnQgdG9vbHMuaWV0Zi5vcmcgYnVncyBhdA0KID4gPiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvdG9vbHMvaXNzdWVzDQogPiA+IG9yIHNlbmQgZW1haWwgdG8gd2VibWFz dGVyQHRvb2xzLmlldGYub3JnDQogPiA+DQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Thu Apr 5 07:27:17 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9DF12D944; Thu, 5 Apr 2018 07:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=tziryxlg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YykOw9PN 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 krz0Y25VIsZq; Thu, 5 Apr 2018 07:27:13 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A4E12D88F; Thu, 5 Apr 2018 07:27:12 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4AE4E2094D; Thu, 5 Apr 2018 10:27:12 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 05 Apr 2018 10:27:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=mLwJgeP8DZWeRS/fFxemTvUny6zH9 tnc7XY8EMP/sRE=; b=tziryxlgyuME9BK2NN+MrE7isv9Ocy0lGs/n88N/SeoaV 9hOxbn91JV49Y10wdbffZZP0xDy2JuPceaNM/THw6gcQNN7hmOj59JmwUT293aR7 GWKkS9iWbpxtWwLgC+WYR+fcC/jnqdEQpfPDK37NqmGmo8++3BfzRnMZgMvRKP0S S7bD96LjW9HqbaB6KAqM+t84GRdCDndzzE+X9jYOZAtGrO1hdseiSrhnStI7XWNa r6Q0BnOiYtRLSFJOmSAE6evmJDSGAaDjn0Z6FC4/hNGvHYZ1lJOXztVUbHNWKvL4 t5xNC9LsRw9XHOpYpap2un6MQjoLkxKHduJg5v3Rg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=mLwJge P8DZWeRS/fFxemTvUny6zH9tnc7XY8EMP/sRE=; b=YykOw9PNyOni7O853HbHcn o0QDglFdMt4uvnQM6c0+NTt/sgErQNBwsSBnoyQWHyGrUYO54iY4KW+iNppAcqJ8 wrLT2jmuDr58oBy/s+dyoXlw6Ga4nJ83q64poNDuTK8Iy6JJoW6rjqZjJyNrKMJs FPXyXvb+QoEn/xOcdMLnQH/cT6+RY1HSRuDZVJHBgVTS3i/LRgL/bAIX7naZIi/X 5mJ/btFwt1bpUwxVprNHL7+90isX6ZScEMNuyueOM8nCv7QbTLTFcCzuzM7gfXed EWof578VlzyWoPxMr4qwEfcLhKPxxMSSUL9RzGkhuqERPKGdDqrtsuFQPAxGhdkA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2C6699E094; Thu, 5 Apr 2018 10:27:12 -0400 (EDT) Message-Id: <1522938432.1964497.1327646184.5CA7E84C@webmail.messagingengine.com> From: Alexey Melnikov To: Henrik Levkowetz , Michael Richardson , tools-discuss@ietf.org, WG Chairs MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-61ab7380 In-Reply-To: <6975a66e-5c69-6ac4-8d5b-44e156ed3d40@levkowetz.com> References: <152278530314.22763.12945914024430620449.idtracker@ietfa.amsl.com> <518.1522875175@obiwan.sandelman.ca> <6975a66e-5c69-6ac4-8d5b-44e156ed3d40@levkowetz.com> Date: Thu, 05 Apr 2018 15:27:12 +0100 Archived-At: Subject: Re: [Tools-discuss] format of AD ballot emails X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 14:27:16 -0000 Hi, My personal opinion: I don't mind reordering, but I would rather not strip the draft prefix name, because searching for a draft is so much easier in my email early in the morning, if I don't need to remember to strip the prefix. So I prefer: Subject: [6tisch] draft-ietf-6tisch-6top-protocol-11: No Objection (COMMENT) from Ben Campbell. Best Regards, Alexey On Thu, Apr 5, 2018, at 2:53 PM, Henrik Levkowetz wrote: > Hi Michael, > > Makes sense to me. Cc:ing wgchairs in case there are additional comments. > > Henrik > > On 2018-04-04 22:52, Michael Richardson wrote: > > > > Right now we see subjects like: > > > > Subject: [6tisch] Ben Campbell's No Objection on > > draft-ietf-6tisch-6top-protocol-11: (with COMMENT) > > > > I wonder if it might be worth changing this to: > > > > Subject: [6tisch] 6top-protocol-11: No Objection (COMMENT) from Ben Campbell. > > > > (i.e. with draft- always removed, with ietf- removed if it exists, > > and with the WG removed if it follows. So things like AD sponsored > > submissions might say, "richardson-foo-bar-fun-03) > > > > my goal here is just to group ballot positions together by draft name in MUA > > folders and in archives. The AD commenting is not as important as that there > > is something being said about a particular document. > > > > My appologies for asking what might be a bike-shed colour suggestion. > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > > > > > ___________________________________________________________ > > Tools-discuss mailing list > > Tools-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/tools-discuss > > > > Please report datatracker.ietf.org and mailarchive.ietf.org > > bugs at http://tools.ietf.org/tools/ietfdb > > or send email to datatracker-project@ietf.org > > > > Please report tools.ietf.org bugs at > > http://tools.ietf.org/tools/issues > > or send email to webmaster@tools.ietf.org > > > > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) From nobody Thu Apr 5 08:13:58 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4051312DA06; Thu, 5 Apr 2018 08:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 fl0RujQY4pfQ; Thu, 5 Apr 2018 08:13:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71E3129C70; Thu, 5 Apr 2018 08:13:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 51FD720090; Thu, 5 Apr 2018 11:23:47 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 25B518105F; Thu, 5 Apr 2018 11:13:55 -0400 (EDT) From: Michael Richardson To: Alexey Melnikov cc: Henrik Levkowetz , tools-discuss@ietf.org, WG Chairs In-Reply-To: <1522938432.1964497.1327646184.5CA7E84C@webmail.messagingengine.com> References: <152278530314.22763.12945914024430620449.idtracker@ietfa.amsl.com> <518.1522875175@obiwan.sandelman.ca> <6975a66e-5c69-6ac4-8d5b-44e156ed3d40@levkowetz.com> <1522938432.1964497.1327646184.5CA7E84C@webmail.messagingengine.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Tools-discuss] format of AD ballot emails X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 15:13:57 -0000 --=-=-= Content-Type: text/plain Alexey Melnikov wrote: > My personal opinion: I don't mind reordering, but I would rather not > strip the draft prefix name, because searching for a draft is so much > easier in my email early in the morning, if I don't need to remember to > strip the prefix. The full draft name would still be in the body. but, I can live with not stripping. I was simply trying to optimize for subject line width. > Subject: [6tisch] draft-ietf-6tisch-6top-protocol-11: No Objection > (COMMENT) from Ben Campbell. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlrGPTIACgkQgItw+93Q 3WXnCwgAk639xlid+6oG1jdqpFmRH6oKINtmOF1FbffMf/+vZ2hXIWdOih94GnE7 cgxAQJQn3h5CkVhJudQfga37HXECPX7LgG5Z/XB0Y/zDrN77fbcppyLgEUXOJKOw M8yoq1aVy2CE3qiqjIz+SR2oX2Qv9Q5NhODpCYmiRYzd5OpA6fNNCioQQILR5nk0 1qpRyE/Z0YQxMkUWbG+Z6aF2aGkbM1YqLszl3Ok7qXYhOmddewI0e0NG+WlfH3uv lTqxLZEtPWB5Cmh95THglMdVgp1xtCfxrGH76zEtZzRlvJApjk5Fhf//kqXowECN Uff+xfPjz4cwGQAsgU75JX98KJrMzQ== =IPqV -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 5 12:46:34 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F63120721; Thu, 5 Apr 2018 12:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 z1GXmjyS1yF5; Thu, 5 Apr 2018 12:46:30 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97094120713; Thu, 5 Apr 2018 12:46:29 -0700 (PDT) X-AuditID: 12074423-42bff700000009f5-bc-5ac67d1265db Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 6A.89.02549.21D76CA5; Thu, 5 Apr 2018 15:46:27 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w35JkOHX018199; Thu, 5 Apr 2018 15:46:25 -0400 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w35JkIla019118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Apr 2018 15:46:21 -0400 Date: Thu, 5 Apr 2018 14:46:18 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: WG Chairs , Henrik Levkowetz , tools-discuss@ietf.org Message-ID: <20180405194618.GR80088@mit.edu> References: <152278530314.22763.12945914024430620449.idtracker@ietfa.amsl.com> <518.1522875175@obiwan.sandelman.ca> <6975a66e-5c69-6ac4-8d5b-44e156ed3d40@levkowetz.com> <1522938432.1964497.1327646184.5CA7E84C@webmail.messagingengine.com> <2277.1522941235@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wxDdMuZNg1r63Hyj" Content-Disposition: inline In-Reply-To: <2277.1522941235@obiwan.sandelman.ca> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsUixCmqrStceyzKYM1nNovmtkNsFj2H+tkt th+Zy2jxf/8URgcWjyVLfjJ5LJ+/g9GjZc4e5gDmKC6blNSczLLUIn27BK6MWRu2MRd08FUs PWfewNjB08XIySEhYCKxZtVl5i5GLg4hgcVMEj+nPmSCcDYwShz+cIoVwjnDJHG1/TErSAuL gIrEugMb2EBsNiC7oRuknZNDREBPYvmRZ4wgNrNAtsStPS1g9cIC5hJLHj4Ds3kFdCQalh+H WjebSeLgwmlQCUGJkzOfsEA0l0lc7bvI3sXIAWRLSyz/xwFicgoYSaw8owhSISqgLLG37xD7 BEaBWUiaZyFpnoXQDBHWkrjx7yUThrC2xLKFr5khbFuJdevesyxgZF/FKJuSW6Wbm5iZU5ya rFucnJiXl1qka6aXm1mil5pSuokRFCHsLso7GF/2eR9iFOBgVOLhFQg7FiXEmlhWXJl7iFGS g0lJlHeLLlCILyk/pTIjsTgjvqg0J7X4EKMK0K5HG1ZfYJRiycvPS1US4XUGaeVNSaysSi3K hymT5mBREuddvH9vlJBAemJJanZqakFqEUxWhoNDSYL3cDVQo2BRanpqRVpmTglCmomD8xCj BAcP0HDpGpDhxQWJucWZ6RD5U4yKUuK8ViAJAZBERmkeXC8osUlk7695xSgO9JYw70qQFTzA pAjX/QpoMBPQ4AmJR0AGlyQipKQaGOu/HXo6cZt7f+havpMrAr3XZ/IvabzF4C+5uOln+OkD jQZCcZMcVzTyr3/2XXeJc+v/v/s9l7H8nq3aGF54SnLOrhxt5xf9pyKMGrfPSXkS2cLKffVX sfHus8ufGtpEB6zdWa2+Y/FmU3upvf3NnqpuT66aseXyP9CyX5WqPjlcdXuXpM7xDiWW4oxE Qy3mouJEAF1nE1pHAwAA Archived-At: Subject: Re: [Tools-discuss] format of AD ballot emails X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 19:46:32 -0000 --wxDdMuZNg1r63Hyj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 05, 2018 at 11:13:55AM -0400, Michael Richardson wrote: >=20 > Alexey Melnikov wrote: > > My personal opinion: I don't mind reordering, but I would rather not > > strip the draft prefix name, because searching for a draft is so mu= ch > > easier in my email early in the morning, if I don't need to remembe= r to > > strip the prefix. >=20 > The full draft name would still be in the body. > but, I can live with not stripping. > I was simply trying to optimize for subject line width. I understand the desire to reduce the subject line width, and so am only mildly negative about removing "draft-". I feel more strongly that the "ietf-" and WG should be retained, as that is helpful for scoping the document, for those of us receiving the mail not through a WG list (e.g., via iesg@). -Ben --wxDdMuZNg1r63Hyj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlrGfQQACgkQKNmm82Tr dRI50Awgh6sVOBF2L4VMqEKFbFD2Xz0goQ1t/pq5n2Gj5IUfZnQIhniNAiMfxVhd fXZxfV0JBzSaXbh9yhRVDqgvlaZRM9bjXks5dZGt5u1vKIzaLZ5zuXDH6UsKPeYd KosaZ+IVmmvptroC4yHFFDL3WedZeSbEPTkIb0UKTEMQYpNZ2Cs40Y01PDQJJ/K9 pHV9TEIIFlyE/gFQVVz1/xS7wQaQySR+GoBvjEarXJ5dZIAJ5NBP43xpyFEmK4hy Vyuo5aD/lu6iPnXNzZ/5O3ZJrxlXNvYy9bA/REmg5/mGsWaPurc/3o9Q378+ufza gdPE/NTjPMN3pi4OVJRT4gGAYchLtPGGST1EoLjJjgJb7ohZ9pEnjrfuh0zsek5K kGicxmqrj3EwUhO9H3G3AQm+FAS7yX1N1yp5/x/L4fKsysQd+eFYWHgMTmcwLxdQ 9I0Ij+wA/LWl3/rWWGNf2osWrjCLh+JUEvnvux0ELyhhIWJjFJwCa0SUd6QRO+Cx lWRrXdI6GEhPDQ== =ZKNA -----END PGP SIGNATURE----- --wxDdMuZNg1r63Hyj-- From nobody Thu Apr 5 13:25:21 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1621112D7E2; Thu, 5 Apr 2018 13:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic8VYdApQCv5; Thu, 5 Apr 2018 13:25:17 -0700 (PDT) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (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 8495912D77B; Thu, 5 Apr 2018 13:25:17 -0700 (PDT) Received: by mail-pl0-x231.google.com with SMTP id g20-v6so20805087plo.9; Thu, 05 Apr 2018 13:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2YuFdvZLMdG3OBgd3cALkTDCh1guUDbQ7yQtDP5xkh8=; b=FnHO4niUNodBUY4JK61yJlHjUq/j4E8sNlaXo8+erCFZrfo98vuDaOtdQ0Yfc009ph kq79bADZ96a9lG5+PXc0wx93m9Fe+Eqoijz9AnpkYIZkdwMvtqwPi4vemGoOfogAt/Qx 7MqYnD+cMyA63oFV7dOWO1MtCStduR2ly/fXfianFF/yJJHcAcOck7ruiWxmGiBt2aNC 2y88LX9AOnwFBlqpgNwkV/yZJIzdjGf0KItu9mbYqn3tOQnFe89qGy+Z0GfVkVKyfd51 2ukvD/RuBLRZZHytQ9XkTQ25DrvLE4pdQXrlqPxTz1FOp/5iHExRGT/pAd6FhZ6P67yO pbcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2YuFdvZLMdG3OBgd3cALkTDCh1guUDbQ7yQtDP5xkh8=; b=Xm21a5GlJMBKQT803Q6RX3vscfUSoG2TfmQAtzIE+fgnAtH2V50+B+5S0IhlSX75jd GOi/qSvEXEZ3nEwQ85yc4JGIWqsuHBEWJOVbBiAGim2CDqiAKXEqV59i0Zgq3P56E6kZ 8wB7pNbrqC98hq1jUp/G4vzrrw5oSTER74k8zJ/Mqg80GKg5a6HTb876+EewkFw4Bxxi CfgHhkog1gQzWh9zLPifu6UbnnetC/gID79C+r5Y3eoCUOp2G7C+oDkMrbaHLA/PQaGj r7SUIyv2jSYkPl9oj5HEy+6cZG757H9v2ePtGd2HM9mAwSmjExPkklBNra1/+bt0roGy fkCg== X-Gm-Message-State: AElRT7F+cpw/GX+b2r1sgGWKWfnv37CFf2WMppr/HWlqEgC689ifKrq5 CHpJ4y0EMqff3G1ej0q3zytBBg== X-Google-Smtp-Source: AIpwx4+Pvbk/3at8k8/QV5Heaz+OfgxwYBC7USXgdy1i9HOmhSgGZJOjzOU7FnRyOx97Lpt9OaKbrg== X-Received: by 2002:a17:902:6a85:: with SMTP id n5-v6mr24526742plk.313.1522959916880; Thu, 05 Apr 2018 13:25:16 -0700 (PDT) Received: from [192.168.178.26] (207.26.255.123.static.snap.net.nz. [123.255.26.207]) by smtp.gmail.com with ESMTPSA id f64sm16394968pfa.154.2018.04.05.13.25.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 13:25:15 -0700 (PDT) Sender: Brian Carpenter To: Alexey Melnikov , Henrik Levkowetz , Michael Richardson , tools-discuss@ietf.org, WG Chairs References: <152278530314.22763.12945914024430620449.idtracker@ietfa.amsl.com> <518.1522875175@obiwan.sandelman.ca> <6975a66e-5c69-6ac4-8d5b-44e156ed3d40@levkowetz.com> <1522938432.1964497.1327646184.5CA7E84C@webmail.messagingengine.com> From: Brian E Carpenter Message-ID: <03f4e4fa-29ee-9b99-e00e-3a0bdb2a4eee@gmail.com> Date: Fri, 6 Apr 2018 08:25:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1522938432.1964497.1327646184.5CA7E84C@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-discuss] format of AD ballot emails X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 20:25:19 -0000 On 06/04/2018 02:27, Alexey Melnikov wrote: > Hi, > > My personal opinion: I don't mind reordering, but I would rather not strip the draft prefix name, because searching for a draft is so much easier in my email early in the morning, if I don't need to remember to strip the prefix. > > So I prefer: > > Subject: [6tisch] draft-ietf-6tisch-6top-protocol-11: No Objection (COMMENT) from Ben Campbell. +1, especially since not all WG lists insert [WGname] otoh my sorting and filtering doesn't care where the draft name appears in the subject, so from my point of view the change has no real value. Brian From nobody Thu Apr 5 14:33:16 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A266127AD4 for ; Thu, 5 Apr 2018 14:33:16 -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 mVgIlcAD2pil for ; Thu, 5 Apr 2018 14:33:11 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (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 6DD8C12D80E for ; Thu, 5 Apr 2018 14:33:11 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id 23-v6so29028916otj.0 for ; Thu, 05 Apr 2018 14:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qADNQfvy0fB43TrUfJLkI9ViyRsEx57ltq3SKFiqviQ=; b=ZimEZWH0LA1tDDXjKpyqDGBcBSQYC6pI2jcSuKtgt9Oaj/mV33+vhDCN89/2Uf/GuY 1B51XJKsOR1h44HfxmEUFrSOhX0zh99as8USyvF66MS81McIg9EmEOUjb9vkgL0GM6f8 Ji08jK13ZOTxHD1ruISheNVwWm2EP1hSUF5IFSMLHczejmDjpaX2+HRWhxUXtQ8GuNSS ZdCegtaN9U/4q9YrbCWEP2osuAGR2kWNmUBnotDhlwGjmIrk8XHQ8jwJrov76NSXwgH/ MZpejUEGbwIiA8rtYMyUTsIJMa0uTNGvuh1mjvw4h3aJKN/QqyktO8D8EmlMlvOyrAwQ amJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qADNQfvy0fB43TrUfJLkI9ViyRsEx57ltq3SKFiqviQ=; b=Il5ZDcyPavpdWRIKexNhV2iOx8KhKjWa/97inJFnpxiqpM1b//2qTyDAcxxzuMFX16 4lEfEySCivEsyFXKc6/hxLxU0/rPOl2deSLdWI+amKJb8OdRb7MAt3FSxCtIfaI3JnpI gUitcIrH8OdWDAUTuF2AN/WfzYDj0Fi++EO4jLleop0fpR5o0i0qENf4/lmSuNa6P63D UtZqQx+c+r1xZrE/hErOnVG8RS9+E49cMm5n+Ywa0QwdgIb8qpLnnpNeVQq7pObg9bZs /gBZ1FmvDfTqX4qAeMmvK0ow31/8YS73XdMYORHndZo0yRYnspoCj+UjRdMShMEldd95 W7bA== X-Gm-Message-State: ALQs6tA/QvDpL2SROurPVK0ih6uXTRDhRqtgJwXEo6eK6FkGCNqHjKKK +CHTEsVn/RR9DZ6h5RM2xs7dlSQACnE0XTujsQiqjw8l X-Google-Smtp-Source: AIpwx49JuBJa1i/Wj2sVVRWWaVHGYCZGtxGIRD0VMVscrhj90+dUKy1B3TwNIFvGgjbKO6deWdSKms7Ue4O0tHJwuc4= X-Received: by 2002:a9d:5919:: with SMTP id t25-v6mr11684644oth.217.1522963990728; Thu, 05 Apr 2018 14:33:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Thu, 5 Apr 2018 14:32:30 -0700 (PDT) In-Reply-To: <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> From: Eric Rescorla Date: Thu, 5 Apr 2018 14:32:30 -0700 Message-ID: To: Henrik Levkowetz Cc: tools-discuss Content-Type: multipart/alternative; boundary="000000000000ac6679056920af15" Archived-At: Subject: Re: [Tools-discuss] Auto-posting IESG ballots X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 21:33:16 -0000 --000000000000ac6679056920af15 Content-Type: text/plain; charset="UTF-8" Thanks, Henrik, I got this working and can now mechanically post reviews from Phabricator to the datatracker (at least to the sandbox). Happy to share the code once I get it more polished. -Ekr On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz wrote: > Hi Ekr, > > In yesterday's datatracker release 6.68.0, now deployed, an API to auto- > post iesg ballot positions was included. > > A brief description of usage, with an example, is available here: > > https://datatracker.ietf.org/api/#iesg-position-api > > The limitations on the API keys follow what we discussed below. For > testing > purposes, you may want to use the datatracker sandbox, > > https://sandbox.ietf.org/ > > where your password is 'password' (as is that of everybody else). > > Any personal API keys you create on the sandbox server will not carry over > to the production site, and will be overwritten within 24 hours when the > next database update comes in from the production site (just after 5 in the > morning, PST). The same goes for positions and other changes you may make. > > Please let me know when you've had time to try it out, and of course if you > have comments and questions about the API endpoint. > > > Best regards, > > Henrik > > > On 2017-10-18 20:50, Eric Rescorla wrote: > > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz > > > wrote: > > > >> > >> On 2017-10-18 17:37, Eric Rescorla wrote: > >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz < > henrik@levkowetz.com> > >> > wrote: > >> > > >> >> > >> >> On 2017-10-18 16:58, Eric Rescorla wrote: > >> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz < > >> henrik@levkowetz.com> > >> >> > wrote: > >> >> > > >> >> >> > >> >> >> On 2017-10-18 16:47, Eric Rescorla wrote: > >> >> >> > Thanks. I would actually be fine with replicating the existing > API > >> >> >> surface > >> >> >> > (it's not that hard to generate form fills), as long as I could > >> use an > >> >> >> API > >> >> >> > key rather than a cookie, because it's a real pain to replicate > the > >> >> >> > anti-CSRF logic. > >> >> >> > >> >> >> I'm fine with an API key as alternative to anti-CSRF, but would > not > >> >> like to > >> >> >> rely on only that for authorization. > >> >> > > >> >> > > >> >> > I was thinking a per-user API token > >> >> > >> >> Yes, I assumed that. > >> >> > >> >> > the way that (say) the Github API works. > >> >> > Would that be a problem? > >> >> > >> >> I'll go and check the github API key details and the way they are > used. > >> >> > >> >> Essentially, what you're proposing is to use a combined > authentication > >> >> and authorization token instead of username+password. If that token > >> >> doesn't leak, it should not be a problem. If it leaks, it's of > course > >> >> a potential problem. > >> >> > >> > > >> > Right, but of course that's the situation for a password as well. > >> > >> Agreed, but you clearly aim to limit exposure of the password more > >> strongly than the API key. To counterbalance this, I believe the > >> API key should be limited in what it authorizes the holder to do. > >> More below. > >> > > > > This seems conceptually fine. > > > > > >>> One property of API keys is often that they have a limited lifetime, > >> >> in order to reduce the impact of leakage. Given what you write > below, > >> >> I guess that's a property you would like to avoid, too? Or would > that > >> >> be acceptable? > >> >> > >> > > >> > Yes, I would like to avoid that. The invariant I want to have here is > >> that > >> > I can provision the bridging server (the one that moves data back and > >> > forth between phabricator and the data tracker) with credentials for > >> > each side and then let it run indefinitely. At the end of the day, > >> > one might imagine merging that logic into phab or the datatracker > >> > or both, but because you want to avoid polling, the upshot will > >> > still be distribution of credentials. > >> > >> Right. > >> > >> Ok, so in order to limit the damage an exposed API key can do, here are > >> some thoughts: > >> > >> * Provide a GUI to revoke a key (necessary in any case) and give > >> an overview of existing keys and their usage. > >> > > > > This seems like a good plan. > > > > > > * Time limit the validity of the key to N days (30?) from the time of > >> the latest login to the datatracker using username+password. > >> > > > > Yeah, this seems like it would probably work though might be brittle. > > > > > > * Limit the key to a given URL path prefix (e.g., /api/iesg/ballot/) > >> This means having multiple keys if we evolve additional API > endpoints, > >> which I expect to happen. > >> > >> * Provide regular information in the datatracker GUI about API key > >> activity in a manner easily digested and minimally distracting. > >> Maybe a message once a week, summarising the activity? > >> > > > > Both of these seem like good ideas. > > > > -Ekr > > > > > >> > >> Thoughts? > >> > >> Henrik > >> > >> > >> > > >> > -Ekr > >> > > >> > > >> >> > Are you ok with doing a regular login > >> >> >> cycle to cookie storage ahead of posting to the form with the API > >> key? > >> >> >> > >> >> > > >> >> > I could also do this as long as the cookie was perpetual so I could > >> >> > log in through my browser and then store the cookie on the server. > >> >> > I'd like to avoid having my password on the server. > >> >> > >> >> Understood. > >> >> > >> >> Henrik > >> >> > >> >> > > >> >> > -Ekr > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >> > >> >> >> Henrik > >> >> >> > >> >> >> > -Ekr > >> >> >> > > >> >> >> > > >> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, Henrik Levkowetz < > >> >> henrik@levkowetz.com> > >> >> >> > wrote: > >> >> >> > > >> >> >> >> Hi Ekr, > >> >> >> >> > >> >> >> >> On 2017-10-17 15:52, Eric Rescorla wrote: > >> >> >> >> > Hi folks. > >> >> >> >> > > >> >> >> >> > I've been working some more on my IETF review tools and I'm > now > >> at > >> >> the > >> >> >> >> point > >> >> >> >> > where I want to take an external review and hoist it into the > >> IESG > >> >> >> >> Ballot. > >> >> >> >> > Is there > >> >> >> >> > an existing API surface for this kind of thing? Perhaps one > >> which > >> >> >> takes > >> >> >> >> an > >> >> >> >> > auth token > >> >> >> >> > so no CSRF/cookie nonsense? > >> >> >> >> > >> >> >> >> No, there isn't, but adding an endpoint for this isn't that > hard. > >> >> There > >> >> >> >> are things ahead of it in the queue, though ,:-) > >> >> >> >> > >> >> >> >> > >> >> >> >> Best regards, > >> >> >> >> > >> >> >> >> Henrik > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> > >> > > >> > >> > > > > > > > > --000000000000ac6679056920af15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Henrik,

I got this w= orking and can now mechanically post reviews from Phabricator to the datatr= acker (at least to the sandbox).

Happy to shar= e the code once I get it more polished.

-Ekr
=



On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowe= tz <henrik@levkowetz.com> wrote:
Hi Ekr,

In yesterday's datatracker release 6.68.0, now deployed, an API to auto= -
post iesg ballot positions was included.

A brief description of usage, with an example, is available here:

=C2=A0 https://datatracker.ietf.org/api/#ie= sg-position-api

The limitations on the API keys follow what we discussed below.=C2=A0 For t= esting
purposes, you may want to use the datatracker sandbox,

=C2=A0 https://sandbox.ietf.org/

where your password is 'password' (as is that of everybody else).
Any personal API keys you create on the sandbox server will not carry over<= br> to the production site, and will be overwritten within 24 hours when the next database update comes in from the production site (just after 5 in the=
morning, PST).=C2=A0 The same goes for positions and other changes you may = make.

Please let me know when you've had time to try it out, and of course if= you
have comments and questions about the API endpoint.


Best regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik


On 2017-10-18 20:50, Eric Rescorla wrote:
> On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz <henrik@levkowetz.com>
> wrote:
>
>>
>> On 2017-10-18 17:37, Eric Rescorla wrote:
>> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz <henrik@levkowetz.com= >
>> > wrote:
>> >
>> >>
>> >> On 2017-10-18 16:58, Eric Rescorla wrote:
>> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz &l= t;
>> henrik@l= evkowetz.com>
>> >> > wrote:
>> >> >
>> >> >>
>> >> >> On 2017-10-18 16:47, Eric Rescorla wrote:
>> >> >> > Thanks. I would actually be fine with repli= cating the existing API
>> >> >> surface
>> >> >> > (it's not that hard to generate form fi= lls), as long as I could
>> use an
>> >> >> API
>> >> >> > key rather than a cookie, because it's = a real pain to replicate the
>> >> >> > anti-CSRF logic.
>> >> >>
>> >> >> I'm fine with an API key as alternative to a= nti-CSRF, but would not
>> >> like to
>> >> >> rely on only that for authorization.
>> >> >
>> >> >
>> >> > I was thinking a per-user API token
>> >>
>> >> Yes, I assumed that.
>> >>
>> >> > the way that (say) the Github API works.
>> >> > Would that be a problem?
>> >>
>> >> I'll go and check the github API key details and the = way they are used.
>> >>
>> >> Essentially, what you're proposing is to use a combin= ed authentication
>> >> and authorization token instead of username+password.=C2= =A0 If that token
>> >> doesn't leak, it should not be a problem.=C2=A0 If it= leaks, it's of course
>> >> a potential problem.
>> >>
>> >
>> > Right, but of course that's the situation for a password = as well.
>>
>> Agreed, but you clearly aim to limit exposure of the password more=
>> strongly than the API key.=C2=A0 To counterbalance this, I believe= the
>> API key should be limited in what it authorizes the holder to do.<= br> >> More below.
>>
>
> This seems conceptually fine.
>
>
>>> One property of API keys is often that they have a limited lif= etime,
>> >> in order to reduce the impact of leakage.=C2=A0 Given wha= t you write below,
>> >> I guess that's a property you would like to avoid, to= o?=C2=A0 Or would that
>> >> be acceptable?
>> >>
>> >
>> > Yes, I would like to avoid that. The invariant I want to have= here is
>> that
>> > I can provision the bridging server (the one that moves data = back and
>> > forth between phabricator and the data tracker) with credenti= als for
>> > each side and then let it run indefinitely. At the end of the= day,
>> > one might imagine merging that logic into phab or the datatra= cker
>> > or both, but because you want to avoid polling, the upshot wi= ll
>> > still be distribution of credentials.
>>
>> Right.
>>
>> Ok, so in order to limit the damage an exposed API key can do, her= e are
>> some thoughts:
>>
>>=C2=A0 * Provide a GUI to revoke a key (necessary in any case) and = give
>>=C2=A0 =C2=A0 an overview of existing keys and their usage.
>>
>
> This seems like a good plan.
>
>
>=C2=A0 * Time limit the validity of the key to N days (30?) from the ti= me of
>>=C2=A0 =C2=A0 the latest login to the datatracker using username+pa= ssword.
>>
>
> Yeah, this seems like it would probably work though might be brittle.<= br> >
>
>=C2=A0 * Limit the key to a given URL path prefix (e.g., /api/iesg/ball= ot/)
>>=C2=A0 =C2=A0 This means having multiple keys if we evolve addition= al API endpoints,
>>=C2=A0 =C2=A0 which I expect to happen.
>>
>>=C2=A0 * Provide regular information in the datatracker GUI about A= PI key
>>=C2=A0 =C2=A0 activity in a manner easily digested and minimally di= stracting.
>>=C2=A0 =C2=A0 Maybe a message once a week, summarising the activity= ?
>>
>
> Both of these seem like good ideas.
>
> -Ekr
>
>
>>
>> Thoughts?
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>>
>>
>> >
>> > -Ekr
>> >
>> >
>> >> > Are you ok with doing a regular login
>> >> >> cycle to cookie storage ahead of posting to the = form with the API
>> key?
>> >> >>
>> >> >
>> >> > I could also do this as long as the cookie was perpe= tual so I could
>> >> > log in through my browser and then store the cookie = on the server.
>> >> > I'd like to avoid having my password on the serv= er.
>> >>
>> >> Understood.
>> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>> >>
>> >> >
>> >> > -Ekr
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>> >> >>
>> >> >> > -Ekr
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, Henrik Lev= kowetz <
>> >> henrik@levkowetz.com>
>> >> >> > wrote:
>> >> >> >
>> >> >> >> Hi Ekr,
>> >> >> >>
>> >> >> >> On 2017-10-17 15:52, Eric Rescorla wrot= e:
>> >> >> >> > Hi folks.
>> >> >> >> >
>> >> >> >> > I've been working some more on= my IETF review tools and I'm now
>> at
>> >> the
>> >> >> >> point
>> >> >> >> > where I want to take an external r= eview and hoist it into the
>> IESG
>> >> >> >> Ballot.
>> >> >> >> > Is there
>> >> >> >> > an existing API surface for this k= ind of thing? Perhaps one
>> which
>> >> >> takes
>> >> >> >> an
>> >> >> >> > auth token
>> >> >> >> > so no CSRF/cookie nonsense?
>> >> >> >>
>> >> >> >> No, there isn't, but adding an endp= oint for this isn't that hard.
>> >> There
>> >> >> >> are things ahead of it in the queue, th= ough ,:-)
>> >> >> >>
>> >> >> >>
>> >> >> >> Best regards,
>> >> >> >>
>> >> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik=
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
>
>


--000000000000ac6679056920af15-- From nobody Thu Apr 5 17:20:19 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BDE12E055; Thu, 5 Apr 2018 17:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDU_K4mDuCsC; Thu, 5 Apr 2018 17:20:16 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::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 0B95812E04B; Thu, 5 Apr 2018 17:20:16 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id u5-v6so12034882ybf.4; Thu, 05 Apr 2018 17:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M4Y92h5QVJ+nW+5IepgyjAwOUvMfNx0bzXbIKTpfvjA=; b=n1ZvzHgKe963VwAZuPyg0Y62W5tlwopFPTwWM0+9H8r1H9h4jkglaP/K/Wfp2e9h3B yddhJrwQlk3JWxUQsSIldqtccPaSh+KKmr6iHOKBJ4PlWS8aEP3oyXAQ/chB61EKvDvI YkaCqxTXuqymYjbIGc38ZnIzkTCOQfC4qx6lof/37G1k7pIQsOe36sL+1UJvwTfht31y zKf5BRrqxK5RERi05LB/qMWmEjz9EuY4Ww57SjxczBFwJIvRrkTN33fUDIuLCQs73f2G 8VlDDVrgrORtIW0l2XmZteYpcnBLUr20f1/8VwxFmFjSUUBXZsZej/hK/uxzx1EfxNxF qr6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M4Y92h5QVJ+nW+5IepgyjAwOUvMfNx0bzXbIKTpfvjA=; b=U6L+ar/0L87Dx8rctclmYMm81jVxtTdiHPNHvoRhOQOytNNVrz82PSTHWTZJM8kcA+ Eyi8PbBOA6Kvq3lxvT2bYQmCdc8OzkKmYZHEdCi6IJiJeyoa/ce/5gOlD0YE7bPJazjE r3cP6rHwf/EcbxLaT0vaRCx3ZPYkrSdSsy3dEWbLFER9azbVPLpNilCyBpiTR8E/yiUD WGUmpsl1+gCBqMAox0YFZ1Rz7tkbe9lIN0JZPdKa2U/sOkqFl3ouACFNuYLuWAhTvexY C4jGH1WvYEKPW7e065id5gSQ/IH6r/joZ8ox77bAZscYsHGoy48QamTXkV1zFAypnKSv rcRw== X-Gm-Message-State: ALQs6tBAzysOkiTJKG2QQIyI9FXKSQg3bMY4v26tbnX4ED9mxS2uCC+O 6jdcoD2jM1ALmGCJ2LEBSrUI9T3d2k7LKuTTRRo= X-Google-Smtp-Source: AIpwx48z4uTdWnL7zqebc69kiaUGlXvGeAMluD0r39PJjjUegIgx1pihVLzvtHabROGJvkn0b33paL1djyN4OX1oTtI= X-Received: by 2002:a25:1e44:: with SMTP id e65-v6mr14517723ybe.221.1522974015057; Thu, 05 Apr 2018 17:20:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:e757:0:0:0:0:0 with HTTP; Thu, 5 Apr 2018 17:20:14 -0700 (PDT) In-Reply-To: <20180405194618.GR80088@mit.edu> References: <152278530314.22763.12945914024430620449.idtracker@ietfa.amsl.com> <518.1522875175@obiwan.sandelman.ca> <6975a66e-5c69-6ac4-8d5b-44e156ed3d40@levkowetz.com> <1522938432.1964497.1327646184.5CA7E84C@webmail.messagingengine.com> <2277.1522941235@obiwan.sandelman.ca> <20180405194618.GR80088@mit.edu> From: Spencer Dawkins at IETF Date: Thu, 5 Apr 2018 19:20:14 -0500 Message-ID: To: Benjamin Kaduk Cc: Michael Richardson , WG Chairs , Henrik Levkowetz , Tools Team Discussion Content-Type: multipart/alternative; boundary="0000000000002b739c056923055d" Archived-At: Subject: Re: [Tools-discuss] [irsg] format of AD ballot emails X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 00:20:18 -0000 --0000000000002b739c056923055d Content-Type: text/plain; charset="UTF-8" Since a new AD who is almost certainly tuning his mail filter rules like a madman surfaced ... (hi, Benjamin!), On Thu, Apr 5, 2018 at 2:46 PM, Benjamin Kaduk wrote: > On Thu, Apr 05, 2018 at 11:13:55AM -0400, Michael Richardson wrote: > > > > Alexey Melnikov wrote: > > > My personal opinion: I don't mind reordering, but I would rather > not > > > strip the draft prefix name, because searching for a draft is so > much > > > easier in my email early in the morning, if I don't need to > remember to > > > strip the prefix. > > > > The full draft name would still be in the body. > > but, I can live with not stripping. > > I was simply trying to optimize for subject line width. > > I understand the desire to reduce the subject line width, and so am > only mildly negative about removing "draft-". I feel more strongly > that the "ietf-" and WG should be retained, as that is helpful for > scoping the document, for those of us receiving the mail not through > a WG list (e.g., via iesg@). > I often wish that IESG ballots used a different mailing list for IESG members than the usual IESG mailing list, which collects mail on almost every topic that has ever interested an IETF participant. I've beaten my own mail filter rules into submission so that I can isolate balloting e-mail, and I hardly ever miss anything, but being able to say "if it's on THIS mailing list, put it HERE" would be super helpful. (And now that I've typed that, I note that subscriptions to an IESG-ballot mailing list could be a lot more widely available than the IESG mailing list, which collects a lot of stuff that's not intended for public viewing, and ISTM there's no obvious reason the archives wouldn't be world-viewable) But Your Mileage May Vary, of course. Spencer, who is waiting to order a saddle for this unicorn until he actually needs one ... --0000000000002b739c056923055d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since a new AD who is almost certainly tuning his mail fil= ter rules like a madman surfaced ... (hi, Benjamin!),=C2=A0

On Thu, Apr 5, 2018 at 2:46 PM, B= enjamin Kaduk <kaduk@mit.edu> wrote:
On Thu, Apr 05, 2018 at 11:13:55AM -0400, Michael R= ichardson wrote:
>
> Alexey Melnikov <aamelnik= ov@fastmail.fm> wrote:
>=C2=A0 =C2=A0 =C2=A0> My personal opinion: I don't mind reorderi= ng, but I would rather not
>=C2=A0 =C2=A0 =C2=A0> strip the draft prefix name, because searching= for a draft is so much
>=C2=A0 =C2=A0 =C2=A0> easier in my email early in the morning, if I = don't need to remember to
>=C2=A0 =C2=A0 =C2=A0> strip the prefix.
>
> The full draft name would still be in the body.
> but, I can live with not stripping.
> I was simply trying to optimize for subject line width.

I understand the desire to reduce the subject line width, and so am<= br> only mildly negative about removing "draft-".=C2=A0 I feel more s= trongly
that the "ietf-" and WG should be retained, as that is helpful fo= r
scoping the document, for those of us receiving the mail not through
a WG list (e.g., via iesg@).

I often wi= sh that IESG ballots used a different mailing list for IESG members than th= e usual IESG mailing list, which collects mail on almost every topic that h= as ever interested an IETF participant. I've beaten my own mail filter = rules into submission so that I can isolate balloting e-mail, and I hardly = ever miss anything, but being able to say "if it's on THIS mailing= list, put it HERE" would be super helpful.=C2=A0

=
(And now that I've typed that, I note that subscriptions to an IES= G-ballot mailing list could be a lot more widely available than the IESG ma= iling list, which collects a lot of stuff that's not intended for publi= c viewing, and ISTM there's no obvious reason the archives wouldn't= be world-viewable)

But Your Mileage May Vary, of = course.

Spencer, who is waiting to order a saddle = for this unicorn until he actually needs one ...
--0000000000002b739c056923055d-- From nobody Sun Apr 8 05:45:20 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E20E120727 for ; Sun, 8 Apr 2018 05:45:19 -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 xJWoulg9gAEi for ; Sun, 8 Apr 2018 05:45:17 -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 57EFB120724 for ; Sun, 8 Apr 2018 05:45:17 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:56365 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f59h5-0000hG-Cc; Sun, 08 Apr 2018 05:45:16 -0700 To: Eric Rescorla References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> Cc: tools-discuss From: Henrik Levkowetz Message-ID: Date: Sun, 8 Apr 2018 14:45:00 +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="h3Qo082gOdUH4hwFoDuqq9C9p3o8S1nJ7" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.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-discuss] Auto-posting IESG ballots X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 12:45:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h3Qo082gOdUH4hwFoDuqq9C9p3o8S1nJ7 Content-Type: multipart/mixed; boundary="2DGpewCAqkwghc9LgkpnTTpl6Aw1UcMSG"; protected-headers="v1" From: Henrik Levkowetz To: Eric Rescorla Cc: tools-discuss Message-ID: Subject: Re: [Tools-discuss] Auto-posting IESG ballots References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> In-Reply-To: --2DGpewCAqkwghc9LgkpnTTpl6Aw1UcMSG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ekr, On 2018-04-05 23:32, Eric Rescorla wrote: > Thanks, Henrik, >=20 > I got this working and can now mechanically post reviews from Phabricat= or > to the datatracker (at least to the sandbox). Oh, good :-) > Happy to share the code once I get it more polished. Ack; hopefully that will be helpful to other ADs. Henrik > -Ekr >=20 >=20 >=20 >=20 > On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz > wrote: >=20 >> Hi Ekr, >> >> In yesterday's datatracker release 6.68.0, now deployed, an API to aut= o- >> post iesg ballot positions was included. >> >> A brief description of usage, with an example, is available here: >> >> https://datatracker.ietf.org/api/#iesg-position-api >> >> The limitations on the API keys follow what we discussed below. For >> testing >> purposes, you may want to use the datatracker sandbox, >> >> https://sandbox.ietf.org/ >> >> where your password is 'password' (as is that of everybody else). >> >> Any personal API keys you create on the sandbox server will not carry = over >> to the production site, and will be overwritten within 24 hours when t= he >> next database update comes in from the production site (just after 5 i= n the >> morning, PST). The same goes for positions and other changes you may = make. >> >> Please let me know when you've had time to try it out, and of course i= f you >> have comments and questions about the API endpoint. >> >> >> Best regards, >> >> Henrik >> >> >> On 2017-10-18 20:50, Eric Rescorla wrote: >> > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz > > >> > wrote: >> > >> >> >> >> On 2017-10-18 17:37, Eric Rescorla wrote: >> >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz < >> henrik@levkowetz.com> >> >> > wrote: >> >> > >> >> >> >> >> >> On 2017-10-18 16:58, Eric Rescorla wrote: >> >> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz < >> >> henrik@levkowetz.com> >> >> >> > wrote: >> >> >> > >> >> >> >> >> >> >> >> On 2017-10-18 16:47, Eric Rescorla wrote: >> >> >> >> > Thanks. I would actually be fine with replicating the exist= ing >> API >> >> >> >> surface >> >> >> >> > (it's not that hard to generate form fills), as long as I c= ould >> >> use an >> >> >> >> API >> >> >> >> > key rather than a cookie, because it's a real pain to repli= cate >> the >> >> >> >> > anti-CSRF logic. >> >> >> >> >> >> >> >> I'm fine with an API key as alternative to anti-CSRF, but wou= ld >> not >> >> >> like to >> >> >> >> rely on only that for authorization. >> >> >> > >> >> >> > >> >> >> > I was thinking a per-user API token >> >> >> >> >> >> Yes, I assumed that. >> >> >> >> >> >> > the way that (say) the Github API works. >> >> >> > Would that be a problem? >> >> >> >> >> >> I'll go and check the github API key details and the way they ar= e >> used. >> >> >> >> >> >> Essentially, what you're proposing is to use a combined >> authentication >> >> >> and authorization token instead of username+password. If that t= oken >> >> >> doesn't leak, it should not be a problem. If it leaks, it's of >> course >> >> >> a potential problem. >> >> >> >> >> > >> >> > Right, but of course that's the situation for a password as well.= >> >> >> >> Agreed, but you clearly aim to limit exposure of the password more >> >> strongly than the API key. To counterbalance this, I believe the >> >> API key should be limited in what it authorizes the holder to do. >> >> More below. >> >> >> > >> > This seems conceptually fine. >> > >> > >> >>> One property of API keys is often that they have a limited lifetim= e, >> >> >> in order to reduce the impact of leakage. Given what you write >> below, >> >> >> I guess that's a property you would like to avoid, too? Or woul= d >> that >> >> >> be acceptable? >> >> >> >> >> > >> >> > Yes, I would like to avoid that. The invariant I want to have her= e is >> >> that >> >> > I can provision the bridging server (the one that moves data back= and >> >> > forth between phabricator and the data tracker) with credentials = for >> >> > each side and then let it run indefinitely. At the end of the day= , >> >> > one might imagine merging that logic into phab or the datatracker= >> >> > or both, but because you want to avoid polling, the upshot will >> >> > still be distribution of credentials. >> >> >> >> Right. >> >> >> >> Ok, so in order to limit the damage an exposed API key can do, here= are >> >> some thoughts: >> >> >> >> * Provide a GUI to revoke a key (necessary in any case) and give >> >> an overview of existing keys and their usage. >> >> >> > >> > This seems like a good plan. >> > >> > >> > * Time limit the validity of the key to N days (30?) from the time = of >> >> the latest login to the datatracker using username+password. >> >> >> > >> > Yeah, this seems like it would probably work though might be brittle= =2E >> > >> > >> > * Limit the key to a given URL path prefix (e.g., /api/iesg/ballot/= ) >> >> This means having multiple keys if we evolve additional API >> endpoints, >> >> which I expect to happen. >> >> >> >> * Provide regular information in the datatracker GUI about API key= >> >> activity in a manner easily digested and minimally distracting. >> >> Maybe a message once a week, summarising the activity? >> >> >> > >> > Both of these seem like good ideas. >> > >> > -Ekr >> > >> > >> >> >> >> Thoughts? >> >> >> >> Henrik >> >> >> >> >> >> > >> >> > -Ekr >> >> > >> >> > >> >> >> > Are you ok with doing a regular login >> >> >> >> cycle to cookie storage ahead of posting to the form with the= API >> >> key? >> >> >> >> >> >> >> > >> >> >> > I could also do this as long as the cookie was perpetual so I = could >> >> >> > log in through my browser and then store the cookie on the ser= ver. >> >> >> > I'd like to avoid having my password on the server. >> >> >> >> >> >> Understood. >> >> >> >> >> >> Henrik >> >> >> >> >> >> > >> >> >> > -Ekr >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> > -Ekr >> >> >> >> > >> >> >> >> > >> >> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, Henrik Levkowetz < >> >> >> henrik@levkowetz.com> >> >> >> >> > wrote: >> >> >> >> > >> >> >> >> >> Hi Ekr, >> >> >> >> >> >> >> >> >> >> On 2017-10-17 15:52, Eric Rescorla wrote: >> >> >> >> >> > Hi folks. >> >> >> >> >> > >> >> >> >> >> > I've been working some more on my IETF review tools and = I'm >> now >> >> at >> >> >> the >> >> >> >> >> point >> >> >> >> >> > where I want to take an external review and hoist it int= o the >> >> IESG >> >> >> >> >> Ballot. >> >> >> >> >> > Is there >> >> >> >> >> > an existing API surface for this kind of thing? Perhaps = one >> >> which >> >> >> >> takes >> >> >> >> >> an >> >> >> >> >> > auth token >> >> >> >> >> > so no CSRF/cookie nonsense? >> >> >> >> >> >> >> >> >> >> No, there isn't, but adding an endpoint for this isn't tha= t >> hard. >> >> >> There >> >> >> >> >> are things ahead of it in the queue, though ,:-) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Best regards, >> >> >> >> >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> > >> > >> >> >=20 >=20 >=20 > ___________________________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss >=20 > Please report datatracker.ietf.org and mailarchive.ietf.org > bugs at http://tools.ietf.org/tools/ietfdb > or send email to datatracker-project@ietf.org >=20 > Please report tools.ietf.org bugs at > http://tools.ietf.org/tools/issues > or send email to webmaster@tools.ietf.org >=20 --2DGpewCAqkwghc9LgkpnTTpl6Aw1UcMSG-- --h3Qo082gOdUH4hwFoDuqq9C9p3o8S1nJ7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrKDswACgkQTptXS4+7 FxogzxAApMjAnbPNmxVQdHBKuhmwgM/5cZiNl5kfcA0CEzZYrMSSfYpTt9lDzc+N nq5ozlzR05OR7g91E4iqc24NoU6KO2yDgQQQqKcjVBLAw0EH4lMGe9EDisFrf4en LSwISDJIlZsohVRNZrwI/qGUdf7mzFxAN2rWLahM4pafFwHjggE5qUgbP+GczfrX 78W4kuiobGm0bkxk0kFet1t1590QODamb/I1VKsebME0G2znVnbJoju0VChTOYjc Swaub7W5q3cJjyvdsOCMkIuJmTM4fWcxOhtOJbFIknxAMfq3wgkwR3erTjPxqBtg Daf7urR8gkFdit99QwR729ERawsWnr1VaBkLoyv/CUkrJA+KSxtcXZ4j9xRtIGiN oOmPFCOJAJWhjipFoIbqXjrPkRaBUYzEhTsbiU8q80FKkkE2daOPerexA5+hMw1Q O3jz+aXTov+Hlap2fRRW+halJN+sr55//iTKx5GuYrSelQnU1+hcrMvF/Ez2qSZD j2aB99usyBc+am06Hg+E0ZX62kU9yJ6lOGs3Bwzp9d1xxpGKdqLpyrhOxcjfFQWa Q1jz/9CiBOz3CA+Vn2KaOnQSEdOqsD5qGdgCTkNNMFPKT/CRtg0Ihza9v0vEwh0k yqf/ynpWsmPa9MOVMjpr+T/13vxooyJSNX9oMr1Lepst3kECGes= =jBJn -----END PGP SIGNATURE----- --h3Qo082gOdUH4hwFoDuqq9C9p3o8S1nJ7-- From nobody Mon Apr 16 12:51:53 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2A3126E01 for ; Mon, 16 Apr 2018 12:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 KqdBpai9kqFJ for ; Mon, 16 Apr 2018 12:51:51 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::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 070C9126DCA for ; Mon, 16 Apr 2018 12:51:51 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id o9-v6so18803184otj.5 for ; Mon, 16 Apr 2018 12:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8CRSCyQd71Koz8iZ5eb8CzF2uJVwdMRYUKmNA3ZAJgg=; b=1gRQWW1L8Z57gss0vaGbTgHcuA7Ok1JlyZc8BQwp42M5GF6x4WEfprwBSXEDs9cYNK zNRaLfi6fAEGHlt+O7HRUODJhgXTi+m8W8svjkKwQJmO4b8LAQjx7/rW8ha5w4oPEYIk ToUo/5RXhIavwpduTAYuMsOFpW1oA2g/zZ5BRbV9YVl3xUo6YdDf0gEW0QlXzcqV0CM7 VyZ2L3bgiX+Um7DofHM8bkz72xXdxxB49Rx1Z3Wda5Cub7y3JPVDc9NkHPisPeWSg9yJ Nts4hHQgIAA+YrJAjnaG/iuxZ/93KKfawMM+KwJal1TdOCt1Y/Anybb/zcwuI5yLnoZ9 7aaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8CRSCyQd71Koz8iZ5eb8CzF2uJVwdMRYUKmNA3ZAJgg=; b=WabZ+2aWJ3Kcpc7EzMau7ZAcq2EcU/nr+xt1B8LYjccvf/ohdTFkx55mIvKM99YLh2 znwe5du5E8B29JCR/e/66iHZd9cLAegjlghX4ctuF46C5SSFWXhWX4g127wTO31NQ+ww 8R8uJUNd2cjtnMDigGHma8geZzh8Vd4ngTX+qfRw6rlBHPMRqtkrJ+Na9hpolAEUN+eL 1XreYZjaJ9CRndr4NkONBQXsCV7g2iYb6e6jRAxrKBMUjOq2eTwv0QvCpcPYG3oNQ49J ytikO3l5GiMhtBtMz1baIvG8CLSleDEebzNM0ZBJ/vn88oawFz5Lsboc2Ccgd4lyKFSh KYtQ== X-Gm-Message-State: ALQs6tAQcAMyPFTVY+mEIL7PGz8rQP/kv1TgTltp3rOV2lhZ9mffAkR1 /pyeOMn3N49y7mPw2GtHxrQDd+8yEmIVCqk5VU/lpJDA X-Google-Smtp-Source: AIpwx49qnJGdUKD+U3pbdLGMePSSN29qHfKQqbpPZlAuhbwS/1Lw4yB5BRiLotOqu4CPiJDFANue5Ka4uATHSvvXnzA= X-Received: by 2002:a9d:5919:: with SMTP id t25-v6mr8219343oth.217.1523908310372; Mon, 16 Apr 2018 12:51:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.132 with HTTP; Mon, 16 Apr 2018 12:51:09 -0700 (PDT) In-Reply-To: References: <3b98c262-6e2b-d41a-17b1-2ecc30057e3a@levkowetz.com> <75c1ceb9-fd47-b9d6-79af-506aa3e55765@levkowetz.com> <7489a941-ada4-d6ac-0ff8-278ae9f4b877@levkowetz.com> From: Eric Rescorla Date: Mon, 16 Apr 2018 12:51:09 -0700 Message-ID: To: Henrik Levkowetz Cc: tools-discuss Content-Type: multipart/alternative; boundary="00000000000082ce660569fc8d4d" Archived-At: Subject: Re: [Tools-discuss] Datatracker is being very slow X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:51:53 -0000 --00000000000082ce660569fc8d4d Content-Type: text/plain; charset="UTF-8" Update: ballotting via the API is now glacially slow. On Mon, Apr 2, 2018 at 4:49 PM, Henrik Levkowetz wrote: > > > On 2018-04-03 01:32, Eric Rescorla wrote: > > On Mon, Apr 2, 2018 at 4:27 PM, Henrik Levkowetz > > wrote: > > > >> > >> On 2018-04-03 01:12, Eric Rescorla wrote: > >> >> Given that the biggest problem right now is the number of lookups > >> >> generated individually per document, instead of being retrieved in > >> >> bulk by fewer more complex queries, the approach doesn't seem > >> >> promising. > >> >> > >> > I wonder if we're talking past each other. My point here is that many > >> > of these values aren't necessary to view the page. For instance, I'd > >> > be willing to have the page render but not be able to see the ballots > >> > or colors or whatever. Based on the description of the problem, it > >> > seems like you ought to be able to do that and then fetch those in > >> > the background, no? > >> > >> Yes. But I don't see that refactoring being any easier than the other > >> possible approaches. And I don't see it being inherently superior, > >> given that the raw database accesses currently take up only about 1/6 > >> of the the total time, when measured on my dev server. It's the > >> accumulated cost of fetching individual pieces from many different > >> places in the code and template that results in the long rendering time. > >> > > > > Yes, but the problem is that you aren't displaying *anything* until you > > have done all of them. > > Ack. True :-} > > Henrik > > --00000000000082ce660569fc8d4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Update: ballotting via the API is now glacially slow.
<= /div>

On Mon, Apr = 2, 2018 at 4:49 PM, Henrik Levkowetz <henrik@levkowetz.com> wrote:


On 2018-04-03 01:32, Eric Rescorla wrote:
> On Mon, Apr 2, 2018 at 4:27 PM, Henrik Levkowetz <henrik@levkowetz.com>
> wrote:
>
>>
>> On 2018-04-03 01:12, Eric Rescorla wrote:
>> >> Given that the biggest problem right now is the number of= lookups
>> >> generated individually per document, instead of being ret= rieved in
>> >> bulk by fewer more complex queries, the approach doesn= 9;t seem
>> >> promising.
>> >>
>> > I wonder if we're talking past each other. My point here = is that many
>> > of these values aren't necessary to view the page. For in= stance, I'd
>> > be willing to have the page render but not be able to see the= ballots
>> > or colors or whatever. Based on the description of the proble= m, it
>> > seems like you ought to be able to do that and then fetch tho= se in
>> > the background, no?
>>
>> Yes.=C2=A0 But I don't see that refactoring being any easier t= han the other
>> possible approaches.=C2=A0 And I don't see it being inherently= superior,
>> given that the raw database accesses currently take up only about = 1/6
>> of the the total time, when measured on my dev server.=C2=A0 It= 9;s the
>> accumulated cost of fetching individual pieces from many different=
>> places in the code and template that results in the long rendering= time.
>>
>
> Yes, but the problem is that you aren't displaying *anything* unti= l you
> have done all of them.

Ack.=C2=A0 True :-}

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik


--00000000000082ce660569fc8d4d-- From nobody Mon Apr 16 12:55:40 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155E4126FB3 for ; Mon, 16 Apr 2018 12:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 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_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] 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 xlBrLmJSlp8b for ; Mon, 16 Apr 2018 12:55:34 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 8F2741241F3 for ; Mon, 16 Apr 2018 12:55:34 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id y20-v6so4269872oix.5 for ; Mon, 16 Apr 2018 12:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L+o9GjtsMKS8QW9L5ITqhtpjpvE1MopRVXofkoysl34=; b=f9cZdX3OojM4B0WmRjYlj3y7qpr+Wot+jpdu0JVlKPhPVTjSw4QNSJdtIWRWatqSMT /fkF4EH5vw5uImAjTLtJ3m4y7xU2huGYlFdEWqOeGAS/VofPm1ZiWfFMTVGYk2DkskK3 YgPiHBybR9vntEP7wtnLdIMjVYYZO+cYK//CG8g23fyGJBUwZYnJ3ARdk2hvbJ6UEni0 Y/AW65dS3ov2xZVoiPPdTVdisd9KnQpB5G8Lf32ebCshHHNoUcaORstcUmLXS5rhPoSu NjkFooFjC9PRO37kY/RCpXGQF8uYuHItmExgY4ndLv3W09+8E2Df+dCwHQyFDamCIAEq br3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L+o9GjtsMKS8QW9L5ITqhtpjpvE1MopRVXofkoysl34=; b=klyJq12J+RfBzfEmJF3JWfrxyj93uqt4z27X/9opWr3f231cGe0i7jYDEXcaKHMIQi H/jA/qhem0NQILL8H/LR0GKQUSWK9YQoNPURywy+i5a4w0cOdibS1N4EP9Jyd80OGymi aIThuYZuyfuqeTEFWm4X3/7mOZPgl/w9ZeMFHUCJsbP3D9nCX//cFVQS0dTVKVIjdu6M DzxIma6h3yVe79Mj/kzXnhtBSb1NvztuLB31LNbSzvkWTKWdqiZ3o5GI8K577NmL+Sh0 wFhxz5RvWw695PteAPrxkk1sji7gT5WcmD5aOy5c5X5i9r1fnVkwu/G+DZCOPOjJQid4 uJEA== X-Gm-Message-State: ALQs6tBU8P1QG9NzsxSrmtj4y6QtWakO9TXEev7IVvl1/JyOt0c8nW6f il3AH14ofhAO/zbsXB+jiQmyIJhUBQdKCpq3K5vekg== X-Google-Smtp-Source: AIpwx4/8ogexwQvj86Rd19E4yYJ2cu/lrwGuCk/FNKPM4+xcmOmn9c6k4RrZA1L8ToDGVCTeTWDiySOmRYNgUrBwvSE= X-Received: by 2002:aca:c744:: with SMTP id x65-v6mr14863043oif.43.1523908533674; Mon, 16 Apr 2018 12:55:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.132 with HTTP; Mon, 16 Apr 2018 12:54:52 -0700 (PDT) In-Reply-To: References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> From: Eric Rescorla Date: Mon, 16 Apr 2018 12:54:52 -0700 Message-ID: To: Henrik Levkowetz Cc: tools-discuss Content-Type: multipart/alternative; boundary="000000000000d1fd870569fc9a1f" Archived-At: Subject: Re: [Tools-discuss] Auto-posting IESG ballots X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:55:38 -0000 --000000000000d1fd870569fc9a1f Content-Type: text/plain; charset="UTF-8" Hi Henrik, The ballot submission API is working great, but it doesn't seem to send email when I ballot. Would it be possible to add a parameter for that. or just have it always happen? -Ekr On Sun, Apr 8, 2018 at 5:45 AM, Henrik Levkowetz wrote: > Hi Ekr, > > On 2018-04-05 23:32, Eric Rescorla wrote: > > Thanks, Henrik, > > > > I got this working and can now mechanically post reviews from Phabricator > > to the datatracker (at least to the sandbox). > > Oh, good :-) > > > Happy to share the code once I get it more polished. > > Ack; hopefully that will be helpful to other ADs. > > Henrik > > > > -Ekr > > > > > > > > > > On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz > > wrote: > > > >> Hi Ekr, > >> > >> In yesterday's datatracker release 6.68.0, now deployed, an API to auto- > >> post iesg ballot positions was included. > >> > >> A brief description of usage, with an example, is available here: > >> > >> https://datatracker.ietf.org/api/#iesg-position-api > >> > >> The limitations on the API keys follow what we discussed below. For > >> testing > >> purposes, you may want to use the datatracker sandbox, > >> > >> https://sandbox.ietf.org/ > >> > >> where your password is 'password' (as is that of everybody else). > >> > >> Any personal API keys you create on the sandbox server will not carry > over > >> to the production site, and will be overwritten within 24 hours when the > >> next database update comes in from the production site (just after 5 in > the > >> morning, PST). The same goes for positions and other changes you may > make. > >> > >> Please let me know when you've had time to try it out, and of course if > you > >> have comments and questions about the API endpoint. > >> > >> > >> Best regards, > >> > >> Henrik > >> > >> > >> On 2017-10-18 20:50, Eric Rescorla wrote: > >> > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz < > henrik@levkowetz.com > >> > > >> > wrote: > >> > > >> >> > >> >> On 2017-10-18 17:37, Eric Rescorla wrote: > >> >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz < > >> henrik@levkowetz.com> > >> >> > wrote: > >> >> > > >> >> >> > >> >> >> On 2017-10-18 16:58, Eric Rescorla wrote: > >> >> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz < > >> >> henrik@levkowetz.com> > >> >> >> > wrote: > >> >> >> > > >> >> >> >> > >> >> >> >> On 2017-10-18 16:47, Eric Rescorla wrote: > >> >> >> >> > Thanks. I would actually be fine with replicating the > existing > >> API > >> >> >> >> surface > >> >> >> >> > (it's not that hard to generate form fills), as long as I > could > >> >> use an > >> >> >> >> API > >> >> >> >> > key rather than a cookie, because it's a real pain to > replicate > >> the > >> >> >> >> > anti-CSRF logic. > >> >> >> >> > >> >> >> >> I'm fine with an API key as alternative to anti-CSRF, but would > >> not > >> >> >> like to > >> >> >> >> rely on only that for authorization. > >> >> >> > > >> >> >> > > >> >> >> > I was thinking a per-user API token > >> >> >> > >> >> >> Yes, I assumed that. > >> >> >> > >> >> >> > the way that (say) the Github API works. > >> >> >> > Would that be a problem? > >> >> >> > >> >> >> I'll go and check the github API key details and the way they are > >> used. > >> >> >> > >> >> >> Essentially, what you're proposing is to use a combined > >> authentication > >> >> >> and authorization token instead of username+password. If that > token > >> >> >> doesn't leak, it should not be a problem. If it leaks, it's of > >> course > >> >> >> a potential problem. > >> >> >> > >> >> > > >> >> > Right, but of course that's the situation for a password as well. > >> >> > >> >> Agreed, but you clearly aim to limit exposure of the password more > >> >> strongly than the API key. To counterbalance this, I believe the > >> >> API key should be limited in what it authorizes the holder to do. > >> >> More below. > >> >> > >> > > >> > This seems conceptually fine. > >> > > >> > > >> >>> One property of API keys is often that they have a limited lifetime, > >> >> >> in order to reduce the impact of leakage. Given what you write > >> below, > >> >> >> I guess that's a property you would like to avoid, too? Or would > >> that > >> >> >> be acceptable? > >> >> >> > >> >> > > >> >> > Yes, I would like to avoid that. The invariant I want to have here > is > >> >> that > >> >> > I can provision the bridging server (the one that moves data back > and > >> >> > forth between phabricator and the data tracker) with credentials > for > >> >> > each side and then let it run indefinitely. At the end of the day, > >> >> > one might imagine merging that logic into phab or the datatracker > >> >> > or both, but because you want to avoid polling, the upshot will > >> >> > still be distribution of credentials. > >> >> > >> >> Right. > >> >> > >> >> Ok, so in order to limit the damage an exposed API key can do, here > are > >> >> some thoughts: > >> >> > >> >> * Provide a GUI to revoke a key (necessary in any case) and give > >> >> an overview of existing keys and their usage. > >> >> > >> > > >> > This seems like a good plan. > >> > > >> > > >> > * Time limit the validity of the key to N days (30?) from the time of > >> >> the latest login to the datatracker using username+password. > >> >> > >> > > >> > Yeah, this seems like it would probably work though might be brittle. > >> > > >> > > >> > * Limit the key to a given URL path prefix (e.g., /api/iesg/ballot/) > >> >> This means having multiple keys if we evolve additional API > >> endpoints, > >> >> which I expect to happen. > >> >> > >> >> * Provide regular information in the datatracker GUI about API key > >> >> activity in a manner easily digested and minimally distracting. > >> >> Maybe a message once a week, summarising the activity? > >> >> > >> > > >> > Both of these seem like good ideas. > >> > > >> > -Ekr > >> > > >> > > >> >> > >> >> Thoughts? > >> >> > >> >> Henrik > >> >> > >> >> > >> >> > > >> >> > -Ekr > >> >> > > >> >> > > >> >> >> > Are you ok with doing a regular login > >> >> >> >> cycle to cookie storage ahead of posting to the form with the > API > >> >> key? > >> >> >> >> > >> >> >> > > >> >> >> > I could also do this as long as the cookie was perpetual so I > could > >> >> >> > log in through my browser and then store the cookie on the > server. > >> >> >> > I'd like to avoid having my password on the server. > >> >> >> > >> >> >> Understood. > >> >> >> > >> >> >> Henrik > >> >> >> > >> >> >> > > >> >> >> > -Ekr > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> >> > >> >> >> >> Henrik > >> >> >> >> > >> >> >> >> > -Ekr > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, Henrik Levkowetz < > >> >> >> henrik@levkowetz.com> > >> >> >> >> > wrote: > >> >> >> >> > > >> >> >> >> >> Hi Ekr, > >> >> >> >> >> > >> >> >> >> >> On 2017-10-17 15:52, Eric Rescorla wrote: > >> >> >> >> >> > Hi folks. > >> >> >> >> >> > > >> >> >> >> >> > I've been working some more on my IETF review tools and > I'm > >> now > >> >> at > >> >> >> the > >> >> >> >> >> point > >> >> >> >> >> > where I want to take an external review and hoist it into > the > >> >> IESG > >> >> >> >> >> Ballot. > >> >> >> >> >> > Is there > >> >> >> >> >> > an existing API surface for this kind of thing? Perhaps > one > >> >> which > >> >> >> >> takes > >> >> >> >> >> an > >> >> >> >> >> > auth token > >> >> >> >> >> > so no CSRF/cookie nonsense? > >> >> >> >> >> > >> >> >> >> >> No, there isn't, but adding an endpoint for this isn't that > >> hard. > >> >> >> There > >> >> >> >> >> are things ahead of it in the queue, though ,:-) > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> Best regards, > >> >> >> >> >> > >> >> >> >> >> Henrik > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> > >> > > >> > > >> > > >> > >> > > > > > > > > ___________________________________________________________ > > Tools-discuss mailing list > > Tools-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/tools-discuss > > > > Please report datatracker.ietf.org and mailarchive.ietf.org > > bugs at http://tools.ietf.org/tools/ietfdb > > or send email to datatracker-project@ietf.org > > > > Please report tools.ietf.org bugs at > > http://tools.ietf.org/tools/issues > > or send email to webmaster@tools.ietf.org > > > > --000000000000d1fd870569fc9a1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Henrik,

The ballot submis= sion API is working great, but it doesn't seem to send email when I bal= lot. Would it be possible to add a parameter for that. or just have it alwa= ys happen?

-Ekr


On Sun, Apr 8, 2018 a= t 5:45 AM, Henrik Levkowetz <henrik@levkowetz.com> wrote:=
Hi Ekr,

On 2018-04-05 23:32, Eric Rescorla wrote:
> Thanks, Henrik,
>
> I got this working and can now mechanically post reviews from Phabrica= tor
> to the datatracker (at least to the sandbox).

Oh, good :-)

> Happy to share the code once I get it more polished.

Ack; hopefully that will be helpful to other ADs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik


> -Ekr
>
>
>
>
> On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz <henrik@levkowetz.com>
> wrote:
>
>> Hi Ekr,
>>
>> In yesterday's datatracker release 6.68.0, now deployed, an AP= I to auto-
>> post iesg ballot positions was included.
>>
>> A brief description of usage, with an example, is available here:<= br> >>
>>=C2=A0 =C2=A0https://datatracker.ietf.org= /api/#iesg-position-api
>>
>> The limitations on the API keys follow what we discussed below.=C2= =A0 For
>> testing
>> purposes, you may want to use the datatracker sandbox,
>>
>>=C2=A0 =C2=A0https://sandbox.ietf.org/
>>
>> where your password is 'password' (as is that of everybody= else).
>>
>> Any personal API keys you create on the sandbox server will not ca= rry over
>> to the production site, and will be overwritten within 24 hours wh= en the
>> next database update comes in from the production site (just after= 5 in the
>> morning, PST).=C2=A0 The same goes for positions and other changes= you may make.
>>
>> Please let me know when you've had time to try it out, and of = course if you
>> have comments and questions about the API endpoint.
>>
>>
>> Best regards,
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>>
>>
>> On 2017-10-18 20:50, Eric Rescorla wrote:
>> > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz <henrik@levkowetz.com
>> >
>> > wrote:
>> >
>> >>
>> >> On 2017-10-18 17:37, Eric Rescorla wrote:
>> >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz &l= t;
>> henrik@levkowetz.com&g= t;
>> >> > wrote:
>> >> >
>> >> >>
>> >> >> On 2017-10-18 16:58, Eric Rescorla wrote:
>> >> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Lev= kowetz <
>> >> henrik@levkowetz.= com>
>> >> >> > wrote:
>> >> >> >
>> >> >> >>
>> >> >> >> On 2017-10-18 16:47, Eric Rescorla wrot= e:
>> >> >> >> > Thanks. I would actually be fine w= ith replicating the existing
>> API
>> >> >> >> surface
>> >> >> >> > (it's not that hard to generat= e form fills), as long as I could
>> >> use an
>> >> >> >> API
>> >> >> >> > key rather than a cookie, because = it's a real pain to replicate
>> the
>> >> >> >> > anti-CSRF logic.
>> >> >> >>
>> >> >> >> I'm fine with an API key as alterna= tive to anti-CSRF, but would
>> not
>> >> >> like to
>> >> >> >> rely on only that for authorization. >> >> >> >
>> >> >> >
>> >> >> > I was thinking a per-user API token
>> >> >>
>> >> >> Yes, I assumed that.
>> >> >>
>> >> >> > the way that (say) the Github API works. >> >> >> > Would that be a problem?
>> >> >>
>> >> >> I'll go and check the github API key details= and the way they are
>> used.
>> >> >>
>> >> >> Essentially, what you're proposing is to use= a combined
>> authentication
>> >> >> and authorization token instead of username+pass= word.=C2=A0 If that token
>> >> >> doesn't leak, it should not be a problem.=C2= =A0 If it leaks, it's of
>> course
>> >> >> a potential problem.
>> >> >>
>> >> >
>> >> > Right, but of course that's the situation for a = password as well.
>> >>
>> >> Agreed, but you clearly aim to limit exposure of the pass= word more
>> >> strongly than the API key.=C2=A0 To counterbalance this, = I believe the
>> >> API key should be limited in what it authorizes the holde= r to do.
>> >> More below.
>> >>
>> >
>> > This seems conceptually fine.
>> >
>> >
>> >>> One property of API keys is often that they have a li= mited lifetime,
>> >> >> in order to reduce the impact of leakage.=C2=A0 = Given what you write
>> below,
>> >> >> I guess that's a property you would like to = avoid, too?=C2=A0 Or would
>> that
>> >> >> be acceptable?
>> >> >>
>> >> >
>> >> > Yes, I would like to avoid that. The invariant I wan= t to have here is
>> >> that
>> >> > I can provision the bridging server (the one that mo= ves data back and
>> >> > forth between phabricator and the data tracker) with= credentials for
>> >> > each side and then let it run indefinitely. At the e= nd of the day,
>> >> > one might imagine merging that logic into phab or th= e datatracker
>> >> > or both, but because you want to avoid polling, the = upshot will
>> >> > still be distribution of credentials.
>> >>
>> >> Right.
>> >>
>> >> Ok, so in order to limit the damage an exposed API key ca= n do, here are
>> >> some thoughts:
>> >>
>> >>=C2=A0 * Provide a GUI to revoke a key (necessary in any c= ase) and give
>> >>=C2=A0 =C2=A0 an overview of existing keys and their usage= .
>> >>
>> >
>> > This seems like a good plan.
>> >
>> >
>> >=C2=A0 * Time limit the validity of the key to N days (30?) fr= om the time of
>> >>=C2=A0 =C2=A0 the latest login to the datatracker using us= ername+password.
>> >>
>> >
>> > Yeah, this seems like it would probably work though might be = brittle.
>> >
>> >
>> >=C2=A0 * Limit the key to a given URL path prefix (e.g., /api/= iesg/ballot/)
>> >>=C2=A0 =C2=A0 This means having multiple keys if we evolve= additional API
>> endpoints,
>> >>=C2=A0 =C2=A0 which I expect to happen.
>> >>
>> >>=C2=A0 * Provide regular information in the datatracker GU= I about API key
>> >>=C2=A0 =C2=A0 activity in a manner easily digested and min= imally distracting.
>> >>=C2=A0 =C2=A0 Maybe a message once a week, summarising the= activity?
>> >>
>> >
>> > Both of these seem like good ideas.
>> >
>> > -Ekr
>> >
>> >
>> >>
>> >> Thoughts?
>> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>> >>
>> >>
>> >> >
>> >> > -Ekr
>> >> >
>> >> >
>> >> >> > Are you ok with doing a regular login
>> >> >> >> cycle to cookie storage ahead of postin= g to the form with the API
>> >> key?
>> >> >> >>
>> >> >> >
>> >> >> > I could also do this as long as the cookie = was perpetual so I could
>> >> >> > log in through my browser and then store th= e cookie on the server.
>> >> >> > I'd like to avoid having my password on= the server.
>> >> >>
>> >> >> Understood.
>> >> >>
>> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>> >> >>
>> >> >> >
>> >> >> > -Ekr
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik=
>> >> >> >>
>> >> >> >> > -Ekr
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, H= enrik Levkowetz <
>> >> >> henrik@l= evkowetz.com>
>> >> >> >> > wrote:
>> >> >> >> >
>> >> >> >> >> Hi Ekr,
>> >> >> >> >>
>> >> >> >> >> On 2017-10-17 15:52, Eric Resc= orla wrote:
>> >> >> >> >> > Hi folks.
>> >> >> >> >> >
>> >> >> >> >> > I've been working som= e more on my IETF review tools and I'm
>> now
>> >> at
>> >> >> the
>> >> >> >> >> point
>> >> >> >> >> > where I want to take an e= xternal review and hoist it into the
>> >> IESG
>> >> >> >> >> Ballot.
>> >> >> >> >> > Is there
>> >> >> >> >> > an existing API surface f= or this kind of thing? Perhaps one
>> >> which
>> >> >> >> takes
>> >> >> >> >> an
>> >> >> >> >> > auth token
>> >> >> >> >> > so no CSRF/cookie nonsens= e?
>> >> >> >> >>
>> >> >> >> >> No, there isn't, but addin= g an endpoint for this isn't that
>> hard.
>> >> >> There
>> >> >> >> >> are things ahead of it in the = queue, though ,:-)
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Best regards,
>> >> >> >> >>
>> >> >> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Henrik
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>
>
>
> _____________________________________________________= ______
> Tools-discuss mailing list
> Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/t= ools-discuss
>
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to datat= racker-project@ietf.org
>
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to webmaster= @tools.ietf.org
>


--000000000000d1fd870569fc9a1f-- From nobody Mon Apr 16 12:57:53 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC4B12EAD9 for ; Mon, 16 Apr 2018 12:57:17 -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 phnNthhLkCc2 for ; Mon, 16 Apr 2018 12:57:13 -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 79D661289B0 for ; Mon, 16 Apr 2018 12:57:13 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:56247 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f8AFT-0004M1-SF; Mon, 16 Apr 2018 12:57:13 -0700 To: Eric Rescorla References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> Cc: tools-discuss From: Henrik Levkowetz Message-ID: <7fe9bb5d-a29c-13b7-17e2-859244b5ce72@levkowetz.com> Date: Mon, 16 Apr 2018 21:57:03 +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="5WB4MRn15cQPcc4MbeuleJlbS47lNpLch" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.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-discuss] Auto-posting IESG ballots X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:57:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5WB4MRn15cQPcc4MbeuleJlbS47lNpLch Content-Type: multipart/mixed; boundary="3D6IOXTauGDvh113jhvxhE1Fk03rK08M0"; protected-headers="v1" From: Henrik Levkowetz To: Eric Rescorla Cc: tools-discuss Message-ID: <7fe9bb5d-a29c-13b7-17e2-859244b5ce72@levkowetz.com> Subject: Re: [Tools-discuss] Auto-posting IESG ballots References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> In-Reply-To: --3D6IOXTauGDvh113jhvxhE1Fk03rK08M0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Eric, On 2018-04-16 21:54, Eric Rescorla wrote: > Hi Henrik, >=20 > The ballot submission API is working great, but it doesn't seem to send= > email when I ballot. Would it be possible to add a parameter for that. = or > just have it always happen? Sure. The latter seems best. I'll make it so. Henrik > -Ekr >=20 >=20 > On Sun, Apr 8, 2018 at 5:45 AM, Henrik Levkowetz = > wrote: >=20 >> Hi Ekr, >> >> On 2018-04-05 23:32, Eric Rescorla wrote: >> > Thanks, Henrik, >> > >> > I got this working and can now mechanically post reviews from Phabri= cator >> > to the datatracker (at least to the sandbox). >> >> Oh, good :-) >> >> > Happy to share the code once I get it more polished. >> >> Ack; hopefully that will be helpful to other ADs. >> >> Henrik >> >> >> > -Ekr >> > >> > >> > >> > >> > On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz >> > wrote: >> > >> >> Hi Ekr, >> >> >> >> In yesterday's datatracker release 6.68.0, now deployed, an API to = auto- >> >> post iesg ballot positions was included. >> >> >> >> A brief description of usage, with an example, is available here: >> >> >> >> https://datatracker.ietf.org/api/#iesg-position-api >> >> >> >> The limitations on the API keys follow what we discussed below. Fo= r >> >> testing >> >> purposes, you may want to use the datatracker sandbox, >> >> >> >> https://sandbox.ietf.org/ >> >> >> >> where your password is 'password' (as is that of everybody else). >> >> >> >> Any personal API keys you create on the sandbox server will not car= ry >> over >> >> to the production site, and will be overwritten within 24 hours whe= n the >> >> next database update comes in from the production site (just after = 5 in >> the >> >> morning, PST). The same goes for positions and other changes you m= ay >> make. >> >> >> >> Please let me know when you've had time to try it out, and of cours= e if >> you >> >> have comments and questions about the API endpoint. >> >> >> >> >> >> Best regards, >> >> >> >> Henrik >> >> >> >> >> >> On 2017-10-18 20:50, Eric Rescorla wrote: >> >> > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz < >> henrik@levkowetz.com >> >> > >> >> > wrote: >> >> > >> >> >> >> >> >> On 2017-10-18 17:37, Eric Rescorla wrote: >> >> >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz < >> >> henrik@levkowetz.com> >> >> >> > wrote: >> >> >> > >> >> >> >> >> >> >> >> On 2017-10-18 16:58, Eric Rescorla wrote: >> >> >> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz < >> >> >> henrik@levkowetz.com> >> >> >> >> > wrote: >> >> >> >> > >> >> >> >> >> >> >> >> >> >> On 2017-10-18 16:47, Eric Rescorla wrote: >> >> >> >> >> > Thanks. I would actually be fine with replicating the >> existing >> >> API >> >> >> >> >> surface >> >> >> >> >> > (it's not that hard to generate form fills), as long as = I >> could >> >> >> use an >> >> >> >> >> API >> >> >> >> >> > key rather than a cookie, because it's a real pain to >> replicate >> >> the >> >> >> >> >> > anti-CSRF logic. >> >> >> >> >> >> >> >> >> >> I'm fine with an API key as alternative to anti-CSRF, but = would >> >> not >> >> >> >> like to >> >> >> >> >> rely on only that for authorization. >> >> >> >> > >> >> >> >> > >> >> >> >> > I was thinking a per-user API token >> >> >> >> >> >> >> >> Yes, I assumed that. >> >> >> >> >> >> >> >> > the way that (say) the Github API works. >> >> >> >> > Would that be a problem? >> >> >> >> >> >> >> >> I'll go and check the github API key details and the way they= are >> >> used. >> >> >> >> >> >> >> >> Essentially, what you're proposing is to use a combined >> >> authentication >> >> >> >> and authorization token instead of username+password. If tha= t >> token >> >> >> >> doesn't leak, it should not be a problem. If it leaks, it's = of >> >> course >> >> >> >> a potential problem. >> >> >> >> >> >> >> > >> >> >> > Right, but of course that's the situation for a password as we= ll. >> >> >> >> >> >> Agreed, but you clearly aim to limit exposure of the password mo= re >> >> >> strongly than the API key. To counterbalance this, I believe th= e >> >> >> API key should be limited in what it authorizes the holder to do= =2E >> >> >> More below. >> >> >> >> >> > >> >> > This seems conceptually fine. >> >> > >> >> > >> >> >>> One property of API keys is often that they have a limited life= time, >> >> >> >> in order to reduce the impact of leakage. Given what you wri= te >> >> below, >> >> >> >> I guess that's a property you would like to avoid, too? Or w= ould >> >> that >> >> >> >> be acceptable? >> >> >> >> >> >> >> > >> >> >> > Yes, I would like to avoid that. The invariant I want to have = here >> is >> >> >> that >> >> >> > I can provision the bridging server (the one that moves data b= ack >> and >> >> >> > forth between phabricator and the data tracker) with credentia= ls >> for >> >> >> > each side and then let it run indefinitely. At the end of the = day, >> >> >> > one might imagine merging that logic into phab or the datatrac= ker >> >> >> > or both, but because you want to avoid polling, the upshot wil= l >> >> >> > still be distribution of credentials. >> >> >> >> >> >> Right. >> >> >> >> >> >> Ok, so in order to limit the damage an exposed API key can do, h= ere >> are >> >> >> some thoughts: >> >> >> >> >> >> * Provide a GUI to revoke a key (necessary in any case) and giv= e >> >> >> an overview of existing keys and their usage. >> >> >> >> >> > >> >> > This seems like a good plan. >> >> > >> >> > >> >> > * Time limit the validity of the key to N days (30?) from the ti= me of >> >> >> the latest login to the datatracker using username+password. >> >> >> >> >> > >> >> > Yeah, this seems like it would probably work though might be brit= tle. >> >> > >> >> > >> >> > * Limit the key to a given URL path prefix (e.g., /api/iesg/ball= ot/) >> >> >> This means having multiple keys if we evolve additional API >> >> endpoints, >> >> >> which I expect to happen. >> >> >> >> >> >> * Provide regular information in the datatracker GUI about API = key >> >> >> activity in a manner easily digested and minimally distractin= g. >> >> >> Maybe a message once a week, summarising the activity? >> >> >> >> >> > >> >> > Both of these seem like good ideas. >> >> > >> >> > -Ekr >> >> > >> >> > >> >> >> >> >> >> Thoughts? >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> >> > >> >> >> > -Ekr >> >> >> > >> >> >> > >> >> >> >> > Are you ok with doing a regular login >> >> >> >> >> cycle to cookie storage ahead of posting to the form with = the >> API >> >> >> key? >> >> >> >> >> >> >> >> >> > >> >> >> >> > I could also do this as long as the cookie was perpetual so= I >> could >> >> >> >> > log in through my browser and then store the cookie on the >> server. >> >> >> >> > I'd like to avoid having my password on the server. >> >> >> >> >> >> >> >> Understood. >> >> >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> > >> >> >> >> > -Ekr >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> >> >> > -Ekr >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, Henrik Levkowetz < >> >> >> >> henrik@levkowetz.com> >> >> >> >> >> > wrote: >> >> >> >> >> > >> >> >> >> >> >> Hi Ekr, >> >> >> >> >> >> >> >> >> >> >> >> On 2017-10-17 15:52, Eric Rescorla wrote: >> >> >> >> >> >> > Hi folks. >> >> >> >> >> >> > >> >> >> >> >> >> > I've been working some more on my IETF review tools a= nd >> I'm >> >> now >> >> >> at >> >> >> >> the >> >> >> >> >> >> point >> >> >> >> >> >> > where I want to take an external review and hoist it = into >> the >> >> >> IESG >> >> >> >> >> >> Ballot. >> >> >> >> >> >> > Is there >> >> >> >> >> >> > an existing API surface for this kind of thing? Perha= ps >> one >> >> >> which >> >> >> >> >> takes >> >> >> >> >> >> an >> >> >> >> >> >> > auth token >> >> >> >> >> >> > so no CSRF/cookie nonsense? >> >> >> >> >> >> >> >> >> >> >> >> No, there isn't, but adding an endpoint for this isn't = that >> >> hard. >> >> >> >> There >> >> >> >> >> >> are things ahead of it in the queue, though ,:-) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Best regards, >> >> >> >> >> >> >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> >> >> >> > >> > >> > >> > ___________________________________________________________ >> > Tools-discuss mailing list >> > Tools-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/tools-discuss >> > >> > Please report datatracker.ietf.org and mailarchive.ietf.org >> > bugs at http://tools.ietf.org/tools/ietfdb >> > or send email to datatracker-project@ietf.org >> > >> > Please report tools.ietf.org bugs at >> > http://tools.ietf.org/tools/issues >> > or send email to webmaster@tools.ietf.org >> > >> >> >=20 --3D6IOXTauGDvh113jhvxhE1Fk03rK08M0-- --5WB4MRn15cQPcc4MbeuleJlbS47lNpLch Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrVABAACgkQTptXS4+7 Fxo0nQ/+LPK4SrPFPunk+TPbgAUuRcHox+SbHMUdNmArp4v/OhCCGo6X88NzawbY QCPb3uYZlGx8UsMyRlx++fJZBzyiIVTjSTzT5lbMcKgL+6Brq1oqD01R4ycKXq+a y7fzrYW7YpHL4+5nbt84lK7WMEganwfACt070CMKVfA8wiZcGc34sfL/+o6H6eah WeuVggPeFaa0zET/PV8IUz1aFNmJFCaEebz1tQyxU3UNsp39Z/jBHvJ28YF36uej sdNst6NQ/eMlaBk5cIx7lWXzMxjIWACsTlpLQIzCTbhJKLISB3HYG3ytV31/dulJ uycfjOKnlCHcmIp1R2oB4Pyz89D3WVOEX0TPQCZPROJ3Zz7T9kvUoox9NZAR5swk 7UT/m+YTPbCcqoE45k5xt3Tt6YLhe7vwUu9uILmDEsnJ3yl5RUp2yYT41+3msq6c 6OpYyzoXQxqsw2CtB03Wx1hz8eJC3nroxA5ZbiK++cBYPxyEuQQlfDo0CnESOT4m tuUMFKYZr89kedP1WwnqBAjzvbm7XBG2IgAWkpw7FVWBALIVex+d7DLx3fXIwRd2 pt9ntR8LPJfrA6ETJhBxlUvlQ7/BzZw0+v4zX/bESfnXTJKCnQkJV6j1jAW4dMTu jrvVke4KjZ/rK7H/3oE4ps4k6GuLNXZwGiI1AvuRNyN8OzJ/Ysc= =dca4 -----END PGP SIGNATURE----- --5WB4MRn15cQPcc4MbeuleJlbS47lNpLch-- From nobody Mon Apr 16 12:59:26 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1751289B0 for ; Mon, 16 Apr 2018 12:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 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_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] 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 ZHIpUQl7mweH for ; Mon, 16 Apr 2018 12:59:08 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 2D2A71241F3 for ; Mon, 16 Apr 2018 12:59:02 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id e123-v6so15740486oih.13 for ; Mon, 16 Apr 2018 12:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=43A/nlaLTMZT1MUvjpEjxX8BMpztIixGatJEawiOEXw=; b=DFKia+PIedmTkjI+NIoqSBp+Q9fAp0JPZdEPtDGqHDWZeBTECbVGgZzcKDm6IxYOrP 0MBwCE+4V0GPWJNjIVihGRuwva316hv73xNCttaMCBemEtkR4DMlR9UTwkMmjSU4gzfj nVgTIq63nsFVZQ+1XokUZA/RJsYQ3emD2f0FI/YWM3QZosSkDqzeEoRDt6fO5VZ+I9pE zbUTpXreQDONhoq3AwWNkdstBpatG81PyB3L8qEUnWaiXAVANPsLTWDqTsYZ46R+vxbQ a6yYOyKaa55B6fCBq+E3RAkYK9ff1wM8c1L8stNzKhdRXrf1b9BAidpzL8sEqG1MEXYd ZTQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=43A/nlaLTMZT1MUvjpEjxX8BMpztIixGatJEawiOEXw=; b=qHSPdBUPJziD4RutMNb4mzow4pW637XPhvMLqBnxNpMMuYCt02bXUjePQ0eokYCBJT Q3R0MFgMQZegvlamFAq9P3BQEy6ZBTxzcQFE+P2EHKuiaGTvQrf8sdhQlj6n+6SvydGG fzS61cFYXNQNzGVLX6O/sgULnvvhHYhdNMFR4VRFADgiBbtQbb/EeKN3NCYZnEkSiO2L l8GIaH5auEsNmBs9agF8bvyNuPZQ/7pWkXQ/6L9roAFytcBeAYPDPNkNBN1qEci2eb3Z MImbZQt19tqxZ/2I0GaKWZGC+Ed2RlWjf9b56c5tw06LzrpeqzA4TBqemXWxoWnyNRzP Ondw== X-Gm-Message-State: ALQs6tCj4YIQ1EN6A0Rjj4TrHSw/cMgtqJfXVIps+rw7XaNsW/Ph9gs7 HDrJ/s2+yFJfVVxwuHgO0rFeNOVyCRquSbW3GZjbVQ== X-Google-Smtp-Source: AIpwx4/l344JoOPT8itdK0SFiD0vPmgXi0m2luh1WeKSp/2MQcuJ8JZCXNEn2fJFIxydBjzC90IxFz47Ynbs52vTyvg= X-Received: by 2002:aca:5405:: with SMTP id i5-v6mr2370852oib.262.1523908741500; Mon, 16 Apr 2018 12:59:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.132 with HTTP; Mon, 16 Apr 2018 12:58:21 -0700 (PDT) In-Reply-To: <7fe9bb5d-a29c-13b7-17e2-859244b5ce72@levkowetz.com> References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> <7fe9bb5d-a29c-13b7-17e2-859244b5ce72@levkowetz.com> From: Eric Rescorla Date: Mon, 16 Apr 2018 12:58:21 -0700 Message-ID: To: Henrik Levkowetz Cc: tools-discuss Content-Type: multipart/alternative; boundary="0000000000003529130569fca7ab" Archived-At: Subject: Re: [Tools-discuss] Auto-posting IESG ballots X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:59:25 -0000 --0000000000003529130569fca7ab Content-Type: text/plain; charset="UTF-8" Thanks! On Mon, Apr 16, 2018 at 12:57 PM, Henrik Levkowetz wrote: > Hi Eric, > > On 2018-04-16 21:54, Eric Rescorla wrote: > > Hi Henrik, > > > > The ballot submission API is working great, but it doesn't seem to send > > email when I ballot. Would it be possible to add a parameter for that. or > > just have it always happen? > > Sure. The latter seems best. I'll make it so. > > > Henrik > > > -Ekr > > > > > > On Sun, Apr 8, 2018 at 5:45 AM, Henrik Levkowetz > > wrote: > > > >> Hi Ekr, > >> > >> On 2018-04-05 23:32, Eric Rescorla wrote: > >> > Thanks, Henrik, > >> > > >> > I got this working and can now mechanically post reviews from > Phabricator > >> > to the datatracker (at least to the sandbox). > >> > >> Oh, good :-) > >> > >> > Happy to share the code once I get it more polished. > >> > >> Ack; hopefully that will be helpful to other ADs. > >> > >> Henrik > >> > >> > >> > -Ekr > >> > > >> > > >> > > >> > > >> > On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz < > henrik@levkowetz.com> > >> > wrote: > >> > > >> >> Hi Ekr, > >> >> > >> >> In yesterday's datatracker release 6.68.0, now deployed, an API to > auto- > >> >> post iesg ballot positions was included. > >> >> > >> >> A brief description of usage, with an example, is available here: > >> >> > >> >> https://datatracker.ietf.org/api/#iesg-position-api > >> >> > >> >> The limitations on the API keys follow what we discussed below. For > >> >> testing > >> >> purposes, you may want to use the datatracker sandbox, > >> >> > >> >> https://sandbox.ietf.org/ > >> >> > >> >> where your password is 'password' (as is that of everybody else). > >> >> > >> >> Any personal API keys you create on the sandbox server will not carry > >> over > >> >> to the production site, and will be overwritten within 24 hours when > the > >> >> next database update comes in from the production site (just after 5 > in > >> the > >> >> morning, PST). The same goes for positions and other changes you may > >> make. > >> >> > >> >> Please let me know when you've had time to try it out, and of course > if > >> you > >> >> have comments and questions about the API endpoint. > >> >> > >> >> > >> >> Best regards, > >> >> > >> >> Henrik > >> >> > >> >> > >> >> On 2017-10-18 20:50, Eric Rescorla wrote: > >> >> > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz < > >> henrik@levkowetz.com > >> >> > > >> >> > wrote: > >> >> > > >> >> >> > >> >> >> On 2017-10-18 17:37, Eric Rescorla wrote: > >> >> >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz < > >> >> henrik@levkowetz.com> > >> >> >> > wrote: > >> >> >> > > >> >> >> >> > >> >> >> >> On 2017-10-18 16:58, Eric Rescorla wrote: > >> >> >> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz < > >> >> >> henrik@levkowetz.com> > >> >> >> >> > wrote: > >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> On 2017-10-18 16:47, Eric Rescorla wrote: > >> >> >> >> >> > Thanks. I would actually be fine with replicating the > >> existing > >> >> API > >> >> >> >> >> surface > >> >> >> >> >> > (it's not that hard to generate form fills), as long as I > >> could > >> >> >> use an > >> >> >> >> >> API > >> >> >> >> >> > key rather than a cookie, because it's a real pain to > >> replicate > >> >> the > >> >> >> >> >> > anti-CSRF logic. > >> >> >> >> >> > >> >> >> >> >> I'm fine with an API key as alternative to anti-CSRF, but > would > >> >> not > >> >> >> >> like to > >> >> >> >> >> rely on only that for authorization. > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > I was thinking a per-user API token > >> >> >> >> > >> >> >> >> Yes, I assumed that. > >> >> >> >> > >> >> >> >> > the way that (say) the Github API works. > >> >> >> >> > Would that be a problem? > >> >> >> >> > >> >> >> >> I'll go and check the github API key details and the way they > are > >> >> used. > >> >> >> >> > >> >> >> >> Essentially, what you're proposing is to use a combined > >> >> authentication > >> >> >> >> and authorization token instead of username+password. If that > >> token > >> >> >> >> doesn't leak, it should not be a problem. If it leaks, it's of > >> >> course > >> >> >> >> a potential problem. > >> >> >> >> > >> >> >> > > >> >> >> > Right, but of course that's the situation for a password as > well. > >> >> >> > >> >> >> Agreed, but you clearly aim to limit exposure of the password more > >> >> >> strongly than the API key. To counterbalance this, I believe the > >> >> >> API key should be limited in what it authorizes the holder to do. > >> >> >> More below. > >> >> >> > >> >> > > >> >> > This seems conceptually fine. > >> >> > > >> >> > > >> >> >>> One property of API keys is often that they have a limited > lifetime, > >> >> >> >> in order to reduce the impact of leakage. Given what you write > >> >> below, > >> >> >> >> I guess that's a property you would like to avoid, too? Or > would > >> >> that > >> >> >> >> be acceptable? > >> >> >> >> > >> >> >> > > >> >> >> > Yes, I would like to avoid that. The invariant I want to have > here > >> is > >> >> >> that > >> >> >> > I can provision the bridging server (the one that moves data > back > >> and > >> >> >> > forth between phabricator and the data tracker) with credentials > >> for > >> >> >> > each side and then let it run indefinitely. At the end of the > day, > >> >> >> > one might imagine merging that logic into phab or the > datatracker > >> >> >> > or both, but because you want to avoid polling, the upshot will > >> >> >> > still be distribution of credentials. > >> >> >> > >> >> >> Right. > >> >> >> > >> >> >> Ok, so in order to limit the damage an exposed API key can do, > here > >> are > >> >> >> some thoughts: > >> >> >> > >> >> >> * Provide a GUI to revoke a key (necessary in any case) and give > >> >> >> an overview of existing keys and their usage. > >> >> >> > >> >> > > >> >> > This seems like a good plan. > >> >> > > >> >> > > >> >> > * Time limit the validity of the key to N days (30?) from the > time of > >> >> >> the latest login to the datatracker using username+password. > >> >> >> > >> >> > > >> >> > Yeah, this seems like it would probably work though might be > brittle. > >> >> > > >> >> > > >> >> > * Limit the key to a given URL path prefix (e.g., > /api/iesg/ballot/) > >> >> >> This means having multiple keys if we evolve additional API > >> >> endpoints, > >> >> >> which I expect to happen. > >> >> >> > >> >> >> * Provide regular information in the datatracker GUI about API > key > >> >> >> activity in a manner easily digested and minimally distracting. > >> >> >> Maybe a message once a week, summarising the activity? > >> >> >> > >> >> > > >> >> > Both of these seem like good ideas. > >> >> > > >> >> > -Ekr > >> >> > > >> >> > > >> >> >> > >> >> >> Thoughts? > >> >> >> > >> >> >> Henrik > >> >> >> > >> >> >> > >> >> >> > > >> >> >> > -Ekr > >> >> >> > > >> >> >> > > >> >> >> >> > Are you ok with doing a regular login > >> >> >> >> >> cycle to cookie storage ahead of posting to the form with > the > >> API > >> >> >> key? > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > I could also do this as long as the cookie was perpetual so I > >> could > >> >> >> >> > log in through my browser and then store the cookie on the > >> server. > >> >> >> >> > I'd like to avoid having my password on the server. > >> >> >> >> > >> >> >> >> Understood. > >> >> >> >> > >> >> >> >> Henrik > >> >> >> >> > >> >> >> >> > > >> >> >> >> > -Ekr > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> Henrik > >> >> >> >> >> > >> >> >> >> >> > -Ekr > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, Henrik Levkowetz < > >> >> >> >> henrik@levkowetz.com> > >> >> >> >> >> > wrote: > >> >> >> >> >> > > >> >> >> >> >> >> Hi Ekr, > >> >> >> >> >> >> > >> >> >> >> >> >> On 2017-10-17 15:52, Eric Rescorla wrote: > >> >> >> >> >> >> > Hi folks. > >> >> >> >> >> >> > > >> >> >> >> >> >> > I've been working some more on my IETF review tools and > >> I'm > >> >> now > >> >> >> at > >> >> >> >> the > >> >> >> >> >> >> point > >> >> >> >> >> >> > where I want to take an external review and hoist it > into > >> the > >> >> >> IESG > >> >> >> >> >> >> Ballot. > >> >> >> >> >> >> > Is there > >> >> >> >> >> >> > an existing API surface for this kind of thing? Perhaps > >> one > >> >> >> which > >> >> >> >> >> takes > >> >> >> >> >> >> an > >> >> >> >> >> >> > auth token > >> >> >> >> >> >> > so no CSRF/cookie nonsense? > >> >> >> >> >> >> > >> >> >> >> >> >> No, there isn't, but adding an endpoint for this isn't > that > >> >> hard. > >> >> >> >> There > >> >> >> >> >> >> are things ahead of it in the queue, though ,:-) > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> Best regards, > >> >> >> >> >> >> > >> >> >> >> >> >> Henrik > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> > > >> > > >> > > >> > ___________________________________________________________ > >> > Tools-discuss mailing list > >> > Tools-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/tools-discuss > >> > > >> > Please report datatracker.ietf.org and mailarchive.ietf.org > >> > bugs at http://tools.ietf.org/tools/ietfdb > >> > or send email to datatracker-project@ietf.org > >> > > >> > Please report tools.ietf.org bugs at > >> > http://tools.ietf.org/tools/issues > >> > or send email to webmaster@tools.ietf.org > >> > > >> > >> > > > > --0000000000003529130569fca7ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks!
On Mon, Apr 16, 2018 at 12:57 PM, Henrik Levkow= etz <henrik@levkowetz.com> wrote:
Hi Eric,

On 2018-04-16 21:54, Eric Rescorla wrote:
> Hi Henrik,
>
> The ballot submission API is working great, but it doesn't seem to= send
> email when I ballot. Would it be possible to add a parameter for that.= or
> just have it always happen?

Sure.=C2=A0 The latter seems best.=C2=A0 I'll make it so.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik

> -Ekr
>
>
> On Sun, Apr 8, 2018 at 5:45 AM, Henrik Levkowetz <henrik@levkowetz.com>
> wrote:
>
>> Hi Ekr,
>>
>> On 2018-04-05 23:32, Eric Rescorla wrote:
>> > Thanks, Henrik,
>> >
>> > I got this working and can now mechanically post reviews from= Phabricator
>> > to the datatracker (at least to the sandbox).
>>
>> Oh, good :-)
>>
>> > Happy to share the code once I get it more polished.
>>
>> Ack; hopefully that will be helpful to other ADs.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>>
>>
>> > -Ekr
>> >
>> >
>> >
>> >
>> > On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz <henrik@levkowetz.com>
>> > wrote:
>> >
>> >> Hi Ekr,
>> >>
>> >> In yesterday's datatracker release 6.68.0, now deploy= ed, an API to auto-
>> >> post iesg ballot positions was included.
>> >>
>> >> A brief description of usage, with an example, is availab= le here:
>> >>
>> >>=C2=A0 =C2=A0https://datatracker= .ietf.org/api/#iesg-position-api
>> >>
>> >> The limitations on the API keys follow what we discussed = below.=C2=A0 For
>> >> testing
>> >> purposes, you may want to use the datatracker sandbox, >> >>
>> >>=C2=A0 =C2=A0https://sandbox.ietf.org/
>> >>
>> >> where your password is 'password' (as is that of = everybody else).
>> >>
>> >> Any personal API keys you create on the sandbox server wi= ll not carry
>> over
>> >> to the production site, and will be overwritten within 24= hours when the
>> >> next database update comes in from the production site (j= ust after 5 in
>> the
>> >> morning, PST).=C2=A0 The same goes for positions and othe= r changes you may
>> make.
>> >>
>> >> Please let me know when you've had time to try it out= , and of course if
>> you
>> >> have comments and questions about the API endpoint.
>> >>
>> >>
>> >> Best regards,
>> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>> >>
>> >>
>> >> On 2017-10-18 20:50, Eric Rescorla wrote:
>> >> > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz &= lt;
>> henrik@levkowetz.com >> >> >
>> >> > wrote:
>> >> >
>> >> >>
>> >> >> On 2017-10-18 17:37, Eric Rescorla wrote:
>> >> >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Lev= kowetz <
>> >> henrik@levkowetz.= com>
>> >> >> > wrote:
>> >> >> >
>> >> >> >>
>> >> >> >> On 2017-10-18 16:58, Eric Rescorla wrot= e:
>> >> >> >> > On Wed, Oct 18, 2017 at 7:54 AM, H= enrik Levkowetz <
>> >> >> henrik@l= evkowetz.com>
>> >> >> >> > wrote:
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> On 2017-10-18 16:47, Eric Resc= orla wrote:
>> >> >> >> >> > Thanks. I would actually = be fine with replicating the
>> existing
>> >> API
>> >> >> >> >> surface
>> >> >> >> >> > (it's not that hard t= o generate form fills), as long as I
>> could
>> >> >> use an
>> >> >> >> >> API
>> >> >> >> >> > key rather than a cookie,= because it's a real pain to
>> replicate
>> >> the
>> >> >> >> >> > anti-CSRF logic.
>> >> >> >> >>
>> >> >> >> >> I'm fine with an API key a= s alternative to anti-CSRF, but would
>> >> not
>> >> >> >> like to
>> >> >> >> >> rely on only that for authoriz= ation.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > I was thinking a per-user API toke= n
>> >> >> >>
>> >> >> >> Yes, I assumed that.
>> >> >> >>
>> >> >> >> > the way that (say) the Github API = works.
>> >> >> >> > Would that be a problem?
>> >> >> >>
>> >> >> >> I'll go and check the github API ke= y details and the way they are
>> >> used.
>> >> >> >>
>> >> >> >> Essentially, what you're proposing = is to use a combined
>> >> authentication
>> >> >> >> and authorization token instead of user= name+password.=C2=A0 If that
>> token
>> >> >> >> doesn't leak, it should not be a pr= oblem.=C2=A0 If it leaks, it's of
>> >> course
>> >> >> >> a potential problem.
>> >> >> >>
>> >> >> >
>> >> >> > Right, but of course that's the situati= on for a password as well.
>> >> >>
>> >> >> Agreed, but you clearly aim to limit exposure of= the password more
>> >> >> strongly than the API key.=C2=A0 To counterbalan= ce this, I believe the
>> >> >> API key should be limited in what it authorizes = the holder to do.
>> >> >> More below.
>> >> >>
>> >> >
>> >> > This seems conceptually fine.
>> >> >
>> >> >
>> >> >>> One property of API keys is often that they = have a limited lifetime,
>> >> >> >> in order to reduce the impact of leakag= e.=C2=A0 Given what you write
>> >> below,
>> >> >> >> I guess that's a property you would= like to avoid, too?=C2=A0 Or would
>> >> that
>> >> >> >> be acceptable?
>> >> >> >>
>> >> >> >
>> >> >> > Yes, I would like to avoid that. The invari= ant I want to have here
>> is
>> >> >> that
>> >> >> > I can provision the bridging server (the on= e that moves data back
>> and
>> >> >> > forth between phabricator and the data trac= ker) with credentials
>> for
>> >> >> > each side and then let it run indefinitely.= At the end of the day,
>> >> >> > one might imagine merging that logic into p= hab or the datatracker
>> >> >> > or both, but because you want to avoid poll= ing, the upshot will
>> >> >> > still be distribution of credentials.
>> >> >>
>> >> >> Right.
>> >> >>
>> >> >> Ok, so in order to limit the damage an exposed A= PI key can do, here
>> are
>> >> >> some thoughts:
>> >> >>
>> >> >>=C2=A0 * Provide a GUI to revoke a key (necessary= in any case) and give
>> >> >>=C2=A0 =C2=A0 an overview of existing keys and th= eir usage.
>> >> >>
>> >> >
>> >> > This seems like a good plan.
>> >> >
>> >> >
>> >> >=C2=A0 * Time limit the validity of the key to N days= (30?) from the time of
>> >> >>=C2=A0 =C2=A0 the latest login to the datatracker= using username+password.
>> >> >>
>> >> >
>> >> > Yeah, this seems like it would probably work though = might be brittle.
>> >> >
>> >> >
>> >> >=C2=A0 * Limit the key to a given URL path prefix (e.= g., /api/iesg/ballot/)
>> >> >>=C2=A0 =C2=A0 This means having multiple keys if = we evolve additional API
>> >> endpoints,
>> >> >>=C2=A0 =C2=A0 which I expect to happen.
>> >> >>
>> >> >>=C2=A0 * Provide regular information in the datat= racker GUI about API key
>> >> >>=C2=A0 =C2=A0 activity in a manner easily digeste= d and minimally distracting.
>> >> >>=C2=A0 =C2=A0 Maybe a message once a week, summar= ising the activity?
>> >> >>
>> >> >
>> >> > Both of these seem like good ideas.
>> >> >
>> >> > -Ekr
>> >> >
>> >> >
>> >> >>
>> >> >> Thoughts?
>> >> >>
>> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > -Ekr
>> >> >> >
>> >> >> >
>> >> >> >> > Are you ok with doing a regular lo= gin
>> >> >> >> >> cycle to cookie storage ahead = of posting to the form with the
>> API
>> >> >> key?
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > I could also do this as long as th= e cookie was perpetual so I
>> could
>> >> >> >> > log in through my browser and then= store the cookie on the
>> server.
>> >> >> >> > I'd like to avoid having my pa= ssword on the server.
>> >> >> >>
>> >> >> >> Understood.
>> >> >> >>
>> >> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik=
>> >> >> >>
>> >> >> >> >
>> >> >> >> > -Ekr
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Henrik
>> >> >> >> >>
>> >> >> >> >> > -Ekr
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > On Wed, Oct 18, 2017 at 5= :19 AM, Henrik Levkowetz <
>> >> >> >> henrik@levkowetz.com>
>> >> >> >> >> > wrote:
>> >> >> >> >> >
>> >> >> >> >> >> Hi Ekr,
>> >> >> >> >> >>
>> >> >> >> >> >> On 2017-10-17 15:52, = Eric Rescorla wrote:
>> >> >> >> >> >> > Hi folks.
>> >> >> >> >> >> >
>> >> >> >> >> >> > I've been wo= rking some more on my IETF review tools and
>> I'm
>> >> now
>> >> >> at
>> >> >> >> the
>> >> >> >> >> >> point
>> >> >> >> >> >> > where I want to = take an external review and hoist it into
>> the
>> >> >> IESG
>> >> >> >> >> >> Ballot.
>> >> >> >> >> >> > Is there
>> >> >> >> >> >> > an existing API = surface for this kind of thing? Perhaps
>> one
>> >> >> which
>> >> >> >> >> takes
>> >> >> >> >> >> an
>> >> >> >> >> >> > auth token
>> >> >> >> >> >> > so no CSRF/cooki= e nonsense?
>> >> >> >> >> >>
>> >> >> >> >> >> No, there isn't, = but adding an endpoint for this isn't that
>> >> hard.
>> >> >> >> There
>> >> >> >> >> >> are things ahead of i= t in the queue, though ,:-)
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> Best regards,
>> >> >> >> >> >>
>> >> >> >> >> >>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Henrik
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>> >
>> > ________________________________________________________= ___
>> > Tools-discuss mailing list
>> > Tools-discuss@ietf.= org
>> > https://www.ietf.org/mailman/l= istinfo/tools-discuss
>> >
>> > Please report datatracker.ietf.org and mailarchive.ie= tf.org
>> > bugs at http://tools.ietf.org/tools/ietfdb<= br> >> > or send email to datatracker-project@ietf.org
>> >
>> > Please report tools.ietf.org bugs at
>> > http://tools.ietf.org/tools/issues
>> > or send email to = webmaster@tools.ietf.org
>> >
>>
>>
>


--0000000000003529130569fca7ab-- From nobody Tue Apr 17 05:10:59 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C7D12EB21 for ; Tue, 17 Apr 2018 05:10:58 -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, 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 AGtgq2MUpPQx for ; Tue, 17 Apr 2018 05:10:54 -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 BEB2712EB1E for ; Tue, 17 Apr 2018 05:10:54 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:57798 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f8PRa-0005FY-MI; Tue, 17 Apr 2018 05:10:48 -0700 To: Eric Rescorla References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> <7fe9bb5d-a29c-13b7-17e2-859244b5ce72@levkowetz.com> Cc: tools-discuss From: Henrik Levkowetz Message-ID: <4b93a2f9-6f35-32c8-2d34-fdf34f17b35f@levkowetz.com> Date: Tue, 17 Apr 2018 14:10:33 +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="gFV0D4oiuh9KubLNnUoLXIbe9U1WbdLSm" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ekr@rtfm.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-discuss] Auto-posting IESG ballots X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 12:10:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gFV0D4oiuh9KubLNnUoLXIbe9U1WbdLSm Content-Type: multipart/mixed; boundary="jvlXN8jF1PmNdmqwdVPDLWEMx0ws2v6co"; protected-headers="v1" From: Henrik Levkowetz To: Eric Rescorla Cc: tools-discuss Message-ID: <4b93a2f9-6f35-32c8-2d34-fdf34f17b35f@levkowetz.com> Subject: Re: [Tools-discuss] Auto-posting IESG ballots References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> <7fe9bb5d-a29c-13b7-17e2-859244b5ce72@levkowetz.com> In-Reply-To: --jvlXN8jF1PmNdmqwdVPDLWEMx0ws2v6co Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ekr, A fix has been committed as changeset [15049]: https://trac.tools.ietf.org/tools/ietfdb/changeset/15049 . I've patched production. Best regards, Henrik On 2018-04-16 21:58, Eric Rescorla wrote: > Thanks! >=20 > On Mon, Apr 16, 2018 at 12:57 PM, Henrik Levkowetz > wrote: >=20 >> Hi Eric, >> >> On 2018-04-16 21:54, Eric Rescorla wrote: >> > Hi Henrik, >> > >> > The ballot submission API is working great, but it doesn't seem to s= end >> > email when I ballot. Would it be possible to add a parameter for tha= t. or >> > just have it always happen? >> >> Sure. The latter seems best. I'll make it so. >> >> >> Henrik >> >> > -Ekr >> > >> > >> > On Sun, Apr 8, 2018 at 5:45 AM, Henrik Levkowetz >> > wrote: >> > >> >> Hi Ekr, >> >> >> >> On 2018-04-05 23:32, Eric Rescorla wrote: >> >> > Thanks, Henrik, >> >> > >> >> > I got this working and can now mechanically post reviews from >> Phabricator >> >> > to the datatracker (at least to the sandbox). >> >> >> >> Oh, good :-) >> >> >> >> > Happy to share the code once I get it more polished. >> >> >> >> Ack; hopefully that will be helpful to other ADs. >> >> >> >> Henrik >> >> >> >> >> >> > -Ekr >> >> > >> >> > >> >> > >> >> > >> >> > On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz < >> henrik@levkowetz.com> >> >> > wrote: >> >> > >> >> >> Hi Ekr, >> >> >> >> >> >> In yesterday's datatracker release 6.68.0, now deployed, an API = to >> auto- >> >> >> post iesg ballot positions was included. >> >> >> >> >> >> A brief description of usage, with an example, is available here= : >> >> >> >> >> >> https://datatracker.ietf.org/api/#iesg-position-api >> >> >> >> >> >> The limitations on the API keys follow what we discussed below. = For >> >> >> testing >> >> >> purposes, you may want to use the datatracker sandbox, >> >> >> >> >> >> https://sandbox.ietf.org/ >> >> >> >> >> >> where your password is 'password' (as is that of everybody else)= =2E >> >> >> >> >> >> Any personal API keys you create on the sandbox server will not = carry >> >> over >> >> >> to the production site, and will be overwritten within 24 hours = when >> the >> >> >> next database update comes in from the production site (just aft= er 5 >> in >> >> the >> >> >> morning, PST). The same goes for positions and other changes yo= u may >> >> make. >> >> >> >> >> >> Please let me know when you've had time to try it out, and of co= urse >> if >> >> you >> >> >> have comments and questions about the API endpoint. >> >> >> >> >> >> >> >> >> Best regards, >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> >> On 2017-10-18 20:50, Eric Rescorla wrote: >> >> >> > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz < >> >> henrik@levkowetz.com >> >> >> > >> >> >> > wrote: >> >> >> > >> >> >> >> >> >> >> >> On 2017-10-18 17:37, Eric Rescorla wrote: >> >> >> >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz < >> >> >> henrik@levkowetz.com> >> >> >> >> > wrote: >> >> >> >> > >> >> >> >> >> >> >> >> >> >> On 2017-10-18 16:58, Eric Rescorla wrote: >> >> >> >> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz < >> >> >> >> henrik@levkowetz.com> >> >> >> >> >> > wrote: >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> On 2017-10-18 16:47, Eric Rescorla wrote: >> >> >> >> >> >> > Thanks. I would actually be fine with replicating the= >> >> existing >> >> >> API >> >> >> >> >> >> surface >> >> >> >> >> >> > (it's not that hard to generate form fills), as long = as I >> >> could >> >> >> >> use an >> >> >> >> >> >> API >> >> >> >> >> >> > key rather than a cookie, because it's a real pain to= >> >> replicate >> >> >> the >> >> >> >> >> >> > anti-CSRF logic. >> >> >> >> >> >> >> >> >> >> >> >> I'm fine with an API key as alternative to anti-CSRF, b= ut >> would >> >> >> not >> >> >> >> >> like to >> >> >> >> >> >> rely on only that for authorization. >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > I was thinking a per-user API token >> >> >> >> >> >> >> >> >> >> Yes, I assumed that. >> >> >> >> >> >> >> >> >> >> > the way that (say) the Github API works. >> >> >> >> >> > Would that be a problem? >> >> >> >> >> >> >> >> >> >> I'll go and check the github API key details and the way t= hey >> are >> >> >> used. >> >> >> >> >> >> >> >> >> >> Essentially, what you're proposing is to use a combined >> >> >> authentication >> >> >> >> >> and authorization token instead of username+password. If = that >> >> token >> >> >> >> >> doesn't leak, it should not be a problem. If it leaks, it= 's of >> >> >> course >> >> >> >> >> a potential problem. >> >> >> >> >> >> >> >> >> > >> >> >> >> > Right, but of course that's the situation for a password as= >> well. >> >> >> >> >> >> >> >> Agreed, but you clearly aim to limit exposure of the password= more >> >> >> >> strongly than the API key. To counterbalance this, I believe= the >> >> >> >> API key should be limited in what it authorizes the holder to= do. >> >> >> >> More below. >> >> >> >> >> >> >> > >> >> >> > This seems conceptually fine. >> >> >> > >> >> >> > >> >> >> >>> One property of API keys is often that they have a limited >> lifetime, >> >> >> >> >> in order to reduce the impact of leakage. Given what you = write >> >> >> below, >> >> >> >> >> I guess that's a property you would like to avoid, too? O= r >> would >> >> >> that >> >> >> >> >> be acceptable? >> >> >> >> >> >> >> >> >> > >> >> >> >> > Yes, I would like to avoid that. The invariant I want to ha= ve >> here >> >> is >> >> >> >> that >> >> >> >> > I can provision the bridging server (the one that moves dat= a >> back >> >> and >> >> >> >> > forth between phabricator and the data tracker) with creden= tials >> >> for >> >> >> >> > each side and then let it run indefinitely. At the end of t= he >> day, >> >> >> >> > one might imagine merging that logic into phab or the >> datatracker >> >> >> >> > or both, but because you want to avoid polling, the upshot = will >> >> >> >> > still be distribution of credentials. >> >> >> >> >> >> >> >> Right. >> >> >> >> >> >> >> >> Ok, so in order to limit the damage an exposed API key can do= , >> here >> >> are >> >> >> >> some thoughts: >> >> >> >> >> >> >> >> * Provide a GUI to revoke a key (necessary in any case) and = give >> >> >> >> an overview of existing keys and their usage. >> >> >> >> >> >> >> > >> >> >> > This seems like a good plan. >> >> >> > >> >> >> > >> >> >> > * Time limit the validity of the key to N days (30?) from the= >> time of >> >> >> >> the latest login to the datatracker using username+passwor= d. >> >> >> >> >> >> >> > >> >> >> > Yeah, this seems like it would probably work though might be >> brittle. >> >> >> > >> >> >> > >> >> >> > * Limit the key to a given URL path prefix (e.g., >> /api/iesg/ballot/) >> >> >> >> This means having multiple keys if we evolve additional AP= I >> >> >> endpoints, >> >> >> >> which I expect to happen. >> >> >> >> >> >> >> >> * Provide regular information in the datatracker GUI about A= PI >> key >> >> >> >> activity in a manner easily digested and minimally distrac= ting. >> >> >> >> Maybe a message once a week, summarising the activity? >> >> >> >> >> >> >> > >> >> >> > Both of these seem like good ideas. >> >> >> > >> >> >> > -Ekr >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> Thoughts? >> >> >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > -Ekr >> >> >> >> > >> >> >> >> > >> >> >> >> >> > Are you ok with doing a regular login >> >> >> >> >> >> cycle to cookie storage ahead of posting to the form wi= th >> the >> >> API >> >> >> >> key? >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > I could also do this as long as the cookie was perpetual= so I >> >> could >> >> >> >> >> > log in through my browser and then store the cookie on t= he >> >> server. >> >> >> >> >> > I'd like to avoid having my password on the server. >> >> >> >> >> >> >> >> >> >> Understood. >> >> >> >> >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > -Ekr >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> >> >> >> >> > -Ekr >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, Henrik Levkowetz < >> >> >> >> >> henrik@levkowetz.com> >> >> >> >> >> >> > wrote: >> >> >> >> >> >> > >> >> >> >> >> >> >> Hi Ekr, >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 2017-10-17 15:52, Eric Rescorla wrote: >> >> >> >> >> >> >> > Hi folks. >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > I've been working some more on my IETF review tool= s and >> >> I'm >> >> >> now >> >> >> >> at >> >> >> >> >> the >> >> >> >> >> >> >> point >> >> >> >> >> >> >> > where I want to take an external review and hoist = it >> into >> >> the >> >> >> >> IESG >> >> >> >> >> >> >> Ballot. >> >> >> >> >> >> >> > Is there >> >> >> >> >> >> >> > an existing API surface for this kind of thing? Pe= rhaps >> >> one >> >> >> >> which >> >> >> >> >> >> takes >> >> >> >> >> >> >> an >> >> >> >> >> >> >> > auth token >> >> >> >> >> >> >> > so no CSRF/cookie nonsense? >> >> >> >> >> >> >> >> >> >> >> >> >> >> No, there isn't, but adding an endpoint for this isn= 't >> that >> >> >> hard. >> >> >> >> >> There >> >> >> >> >> >> >> are things ahead of it in the queue, though ,:-) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Best regards, >> >> >> >> >> >> >> >> >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > ___________________________________________________________ >> >> > Tools-discuss mailing list >> >> > Tools-discuss@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/tools-discuss >> >> > >> >> > Please report datatracker.ietf.org and mailarchive.ietf.org >> >> > bugs at http://tools.ietf.org/tools/ietfdb >> >> > or send email to datatracker-project@ietf.org >> >> > >> >> > Please report tools.ietf.org bugs at >> >> > http://tools.ietf.org/tools/issues >> >> > or send email to webmaster@tools.ietf.org >> >> > >> >> >> >> >> > >> >> >=20 >=20 >=20 > ___________________________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss >=20 > Please report datatracker.ietf.org and mailarchive.ietf.org > bugs at http://tools.ietf.org/tools/ietfdb > or send email to datatracker-project@ietf.org >=20 > Please report tools.ietf.org bugs at > http://tools.ietf.org/tools/issues > or send email to webmaster@tools.ietf.org >=20 --jvlXN8jF1PmNdmqwdVPDLWEMx0ws2v6co-- --gFV0D4oiuh9KubLNnUoLXIbe9U1WbdLSm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrV5DkACgkQTptXS4+7 FxoBAQ//SNFR+fQyuH7Xy9zqOtwgDUp8YbT9Ormj1AAiq2m43uFeerG+opI6jhsv 2+dhRb/xNlOvjTuOMdZlvr+xLAKxdFWLOy4PuWS6G1C/r4KvEnTkTSZ/hFOlUha1 qlt4MvwLz9RE7o2Bu3p3Yj8L/OlPh2x4rVJwk1X4naDv54qd9uko9r0oT4YpVGy0 YrBqJracO0C9l6+CB02gfu1dMPyOsb/RsNjLkyLt+MUnzPL8I0uMPML4vVh8rNEk tsjJvNlgiNQafo+k4l0oP8tuxofYAoYh3JYm3DBnE3MRlW/DqxdwapGx0MhbIdqo YlLFUFFSv2JYwf+XYD2gwUZVBbdJbhr6UqTTufg3fo/YHt6+dXKzd1M8FB3j/Pma USdopCLWkK3j6gbFBKKggqWwuT9X/jD0OFAr8kQJws000D+znoomfsXeHBMvE7kI EHEr3dNNfhoyTtU/x1KQA4lDzezSi8Ug4/l7KnowNfyx1r2anCockrh0eJ5nJJ3D qXIEDDSd8fYOBRD2ssMQpmMjfkHSG1fv7rHpaikgSsWk/GCW88szmaQoULawkApE QdaMz6bGEynHDNwMFkU5P8qF8bMI/y15qmb6wn4wisehJa5yviR/um1wTHf9EdC2 2+cncEunYjxm3KGS26WoWcTPT3gkmYspKvi8I+U9kFCSr0NBATc= =nRF3 -----END PGP SIGNATURE----- --gFV0D4oiuh9KubLNnUoLXIbe9U1WbdLSm-- From nobody Tue Apr 17 06:41:09 2018 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B745E12EB47 for ; Tue, 17 Apr 2018 06:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, 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 31brUS2faTFP for ; Tue, 17 Apr 2018 06:41:04 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (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 5393612EB45 for ; Tue, 17 Apr 2018 06:41:04 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id d9-v6so21379832oth.10 for ; Tue, 17 Apr 2018 06:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IM6ssWCiLMCYH/qcAXazLnXQOY27PHiPFV4KZWR7XcA=; b=VRK0HfBiLICGzCMlYHYD9N8MJHxkCICfm3lHxtE8JKOwjIAaFEAAHI9wERzT7F+lwP fuVCdMBGps5fTREfV42rGG5emrnKGRXNhvtbhgZqLM/9m8kJfGoV2jVnN45N6qoAakMP YkY0DG1UQObay9vUJN9IQv2nO5Cgj0yemnsawxqu3IdR3K24y1BQ4o7I/qq8gf5MDhto a7iNw/uideZiVTtNexLti6U52PLyNUHe0nX2/ia2BPJKpOvRgDSaAY7ISls7WMZeLhJG YaeVg57W5gJEfjLK3I+pFn94ZIji9geG+5t4wXzVD7dE+KjSfr8/gdPfiQirELj82p2K a4rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IM6ssWCiLMCYH/qcAXazLnXQOY27PHiPFV4KZWR7XcA=; b=hcnjQPawsofAAlfvfbEQ6f5mWyk5uH0AVgPYIIklIf8wpvjjA7NctevcUh6w7LL3ur 7BCmq9lIiKq+g9ZkM7AWbdznDjo0+CtE6dT8rMQXeIPgHcEczPvD4buXJaAUgDn9M6jl MQlNp35rPtLZCr83XUYVUPLb7HCKXgx5FVDe1KpjodOehMvllwMSHa0V6MlM9D6q0zSP azwaQRssXGqgfv0gTLUsX13t2LnLpo0OacPgMxPq7Nv7Bl5NXwB4OlKHVNAUPgkYx/DC yLEbxEgTRkZ9OQzu9QbYXHw4MjG1KKRSl49o0ZLlbT59MC1henZlDy8Hv+6R8e9LnCNo zmwQ== X-Gm-Message-State: ALQs6tBqm6dNMCDy6qJ8ALi0lzxCVqF7maAa9AbSa5eLmidWmDcBBVaU O/lMspStZlg6gP5UEAPqas5bMxtMvikKCTEoRKJEGXcH X-Google-Smtp-Source: AIpwx4+I8XF6Xfo2UfQSQxKV17vDKgJJmSDupET4DMcXO0r0IxL3nCQgzXBZtEoOGazHnmzg6C/ifJyV/X/TU8lqi2s= X-Received: by 2002:a9d:3636:: with SMTP id w51-v6mr1338460otb.101.1523972463638; Tue, 17 Apr 2018 06:41:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.132 with HTTP; Tue, 17 Apr 2018 06:40:23 -0700 (PDT) In-Reply-To: <4b93a2f9-6f35-32c8-2d34-fdf34f17b35f@levkowetz.com> References: <2da19e94-bf94-0956-e053-1bb4bd5605c0@levkowetz.com> <52c39da2-6457-d43d-912e-cdfbea7d687b@levkowetz.com> <7dce0eb9-b26a-46eb-124f-f6c0e17f010a@levkowetz.com> <3010c065-91aa-a689-5bc3-2d3d20292a70@levkowetz.com> <7fe9bb5d-a29c-13b7-17e2-859244b5ce72@levkowetz.com> <4b93a2f9-6f35-32c8-2d34-fdf34f17b35f@levkowetz.com> From: Eric Rescorla Date: Tue, 17 Apr 2018 06:40:23 -0700 Message-ID: To: Henrik Levkowetz Cc: tools-discuss Content-Type: multipart/alternative; boundary="00000000000057f76f056a0b7d5c" Archived-At: Subject: Re: [Tools-discuss] Auto-posting IESG ballots X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 13:41:08 -0000 --00000000000057f76f056a0b7d5c Content-Type: text/plain; charset="UTF-8" Great! Thanks again for the quick response. On Tue, Apr 17, 2018 at 5:10 AM, Henrik Levkowetz wrote: > Hi Ekr, > > A fix has been committed as changeset [15049]: > https://trac.tools.ietf.org/tools/ietfdb/changeset/15049 . > > I've patched production. > > Best regards, > > Henrik > > > On 2018-04-16 21:58, Eric Rescorla wrote: > > Thanks! > > > > On Mon, Apr 16, 2018 at 12:57 PM, Henrik Levkowetz > > > wrote: > > > >> Hi Eric, > >> > >> On 2018-04-16 21:54, Eric Rescorla wrote: > >> > Hi Henrik, > >> > > >> > The ballot submission API is working great, but it doesn't seem to > send > >> > email when I ballot. Would it be possible to add a parameter for > that. or > >> > just have it always happen? > >> > >> Sure. The latter seems best. I'll make it so. > >> > >> > >> Henrik > >> > >> > -Ekr > >> > > >> > > >> > On Sun, Apr 8, 2018 at 5:45 AM, Henrik Levkowetz < > henrik@levkowetz.com> > >> > wrote: > >> > > >> >> Hi Ekr, > >> >> > >> >> On 2018-04-05 23:32, Eric Rescorla wrote: > >> >> > Thanks, Henrik, > >> >> > > >> >> > I got this working and can now mechanically post reviews from > >> Phabricator > >> >> > to the datatracker (at least to the sandbox). > >> >> > >> >> Oh, good :-) > >> >> > >> >> > Happy to share the code once I get it more polished. > >> >> > >> >> Ack; hopefully that will be helpful to other ADs. > >> >> > >> >> Henrik > >> >> > >> >> > >> >> > -Ekr > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz < > >> henrik@levkowetz.com> > >> >> > wrote: > >> >> > > >> >> >> Hi Ekr, > >> >> >> > >> >> >> In yesterday's datatracker release 6.68.0, now deployed, an API to > >> auto- > >> >> >> post iesg ballot positions was included. > >> >> >> > >> >> >> A brief description of usage, with an example, is available here: > >> >> >> > >> >> >> https://datatracker.ietf.org/api/#iesg-position-api > >> >> >> > >> >> >> The limitations on the API keys follow what we discussed below. > For > >> >> >> testing > >> >> >> purposes, you may want to use the datatracker sandbox, > >> >> >> > >> >> >> https://sandbox.ietf.org/ > >> >> >> > >> >> >> where your password is 'password' (as is that of everybody else). > >> >> >> > >> >> >> Any personal API keys you create on the sandbox server will not > carry > >> >> over > >> >> >> to the production site, and will be overwritten within 24 hours > when > >> the > >> >> >> next database update comes in from the production site (just > after 5 > >> in > >> >> the > >> >> >> morning, PST). The same goes for positions and other changes you > may > >> >> make. > >> >> >> > >> >> >> Please let me know when you've had time to try it out, and of > course > >> if > >> >> you > >> >> >> have comments and questions about the API endpoint. > >> >> >> > >> >> >> > >> >> >> Best regards, > >> >> >> > >> >> >> Henrik > >> >> >> > >> >> >> > >> >> >> On 2017-10-18 20:50, Eric Rescorla wrote: > >> >> >> > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz < > >> >> henrik@levkowetz.com > >> >> >> > > >> >> >> > wrote: > >> >> >> > > >> >> >> >> > >> >> >> >> On 2017-10-18 17:37, Eric Rescorla wrote: > >> >> >> >> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz < > >> >> >> henrik@levkowetz.com> > >> >> >> >> > wrote: > >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> On 2017-10-18 16:58, Eric Rescorla wrote: > >> >> >> >> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz < > >> >> >> >> henrik@levkowetz.com> > >> >> >> >> >> > wrote: > >> >> >> >> >> > > >> >> >> >> >> >> > >> >> >> >> >> >> On 2017-10-18 16:47, Eric Rescorla wrote: > >> >> >> >> >> >> > Thanks. I would actually be fine with replicating the > >> >> existing > >> >> >> API > >> >> >> >> >> >> surface > >> >> >> >> >> >> > (it's not that hard to generate form fills), as long > as I > >> >> could > >> >> >> >> use an > >> >> >> >> >> >> API > >> >> >> >> >> >> > key rather than a cookie, because it's a real pain to > >> >> replicate > >> >> >> the > >> >> >> >> >> >> > anti-CSRF logic. > >> >> >> >> >> >> > >> >> >> >> >> >> I'm fine with an API key as alternative to anti-CSRF, but > >> would > >> >> >> not > >> >> >> >> >> like to > >> >> >> >> >> >> rely on only that for authorization. > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > I was thinking a per-user API token > >> >> >> >> >> > >> >> >> >> >> Yes, I assumed that. > >> >> >> >> >> > >> >> >> >> >> > the way that (say) the Github API works. > >> >> >> >> >> > Would that be a problem? > >> >> >> >> >> > >> >> >> >> >> I'll go and check the github API key details and the way > they > >> are > >> >> >> used. > >> >> >> >> >> > >> >> >> >> >> Essentially, what you're proposing is to use a combined > >> >> >> authentication > >> >> >> >> >> and authorization token instead of username+password. If > that > >> >> token > >> >> >> >> >> doesn't leak, it should not be a problem. If it leaks, > it's of > >> >> >> course > >> >> >> >> >> a potential problem. > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > Right, but of course that's the situation for a password as > >> well. > >> >> >> >> > >> >> >> >> Agreed, but you clearly aim to limit exposure of the password > more > >> >> >> >> strongly than the API key. To counterbalance this, I believe > the > >> >> >> >> API key should be limited in what it authorizes the holder to > do. > >> >> >> >> More below. > >> >> >> >> > >> >> >> > > >> >> >> > This seems conceptually fine. > >> >> >> > > >> >> >> > > >> >> >> >>> One property of API keys is often that they have a limited > >> lifetime, > >> >> >> >> >> in order to reduce the impact of leakage. Given what you > write > >> >> >> below, > >> >> >> >> >> I guess that's a property you would like to avoid, too? Or > >> would > >> >> >> that > >> >> >> >> >> be acceptable? > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > Yes, I would like to avoid that. The invariant I want to have > >> here > >> >> is > >> >> >> >> that > >> >> >> >> > I can provision the bridging server (the one that moves data > >> back > >> >> and > >> >> >> >> > forth between phabricator and the data tracker) with > credentials > >> >> for > >> >> >> >> > each side and then let it run indefinitely. At the end of the > >> day, > >> >> >> >> > one might imagine merging that logic into phab or the > >> datatracker > >> >> >> >> > or both, but because you want to avoid polling, the upshot > will > >> >> >> >> > still be distribution of credentials. > >> >> >> >> > >> >> >> >> Right. > >> >> >> >> > >> >> >> >> Ok, so in order to limit the damage an exposed API key can do, > >> here > >> >> are > >> >> >> >> some thoughts: > >> >> >> >> > >> >> >> >> * Provide a GUI to revoke a key (necessary in any case) and > give > >> >> >> >> an overview of existing keys and their usage. > >> >> >> >> > >> >> >> > > >> >> >> > This seems like a good plan. > >> >> >> > > >> >> >> > > >> >> >> > * Time limit the validity of the key to N days (30?) from the > >> time of > >> >> >> >> the latest login to the datatracker using username+password. > >> >> >> >> > >> >> >> > > >> >> >> > Yeah, this seems like it would probably work though might be > >> brittle. > >> >> >> > > >> >> >> > > >> >> >> > * Limit the key to a given URL path prefix (e.g., > >> /api/iesg/ballot/) > >> >> >> >> This means having multiple keys if we evolve additional API > >> >> >> endpoints, > >> >> >> >> which I expect to happen. > >> >> >> >> > >> >> >> >> * Provide regular information in the datatracker GUI about API > >> key > >> >> >> >> activity in a manner easily digested and minimally > distracting. > >> >> >> >> Maybe a message once a week, summarising the activity? > >> >> >> >> > >> >> >> > > >> >> >> > Both of these seem like good ideas. > >> >> >> > > >> >> >> > -Ekr > >> >> >> > > >> >> >> > > >> >> >> >> > >> >> >> >> Thoughts? > >> >> >> >> > >> >> >> >> Henrik > >> >> >> >> > >> >> >> >> > >> >> >> >> > > >> >> >> >> > -Ekr > >> >> >> >> > > >> >> >> >> > > >> >> >> >> >> > Are you ok with doing a regular login > >> >> >> >> >> >> cycle to cookie storage ahead of posting to the form with > >> the > >> >> API > >> >> >> >> key? > >> >> >> >> >> >> > >> >> >> >> >> > > >> >> >> >> >> > I could also do this as long as the cookie was perpetual > so I > >> >> could > >> >> >> >> >> > log in through my browser and then store the cookie on the > >> >> server. > >> >> >> >> >> > I'd like to avoid having my password on the server. > >> >> >> >> >> > >> >> >> >> >> Understood. > >> >> >> >> >> > >> >> >> >> >> Henrik > >> >> >> >> >> > >> >> >> >> >> > > >> >> >> >> >> > -Ekr > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> >> > >> >> >> >> >> >> Henrik > >> >> >> >> >> >> > >> >> >> >> >> >> > -Ekr > >> >> >> >> >> >> > > >> >> >> >> >> >> > > >> >> >> >> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, Henrik Levkowetz < > >> >> >> >> >> henrik@levkowetz.com> > >> >> >> >> >> >> > wrote: > >> >> >> >> >> >> > > >> >> >> >> >> >> >> Hi Ekr, > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> On 2017-10-17 15:52, Eric Rescorla wrote: > >> >> >> >> >> >> >> > Hi folks. > >> >> >> >> >> >> >> > > >> >> >> >> >> >> >> > I've been working some more on my IETF review tools > and > >> >> I'm > >> >> >> now > >> >> >> >> at > >> >> >> >> >> the > >> >> >> >> >> >> >> point > >> >> >> >> >> >> >> > where I want to take an external review and hoist it > >> into > >> >> the > >> >> >> >> IESG > >> >> >> >> >> >> >> Ballot. > >> >> >> >> >> >> >> > Is there > >> >> >> >> >> >> >> > an existing API surface for this kind of thing? > Perhaps > >> >> one > >> >> >> >> which > >> >> >> >> >> >> takes > >> >> >> >> >> >> >> an > >> >> >> >> >> >> >> > auth token > >> >> >> >> >> >> >> > so no CSRF/cookie nonsense? > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> No, there isn't, but adding an endpoint for this isn't > >> that > >> >> >> hard. > >> >> >> >> >> There > >> >> >> >> >> >> >> are things ahead of it in the queue, though ,:-) > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> Best regards, > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> Henrik > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> >> > > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > ___________________________________________________________ > >> >> > Tools-discuss mailing list > >> >> > Tools-discuss@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/tools-discuss > >> >> > > >> >> > Please report datatracker.ietf.org and mailarchive.ietf.org > >> >> > bugs at http://tools.ietf.org/tools/ietfdb > >> >> > or send email to datatracker-project@ietf.org > >> >> > > >> >> > Please report tools.ietf.org bugs at > >> >> > http://tools.ietf.org/tools/issues > >> >> > or send email to webmaster@tools.ietf.org > >> >> > > >> >> > >> >> > >> > > >> > >> > > > > > > > > ___________________________________________________________ > > Tools-discuss mailing list > > Tools-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/tools-discuss > > > > Please report datatracker.ietf.org and mailarchive.ietf.org > > bugs at http://tools.ietf.org/tools/ietfdb > > or send email to datatracker-project@ietf.org > > > > Please report tools.ietf.org bugs at > > http://tools.ietf.org/tools/issues > > or send email to webmaster@tools.ietf.org > > > > --00000000000057f76f056a0b7d5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great! Thanks again for the quick response.

On Tue, Apr 17, 2018 a= t 5:10 AM, Henrik Levkowetz <henrik@levkowetz.com> wrote:=
Hi Ekr,

A fix has been committed as changeset [15049]:
=C2=A0 https://trac.tools.ietf.org/tool= s/ietfdb/changeset/15049 .

I've patched production.

Best regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik


On 2018-04-16 21:58, Eric Rescorla wrote:
> Thanks!
>
> On Mon, Apr 16, 2018 at 12:57 PM, Henrik Levkowetz <henrik@levkowetz.com>
> wrote:
>
>> Hi Eric,
>>
>> On 2018-04-16 21:54, Eric Rescorla wrote:
>> > Hi Henrik,
>> >
>> > The ballot submission API is working great, but it doesn'= t seem to send
>> > email when I ballot. Would it be possible to add a parameter = for that. or
>> > just have it always happen?
>>
>> Sure.=C2=A0 The latter seems best.=C2=A0 I'll make it so.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>>
>> > -Ekr
>> >
>> >
>> > On Sun, Apr 8, 2018 at 5:45 AM, Henrik Levkowetz <henrik@levkowetz.com>
>> > wrote:
>> >
>> >> Hi Ekr,
>> >>
>> >> On 2018-04-05 23:32, Eric Rescorla wrote:
>> >> > Thanks, Henrik,
>> >> >
>> >> > I got this working and can now mechanically post rev= iews from
>> Phabricator
>> >> > to the datatracker (at least to the sandbox).
>> >>
>> >> Oh, good :-)
>> >>
>> >> > Happy to share the code once I get it more polished.=
>> >>
>> >> Ack; hopefully that will be helpful to other ADs.
>> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>> >>
>> >>
>> >> > -Ekr
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz &l= t;
>> henrik@levkowetz.com&g= t;
>> >> > wrote:
>> >> >
>> >> >> Hi Ekr,
>> >> >>
>> >> >> In yesterday's datatracker release 6.68.0, n= ow deployed, an API to
>> auto-
>> >> >> post iesg ballot positions was included.
>> >> >>
>> >> >> A brief description of usage, with an example, i= s available here:
>> >> >>
>> >> >>=C2=A0 =C2=A0https://da= tatracker.ietf.org/api/#iesg-position-api
>> >> >>
>> >> >> The limitations on the API keys follow what we d= iscussed below.=C2=A0 For
>> >> >> testing
>> >> >> purposes, you may want to use the datatracker sa= ndbox,
>> >> >>
>> >> >>=C2=A0 =C2=A0https://sandbox.ietf.org/
>> >> >>
>> >> >> where your password is 'password' (as is= that of everybody else).
>> >> >>
>> >> >> Any personal API keys you create on the sandbox = server will not carry
>> >> over
>> >> >> to the production site, and will be overwritten = within 24 hours when
>> the
>> >> >> next database update comes in from the productio= n site (just after 5
>> in
>> >> the
>> >> >> morning, PST).=C2=A0 The same goes for positions= and other changes you may
>> >> make.
>> >> >>
>> >> >> Please let me know when you've had time to t= ry it out, and of course
>> if
>> >> you
>> >> >> have comments and questions about the API endpoi= nt.
>> >> >>
>> >> >>
>> >> >> Best regards,
>> >> >>
>> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>> >> >>
>> >> >>
>> >> >> On 2017-10-18 20:50, Eric Rescorla wrote:
>> >> >> > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Le= vkowetz <
>> >> henrik@levkowetz.= com
>> >> >> >
>> >> >> > wrote:
>> >> >> >
>> >> >> >>
>> >> >> >> On 2017-10-18 17:37, Eric Rescorla wrot= e:
>> >> >> >> > On Wed, Oct 18, 2017 at 8:31 AM, H= enrik Levkowetz <
>> >> >> henrik@l= evkowetz.com>
>> >> >> >> > wrote:
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> On 2017-10-18 16:58, Eric Resc= orla wrote:
>> >> >> >> >> > On Wed, Oct 18, 2017 at 7= :54 AM, Henrik Levkowetz <
>> >> >> >> henrik@levkowetz.com>
>> >> >> >> >> > wrote:
>> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >> On 2017-10-18 16:47, = Eric Rescorla wrote:
>> >> >> >> >> >> > Thanks. I would = actually be fine with replicating the
>> >> existing
>> >> >> API
>> >> >> >> >> >> surface
>> >> >> >> >> >> > (it's not th= at hard to generate form fills), as long as I
>> >> could
>> >> >> >> use an
>> >> >> >> >> >> API
>> >> >> >> >> >> > key rather than = a cookie, because it's a real pain to
>> >> replicate
>> >> >> the
>> >> >> >> >> >> > anti-CSRF logic.=
>> >> >> >> >> >>
>> >> >> >> >> >> I'm fine with an = API key as alternative to anti-CSRF, but
>> would
>> >> >> not
>> >> >> >> >> like to
>> >> >> >> >> >> rely on only that for= authorization.
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > I was thinking a per-user= API token
>> >> >> >> >>
>> >> >> >> >> Yes, I assumed that.
>> >> >> >> >>
>> >> >> >> >> > the way that (say) the Gi= thub API works.
>> >> >> >> >> > Would that be a problem?<= br> >> >> >> >> >>
>> >> >> >> >> I'll go and check the gith= ub API key details and the way they
>> are
>> >> >> used.
>> >> >> >> >>
>> >> >> >> >> Essentially, what you're p= roposing is to use a combined
>> >> >> authentication
>> >> >> >> >> and authorization token instea= d of username+password.=C2=A0 If that
>> >> token
>> >> >> >> >> doesn't leak, it should no= t be a problem.=C2=A0 If it leaks, it's of
>> >> >> course
>> >> >> >> >> a potential problem.
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > Right, but of course that's th= e situation for a password as
>> well.
>> >> >> >>
>> >> >> >> Agreed, but you clearly aim to limit ex= posure of the password more
>> >> >> >> strongly than the API key.=C2=A0 To cou= nterbalance this, I believe the
>> >> >> >> API key should be limited in what it au= thorizes the holder to do.
>> >> >> >> More below.
>> >> >> >>
>> >> >> >
>> >> >> > This seems conceptually fine.
>> >> >> >
>> >> >> >
>> >> >> >>> One property of API keys is often t= hat they have a limited
>> lifetime,
>> >> >> >> >> in order to reduce the impact = of leakage.=C2=A0 Given what you write
>> >> >> below,
>> >> >> >> >> I guess that's a property = you would like to avoid, too?=C2=A0 Or
>> would
>> >> >> that
>> >> >> >> >> be acceptable?
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > Yes, I would like to avoid that. T= he invariant I want to have
>> here
>> >> is
>> >> >> >> that
>> >> >> >> > I can provision the bridging serve= r (the one that moves data
>> back
>> >> and
>> >> >> >> > forth between phabricator and the = data tracker) with credentials
>> >> for
>> >> >> >> > each side and then let it run inde= finitely. At the end of the
>> day,
>> >> >> >> > one might imagine merging that log= ic into phab or the
>> datatracker
>> >> >> >> > or both, but because you want to a= void polling, the upshot will
>> >> >> >> > still be distribution of credentia= ls.
>> >> >> >>
>> >> >> >> Right.
>> >> >> >>
>> >> >> >> Ok, so in order to limit the damage an = exposed API key can do,
>> here
>> >> are
>> >> >> >> some thoughts:
>> >> >> >>
>> >> >> >>=C2=A0 * Provide a GUI to revoke a key (= necessary in any case) and give
>> >> >> >>=C2=A0 =C2=A0 an overview of existing ke= ys and their usage.
>> >> >> >>
>> >> >> >
>> >> >> > This seems like a good plan.
>> >> >> >
>> >> >> >
>> >> >> >=C2=A0 * Time limit the validity of the key = to N days (30?) from the
>> time of
>> >> >> >>=C2=A0 =C2=A0 the latest login to the da= tatracker using username+password.
>> >> >> >>
>> >> >> >
>> >> >> > Yeah, this seems like it would probably wor= k though might be
>> brittle.
>> >> >> >
>> >> >> >
>> >> >> >=C2=A0 * Limit the key to a given URL path p= refix (e.g.,
>> /api/iesg/ballot/)
>> >> >> >>=C2=A0 =C2=A0 This means having multiple= keys if we evolve additional API
>> >> >> endpoints,
>> >> >> >>=C2=A0 =C2=A0 which I expect to happen.<= br> >> >> >> >>
>> >> >> >>=C2=A0 * Provide regular information in = the datatracker GUI about API
>> key
>> >> >> >>=C2=A0 =C2=A0 activity in a manner easil= y digested and minimally distracting.
>> >> >> >>=C2=A0 =C2=A0 Maybe a message once a wee= k, summarising the activity?
>> >> >> >>
>> >> >> >
>> >> >> > Both of these seem like good ideas.
>> >> >> >
>> >> >> > -Ekr
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >> Thoughts?
>> >> >> >>
>> >> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik=
>> >> >> >>
>> >> >> >>
>> >> >> >> >
>> >> >> >> > -Ekr
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >> > Are you ok with doing a r= egular login
>> >> >> >> >> >> cycle to cookie stora= ge ahead of posting to the form with
>> the
>> >> API
>> >> >> >> key?
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > I could also do this as l= ong as the cookie was perpetual so I
>> >> could
>> >> >> >> >> > log in through my browser= and then store the cookie on the
>> >> server.
>> >> >> >> >> > I'd like to avoid hav= ing my password on the server.
>> >> >> >> >>
>> >> >> >> >> Understood.
>> >> >> >> >>
>> >> >> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Henrik
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > -Ekr
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Henrik
>> >> >> >> >> >>
>> >> >> >> >> >> > -Ekr
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >> > On Wed, Oct 18, = 2017 at 5:19 AM, Henrik Levkowetz <
>> >> >> >> >> henrik@levkowetz.com>
>> >> >> >> >> >> > wrote:
>> >> >> >> >> >> >
>> >> >> >> >> >> >> Hi Ekr,
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> On 2017-10-1= 7 15:52, Eric Rescorla wrote:
>> >> >> >> >> >> >> > Hi folk= s.
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > I'v= e been working some more on my IETF review tools and
>> >> I'm
>> >> >> now
>> >> >> >> at
>> >> >> >> >> the
>> >> >> >> >> >> >> point
>> >> >> >> >> >> >> > where I= want to take an external review and hoist it
>> into
>> >> the
>> >> >> >> IESG
>> >> >> >> >> >> >> Ballot.
>> >> >> >> >> >> >> > Is ther= e
>> >> >> >> >> >> >> > an exis= ting API surface for this kind of thing? Perhaps
>> >> one
>> >> >> >> which
>> >> >> >> >> >> takes
>> >> >> >> >> >> >> an
>> >> >> >> >> >> >> > auth to= ken
>> >> >> >> >> >> >> > so no C= SRF/cookie nonsense?
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> No, there is= n't, but adding an endpoint for this isn't
>> that
>> >> >> hard.
>> >> >> >> >> There
>> >> >> >> >> >> >> are things a= head of it in the queue, though ,:-)
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Best regards= ,
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Henrik
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________= ____________
>> >> > Tools-discuss mailing list
>> >> > Tools-disc= uss@ietf.org
>> >> > https://www.ietf.org/mailm= an/listinfo/tools-discuss
>> >> >
>> >> > Please report datatracker.ietf.org and maila= rchive.ietf.org
>> >> > bugs at http://tools.ietf.org/tools/ie= tfdb
>> >> > or send email to datatracker-project@ietf.org
>> >> >
>> >> > Please report tools.ietf.org bugs at
>> >> > http://tools.ietf.org/tools/issues
>> >> > or send email to webmaster@tools.ietf.org
>> >> >
>> >>
>> >>
>> >
>>
>>
>
>
>
> ___________________________________________________________
> Tools-discuss mailing list
> Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/t= ools-discuss
>
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to datat= racker-project@ietf.org
>
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to webmaster= @tools.ietf.org
>


--00000000000057f76f056a0b7d5c--