FWIW and noting that this has been proposed more times than I can count and since long before the current model...
--On Sunday, February 9, 2025 15:24 -0500 Joel Halpern <j...@joelhalpern.com> wrote: > In the abstract, I like the idea of getting RPC reviews done > early. However > > 1) It is not at all clear that it falls within the RSWG / RSAB / > RPC purview to change the IETF processing sequence. Nor what it would mean for the other streams. > 2) It seems that we would need more staff. Even if we assumed > that the early review saved later work, I doubt it saves all the > later work. And the time frame the RPC currently aims to meet for > reviews is longer than we would want for something like a last-call > / IESG processing review (which while it often takes longer, we aim > for 4 - 6 weeks.) First, there are two ways to think about an "RPC review". One is similar to the all of the other reviews, in which the RPC would be expected to make comments on the document but not start editing. The other would involve a preliminary editing job. They have different implications for workload: * Review and comment would probably take less time prior to the post-approval editing stage, but maybe not much less, especially, as Joel suggests, if the document changed significantly during or after IETF LC or IESG processing. There would also be differences depending on our expectation about the comments which could range from "the document is/is not in good shape but will require work on..." to expecting every issue to be identified. The other is an actual edit which, because documents do sometimes change significantly after IETF LC starts, could nearly double the time requirement. It would have one other implication: at present, we allow a document to be prepared and go through the I-D process in almost any format as long as either RFCXML or text (or html?) can be handed off to the submission tool. If the RPC is going to do the editing, presumably any further document modifications to the I-D have to be done in RFCXML or the edit essentially forks the document. The latter is just looking for trouble. The former would require that all authors learn that language to a much greater extent than is the case now for AUTH48 _and_ that the RPC be prepared to work in/with the draft dialect of RFCXML and probably that bugs and misfeatures in processing of that version that have been ignored for years because they have no impact on the production version be fixed. While I'd like to see those fixes, that does not sound practical to me. > 3) This would also seem to need changes to the RPC work flow, since > what the RPC reviews is not the I-D that we work with during > development. If the RPC was actually going to do an editing pass, rather than a preliminary review, it would also need changes to author and WG work flow and to tooling. > I am not sure how to reconcile these parameters. With the other considerations included above included, I think the conclusion is probably "impractical"... at least unless we are willing to accept significant changes in requirements for I-D authors and editors and, for many cases, large increases in the overall time between when a WG (for example) thinks it is finished with a document and when that document is actually published. best, john -- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
