Spec: replace SSL refs with TLS

Thanks to Peter Balland for pointing this one out.

doc/of-spec/appendix.tex

@@ -142,7 +142,7 @@ The \verb|vendor| field is the Vendor ID, which takes the same form as in struct
 
 \subsubsection{Handshake}
 \label{cts:handshake} 
-Upon SSL session establishment, the controller sends an \verb|OFPT_FEATURES_REQUEST| message.  This message does not contain a body beyond the OpenFlow header.  The switch responds with an \verb|OFPT_FEATURES_REPLY| message:
+Upon TLS session establishment, the controller sends an \verb|OFPT_FEATURES_REQUEST| message.  This message does not contain a body beyond the OpenFlow header.  The switch responds with an \verb|OFPT_FEATURES_REPLY| message:
 
 \input{struct/ofp_switch_features}
 The \verb|datapath_id| field uniquely identifies a datapath.  The lower 48 bits are intended for the switch MAC address, while the top 16 bits are up to the implementer.  An example use of the top 16 bits would be a VLAN ID to distinguish multiple virtual switch instances on a single physical switch.  This field should be treated as an opaque bit string by controllers.

doc/of-spec/openflow-spec-v0.9.0.tex

@@ -318,7 +318,7 @@ The OpenFlow protocol supports three message types, \emph{controller-to-switch},
 \subsubsection{Controller-to-Switch}
 Controller/switch messages are initiated by the controller and may or may not require a response from the switch.
 \\\\
-\textbf{Features:}  Upon SSL session establishment, the controller sends a features request message to the switch.  The switch must reply with a features reply that specifies the capabilities supported by the switch.
+\textbf{Features:}  Upon Transport Layer Security (TLS) session establishment, the controller sends a features request message to the switch.  The switch must reply with a features reply that specifies the capabilities supported by the switch.
 \\\\
 \textbf{Configuration:} The controller is able to set and query configuration parameters in the switch.  The switch only responds to a query from the controller.
 \\\\
@@ -358,7 +358,7 @@ When an OpenFlow connection is first established, each side of the connection mu
 If the negotiated version is supported by the recipient, then the connection proceeds. Otherwise, the recipient must reply with an \verb|OFPT_ERROR| message with a \verb|type| field of \verb|OFPET_HELLO_FAILED|, a \verb|code| field of \verb| OFPHFC_COMPATIBLE|, and optionally an ASCII string explaining the situation in \verb|data|, and then terminate the connection.
 
 \subsection{Connection Interruption}
-In the case that a switch loses contact with the controller, as a result of a echo request timeout, SSL session timeout, or other disconnection, it should attempt to contact one or more backup controllers.  The ordering of the controller IP addresses is not specified by the protocol.
+In the case that a switch loses contact with the controller, as a result of a echo request timeout, TLS session timeout, or other disconnection, it should attempt to contact one or more backup controllers.  The ordering of the controller IP addresses is not specified by the protocol.
 \\\\
 If some number of attempts to contact a controller (zero or more) fail, the switch must enter ``emergency mode'' and immediately reset the current TCP connection.  In emergency mode, the matching process is dictated by the emergency flow table entries (those marked with the emergency bit when added to the switch).  All normal entries are deleted when entering emergency mode.
 \\\\
@@ -367,7 +367,7 @@ Upon connecting to a controller again, the emergency flow entries remain.  The c
 The first time a switch starts up, it is considered to be in emergency mode.  Configuration of the default set of flow entries is outside the scope of the OpenFlow protocol.
 
 \subsection{Encryption}
-The switch and controller communicate through an SSL connection.  The SSL connection is initiated by the switch on startup to the controllerÕs server, which is located by default on TCP port \input{define/OFP_TCP_PORT}.   The switch and controller mutually authenticate by exchanging certificates signed by a site-specific private key.  Each switch must be user-configurable with one certificate for authenticating the controller (controller certificate) and the other for authenticating to the controller (switch certificate).
+The switch and controller communicate through a TLS connection.  The TLS connection is initiated by the switch on startup to the controller's server, which is located by default on TCP port \input{define/OFP_TCP_PORT}.   The switch and controller mutually authenticate by exchanging certificates signed by a site-specific private key.  Each switch must be user-configurable with one certificate for authenticating the controller (controller certificate) and the other for authenticating to the controller (switch certificate).
 
 \subsection{Spanning Tree}
 \label{flow_table:stp_support}