> Gee, nobody wants to publish documents that are harmful to > the Internet, but there can be disagreements about the > amount of review needed and the sense of how a specification > might cause harm.
There can also be confusion if a reader believes that a document in the RFC series has been through one review process when it has actually been through a substantially different review process. Right now we appear to have have different review processes for Informational and Experimental RFCs depending on whether they've been produced by IETF (either via a WG or as individual submissions) or as independent submissions to the RFC Editor. I won't assume a priori that say IETF's review process (consisting of AD writeup, IESG review, last call, etc.) is inherently superior to the RFC Editor's review process (consisting of I don't know what). However I do think that differences in these processes will tend to result in differences in document quality that at the very least should be communicated to readers. And I sincerly doubt that the RFC Editor can provide adequate review of documents affecting multiple areas without a public feedback mechanism similar to IETF last calls. I certainly encourage the RFC Editor to employ cross-area review for any document that describes a protocol that has the potential to impact multiple interest areas - (and not just "areas" in the IETF sense). When documenting existing protocols, there has always been a tension between accurately documenting the protocol as it appears in the wild and documenting the protocol as it "should" work. Both IETF and the RFC Editor should encourage authors documenting existing protocols to document them first as they are actually implemented and to clearly separate any opinions about how they "should" work from the actual descriptions of how they _do_ work. At the same time it is important to make readers aware of the hazards of implementing and using a poorly-designed protocol. One way to do this would be to include a detailed discussion of the protocol's hazards (security or otherwise) and any fixes for those hazards in an appendix, while including pointers to that appendix in appropriate locations in the main protocol description. > The IESG is the IETF's designated final review arm and it > treats specifications as being available for any environment > and as needing multiple cross-area reviews for potential > harm to the Internet (as well as other cross-area issues). > I believe currently independent protocols do not > get multiple cross-area reviews of this sort, though I > might be wrong. There is not a statement and the reviews > are not public. > > The IESG no longer reviews RFC Editor independent submissions > for content, which is correct for the independents. However, > they do have to read them for conflicts. In the not too > distant past, it was a not surprising example when > an independent protocol went by with a plaintext password > because it was "for the LAN" and documented the existing > protocol. > > I don't know if there is now security review on every > independent document (versus a security reviewer only for > security-specific documents). But anyway security issues > (and others) that could harm the Internet in independent > protocols can go by inadvertantly if the reviews are not > cross-area, at least in my experience... _______________________________________________ INDEPENDENT mailing list [email protected] https://www1.ietf.org/mailman/listinfo/independent
