[rfc-i] Relation to other RFCs - Updates
mrex at sap.com
Thu May 3 15:03:20 PDT 2012
> Martin Rex wrote:
> >rfc2223 section 12 (defining a narrow scope for Updates: and Replaces:
> >as RFC meta-data) seems to be similar to Section 2.11 (page 9) of
> >this document:
> >The purpose of _all_3_ is to guide RFC reader into finding the
> >most current/accurate information describing the technology that
> >was originally described in the *EXISTING* document.
> Ok. but it may be difficult to convince RFC authors about that.
We should empower RFC Editor & IESG to enforce this.
Think of all three (errata, Updates:, Obsoletes:) as retroactive
normative references being inserted into an existing RFC.
Navigational consistency is not just a marginal issue of style.
I don't think it would make sense if Google maps would output maps
with the direction north randomly chosen among top,right,bottom & left.
> >so for consistency,
> > IPv6 does not "Obsolete" (=completely replace) IPv4,
> These are two different technologies.
TLSv1.1 and TLSv1.2 may share more characteristics than IPv4 and IPv6,
but what they clearly have in common with IPv4 and IPv6 is, that TLSv1.1
and TLSv1.2 will reliably fail the handshake and therefore not interoperate
(they use a different PRF for calculating the finished messages,
besides changes in some PDUs).
> RFC 5321 obsoletes RFC 2821. RFC 2821 obsoletes RFC 821. These is
> a normative reference in RFC 5321 to RFC 821. There is an
> explanation from the editor of the RFC about why that approach was
The consolidation of documents such as 5321 is highly appreciated.
At the other far end you'll find a mess like the fragmented wilderness
of documents describing various parts of "DNS".
The primary specs for DNS seem to be 1034, 1035 and 2181.
A quick glance at 1034 and the "Updated by:" meta-data suggests:
Correct "Updates:" to 1034 are 1982,2308,4343,4592,5936
Incorrect "Updates:" to 1034 are 1101,1183,1348,1876,2065,2535,4033,4034,4035
> It difficult to have exact guidance. Here's something that was
> posted to some list:
> "the IETF only allows about 5 authors to be listed at the top
> of the draft"
> Half-truths tend to be turned into the absolute truth. The same
> argument applies for "Updates:". Even what I said above could be wrong.
I do not see the problem.
The authors on the front page of an I-D ought to list the _active_
editors for that document. The authors of the last I-D are carried
through to RFC, and those are the one who the RFC Editor will probably
talk to. Having more than 5 _active_ document editors seems
somewhat unreasonable to me.
There is no limit to the number of authors in the Authors section,
and should there be a need, you could add a few paragraphs to the
Acknowledgement section about the "exact amounts of authorships" that
you may want to explicitly attribute to specific authors.
More information about the rfc-interest