At Thu, 29 Nov 2007 09:54:47 +1300,
Brian E Carpenter wrote:
On 2007-11-29 09:21, IETF Chair wrote:
...
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?
I thought about this a bit when the RFC Editor started to catch up and
accelerate; it's excellent news that it's no longer a theoretical
question, so kudos to the Editor team (and IANA, who also have a role
to play in getting many RFCs out).
My conclusion is that the number of appeals is relatively low. I'd hate
for the low risk of having to roll back an approval to slow down all
publications. So my personal preference is to not hold up publication
(unless there is good reason to expect an appeal), but to add a new
RFC status, let's call it PROVISIONAL for the sake of argument, that
would be applied if an appeal is received within the 2 month window
but after publication. If the appeal succeeds, the status can be
changed as appropriate (likely to HISTORIC), and if the appeal fails
it can revert to its original value.
So, obviously it's important not conflate statements about what the
rules *should* say with what they *do say*, but with that in mind, my
reading of 2026 is that this isn't necessarily sufficient. Here's
the relevant passage:
S 6.5.2.
If circumstances warrant, the IAB may direct that an IESG decision be
annulled, and the situation shall then be as it was before the IESG
decision was taken. The IAB may also recommend an action to the IESG,
or make such other recommendations as it deems fit. The IAB may not,
however, pre-empt the role of the IESG by issuing a decision which
only the IESG is empowered to make.
It seems to me that the situation of an existing RFC marked HISTORIC
is pretty different from that of no RFC existing at all, so what
ISTM that what you propose would require a change to 2026.
-Ekr
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf