<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 5 Jul 2021 at 14:55, Paul Wouters <<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Jul 5, 2021, at 14:46, Andrew Cagney <<a href="mailto:andrew.cagney@gmail.com" target="_blank">andrew.cagney@gmail.com</a>> wrote:<br>
> <br>
> <br>
> Again, three possible outcomes requiring three clear status codes:<br>
> > - exchange succeeds; child succeeds STF_OK<br>
> > - exchange succeeds; child fails (ike survives) STF_FAIL<br>
> > - exchange fails, implying that the ike family dies STF_FATAL<br>
> we need a way to differentiate between them, and return accordingly.<br>
<br>
I agree for ikev2. Is it possible that we rename these to STFv2_XXX ?<br>
<br>
Because re-assigning meaning here might make sense but will really be confusing when looking at the IKEv1 code where this is not true.<br>
<br>
We are really changing the meaning here.<br>
<br></blockquote><div><br></div><div>So I looked at v3.23 IKEv1.</div><div><br></div><div>- to your point, the STF_FAIL path contains the comment:</div><div>             /* As it is, we act as if this message never happened:<br>                 * whatever retrying was in place, remains in place</div><div><br></div><div>- however to my point, it already contains code to send notifications and delete the (quick) state - not exactly following the guidelines</div><div><br></div><div>Helps explain why STF_DROP and STF_IGNORE were added.</div><div><br></div><div>For a name change I don't know what to call them.<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> <br></div></div></div>