diff --git a/PBDSecPaper.tex b/PBDSecPaper.tex
index dd25803..654269c 100644
--- a/PBDSecPaper.tex
+++ b/PBDSecPaper.tex
@@ -79,9 +79,7 @@
 
 \begin{abstract}
 \begin{itemize}
-\item PBD centers around minimizing costs of developing and manufacturering new components along with changing the landscape of this ecosystem, through the use of a ``meet-in-the-middle'' methodology where successive refinements of specificiations meet with abstractions of pototential implemenetations; the goal being to obtain the same level of abstraction as is writtien into good coding functions.~\cite{Vincentelli2002}
-\item Security centers around being able to gauge the trustworthiness of components as well as the larger system made of distributed components.
-\item Lack of design/methodology for doing platform-based design of security elements, although conceptual use in mobile embedded systems. \textbf{[Add citation(s) here]}
+\item PBD centers around minimizing costs of developing and manufacturering new components along with changing the landscape of this ecosystem, through the use of a ``meet-in-the-middle'' methodology where successive refinements of specificiations meet with abstractions of pototential implemenetations; the goal being to obtain the same level of abstraction as is writtien into good coding functions.~\cite{Vincentelli2002} Security centers around being able to gauge the trustworthiness of components as well as the larger system made of distributed components.  There is a distinct lack of design methodology for doing platform-based design of security elements, although there is conceptual use in mobile embedded systems. \textbf{[Add citation(s) here]}
 \item Ground work for implementing security via PBD exists; this paper is centered around connecting the dots and laying the foundation for framework that will be built upon for creating security in a doucmented, rigorous, standardized way.
 \end{itemize}
 \end{abstract}
@@ -89,64 +87,34 @@
 \section{Motivation}
 \label{Motivation}
 \begin{itemize}
