Changed authorlist to reflect that Hema no longer maintains the HOWTO.

Made some small cleanup changes, corrected some typos.

LDP/howto/docbook/Usenet-News-HOWTO/Usenet-News-HOWTO.sgml

@@ -23,11 +23,6 @@
             <author>
                 <firstname>Shuvam Misra</firstname>
                 <othername>
-                </othername>
-            </author>
-            <author>
-		<firstname>Hema Kariyappa</firstname>
-                <othername>
                 (usenet at starcomsoftware dot com)
                 </othername>
             </author>
@@ -58,6 +53,7 @@
             </revision>
         </revhistory>
     </articleinfo>
+#<toc></toc>
 &what;
 &pop;
 &software;

LDP/howto/docbook/Usenet-News-HOWTO/conclusion.sgml

@@ -20,7 +20,7 @@ systems would have remained very fragmented and superficial. Our insight
 into Unix came from our ``Village Elders'' in the Department of Computer
 Science of the IIT (Indian Institute of Technology) at Mumbai, specially
 from ``Hattu,'' ``Sathe,'' and ``Sapre,'' none of whom are with the IIT
-today, and from Professor D.B.Phatak and others, many of whom, luckily
+today, and from Professor D. B. Phatak and others, many of whom, luckily
 are still with the Institute.</para>
 
 <para>Coming to Starcom, all the members of Starcom Software who
@@ -28,6 +28,9 @@ have worked on various problems with networking, Linux, and Usenet news
 installations have helped the authors in understanding what works and
 what doesn't. Without their work, this HOWTO would have been a dry text
 book.</para>
+
+<para>Hema Kariyappa co-authored the first couple of versions of this
+HOWTO, starting with v2.0.</para>
 </section>
 
 <section><title>Comments invited</title>

LDP/howto/docbook/Usenet-News-HOWTO/perspective.sgml

@@ -27,40 +27,38 @@ opinion than detail, are discussed here.
 
 <listitem><para> 
     <emphasis>Ping-pong protocol</emphasis>: NNTP is unsuitable for
-    bulk streaming data transfer.
+    bulk streaming data transfer because the TCP sliding window feature
+    is unusable with NNTP.
 </para></listitem>
 </itemizedlist>
 
 <para>
-    A word of explanation on the ping-pong issue is perhaps
-    needed here. TCP uses a sliding window mechanism to pump out
-    data in one direction very rapidly, and can achieve near
-    wire speeds under most circumstances. However, this only
-    works if the application layer protocol can aggregate a
-    large amount of data and pump it out without having to stop
-    every so often, waiting for an ack or a response from the
-    other end's application layer. This is precisely why sending
-    one file of 100~Mbytes by FTP takes so much less clock time
-    than 10,000 files of 10~Kbytes each, all other parameters
-    remaining unchanged. The trick is to keep the sliding window
-    sliding smoothly over the outgoing data, blasting packets
-    out as fast as the wire will carry it, without ever
-    allowing the window to empty out while you wait for an ack.
-    Protocols which require short bursts of data from either end
-    constantly, <emphasis>e.g.</emphasis> in the case of remote
-    procedure calls, are called ``ping pong protocols'' because they
-    remind you of a table-tennis ball.  
+    What is a ping-pong protocol? TCP uses a sliding window mechanism to
+    pump out data in one direction very rapidly, and can achieve near
+    wire speeds under most circumstances. However, this only works if
+    the application layer protocol can aggregate a large amount of data
+    and pump it out without having to stop every so often, waiting for
+    an ack or a response from the other end's application layer. This is
+    precisely why sending one file of 100 Mbytes by FTP takes so much less
+    clock time than 10,000 files of 10 Kbytes each, all other parameters
+    remaining unchanged. The trick is to keep the sliding window sliding
+    smoothly over the outgoing data, blasting packets out as fast as the
+    wire will carry it, without ever allowing the window to empty out
+    while you wait for an ack.  Protocols which require short bursts of
+    data from either end constantly, <emphasis>e.g.</emphasis> in the
+    case of remote procedure calls, are called ``ping pong protocols''
+    because they remind you of a table-tennis ball.
 </para>
 
 <para>
     With NNTP, this is precisely the problem. The average size
     of Usenet news messages, including header and body, is
     3 Kbytes. When thousands of such articles are sent out by
-    NNTP, the sending server has to send the message~ID of the
+    NNTP, the sending server has to send the message ID of the
     first article, then wait for the receiving server to respond
-    with a ``yes'' or ``no.'' Once the sendiing server gets the
+    with a ``yes'' or ``no.'' Once the sending server gets the
     ``yes'', it sends out that article, and waits for an ``ok''
-    from the receiving server. Then it sends out the message~ID
+    from the receiving server. Then it sends out the message ID
     of the second article, and waits for another ``yes'' or
     ``no.'' And so on. The TCP sliding window never gets to do
     its job.  

LDP/howto/docbook/Usenet-News-HOWTO/security.sgml

@@ -34,7 +34,7 @@ business or occupation.</para>
 <section><title>Generic server vulnerabilities</title>
 
 <para>Foremost among these vulnerabilities are those which render
-<emphasis>any</emphasis>server vulnerable to intrusion attempts.
+<emphasis>any</emphasis> server vulnerable to intrusion attempts.
 Most of these vulnerabilities are unrelated to Usenet news itself. For
 instance, if you have the Telnet service active on a server exposed to
 the Internet, then it is likely that systematic attempts by intruders