Re: Workload constants [was I-D Action: draft-rsalz-termlimits-00.txt]

Keith Moore <moore@network-heretics.com> Fri, 22 October 2021 14:02 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBEF3A0E03 for <ietf@ietfa.amsl.com>; Fri, 22 Oct 2021 07:02:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 b0BL6I4mXTlr for <ietf@ietfa.amsl.com>; Fri, 22 Oct 2021 07:02:04 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FF33A0DEC for <ietf@ietf.org>; Fri, 22 Oct 2021 07:02:01 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 85E9832006F2; Fri, 22 Oct 2021 10:01:58 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Fri, 22 Oct 2021 10:01:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=IuZiwgMatjQKcLXn4bqHO70XUcY4RnYImUlhw5hf9 5Y=; b=iEVzkm1tCqIZ632sAtTIQhPqzpkPDwHgfPTOGOc8zfFG3iv/Apxg4yeak CYwBzGrq7ufduCALbJE8eUToHrqxwMJHChoKoNhzXmnE8Ar0erK5HXuJa0kMGF45 tQgBvlisnVEQmyeGdDWdoNNzQrxJlg5Kvw/aTM+Omb4dB2XqUPY2qVn5S1PgEUTi n0gcsV6UycD1zf0NxPbpWKb6QK5MYyESME4CFce3ksFvPTLbJ3rwRygOb624pfYy PeWf81zFsoZmIERaEOwwth872aOI1wL+GtOFq6ivBEBsK3y/YuTQ+u6lXoJiXJ3E klWtnuneNXD7waw5m5eRqtMRtcAjw==
X-ME-Sender: <xms:VcRyYUjZXR0Ygvmx-ufu5vkxUj9-62c-9hf9CDMZfvhZ9ncW8T7LvQ> <xme:VcRyYdBPgtjDHa8z5wITieI_EAbaRQMKCLHw0fepLph2ECRvAMkksVDruQXFwfbCD e2NAQ8n8g0OFg>
X-ME-Received: <xmr:VcRyYcEzUS5z5xN198yS2FAhy3EmujaBNZhI-DC2CqpPuF2JyBIPn7iU4ersXpMjRRd-wr8g_A1qbZGqlWa_iN9NZQOmX2WJRGJNn4WuEH1FvFoICa-bdA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvkedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepmfgvihht hhcuofhoohhrvgcuoehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh eqnecuggftrfgrthhtvghrnhephefhuedtheefgfefgffhkeehgfeugfeiudeugeejkeef leelueeiffetfeeuudeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:VcRyYVTb4QVoACxL4dmfBVlzK6itsOGGq6iDbf3Vn0jYC4mP2OIF3w> <xmx:VcRyYRyf67FiIxJH1fH9ajVmMAc0wxhDIueEJyS2LOd8_lGTx0btcg> <xmx:VcRyYT6D_OgRNh2FsBSNnUHXcvkjI29ZfoZEBKwkyG2QjG3ATvqjcw> <xmx:VsRyYSp90QP6VN9_oWgZgLd0LipfaUo-laRh0CFiqk54ujSo6HAqBw>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 Oct 2021 10:01:57 -0400 (EDT)
Subject: Re: Workload constants [was I-D Action: draft-rsalz-termlimits-00.txt]
To: "Salz, Rich" <rsalz@akamai.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Barry Leiba <barryleiba=40computer.org@dmarc.ietf.org>
Cc: IETF discussion list <ietf@ietf.org>
References: <20211021005426.639E92B1D176@ary.qy> <e6d59712-ca73-0723-5cb2-b1f749e37577@network-heretics.com> <CAC4RtVDCxp7RveAXxTUU47fYXw5ebV+yJTMkDAJWGvcq-4DyTw@mail.gmail.com> <25a9f62e-1957-0e77-1e7a-733d9dae4a86@gmail.com> <02ccb205-d628-b490-946b-a518e963e210@network-heretics.com> <9538275C-EE23-456B-824A-492E0541FF48@akamai.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <d765983a-7839-11e4-5ee7-513a0ac25588@network-heretics.com>
Date: Fri, 22 Oct 2021 10:01:56 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <9538275C-EE23-456B-824A-492E0541FF48@akamai.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/8bzlqIrc1wc5FjdLrCY91tDYNT8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Oct 2021 14:02:09 -0000

On 10/22/21 9:37 AM, Salz, Rich wrote:

>>    Is the relevance of a typical IETF RFC going up or down?
> How do you tell?  Can you measure it, other than have opinions?

I don't know how to measure it.  (Also, I think there's a general 
problem in society these days which is that we pay more attention to 
things that are easily measured, than to things that aren't, even when 
the things that are easily measured are less important.)

I do however suggest (for example) that work that has significant 
potential benefit for a broad portion of the Internet user community, is 
more deserving of IETF attention than work that has less significant 
benefit, or which benefits a narrow portion of the user community.

I also wonder (again for example) to what extent it's worth a multi-year 
effort to make detailed minor revisions to old specifications of old 
protocols is worth IETF's attention, or whether there's a point of 
diminishing returns, after which trying to rewrite old documents creates 
more ambiguities or interoperability problems than it solves.   I wonder 
if we could find a better way to update old documents than to publish 
new RFCs to replace them, with the dual goals of taking less work to get 
to completion and also encouraging changes to mature specifications only 
where and when they are necessary.

I don't like quotas.   But what would happen if we set a goal of 
producing fewer technical RFCs every year, of more average relevance 
than the average technical RFC of the previous year?

Keith