John C Klensin
john-ietf at jck.com
Thu Jun 25 08:12:25 PDT 2015
--On Tuesday, June 23, 2015 19:50 -0500 Nico Williams
<nico at cryptonector.com> wrote:
> On Fri, Jun 19, 2015 at 10:10:03AM -0400, John C Klensin wrote:
>> (2) Carried into RFC? Current RFC-to-RFC info, yes. I-D to
>> I-D info, no.
> Hmmm, well, for RFC formats where this metadata can be kept and
> displayed without being too annoying (e.g., for HTML, say, but
> not for .txt), sure. For .txt, no.
> RFCs can update/obsolete/move to historical other RFCs.
> Internet-Drafts can mean to update/obsolete/move to historical
> other RFCs.
> Internet-Drafts can replace other Internet-Drafts.
I may be just strange and/or old and/or stuck in old ways of
thinking about things that are no longer relevant. As evidence
of that possibility, note that I'm still very concerned that
declaring an XML source format as the de factor archival form
and then having multiple representations of it may be a decision
we will regret in a decade or two.
However, the notion that I-Ds are transitory documents that
expire for procedural purposes and that they are not referenced,
at all, from RFCs except as works in program (and then not
normatively) has served us well. I have argued that the RFC
Editor should allow informative references to particular
versions of I-Ds that are referenced purely for historical
context and still believe that. I think that carrying tracking
information from I-Ds forward into RFCs would reduce the clear
importance of being sure that RFCs are self-contained and would
invite "what is really the standard" questions when the RFC is
referencing documents that say something different.
Remember that we fairly often make rather significant changes to
details post-last-call and that those changes often don't appear
in I-Ds, especially not with justification and explanation.
For those reasons anod others, If someone wants to back-trace
the history of an RFC, I really think we want to force them into
the tracker because the historical information is, or is
supposed to be, there, not just pointers to the earlier versions.
> RFCs notionally just exist without reference to any earlier
> draft form. However, it's convenient to have at hand the
> history of how an RFC was pulished, which includes all the
> relevant metadata, such as:
> - last I-D prior to publication
> - time (date ranges) spent on the RFC-Editor queue at each
> state - shepherding AD
> - IESG review and ballot record
> - appeal record
> - links to mailing list archives on which reviews of the I-Ds
> took place
> - previous I-D handles
> - links to the XML (and/or other submission formats) for all
> past versions of the I-Ds leading to the RFC's publication
See above. Note that some of that information, if more readily
available, invites claims, years later, that the consensus
behind a particular spec was insufficient. We are far better
off, IMO, taking the position that the community decided it had
adequate consensus about the document as published (something
that is not true of any I-D), that the appeals window closed,
and therefore so did the matter. While the information is in
the tracker, explicitly calling it out in the RFC as
authoritative material increases the risk.
> In practice most of this has to be collated when it's needed
> (if it's needed). It's not that hard to do it, and mostly
> it's not needed, so in the end it'd be best not to add this
> collation workload to the RFC-Editor's. It suffices that the
> datatracker have it, so a link to the datatracker page for the
> RFC (or last I-D leading to the RFC's publication) should
We have that today if one knows to go to the datatracker and ask
under either the RFC number or the I-D name. I'd like to avoid
it because I believe that, for anyone just interested in the
spec and not how it came to be and the vast majority of those
who want or need to dig into the history, it would just be
clutter to be ignored, but I wouldn't see a huge problem with a
boilerplate line somewhere in the RFC format that said "For
information on the history of this document, search under the
RFC number at https://datatracker.ietf.org/doc/. That would, of
course, require that we keep that URL completely stable... and
that is another reason to not do it.
More information about the rfc-interest