Sorry... I was going to not get further involved in this discussion, but... --On Monday, December 12, 2016 13:39 +1300 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > On 12/12/2016 10:23, Scott O. Bradner wrote: >> see, for example, >> https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposin >> g-isd/ > And while we're reviewing ancient history, let me say that the > new IESG in 2005, with me as the new Chair, did spend hours > discussing that draft and failing to reach a useful consensus. > But not because we thought there was no problem. As I've said > more than once, there is a problem, for any protocol that is > complicated enough to need several interlocking RFCs to define > it. As those various components require updating, we grow a > dependency tree. The "Updates" tag on the more recent RFCs is a > very coarse way of expressing the dependencies. And a vague one that covers a large range of relationships. I have assumed that the indefiniteness of that range is at least part of what motivated Erik's effort. > Requiring the updating RFC to be clear about why and how it is > updating other RFCs is IMHO a good idea. However, I don't > think that a mandatory section in the updating RFC is the > right way to ensure this. It would just become a box-ticking > exercise. Bite that the IESG has tried that by, IIR, requiring "updates Foo" statements in Abstracts and Introductions or separate section, and, IMO, has gotten, not merely box-ticking but meaningless statements that contain no useful information and almost no one reads. The other difficulty is that, even if each updating RFC is clear about what it is changing, if there are multiple documents (either contemporaneously, serially, or both) and multiple updates, one rapidly ends up with hopeless spaghetti-threading and even some question about what the standard actually is. That is the problem to which draft-ietf-newtrk-repurposing-isd was addressed and for which it got WG consensus as a solution. It then became the problem that the IESG decided was not important enough to be worth the trouble (or at least couldn't reach agreement that it was). Attempts to reintroduce the topic from time to time over the last decade have gotten similar levels of enthusiasm from the IESG. If anyone thinks this is really a problem, tell it to the Nomcom and tell them that they should extract promises from IESG candidates. I hope they would listen if enough people deliver that message. Otherwise, well, it is probably worth just getting used to the problem because narrow rules about descriptions of the updates won't help much. john