This is an important question to get sorted out. And, it impacts
the (motivation for) the discussion of permanent stable identifiers
post-approval.
(STD series numbering is not the issue under discussion in
that requirement. I had assumed/understood NEWTRK was going to
sort out what our document series are called/how they are handled,
and techspec should follow from that).
Leslie.
Brian E Carpenter wrote:
Thomas Narten wrote:
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!
I can buy this argument, but note that it is at least a clarification
if not an actual update to RFC 2026. And the notion of a withdrawn RFC
is new. So we have to be very clear about that.
Brian
_______________________________________________
Techspec mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/techspec
_______________________________________________
Techspec mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/techspec
