> > Also, because of the two month timeout in the RFC 2026 appeal > > process, it turns out that our standards process actually implies > > that an RFC MUST NOT be published until two months after approval.
> I don't see that that follows - we can always declare the mis-published RFC > Historical and publish a fixed one later, as we did with (for instance) the > RFCs for RADIUS that came out with the wrong port numbers in them, or the > SNMPv3 RFCs that turned out to have the wrong encrypted-values in the > examples. I strongly concur. Our processes should (by default) be forward looking. We should not be adding extra (and harmful) delay to our processes in order to facilitate appeals, or those that would raise them. Let's not have the cost outweigh the benefit! Thomas _______________________________________________ Techspec mailing list [email protected] https://www1.ietf.org/mailman/listinfo/techspec
