On 6/2/19 12:59 PM, Heather Flanagan wrote:
*If the editors only look at changes, critical context will be missed. Part of the RFC Editor job is to ensure consistency, which means reviewing a document in the context of other items published in the series. It is unclear how we are supposed to handle a -bis document where only sections of the document are updated, potentially resulting in large questions of terminology.
That's a reasonable point, and it's one that I would expect the publication arm to make its own decisions about. I would hope that the unchanged parts of the document would impose significantly lower workload than those that have been added or changed. I can't quite tell from your comment whether that is a bad assumption.
* I agree with Stephen Farrel’s concern regarding giving known issues a “free pass” - republishing them without changes implies endorsement. This is a reputational problem for the series. (I do see the flip side of this, however, that significant delays in updates and overall publication of material is also a repetitional hit for the series.)
Do you have thoughts about the specific proposal that such known issues are at least called out if they can't be fixed? There are a lot of documents in the series that have been published either as informational documents without IETF consensus, or as part of the ISE stream, that had known flaws in them, such that they were published with an IESG warning at the top about suitability of use. My proposal includes a congruent mechanism, intended to address the concern you describe above. Do you think that the proposed approach is insufficient? If so, can you think of anything that would be sufficient?
* I share John Klensin’s concern around what should happen with normative references ( "And, of course, none of that addresses the cases in which other documents exist that normatively reference the original RFC and whether they are automagically treated as referencing the replacement document (works for some types of changes that might be covered by your I-D but not others) or continuing to reference the older, now-obsoleted one.”). This will need to be handled with explicit guidance to the RFC Editor.
I really admire this problem for its complexity, but observe that it exists for every bis document the IETF ever publishes. There was an earlier effort to redefine how we progress documents, which failed (as far as I can tell) largely because the participants in that effort got stuck arguing about which specific oceans to boil. I'm trying to take that experience into account in defining a fairly narrow scope of fixing one problem. I'd like to see some effort launched at some point to address the different problem you just described, but am extremely hesitant to take it on as part of this work.
* How should documents that span format and style guide eras be handled? For example, if a -bis document is updating a document that was created before there were required IANA and Security Consideration sections, should those be added? If the original document was based on .nroff and not XML, how much should the RFC Editor change/update with regards to document formatting of the original text?
I would think that you have more experience with these topics than anyone else on this mailing list, and would love to hear your proposals. :)
* My preference for all RFCs that originate from a working or research group is that the RFCs have no more than two editors, and all contributors are recorded in the contributor section. I also recognize my preference on this one is not the consensus of any document stream, and I’d rather not reopen that battle on this particular thread. That said, I am unclear on what the expectation is with regards to the author list for a -bis document. If the original authors are retained in the author list, they will be requested to respond during AUTH48. It may be simpler to move them to contributors, and have someone be assigned as an editor for the -bis document.
As with the normative reference question above, I believe that this is a separate problem that already exists with all bis documents the IETF publishes; and, as with that problem, I would not like to take it on as part of this effort.
* If there are verified editorial errata associated with sections that are not otherwise being changed during the -bis process, can/should they be fixed in the -bis document?
Well, that's what I propose in section 3.1 criterion 3, but I'm happy to hear opinions about whether that's the right thing to do.
/a
