Regarding whether it should be verified or HFDU, I haven’t taken a hard look yet. The operative question from the guidance [1] though, is if the change corrects “errors at the time the document was published”.
The guidance is necessarily not completely prescriptive and my impression is that these errata could be verified in that they do not change the operation of the protocol from what was intended (“Technical items that have a clear resolution in line with the original intent should be classified as Verified.”) I’d be interested in any further discussion, though, and won’t immediately verify the errata. —John [1] https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/ On Mar 16, 2024, at 3:19 PM, Ketan Talaulikar <[email protected]> wrote: [External Email. Be cautious of content] Hi Acee, I agree with this errata and thanks for raising it. Not sure if it can be "Verified" or "Held for Document Update" though. Thanks, Ketan On Fri, Mar 15, 2024 at 8:07 PM RFC Errata System <[email protected]<mailto:[email protected]>> wrote: The following errata report has been submitted for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7850<https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7850__;!!NEt6yMaO-gk!HwIp5PZkRjlTKoSPhbXzVwPGGfDGvAJPbFU3DQHxLs4GT4ib86TODbfFg2kc8wl0MbLAregdpczroM9_EA$> -------------------------------------- Type: Technical Reported by: Alfred Lindem <[email protected]<mailto:[email protected]>> Section: 10.7/A.3.5 Original Text ------------- Section 10.7 Each LSA specified in the Link State Request packet should be located in the router's database, and copied into Link State Update packets for transmission to the neighbor. These LSAs should NOT be placed on the Link state retransmission list for the neighbor. If an LSA cannot be found in the database, something has gone wrong with the Database Exchange process, and neighbor event BadLSReq should be generated. Section A.3.5 Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always sent directly to the neighbor. For more information on the reliable flooding of LSAs, consult Section 13. Corrected Text -------------- Section 10.7 Each LSA specified in the Link State Request packet should be located in the router's database, and copied into Link State Update packets for transmission directly to the neighbor, i.e., unicast on all interface types except point-to-point interfaces where all OSPF packets are sent to the address AllSPFRouters. These LSAs should NOT be placed on the Link state retransmission list for the neighbor. If an LSA cannot be found in the database, something has gone wrong with the Database Exchange process, and neighbor event BadLSReq should be generated. Section A.3.5 Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always sent directly to the neighbor. For more information on the reliable flooding of LSAs, consult Section 13. Link State Update packets are also sent directly to the neighbor in response to Link State Request packets as specified in Section 10.7. Notes ----- Clarify that OSPF Link State Updates sent in response to OSPF Link Requests should be unicast. Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : INTERNET STANDARD Source : Open Shortest Path First IGP Stream : IETF Verifying Party : IESG _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!HwIp5PZkRjlTKoSPhbXzVwPGGfDGvAJPbFU3DQHxLs4GT4ib86TODbfFg2kc8wl0MbLAregdpcw3s-wxEA$>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
