RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 1 record.

Status: Held for Document Update (1)

RFC 4277, "Experience with the BGP-4 Protocol", January 2006

Source of RFC: idr (rtg)

Errata ID: 146

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-03-21
Held for Document Update by: Stewart Bryant
Date Held: 2013-02-28

 

(1)  Relationship to RFC 1773

While studying RFC 4277, and re-reading its predecessor, RFC 1773,
it became more and more unclear to me why RFC 1773 has not simply
been declared being obsoleted by RFC 4277 - or perhaps being done
so by RFC 4277 plus RFC 4276.

Almost all material contained in RFC 1773 has been expanded upon
in RFC 4277; only a few historical noted have been dropped -
which arguably are of no more interest from the point of view
of current standardization and implementation efforts.

Hence, RFC 4277 apparently is a perfect replacement for RFC 1773,
and it would have added to clarity about the status of the memos
making this visible in the RFC index by means of a pair of
related  OBSOLETED BY  and  OBSOLETES  notes.


(2)  Inconsistencies with References

There are a few issues with References in RFC 4277:

(2a)

RFC 1965 had been obsoleted by RFC 3065, as noted in the text,
and consistently, the Ref. [RFC1965] has been placed into the
Informative References (Section 22.2), whereas [RFC3065] has
been recorded as a Normative Reference.  That's pretty o.k.

A similar relation exists between RFC 1966 and RFC 2796 (that
had obsoleted the former), and the text contains a similar,
parallel treatment of this RFC pair as the pair noted above.
Nevertheless, the Ref. [RFC1966] has been placed in Section
22.1, Normative References.
That seems to be inappropriate and inconsistent; [RFC1996]
should have been filed as an Informative Reference.

(2b)

The first sentence of Section 3, on page 3, contains a citation to
"[BGP-MIB]" that can be assumed from the context to mean RFC 4273,
but there's no such entry in Section 22 !

Consistently with (2a) above, the Ref. [RFC1657] from Section 22.1
should better have been placed into Section 22.2, and instead of it,
a new entry [BGP-MIB] pointing to RFC 4273 inserted into the
Normative References, Section 22.1.


The following text might be considered for inclusion in an RFC
Errata Note for RFC 4277 to resolve isuues (2a) and (2b):

-----
RFC 4271, in Section 22.1, "Normative References", on page 17,
contains entries labeled  '[RFC1966]'  and  '[RFC1657]' .
These entries should have been placed into Section 22.2,
"Informative References", instead.

Additionally, another entry should be added to Section 22.1 :

   [BGP-MIB]   Haas, J., Ed. and S. Hares, Ed., "Definitions of Managed
               Objects for BGP-4", RFC 4273, January 2006.
-----


(3)  further errata (typos)

(3a)

The example network topology diagram in Section 8, on mid-page 8,

                     /---- transit B ----\
         end-customer                     transit A----
                     /---- transit C ----\

should say:

                     /---- transit B ----\
         end-customer                     transit A----
                     \---- transit C ----/

Rationale: cf. RFC 1773 !

(3b)

Conforming to standard IPsec terminology, the first sentence
in Section 17.2 of RFC 4277 (on page 14),

                                    vvv
   BGP can run over IPsec, either in a tunnel or in transport mode,
   where the TCP portion of the IP packet is encrypted.  [...]

should better say:
                                           vvvvvv
|  BGP can run over IPsec, either in tunnel mode or in transport mode,
   where the TCP portion of the IP packet is encrypted.  [...]

or even, omitting that first 'mode' entirely,

|  BGP can run over IPsec, either in tunnel or in transport mode, where
   the TCP portion of the IP packet is encrypted.  [...]

(3c)

The last sentence in Section 21 of RFC 4277, on page 16,

   Finally, we'd like to think the IDR WG for general and specific input
   that contributed to this document.

should say:
                           v
|  Finally, we'd like to thank the IDR WG for general and specific input
   that contributed to this document.

Notes:

from pending

Report New Errata



Search RFCs
Advanced Search
×