Yes, of course, so when you&#x27;re writing the strictly validating code, it has to be written with the assumption that although field must be zero <i>now</i>, that <i>change</i> in the future. And when it changes, the same code image will still be deployed in many places. Therefore, the validation cannot be hard coded; it has to be configurable so that the behavior can change to reflect the changed status of the field. This configurability has to be properly verified: does the equipment really stop validating and sending RST&#x27;s in the &quot;off&quot; configuration for that field.<p>RFC3360 says that sending RST is bad, and everyone please change that. It is written based on the fear that the rejecting behavior is hard-coded in some binary machine language images, so that if fixes aren&#x27;t deployed now to get rid of the behavior, then when it becomes necessary to start using the field, it will be impossible, due to the need to roll out a massive upgrade to all sorts of networking equipment all over the world.<p>The topic should be: &quot;RST-generating checks <i>that cannot be disabled</i> without upgrading the software image on the networking equipment are harmful&quot;.