From owner-svn-doc-all@freebsd.org Wed Jan 4 19:19:38 2017 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B52E3C9F7FD; Wed, 4 Jan 2017 19:19:38 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41BB91E7E; Wed, 4 Jan 2017 19:19:37 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.15.2/8.15.2) with ESMTP id v04JJSIk022944; Wed, 4 Jan 2017 22:19:28 +0300 (MSK) (envelope-from maxim.konovalov@gmail.com) Date: Wed, 4 Jan 2017 22:19:28 +0300 (MSK) From: Maxim Konovalov To: Warren Block cc: Warren Block , doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org, dru@freebsd.org Subject: Re: svn commit: r49600 - head/en_US.ISO8859-1/books/handbook/firewalls In-Reply-To: Message-ID: References: <201610281531.u9SFVL7u096914@repo.freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 19:19:38 -0000 [...] > > I'd remove the "setup" keyword from the command. Let me know if I can > > go ahead with this change. > > It's okay with me. Er, "Approved". It would be really nice if you could test > and verify it, but not required. > Done. Just a side note: the chapter still needs more work -- e.g. there is the time service rule in the ipf (not sure if it is ever functional on FreeBSD these days) sub-chapter. There is a quite dubious 310 rule in the ipfw example (dru@ cc'ed) that claims that denies "Deny public pings" but in fact denies all ICMP not just ICMP echo request/response or types 9/0. It means it could break the path mtu discovery mechanism that relies on ICMP type 3 code 4 messages. I must admit I haven't read the chapter carefully. Thanks, Maxim -- Maxim Konovalov