Hi all, Thanks for your replies, and apologies for my confusion!
Note that a new errata report has been submitted [1] and the erroneous report (EID 7645) has been deleted. Thank you, RFC Editor/sg [1] https://www.rfc-editor.org/errata/eid7649 > On Sep 19, 2023, at 7:41 AM, Joe Clarke (jclarke) <jcla...@cisco.com> wrote: > > 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 <sgin...@amsl.com> > Date: Tuesday, September 19, 2023 at 10:03 > To: Jürgen Schönwälder <jschoenwaelder@constructor.university> > Cc: Chris Smiley <csmi...@amsl.com>, j.schoenwael...@jacobs-university.de > <j.schoenwael...@jacobs-university.de>, Warren Kumari <war...@kumari.net>, > Rob Wilton (rwilton) <rwil...@cisco.com>, Henk Birkholz > <henk.birkh...@sit.fraunhofer.de>, Joe Clarke (jclarke) <jcla...@cisco.com>, > zhoutian...@huawei.com <zhoutian...@huawei.com>, o...@delong.com > <o...@delong.com>, opsawg@ietf.org <opsawg@ietf.org>, RFC Editor > <rfc-edi...@rfc-editor.org> > 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 > <jschoenwaelder@constructor.university> 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 <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 > > > > -- > 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
