The erratum was supposed to be for RFC 5340, which came from the OSPF WG. This is why I suggested it might be easier to simply reject the erratum as reported and have the submitter open a new one on the correct RFC so everything is directed to the right places and people.
Joe From: Sandy Ginoza <[email protected]> Date: Tuesday, September 19, 2023 at 10:03 To: Jürgen Schönwälder <[email protected]> Cc: Chris Smiley <[email protected]>, [email protected] <[email protected]>, Warren Kumari <[email protected]>, Rob Wilton (rwilton) <[email protected]>, Henk Birkholz <[email protected]>, Joe Clarke (jclarke) <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, RFC Editor <[email protected]> Subject: Re: [Technical Errata Reported] RFC5343 (7645) Hi Jürgen, >From the datatracker: Was draft-ietf-opsawg-snmp-engineid-discovery (opsawg WG) This document is the product of the Operations and Management Area Working Group. Is OPSAWG incorrect, or are you suggesting that the right place to discuss this RFC now is OSPF? Thanks, RFC Editor/sg On Sep 18, 2023, at 11:30 PM, Jürgen Schönwälder <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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
