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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf