You have to make sure that the right people and WG receive the erratum, RFC 5340 belongs to the OSPF WG.
/js On Mon, Sep 18, 2023 at 04:32:02PM -0700, Chris Smiley wrote: > > Greetings, > > This errata reports a problem with Section A.3.3/RFC 5343. It has been > corrected to Section A.3.3/RFC 5340 > > Please let us know any concerns. > > Thank you. > > RFC Editor/cs > > > > On Sep 17, 2023, at 10:49 PM, RFC Errata System <[email protected]> > > 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
