diff --git a/documentation/design-documentation/chapters/chapter03.tex b/documentation/design-documentation/chapters/chapter03.tex
index 449bff1c9c2956f25180cbc300b57c55a8e0f2b3..0c3aa4471f6f41691a86110626e117fb598d7b24 100644
--- a/documentation/design-documentation/chapters/chapter03.tex
+++ b/documentation/design-documentation/chapters/chapter03.tex
@@ -15,15 +15,37 @@ Some loose thoughts for this chapter, as data networks consists out of:
 		\item physical links cannot be changed by a software, as some entity has to change the physical connection, i.e., either a human or by robots (see~\cite{de-cix:robots} as one possible example).
 		\item logical links can be changed by a software, but the ways of doing so depend on~\ref{ch:underpinnings:network:changes}. 
 	\end{enumerate}
+	\item a logical link is tight to a physical link or to an underlying logical link (a case of recursion)
+	\item basic properties of links: directionality (uni or bi)
+		\begin{enumerate}
+		\item directionality (uni or bi)
+		\item point-to-point
+		\item point-to-multipoint (multicast or broadcast)
+		\item multi-point-to-multipoint (multicast or broadcast) (XXX is this really true?)
+	\end{enumerate}
 \end{enumerate}
 
 \subsection{Can the network be changed during operation?}
 \label{ch:underpinnings:network:changes}
+
+Changes of device or service configurations -- this is intended for semi-static configurations:
 \begin{enumerate}
 	\item classical way: physical links can be changed by a software via the command line interface (CLI), e.g., a router can create a new IP~subnetwork on an interface via the CLI.
 	\item SDN way: physical links can be changed by a software via an Application Programming Interface (API), e.g., a router can create a new IP~subnetwork via an API
 \end{enumerate}
 
+Changes of forwarding behavior -- this is intended for dynamic configurations that require to keep state in the network:
+\begin{enumerate}
+	\item classical way: not possible, as human interaction is just too slow for any reaction.
+	\item network build-in: the control plane of a network device autonomously decides to change the flow forwarding behavior. Examples are: IP routing, firewwalls and Network Address Translators (NATs). 
+	\item SDN way: forwarding behavior of the network can be changed via an API
+\end{enumerate}
+
+
+\subsection{Network Management}
+\label{ch:underpinnings:network:management}
+
+ISO/IEC ISO/IEC 7498-4, FCAPS, ITIL, Assets, configuration, etc 
 
 \section{Requirements}
 \label{ch:underpinnings:requirements}
diff --git a/documentation/design-documentation/thesis.pdf b/documentation/design-documentation/thesis.pdf
index d72fa7802a4a40ecf410bb225c562ce9876c2da6..2c580b6c9b330255e5ead063d8c9de79580d9399 100644
Binary files a/documentation/design-documentation/thesis.pdf and b/documentation/design-documentation/thesis.pdf differ