cleaned up product names

site/encryption/crypto-overview.md

@@ -5,11 +5,11 @@ layout: default
 
 
 
-Weave can be configured to encrypt both the data passing over the TCP
+Weave Net can be configured to encrypt both the data passing over the TCP
 connections and the payloads of UDP packets sent between peers. This
 is accomplished using the [NaCl](http://nacl.cr.yp.to/) crypto
 libraries, employing Curve25519, XSalsa20 and Poly1305 to encrypt and
-authenticate messages. Weave protects against injection and replay
+authenticate messages. Weave Net protects against injection and replay
 attacks for traffic forwarded between peers.
 
 NaCl was selected because of its good reputation both in terms of
@@ -20,17 +20,17 @@ quite difficult to use NaCl incorrectly. Contrast this with libraries
 such as OpenSSL where the library and its APIs are vast in size,
 poorly documented, and easily used wrongly.
 
-There are some similarities between Weave's crypto and
-[TLS](https://tools.ietf.org/html/rfc4346). Weave does not need to cater
+There are some similarities between Weave Net's crypto and
+[TLS](https://tools.ietf.org/html/rfc4346). Weave Net does not need to cater
 for multiple cipher suites, certificate exchange and other
 requirements emanating from X509, and a number of other features. This
 simplifies the protocol and implementation considerably. On the other
-hand, Weave needs to support UDP transports, and while there are
+hand, Weave Net needs to support UDP transports, and while there are
 extensions to TLS such as [DTLS](https://tools.ietf.org/html/rfc4347)
 which can operate over UDP, these are not widely implemented and
 deployed.
 
 **See Also**
 
- * [How Weave Implements Encryption](/site/encryption/ephemeral-key.md)
+ * [How Weave Implements Encryption](/site/encryption/implementation.md)
  * [Securing Containers Across Untrusted Networks](/site/using-weave/security-untrusted-networks.md)

site/encryption/implementation.md

@@ -1,5 +1,5 @@
 ---
-title: How Weave Implements Encryption
+title: How Weave Net Implements Encryption
 layout: default
 ---
 
@@ -27,7 +27,7 @@ When a peer has received a public key from the remote peer, it uses
 this to form the ephemeral session key for this connection. The public
 key from the remote peer is combined with the private key for the
 local peer in the usual [Diffie-Hellman way](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange), 
-resulting in both peersarriving at the same shared key. To this is appended the supplied
+resulting in both peers arriving at the same shared key. To this is appended the supplied
 password, and the result is hashed through SHA256, to form the final
 ephemeral session key. 
 
@@ -53,7 +53,7 @@ between two peers.
 Generating fresh keys for every connection
 provides forward secrecy at the cost of placing a demand on the Linux
 CSPRNG (accessed by `GenerateKey` via `/dev/urandom`) proportional to
-the number of inbound connection attempts. Weave has accept throttling
+the number of inbound connection attempts. Weave Net has accept throttling
 to mitigate against denial of service attacks that seek to deplete the
 CSPRNG entropy pool, however even at the lower bound of ten requests
 per second, there may not be enough entropy gathered on a headless
@@ -71,7 +71,7 @@ entirely safe for use as key material.
 
 By way of comparison, this is exactly how OpenSSL works - it reads 256
 bits of entropy at startup, and uses that to seed an internal CSPRNG,
-which is used to generate keys. While Weave could have taken
+which is used to generate keys. While Weave Net could have taken
 the same approach and built a custom CSPRNG to work around the
 potential `/dev/random` blocking issue, the decision was made to rely
 on the [heavily scrutinised](http://eprint.iacr.org/2012/251.pdf) Linux random number
@@ -80,7 +80,7 @@ here](http://cr.yp.to/highspeed/coolnacl-20120725.pdf) (page 10,
 'Centralizing randomness'). 
 
 >>**Note:**The aforementioned notwithstanding, if
-Weave's demand on `/dev/urandom` is causing you problems with blocking
+Weave Net's demand on `/dev/urandom` is causing you problems with blocking
 `/dev/random` reads, please get in touch with us - we'd love to hear
 about your use case.
 

site/fastdp/fastdp-how-it-works.md

@@ -4,12 +4,12 @@ layout: default
 ---
 
 
-Weave implements an overlay network between Docker hosts. Without fast datapath enabled, each packet is encapsulated in a tunnel protocol header and sent to the destination host, where the header is removed.  The Weave router is a user space process, which means that the packet follows a winding path in and out of the Linux kernel:
+Weave Net implements an overlay network between Docker hosts. Without fast datapath enabled, each packet is encapsulated in a tunnel protocol header and sent to the destination host, where the header is removed.  The Weave router is a user space process, which means that the packet follows a winding path in and out of the Linux kernel:
 
 ![Weave Net Encapsulation](/images/weave-net-encap1-1024x459.png)
 
 
-The fast datapath in Weave uses the Linux kernel's [Open vSwitch datapath module](https://www.kernel.org/doc/Documentation/networking/openvswitch.txt). This module enables the Weave router to tell the kernel how to process packets:
+The fast datapath in Weave Net uses the Linux kernel's [Open vSwitch datapath module](https://www.kernel.org/doc/Documentation/networking/openvswitch.txt). This module enables the Weave Net router to tell the kernel how to process packets:
 
 ![Weave Net Encapsulation](/images/weave-net-fdp1-1024x454.png)
 
@@ -19,7 +19,7 @@ Because Weave Net issues instructions directly to the kernel, context switches a
 
 Prior to version 1.2, Weave Net used a custom encapsulation format. Fast data path uses VXLAN, and like Weave Net's custom encapsulation format, VXLAN is UDP-based, and therefore needs no special configuration with network infrastructure. 
 
->>Note:The required open vSwitch datapath (ODP) and VXLAN features are present in Linux kernel versions 3.12 and greater. If your kernel was built without the necessary modules Weave Net will fall back to the "user mode" packet path.
+>>**Note:** The required open vSwitch datapath (ODP) and VXLAN features are present in Linux kernel versions 3.12 and greater. If your kernel was built without the necessary modules Weave Net will fall back to the "user mode" packet path.
 
 
 **See Also**

site/fastdp/using-fastdp.md

@@ -20,19 +20,19 @@ $ WEAVE_NO_FASTDP=true weave launch
 
 ###Fast Datapath and Encryption
 
-Encryption does not work with fast datapath. If you enable encryption using the `--password` option to launch weave (or you use the `WEAVE_PASSWORD` environment variable), fast data path will by default be disabled. 
+Encryption does not work with fast datapath. If you enable encryption using the `--password` option to launch weave (or you use the `WEAVE_PASSWORD` environment variable), fast datapath will by default be disabled. 
 
-When encryption is not in use there may be other conditions in which the fastdp will revert back to `sleeve mode`. Once these conditions pass, weave will revert back to using fastdp. To view which mode Weave is using, run `weave status connections`.
+When encryption is not in use there may be other conditions in which the fast datapath reverts to `sleeve mode`. Once these conditions pass, Weave Net reverts back to using fastdp. To view which mode Weave Net is using, run `weave status connections`.
 
 ###Viewing Connection Mode Fastdp or Sleeve
 
-Weave automatically uses the fastest datapath for every connection unless it encounters a situation that prevents it from working. To ensure that Weave can use the fast data path:
+Weave Net automatically uses the fastest datapath for every connection unless it encounters a situation that prevents it from working. To ensure that Weave Net can use the fast datapath:
 
  * Avoid Network Address Translation (NAT) devices
  * Open UDP port 6784 (This is the port used by the Weave routers)
  * Ensure that `WEAVE_MTU` fits with the `MTU` of the intermediate network (see below)
 
-The use of fast datapath is an automated connection-by-connection decision made by Weave, and because of this, you may end up with a mixture of connection tunnel types. If fast data path cannot be used for a connection, Weave falls back to the "user space" packet path. 
+The use of fast datapath is an automated connection-by-connection decision made by Weave Net, and because of this, you may end up with a mixture of connection tunnel types. If fast datapath cannot be used for a connection, Weave Net falls back to the "user space" packet path. 
 
 Once a Weave network is set up, you can query the connections using the `weave status connections` command:
 
@@ -41,7 +41,7 @@ $ weave status connections
 <-192.168.122.25:43889  established fastdp a6:66:4f:a5:8a:11(ubuntu1204)
 ~~~
 
-Where fastdp indicates that fast data path is being used on a connection. If fastdp is not shown, the field displays `sleeve` indicating Weave Net's fall-back encapsulation method:
+Where fastdp indicates that fast datapath is being used on a connection. If fastdp is not shown, the field displays `sleeve` indicating Weave Net's fall-back encapsulation method:
 
 ~~~bash
 $ weave status connections

site/features.md

@@ -37,7 +37,7 @@ To application containers, the network established by Weave
 resembles a giant Ethernet switch, where all containers are 
 connected and can easily access services from one another. 
 
-Because Weave uses standard protocols, your favorite network 
+Because Weave Net uses standard protocols, your favorite network 
 tools and applications, developed over decades, can still 
 be used to configure, secure, monitor, and troubleshoot 
 a container network. 
@@ -50,7 +50,7 @@ and [Deploying Applications to Weave Net](/site/using-weave/deploying-applicatio
 
 ###<a name="fast-data-path"></a>Fast Datapath
 
-Weave automatically chooses the fastest available method to 
+Weave Net automatically chooses the fastest available method to 
 transport data between peers. The best performing of these 
 (the 'fast datapath') offers near-native throughput and latency.
 
@@ -63,7 +63,7 @@ See [Using Fast Datapath](/site/fastdp/using-fastdp.md) and
 
 ###<a name="docker"></a>Seamless Docker Integration (Weave Docker API Proxy)
 
-Weave includes a [Docker API Proxy](/site/weave-docker-api/set-up-proxy.md), which can be 
+Weave Net includes a [Docker API Proxy](/site/weave-docker-api/set-up-proxy.md), which can be 
 used to launch containers to the Weave network using the Docker [command-line interface](https://docs.docker.com/reference/commandline/cli/) or the [remote API](https://docs.docker.com/reference/api/docker_remote_api/). 
 
 To use the proxy run: 
@@ -82,7 +82,7 @@ See [Using the Weave Docker API](/site/weave-docker-api/using-proxy.md)
 
 ###<a name="plugin"></a>Weave Network Docker Plugin
 
-Weave can also be used as a [Docker plugin](https://docs.docker.com/engine/extend/plugins_network/).  A Docker network 
+Weave Net can also be used as a [Docker plugin](https://docs.docker.com/engine/extend/plugins_network/).  A Docker network 
 named `weave` is created by `weave launch`, which is used as follows:
 
     $ docker run --net=weave -ti ubuntu 
@@ -107,7 +107,7 @@ Containers are automatically allocated a unique IP address. To view the addresse
 Instead of allowing Weave to automatically allocate addresses, an IP address and a network can be explicitly 
 specified. See [How to Manually Specify IP Addresses and Subnets(/site/using-weave/manual-ip-address.md) for instructions. 
 
-For a discussion on how Weave uses IPAM, see [Automatic IP Address Management](/site/ipam/overview-init-ipam.md). And also review the 
+For a discussion on how Weave Net uses IPAM, see [Automatic IP Address Management](/site/ipam/overview-init-ipam.md). And also review the 
 [the basics of IP addressing](/site/ip-addresses/ip-addresses.md) for an explanation of addressing and private networks. 
 
 
@@ -128,7 +128,7 @@ See [Naming and discovery with Weavedns](/site/weavedns/how-works-weavedns.md).
 
 ###<a name="application-isolation"></a>Application Isolation
 
-A single weave network can host multiple, isolated 
+A single Weave network can host multiple, isolated 
 applications, with each application's containers being able 
 to communicate with each other but not with the containers 
 of other applications.
@@ -158,13 +158,13 @@ for details.
 ###<a name="security"></a>Security
 
 In keeping with our ease-of-use philosophy, the cryptography 
-in Weave is intended to satisfy a particular user requirement: 
+in Weave Net is intended to satisfy a particular user requirement: 
 strong, out-of-the-box security without a complex setup or 
 the need to wade your way through the configuration of cipher 
 suite negotiation, certificate generation or any of the 
 other things needed to properly secure an IPsec or TLS installation.
 
-Weave communicates via TCP and UDP on a well-known port, so 
+Weave Net communicates via TCP and UDP on a well-known port, so 
 you can adapt whatever is appropriate to your requirements - for 
 example an IPsec VPN for inter-DC traffic, or VPC/private network 
 inside a data-center. 
@@ -175,7 +175,7 @@ mechanism which you can use in conjunction with or as an
 alternative to any other security technologies you have 
 running alongside Weave. 
 
-Weave implements encryption and security using [Daniel J. Bernstein's NaCl library](http://nacl.cr.yp.to/index.html).
+Weave Net implements encryption and security using [Daniel J. Bernstein's NaCl library](http://nacl.cr.yp.to/index.html).
 
 For information on how to secure your Docker network connections,
 see [Securing Connections Across Untrusted Networks](/site/using-weave/security-untrusted-networks.md)
@@ -184,7 +184,7 @@ and for a more technical discussion on how Weave implements encryption see, [Usi
 
 ###<a name="host-network-integration"></a>Host Network Integration
 
-Weave application networks can be integrated with a host's 
+Weave Net application networks can be integrated with a host's 
 network, and establish connectivity between the host and 
 application containers anywhere.
 
@@ -213,7 +213,7 @@ See [Enabling Multi-Cloud networking and Muti-hop Routing](/site/using-weave/mul
 ###<a name="multi-hop-routing"></a>Multi-Hop Routing
 
 A network of containers across more than two hosts can be established 
-even when there is only partial connectivity between the hosts. Weave 
+even when there is only partial connectivity between the hosts. Weave Net
 routes traffic between containers as long as there is at least one *path* 
 of connected hosts between them.
 
@@ -239,17 +239,17 @@ See [Managing Services in Weave: Exporting, Importing, Binding and Routing](/sit
 
 ###<a name="fault-tolerance"></a>Fault Tolerance
 
-Weave peers continually exchange topology information, and 
+Weave Net peers continually exchange topology information, and 
 monitor and (re)establish network connections to other peers. 
 So if hosts or networks fail, Weave can "route around" the problem. 
 This includes network partitions, where containers on either side 
 of a partition can continue to communicate, with full connectivity 
 being restored when the partition heals.
 
-The Weave Router container is very lightweight, fast and and disposable. 
-For example, should Weave ever run into difficulty, one can 
+The Weave Net Router container is very lightweight, fast and and disposable. 
+For example, should Weave Net ever run into difficulty, one can 
 simply stop it (with `weave stop`) and restart it. Application 
 containers do *not* have to be restarted in that event, and 
-if the Weave container is restarted quickly enough, 
+if the Weave Net container is restarted quickly enough, 
 may not experience a temporary connectivity failure.
 

site/installing-weave.md

@@ -15,12 +15,12 @@ Install Weave Net by running the following:
 If you are on OSX and are using Docker Machine) you need to make sure
 that a VM is running and configured before getting Weave Net. Setting up a VM is shown in [the Docker Machine
 documentation](https://docs.docker.com/installation/mac/#from-your-shell).
-After the VM is configured with Docker Machine, Weave can be launched directly from the OSX host.
+After the VM is configured with Docker Machine, Weave Net can be launched directly from the OSX host.
 
-Weave respects the environment variable `DOCKER_HOST`, so that you can run
+Weave Net respects the environment variable `DOCKER_HOST`, so that you can run
 and control a Weave Network locally on a remote host. See [Using The Weave Docker API Proxy](/site/weave-docker-api/using-proxy.md)
 
-With Weave downloaded onto your VMs or hosts, you are ready to launch a Weave network and deploy apps onto it. See [Deploying Applications to Weave](/site/using-weave/deploying-applications.md#launching)
+With Weave Net downloaded onto your VMs or hosts, you are ready to launch a Weave network and deploy apps onto it. See [Deploying Applications to Weave](/site/using-weave/deploying-applications.md#launching)
 
 CoreOS users see [here](https://github.com/fintanr/weave-gs/blob/master/coreos-simple/user-data) for an example of installing Weave using cloud-config.