[rfc-i] independent submissions to RFC Editor
mankin at psg.com
Wed Jan 12 18:51:45 PST 2005
>From the point-of-view of the IETF i-d tracker system (which is
what decides which drafts live longer than six months), RFC Editor
Queue state does not occur until after IESG approval. States from
Publication Requested, through AD Evaluation, on to RFC Editor Queue
(approved) prevent normal expiration. The tracker doesn't contain
RFC Editor independent submissions until IESG is asked; then we assign
them a state in the database, usually AD Evaluation or IESG Evaluation,
which assures non-expiration. When the IESG completes its review (as
described now in RFC 3932), the draft is placed in the IETF's RFC Editor
Queue state. This is the approved state in which the draft won't
expire, where it stays until the RFC is published.
(Of course, the system breaks sometimes :(, so Carl's 4 drafts could be
ones that should not have expired - we tell authors to watch out...)
Bottom line though: the database/state table for the i-d expiry system is
on the IETF side, and we have a bit of mismatch when it comes to RFC Editor
Queue for the RFC Editor independent submissions.
P.S. Carl, are your 4 totally missing, versus version changes?
> > *> From a procedural point of view it would be nice if ID's that are in
> > *> the RFC Editor's queue would not expire after 6 months (do they right now?).
> > *>
> > The Secretariat is not supposed to expire I-Ds that are in the RFC
> > Editor queue. That's the theory... what the practice is, we are
> > unsure.
> Hi Bob -
> Of the 166 I-D's in rfc-editor.org/queue.html, 4 are not present in the
> http://www.ietf.org/internet-drafts/ directory.
> Please don't hesitate to write me if you want help figuring out what
> the four are or how to contact the IETF secretariat.
> Best regards,
More information about the rfc-interest