[Resending with a corrected address for RSWG]
anyone want to make an argument in favor of issuing something
with the number 10000?
Oh, all right. Two possibilities:
1. Issue it on the first day of next month, with minimal content (perhaps based
on the fact that RFC 16 is presumably the shortest RFC ever and that 0b10000 is
equal to 16).
2. Issue it purely as a test document, some weeks before RFC 10001.
I don't seriously advocate either of these. "Not issued" works for me.
Regards/Ngā mihi
Brian
On 07-Mar-26 11:28, John C Klensin wrote:
--On Friday, March 6, 2026 15:24 -0600 Jean Mahoney
<[email protected]> wrote:
Hi all,
On 3/6/26 2:35 PM, Eric Rescorla wrote:
On Fri, Mar 6, 2026 at 11:59 AM John C Klensin
<[email protected] <mailto:[email protected]>> wrote:
(copying RSWG because this is a policy matter)
--On Friday, March 6, 2026 10:30 -0600 Robert Sparks
<[email protected] <mailto:[email protected]>> wrote:
>
>### RFC Production Center work
>
> We are primarily focusing on the RFC Production Center
> modernization tasks, both on the workflow management
> tooling, the RFC Editor website rewrite, and editor tooling
> because of issues that need to be resolved before RFC10000
> is published. Deployment of these components will take
> place just after IETF 125. The publication of RFC10000 is
> currently expected to occur in May.
One tiny suggestion about this, drawing on RFC Series
precedent and if you are not already ahead of me: Don't
publish an RFC 10000, just mark the number as "Not Issued" and
move on. If it is assigned to the next document that comes
up in the normal order of events, it is likely to turn into
bragging rights, some sort of dispute over who gets the
number, or an argument about precedents when it is time for
RFC 20000, any one of which would be inherently painful and/or
disruptive. Or, if you want to use the number, look to RFC
1000 as an example and make it an Editorial Stream document
about the series, one that constitutes a summary of actions
already taken or otherwise unlikely to be obsoleted. If it
were thought to be interesting enough to justify the effort, a
discussion of what it took to fix things and allow a
five-digit number might be such a document. Even then, I
think we'd all be better off if that were published as RFC
9999 and 10000 were just permanently reserved.
FWIW, I tend to agree with John about this. I think there are some
safe things you could put here ("57 years of RFCs"), but having it
be a technical document seems unfortunate.
[JM] The last big, round number (RFC 9000) went to QUIC. RFC
numbers 4000, 6000, and 7000 were never issued. Other big, round
numbers like RFC 5000 were used for lists of RFCs, but that
practice was retired with RFC 7100.
The RPC has a policy that RFC numbers can't be reserved, and we
haven't received any serious inquiries regarding RFC 10000. There
isn't a retrospective document in the works that I know of (i.e.,
the RPC hasn't started one). <individual hat on> I'd be okay with
not issuing RFC 10000 and just moving forward.
Jean,
Thanks. And not issuing a document with that number would certainly
be a satisfactory solution and much less work than a retrospective
document of any sort. My vague recollection is that the idea of
issuing 999 as a catchup document and then immediately issuing 1000
to summarize the series to date was Joyce's, but those sorts of
summaries were retired long ago. RFC 1000 might actually been the
last of those; RFC 7100 retired the Official Protocol Standards
series, which was different and continued much longer.
Since that was just with your individual hat and I don't have a hat
to wear in this particular discussion and assume that ekr doesn't
either, anyone want to make an argument in favor of issuing something
with the number 10000?
best,
john
-----------------------------------------------
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]
