diff --git a/paper/paper.pdf b/paper/paper.pdf
index 1b51f5aa9d62d83c0dc42ac556c54c00415b8657..0906c4b07b270fad3322db8cad3556bc985e6279 100644
Binary files a/paper/paper.pdf and b/paper/paper.pdf differ
diff --git a/paper/paper.tex b/paper/paper.tex
index 63a7f4e3a80b2e2c159a38d7bfaa2dba9bd70160..653bae278dd70389de13104cd004f423969ee9b4 100644
--- a/paper/paper.tex
+++ b/paper/paper.tex
@@ -496,7 +496,7 @@ However, new challenges surface with the usage of the Internet changing from a r
 
 With the key mechanisms of naming information at the network layer, caching and storing content in the network and native multicast functionality, ICN is put forward as a promising candidate of a Future Internet architecture. \cite{IEEE:xylomenos} Additionally, efficient and reliable data delivery, mobility management and security and privacy considerations are being built into the network architecture. 
 
-The need for ICN highlights the shift of the Internet from a pair-wise communication mechanism between end hosts to a information dissemination system. This is being reflected in the Internet of Things (IoT), a networking trend whereby an ever increasing number of low-power sensor and actuator devices are being connected to the Internet. With data being created at these new end-points, the need for efficient naming and addressing schemes for billions of devices (and contents) arises. Since these devices often need to preserve battery power, the issue of data availability needs to be handled: a possible solution lies in the in-network caching mechanism of ICN. \cite{IEEE:arshad}
+The need for ICN highlights the shift of the Internet from a pair-wise communication mechanism between end hosts to a information dissemination system. This is being reflected in the Internet of Things (IoT), a networking trend whereby an ever-increasing number of low-power sensor and actuator devices are being connected to the Internet. With data being created at these new end-points, the need for efficient naming and addressing schemes for billions of devices (and contents) arises. Since these devices often need to preserve battery power, the issue of data availability needs to be handled: a possible solution lies in the in-network caching mechanism of ICN. \cite{IEEE:arshad}
 
 This paper aims to present the ICN architecture and highlight the specific requirements of IoT when applying ICN as a possible network paradigm to it. To showcase some specific work done on the security and privacy aspects of ICN in IoT, a proposed ICN architecture with focus on security \cite{IEEE:sicari} will be discussed. Finally, the concluding remarks will summarize the topics covered and discuss further work to be done in ICN research.
 
@@ -512,7 +512,7 @@ While traditional Internet architectures are sender-driven, the publish/subscrib
 
 \subsection{Requirements and Challenges}
 
-In designing and building a new Internet architecture, especially in regards to the upcoming Internet of Things (IoT), one has to identify the flaws in the current one and identify challenges to be met. The setting of technical and architectural requirements is the first step in builing a new network better suited for applications of the future. 
+In designing and building a new Internet architecture, especially in regard to the upcoming Internet of Things (IoT), one has to identify the flaws in the current one and identify challenges to be met. The setting of technical and architectural requirements is the first step in building a new network better suited for applications of the future. 
 
 \
 
@@ -520,7 +520,7 @@ In designing and building a new Internet architecture, especially in regards to
 
 \
 
-A future Internet architecture like ICN has to take into account that the connected devices will be very different in terms of available resources, ranging from network nodes with abundant energy, computing power, storage and bandwith to IoT devices with severe resource constraints. 
+A future Internet architecture like ICN has to take into account that the connected devices will be very different in terms of available resources, ranging from network nodes with abundant energy, computing power, storage and bandwidth to IoT devices with severe resource constraints. 
 Furthermore, the means of connecting to the Internet will be extremely heterogeneous. Especially with IoT devices collecting sensor data from sensitive sources (e.g. from smart home environments) security and privacy are strong requirements. \cite{IETF:zhang}
 
 There is a strong need for the use of caching mechanisms. The network needs to support efficient resolution of cached copies of requested data. \cite{IETF:zhang} Through caching, high data availability and energy efficiency are to be achieved.
