> On 11. May 2024, at 05:49, Meral Shirazipour via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Meral Shirazipour > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-tsvwg-sctp-zero-checksum-09 > Reviewer: Meral Shirazipour > Review Date: 2024-05-10 > IETF LC End Date: 2024-05-16 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > Major issues: > > Minor issues: > > Nits/editorial comments: > [Page 4], "use a heuristic to detect the existence of such middleboxes". > Would be great to add a few lines on the logic of such heuristic. Hi Meral, thanks for the review. Regarding your comment: A heuristic could consist of sending path heartbeats (path confirmation and normal) with a checksum of zero, turn using the zero checksum off after two consecutive timeouts, and add tests on implicitly confirmed paths. However, the decision to keep this out of this specification is based on: * For the use case the document focusses on (SCTP over DTLS) this is not needed. * This is not implemented by the stacks implemented by the stacks focussing on SCTP over DTLS. So we would not have any implementation experience. * I guess one can optimize the heuristic for a specific alternate error detection method. Therefore it should be defined in such a document. That also would allow to get some implementation experience. Knowing the above reasons, would you still recommend specifying such a heuristic? Best regards Michael > > -- > last-call mailing list -- last-call@xxxxxxxx > To unsubscribe send an email to last-call-leave@xxxxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
