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.
/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 -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
