[rfc-i] Reference to historic or obsoleted RFCs
Livio Zanol Puppim
livio.zanol.puppim at gmail.com
Mon Aug 6 10:15:22 PDT 2012
I understand what you're saying, but as long as the RFCs are becoming one
of the most important source for "standard" information, even a
informational RFC should be carefully revised. As you said, in the RFCs
world this is not such a difficult thing to do, as you have the right tool (
Even if you are creating a standard RFC that "beats the informational
ones", my understand is that the WG responsible for it's creation (or the
revision team) should take the care necessary to avoid this kind of
I'm not discussing this particularly case, errors can happen, it's a
natural human behavior. I'm arguing about the whole process of publishing
RFCs. I don't know if this kind of situation (not modifying referenced
RFCs) is normal or not, if the authors must search for referenced RFCs or
I'm suggesting, that, if this kind of situation is normal, maybe IETF or
IESG should include this kind of rev. as a pre-req to publication.
What you think?
2012/8/6 Brian E Carpenter <brian.e.carpenter at gmail.com>
> On 06/08/2012 17:14, Livio Zanol Puppim wrote:
> > Hello,
> > Reading the *RFC 5375* I've found references to some RFCs that are
> > considered Historic, or have been updated. In some cases, this can lead
> > a misunderstand of a section in a RFC.
> > For example:
> > The* RFC 5375* in section *B.2.2* states that we should avoid using /127
> > IPv6 prefix, but* RFC 6164* clearly says that we can use /127 prefix for
> > Inter-Router links. In fact, the *RFC 6547*, moves the *RFC
> > 3627*(referenced by the
> > * RFC 5375* in the above section) to Historic status.
> > If my point of view is indeed correct, I think that every time a new RFC
> > published that proposes an *Update* to another RFC, or *Obsoletes*
> > RFC or moves a RFC to *Historic *status, the team responsible for it's
> > creation needs to read every reference to that RFC
> Did you ever hear about the ComeFrom statement, proposed as an alternative
> to the GoTo at one point in the history of programming languages? A bit
> to implement, like finding "every reference to that RFC". If you mean evry
> RFC that references an RFC, that's indeed possible with
> You are correct, a conscientious author should always do that.
> > and request changes in
> > order to avoid this kind of misunderstanding. This is very important to
> > guys like me, that only reads the RFCs.
> It may not be a matter of requesting specific changes, but deciding what to
> do is certainly necessary.
> However, the reader of an RFC should always check the status of that RFC
> before implementing it. Thus, someone who follows the reference from 5375
> to 3627 would discover that it is now obsoleted.
> Also, 6164 is on the standards track, so it automatically beats the others,
> which are Informational.
> Unfortunately today there is no easy way to avoid this sort of problem
> except by careful study of the status of each RFC (for example in the
> RFC Index).
> > the section from RFC 5375
> > http://tools.ietf.org/html/rfc5375#appendix-B.2.2
> > "
> > B.2.2 <http://tools.ietf.org/html/rfc5375#appendix-B.2.2>. /127
> > The usage of the /127 addresses, the equivalent of IPv4's RFC 3021
> > <http://tools.ietf.org/html/rfc3021>
> > [RFC3021 <http://tools.ietf.org/html/rfc3021>], is not valid and
> > should be strongly discouraged as
> > documented in RFC 3627 <http://tools.ietf.org/html/rfc3627>
> > [RFC3627 <http://tools.ietf.org/html/rfc3627>].
> > "
> > ------------------------------------------------------------------------
> > _______________________________________________
> > rfc-interest mailing list
> > rfc-interest at rfc-editor.org
> > https://www.rfc-editor.org/mailman/listinfo/rfc-interest
Lívio Zanol Puppim
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rfc-interest