Hi -
On 2023-09-18 12:42 AM, Jürgen Schönwälder wrote:
This erratum should be rejected since the text does not appear in RFC
5343. It seems the text is found in 5340, 'OSPF for IPv6', and this is
a typo when the erratum was entered.
I concur. There may be a problem, but it's not in RFC 5343.
Randy
/js
On Sun, Sep 17, 2023 at 10:49:29PM -0700, RFC Errata System wrote:
The following errata report has been submitted for RFC5343,
"Simple Network Management Protocol (SNMP) Context EngineID Discovery".
--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7645
--------------------------------------
Type: Technical
Reported by: Owen DeLong <[email protected]>
Section: A.3.3
Original Text
-------------
Section A.3.3 (in part) reads:
Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent
out the associated interface without fragmentation. The MTUs of
common Internet link types can be found in Table 7-1 of [MTUDISC].
Interface MTU should be set to 0 in Database Description packets
sent over virtual links.
Corrected Text
--------------
Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent
out the associated interface without fragmentation. The MTUs of
common Internet link types can be found in Table 7-1 of [MTUDISC].
Interface MTU should be set to 0 in Database Description packets
sent over OSPF virtual links. This rule should not be applied to tunnel
or other software interfaces.
Notes
-----
OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed and this provision
makes sense. For interfaces that have an actual MTU, even though they may be "virtual"
interfaces, they are not "virtual links" in the intended meaning of this paragraph. As
such, this change will provide clarification and remove ambiguity from the current standard. At
least one popular router vendor implements this RFC as MTU = 0 sent on all GRE interfaces which
results in incompatibilities with most other router platforms which expect an actual value. The
router vendor points to this provision in the RFCs as justification for their implementation. It is
(arguably) a legitimate, if nonsensical interpretation of the existing text.
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC5343 (draft-ietf-opsawg-snmp-engineid-discovery-03)
--------------------------------------
Title : Simple Network Management Protocol (SNMP) Context
EngineID Discovery
Publication Date : September 2008
Author(s) : J. Schoenwaelder
Category : PROPOSED STANDARD
Source : Operations and Management Area Working Group
Area : Operations and Management
Stream : IETF
Verifying Party : IESG
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
