In D52979#1210419, @rrs wrote:

Testing is a good thing so I think this is well worth having. I will say on the rumor of name changes inside tcp_hpts due to the idea of possibly supporting
more than just TCP. I am unsupportive of this UNTIL we have tcp_hpts being able to handle multiple protocols. When I originally wrote hpts (called pacing not hpts.. Robert
renamed it hpts) I did envision expanding it to include not just TCP but SCTP and maybe even UDP. But the fundamental problem I hit was the fact that choosing where
to dice the thing such that you would have a common call point into the protocol was not a cut and dried thing. For TCP it was easy since there was a clear demark between
the initial input of the packet and the actual segment processing, which I used when I broke out the multiple stacks idea. However for SCTP and UDP no such clear
basis exists that is common with TCP..... or even between SCTP and UDP... so I back down and decided to implement it has a TCP thing. Now if someone comes up
with a clean and elegant way to call into to TCP/SCTP and UDP then name changes would be appropriate within the code.. without that elegant set of proposed
changes name changes I am STRONGLY against and will object to since they are just irrelevant until HTPS can support multiple protocols... so in summary

1. HPTS needs a clean way to do multiple protocols *first*
2. Name changes afterwards

Not the other way around :)

This change looks good to me, though I personally prefer to the more verbose comments before you shortened them. But I wouldn't block on that.

Hello! While I realize it might not be a priority here, I just wanted to leave a comment to let you know these recent changes to add files with : in the filename have broken git clone/pull on Windows (which doesn't allow these characters in the file names). I had the repo cloned on a Windows laptop so I could read the code, but now can no longer git pull the latest. It would be great if we could maintain that support. Thanks!

In D51721#1181966, @tuexen wrote:

Just to be clear: I am not concerned that some invalid value is passed in. The values used for rstreason are defined in icmp_var.h so I think changing them to an enum would not only affect the TCP code.

I feel like this is pretty fragile. This reset reason can pass through a few layers of code, and it's not clear before this point (at least for me, a newcomer to the code) that these are the only two valid reasons (nor why they are). Also, it's not trivial to quickly/trivially walk the code paths to be certain this assert holds.