Hi all,
Thank you for your comments on what to do with RFC 10000. The RPC will
not issue the number.
There isn't a need to publish RFC 10000 as a test document because we
have a dedicated testing environment for the new queue management system
and website. And RFC 10000 couldn't be issued as an April 1 RFC because
the new infrastructure won't yet be in place to support it.
For those who expressed interest in retrospectives, the sixtieth
anniversary of the Series is coming up in 2029, and the RPC will start
working on "Sixty Years of RFCs" (RFC number TBD), which will follow "30
Years of RFCs" [RFC2555], "40 Years of RFCs" [RFC5540], and "Fifty Years
of RFCs" [8700].
Best regards,
Jean
On 3/13/26 2:58 AM, IETF Executive Director wrote:
John
I agree with your analysis that the RPC can choose to skip the number as
that is consistent with long historical practice, and they do not need
to give a reason for doing so, but anything else would be a policy matter.
Jay
On Fri, Mar 13, 2026 at 3:45 PM John C Klensin <[email protected]
<mailto:[email protected]>> wrote:
(Address for RSWG corrected -- those following this on that list are
encouraged to check out the archive for [email protected]
<mailto:[email protected]> -- my
apologies for initially getting it wrong)
--On Thursday, March 12, 2026 23:50 -0700 Wes Hardaker
<[email protected] <mailto:[email protected]>> 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 <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
--
rswg mailing list -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
-----------------------------------------------
Tools-discuss mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mailarchive.ietf.org/arch/browse/tools-discuss/
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
