Juergen is right. 5340 is the correct rfc and 5333 is a typo. Apologies. Can the errata be reassigned or should I resubmit? What is the best process here?
Owen > On Sep 18, 2023, at 00:42, Jürgen Schönwälder > <[email protected]> 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. > > /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
