[Preliminary comments on this review: I have contributed to the IAB's RFC Editor Future Development Program (sorry, that's the official title) and therefore to this document. I'm not sure why Pete Resnik picked me as the reviewer, but anyway, I agreed to do it because I hadn't done a full read-through of the document yet. The review was requested by Mirja Kühlewind with the following words: "We're aiming to maximize the reviews for all documents associated with the change in the RFC Editor model. This document is the main deliverable from the RFC future editor model program and describes the new RFC editor model. The more eyes we get on this, the better!"] This review was requested from the I18N Directorate. So here first my comments re. internationalization, as far as there are some: Progress on internationalization of RFCs has been made in the past (RFC 7997). Some more progress in that direction seems highly desirable. In my opinion, the new process proposed in the current document shouldn't make it more difficult to make such progress, but on the other hand probably also won't make it much easier. Process changes and internationalization are mostly independent of each other. [There's also a small personal issue in the Acknowledgments section, which mentions "Martin Duerst (note: replace "ue" with U+00FC before publication)". I'm confident that Peter Saint-Andre and the RPC can figure how to actually change this to "Martin Dürst".] What follows are general comments, unrelated to internationalization. I decided to include everything that caught my eyes, so it ended up to be quite a lot. Abstract: It may be worth mentioning the RSCE and the Editorial Stream here, because they are also important and new. 1. Introduction: "The RFC Editor function is responsible for the packaging and distribution of all RFCs;" "packaging" sounds a bit strange; it might be better to say something like "The RFC Editor function is responsible for the editing and distribution of all RFCs;" 2. Overview It would be great if the first two paragraphs could be exchanged so that the actual new model comes first. But this may need too much editing. I think I might have asked that question somewhere already, but is it clear where April Fool RFCs go? The most recently published April fool RFC　(RFC 8962) says: "This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment." Looking around a bit, this seems to be part of the template of the Independent Stream. Will it be in the RPC's discrecion to publish such RFCs in the future? Essentially, the "RFC Editor" is now mostly just the RPC, and in this case, the text looks a bit strange, not only for April fool RFCs. "In short:": What follows isn't really any much shorter than what preceded it, so the "in short" seems a bit misplaced. "* If approved, such proposals are published as RFCs in the Editorial Stream and thus define the policies to be followed by the RSWG, RSAB, RSCE, and RPC." Shouldn't the IETF LLC also be mentioned here? My understanding is that the LLC can say that something won't work because there's no money for it, but that once it has accepted that a policy is implementable with reasonable means, it also has to follow this policy. 3. Policy Definition The first paragraph is quite long and convoluted. Something like "Policies governing the RFC Series as a whole are defined via a three-step open process: First ..." 3.1.1.4 Mode of Operation: The paragraph starting "When the RSWG is formed" should be moved one paragraph down to just before the paragraph starting "The RSWG may decide by rough consensus" (or probably better the later should be moved up) to make people help understand what the "when ... is formed" part is all about. "for those unable to to attend" -> "for those unable to attend" " The RSWG may decide by rough consensus to use additional tooling (e.g., GitHub as specified in [RFC8874]), forms of communication, and working methods (e.g., design teams) as long as they are consistent with [RFC2418]." Should this read "as long as they are consistent with [RFC 2418] and this document?" 3.1.2.2. Members "As the stream representative for the IETF stream, an IESG member or other person appointed by the IESG" -> "As the stream representative for the IETF stream, an IESG member or another person appointed by the IESG" (And same for the next three bullets; it feels unnatural to have the "an" apply over an "or", and it feels even less natural to have to imagine an "an" for the later two bullets where the preceding options take the definitive article.) 3.1.2.4. Vacancies This is the part that I'm really still not sure about. First, there's a problem with what the text means. Imagine a first 3-month period, during which a second 3-month period starts. So far, the text is clear. But let's say then there's a third 3-month period, which overlaps with the second one. Does that extend the delay again? Or is there only one delay, because the text mentions only one delay? This should be clarified. On a higher level, I think the probability of these things happening are very low, but in the whole new process, this is one of the weakest points. 3.1.2.6. Mode of Operation "although topics that require confidentiality (e.g., personnel matters) may be elided from such archives or discussed in private." The "elided" part is wishful thinking. If something is published once, it's out. "eliding" doesn't really help. So I wouldn't mention this. 3.2. Process: This section may benefit from a bit of introductory text. 3.2.2. Workflow, point 2: "If by following working group procedures for rough consensus the chairs determine that there is sufficient interest in the proposal, the RSWG may adopt the proposal as a draft proposal of the RSWG...": The "may" here 'may' be correct logically, but because it turns up so late in the sentence, it's difficult to read this other than "even if the chairs determine that there is sufficient interest, it's still just a 'may'". I think this would be wrong. Reordering the sentence to have the 'if' part after the 'may' part should solve this. point 3: "Members of the RSAB are expected to participate as individuals in all discussions relating to RSWG proposals so that they are fully aware of proposals early in the policy definition process, and so that any issues or concerns that they have will be raised during the development of the proposal, not left until the RSAB review period." This sentence is simply too long, in particular because after the last comma, it would make sense replace "not" by "and will not be". So please split this sentence into smaller ones. point 4: "call for comment": from a quick search, it seems that "call for comments" is much more widely used, and I suggest to follow that throughout this document. I feel it's also more encouraging, asking for as many as there might be rather than pretending it might be only one or, if there is more, just treating it as an amorphous mass. Also, at least according to Wikipedia, RFC itself stands for "Request for Comments", not for "Request for Comment". [this applies thoughout the document, to quite a few instances] point 7: "If the scope of the revisions made in the previous step is large": It might be better to change "large" to "substantial", because that might better express that it's not only about the volume of changes, but also about their impact (at least I hope so). point 9: "the RSAB will then poll among its members regarding the proposal": Does this need to be so indirect? Why not just something like "poll its members for positions on the proposal"? point 15: "unless the IETF LLC objects pending resolution of resource or contract issues": "objects pending" is a bit obscure. "unless they are delayed while the IETF LLC resolves pending resource or contract issues". This would make it clearer that the IETF LLC cannot object to the policies themselves at this point. 3.2.3. Community Calls for Comment "A URL to the Internet-Draft that defines the proposal" -> "A URL pointing to the Internet-Draft that defines the proposal" "Any commentary or questions for the community that the RSAB deems necessary (using their usual decision-making procedures)" "Any commentary" -> "Any explanations" (commentary sounds just a bit too academic) 3.2.6. RFC Boilerplates "Each stream to which the boilerplate applies, which approves that the boilerplate meets its needs": This can be read as the boilerplate approving the boilerplate. Not sure how to fix this, but if somebody has a good idea, please apply it. 4. Policy Implementation 4.1. Roles and Processes "by legacy RFCs which apply to the RPC and which have not yet been superseded by Editorial Stream RFCs": "legacy" -> "existing" (Legacy can mean leftover, outdated, old, but my understanding is that these RFCs are perfectly fine, no rush and no need to update them. Caution: the word 'legacy' turns up again later and should be fixed there, too.) 4.3. RPC Responsibilities point 17: "depositing copies on the RFC Editor site both individually and in collections": As far as I understand, maintaining the RFC Editor website will also be the responsibility of the RPC, but this isn't listed in these points. This should be added. The word "depositing" then makes even less sense than it does currently, I'd replace it with "publishing". point 22: "Providing storage and preservation of records.": I (mis)read this as "Providing storage, and preservation of records". Maybe "Providing for the storage and preservation of records" would avoid such misreading. 4.4. Resolution of Disagreements between Authors and the RPC "If there is a conflict with a policy for a particular stream, the RPC should consult with the relevant stream approving body and other representatives of the relevant streams to help achieve a resolution, if needed also conferring with a per-stream body such as the IESG or IRSG." This looks like a mess. We have - the relevant stream approving body - other representatives of the relevant streams - a per-stream body To me, these seem to be one and the same thing three times. If they are supposed to be the same, then we shouldn't need to mention them three times. If the intent was that these should be different, then the text has to be written so that the difference is much clearer. 5.4. Conflict of Interest Unclear whether the following is one or two paragraphs: >>>> The RPC service provider may contract services from the RSCE service provider, and vice versa including for services provided to the IETF LLC. All contracts between the two must be disclosed to the IETF LLC. Where those services are related to services provided to the IETF LLC, IETF LLC policies shall apply, including publication of relevant parts of the contract. >>>> Also unclear how that's being generate. Also, there are other, similar instances. 6. Editorial Stream All documents produced by the RSWG and approved by the RSAB shall be published as RFCs in the Editorial Stream with a status of Informational. I think there should be an additional sentence saying that despite the name of the status, these documents nevertheless define policy. (in the long term, a better name for the status may be desirable, such as "RFC Policy" or something similar) 8.2. RFC Series Editor Implied by the changes outlined in the previous section, the responsibilities of the RFC Series Editor (RSE) as a person or role (contrasted with the overall "RFC Editor function") are now split or shared among the RSWG, RSAB, RPC, and IETF LLC (alone or in combination). In this list, the RSCE should also be mentioned, because the RFC Series Editor also had consulting/advisory roles, and these are now held by the RSCE. 9. Updates to This Document I think this section should be before section 8, because it's material for the future, whereas Section 8 is just documentary about the past.