On Mon, Jun 3, 2019, at 03:59, 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. There is a difference between concentrating on the *changes* and concentrating on the *diff*. Heather is right in saying that a narrow focus on a diff would be inappropriate. However, I think that it should be possible to constrain efforts to making narrowly targeted changes. Not in general, but often enough that this proposed change is useful. The draft says that a diff is provided. I think that is still useful, but it might pay to further highlight the inadequacy of reviewing by diff alone. > * I share John Klensin’s concern around what should happen with > normative references I confess that I don't understand this concern. Old documents will continue to refer to the replaced document. More interesting is where the updated document cites replaced documents. Like errata (as below), should it be in scope to update those references? I'd say yes, but it will require judgment. In many cases, the updates will only have the effect of pulling in additional errata from a similar sort of -bis update, but some changes might be inadvisable. e.g., an update from RFC 5246 to 8446 might not be appropriate. > * 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 don't see a major problem here, except perhaps a purely mechanical one.. That is, it might be hard to mechanically produce a diff that makes sense. The new document should use the current format. That said, this is worth writing down, because this is likely to be a real problem for the foreseeable future. > * 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? Good question. I'd say yes, even for design errata with clear outcomes. That increases the scope of the -bis, so I would leave the final decision with the working group. If any errata are not fixed, we might want to suggest that those are explicitly listed in the "changes" section along with Stephen's requested list of "stuff we're not fixing".
