From owner-freebsd-doc@FreeBSD.ORG Thu Nov 25 21:12:30 2004 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 253ED16A4CE for ; Thu, 25 Nov 2004 21:12:30 +0000 (GMT) Received: from mail.elvandar.org (redqueen.elvandar.org [217.148.169.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 234A643D62 for ; Thu, 25 Nov 2004 21:12:29 +0000 (GMT) (envelope-from remko@elvandar.org) Received: from localhost (localhost [127.0.0.1]) by mail.elvandar.org (Postfix) with ESMTP id DCB5029542D; Thu, 25 Nov 2004 17:20:49 +0100 (CET) Received: from mail.elvandar.org ([127.0.0.1]) by localhost (redqueen.elvandar.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95173-10; Thu, 25 Nov 2004 17:20:49 +0100 (CET) Message-ID: <41A60664.5000603@elvandar.org> Date: Thu, 25 Nov 2004 17:20:52 +0100 From: Remko Lodder User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tillman Hodgson References: <419E4747.6070001@FreeBSD.org> <419E510B.6020800@elvandar.org> <20041119203338.GF61766@seekingfire.com> <200411200335.56638.max@love2party.net> <20041120030001.GI61766@seekingfire.com> <20041122005112.GA73187@freebsdmall.com> <20041122144727.GY61766@seekingfire.com> In-Reply-To: <20041122144727.GY61766@seekingfire.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at elvandar.org cc: freebsd-doc@freebsd.org Subject: Re: Proposal regarding security chapter X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2004 21:12:30 -0000 Tillman Hodgson wrote: > On Sun, Nov 21, 2004 at 04:51:12PM -0800, Murray Stokely wrote: > >>On Fri, Nov 19, 2004 at 09:00:01PM -0600, Tillman Hodgson wrote: >> >>>V System Administration -> MAC -> Biba >>>V System Administration -> Firewalls -> PF >>>V System Administration -> Kerberos5 >> >>I think you mean 'Security' here. As in a new Security , rather >>than two named 'System Administration'. > > > Yes. > > >>>Basically putting all of the security topics on equal footing. This >>>highlights the importance of security, makes individual topics easier to >>>find (and less "deep" in level), >> >>Adding a new part and pushing the total chapter count to 30 is going >>to remove some of "easier to find" justification. > > > I find that a finely-grained ToC is generally more useful, *especially* > in a reference manual. > > >>This would also move content about SSH and MAC away from chapters >>about NIS, Unix accounts, other network services, etc. > > > I don't have a problem with that. > > MAC has its own chapter and there's a proposal to make Firewalls its own > chapter. I think that this trend will continue as more detailed > documentation is written about the various security topics. > > As a hypothetical end user looking for Security information, if I look > in III System Administration -> Security I'm no longer getting the whole > picture. It's become a "Where's Waldo?" adventure :-) > > >>I like the original suggestion best: moving the firewall (and OpenSSH >>sections) out of security and into the Network Services . >>Network Services is our newest part, and the System Admin part has >>twice as many chapters as the Network Services . We should just >>continue the work that began this summer of moving the network bits >>out of the general System Administration part and into the Network >>Services part. That's what it was created for. > > > iI agree with you as far as network services are concerned. However, I > think that Security is a different topic than network services (albeit > with some overlap). > > I guess my concern boils down to this: A hypothetical user who wants to > learn about security w.r.t FreeBSD *but doesn't yet know the right > buzzwords* doesn't have a place to look. They might be able to pick it > up by osmosis if they read two of the largest sections of the Handbook, > but I don't consider that a good solution. > > I admit to bit of bias in this area. In another of my aspects I'm a > security consultant so I tend to advocate making security information > as prominent and accessible as possible. > > >>I don't think adding another for Security issues is a logical >>division point with just two candidate chapters at this point. > > > Perhaps poor communication on my part, as I wasn't proposing to create a > new for only two chapters. > > Most of the sub-chapters within the existing Security chapter could > easily be promoted to full chapters. For example, I have a patch for > Kerberos5 being reviewed (hopefully ;-)) that will, as a by-product of > covering more sub-topics, expand the sub-chapter by a noticable amount. > My plan is to next write a second patch to cover the use of OpenSSH in a > Kerberos environment. At that point it'll be almost unwieldy as a > sub-chapter. > > I believe that it would be much better organized if it was a chapter > rather than a subchapter -- it's now organized into broad section that > would work well in that format, and when I see headings like > "14.8.1.2.1" it's starting to resemble SNMP OIDs ;-) > > >>Security topics are integral to both System Administration and Network >>Services, and we shouldn't remove security information from those >>parts to make a new one. > > > Or, from a security guys point of view, security topics transcends both > system administration and network services and we shouldn't be burying > the security information ;-) > > >>All of these proposals seem to have two things in common : >> >>1. The security chapter is too big. >>2. The firewalls information should go into a separate chapter. > > > I'd add: > > 3. Some of the security chapter sub-chapters are getting awfully large > for the format > 4. Making security information prominent and detailed is a worthwhile > goal for the Handbook > > >>Moving a chapter between parts is easy. So how about splitting out >>the firewall content into a new 'firewalls/chapter.sgml' file, and >>then temporarily adding this into the Network Services part. >> >>If it turns out that people do feel there is enough content for a >>whole new dedicated to security, then it will just be a one >>line diff to move the firewalls chapter from the network to a >>new security . > > > Sure, I have no problems with interim solutions. It's the same work > either way, and "results trump theory" :-) > > - Tillman > > I can live with the stuff above. I will consider on how to do it etc while i am in Spain for the next 12 days. After that i will start working on a seperated firewalls/chapter.sgml thingy and put it into Network Services. That is, unless someone objects to it and we need to rethink stuff etc. Cya in 12 days :) -- Kind regards, Remko Lodder |remko@elvandar.org Reporter DSINet |remko@dsinet.org Projectleader Mostly-Harmless |remko@mostly-harmless.nl Founder Tienervaders |remko@tienervaders.org