[rfc-i] obsoletes/updates

John C Klensin john-ietf at jck.com
Fri Jun 19 07:10:03 PDT 2015

(1) Just -00 or persisting?   Yes
(2) Carried into RFC?  Current RFC-to-RFC info, yes.  I-D to I-D
info, no.

Details and explanation inline below. 

--On Friday, June 19, 2015 07:54 +0000 "Joe Hildebrand
(jhildebr)" <jhildebr at cisco.com> wrote:

> Requirements questions:
> Would you expect the obsoletes attribute to be on just the
> -00, or to persist through further versions?  (I could see
> either, with a slight preference to just the -00, with the
> tooling giving warnings as needed)

If it is to be used for threading, the -00 is obviously the most
important one.  Like you, I could see either, with a _very_
slight preference for carrying it forward or leaving it to
author discretion.  I'd expect the latter to depend on how
significant the changes were across the transition.  In other
words, if draft-abc-def-new-version-00 differed very little from
draft-xxx-yyy-old-version-05, then -00 only should be quite
adequate.  If there were big changes across the transition
rather than, e.g., renaming for procedural reasons, it would be
nice to carry the information along.  In cases of doubt, bits
are cheap.

A possible useful analogy (of which I was reminded by an
unrelated conversation this week) occurs with (I-D)
version-by-version change logs.  Some of us like them because
they provide a useful incremental record of what the editor
thought was being changed and lets WG participants check that
off against topics on lists, in trackers, etc.  It also pulls
that information together into one place and as a timeline as
compared to, e.g., requiring generating and comparing multiple
diffs.  Others prefer to stick with the diffs on the grounds
that they are guaranteed to be accurate about what changes were
made.  We generally leave the choice up to authors although I've
occasionally heard of WG Chairs or ADs being insistent about the
logs.  I think that is a good choice -- the authors (and WG
leadership) are in a better position to determine what is useful
or needed that some tool or set of rules.  

I think the answer about an obsoletes attribute linking
replacement I-Ds (and "replaces" might be a better term for what
I'm getting at than "obsoletes") beyond -00 is, on the same
reasoning, quite appropriately left to author discretion.

> Would you expect the obsoletes attribute to be on the RFC that
> replaces the I-D? (this seems like a much bigger departure,
> and my slight preference would be "no", but it follows from
> the desire to de-manualize the tooling).

I'm confused about what you are asking, so let me try to make a
distinction.   I think our historical "obsoletes" attribute --
pointing to a previous RFC or a placeholder for an RFC number --
continues to be useful, important, and something that should be
carried into an RFC that ultimately results from the I-D.    I
think I-D replacement information -- pointing to what is
conceptually an earlier version of the same I-D or an earlier
I-D that was dropped after significant text and/or concepts were
incorporated into the new one even if there are significant
changes involved -- is more like I-D version change log
information and should disappear in the transition to an RFC.    

In the (I think very rare) cases in which between-I-D tracking
information belongs in the RFC, I think it should be part of
acknowledgments or a narrative historical section or appendix
that has more to do with the changes in concepts than ties to
particular I-D versions.  That is also consistent with what I
assume is still our general preference to keep explicit
references to I-Ds, much less I-D versions, out of RFCs.


More information about the rfc-interest mailing list