Re: [Tools-discuss] [rfc-i] what metric replaces page-count?

Nico Williams <nico@cryptonector.com> Mon, 12 April 2021 23:09 UTC

Return-Path: <nico@cryptonector.com>
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 255E33A159F for <tools-discuss@ietfa.amsl.com>; Mon, 12 Apr 2021 16:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 7YMM852hANye for <tools-discuss@ietfa.amsl.com>; Mon, 12 Apr 2021 16:09:24 -0700 (PDT)
Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (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 707293A156D for <tools-discuss@ietf.org>; Mon, 12 Apr 2021 16:09:24 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 39D84342FDB; Mon, 12 Apr 2021 23:09:23 +0000 (UTC)
Received: from pdx1-sub0-mail-a47.g.dreamhost.com (100-96-133-83.trex.outbound.svc.cluster.local [100.96.133.83]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B0576342501; Mon, 12 Apr 2021 23:09:22 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a47.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.133.83 (trex/6.1.1); Mon, 12 Apr 2021 23:09:23 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Bitter-Inform: 6ef075386fc3850a_1618268963015_1953336363
X-MC-Loop-Signature: 1618268963015:2021330972
X-MC-Ingress-Time: 1618268963015
Received: from pdx1-sub0-mail-a47.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a47.g.dreamhost.com (Postfix) with ESMTP id 71F4E81760; Mon, 12 Apr 2021 16:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=dxni5NTNf0sV8e xXrM9Ulygr46U=; b=YEzLslulp/S9+ZS2xBNYRVTjnzKwqaW3EQ6nk/+zZkUjT6 3mn3XvN7Q1CYiCHCuZzSYbhrxeCPSp5lJ9hfocuvqKSUlY0e1ZXjoGUOZobozzlt 1N5ug5fBpqU9V6ebM8kBfj9yHQfhp+ReyO+UKLRTTW4Kr+JcsUlCHXEaHvz+s=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a47.g.dreamhost.com (Postfix) with ESMTPSA id 720E97E5FC; Mon, 12 Apr 2021 16:09:17 -0700 (PDT)
Date: Mon, 12 Apr 2021 18:09:14 -0500
X-DH-BACKEND: pdx1-sub0-mail-a47
From: Nico Williams <nico@cryptonector.com>
To: Richard Barnes <richard.barnes@gmail.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, rfc-interest <rfc-interest@rfc-editor.org>, tools-discuss <tools-discuss@ietf.org>
Message-ID: <20210412230913.GX9612@localhost>
References: <20557.1618171860@localhost> <F35C8691-ADA2-4DEC-B24A-0DFB5B76567F@tzi.org> <66fd7812-4d2c-bf9d-d4bf-16c501754d7e@gmail.com> <CACB24MtXPct5iOmYSgG5yQVt=-y5=L1nXmkqb4=TsPNfgsQihQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACB24MtXPct5iOmYSgG5yQVt=-y5=L1nXmkqb4=TsPNfgsQihQ@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/45H3dJWl1cs-cZn5j_FWCz3gOp8>
Subject: Re: [Tools-discuss] [rfc-i] what metric replaces page-count?
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2021 23:09:29 -0000

On Mon, Apr 12, 2021 at 10:55:46AM -0400, Richard Barnes wrote:
> Lawyers and judges are happy to cite by section.  Time to move on from
> tired, inaccurate metaphors.

But Michael was not asking about citations.  He was asking for a
complexity metric.

Speaking of sections for citations _and_ metrics, the ITU-T x.68x and
x.69x series documents do a great job of breaking everything down into
many many teeny tiny sections, which makes it very easy to refer very
specifically to parts of their texts, and since they're all small,
counting them might be a useful metric.

I think it would be much harder for us to adopt that approach than
anything we might do regarding pagination, but I have to say that I like
many-tiny-sections, and it would be especially nice to have all MUSTs,
SHOULDs, and so on, referenceable by section number just by dint of
their containing sections being so small.

Many-tiny-sections is _mostly_ a matter of style, but in the ITU-T specs
I mentioned, only top-level sections and sub-sections have titles, with
sub-sub-sections having no title and the first paragraph on the same
line as the subsection number.  That may require xml2rfc support.  E.g.:

   8.   Basic encoding rules
   ...
   8.19 Encoding of an object identifier value

   8.19.1 The encoding of an object identifier value shall be primitive.

   8.19.2 The contents octets shall be an (ordered) list of encodings of
   subidentifiers (see 8.19.3 and 8.19.4) concatenated together.

   Each subidentifier ...

   8.19.3 The number of subidentifiers ...

where sections and sub-sections have titles, but sub-sub-sections do
not.

This is almost like having paragraph numbering as a sort of sub-section
numbering, except that you can see that's not quite the rule (e.g.,
x.690 section 8.19.2 has two paragraphs).  But I would be fine with that
too.

That said, x.68x and x.69x series documents not only have many tiny
sections, they are also paginated.

Unpopular idea: maybe we should revisit the no-pagination decision.

Nico
--