<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Was the original reasoning to use StrongSwan over OpenSwan, only because of community support? I vaguely recall something mentioned about StrongSwan having additional capabilities or something. Can anyone confirm?<div><br></div><div>As far as which option, it sounds like B or C-2 are the better choices, just because of the RHEL support. The two are very similar (from an end-user standpoint), so the added doc/help shouldn't be too bad. From a code perspective, much of the code can be shared, so the added testing requirements should also be minimal.</div><div><br></div><div>The only point to make about C-2 is it requires us to either take the extra time now to support multiple drivers (we will have to eventually - I'll be working on one), or do a refactoring later to support a hierarchy of drivers. I brought that point up in the review of the reference driver, and Nachi and I talked about this a bit yesterday. We both agreed that we could do the refactoring later, to support drivers that are different than the Swan family.</div><div><br></div><div>Related to that, I did have some question about multiple drivers...</div><div><br></div><div>How do we handle the case where the drivers support different capabilities? For example, say one driver supports an encryption mode that the other does not.</div><div><br></div><div>Can we reject unsupported capabilities at configuration time? That seems cleaner, but I'm wondering how that would be done (I know we'll specify the provider, but wondering how we'll invoke driver specific verification routines - do we have that mechanism defined?).</div><div><br></div><div>Regards,</div><div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>PCM (Paul Michali)</div><div><br></div><div>MAIL <a href="mailto:pcm@cisco.com">pcm@cisco.com</a></div><div>IRC pcm_ (<a href="http://irc.freenode.net">irc.freenode.net</a>)</div><div>TW @pmichali</div></span>
</div>
<br><div><div>On Aug 19, 2013, at 6:15 PM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi folks<br><br>I would like to discuss whether supporting OpenSwan or StrongSwan or Both for<br>ipsec driver?<br><br>We choose StrongSwan because of the community is active and plenty of docs.<br>However It looks like RHEL is only supporting OpenSwan.<br><br>so we should choose<br><br>(A) Support StrongSwan<br>(B) Support OpenSwan<br>(C) Support both<br> (C-1) Make StrongSwan default<br> (C-2) Make OpenSwan default<br><br>Actually, I'm working on C-2.<br>The patch is still WIP <a href="https://review.openstack.org/#/c/42264/">https://review.openstack.org/#/c/42264/</a><br><br>Besides the patch is small, supporting two driver may burden<br>in H3 including docs or additional help.<br>IMO, this is also a valid comment.<br><br>Best<br>Nachi<br><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></body></html>