@@ -535,15 +535,15 @@ Open APIs should be used for commonly used interactions like pull, push, naming,
 
 \
 
-A future Internet architecture like ICN has to accomodate a huge number of connected devices, of which a significant part are going to be mobile. It has to support interactions with applications across boundaries of administration and domains. \cite{IETF:zhang} Architectural requirements are scattered over all of its functional domain.
+A future Internet architecture like ICN has to accommodate a huge number of connected devices, of which a significant part are going to be mobile. It has to support interactions with applications across boundaries of administration and domains. \cite{IETF:zhang} Architectural requirements are scattered over all of its functional domain.
 
-The central requirements for the naming mechanism of ICN are that names are to be persistent and secure, and provide advantages in comparision to traditional host-centric architectures. An ICN system should register, update and resolve a given name without long latencies.
+The central requirements for the naming mechanism of ICN are that names are to be persistent and secure, and provide advantages in comparison to traditional host-centric architectures. An ICN system should register, update and resolve a given name without long latencies.
 Scalability is another central requirement which spans over multiple levels of the architecture: naming, name resolution, data routing, forwarding and security.
 Furthermore, two kinds of internet traffic have to be considered: local area traffic and wide area communications. Both of these kinds of traffic demonstrate a certain periodicity and burstiness in the IoT context. The expected traffic shape has to be accounted for in designing the network. \cite{IETF:zhang}
 
 Since mobility is a central aspect of future Internet architectures, the spatial and temporal context of network connections have to be considered. Moving away from inefficient mobility anchors and tunneling, there is a need for capitalizing on location information in the and taking advantage of multicast and broadcast mechanisms. \cite{IRTF:kutscher} Depending on application domain, locally close devices should be able to form "clusters" to communicate effectively with one another or form long-term connections based upon social contacts. \cite{IETF:zhang}
 
-Security and privacy are fundamental requirements and challenges for ICNs, since in the IoT physical objects are made accessible through a wide network and are often integrated within critical infrastructure and industrial systems. Security requirements comprehend trust management, data integrity, authentication and access control. Privacy requirements are to protect the content and the context arout data from IoT devices. \cite{IETF:zhang}
+Security and privacy are fundamental requirements and challenges for ICNs, since in the IoT physical objects are made accessible through a wide network and are often integrated within critical infrastructure and industrial systems. Security requirements comprehend trust management, data integrity, authentication and access control. Privacy requirements are to protect the content and the context of data from IoT devices. \cite{IETF:zhang}
 
 The network is expected to be self-organizing to the degree that it is capable of quickly discovering heterogeneous and relevant devices, data and services based on application context. To enable this, the infrastructure and application specific logics need to be decoupled.
 Furthermore, there is a need for supporting two modes of network operation: an ad-hoc mode and an infrastructure mode. Devices should be able to switch between being a simply routed network node and performing more challenging tasks like topology discovery and being a temporary gateway. \cite{IETF:zhang}
@@ -562,7 +562,7 @@ Besides the requirements, different challenges present themselves on a technical
 The presence of actuators in IoT devices poses a technical challenge to a data-centric network: a way to model traditional control patterns in ICN has to be conceived. 
 The latency of the name resolution system is critical for real-time or delay sensitive applications. In such cases, a local name resolution schema could be preferred to a centralized one. 
 For caching, the main challenges are to decide what data items are to be cached at all (individual data items / publish-subscribe-lists / \ldots ), and which nodes along the routing path should cache the data in question. 
-Also, mobility and volatiliy of devices and data pose a challenge to the name resolution system, which should be able to deal with these dynamic conditions of the network. \cite{IETF:zhang}
+Also, mobility and volatility of devices and data pose a challenge to the name resolution system, which should be able to deal with these dynamic conditions of the network. \cite{IETF:zhang}
 
 For implementing security and privacy mechanisms, energy limitation is the biggest challenge in resource-constrained nodes. Furthermore, there are several threats posed by the new infrastructure: adversaries may gain access, gather information, forge signatures, impersonate source addresses or manipulate the message exchange with sufficient effort. \cite{IETF:zhang}
 
