diff --git a/src/docbook/en-US/module/architecture.xml b/src/docbook/en-US/module/architecture.xml
index dc12117f80..af8891691d 100644
--- a/src/docbook/en-US/module/architecture.xml
+++ b/src/docbook/en-US/module/architecture.xml
@@ -84,7 +84,7 @@
   <section>
     <title>Universal Asynchronous I/O API</title>
     <para>
-      Traditional I/O APIs in Java provided different types and methods for
+      Traditional I/O APIs in Java provide different types and methods for
       different transport types.  For example,
       <classname>java.net.Socket</classname> and
       <classname>java.net.DatagramSocket</classname> do not have any common
@@ -93,32 +93,33 @@
     </para>
     <para>
       This mismatch makes porting a network application from one transport to
-      the other tedious and difficult.  The lack of portability between
-      transports becomes a problem when you need to support more transports not
-      rewriting the network layer of the application.  Logically, many protocols
-      can run on more than one transport such as TCP/IP, UDP/IP, SCTP, and
-      serial port communication.
+      another tedious and difficult.  The lack of portability between
+      transports becomes a problem when you need to support additional
+      transports, as this often entails rewriting the network layer of the
+      application.  Logically, many protocols can run on more than one
+      transport such as TCP/IP, UDP/IP, SCTP, and serial port communication.
     </para>
     <para>
-      To make the matter worse, Java New I/O (NIO) API introduced the
-      incompatibility with the old blocking I/O (OIO) API, and so will NIO.2
-      (AIO).  Because all these APIs are different from each other in design
-      and performance characteristics, you are often forced to determine which
-      API your application will depend on before you even begin the
-      implementation phase.
+      To make matters worse, Java's New I/O (NIO) API introduced
+      incompatibilities with the old blocking I/O (OIO) API and will continue
+      to do so in the next release, NIO.2 (AIO).  Because all these APIs are
+      different from each other in design and performance characteristics, you
+      are often forced to determine which API your application will depend on
+      before you even begin the implementation phase.
     </para>
     <para>
       For instance, you might want to start with OIO because the number of
       clients you are going to serve will be very small and writing a socket
       server using OIO is much easier than using NIO.  However, you are going
-      to be in trouble when your business grows up exponentially and your server
-      starts to serve tens of thousand clients simultaneously.  You could
-      start with NIO, but it might take much longer time to implement due to
-      the complexity of the NIO Selector API, hindering rapid development.
+      to be in trouble when your business grows exponentially and your server
+      needs to serve tens of thousands of clients simultaneously.  You could
+      start with NIO, but doing so may hinder rapid development by greatly
+      increasing development time due to the complexity of the NIO Selector
+      API.
     </para>
     <para>
-      Netty has a universal asynchronous I/O interface called &Channel;, which
-      abstracts away all operations required to point-to-point communication.
+      Netty has a universal asynchronous I/O interface called a &Channel;, which
+      abstracts away all operations required for point-to-point communication.
       That is, once you wrote your application on one Netty transport, your
       application can run on other Netty transports.  Netty provides a number
       of essential transports via one universal API:
@@ -144,16 +145,15 @@
           </para>
         </listitem>
       </itemizedlist>
-      Switching from one transport to the other usually takes just a couple
+      Switching from one transport to another usually takes just a couple
       lines of changes such as choosing a different &ChannelFactory;
       implementation.
     </para>
     <para>
-      Also, you are even able to take advantage of a new transport which is
-      not written yet, serial port communication transport for instance, again
+      Also, you are even able to take advantage of new transports which aren't
+      yet written (such as serial port communication transport), again
       by replacing just a couple lines of constructor calls.  Moreover, you can
-      write your own transport by extending the core API because it is highly
-      extensible.
+      write your own transport by extending the core API.
     </para>
   </section>