a little more adjustment, after discussing with henning;

1 files changed, 4 insertions, 4 deletions

diff --git a/share/man/man5/pf.conf.5 b/share/man/man5/pf.conf.5
index 81546df5323..13e23423daa 100644
--- a/share/man/man5/pf.conf.5
+++ b/share/man/man5/pf.conf.5
@@ -1,4 +1,4 @@
-.\"	$OpenBSD: pf.conf.5,v 1.573 2018/02/08 17:51:43 jmc Exp $
+.\"	$OpenBSD: pf.conf.5,v 1.574 2018/02/09 07:14:17 jmc Exp $
 .\"
 .\" Copyright (c) 2002, Daniel Hartmeier
 .\" Copyright (c) 2003 - 2013 Henning Brauer <henning@openbsd.org>
@@ -28,7 +28,7 @@
 .\" ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\" POSSIBILITY OF SUCH DAMAGE.
 .\"
-.Dd $Mdocdate: February 8 2018 $
+.Dd $Mdocdate: February 9 2018 $
 .Dt PF.CONF 5
 .Os
 .Sh NAME
@@ -1364,8 +1364,8 @@ Upon reception of the client's ACK in response to the syncookie
 SYNACK, pf will evaluate the ruleset and create state if the ruleset
 permits it, complete the three way handshake with the target host,
 and continue the connection with synproxy in place.
-This allows pf to be resilient against large synflood attacks which would
-otherwise run the state table against its limits.
+This allows pf to be resilient against large synflood attacks,
+which could otherwise exhaust the state table.
 Due to the blind answers to each and every SYN,
 syncookies share the caveats of synproxy:
 seemingly accepting connections that will be dropped later on.