@@ -576,14 +576,14 @@ In this section, various design choices will be presented which can have great i
 
 \
 
-Data naming is the key mechanism for addressing data content in ICN. But naming can also extend to the naming of services, which could be requested using an unique identifier. \cite{IETF:zhang} 
+Data naming is the key mechanism for addressing data content in ICN. But naming can also extend to the naming of services, which could be requested using a unique identifier. \cite{IETF:zhang} 
 To ensure a verifiable binding between data content and its name, a name-data binding validation is to be established. \cite{IRTF:kutscher}
 
 There are different naming schemes to chose among while designing a name-data binding scheme:
 Hierarchical names have the advantage that scalability is easily achieved by name aggregation. Routing table size can be extensively reduced when names are aggregated in a way that reflects the network topology. Challenges occur when mobile hosts change the topology of the network. \cite{IEEE:xylomenos}
 In contrast, flat names are not bound to a location by virtue of their name: they are location-independent and support mobility better than their counterparts. However, by their nature they are difficult to aggregate and can require mechanisms like \textit{Distributed Hash Tables} to manage. \cite{IEEE:xylomenos} 
 
-With hash-based content names, the hash of a data object is directly embedded in the object's name. \cite{IRTF:kutscher} Another option are metadata-based content names. Relying on the metadata of data objects allows for generating a name for an object before it is created. \cite{IETF:zhang} With indirect binding, the public key of the publisher is embedded in the name and the hash of the data object is signed the the corresponding private key. \cite{IRTF:kutscher}
+With hash-based content names, the hash of a data object is directly embedded in the object's name. \cite{IRTF:kutscher} Another option are metadata-based content names. Relying on the metadata of data objects allows for generating a name for an object before it is created. \cite{IETF:zhang} With indirect binding, the public key of the publisher is embedded in the name and the hash of the data object is signed the corresponding private key. \cite{IRTF:kutscher}
 
 Names can be either human-readable or self-certifying. Due to this, ICN architectures that want to combine both aspects have to rely on additional systems that bind two kinds of names to the same data. \cite{IEEE:xylomenos}
 Furthermore, names can be designed to be confidential so that they don't reveal information about the nature of the communication. \cite{IETF:zhang}
@@ -603,7 +603,7 @@ Name resolution and data routing are the mechanisms thanks to which transmission
 Different approaches are used for resolving names to data sources. ICN architectures based on hierarchical names want to get the scaling benefits without the limitations imposed by the location-identity binding. Architectures using flat names however face the problem of handling a name space without being able to aggregate it. \cite{IEEE:xylomenos} A hybrid approach tries to combine both schemes by concatenating flat names to aggregate them. This would reduce the huge routing table size otherwise needed for flat name routing. \cite{ACM:ghodsi}
 
 Data routing can be coupled or decoupled from name resolution. In the first case, routing information is collected while the name of the requested data is being resolved. The path taken can be stored in the request packets or by the content routers themselves. Usually the data transmission takes the inverse path of the name resolution.
-In the second case, the route the data transmission takes is independently calculated. This can be done by a indipendent system that is part of the ICN architecture or by using traditional IP-based Internet routing once the address of the data publisher is discovered by name resolution. \cite{IEEE:xylomenos}
+In the second case, the route the data transmission takes is independently calculated. This can be done by a independent system that is part of the ICN architecture or by using traditional IP-based Internet routing once the address of the data publisher is discovered by name resolution. \cite{IEEE:xylomenos}
 
 Examples for data routing strategies are Route-By-Name Routing, Lookup-By-Name Routing and Hybrid Routing.
 Route-By-Name Routing is an instance of coupled routing, as explained earlier in this section. 
