Re: I-D Action: draft-wilde-updating-rfcs-00.txt

[John C Klensin <[e-mail]>]

Sorry... I was going to not get further involved in this
discussion, but...

--On Monday, December 12, 2016 13:39 +1300 Brian E Carpenter
<[e-mail]> 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