Subject: [Tools-discuss] Re: March tools update
From: John C Klensin <[email-masked]>
To: Wes Hardaker <[email-masked]>, Warren Kumari <[email-masked]>
Cc: Dave Thaler <[email-masked]>, Alan DeKok <[email-masked]>, Robert Sparks <[email-masked]>, Tools Team Discussion <[email-masked]>, WG Chairs <[email-masked]>, RSWG <[email-masked]>
Date: Fri, 13 Mar 2026 03:44:29 -0400
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>

(Address for RSWG corrected -- those following this on that list are
encouraged to check out the archive for [email-masked] -- my
apologies for initially getting it wrong)

--On Thursday, March 12, 2026 23:50 -0700 Wes Hardaker
<[email-masked]> wrote:

>> I don't think that it is a "dummy" RFC, I think that it is more
>> that 10000 is "special" from a human / vanity viewpoint, and so
>> removing it from the lottery prize pack would be nice.
>> 
> 
> How about something like this, that is helpful, timely, somewhat
> humorous, educational, and a bunch of other adjectives:
> 
> https://github.com/hardaker/draft-hardaker-ietf-protocol-field-size
> s/blob/main/draft-hardaker-ietf-protocol-field-sizes.txt
> 
> [obviously incomplete]

Wes (and Warren),

I think we could diddle around with this enough to make it
acceptable, just as I think we would fuss with Warren's idea enough
to make it non-ridiculous.   I think anything obviously ridiculous
would ultimately reflect badly on the series (especially if not in
April 1 form), at least without an introduction that would require
some effort to write and get right.  The problem with either idea
--or my silly variation on Warren's-- is that, for publication in the
IETF Stream, we'd have to fuss enough to get community consensus that
it is ok to publish (or at least enough consensus to get it signed
off).  Probably not as much work as the type of actual historical
review and perspective as Brian and I have been discussing, but
enough to have real costs.   Even publication in any of the other
streams would require some sort of review and discussion and then
work by the RPC to publish, get metadata right, etc.   Jean's
suggestion of just skipping the number is the only option I can think
of that does not require RPC work, work that has to be prioritized
and that pushes some publication of some other document back, however
slightly, and therefore would have real costs.  And, while the energy
that has gone into this discussion --both of skipping the number and
of finding an alternative to doing that while recognizing that the
number is problematic-- cannot be recovered, it has consumed far more
time and energy already than I anticipated when I first suggested
recording the number as "Not Issued".  

If "Not Issued" were a new concept, I would have expected this sort
of discussion, but there is years of precedent for it, including its
appearance in the header of the text-form rfc-index.   And, fwiw, the
comments surrounding my suggestion and Jean's, plus those around
publishing a substantive historical document, plus those descending
from Warren's suggestion, suggests strongly to me that (a) any action
other than an RPC decision to skip the number would now be now be a
policy question (including, given Jean's comment, just reserving the
number for a particular spec) even if it were not one when I posted
my note, and hence (b) that there is almost no hope of getting
consensus to just publish an ordinary technical spec in sequence with
that number as Marc suggested.

Any chance we can just accept Jean's idea and comment and move on?

   john