There are a few things I think people should keep in
mind while discussing this:
Russ has presented the IETF-particular case. If the
solution lies in IETF process (i.e., update to RFC2026),
that's fine. If the solution lies in adjusting RFC process,
then we need to make sure there is agreement on how
that impacts the whole RFC series (i.e., wider than IETF
audience involved).
For example -- shortening the appeal window (or going
to a 2-stage process, as Ted noted) is an IETF process
change. Determining that "withdrawing a published
RFC" meets appeal-resolution requirements is an IETF
process discussion.
Changing the status of documents, or withdrawing them
entirely, impacts the RFC series (RFC4844 and related).
A wider discussion will be needed. (Note -- that wider
discussion might be needed *anyway*, if there is belief
that the ability to withdraw a published RFC is
needed for other reasons.)
Leslie.
IETF Chair wrote:
Dear IETF Community:
Due to a lot of hard work, the RFC Editor is publishing approved
Internet-Drafts more quickly. Overall this is just what we want to
happen. However, I am concerned that the RFC Editor is might be getting
too quick. Anyone can appeal the approval of a document in the two months
following the approval. In the past, there was not any danger of the RFC
Editor publishing a document before this timer expired, and the only
documents that became RFCs in less than 60 days were the ones where the
IESG explicitly asked for expedited processing. The recent improvements
by the RFC Editor make it likely that all documents will be moving through
the publication process in less than two months.
If we receive an appeal before the RFC is published, we can put a hold on
the document, preventing pblication until the appeal has been studied.
However, we have no way to pull an RFC back if it is published before the
appeal arrives. As we all know, once an RFC is published, it cannot be
changed. Thus, the RFCs form an archival series. If we find a bug in an
RFC, we write a revised RFC that obsoletes the one that contains the
error. So, what should we do if there is a successful appeal after the
RFC is published?
While we figure out what policy we want, I have asked the RFC Editor to
not publish any IESG approved documents until their appeal timer has
expired. I also challenged the RFC Editor to move things along so fast
that this matters. I suspect they can. Which means that the whole IETF
community needs to help the leadership figure out the appropriate policy
before the rapid processing of Internet-Draft documents into RFCs becomes
the norm.
Russ
--
-------------------------------------------------------------------
"Reality:
Yours to discover."
-- ThinkingCat
Leslie Daigle
leslie@xxxxxxxxxxxxxxx
-------------------------------------------------------------------
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf