Hi Acee, WG, I'm convinced this doesn't meet the criteria to be verified as a technical erratum. I am considering verifying it as "Hold for Document Update”, though. The definition for HFDU is "The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update.” [1]
Please let me know soon if you have any concerns about that disposition. --John [1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ > On Sep 17, 2023, at 6:25 PM, Acee Lindem <[email protected]> wrote: > > Given that the context of the “Interface MTU” is specifically the “interface > MTU” field in OSPFv3 Database Description packets and OSPF virtual links (RFC > 2328), the additions recommended in this Errata are unnecessary. The Errata > should be rejected. > > Thanks, > Acee >> On Sep 17, 2023, at 15:58, RFC Errata System <[email protected]> >> wrote: >> >> The following errata report has been submitted for RFC5838, >> "Support of Address Families in OSPFv3". >> >> -------------------------------------- >> You may review the report below and at: >> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7644__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmW7pFbpMU$ >> >> -------------------------------------- >> Type: Technical >> Reported by: Owen DeLong <[email protected]> >> >> Section: 2.7 >> >> Original Text >> ------------- >> Interface MTU >> The size in octets of the largest address family specific datagram >> that can be sent on the associated interface without >> fragmentation. The MTUs of common Internet link types can be >> found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set >> to 0 in Database Description packets sent over virtual links. >> >> >> Corrected Text >> -------------- >> Interface MTU >> The size in octets of the largest address family specific datagram >> that can be sent on the associated interface without >> fragmentation. The MTUs of common Internet link types can be >> found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set >> to 0 in Database Description packets sent over (OSPF3) virtual links. >> This recommendation MUST NOT be applied to tunnel and other virtual >> or software interfaces which carry traffic other than OSPF protocol >> packets. >> >> Notes >> ----- >> Currently, the language is ambiguous and at least one vendor has implemented >> OSPF3 sending an MTU of zero on GRE interfaces (and possibly others such as >> IPIP, IPSEC, etc., as I have not tested these). I believe that the intent of >> the RFC is to refer strictly to OSPF virtual-links which carry only OSPF >> protocol data and therefore have no meaningful MTU. When this is mistakenly >> applied to other forms of "virtual" interfaces such as tunnels, the results >> can be quite harmful. >> >> As such, I think that clarification is in order, since the vendor in >> question is unrepentant and claims their current implementation to be >> compliant with the RFC. >> >> 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. >> >> -------------------------------------- >> RFC5838 (draft-ietf-ospf-af-alt-10) >> -------------------------------------- >> Title : Support of Address Families in OSPFv3 >> Publication Date : April 2010 >> Author(s) : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. >> Aggarwal >> Category : PROPOSED STANDARD >> Source : Open Shortest Path First IGP >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmWKATRhUo$ _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
