--- a/doc/manual/attributes.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/attributes.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -297,7 +297,7 @@
 Note that initialization of the attribute relies on the macro
 NS_OBJECT_ENSURE_REGISTERED (DropTailQueue) being called; if you leave
 this out of your new class implementation, your attributes will not be 
-initialized corretly.
+initialized correctly.
 
 @subsection Basic usage
 
@@ -521,7 +521,7 @@
  uint32_t m_cWnd;   // Congestion window
 @end verbatim
 
-Suppose that someone working with Tcp wanted to get or set the 
+Suppose that someone working with TCP wanted to get or set the 
 value of that variable using the metadata system.  If it were not
 already provided by ns-3, the user could declare the following addition 
 in the runtime metadata system (to the TypeId declaration for TcpSocket):
@@ -597,7 +597,7 @@
 of writing 
 the conversions to/from strings and attribute values.  Most of this can be
 copy/pasted with macro-ized code.  For instance, consider class
-delcaration for Rectangle in the @code{src/mobility/} directory:
+declaration for Rectangle in the @code{src/mobility/} directory:
 
 @verbatim
 /**
@@ -663,7 +663,7 @@
 found in @code{src/contrib} and not in the main tree.  If you like this feature
 and would like to provide feedback on it, please email us.
 
-Values for ns-3 attributes can be stored in an ascii or XML text file and
+Values for ns-3 attributes can be stored in an ASCII or XML text file and
 loaded into a future simulation.  This feature is known as the
 ns-3 ConfigStore.  
 The ConfigStore code is in @code{src/contrib/}.  It is not yet main-tree

--- a/doc/manual/callbacks.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/callbacks.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -19,7 +19,7 @@
 Consider that you have two simulation models A and B, and you wish
 to have them pass information between them during the simulation.  One
 way that you can do that is that you can make A and B each explicitly
-knowledgable about the other, so that they can invoke methods on each
+knowledgeable about the other, so that they can invoke methods on each
 other. 
 
 @verbatim
@@ -141,7 +141,7 @@
 }
 @end verbatim
 
-Consider also the following main program snippett:
+Consider also the following main program snippet:
 @verbatim
 int main (int argc, char *argv[])
 {

--- a/doc/manual/csma.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/csma.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -139,7 +139,7 @@
 net devices on the channel identically.  You can think of a symmetrical hub
 in which the packet bits propagate to a central location and then back out
 equal length cables to the other devices on the channel.  The single ``speed
-of light'' delay then corresponds to the time it takes for: 1) a singal to 
+of light'' delay then corresponds to the time it takes for: 1) a signal to 
 propagate from one CsmaNetDevice through its cable to the hub; plus 2) the
 time it takes for the hub to forward the packet out a port; plus 3) the time
 it takes for the signal in question to propagate to the destination net 
@@ -168,7 +168,7 @@
 @item ReceiveEnable:  Enable packet reception if true;
 @item EncapsulationMode:  Type of link layer encapsulation to use;
 @item RxErrorModel:  The receive error model;
-@item TxQueue:  The trasmit queue used by the device;
+@item TxQueue:  The transmit queue used by the device;
 @item InterframeGap:  The optional time to wait between "frames";
 @item Rx:  A trace source for received packets;
 @item Drop:  A trace source for dropped packets.
@@ -181,7 +181,7 @@
 Packets sent over the CsmaNetDevice are always routed through the 
 transmit queue to provide a trace hook for packets sent out over the 
 network.  This transmit queue can be set (via attribute) to model different
-queueing strategies.
+queuing strategies.
 
 Also configurable by attribute is the encapsulation method used by the
 device.  Every packet gets an EthernetHeader that includes the 
@@ -219,7 +219,7 @@
 
 The CSMA net devices and channels are typically created and configured using
 the associated @code{CsmaHelper} object.  The various ns3 device dhelpers 
-generatlly work in a simlar way, and their use is seen in many of our example
+generally work in a similar way, and their use is seen in many of our example
 programs.
 
 The conceptual model of interest is that of a bare computer ``husk'' into which 
@@ -302,13 +302,13 @@
 the random exponential backoff handler if a timeout is detected.
 
 Case (3) implies that a packet is dequeued from the transmit queue if it is 
-unable to be transmittted according to the backoff rules.  It is important 
+unable to be transmitted according to the backoff rules.  It is important 
 to understand that this will appear as a Dequeued packet and it is easy to 
 incorrectly assume that the packet was transmitted since it passed through
 the transmit queue.  In fact, a packet is actually dropped by the net device
 in this case.  The reason for this behavior is due to the definition of the 
-Queue Drop event.  The m_traceDrop event is, by defintion, fired when a 
-packet cannot be enqueued on the transmit queue becasue it is full.  This 
+Queue Drop event.  The m_traceDrop event is, by definition, fired when a 
+packet cannot be enqueued on the transmit queue because it is full.  This 
 event only fires if the queue is full and we do not overload this event
 to indicate that the CsmaChannel is "full."
 

--- a/doc/manual/emu.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/emu.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -78,9 +78,9 @@
 @itemize @bullet
 @item Address:  The Mac48Address of the device;
 @item DeviceName: The name of the underlying real device (e.g., ``eth1'');
-@item Start:  The simualtion time at which to enable the underlying socket;
-@item Stop:  The simualtion time at which to stop receiving from the underlying socket;
-@item TxQueue:  The trasmit queue used by the device;
+@item Start:  The simulation time at which to enable the underlying socket;
+@item Stop:  The simulation time at which to stop receiving from the underlying socket;
+@item TxQueue:  The transmit queue used by the device;
 @item InterframeGap:  The optional time to wait between "frames";
 @item Rx:  A trace source for received packets;
 @end itemize
@@ -88,7 +88,7 @@
 Packets sent over the EmuNetDevice are always routed through the 
 transmit queue to provide a trace hook for packets sent out over the 
 network.  This transmit queue can be set (via attribute) to model different
-queueing strategies.
+queuing strategies.
 
 @node Using the EmuNetDevice
 @section Using the EmuNetDevice
@@ -102,8 +102,8 @@
 is no channel, the global router will be unable to do this.
 
 The Emu net devices are typically created and configured using the associated 
-@code{EmuHelper} object.  The various ns3 device helpers generatlly work in a
-simlar way, and their use is seen in many of our example programs.
+@code{EmuHelper} object.  The various ns3 device helpers generally work in a
+similar way, and their use is seen in many of our example programs.
 
 The conceptual model of interest is that of a bare computer ``husk'' into which 
 you plug net devices.  The bare computers are created using a @code{NodeContainer}
@@ -173,8 +173,8 @@
 transmit queue.  Dequeues from the transmit queue happen immediately after
 the Enqueue event and just prior to the packet being sent to the underlying
 socket.  This means that the transmit queue really only exists to fire on
-enqueue and dequeue operations so the Emu device bhaves like other ns-3
-devices in this repect.
+enqueue and dequeue operations so the Emu device behaves like other ns-3
+devices in this respect.
 
 @subsection Lower-Level (PHY) Hooks
 

--- a/doc/manual/emulation.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/emulation.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -35,7 +35,7 @@
 
 We expect the primary use for this configuration will be to generate repeatable
 experimental results in a real-world network environment that includes all of 
-the ns-3 tracing, loging, visualization and statistics gathering tools.
+the ns-3 tracing, logging, visualization and statistics gathering tools.
 
 In what can be viewed as essentially an inverse configuration, we allow ``real'' 
 machines running native applications and protocol stacks to integrate with
@@ -188,7 +188,7 @@
   ed->SetAddress ("00:00:00:00:00:02");
 @end verbatim
 
-And then the IP address of the client or serveris set in the usual way using
+And then the IP address of the client or server is set in the usual way using
 helpers.
 
 @verbatim

--- a/doc/manual/node.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/node.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -100,7 +100,7 @@
     MakeCallback (&Ipv4L3Protocol::Receive, ipv4), 
     Ipv4L3Protocol::PROT_NUMBER, 0);
 @end verbatim
-and likewise for Ipv6, Arp, etc.
+and likewise for Ipv6, ARP, etc.
 
 @section NodeList
 
@@ -115,7 +115,7 @@
 must be aggregated to it to provide useful node functionality.
 
 The ns-3 source code directory @code{src/internet-stack} provides
-implmentation of TCP/IPv4-related components.  These include IPv4,
+implementation of TCP/IPv4-related components.  These include IPv4,
 ARP, UDP, TCP, and other related protocols.
 
 Internet Nodes are not subclasses of class Node; they are simply Nodes 
@@ -289,7 +289,7 @@
 
 To summarize, internally, the UDP implementation is organized as follows:
 @itemize @bullet
-@item a @code{UdpImpl} class that implements the Udp socket factory
+@item a @code{UdpImpl} class that implements the UDP socket factory
 functionality
 @item a @code{UdpL4Protocol} class that implements the protocol logic
 that is socket-independent 

--- a/doc/manual/other.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/other.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -515,7 +515,7 @@
 create this network, so we will just quickly go over the main sections of the
 script.
 
-The first section creates a CSMA lan that will become the left side of the
+The first section creates a CSMA LAN that will become the left side of the
 dumbbell network.  This code should be very familiar since we used the same
 process to create our first example.
 
@@ -549,7 +549,7 @@
   CsmaIpv4Topology::AddIpv4Address (n3, nd3, "10.1.1.4", "255.255.255.0");
 @end verbatim
 
-The code to generate the CSMA lan on the right side is similar; only the names
+The code to generate the CSMA LAN on the right side is similar; only the names
 have been changed.
  
 @verbatim
@@ -582,9 +582,9 @@
   CsmaIpv4Topology::AddIpv4Address (n7, nd7, "10.1.2.4", "255.255.255.0");
 @end verbatim
 
-Next, we create a point to point link to connect the two lans.  We connect
-the point-to-point channel between nodes three (on the left lan) and four
-(on the right lan).  You should recoginze this as substantially similar to
+Next, we create a point to point link to connect the two LANs.  We connect
+the point-to-point channel between nodes three (on the left LAN) and four
+(on the right LAN).  You should recognize this as substantially similar to
 the link setup from the @code{point-to-point} example.
 
 @verbatim
@@ -599,7 +599,7 @@
 @end verbatim
 
 Then we configure data flows.  We create four echo clients that send UDP 
-packets from the left side lan to servers created on the right side lan.
+packets from the left side LAN to servers created on the right side LAN.
 Notice that we send 100 packets with an inter-packet gap of ten milliseconds
 instead of the single packet we have previously used.  This data rate is
 sufficient to saturate the point-to-point link and will cause packets to be
@@ -710,7 +710,7 @@
 to some people, we'll take some time here and outline a simple methodology 
 you can follow.
 
-@section Object Design 101 --- Class Ipv4BusNetwork
+@section Object Design 101 --- Class IPv4BusNetwork
 If you are a master of object oriented design, feel free to skip or skim this
 section, in which we derive a simplistic but fully operational bus network 
 class.
@@ -735,7 +735,7 @@
 Immediately we can notice that at the highest level we are talking about the
 noun @emph{network}.  This probably won't surprise you.  We also have an 
 adjective that modifies the noun --- @emph{bus}.  This should lead us to our 
-first class defintion.  Usually class names are constructed in the same way
+first class definition.  Usually class names are constructed in the same way
 as an English language sentence would be spoken.  For example, one would speak
 of a @emph{bus network} in conversation, so we would normally create a
 @code{class BusNetwork} to represent it.  
@@ -1005,7 +1005,7 @@
 
 @section Using Ipv4BusNetwork
 If all you ever want to do with a bus network can be captured in a topology
-with four nodes on the bus, the preceeding section may seem like a colossal
+with four nodes on the bus, the preceding section may seem like a colossal
 waste of time.  This is probably not the case, though.  Now that we have a
 relatively abstract bus class, we can create bus networks with 4, 40 or 4000
 nodes with no additional effort.
@@ -1044,7 +1044,7 @@
 
 This concludes the first part of the tutorial.  We have focused on
 using the @command{ns-3} system to construct various network topologies and to
-simulate sendng data across the networks; and we've shown you how to use the 
+simulate sending data across the networks; and we've shown you how to use the 
 trace facility to get access to simulation results.
 
 We now encourage you to play with the system a little.  Experiment with what
@@ -1058,7 +1058,7 @@
 examining the lower levels of the system in more detail.  We are going to
 explain how to change the behavior of the system and eventually how to write
 new models and applications.  This is a good time to make sure that you
-thorougly understand what we've gone over so far.
+thoroughly understand what we've gone over so far.
 
 @c ========================================================================
 @c Object Model
@@ -1365,7 +1365,7 @@
 Technically, the class named @code{Object} is simply a base class that you
 will inherit from if you want your @code{Objects} to support aggregation and
 discovery.  Many systems have a base class that implements common 
-functionality and these base classes are typically called somthing like 
+functionality and these base classes are typically called something like 
 Object.  The @command{ns-3} version of this base class relates primarily to
 @code{Object} aggregation and discovery, although it does also provide methods
 to help with intrusive reference counting and tracing as well.
@@ -1383,7 +1383,7 @@
 For those of you unfamiliar with Microsoft COM, CORBA or ORBit, this might 
 sound obvious.  For those of with such a background, the point we are making 
 is that there is no such thing in @command{ns-3} as a separate Interface
-declaration, no such thing as an Interface Definiition Language, no such thing
+declaration, no such thing as an Interface Definition Language, no such thing
 as a UUID or GUID, etc.  In @command{ns-3} we just work with C++ objects that
 may be given some very useful abilities by inheriting from the @command{ns-3}
 base class @code{Object}.  @command{Ns-3} @code{Objects} are not required to
@@ -1422,7 +1422,7 @@
 @code{Object}.  So, when the @code{Node} object is created it is really an 
 aggregation of one @code{Object} and you can call @code{AggregateObject} or
 @code{GetObject} on the resulting @code{Node} object.  Along with being an
-aggregation, the @code{Node} class also describes a public interface.  THis
+aggregation, the @code{Node} class also describes a public interface.  This
 public interface (API) is declared just as any C++ object is declared, via its
 class methods as specified in the inheritance tree.  For those steeped in 
 COM or CORBA, this is where the concept of Interface works in @command{ns-3}.
@@ -1435,7 +1435,7 @@
 The line with the circle at the top of the diagram represents the appearance 
 of the @code{Object} API to the external world.  This circle and line are 
 together called a lollipop because of its superficial similarity to a kind of
-childs candy.  
+child's candy.  
 
 @sp 1
 @center @image{oneobj,,,,png}
@@ -1514,7 +1514,7 @@
   a->AggregateObject (c);
 @end verbatim
 
-Thats all there is to it.  Now that you have those connectors snapped
+That's all there is to it.  Now that you have those connectors snapped
 together, you can ask each of the @code{Objects} in the aggregation for any of
 the other @code{Objects} in the aggregation.  Lets look at a simple example:
 
@@ -1527,11 +1527,11 @@
 @code{B} to help with memory management of the returned @code{Object} pointer.
 You should be very familiar with smart pointers at this stage of the tutorial.
 
-The right hand side illustrates how @code{GetObject} is acutally used.  
-The method @code{GetObject} is templated.  The assocated template parameter 
+The right hand side illustrates how @code{GetObject} is actually used.  
+The method @code{GetObject} is templated.  The associated template parameter 
 (between the brackets) specifies the @emph{class} that is being requested.
 This is important.  Since it is the class type that specifies the search
-criteron, there can be only one instance of a particular class present in an
+criterion, there can be only one instance of a particular class present in an
 aggregation.  Looking back a little, although the parameter to
 @code{AggregateObject} appears to be a vanilla C++ object (@code{b} or @code{c}
 above), it actually represents (is an instance of) a class that has an
@@ -1648,7 +1648,7 @@
 @cindex TypeId
 @cindex GetTypeId
 The final piece of this puzzle is the @code{TypeId}.  Recall that the
-declaration our eample object above included the following code
+declaration our example object above included the following code
 
 @verbatim
   static ns3::TypeId GetTypeId (void)
@@ -1724,7 +1724,7 @@
 @code{class A}, and is initialized by a call to the constructor for the class
 @code{TypeId}.  The constructor for @code{TypeId} takes a @code{std::string}
 that can be used to locate the type information for your class.  We usually
-privide the class name as the string.
+provide the class name as the string.
 
 Hopefully, this much of the declaration is now clear:
 
@@ -1787,7 +1787,7 @@
   AddConstructor<A> ();
 @end verbatim
 
-You can interpret this as explaining to the @command{ns-3} object ssytem that
+You can interpret this as explaining to the @command{ns-3} object system that
 you have a constructor named @code{A::A} which takes no parameters.  You are
 saying that this constructor should be used when @code{CreateObject} is called
 with no parameters.
@@ -2077,10 +2077,10 @@
 
 @emph{Remember:  Object types do not identify objects.}
 
-@subsection Dont use GetObject to Check Your Own Type.
+@subsection Don't use GetObject to Check Your Own Type.
 @cindex GetObject
 It is tempting to use @code{GetObject} as a form of runtime type
-information.  Dont do it.  You have no control over what @emph{other}
+information.  Don't do it.  You have no control over what @emph{other}
 object may be added to your aggregation.  Someone else may have
 appropriated (reimplemented) your type and aggregated themselves onto the
 aggregation.

--- a/doc/manual/output.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/output.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -72,7 +72,7 @@
 the @command{ns-3} low-level 
 tracing system that lets you get access to underlying trace events easily.  
 The output of a trace of a simulation run is an ASCII file --- thus the name.  
-In the spririt of keeping things simple, you won't be able to control or 
+In the spirit of keeping things simple, you won't be able to control or 
 configure the output at this stage.
 
 For those familiar with @command{ns-2} output, this type of trace is
@@ -121,10 +121,10 @@
 change into the top level directory and take a look at the file 
 @code{tutorial.tr} in your favorite editor.
 
-@subsubsection Parsing Ascii Traces
-@cindex parsing ascii traces
+@subsubsection Parsing ASCII Traces
+@cindex parsing ASCII traces
 
-This section parses in detail the structure of the ascii tracing
+This section parses in detail the structure of the ASCII tracing
 output.  If you find this output format self explanatory (it
 resembles tcpdump output), you may skip to the next
 section on pcap tracing.
@@ -191,7 +191,7 @@
 zero.  Therefore, @code{nodeid=0} means that the node in which the given trace
 event originated is the first node we created.  In the case of our script, 
 this first node is is the node pointed to by the smart pointer @code{n0}.  Not
-too surpsisingly, this is also the node to which we attached the
+too surprisingly, this is also the node to which we attached the
 @code{UdpEchoClient}.  The device number is local to each node, and so the
 device given by @code{device=0} is the first net device that we added to the
 node in question.  In our simulation, this corresponds to the 
@@ -269,10 +269,10 @@
 Looking at the packet payload (references 10-14) we see that this is an ARP
 reply to the request sent by node one.  Note that the simulation time
 (reference 01) is now 2.00207 seconds.  This is direct result of the data rate
-(5 mb/s) and latency (2 ms) parameters that we passed to the 
+(5 MB/s) and latency (2 ms) parameters that we passed to the 
 @code{CsmaChannel} when we created it.  Clearly the ARP request packet was 
 sent over the channel and received approximately 2 ms later by node one.  A
-corresponding ARP response packet was created and enqueued on node one's net
+corresponding ARP response packet was created and enqueued on node ones net
 device.  It is this enqueue trace event that has being logged.  
 
 @cindex queue
@@ -339,7 +339,7 @@
 on that node has turned the packet around.  Just as node zero needed to ARP
 for the MAC address of node one, now node one must ARP for the MAC address of
 node zero.  We see the ARP request enqueued on the transmit queue of node one;
-then we see the ARP request dequeued from the tranmit queue of node one (and
+then we see the ARP request dequeued from the transmit queue of node one (and
 implicitly transmitted to node zero).  Then we see an ARP response enqueued
 on the transmit queue of node zero; and finally the ARP response dequeued (and
 implicitly transmitted back to node one).
@@ -396,7 +396,7 @@
 The code used to enable pcap tracing is similar to that for ASCII tracing.  
 We have provided another file, @code{tutorial-csma-echo-pcap-trace.cc} that 
 uses the pcap trace wrapper.  We have added the code to include the pcap 
-trace wrapper defintions:
+trace wrapper definitions:
 
 @verbatim
   #include "ns3/pcap-trace.h"
@@ -447,7 +447,7 @@
 
 @subsubsection Reading output with Wireshark
 @cindex Wireshark
-If you are unfamilar with Wireshark, there is a web site available from which
+If you are unfamiliar with Wireshark, there is a web site available from which
 you can download programs and documentation:  @uref{http://www.wireshark.org/}.
 
 If you have Wireshark available, you can open each of the trace files and

--- a/doc/manual/packets.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/packets.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -59,7 +59,7 @@
 layer.
  
 Memory management of Packet objects is entirely automatic and extremely
-efficient: memory for the application-level payload can be modelized by
+efficient: memory for the application-level payload can be modeled by
 a virtual buffer of zero-filled bytes for which memory is never allocated
 unless explicitly requested by the user or unless the packet is fragmented
 or serialized out to a real network device.
@@ -458,7 +458,7 @@
 @verbatim
   Ptr<Packet> p;  // pointer to a pre-existing packet
   SocketIpTtlTag tag
-  tag.SetTtl (m_ipMulticastTtl); // Convey the TTL from Udp layer to IP layer
+  tag.SetTtl (m_ipMulticastTtl); // Convey the TTL from UDP layer to IP layer
   p->AddPacketTag (tag);
 @end verbatim
 
@@ -636,7 +636,7 @@
 On the other hand, copying a Packet and its tags is a matter of 
 copying the TagData head pointer and incrementing its reference count.
 
-Tags are found by the unique mapping betweent the Tag type and
+Tags are found by the unique mapping between the Tag type and
 its underlying id.  This is why at most one instance of any Tag
 can be stored in a packet.  The mapping between Tag type and 
 underlying id is performed by a registration as follows:

--- a/doc/manual/point-to-point.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/point-to-point.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -35,7 +35,7 @@
 @itemize @bullet
 @item Address:  The ns3::Mac48Address of the device (if desired);
 @item DataRate:  The data rate (ns3::DataRate) of the device;
-@item TxQueue:  The trasmit queue (ns3::Queue) used by the device;
+@item TxQueue:  The transmit queue (ns3::Queue) used by the device;
 @item InterframeGap:  The optional ns3::Time to wait between "frames";
 @item Rx:  A trace source for received packets;
 @item Drop:  A trace source for dropped packets.
@@ -78,7 +78,7 @@
 
 The PointToPoint net devices and channels are typically created and configured using
 the associated @code{PointToPointHelper} object.  The various ns3 device helpers 
-generally work in a simlar way, and their use is seen in many of our example
+generally work in a similar way, and their use is seen in many of our example
 programs and is also covered in the ns-3 tutorial.
 
 The conceptual model of interest is that of a bare computer ``husk'' into which 
@@ -93,7 +93,7 @@
 
 Once you have your nodes, you need to instantiate a @code{PointToPointHelper} and set
 any attributes you may want to change.  Note that since this is a point-to-point 
-(as compared to a point-to-mulipoint) there may only be two nodes with associated 
+(as compared to a point-to-multipoint) there may only be two nodes with associated 
 net devices connected by a PointToPointChannel.
 
 @verbatim

--- a/doc/manual/random.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/random.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -28,7 +28,7 @@
 @itemize @bullet
 @item @strong{by default, ns-3 simulations use a fixed seed}; if there is any 
 randomness in the simulation, each run of the program will yield identical
-results uniess the seed and/or run number is changed.  
+results unless the seed and/or run number is changed.  
 @itemize @bullet
 @item @strong{in ns-3.3 and earlier, ns-3 simulations used a random seed by 
 default; this marks a change in policy starting with ns-3.4}
@@ -81,7 +81,7 @@
 the first stream might use the first N/2 values and the second
 stream might produce the second N/2 values.  An important property
 here is that the two streams are uncorrelated.  Likewise, each
-stream can be partitioned disjointly to a number of 
+stream can be partitioned disjointedly to a number of 
 uncorrelated @emph{substreams}.  The underlying RNG hopefully
 produces a pseudo-random sequence of numbers with a very long
 cycle length, and partitions this into streams and substreams in an 

--- a/doc/manual/routing.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/routing.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -225,7 +225,7 @@
 by the simulation author) until a route is found.  
 
 We chose this approach because it may better
-faciliate the integration of disparate routing approaches that may 
+facilitate the integration of disparate routing approaches that may 
 be difficult to coordinate the writing to a single table, approaches
 where more information than destination IP address (e.g., source
 routing) is used to determine the next hop, and on-demand
@@ -300,7 +300,7 @@
 
 Typically there are two main types of multicast routes:  routes of the 
 first kind are used during forwarding.  All of the conditions must be
-exlicitly provided.  The second kind of routes are used to get packets off
+explicitly provided.  The second kind of routes are used to get packets off
 of a local node.  The difference is in the input interface.  Routes for
 forwarding will always have an explicit input interface specified.  Routes
 off of a node will always set the input interface to a wildcard specified

--- a/doc/manual/sockets.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/sockets.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -177,7 +177,7 @@
 Similarly, passing in a zero to the pointer argument in the raw buffer
 variants has the same effect.  Note that, if some subsequent code tries
 to read the Packet data buffer, the fake buffer will be converted to
-a real (zero'ed) buffer on the spot, and the efficiency will be lost there.
+a real (zeroed) buffer on the spot, and the efficiency will be lost there.
 
 @subsection Socket options
 

--- a/doc/manual/tcp.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/tcp.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -28,7 +28,7 @@
       ...
     }
 @end verbatim
-The parameter @code{m_tid} controls the TypeId of the actual Tcp Socket
+The parameter @code{m_tid} controls the TypeId of the actual TCP Socket
 implementation that is instantiated.  This way, the application can be
 written generically and different socket implementations can be swapped out
 by specifying the TypeId.
@@ -138,7 +138,7 @@
 
 @subsection Configuring and Downloading
 
-NSC is disbled by default and must be explicitly configured in.  To try
+NSC is disabled by default and must be explicitly configured in.  To try
 this, type
 @verbatim
 ./waf configure --enable-nsc
@@ -210,7 +210,7 @@
 The key line is the @code{SetNscStack}.  This tells the InternetStack
 helper to aggregate instances of NSC TCP instead of native ns-3 TCP
 to the remaining nodes.  It is important that this function be called
-@strong{before} callling the @code{Install()} function, as shown above.
+@strong{before} calling the @code{Install()} function, as shown above.
 
 Which stacks are available to use?  Presently, the focus has been on
 Linux 2.6.18 and Linux 2.6.26 stacks for ns-3.  To see which stacks

--- a/doc/manual/wifi.texi	Fri Sep 04 17:27:33 2009 +0200
+++ b/doc/manual/wifi.texi	Fri Sep 04 17:23:34 2009 -0700
@@ -128,11 +128,11 @@
 configuration of the WifiNetDevice powerful but complex.  For this reason,
 we provide some helper classes to perform common operations in a simple
 matter, and leverage the ns-3 attribute system to allow users to control
-the parameterization of the underlying models.
+the parametrization of the underlying models.
 
 Users who use the low-level ns-3 API and who wish to add a WifiNetDevice
 to their node must create an instance of a WifiNetDevice, plus 
-a number of consitutent objects, and bind them together appropriately
+a number of constituent objects, and bind them together appropriately
 (the WifiNetDevice is very modular in this regard, for future
 extensibility).  At the low-level API, this can be done
 with about 20 lines of code (see @code{ns3::WifiHelper::Install}, and