[rfc-i] Reference to historic or obsoleted RFCs
Livio Zanol Puppim
livio.zanol.puppim at gmail.com
Mon Aug 6 10:21:42 PDT 2012
Just to be a little more accurate,
RFC 6164 cities RFC 5375 in section 4, but does not propose any kind of
modification, or better, 6164 became a STANDARD, and RFCs 3627 and 5375
hasn't change. Isn't that the reason for RFC 6547?
Maybe is just an error, maybe not... As we can see, the RFC 6164 was
written correctly but no actions was taken for RFC 5375 (or 3627 before RFC
2012/8/6 Livio Zanol Puppim <livio.zanol.puppim at gmail.com>
> 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 is
>> > 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
>> 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
>> 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
Lívio Zanol Puppim
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rfc-interest