Hi John, My view is that these erratum are introducing certain "details" which were missed and resulted in some implementers following procedures that are inefficient or incorrect based on the individual "bar" (I personally lean towards incorrect).
As such, this is perhaps an error of omission in the RFC. These clarifications are certainly required and will be helpful - so no concerns from my side with marking as "verified". Thanks, Ketan On Sat, Mar 16, 2024 at 11:19 AM John Scudder <[email protected]> wrote: > 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]> 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]> >> >> 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] >> 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