@@ -617,7 +617,7 @@ Hybrid Routing combines both Route-By-Name Routing and Lookup-By-Name Routing to
 
 \ 
 
-Caching mechanisms are essential to save on wireless bandwith, transmission time and power consumption. Especially on resource-limited IoT devices, caching becomes an indispensable part of the network architecture. \cite{IETF:zhang} Every ICN node can cache data objects and answer requests for that data -- in this way, ubiquitous in-network storage is realized. \cite{IRTF:kutscher}
+Caching mechanisms are essential to save on wireless bandwidth, transmission time and power consumption. Especially on resource-limited IoT devices, caching becomes an indispensable part of the network architecture. \cite{IETF:zhang} Every ICN node can cache data objects and answer requests for that data -- in this way, ubiquitous in-network storage is realized. \cite{IRTF:kutscher}
 
 Caching can be realized in two basic ways. On-path caching provides a short-circuiting of data requests by the router or node that receives them. Instead of relaying a request to the data source, the router can provide the data if the routers cache contains it. On-path caching is facilitated by the coupling of name resolution and data routing, as there are more opportunities to make use of opportunistic caching along the resolution path.
 In off-path caching, external caches announce their contents to the name resolution system. It can then route data requests to the external caches if this would provide a performance gain. \cite{IEEE:xylomenos}
@@ -631,7 +631,7 @@ Through caching, communication can be made faster and more robust by enabling th
 
 \ 
 
-Since devices are expected to be mobile and thus have interruptions in network connectivity, decoupling of sender and receiver is a critical feature of the network. It should be possible to deliver data in an asynchronous way, while saving on power and bandwith by forwarding data opportunistically. \cite{IETF:zhang}
+Since devices are expected to be mobile and thus have interruptions in network connectivity, decoupling of sender and receiver is a critical feature of the network. It should be possible to deliver data in an asynchronous way, while saving on power and bandwidth by forwarding data opportunistically. \cite{IETF:zhang}
 
 \ 
 
@@ -670,24 +670,24 @@ Many IoT applications face challenges like limited IP space, resource constraint
 The ICN paradigm seems to be a good choice as an architecture for the Internet of Things, since the applications and usage of the IoT often embody information centric usage patterns, and the need for maintaining point-to-point communication is lessening. \cite{IEEE:adhatarao} With naming of data being at the core of ICN, the network distributes content and provides a service at the same time. \cite{IETF:ravindran} Namespace issues vanish thanks to virtually unbounded naming schemes, while security is embedded into the content and in-network caching balances network load. \cite{IEEE:adhatarao} 
 
 However, IoT use cases differ in some aspects from the originally intended use case of ICN because of the high heterogeneity of connected devices and the very high rate of newly generated information, among others. Because of this, a good trade-off has to be found between a host-centric and information-centric approach. \cite{IETF:lindgren} 
-IoT networks tend to be studied and treated as indipendent entities, but recent research efforts focus on connecting IoT networks to the current Internet. To connect  ICN networks with IP-based networks, either by offloading routing to the Internet Protocol or by connecting them through gateways. \cite{IEEE:adhatarao}
+IoT networks tend to be studied and treated as independent entities, but recent research efforts focus on connecting IoT networks to the current Internet. To connect  ICN networks with IP-based networks, either by offloading routing to the Internet Protocol or by connecting them through gateways. \cite{IEEE:adhatarao}
 
 \subsection{Specific aspects and design choices for IoT}
 
