BTW, I really like where this is going. We need more ways to smooth the path toward maintaining protocols (see what I did there?).
In the spirit of providing feedback on the document as written...
On Wed, May 8, 2019, at 12:50, Adam Roach wrote:
> Thanks for noticing and providing proactive feedback.
2. The changes from the document being obsoleted must not constitute
the majority of the document. This is a subjective evaluation,
not a mathematical one.
I think that there is case for assessing a "substantial portion of the document or a significant technical change" rather than "majority of the document" test here. That makes the call even more subjective, but I don't believe that it would be appropriate to pass something that changed fundamental concepts without thorough review. For instance, it might be possible to amend the definition of dialog-forming requests in SIP without hitting enough of RFC 3261 to meet a "majority" test, but publication of a change like that under the proposed process is not likely to be appropriate.
4. The document SHOULD contain an appendix detailing the changes
from the RFC it is replacing. Any change for which the rationale
is not abundantly obvious should be explained in this appendix.
I don't see why an appendix is stipulated. Concise descriptions of changes in introductory sections are often a very welcome way to explain differences.
3. The "Last-Call notification" MUST also include a pointer to a
mechanically-generated diff [...]
This is good, but you might make it easier by citing the section that summarizes changes.
Section 3.3 is I think the most difficult part of this. I agree with you that finding a way to be able to publish a document without touching certain outdated pieces is very important, but I think that your solution contains another problem.
If some things are controversial, we might find that even listing things that don't follow best practice to be difficult. I would instead suggest that rather than requiring enumeration of all the "icky bits", we instead label what is updated and say that "everything else is left as is and might not reflect current best practice". That is,
This document is a revision of a previously published RFC. Those
portions of the text that have not been updated might not meet
current best practices for documents published by the IETF.
I know that this is weaker than what you are proposing, but it should avoid having people avoid updates where there are these booby traps. I'm happy if you encourage the listing of things that are especially problematic, but you use the "m" word (in lowercase, which I don't quite follow), which creates a barrier.
Now, I would prefer that people work through those controversial points, but I've seen enough good work stymied by bickering over unimportant or unrelated points that some caution might be wise.
Finally, you might consider promoting the real content from Section 6 to the body of the document.
