<div dir="ltr">Here's a 'newbie' view:<br><div class="gmail_extra"><br><div class="gmail_quote">On 2 October 2017 at 22:10, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Mon, 2 Oct 2017, D. Hugh Redelmeier wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
| We have talked about this in the past, but before I go ahead, I wanted<br>
| to ask if anyone objects to the test cases being converted to standalone<br>
| configuration files that no longer use or need ipsec.conf.common.<br>
<br>
| The disadvantage is that any changes that upto now could be made in an<br>
| also= conn that is included would effect all the conns that use it.<br>
<br>
This is a very late comment.  Sorry. [I deleted all my excuses.]<br>
<br>
It is also theoretical.  I don't often look at the details of the test<br>
configurations.<br>
<br>
I think that saying something once, in one place, is a lot better than<br>
smearing it over a lot of locations.  That means that any bug fix or<br>
change will be consistently applied.<br>
</blockquote>
<br></span>
[ remainder of arguming about good also= discipline ]<br>
<br>
I think you are missing the point. The idea is that by NOT using any<br>
also= statements, all test cases become defacto documentation/examples we<br>
can point to. Right now, the test cases cannot be used as documentation<br>
because endusers cannot follow the maze of also's to extract a meaningful<br>
configuration example.<br></blockquote><div><br></div><div>I still don't know the correct way to set up a basic configuration (technically I know the wrong way to set up a basic configuration - by driving whack directly).  What should require just a few lines gets lost in multiple levels of indirection, each adding stuff I suspect isn't needed.<br></div><div><br></div><div>For the timeout stuff I started out with also=slow-retransmits, but then found that a significant percentage of tests couldn't access it - road tests get minimal configurations - so I went through and inlined everything.  I don't think this is an issue as, by applying a little discipline (a.k.a. sed), they all looked like:</div><div>    retransmit-interval=2000 # slow retransmits</div><div>(I now see some of the values have been increased to 15000, fixing :-)<br></div><div><br></div><div>Andrew</div><div><br></div><div>PS: slow-retransmits is interesting for another reason, there's an impair mechanism that almost does the right thing - it fails because it (correctly) logs that it impaired the re-transmit<br></div></div></div></div>