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 <rfc-edi...@rfc-editor.org> > 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 <o...@delong.com> > > 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