-IoT has a broad application domain, but still it poses some framework conditions that shape aspects of and design choices for an application of the ICN paradigma to IoT:
+IoT has a broad application domain, but still it poses some framework conditions that shape aspects of and design choices for an application of the ICN paradigm to IoT:
 
 While the retrieval and dissemination of sensor data from IoT devices is well served by an ICN paradigm, controlling actuators in IoT devices appears to be less easily accomplished.
 To achieve this through ICN, the functionality of the actuators have to be mapped to (the requesting of) named data. Possible scenarios are (i) an IoT device periodically requesting its supposed state from the network or (ii) a IoT device invoking its actuation function in response to a received data request. In both of these cases caching can be problematic, if it hinders requests to arrive at the IoT device. \cite{IETF:lindgren}
 
 The name of content in IoT can often be longer than the actual data itself, for example when transmitting simple integer data. \cite{IETF:zhang} There is a trade-off involved in that these numerous small objects result in a larger naming overhead. \cite{IETF:lindgren}
 
-IoT data is often modelled as a stream, e.g. a stream of temperature readings of a smart building. If access to singular values in the stream is wanted, it could be beneficial to support sequence numbers in data requests. If the latest value of a stream is seeked, the corresponding sequence number could be obtained by meta-data transmitted while subscribing or by adaptive sequence number probing. \cite{IETF:lindgren}
+IoT data is often modeled as a stream, e.g. a stream of temperature readings of a smart building. If access to singular values in the stream is wanted, it could be beneficial to support sequence numbers in data requests. If the latest value of a stream is sought, the corresponding sequence number could be obtained by meta-data transmitted while subscribing or by adaptive sequence number probing. \cite{IETF:lindgren}
 
-Since time is an important propery of IoT data, it could be useful to extend an ICN system to embed a mapping from sequence numbers of streams of data to time values. \cite{IETF:lindgren}
+Since time is an important property of IoT data, it could be useful to extend an ICN system to embed a mapping from sequence numbers of streams of data to time values. \cite{IETF:lindgren}
 
 The decoupling of senders and receivers through caching is an important feature of ICN for IoT, since it allows for IoT devices to be offline for certain intervals of time (e.g. to save battery power). \cite{IETF:ravindran} The caching mechanism of ICN ensures that data objects are available even when the device is offline. \cite{IETF:lindgren} 
 
-To support scalability of ICN networks in IoT it is essential to make the named data object immutable. This prevents cache inconsistencies, but also has the consequence that dynamic data has to be modelled as a stream of immutable data objects, which can be more resource-intensive. 
+To support scalability of ICN networks in IoT it is essential to make the named data object immutable. This prevents cache inconsistencies, but also has the consequence that dynamic data has to be modeled as a stream of immutable data objects, which can be more resource-intensive. 
 Furthermore, ICN does not provide processing, transformation or aggregation of data. This is a deliberate design choice, as such operations are better performed on intermediate processing nodes, leaving the network to its main function of distributing data. \cite{IETF:lindgren}
 
 Many IoT applications work with a PUSH model for transmitting data, where the transmission is initiated by the publisher. Since ICN is by design receiver-driven, implementing a PUSH-like model presents a challenge, albeit not a insuperable one. \cite{IRTF:kutscher} A way to resolve this challenge would be to implement triggers for responding to a data request. Data would be pushed when the trigger of the request is fulfilled, e.g. immediately or even repeatedly at a certain time. \cite{IEEE:lindgren}
@@ -704,7 +704,7 @@ Different forms of data collections are possible. \emph{Triggered} data collecti
 
 Since the network structure and scope is simple, a slimmer ICN protocol like CCN-lite or NDN-lite could be deployed. \cite{IEEE:adhatarao} To access the sensor network from the current Internet, there needs to be a protocol translation in place. A gateway equipped with necessary intelligence could perform this task, engineering a near transparent flow of traffic between the two networks to integrate them seamlessly.
 
