trying to see a reeasonable thing to do rather than trying to decode the
I don't think the writers of 2026 anticipated that people would consider
the time delay between IESG approval and RFC publication to be significant.
To my mind, a reasonable time to make the clock start from is the date
of the RFC Editor's announcement of RFC availability; it's an easily
documented date (albeit not published in a permanent medium), and
reflected (at month granularity) in the document itself, which IS a
And to my mind, it "remains at the Draft Standard" level until a new
standards action is taken by the IESG, so the only action that cannot be
taken until 4 months has passed is the IESG approval of the next version.
This is of course slightly inconsistent with the above, but with all the
worries people have had with post-IESG-approval changes, it seems
unreasonable to argue that a standard's final form is 100% set before
the RFC comes out.
The idea of the IESG apprving a document after 3 months and trying to
instruct the RFC Editor that publication delay must be at least one
month seems to me to be "not worth the trouble to go there".
John C Klensin skrev:
Since RFC 5321 (2821bis) has apparently just been posted, I went
back to review what 2026 says about the Draft -> Full Standard
What is says is that (Section 6.2)
A specification shall remain at the Draft Standard level
for at least four (4) months, or until at least one IETF
meeting has occurred, whichever comes later.
That is fairly clear except it doesn't really identify the time
at which the clock starts running. The previous section appears
to answer that question, but it sort of hits the jackpot. What
it says is:
If a standards action is approved, notification is sent to
the RFC Editor and copied to the IETF with instructions to
publish the specification as an RFC. The specification
shall at that point be removed from the Internet-Drafts
An official summary of standards actions completed and
pending shall appear in each issue of the Internet Society's
newsletter. This shall constitute the "publication of
record" for Internet standards actions.
The RFC Editor shall publish periodically an "Internet
Official Protocol Standards" RFC , summarizing the status
of all Internet protocol and service specifications.
So, we no longer remove documents from the I-D directory when
the Protocol Action notice is issued and the RFC Editor
notified. We don't have the Internet Society Newsletter
contemplated by the second paragraph, so it can't be the
"publication of record". And we have dropped STD0001 as a
So, one question is when does the clock start? The other
question, to which 2026 does not appear to address itself at
all, is whether a Last Call can be initiated within that
four-month period or whether it has to wait until the four
months is up.
Plausible candidates for clock-starting would appear to be:
(1) When the IESG signs off and the Protocol Action
Notice is issued. The IESG signed off on this on 22
July and the Notice was issued on 24 July (not enough
different to be worth worrying about). If that is the
relevant date, then, since the IETF met the following
week, it would be possible to process 2821ter/5321bis
to Full Standard any time after 24 November and I should
optimally get an I-D posted sometime this month (early
this month if it is possible to start a four-week Last
Call around the 24th of October).
(2) The publication date of record for the RFC. That date could
be the RFC Index date, in which case we have a month, not a day,
and it isn't clear whether that month is included in the four or
not. Or it could be the date of the actual announcement, which
is today, since that just appeared, date-stamped "01 October,
2008 16:15 -0700". That would imply an earliest processing
date of 1 February, an earliest Last Call date (see above) of 1
January and that I should have a draft up in December or perhaps
around the time of IETF 73.
Opinions (or an IESG decision) welcome, as would be an
indication of whether I really need to write an I-D that
modifies 2026 to resolve this question and whether the IESG
would be prepared to process such an I-D.
Ietf mailing list
Ietf mailing list