-\item As systems move towards more complex designs and implementations (as allowed by growths in technology; Moore's Law) the ability to make simplistic changes to these designs becomes exponentially more difficult.  For this reason, levels of abstraction are desired when simplifying the design/evaluation phases of systems development.
-	\begin{itemize}
-	\item Use of system-on-chip (SoC) to replace multi-chip solutions.
-		\begin{itemize}
-		\item Use of SoC to handle encryption/security in a secure and removed manner.
-		\end{itemize}
-	\end{itemize}
+\item As systems move towards more complex designs and implementations (as allowed by growths in technology; Moore's Law) the ability to make simplistic changes to these designs becomes exponentially more difficult.  For this reason, levels of abstraction are desired when simplifying the design/evaluation phases of systems development.  An example of this abstraction simplification is the use of system-on-chip (SoC) to replace multi-chip solutions.  This abstraction solution is then used for a variety of tasks, ranging from arithmatic to system behavior.  It is an industry standard to use SoC to handle encryption/security in a secure and removed manner.
 \item Middleware describes software that resides between an application and the inner workings of the system hosting the application.  The purpose of the middleware is to abstract the complexities of the underlying technology from the application layer~\cite{Lang2003}; to act as translation software for communicating from lower level to a higher level.  This is the same sort of ``abstraction bridge'' that is required by the ``meet-in-the-middle'' methodology of PBD, along with the sort of software construct that benefits the virtualization of security component mapping.
 \item ``However, even though current silicon technology is closely following the growing demands; the effort needed in modeling, simulating, and validating such designs is adversely affected.  This is because current modeling tools and frameworks, hardware and software co-design environments, and validation and verification frameworks do not scale with the rising demands.''`\cite{Patel2007}
 \item \textbf{\textit{Add something about previous security work; taxonomy?}}
 \end{itemize}
 
 \begin{itemize}
-\item What standardization is important, why is it important?
+\item Standardization is the process of developing and implementing technical standards.  Standardization can help to maximinze compatability, interoperability, safety, repeatability, or quality; it can also faciliate commoditization of formerly custom processes.  Standards appear in all sorts of domains.
 	\begin{itemize}
-	\item IC Domain standardization: flexibile integrated circuit where customization for a particular application is achieved by programming one or more components on the chip.
-	\item PC Domain standardization: PC makers and application software designers develop their products quickly and efficiently around a stanrad `platform' that emerged over time.
-		\begin{itemize}
-		\item x86 ISA - possible to reuse the OS \& SW application
-		\item Fully spcified set of buses (ISA, USB, PCI) - use same xplansion boards of IC's for different products
-		\item Full specification of a set of IO devices - keyboard, mouse, audio and video devices
-		\item Software can also be developed independently of the new hardware availability, thus offering a real hardware-software codesign approach
-			\begin{itemize}
-			\item \textbf{Note:} ``If the instruction set architecture (ISA) is kept constant, then software porting is much easier.''~\cite{Vincentelli2002}
-			\end{itemize}
-		\end{itemize}
-	\item System Domain: Aspect of the capabilities a platform offeres to develop quickly new applications
-		\begin{itemize}
-		\item A distillation of the principles is needed so that a rigorous methodology can developed and profitably used across different design domains
-		\end{itemize}
+	\item For the IC domain standardization manifests as a flexibile integrated circuit where customization for a particular application is achieved by programming one or more components on the chip.  PC makers and application software designers develop their products quickly and efficiently around a standard `platform' that emerged over time.  As a quick over view of these standards: x86 ISA which makes is possible to reuse the OS \& SW applications, a full specified set of buses (ISA, USB, PCI) which allow for use of the same expansion boards of IC's for different products, and a full specification of a set of IO devices (e.g. keyboard, moust, audio and video devices).  The advantage of the standardization of the PC domain is that software can also be developed independently of the new hardware availability, thus offering a real hardware-software codesign approach.  If instruction set architecture (IAS) is kept constant (e.g. standardized) then software porting, along with future development, is far easier~\cite{Vincentelli2002}.  In a `System Domain' lens, standardization is the aspect of the capabilities a platform offeres to develop quickly new applications (adoptability).  In other words, this requires a distillation of the principles so that a rigorous methodology can developed and profitably used across different design domains.
 	\item So why is standardization useful?  Standardization allows for manufacturers, system developers, and software designers to all work around a single, accepted, platform.  It is understood what the capabilities of the hardware are, what the limitations of system IO will be, along with what the methods/protocols of communication will be.  Even these preset aspects of the `standard' have their own `contractual obligations' of how they will function, what their respective `net-lists' are, and where the limtations of such standards lie.  While the act of creating a standard takes time, not only due to time of development but due to speed of adoption of wide use, it is a necessary step.  Without it, it becomes far more difficult to create universally used complex systems, let alone validate their correctness and trustworthiness.
 	\item ``Indeed, market data indicate that more than 80\% of system development efforts are now in software versus hardware.  This implies that an effective platform has to offer a powerful design environment for software to cope with development cost.''~\cite{Vincentelli2002}
 	\end{itemize}
 \item Where do we gain/lose on shifting the method of design.  Development of these tools implies that there is a need to change the focus and methods of design/development\textbf{[Add Quo Vadis paper citation here]}.
 	\begin{itemize}
-	\item Gain is ease of changes in development and searching of design space
-		\begin{itemize}
-		\item For PBD this means that a company/manufacturer is able to lower the cost and time spent in the `early development phase'; the time spent when first drawing up system designs prior to initial prototyping.  While the advantage of overcoming multiple prototpying re-designs with a series of virtualization tools will cut down on development time, it can not be forgotten that the rigorous standards and documentation need to be developed for this sort of advantage.   It is here that the most effort must be focused at first, but once this hurdle is passed then the advantages of such a system can be reaped
-		\item For security this mean that components can be standardized from a local, network, and distributed standpoint.  These different scopes of security will be tackled in Section~\ref{Security}.  The main point here is that with standardization comes a form of `contract' that all parties can expect will be followed, thus allowing for a different manufacturers/developers to create different aspect while knowing that these different elements will come together in the final product.
-		\end{itemize}
-	\item Loss is time in developing the standards, rigors, and documentation that would be used as new standards for the industry.  
+	\item The advatange to this method is ease of changes in development and searching of design spaces during early design and development of those systems.  For PBD this means that a company/manufacturer is able to lower the cost and time spent in the `early development phase'; the time spent when first drawing up system designs prior to initial prototyping.  While the advantage of overcoming multiple prototpying re-designs with a series of virtualization tools will cut down on development time, it can not be forgotten that the rigorous standards and documentation need to be developed for this sort of advantage.   Once this hurdle is passed then the advantages of such a system can be reaped.  For security this means that components can be standardized from a local, network, and distributed standpoint.  These different scopes of security will be tackled in Section~\ref{Security}.  The main point here is that with standardization comes a form of `contract' that all parties can expect will be followed, thus allowing for a different manufacturers/developers to create different aspect while knowing that these different elements will come together in the final product; much like the advantages of platform-based design.
+	\item The disadvantage of using a new method is the loss in time for developing the standards, rigors, and documentation that would be used as new standards for the industry.  
 		\begin{itemize}
 		\item Ideally all manufacturers would adopt a new commodity; rather than components, `design combinations' would be the new commodity that manufacturers would peddle (e.g. instead of saying ``my components are the best'' the dialog moves towards ``My ability to combine these components is the best'')
 		\end{itemize}
-	\item Virtualization will help offset the costs in the long game
+	\item Virtualization will help offset the time and monetary costs in the long run.
 		\begin{itemize}
-		\item Essentially, how to abstract the lower level requirements of a system (assembly/C) into a simpler high level set of tools (API/block)
-			\begin{itemize}
-			\item A new set of tools that can be used to build bigger and greater things out of a series of smaller more manage/customizable blocks
-			\item Flexbilitiy of low level elements will help minimize conflict when attempting to design higher level blocks
-			\item Need for `tunable desings' that can be centered around specific aspects (e.g. power/energy efficient systems to minimize ``power cost buildup'', or security/trust centric needs).
-			\item Functions should be kept simple (e.g. decide output, \textbf{but} not how output manifest).  This lends to both the ideas of abstraction (choosing the simple output) and standardization/documentation (know what the outputs are, but not needing to know exactly how they manifest; just that they will)
-			\end{itemize}
+		\item Essentially the issue boils down to how to abstract the lower level requirements of a system (assembly/C) into a simpler high level set of tools (API/block).  A new set of tools needs to be developed that can be used to build bigger and greater things out of a series of smaller more manage/customizable blocks.  Flexbilitiy of low level elements will help minimize conflict when attempting to design higher level blocks.  As with any new system, there is a need for `tunable desings' that can be centered around specific aspects (e.g. power/energy efficient systems to minimize ``power cost buildup'', or security/trust centric needs).  Functions, in this tool set, should be kept simple (e.g. decide output, \textbf{but} not how the output manifests).  This tool lends to both the ideas of abstraction (choosing the simple output) and standardization/documentation (know what the outputs are, but not needing to know exactly how they manifest; just that they will).
 		\end{itemize}
 	\end{itemize}
 \item Hardware/Software Codesign
 	\begin{itemize}
-	\item There are different coding languages toi handle different aspects (i.e. SW/HW)
+	\item There are different coding languages to handle different aspects (i.e. SW/HW)
 		\begin{itemize}
 		\item Software: bad at timing and concurrency semantics
 		\item Hardware: Hardware semantics are very specific (and tough to simulate; thus existence of languages like SystemC)
@@ -190,7 +158,7 @@ \section{Platford-based design}
 		\item The types of decisions that are made at these higher levels lend to the design traits that are requirements at lower levels.  For example, a lower level consideration may be heat dissipation concerns which manifests itself as size constraints at higher levels.  This sort of complexities in cost of design are exactly why abstraction/virtualization are required/desired.  Additional levels of abstraction (along with virtualization tools for design space exploration) aid in simplifying the design process.
 		\item ``Critical decisions are about the architecture of the system, e.g., processors, buses, hardware accelerators, and memories, that will carry on the computation and communication tasks associated with the overall specification of the design.''~\cite{Vincentelli2007}
 		\end{itemize}
-	\item There are elements of recursive behavior that need to be tackled from a virtualized tool standpoint.  In a PBD refinement-based design process, platforms shoould be defined to eliminate large loop iterations for affordable designs~\cite{Vincentelli2007}.  This refinement should restrict the design space via new forms of regularity and structure that surrender some design potential for lower cost and first-pass sucess.  The library of functional and communication components is the design space that we are allowed to explore at the appropriate level of abstraction~\cite{Vincentelli2007}.
+	\item The library of functional and communication components is the design space that we are allowed to explore at the appropriate level of abstraction~\cite{Vincentelli2007}.  There are elements of recursive behavior that need to be tackled from a virtualized tool standpoint.  In a PBD refinement-based design process, platforms shoould be defined to eliminate large loop iterations for affordable designs~\cite{Vincentelli2007}.  This refinement should restrict the design space via new forms of regularity and structure that surrender some design potential for lower cost and first-pass sucess.
 	\item Due to the recursive nature of platform-based design, establishing the number, location, and components of intermediate ``platforms'' is the essence of PBD~\cite{Vincentelli2007}.  ``In fact, designs with different requirements and specification may use different intermediate platforms, hence different layers of regularity and design-space constraints.  The tradeoffs involved in the selection of the number and characteristics of platforms relate to the size of the design space to be explored and the accuracy of the estimation of the chracteristics of the solution adopted.  Naturally, the larger the step across platforms, the more difficult is predicting performance, optimizing at the higher levels of abstraction, and providing a tight lower bound.  In fact, the design space for this approach may actually be smaller than the one obtained with smaller steps because it becomes harder to explore meaningful design alternatives and the restriction on search impedes complete design-space exploration.  Ultimately, predictions/abstractions may be so inaccurate that design optimizations are misguided and the lower bounds are incorrect.''~\cite{Vincentelli2007}
 	\item ``The identification of precisely defined layers where the mapping processes take place is an important design decision and should be agreed upon at the top design management level.''~\cite{Vincentelli2007}
 		\begin{itemize}
@@ -203,8 +171,8 @@ \section{Platford-based design}
 \section{Security}
 \label{Security}
 \begin{itemize}
-\item Evolving with time and understanding as knowledge of encryption and other security encapsulation techniques.  There are considerations that are accounted from a software standpoint: capabilities of the software, speed of the algorthims/actions that take place, and how unique (level of uniqueness) a given solution is.  Similarly there are hardware considerations as well: tolerance of the chip elements in use, their capabilities, power distribution over the entire hardware design, signal lag between different elements, and cross-talk caused by communication channels.
-\item Trusted Computing Group (TCG) created Trusted Platform Modules (TPM) which are able to validate their own functionality and if they have been tampered with.  This is, in essence, a method of `self-analysis'; thus the ground work for a `self-analyzing' security component is already in place.  This self checking can be used as a method for allowing the larger system of security components to locate damaged/error-prone componenets so that they can be replaced/fixed thus raising the overall trustworthiness of the system of components.
+\item Evolving with time and understanding as knowledge of encryption and other security encapsulation techniques.  There are considerations that are accounted from a software standpoint: capabilities of the software, speed of the algorthims/actions that take place, and how unique (level of uniqueness) a given solution is.  Similarly there are hardware considerations as well: tolerance of the chip elements in use, their capabilities, power distribution over the entire hardware design, signal lag between different elements, and cross-talk caused by communication channels.  Different groups have tackled aspects of these considerations.
+\item The Trusted Computing Group (TCG) created Trusted Platform Modules (TPM) which are able to validate their own functionality and if they have been tampered with.  This is, in essence, a method of `self-analysis'; thus the ground work for a `self-analyzing' security component is already in place.  This self checking can be used as a method for allowing the larger system of security components to locate damaged/error-prone componenets so that they can be replaced/fixed thus raising the overall trustworthiness of the system of components.
 \item The definition of ``trustworthiness'' that is chosen to help color this perspective on security is as defined in the Benzel et.~al.~paper. 
 \begin{quotation}
 ``\textit{Trustworthy} (noun): the degree to which the security behavior of the component is demonstrably compliant with its stated functionality (\textit{e.g., trustworthy component}). \\ \textit{Trust}: (verb) the degree to which the user or a component depends on the trustworthiness of another component. For example, component A \textit{trusts} component B, or component B is \textit{trusted} by component A. Trust and trustworthiness are assumed to be measured on the same scale.''~\cite{Benzel2005}