-In regard to the naming scheme, short names are preferred to minimize transfered data and to save on energy and memory resources of the constrained devices. Still, metadata has to be embedded into the name. A naming structure like \emph{Metric/ID/Area/Date/Time}, where \emph{Metric} is the type of data (humidity, temperature, .. ), \emph{ID} denotes the identifier assigned to a device, \emph{Area} indicates the geographic location of the device and \emph{Date} and \emph{Time} specify the time-related metadata of the sensor reading. A sample name could be \emph{/temperature/UNI/ComputerScience/Building1/room1/03-11-16/12:30}. \cite{IEEE:adhatarao}
+In regard to the naming scheme, short names are preferred to minimize transferred data and to save on energy and memory resources of the constrained devices. Still, metadata has to be embedded into the name. A naming structure like \emph{Metric/ID/Area/Date/Time}, where \emph{Metric} is the type of data (humidity, temperature, .. ), \emph{ID} denotes the identifier assigned to a device, \emph{Area} indicates the geographic location of the device and \emph{Date} and \emph{Time} specify the time-related metadata of the sensor reading. A sample name could be \emph{/temperature/UNI/ComputerScience/Building1/room1/03-11-16/12:30}. \cite{IEEE:adhatarao}
 
 As for gathering the sensor data, a base station in the sensor network could act as a collector / sink. It could employ a publish / subscribe communication pattern to receive the periodic data published by the sensor devices and provide them to the Internet. But a query / response communication model is also applicable: in this case, users interested in some content would query the network with a specific content name. The producer (or caches along the way) would respond with the requested sensor data content, possibly even creating it on the spot. \cite{IEEE:adhatarao}
 
@@ -743,11 +743,11 @@ As an intermediate conclusion, this section will summarize and highlight the maj
 
 \item Self-certifying names are good for decentralized operation of the network
 
-\item Distributed caching allows for alleviating impacts of resource constraints in IoT devices by saving on wireless bandwith and power.
+\item Distributed caching allows for alleviating impacts of resource constraints in IoT devices by saving on wireless bandwidth and power.
 
 \item Applications for IoT networks can benefit from local caches to reduce transmission delays.
 
-\item Intermittent network connectivity is mitigated through the decoupling between publishers and consumers. As each request for a data object is indipendent, there is no need to maintain long-lived connections.
+\item Intermittent network connectivity is mitigated through the decoupling between publishers and consumers. As each request for a data object is independent, there is no need to maintain long-lived connections.
 
 \item ICN's native broad- and multicast support fits well into IoT application scenarios.
 
@@ -805,7 +805,7 @@ There are several research directions which could address current issues and cha
 
 \item Content discovery in highly dynamic environments is still problematic. Novel approaches for efficient information lookup have to be devised.
 
-\item Finally, another area which is not yet explored is Quality-of-Service (QoS). QoS-aware protocols could improve delay and save bandwith to satisfy QoS requirements.
+\item Finally, another area which is not yet explored is Quality-of-Service (QoS). QoS-aware protocols could improve delay and save bandwidth to satisfy QoS requirements.
 
 \end{itemize}
 
@@ -818,7 +818,7 @@ There are several research directions which could address current issues and cha
 
 To provide in-depth considerations of security aspects in ICN-IoT networks, I will review and summarize the work of Sicari et al.. \cite{IEEE:sicari} In the paper ``A Secure ICN-IoT Architecture'' the authors analyze the current security functionalities of the ICN-IoT middleware proposed by the ICNRG (Information Centric Networking Research Group) \cite{ICNRG:zhang}, devise new security schemes and validate the proposed approach by means of a running example.
 
