In section 6.3.2.2, below table 102 on page 104, the text describes server and client proxies for dealing with redundancy.

This text is unclear for several reasons:

• context not clear: If the server vendor provides such a proxy what does that mean for the client vendor.
• In the first sentence of the first paragraph only a server proxy is mentioned, later on the client proxy and the "other method"
• the Fig. 26 has the different solutions in a different order then the text
  The figure implies that the server proxy does not run on the client box whereas the text implies that is runs on the client machine

Here is a proposal how to rephrase it:

A vendor can use the non-transparent redundancy features to create a proxy running on the client machine to provide transparent redundancy to the client. This reduces the amount of functionality that shall be designed into the Client and enables simpler Clients to take advantage of non-transparent redundancy.

By using the TransferSubscriptions Service, which allows a Client to request that a set of Subscriptions be moved from one Session to another, a vendor can effectively make transparent failover a part of a proxy stub that lives on the Client. There are two ways to do this.
The server proxy approach requires code in the Server and on the Client machine to support this and the client proxy approach is doing it all from the Client proxy process.

When the Client proxy is used, the proxy simply duplicates Subscriptions and modifications to
Subscriptions, by passing the calls on to both Servers, but only enabling publishing and/or sampling on one Server. When the proxy detects a failure, it enables publishing and/or sampling on the backup Server, just as the Client would if it were a redundancy-aware Client.

The other method also requires a Client stub, but in this case the stub is a much lighter-weight process. In this mode, it is the Server which mirrors all Subscriptions in the other Server, but the
Client endpoint for these Subscriptions is the active Server. When the stub detects that the active
Server has failed, it issues a TransferSubscriptions call to the backup Server, moving the
Subscriptions from the Session owned by the failed Server to its own Session, and activating publishing.

[Change the order in Fig. 26]