I have read draft-iesg-rfced-documents-00.txt and generally support this change in the current practices. In review of background BCPs, in particular RFC 2026, I find this change can, and in my opinion, should be returning to the procedures outlined in RFC 2026. However, I do have some concerns (see below) and some editorial suggestions (which I will send separately to the I-D's authors). General support: It is my opinion that RFC 2026 did not intend for the IESG, nor the RFC Editor for that matter, to undertake a "full scale" technical review of the individual submission. RFC 2026 described the IESG review propose "[t]o ensure that the non-standards track Experimental and Informational designations are not misused to circumvent the Internet Standards Process." RFC 2026 described the RFC Editor's review purpose as ensuring "editorial suitability" and subject to "editorial considerations". While I support the RFC Editor continued right to "refuse to publish a document which, in the expert opinion of the RFC Editor, is unrelated to Internet activity or falls below the technical and/or editorial standard for RFCs", we should continue the long standing tradition of allowing publication of alternative ideas, alternative protocols, and April Fool's RFCs. Concerns: I am concerned is the document by this Section 3 paragraph: Note that judging the technical merits of submissions, including considerations of possible harm to the Internet, will become solely the responsbility of the RFC Editor. The IESG assumes that the RFC Editor will create its own mechanisms for additional technical review. I argue that the RFC Editor should not refuse publication of a work because, in the opinion of the RFC Editor, that work would be harmful to the Internet. While I can see that cases where a document fails to met the technical standards of RFCs, a document that causes harm to the Internet does not necessarily below those technical standards. Determining whether a document would cause harm requires more detailed review than simply determining whether the document fails to met the technical standards of RFCs. Certainly the technical standard of RFCs (including those produced by the IETF) is, at times, quite low. Hence, I recommend the phrase "including considerations of possible harm to the Internet" be dropped or, better yet, this paragraph be replaced with language more consistent with that used in RFC 2026. Also, as the kind of harm discussed in section 5 is about confusion with standardization efforts, not about harm caused by technical flaws in the technical specification itself (as discussed in Section 3), the meaning of 'harmful' is confused in this document. Deleting the phrase as suggested above would remove that confusion and focus the issue on proper standards coordination and not in-depth technical review of the document. Kurt