Greg, In general, I think your clarifications are helpful. The one point I have minor disagreement is "SHOULD be populated/initialized" ... to what? One option is "an expected value". Personally, I'd find "an expected value. A suggested value is ..." and use the defaults below.
That said, I don't have a strong opinion that we must use some magic value. My desire is that we avoid unset values being a potential vector for disclosure of uninitialized memory. -- Jeff > On Apr 12, 2023, at 4:10 PM, Greg Mirsky <[email protected]> wrote: > > Hi Jeff, > thank you for your response. It seems to me that the values of these fields > are implementation specific and don't impact interoperability. If that is > correct, then I propose the following updates: > OLD TEXT: > Within the BFD Unaffiliated Echo packet, the "Desired Min TX > Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD > be populated with a value of 1 second (1,000,000 microseconds). > These values, however, are ignored and not used to calculate the > Detection Time. > NEW TEXT: > Within the BFD Unaffiliated Echo packet, the "Desired Min TX > Interval" and "Required Min RX Interval" defined in [RFC5880], SHOULD > be initialized before the transmission and MUST be ignored on receipt. > Furthermore, these values MUST NOT be used to calculate the > Detection Time. > > OLD TEXT: > The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set > to zero. > NEW TEXT: > The "Required Min Echo RX Interval" defined in [RFC5880] SHOULD be set > before the transmission and MUST be ignored upon receipt. > > Regards, > Greg > > > On Wed, Apr 12, 2023 at 8:00 AM Jeffrey Haas <[email protected] > <mailto:[email protected]>> wrote: > Greg, > > Flipping the question around somewhat: > > These portions of the PDU will be serialized onto the wire. > An implementation could choose values locally to help its own procedures. > Perhaps for heuristic tuning of the session. So, there's argument for "these > values are left to the implementation" - or as you note "this value is > ignored". > > What text would YOU want to see present in this draft? > > In the absence of an implementation having an opinion about the behavior for > its own purposes, I believe we want some boring "expected" value minimally as > implementation advice. IMO, that's one step nicer than whatever memory noise > is left from your allocated buffer that might disclose something unexpected > from your implementation internals. (See various virtualized host > environment bugs relating to memory ownership.) > > -- Jeff > > > > >> On Apr 12, 2023, at 10:22 AM, Greg Mirsky <[email protected] >> <mailto:[email protected]>> wrote: >> >> Dear, Authors and all, >> my apologies for the belated comments. I greatly appreciate your >> consideration of the notes below: >> Given that it is stated that the values of "Desired Min TX Interval" and >> "Required Min RX Interval" in an Unaffiliated BFD Echo message are ignored, >> what do you see as the value of using the normative language in: >> Within the BFD Unaffiliated Echo packet, the "Desired Min TX >> Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD >> be populated with a value of 1 second (1,000,000 microseconds). >> As I understand it, the "Required Min Echo RX Interval" value is not used in >> the Unaffiliated BFD Echo. If that is the case, what do you see as the value >> of requiring it to be zeroed: >> The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set >> to zero. >> Perhaps stating that the "Required Min Echo RX Interval" value is ignored in >> the Unaffiliated BFD Echo is sufficient. WDYT? >> >> Regards, >> Greg >> >> On Mon, Apr 10, 2023 at 8:27 AM Jeffrey Haas <[email protected] >> <mailto:[email protected]>> wrote: >> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo >> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo> >> >> Working Group, >> >> The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has >> completed. My judgment is that it has weak, but positive support to proceed >> to publication. This isn't atypical of BFD work at this point in the BFD >> Working Group's life. >> >> The next steps for the document: >> >> 1. Please continue to iterate through the issues raised during last call. I >> will be summarizing them in the original WGLC thread. I suspect we can >> reach conclusion for them shortly. >> >> 2. Each of the authors needs to make an attestation as to whether they're >> aware of any additional IPR applicable to this document. The rest of the >> Working Group, as per BCP 78/79[1] should also disclose of any applicable >> IPR if they're aware of it. >> >> One thing that makes this document particularly interesting is that this >> work is covered partially under work done in BBF in TR-146. This will be >> noted in the shepherd writeup. >> >> >> -- Jeff >> >> [1] https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1 >> <https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1> >> >> >