-The ICN-IoT middleware is introduced to challenge the lack of standardized platforms for IoT systems. With ICN-IoT, a set of tools and interfaces is introduced which makes managing interoperability across different hardware and software vendors and vertical application domains possible. These are necessary to tackle upcoming challenges like coexisting protocols and mobility of IoT devices. In building new Internet architectures like ICN, the integrity and confidentiality of the handled information as well as the privacy of user sensitive data have to be preserved. To deal with these issues, the authors take an architectural approach, enriching the ICN-IoT middleware with security functionality. The middleware needs to be able to satisfy three imporant goals: providing a trust model that is suitable for the involved entities and relationships, preserving the privacy for sensitive information transmitted within the network and guaranteeing an effective access control system which is based on well-defined and cross-domain policies.
+The ICN-IoT middleware is introduced to challenge the lack of standardized platforms for IoT systems. With ICN-IoT, a set of tools and interfaces is introduced which makes managing interoperability across different hardware and software vendors and vertical application domains possible. These are necessary to tackle upcoming challenges like coexisting protocols and mobility of IoT devices. In building new Internet architectures like ICN, the integrity and confidentiality of the handled information as well as the privacy of user sensitive data have to be preserved. To deal with these issues, the authors take an architectural approach, enriching the ICN-IoT middleware with security functionality. The middleware needs to be able to satisfy three important goals: providing a trust model that is suitable for the involved entities and relationships, preserving the privacy for sensitive information transmitted within the network and guaranteeing an effective access control system which is based on well-defined and cross-domain policies.
 
 In the reference middleware architecture, IoT services run separately from ICN services. The core functionality provided by the ICN infrastructure is device and network service discovery, naming, context processing, storage and caching. The architecture is subdivided into five components:
 
@@ -876,7 +876,7 @@ This protocol makes sure only \emph{Users} with valid credentials can discover a
 \includegraphics[width=\linewidth]{sns.png}
 \end{figure}
 
-The naming service has the task to assign an authenticate device names. Device names in ICNs are unique and persistent. The process of assigning names to devices securely involves the device, the \emph{Aggregator} and the \emph{Local Service Gateway (LSG)}. When the \emph{Aggregator} receives a secure ID from a new device, it forwards it to the \emph{LSG} along with the signature key and the action key of the device. The \emph{LSG} then assigns a name to the device and generates a certificate that ties the generated ICN name to the siganture key forwarded by the \emph{Aggregator}. After storing the name along with the keys in its local storage, the \emph{LSG} communicates the new name to the \emph{Aggregator}. The \emph{Aggregator} also stores the name-keys-tuple and finally forwards the name to the device, encrypting it with the action key.
+The naming service has the task to assign names to authenticated devices. Device names in ICNs are unique and persistent. The process of assigning names to devices securely involves the device, the \emph{Aggregator} and the \emph{Local Service Gateway (LSG)}. When the \emph{Aggregator} receives a secure ID from a new device, it forwards it to the \emph{LSG} along with the signature key and the action key of the device. The \emph{LSG} then assigns a name to the device and generates a certificate that ties the generated ICN name to the signature key forwarded by the \emph{Aggregator}. After storing the name along with the keys in its local storage, the \emph{LSG} communicates the new name to the \emph{Aggregator}. The \emph{Aggregator} also stores the name-keys-tuple and finally forwards the name to the device, encrypting it with the action key.
 
 This naming mechanism is not only applicable for embedded IoT devices, but can also be used to name high-level IoT devices like \emph{Aggregators} and \emph{LSGs}.
 
@@ -917,7 +917,7 @@ According to the authors, the postulated system represents a valuable starting p
 In the first section of this paper, I provided a general overview over the ICN paradigm, its requirements and challenges it poses to internet infrastructure design. 
 Possible design choices in all relevant areas of ICN development were presented in the second section of the paper. 
 In the third section, I discussed the Internet of Things paradigm, providing specific aspects and design choices for ICN-IoT deployments and highlighting advantages and drawbacks of ICN use in IoTs. Also, a ``smart home'' scenario was given as a sample real-world use case of ICN-IoT. 
-Finally, an in-depth exploration of a proposed secure ICN-IoT architecture was carried out, illustrating the complex interactions that statisfy the high security requirements that are imposed on ICNs.
+Finally, an in-depth exploration of a proposed secure ICN-IoT architecture was carried out, illustrating the complex interactions that satisfy the high security requirements that are imposed on ICNs.
 
 The prospect for ICN use in the real world is promising. Although this new paradigm is still in the research and development phase, some fairly successful implementations begin to surface and prove their worth through performance and efficiency gains. \cite{IEEE:xylomenos} In the years to come, we can expect to see more and more fruitful development.