I agree with what Dave, Tim, and Harald said. Besides, if we really wanted a delay, we should pay the RFC Editor less and ask them to provide slower service :-) But please keep this as a secret from the IAOC... I would also like to point out its not the bits that are dangerous in a mistakenly or inappropriately approved document. It is the status that the IETF gives to these bits that matter. E.g., Proposed Standard, product of such and such WG. The bits are already out there in many places; we cannot withdraw them. What we can control is the status that the IETF gives for those bits. The modern tools we have for viewing IETF documents can make it plainly obvious to people what the status of an RFC is. But I would also caution a little bit against thinking that the solutions are easy. I think we should have a short deadline for notifying intent to appeal. However, a 5 page document may still get through the RFC Editor in a surprisingly small amount of time. And we can move a document to historic, but what about the other documents that referred to it? We can delay only the documents that we know will be appealed, but this appears to have obvious DoS problems. Nevertheless, I think repairing damage if it occurs is probably the right answer. Possibly combined with a short intent-to-appeal period, so that we can try to do the right thing as soon as possible. Jari _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf